If you become involved in making the formalized Finished-Form documents that are part of the system described in Chapter 8C (see page 217), you may find it profitable to know some of the more technical details regarding how we’ve setup the system.  Describing those matters is the purpose of this section.

In general, it is ServiceDesk’s job as part of this system to peruse through the various and sundry files it has compiled, in reference to a particular job, and attempt from there to glean what’s relevant for inclusion into each of the various text boxes of the form you are preparing.  It is further its job, obviously, to attempt to place each item of information into the particular textual format that you’re likely to want for the box into which the item is being inserted.  If you know some details about this process, it will help you understand the results you see, and perhaps help you plan better toward getting the results you want.

First, in regard to the name, address and telephone numbers, you’ll notice these are very straightforward, with information being pulled simply from text within the item’s JobRecord.  The one complication is that, for the Narda form, there’s only spaces for one info-set (i.e., not separate sections for both the paying party and location info).  As a convention for the Narda form, ServiceDesk places the name and address set here that’s found in the ‘Location Info’ section of the JobRecord.  However, in the event it does not find you’ve used that section for an apparent name and address (a matter it deduces by looking for a comma in the LocationName line and an opening bracket in the LocationAddress line), it inserts text from the JobRecord’s Customer-Info section instead.  (Since the Generic form has boxes corresponding to both the Customer and LocationInfo section of the JobRecord, there are obviously none of these considerations in reference to text inserting to it.)

In regard to the P.O. Number, if there’s one present in the item’s JobRecord, ServiceDesk will insert it to the “Special Authorization #” space in the Narda form, and place an “X” in the corresponding checkbox for you.  The “Customer’s Request” information, as inserted to the form, is obviously transferred directly from the JobRecord’s corresponding “Problem to be solved and/or Description of Customer’s Request” box, the “Date Call Received” text is based on the ‘Origin Date’ for the JobRecord, and so on.  Most of that is pretty straightforward.

For the inserted “Completion Date,” ServiceDesk examines the History for the job and looks for an entry with the phrase “job completed.”  Assuming such an entry is found (ServiceDesk will have created precisely this kind of entry on completion of any PostVisitReport in which the query “Is the job done?” was answered in the affirmative), the date of such entry will be inserted for you.

For the blocks describing times when the tech started and ended on each visit, ServiceDesk again examines the History for the job.  Specifically, it looks for the kind of entry that’s created when, in conjunction with a standard, PostVisitReport, the technician indicates what the start and end times, during his visit, happened to be.  Finding such appropriate descriptive text, the system gleans the actual times stated, and inserts them into the form for you.  What it looks for, specifically, is an entry beginning with standard date and time, then a tech’s initials followed by the key word “ there “, then an appointment reference, a comma, then two times separated by the key word “ to “, then another comma and more text (as in “3/4/00 16:42: DS there 14 TUE, 11:40 to 12:30, diagnosed bad valve . . .”).  If you’ve made any manual changes in the job’s History and corrupted this precise kind of format, you may find that ServiceDesk fails to winnow out the start and end times as wanted.

It’s also by reading these particular entries in the History, you should know, that ServiceDesk deduces which technician’s name should be inserted into the Narda form space that calls for one.  At least, this is conditionally the case.  But in fact, you may have a job on which different technicians made separate visits.  If that’s the case, ServiceDesk chooses the name of the technician on the last indicated visit (at least in respect to the last entry it is able to successfully interpret as such).  But it’s still conditional.  If (as we figure will usually be the case) there’s a SalesJournal entry for the job, the system will choose the technician indicated in conjunction with it (always bear in mind that, regardless of what’s inserted for you, you can change any of the form’s text boxes to what is specifically wanted at the moment).

