When the technician finishes a job, he of course is generally done with it. But not the office. We still have additional work to do, and that is the subject of this chapter.
While collected moneys are your business's lifeblood (and expected surpluses its reason for being), it's no secret that such collections depend, ultimately, on something even more basic: completed sales. It's further no secret that sales figures are the first input into the accounting process—which, in turn, leads to the financial statements by which you can tell whether, in the long run, you can expect to have any money surpluses at all (and on the basis of which you'll calculate income for paying taxes, etc.).
Here again we tread in an area that is already well-traveled by other software. In particular, there are many applications that allow you to record individual sales in the context of a larger accounting package. We have found, moreover, that many ServiceDesk buyers are already setup and practiced in using these other systems. Thus, the question arises as to how much, if at all, your ServiceDesk sales-recording features should supersede those already used in an accounting context, or if they should be used in a fashion that duplicates those already used, or not used at all?
In regard to the possibility of using the ServiceDesk sales-recording features in a fashion that duplicates entries still being made in another context, the answer is simple: DON'T DO IT! No one wants to enter the same information twice; its just doesn't make sense (except possibly during a limited transition period, when you're testing ServiceDesk features to assure they’re adequate to your requirements).
In regard to the possibility of simply not using the ServiceDesk sales-recording features and continuing to rely, as you presumably have in the past, or another application for the purpose, the possibility exists, but you should be aware that you'll be sacrificing several elements of automatic-interface between various aspects of ServiceDesk operation. The normal method by which JobRecords are checked-off as ready for archiving out of the JobsCurrent file, for example, is via your entry of a completed sale through the SalesEnter system (at which point ServiceDesk automatically checks the corresponding JobRecord into "Recorded to SlsJrnl" status). Absent your use of the SalesEnter process, another means is needed for this indication. Similarly, if you do not enter your completed sales in the ServiceDesk system, there will be no means, therein, for automatically verifying that adequate funds are collected, for creating an AccountsReceivable file, for generating automatic Billing reminders, creating Commission Reports, searching past sales in the SalesJournal, and so on.
Since so much utility would be lost in the absence of using the ServiceDesk sales-recording features, we think such a course would be inadvisable in all but the most unusual of circumstances. Instead, we suggest that regardless of what package you've been using in the past, you now rely exclusively on ServiceDesk features for the purpose of recording individual sales. If there are things your old package did in connection with individual sales that ServiceDesk does not yet do, and you really want those features, let us know and we'll try to incorporate them in an update that we'll rush just for you.
Of course, ServiceDesk will not do your financial accounting or the expense side of your bookkeeping. Yet, doing your sales and accounts-receivable is, essentially, taking care of the revenue side of your bookkeeping (at least that portion involved with performing service). This raises the question: How do you integrate ServiceDesk (and these revenue-side functions of accounting that it’s performing) with whatever other system you have used or will use to do the balance of your bookkeeping and accounting?
At first blush, the problem might seem a difficult one, but in fact it’s very simple. If you’ve been using QuickBooks or almost anything similar, chances are that you were formerly recording each of yours sales, individually, within it (and managing each of your accounts-receivable there, etc.). To move into ServiceDesk for those functions, you’ll simply cease to record individual sales transactions in that old context, instead using the facilities provided within ServiceDesk. Then, as often as you compile financial statements (whether once a month or once a year), you’ll run a report in ServiceDesk that summarizes its revenue side activity. You’ll then take those summary figures, and input them into QuickBooks or whatever other system you are using. (For detailed instructions in how to do this, see the section that begins on page 302).
In other words, the detail work for your revenue side activity (recording each individual sale, handling each receivable, etc.) gets shifted into ServiceDesk. Your financial accounting package no longer gets to handle that particular kind of detail. Instead, it just gets a summary regarding that particular activity, and then incorporates this summary into its calculations of profit/loss, etc.
By following this basic outline, you'll be letting ServiceDesk do what it does best, while at the same time allowing your accounting/bookkeeping software to perform where it most excels.
Having now discussed whether you should use the ServiceDesk sales-recording features in preference to other systems you may already have, we obviously need to discuss what those features are, and how they are used.
Basically, there are three forms involved, one for entering sales, one for reviewing past entries, and one for creating reports. They are appropriately called the SalesEnter, SalesView, and Reports forms (accessed by pressing F9, SHIFT-F3, or F11, respectively, or by clicking on the corresponding MainMenu command buttons).
Beginning with the first of these forms, suppose you have several invoices reflecting completed sales, which now need entered. With the invoices in front of you, access the SalesEnter form by pressing F9. The form will now display, showing your most recent ten entries (the intent is that with a reminder of what was last entered, it may help you avoid even the attempt to enter the same items twice). Your cursor is positioned on the entry line, and there is a note indicating the items of data ServiceDesk expects you to enter from the completed invoice. You might note that you're instructed to separate each item on the single line by a comma (rather than having separate boxes for each item), which is more reminiscent of the old DOS environment than Windows. The reason for this setup is because, for items that are entered in the same order so frequently that the sequence becomes a matter of automatic habit, separation by commas is easier and more efficient than tabbing between boxes. Sales, hopefully at least, will be entered with great frequency, so we want an entry method that is as efficient as possible.
There are, as you'll see, nine items of data requested in a single line of entry. These are the TechCode (i.e., two-character initials for the tech completing the job), CustomerName, InvoiceNumber, MerchandiseSold (i.e., if you sold a whole machine that is categorized differently, for your purposes, than mere parts), PartsSold, S.CallSold, LaborSold, InvoiceTotal, and Paycode. The last item should be a "1" or "2", which designate, respectively, either that the job was completed and paid for, or that it was completed but billed.
There's an important convention that applies in regard to entering the CustomerName whenever you've got a third-party payer job (i.e., one party paying, work is being done for another). Enter the last name or initials of the paying party, then a hyphen (no spaces), then the last name where the work was done. Thus, a job might be designated here as "AHS-SMITH"—providing on-its-face evidence of both payer and service location.
Upon completing a line, press Enter. At this time ServiceDesk will review your entry, making several checks to verify its legitimacy.
First it checks the entry's general form, verifying that you have correct quantity of items entered, that your TechCode and Paycode are acceptable values (i.e., the indicated TechCode must correspond to a tech you actually have, the Paycode must be either a '1' or a '2'), that your invoice number is in the proper format (i.e., five or six numbers, no letters), that you have numerical amounts where monetary quantities should be indicated, that each of the constituent amounts correctly add to the indicated total, and so on.
Next ServiceDesk checks in the JobsCurrent file to find the record corresponding to the InvoiceNumber you've indicated, and makes sure you've indicated the appropriate CustomerName. It further assures, while there, that you haven't previously reported a completed sale on the item (to help you avoid making inadvertent double sales entries), and even checks in the string of entries being made (not yet recorded to the SalesJournal) for the same purpose. Finally, if you're indicating a Paycode 1 (i.e., paid) sale, ServiceDesk checks in the FundsJournal (as described in the last section) to assure there are entries there showing receipt of funds adequate to the sale.
If ServiceDesk discovers a defect in any of these areas, it will inform you of the precise discrepancy, and coach you in its correction. The beauty of this system is that it's almost impossible for you to unintentionally make an erroneous entry. This not only enhances accuracy in the record, but also frees the operator from the need to exercise great care. Thus, she can enter data almost recklessly, with great speed and abandon, confident that if and when she errors, ServiceDesk will immediately lead her toward correction.
Typically, an operator will sit down with a stack of invoices representing the previous day's sales. She'll go rapidly from one item to the next, entering each in rapid succession, taking very little time as she gains experience.
You might notice that as each such item is entered, it moves up into the list displayed above the entry line. If the operator needs to, she can move up into the list and edit entries made in the present session. She can conclude the session and record her entries either by clicking on the indicated command button, or by simply hitting Esc (to exit the form), at which time ServiceDesk will ask if she wants to 'save,' allowing her to indicate 'yes' with a press of the Enter key (for many people, a simple Esc/Enter sequence is easier than using the mouse to click on the command button, then hitting Esc to exit the form).
While entering paid jobs is straightforward, there are some additional procedures you should know about when entering billed (i.e., Paycode "2") sales. In such a case, you'll find ServiceDesk expects to create an AccountsReceivable record for each entry, reflecting (in the AccountsReceivable file) the fact that you expect eventual payment, from your customer, on it. Specifically, you'll find ServiceDesk presenting, for your review and approval, the contents of the A/R record it intends to create, including the customer's formalized name (as it would need to appear, in case this customer doesn't pay promptly, on a dunning letter), mailing address, and so forth.
It also shows the amount already paid, if any (as gleaned from the FundsJournal), while requiring you to indicate, in a field labeled "Attn designee or Salutation," the name to be used, should a dunning letter become necessary, following either the letter's "Dear . . . " salutation in those instances where the customer is a person (i.e., you'd indicate "Mr. Smith" for a customer named John Smith), or following "Attn: . . . " on the envelope in those instances where the customer is a business (i.e., you'd typically indicate "Accounting" if you have no specific contact person at the business, or the name of that person if you do).
When everything is appropriately acceptable in the proposed A/R entry, you can click on the indicated command button or hit Enter to indicate your acceptance. ServiceDesk will then place you in the position for your next SalesJournal entry.
As is obvious from the context, these Paycode "2" entries result in ServiceDesk writing new records not only to the SalesJournal, but also to the AccountsReceivable file. Less obvious, but something you should know, is that with either Paycode entry ServiceDesk also writes a note to the job's History, reflecting entry of the completed sale. This, then, provides on-its-face documentation, within the job's History—of its final step to completion. It further marks the JobRecord as being ready for movement out of the JobsCurrent file and into the JobsArchived file, the next time an ArchiveJobs routine is run.
There are a few other incidentals you should know about.
First, you should understand that we make use of four other PayCodes, besides the "1" and "2" mentioned. These are "3," for an entry that indicates final payment on a job that was formerly billed, "4," for an entry that indicates we've given up seeking payment and are writing off the receivable as a bad debt, "5," for an entry regarding a discount that was granted a customer for rapid payment, and, finally, “6” for an entry indicating that a fund item was written off as missing or unredeemable (i.e., a bad check that could not be collected on, a denied credit card that we could not correct, etc.). These four kinds of entries are all made from other contexts for you (see pages 157, 179, 161 and 162), so are discussed here only incidentally. What all these Paycodes do (or rather, the necessary succession of entries under them), among other things, is to enable ServiceDesk to compile periodic sales summaries (see page 172) that show not only total sales, but what quantities were sold but billed, what was formerly billed and now collected, what was written off in any period, and what discounts were granted. These values have great analytical and informative power in their own right, of course, and besides are needed as inputs for your financial accounting system.
Second, it probably does not happen infrequently, for you, that a job is canceled by the customer after it's written up, but before your tech even gets there. Or it's a callback, and the total sale ends up equaling zero. In either case, be sure to record the item as though it were completed sale, albeit one with a sale amount of zero. It's important to do this, at least, to allow removal of the item's JobRecord from your JobsCurrent file.
Third, please remember there is an alternative mechanism via which you may arrive at the SalesEnter form for the purpose of making entries there. Rather than doing it in a batch process as is generally described here (i.e., taking a stack of tickets on which all preceding work, such as Post-Visit Reports, etc, has been done, and making sales entries, one after another, for each item in that stack) you may instead choose to use the Integrated Processes option, via which, upon finishing a Post-Visit Report where the job has been completed, the system will lead you automatically—but for that ticket only—into the Finished-Form and/or SalesEnter processes as well (see page 116). Or you can link to the SalesEnter process from the FinishedForm context as a standing-alone type of link (see page 188).
Finally, we have some advice regarding the procedure for handling your final, remaining copy of the invoice (the one you've got left after other copies in the multi-part set have been given to the location resident, sent as a bill to the customer, or simply discarded). As you finish recording a stack of Paycode "1" (i.e., paid) invoices to the SalesJournal, immediately use one of those little date stampers to imprint the present date, and do it in some regular place you've decided on (on the invoice’s bottom right corner works well for us). This date stamp then provides subsequent evidence, on the face of the invoice, that it's sale was recorded to your SalesJournal on the indicated date. As you follow this practice each day, placing the resulting set of invoices on top of that generated the previous day, you'll end up with an ever-increasing physical archive of your completed invoices.
Of course, you'll also have your retained copy of billed invoices to deal with. Here, as you finish entering a stack of Paycode "2" entries, we suggest you pick a different place on the invoice to imprint the date-stamp indicating your entry. Thus, by its different position, this stamp will indicate the date on which the invoice was recorded to your SalesJournal as done, but not paid. Once this is done, the invoice will obviously go into some place you've setup where you keep them while awaiting payment. When payment arrives, you'll obviously locate the particular invoices it pertains to (from this place), and with these in hand, go to the FundsForm procedure (described at page 157) to enter receipt of the check, and to indicate which invoices it pertains to. As you complete this procedure, we suggest you document its occurrence and timing by date-stamping the invoice a second time, but in this case in the same location (again, bottom right corner works well for us) as you did for jobs that were initially paid. Thus, by examining the invoice afterward, you can see from the first date stamp when the invoice was initially recorded as a billed job, and from the second when it was subsequently recorded as paid.
Once they've been by this final hurdle, we suggest you add these once-billed-now-paid invoices onto the same stack in which your COD invoices are also accumulating, as described above. In result, you'll end up with a stack that contains all your invoices, arranged in the order (as identified by the stamp date on them) by which each was entered into your SalesJournal and (whether initially or ultimately) also paid. In other words, the stack ends up containing all your invoices in the date sequence by which Paycode "1" or "3" entries were made on them (invoices in Paycode "2" status, obviously, did a temporary diversion into your AccountsReceivable pile—until they became Paycode "3"s). You may also include in this archived stack, and in the same order, any billed jobs that you ultimately had to write off as uncollectible (i.e., Paycode "4"s).
While referring to this stack of fully done invoices (i.e., they're completed and paid for or written off), it should be obvious we're using the term "stack" somewhat loosely. In reality, we expect your stack will be segmented into various parts, conveniently placed in neatly labeled, ordered boxes, possibly shelved side-by-side. The main idea is for you to have this physical archive of all your invoices, added to continually in the particular date-of-entry-to-your-SalesJournal sequence described. This has some advantages, to be described shortly.
Having gone to the trouble of creating a unique entry in your SalesJournal reflecting every single invoice’s final resolution in terms of sale (or perhaps a pair of entries, reflecting those jobs first billed then paid), it's obvious you might want to view those entries, maybe do some editing, or possibly search for particular entries in which you might have an interest. Press SHIFT-F3 to bring up the SalesView form. As you'll see, it offers several viewing options, allowing you to view either entire pages from the file (whether beginning at a specified date, record number, first page, last page, etc.), or to search for specific records based on name, invoice number, or total amount of sale.
Regardless of your needs, the form's operation is self-explanatory. When viewing entire pages, you can use the PgUp and PgDn keys to move to adjoining pages. If conducting a search and the found entries fill an entire page, you can resume searching on a clean page simply (as prompted) by pressing any key. Search targets needn't be complete: a mere name segment will do, and global characters can also be used. If you need to edit an entry, again follow the normal ServiceDesk convention by left-clicking on it. ServiceDesk will enclose the item in edit boxes, allowing you to change any field as desired (the value displayed as 'total' will change automatically for you, as values are changed in constituent fields). Just press Enter when ready to record your edits (or Esc if you've changed your mind and want to leave the record unaltered).
You'll notice that the SalesJournal records contain minimal information, consisting of nothing more than what you entered during the SalesEnter process, along with six digits denoting the date of your entry. Some early users have requested more data here, but there's a purpose in the brevity. Because of the relatively small individual record size, you'll be able to accumulate many years of sales data in a single, manageable-size file. Plus, it makes it possible to run an unsorted search through a file containing tens of thousands of sales entries in a reasonable amount of time. More extensive data on individual jobs can be found elsewhere (in the JobsArchived file, for example, accessed through the CstmrDbase system). It is simply not the purpose of the SalesJournal to provide such detail: it's a different kind of record.
As one advantage in this system, you'll be able to do something very few businesses can: lay your hands on a particular invoice (i.e., the authentic paper copy), within only moments of formulating the desire—even if that invoice dates from years ago (while the need to review physical invoices from the past is much reduced, given extensive information in the JobsArchived file, there is sometimes no substitute for having that actual paper in your hands).
To accomplish this legerdemain, you simply must allow your invoice archive to accumulate in the systematic, easy manner described in the last section. Then, when you need to locate a particular item within it, all you need to know is the date the invoice was added. Knowing this, finding its location in the stack becomes as easy (in principle at least) as finding a particular page number in a sequentially numbered book (in this case, your date stamps on the invoices are the substitute for page numbers). It's in knowing the proper date, to locate in the stack, that your SalesView form comes into play. With its search features, you can quickly locate the date of any item's final recording (i.e., entries with Paycodes "1", "3" or "4") to the SalesJournal—which date, if you've followed our advice, will also correspond with what's stamped on the invoices, and with their physical sequence within your archive stack.
One suggestion in regard to this invoice stack. Have strict rules about removing invoices from it. Don't let anyone ever remove such an invoice from your office, or even take it out of the stack for more than a few moments of quick examination, or to make a photocopy. And be religious about being sure it gets immediately back to its proper place. Otherwise, your only paper document having the customer's signature, and all the technician's handwritten documentation on the job, will be lost. You never know when it might be needed.
While the Reports form has functions broader than merely reporting on sales (it can also produce Commission reports, Wage reports, and Aging of Accounts Receivable, for example), it bears mentioning here, for the sake of contextual discussion, that this is the specific form you'll use (press F11, or click on the corresponding MainMenu command button) when wanting to compile reports on sales. As you'll see from the form, you can do this on a daily, weekly, monthly or yearly basis (or as often as you wish, and covering whatever period you wish). You can print reports to either your screen or printer, and applicable to all sales, or only a particular department if wanted (see following). The reports include a plethora of data, along with useful ratios and other figures. There should be everything you need for thorough analysis, and to provide the particular figures that are needed for entry into your accounting software (see page 302), for compiling legally-required sales tax reports, and so on.
Some of our clients have wanted to separately track sales between different parts of their company's operation. One client, for example, has a division doing appliance service, another HVAC work, still another plumbing, and one involving over-the-counter parts sales. To know the separate profitability for each operation, they needed to know the specific sales of each. Thus, we have added a feature allowing this. It is purely optional: if you want to use it, you must enable the option from the 'Network' section of the Settings form (press Ctrl-F1 or use the MainMenu to access this form).
When enabled, you'll find that as you go to create a job from the Create Job/Sale form (see page 72), ServiceDesk will at such time require that you specify the department to which the job belongs. That assignment will then stay with the job, and never needs to be re-specified in any other context.
For the purpose of making this specification, there's a list box that will appear in the Create Job/Sale form (it appears only if you've enabled this feature from the Settings form). Initially, this box will be empty. To place names for each of your departments into the list, simply type in each name, and press Enter. You'll be required to use your password (this is to prevent a mere operator from altering the list), then each name will be part of the list from then on (unless deleted by you, which also requires your password).
Thus, after you've entered each of the department names into the list box, they'll be there from then on—for your operators to select the appropriate department as they create each job.
At present, any job's particular department-assignment is operationally substantive in only one context (though the assigned department will display from the JobRecord, and can be changed from there). When you produce a Sales report from the Reports form, if you have the Departmentalize feature enabled, you'll see a list box showing each of your departments. If you want your report to reflect sales only in a particular department, select that department (otherwise, the report will show all of your sales). Or you can select an option to print a departmental summary, that will tally the principle total figures for each of your departments. It's that simple.
Eventually, as we expand ServiceDesk to track specific job costing (or as we have particular requests), we'll likely expand the functions from which a job's department-assignment is referenced. For now, it's only in Sales reports where the matter is relevant.
There is still another area where many small businesses lose shocking sums of money. It's the matter of managing accounts receivable. We need, quite obviously, to police every item of money owed to us, to assure it's promptly paid, or that due and proper notice is sent when it becomes past due. But in most setups, this requires dedicated, ongoing, seemingly constant attention—and with the press of completing new work so demanding, it's common for office personnel to let this need slip. The best solution, obviously, is to make managing accounts receivable into a matter that involves only minimal labor, rather than much. As you might expect, this is precisely the solution ServiceDesk provides.
The primary file that's used to deal with AccountsReceivable is called, not surprisingly, the 'AccountsReceivable' file. As mentioned elsewhere, for every billed sale that you record via the SalesEnter system (see page 165), ServiceDesk creates a unique record, within this file, reflecting the sale and its expected payment. Thus, the file becomes a simple set of records reflecting every past sale on which payment is still expected.
ServiceDesk provides two forms for working with this file.
First is the AccountsReceivable form, which individually displays all the data from each record. It further provides search capabilities between records, various housekeeping and editing functions, and many other capabilities. To access it, press F3 or click on the corresponding MainMenu command button. You'll see that most of its functions are quite self-explanatory.
The second form (accessed by pressing Ctrl-F3) addresses more of an operational need, for aside from keeping our AccountsReceivable records, reviewing and/or editing them as needed, and so on, our real concern is to be sure each is promptly paid—or that appropriate reminders are sent (in the forming of dunning letters or statements) if they are not. For the function of sending such reminders, we use the Dunning form.
In regard to billing reminders (whether you prefer sending them in letter format or as more typical statements), you should note that here is another area where ServiceDesk discriminates between companies you've designated as ‘HighVolume’ types (see page 60) and all others. The reason is because, presumably, your HighVolume-type clients will probably owe on many receivables at one time, while regular clients will probably owe on just one (or certainly not more than a few). In addition, the preferred format of treatment is likely to be a little different for one type than for another.
Regardless, upon viewing the Dunning form (again, press Ctrl-F3), you’ll see that your first option is to specify whether you want to do 'Standard Dunning' or 'Special HVC-type Notices. The methodology for either procedure is almost self-explanatory, but we'll overview here regardless.
We should start by clarifying a matter of terminology, and connected practice. Some companies are accustomed to sending out—as a way of reminding customers to pay what’s owed—what may be thought of, more or less, as standard “statements”. Others have used more of a letter-type format, with each letter explaining in more of a conversational manner what’s owed (with these typically being referred to as “dunning letters”). As another difference, some companies send statements right up front, without waiting for items to become past due. Others just mail a copy of the invoice for initial billing, and don’t send statements (or, or course, dunning letters either) until after that initial request becomes past due. You can do it any way you wish within ServiceDesk, though typically we think it’s easiest to use the invoice-copy method (or, actually, one part of a multi-part form) for initial billing, and send a statement or dunning letter only later, when and if the item remains unpaid. Regardless, whether it’s statement format or dunning letter, we’ll refer to both here, generically, as “billing reminders.”
With that said, you should begin by understanding that, at this time, ServiceDesk is not configured to produce finished billing reminders for your normal (i.e., non-HighVolume) clients. Instead, the idea is for it to produce the raw data that can then be fed, typically, into the mail-merge (otherwise known as “form letter”) feature of a word processing program, such as Microsoft’s Word, for example, which will then take the data and place it into whatever finished context you may prefer. The reason for this design, obviously, is that it allows you nearly infinite flexibility in formulating your billing reminders in whatever manner you most prefer (in fact, you could even use contexts other than word processing for the purpose, such as Microsoft’s Excel spreadsheet program, for example).
If you have not previously been involved in creating merge documents, we'll explain a little here. This is what big companies use to make it look like you’ve received a personal letter, when in fact your name and other information is just inserted at the right places within the text of a letter, in the address area on an envelope, and so on. The text might even vary, from place to place, depending on particularities in your own data. The reason they’re called “merge” documents is because of how it works. Essentially, there’s two documents that are merged together to make the set of output documents that’s personalized for each of maybe hundreds or thousands of individuals. One document (generally called the “Master” document), essentially contains the overall instruction set and common text. The other (generally called the “Data” document) contains the particular data for each of many individuals.
How it works is like this. The master document has the general text along with places, here and there, where essentially the internal instruction says "put the NAME from each individual here,” or “put the FIRST LINE OF THE ADDRESS here,” and so on. The data document, by contrast, has a paragraph of text items for each individual, with separate text items within that paragraph, each containing a particular element of information that’s relevant and available for insertion to the master document. When it’s all setup just right, the word processing program looks at the master document, then at the first paragraph of text from the data document, and inserts each element of text from that paragraph into appropriately-instructed places from the master document, sending the “merged” output to a new document, which you can then print. It then does the same from the next data paragraph (as pertaining to the next individual represented there), and so on through the entire set.
If you’ve not previously setup a word-processing program for this kind of feat, the task can at first seem daunting. That’s why we’ve set it up so you don’t have to. Instead, we’ve created a Word-based master document for you, that will produce very nice billing reminders.
It’s designed to produce them in a format that’s something of a hybrid between a typical statement and dunning letter, hopefully carrying most of the advantages from each. It’s designed to make the letters vary in tone, urgency (and threat level), depending on how many previous reminders have been sent. Though you may need a magnifying glass to make them out, the following three items illustrate the kind of output that the provided Word master document will produce:
Please note that you’d want to print these on paper with your own letterhead, and at the bottom (from within the Master document, of course) you’d need to replace the text, where it says “Name of Sending Person” with a real person’s name from your company. Please also note that you could change any of the other text (from the Master document) in any manner you might wish, though much of it is hidden and conditioned on particular circumstances (one receivable item versus more, how many previous reminders, etc.). Figuring out how to make the whole thing work when dealing with the hidden, instructional text is, again, not easy.
Of course, if you’re up to the challenge, you may produce any kind of master document you wish (it is, in general, a one-time task, for typically you’ll be wanting to use the same master document over and over again, month after month, year after year). We’ve provided one for you (one that produces the kind of reminders shown), simply to make it easy for those who don’t wish to struggle with producing your own.
Regardless, once you have your preferred master document in place (again, for simplicity we recommend using ours), the task of producing your finished billing reminders, on a monthly or more often basis, is a very easy and simple one. It’s done in three simple steps.
In result of this simple sequence (should typically require less than 3 minutes), you can happily watch as a succession of perfect billing reminders stream from your printer—in whatever quantity as Special HighVolumeClient Notices
Ordinarily (and hopefully, at least) there's much less trouble collecting from the big institutional type of clients that you will have designated as ‘HighVolume’ types. Most pay reliably, within some predictable time frame, on almost all invoices. However, it still happens occasionally that a few invoices somehow fall through the cracks. Some system is needed to regularly remind this type of client of the particular invoices which have so fallen. In this case, a somewhat different format seems preferable, and probably less formality is needed. For such reason, in this context we’ve designed it so that ServiceDesk will generate the reminders for you directly.
To use this feature, begin again by loading the 'Dunning' form (press Ctrl-F3), then select its 'Special HVC Notice' option. Immediately you'll see a list of each company you've designated (from the 'QuickEntries' form) as a ‘HighVolume’ type company (see page 60). Click on any company you're interested in, and immediately you'll see a report indicating what the receivable status is from that company (i.e., how many items and of what value over 30 days, over 60 days, etc.). If you wish to generate a reminder notice to this company, simply indicate when prompted. As you'll notice, you can specify any period of tardiness you wish to include in the notice.
In result of the sequence, ServiceDesk will independently generate a nice little summary for the company involved, which you may then either mail or fax.
As you can see, we've made the process for sending these reminders very easy (easier than for normal billing reminders, for here there’s no need to go through a merge-document type of procedure form a separate word-processing program). Still, if you don't have the discipline to go through it on a regular basis, it will do you little good. To stay right on top of things, you should create and send these reminder notices on at least a monthly basis. Please see that you do.
In case you're wondering how items are taken out of AccountsReceivable status upon being paid, we'll simply mention here that it's done, using a utility provided for the purpose, within the FundsForm (see page 157). You'll notice, in this regard, there's an item of information, displayed in the AccountsReceivable form and pertaining to each record, that indicates how much has been received on the sale in question. Whenever funds are checked in via the process just mentioned, this figure is updated by ServiceDesk for you. Of course, there may be occasions when you need to adjust the value manually. If so, it's easy to do so directly from the AccountsReceivable form (for the sake of security, this does require use of the owner/manager password).
As various AccountsReceivable records are in fact paid off (and their PaidToDate figures consequently indicate an amount equal to the sale), their records obviously don't need to exist within the file any longer (they are, after all, no longer AccountsReceivable). Thus again, we have a place in ServiceDesk where there’s need, to run a routine with some regularity, that purges no longer needed records from the file. This is another of the events that will be done for you, on a nightly basis, if you have the Auto-Archive feature turned on (see page 209). Otherwise, on at least a monthly basis, you should click within the AccountsReceivable form on the button labeled 'Clean-out completed items'. This will run a routine that removes all records from the file which have a PaidToDate amount equal to (or exceeding) the total sale. If this routine is not at least occasionally run, your AccountsReceivable file will grow ever larger, becoming filled over time mostly with items that have been paid and which need no longer to be there. Eventually, ServiceDesk will note the excessive size and alert you to run the routine.
Unfortunately, it’s a sad reality that the path to retirement for some receivables is not by virtue of having been paid. Sometimes you’ll find an item is simply uncollectible, or at least that further efforts to collect are not worthwhile. In such cases, you need a formalized method to "write off" the debt (i.e., to remove its item from the AccountsReceivable file, record the loss, etc.). This function is also addressed from the AccountsReceivable form. Simply bring up the particular record you're interested in, then click on the command button labeled 'Write Off as Bad Debt'. In response, the form will fictitiously change the item's 'PaidToDate' value to equal the sale amount (this sets up the record to be purged the next time you run the 'Purge Chaff' routine), and it will simultaneously make a Paycode "4" entry into the SalesJournal (see page 169), reflecting the loss. That entry (along with any similar ones) will then be the basis, when you later compile a SalesReport, of showing what you lost in bad debt during the period (as is necessary for entry into your accounting program).
In introducing this section, we mentioned that the primary file for managing the various accounts on which you expect payment is the AccountsReceivable file (reviewed and managed via the AccountsReceivable form). This discussion would not be complete, however, if we did not mention another file and its associated form.
It so happens that on some receivables you’ll receive a series of payments before the amount is paid in full (thus, you’ve got multiple payments on one bill). On others, you’ll receive a just one check that applies to several different bills. From the accounts receivable file, the system keeps track only of the total that’s been paid, at any given time, on any given receivable. There’s no history there of how the payment came in (i.e., via what checks, on what date, and applied in what amount, to which receivables?). Sometimes, this latter information can be very useful (as when, for example, a client claims they made some particular payment against a certain claim, and you need to go back and see if you actually received the check, and if so how you actually applied it).
The ApplicationsJournal (a separate file) is intended for this purpose. In one sense, you might say it’s a bridge between the Funds form (where any payment on a receivable should be checked in, see page 157) and journal, and the AccountsReceivable context. Basically, each time you check in payment on a receivable, the system makes entries into this journal, for you, regarding how the fund was applied (i.e., how much on which receivables). Thus, you have a permanent record to refer back to, when needed.
To access and review this information, use ApplicationsJournal form, accessed by pressing Alt-F9. There are self-explanatory search and review features, but aside from that, there’s essentially no work to be done within this form, for its purpose is informational only.
The next chapter has two sections. Arguably, the first should instead be fitted as the third section in this chapter (indeed, right here in this very spot). The section is about submitting electronic claims, after all, which directly involves post-completion management (the precise focus of this chapter, so you’d think it should go here). But as it happens, claims submission is done within the Finished-Forms interface, which is the direct topic of the next chapter. For such reason, we place the discussion there.
