Finding customer records

Because there are so many available, we want to provide a synopsis here of the various kind of customer records you can look up, and of the contexts in which you may do so.

First among the records, of course, are the Callsheets. These are created, obviously, when a job (or often merely a telephone call) comes in. When their task is complete, they are moved and stored permanently within the CallsheetArchive. From this context past call records can be viewed page-by-page, or of course you may conduct specific searches for any particular name segment (see page 80). Sometimes it’s very handy, even, to use this as a kind of telephone book. You need a number for so and so, and remember you must have fielded a call or two from them in the past. Just do a quick search in the CallsheetArchive and, wala, there’s the information.

More typically, of course, you’ll be interested in looking up information that directly describes past jobs—for which purpose JobRecords are obviously much more useful than Callsheets. Current JobRecords can be viewed record-by-record in the JobsCurrent form, archived ones in the JobsArchived form. Specific searches may be conducted from either form, but it's typically much better to search in both records simultaneously using the CstmrDbase utility. As explained elsewhere (see page 283), the underlying data for this utility consists of records from both contexts, and it uses indexes to rapidly search among and locate the particular records wanted. There are several contexts in which searches may be conducted from among these indexes. We’ll summarize them here.

First, there’s the auto-CstmrDbase-Search utility, which (so long as it’s turned on) functions automatically whenever you're typing into a name, address or telephone-number box of a Callsheet (see page 66). A search is likewise conducted whenever your cursor is in such location and you also press F1. Second and closely related, there’s the JobsCurrent form’s built-in CstmrDbase-Search, which allows you to press F1 (from within the JobsCurrent form) to search simultaneously on all of an existing job’s relevant fields (see page 106). Alternatively, you can put your cursor in a particular field and press F1 to search specifically on it. Third, you’ll very frequently be using the convenient CstmrDbase-Search utility that’s provided as part of the TechInterface form.

Given that latter form’s name, you might think its CstmrDbase search feature would be oriented more toward technicians than office personnel, but this is not the case (in fact, given the form’s expanded functions it ought to have a different name, but we haven’t thought of one yet). At any rate, whenever you want to lookup something in the CstmrDbase and you’re not otherwise in a Callsheet or similar context in which the search text either exists already or is something you must type-in, there, regardless, the easiest method is to just hit F12. This loads the TechInterface form and selects its CstmrDbase search option. Thus your only remaining step (after hitting that one key) is to begin typing in your search target (no need even to specify whether it's a name, address or telephone-number you're looking for). As the list of matching items pops up, you can click on any one to view it fully (or more easily hit F1 to enter the list and display the first item, then use the cursor keys to move up or down viewing others). Also note that from here you can directly print the history of any selected item (see page 74), a feature that’s not so conveniently available from other CstmrDbase contexts.

While CstmrDbase-oriented searches are extremely powerful, you should remember their limitations. Consider, for example, that any JobRecords added since the last indexing event will not appear in a CstmrDbase search. These must be found by direct searches in the JobsCurrent form (however, if you use the Auto-Archive function, there will never be more than a day’s worth of jobs in such category). And there are kinds of searches that cannot be run from any of the various CstmrDbase contexts, but can be from elsewhere. If wanting to locate a job by P.O. Number, for example, you'll have to conduct a search directly from the JobsCurrent form (for current jobs) or JobsArchived form (for archived jobs). Or if wanting to locate by street name, a utility for the purpose exists only within the JobsArchived form (thus, it's impossible to search from among current jobs by street name).

If you consider the path of job progression in ServiceDesk, you’ll realize that when a job or mere call first comes in, there is first a Callsheet created, which we’ve already discussed as forming the potential for subsequent lookup. Then, when an actual job is created, there’s the JobRecord. We’ve just discussed the potential for lookup in those. Now what else happens? What other kinds records are created that we might have occasion to lookup?

Well, there’s the process of ordering non-stock parts. These incidents leave specific records in the PartsProcess system. Maybe you want to know, for example, what kind of part you ordered for so-and-so two years ago, who you ordered it from, and for how much (or how many times you’ve ordered that part, what’s the range of prices paid, etc.). Use the PartsProcess Archive to quickly look it up and find out.

Then there’s the process of using, restocking and reordering the parts you do stock. All records regarding such history are kept in the InventoryJournal that’s part of the InventoryControl system. To lookup and review this kind of data, use the InventoryControl form.

What about funds collected from a customer? There’s a couple of files applicable here, the FundsJournal and the ApplicationsJournal. Depending on context, either or both may be used when wanting to lookup the relevant history regarding payments from any particular customer, or in connection with any particular job (and of your related deposit activity, etc.).

Amazingly, all these records may be created before a job is even completed. And with that event, even more records are produced. Most importantly, there’s a record that contains an entry describing each and every completed sale (i.e., the SalesJournal). Many times, you may want to lookup a specific such record. Use the SalesView form. Of course, if there were still amounts outstanding when a sale was completed, there will also be an AccountsReceivable record in its connection (at least until paid). Use the AccountsReceivable form to lookup and review these.

The primary point here is that there are a multitude of methods which allow you to quickly put your finger on the particular record that has the information you want. We urge you to become familiar with and use all of them.