Still another matter concerns the description of work performed (i.e., the space specifically labeled “Service Performed” on the Narda sheet).  In this case, there may be much text in the job’s History that is not a specific description of work the technician actually did, and obviously ServiceDesk lacks the genuine intelligence that would be needed to separate and winnow out such completely descriptive words from other text.  Instead, it does the next best thing.  Basically, it identifies entries made in a PostVisitReport by looking for the same key phrases as described above (i.e., it looks for references to the times when a tech started and ended his visit).  It then assumes that at least most of the language following the preliminaries in such an entry is probably a description of what the technician did, and so culls this specific text and places it into the relevant box on your form.  If there were multiple visits, it includes the text from each, while placing a pipe symbol (i.e., “|”) between each one to help you see the separation.  We expect this is one box (on the form that is) that you’ll edit in virtually every instance, but it should be very easy.  In most cases it will probably be a matter of using your mouse to highlight extraneous text, then hit delete, for maybe a two or three second operation overall.

The last major matter in regard to which the system reads the job’s History is in regard to parts used from stock.  It depends entirely on descriptive language in the History for this purpose, so be sure all stock-used is properly reported through the PostVisitReport system, so that such proper descriptions will be there for this purpose (and again, bear in mind that if you’ve previously changed the ServiceDesk-inserted History text so that’s it’s now different from the expected format, ServiceDesk may fail to glean the needed meaning).  Specifically, to deduce that particular language in a History refers to parts-stock used, ServiceDesk looks for the word “used“, followed by any two words, then the words “from stock“ (as in “ used 1 3363394 from stock “).  On finding this kind of a phrase, ServiceDesk deduces the quantity and part number of item used, and makes corresponding entries in the form for you (actually, there’s more work to do in figuring the prices that should be inserted for such parts, as described later in this section).

Several of the Narda boxes refer to information specifically about the machine that was serviced (i.e., make, type, model, serial, purchase date and selling dealer).  As you might guess, this information is taken directly from any UnitInfoSheet that’s attached to the job, with each such item of information inserted to the appropriate box on the Narda form (or Generic form, for those boxes that are applicable).

The Narda form also includes, you might notice, boxes for a “Servicer Number” and “Servicer State Number.”  For this data, ServiceDesk looks to the QuickEntry template for whichever client is in the CustomerInfo block of the item’s JobRecord.  In other words, if you have a QuickEntry template for Whirlpool, say, and the job has Whirlpool listed as the client (i.e., it’s their name and address in the CustomerInfo block of the JobRecord), ServiceDesk will look to the QuickEntry template that you’ve created for Whirlpool.  If it finds that you’ve listed a Servicer ID and Servicer State # in the spaces there provided, it will insert those same numbers into appropriate spaces on the Narda form.

Also on the Narda form there’s a space for a “Service Agreement Number.”  Basically, if you’ve indicated a “Contract Number” in the item’s JobRecord (like many other items in the JobRecord, this will typically have first been entered from the job’s initiating Callsheet), that’s the number ServiceDesk will place into this box for you (see page 59).  Also, you may note that besides its own pre-printed Number in the upper-right corner, the Narda form has an open space directly below.  This is for your own, internal job-identification number—which of course in ServiceDesk we refer to simply as the InvoiceNumber.  Thus, ServiceDesk will place its own InvoiceNumber, for the job, in this location, and print it to the form.  This will be useful, obviously, to help you refer back to the job when a Narda claim is returned, paid, or there’s any similar action.

There are some other, miscellaneous boxes on the Narda form which ServiceDesk makes no effort to fill.  If they need filled, you’ll have to do it yourself, manually—which should be little effort, considering how few are left.

Aside from those many miscellaneous boxes, there are of course two large, multi-box sections remaining, in both the Generic and Narda forms.  These are: first, the set of boxes that describe parts used; and second, the set where charges are totaled.

In regard to parts used, we’ve already mentioned that, for parts used from stock, the system deduces such usage by reading through the job’s History (see several paragraphs back).  That, of course, explains how it deduces how many of which kind of parts were used (which it sensibly places into the appropriate boxes on your form).  It does not explain how it deduces what price, for the parts, should be inserted in boxes indicating such.  For this deduction, ServiceDesk looks into either: (a) your MasterPartsPlan; or (b) your Journal of Stock Transfers (see page 144).  Specifically, if loading info to the Generic form, the system figures you must intend retail price for parts used, and so gets this price from the item’s entry (which should include expected retail price) in the MasterPartsPlan.  If, on the other hand, it’s loading info to the Narda form, we expect that you probably need to list your cost on the part (since, as a rule, that’s what Narda-type clients demand to have listed).  So in this case, the system finds the most recent Journal entry showing use of the part, and inserts the price paid (as indicated in that entry) for the part.

