Poor Steve McKlintock, I don't think we need to name this thread after him
anymore.
At 10:47 PM -0800 1/5/00, Susan Kline wrote:
>Back in 1994, when I bought my 486, I didn't want to spend a lot of money
>on programs. I also was quite new to computing. The store people steered me
>to MsWorks, and I struggled for a few days learning to build databases
>and spreadsheets. Pretty soon it came very naturally, and I built forms
>for invoices, estimates, etc. I have a database for customer records,
>with an estimate form as page 2, so I can print from it. I can sort by
>many topics, and I can search easily.
>
>It really wasn't that hard. I don't think it was any harder than it would
>be to buy someone else's program aimed at piano tuners, and learn it and
>adapt it to individual needs. Certainly I didn't spend $300 worth of time
>on it, and I still use it, almost unchanged, after 6 years.
>Go for it!
My sentiments exactly. It's all programming whether you're writing in an
app's scripting language, or an operating system's developement language.
If the language is complete enough and if you know what you want to do (and
if you don't mind reading the manual and subscribing to the publisher's
listserve), it's amazing what you can come up with.
My basic "business suite" is a file set of three databases: Customer (where
a record is one customer), Accounts Receivable (the record, an invoice),
and Phone Log (the record, an answering machine message or otherwise to-do
item). The way they interact should be just the way you would want to do it
with pencil, paper, eyeball and brain.
When I enter the customer name of a new invoice, the AR file lookups in the
CUS file for a match with the lastname just entered. If there is only one
matching last name entry, the AR file can bring back the corresponding CUD
ID (first three letters of the last name plus first three numbers of the
last four in the phone number). If the lookup finds more than one customer
with that last name, it draws a scrolling list of "CUS ID + First Name +
(Town)". I click and the current record is tagged with the proper CUS ID.
In the Phone Log, if I want to know who else to schedule in the
neighborhood of the current answering machine request, a click draws me a
scrolling list of everyone in the CUS db who shares the same neighborhood
("Geo" field) as the current request in Phone Log. I select as many as I
want from that list, and this column of selections is deposited in the
"ToDo" field for that particular phone request: "Last Name + , + First Name
+ ..... + Phone#". This same database also dials my phone numbers for me.
The next file set is for estimating: CUS, "Parts List" (each record, a
piano part or a chunk of my labor), and "EST Proposal" (each record, a
proposal which will mutate to a contract). "Parts List" is essentially a
scratch file, in which each estimate is composed one at a time, but any
estimate can be archived in this file to be later reconstructed (should
the customer decide yes three years later, or should a new estimate be
similar enough to an earlier one to be based on it). 284 records: 22 for
subcontractors' primary chunks of work, 69 steps of my labor, and 193 piano
parts.
The estimate is laid out in outline structure beginning with primary chunks
(string ass'y, action or case), within that, areas of work (ie., in action:
keyboard, action recondtion, new parts install, regulation, and xn
weigh---you get the picture, and within these categories, the separate
chunks of labor (or separate ways of getting through that area) and the
parts and supplies used in each chunk of labor. It distiguishes between a
core piece of work, an option and a contingency. The estimate thus drawn up
can be outlined, based of the primary chunks of work, or based on the
divison of labor and parts. (The labor page of the report can be used as a
shop sheet, and the parts portion of the report can be turned into faxable
orders to each vendor, as well as notes on what parts and what amounts were
actually used on the job and whether you would use them again in the future.
"Parts List" can forward a summary of each primary area of work to "EST
Proposal". (BTW, My next project with "Parts List" is a field for each
record, converting my own sparse and cryptic nomenclature into plain
English (either words, clauses or sentances), so that this summary will
require little or no translation into consumer-friendly copy for the
proposal.) When you and the owner have discussed the proposal, options get
dropped or folded into their associated primary areas. A quick pass through
"Parts List" and the payment schedule is calculated (deposit = all of
parts/materials + 1/3 of labor for 1st primary, 2d pay = final 2/3 labor
for the first primary + 1st 1/3 labor for 2d primary.......you get the
picture.)
Back before Black Easter Morn of '97 (when the file directory of the hard
drive volume where I stored files got trashed), I even had a shop time
accounting file. In it, Net Time figures for the minute breakdown steps of
the labor steps on which the current job was estimated can be entered on a
daily basis. (Yes, the whole thing is based on time studies and job
costing.) At the end of each job, a shop time summary could be archived to
serve as feedback on the accuracy of the original time figures used for
"Parts Lists"'s estimating. I'll get back to that one. I'm also toying with
a way of stroring the large amounts of action touchweight analysis
acculumating around here.
My favorite database is compact ("Parts List" checks in at 136K), it's
RAM-based so it's extremely fast, and the scripting language is extensive
enough that folks in the mailing list discussion group are using it for web
server cgi's and point-of-sales. And Fans of "the other database"
(FileMonkeyPro) have the impression that this one's a flat file db. Oh yes,
it's also in Beta for Windows 99.
Life? What's that. It sounds likea database problem to me.
Bill Ballard, RPT
New Hampshire Chapter, PTG
"When writing a mental note, first procure a mental piece of paper"
............mental graffitti
This PTG archive page provided courtesy of Moy Piano Service, LLC