Recording Sales

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.