While that describes the situation in regard to stocking parts used, it’s obviously a different matter when dealing with parts special-ordered for a job.  Here, it’s actually a bit more simple.  ServiceDesk simply checks the PartsProcess files (both Current and Archived) for entries that correspond with the invoice number of the job in question.  For any such entries that show a date in the ‘Date Received’ box, the system figures you presumably must have used the part, and so inserts its description, part number and so on into appropriate boxes of the form.  For price to insert, it looks for a value in the same entry’s ‘$ Sold’ box, and inserts this into the appropriate space on your form.  For Distributor Invoice Number, it looks in the ‘Notes’ section of the entry.  If, as the first “word” in this entry, it finds text that’s all numeric (i.e., “1568556” as opposed to “C1568556”) it concludes that must be the invoice number on which you purchased the part, and inserts it to the NARDA as such.  Regardless and in any case, some editing may sometimes be required.  If for example a wrong part was ordered and received, the system may erroneously include its entry, as though used, within your form.  Alternatively, a part may have been ordered, used and received without the expected processing through the PartsProcess system.  If this occurred, it’s entry will not be found and inserted for you.  You’ll have to be watchful for such possibilities, and edit from within the form accordingly.

Finally, we are concerned with how ServiceDesk fills the various boxes in either of the forms’ totaled items columns.

In the Narda form, you may notice, there’s a box (under the column of prices for parts used) labeled “Sub Total”.  Here, and with obvious logic, the system simply places the total of the various parts prices that are listed above.

Aside from that simple matter, and in its last reading of the job’s History, the system looks to see if there’s an entry there, as is made by the system when the job is finally recorded to the SalesJournal (see page 167).  Specifically, it looks for this precise text “, ttl $” (as appears as part of an entry such as “3/15/00 13:04 BN: rcrdd blld cmpltn in SlsJrnl, ttl $117.54”).  Assuming that it finds that little snippet, the system figures you’ve indeed made a SalesJournal entry on the job, and that it should be able to find such an entry within your SalesJournal.  Thus, it makes a search therein.  Assuming that it finds such an entry, it pulls the amounts indicated and places them into appropriate spaces on the form.

A question, in this regard, is what should the system do if it finds a parts total, as indicated in the SalesJournal entry, that differs from the total as deduced by adding the prices for parts as listed?  To which figure should it give deference as values are inserted to the form?  In the case of the Narda form, there’s a box for you to fill-in your “Handling” fee on parts used.  Thus, for this form only we figured it was sensible to deduce that any difference, between parts total as indicated in the SalesJournal entry and parts total as derived by adding actual parts, must be a handling fee, and that value, if any (i.e., the difference between) is inserted to this box for you.  In the case of the Generic form, no such assumption seems sensible (nor is there a  separate box for a so-called handling fee).  So, if there is a discrepancy in this case, the system alerts you with a descriptive warning, and for the time-being places a row or asterisks in the form’s PartsTotal box.

As you edit in either the parts description boxes or the totaled item boxes, you’ll notice that the system automatically does the appropriate math to adjust the carryovers for you.  As we’ve indicated elsewhere, however, the system is new, so it will not be too surprising if you discover imperfections.  If so, please let us know.  

A final caveat concerns the searches that are done within the PartsProcess Archive (to find parts special ordered) and the SalesJournal (to find totals charged).  In respect to the first (and to conserve time searching), the system looks back no further than 300 records deep into the Archive (of course it searches the current PartsProcess file in full).  In respect to the SalesJournal, it searches no more than 1000 records back.  In consequence, if you’re trying to load data into a form from a job that was completed some significant time ago, you may find the particular items of data which correspond with these searches do not automatically fill-in for you.  Of course, you can still type-in the relevant information manually.  It’s just not as easy or convenient.