In this regard, ServiceDesk recognizes two broad contexts in which a typical service company collects funds.  First, is where moneys are collected either before or concurrent with job completion, as is always the case with COD jobs, and may happen to some extent even with billed jobs (as when collecting deductibles on a home-warranty type job, for example).  In this context, the funds are usually collected by a technician, and it's similarly him who brings them to the office.  The second context is where the job was completed with funds still owing, so the job is billed, and payment is received thereafter.  Here, payment usually comes by mail, and is received directly by the office.  Depending on the context, the processes for making entry of the receipt within ServiceDesk (and assuring that all appropriate entries are made) are considerably different.

The first context is addressed, for the purpose of entering funds received, via the PostVisitReporting process (see page 110).  As you may recall, one of the queries you (or your reporting tech) must answer, during this procedure, is whether any funds were collected from the customer, if so what kind, how much, and so on.  Based on your answers, ServiceDesk will make an appropriate FundsJournal entry for you, regarding all details of the fund received.  This reporting venue is used, for funds received prior to or concurrent with job completion, for several reasons.  One is convenience.  Since most collections in such context are done in the course of a technician's actual visit to the home, it follows that you'll be making a PostVisitReport, in such cases, regardless.  Thus, no separate effort is required to report on the money received; it's simply done in consequence of other procedures you're doing already (for those few items collected separate from a scheduled visit—yet with a job still pending—you can still use the same PostVisitReporting context).  This venue also allows ServiceDesk to make a redundant recording of the collection within the job's History, making the narrative there, as it pertains to the particular job, more complete and informative.

In the second context, when payment is received after a job has been completed and recorded to your SalesJournal (in this case it will have been recorded as ‘billed’), you should note that its JobRecord will have already been closed out.  Thus, the PostVisitReporting process will no longer be available as a venue for making reports on the job.  Thus, a different ServiceDesk venue is needed for recording payments that come in on a job that was formerly completed and billed.  Here, we simply use a feature, directly within the Funds form, that’s specifically provided for the purpose (press Ctrl-F9 to access the form, then select its 'rcv Payment on frmrly billed job(s)' option).

Basically, the system will walk you through a procedure in which it collects info about the particular item of money received (most always either a check or credit memo for parts used, in this context), then asks about each invoice the payment should apply toward, in what portion, and so on.  In consequence of your answers, it makes entries in several files.  First, it makes a single entry to the FundsJournal regarding the particular receipt you've reported.  Second, it makes as many entries as are needed (some checks obviously apply to more than just one invoice) to a file called the ApplicationsJournal (press Alt-F9 to access it).  Here, ServiceDesk keeps a running record, solely for your benefit, of how you instructed it to apply every portion of every check received for such purpose.  Third, it makes an entry to every relevant AccountsReceivable record, showing application of the indicated amount.  And finally, if such application satisfies the total due on a receivable (most often the case), it makes a PayCode 3 entry to your SalesJournal, which of course documents the fact of final and complete payment (see page 169 for an explanation of PayCodes).  Thus, a lot of entries are made in various files for you, based on your execution of a single, simple procedure.

To recap, there are two general methods by which we report on each item of money received.  For items received in connection with jobs that are not yet recorded to the SalesJournal, we use the PostVisitReporting process (each such report results in a narrative description in the job's History, as well as the all-important FundsJournal entry).  When receipts come in after a job's been recorded to the SalesJournal (meaning such receipts must be in payment on billed jobs), we use the specific function, provided for this reporting purpose, in the FundsForm (in result, an appropriate and specific entry is again made to the FundsJournal, together with corresponding entries in plethora of other files).

Now that we know how ServiceDesk collects information for its detailed record concerning every item of money received, the next question is how it uses this data to insure you never lose any such item of money without knowing it, nor that you ever mistakenly credit yourself with receiving a fund when in fact you haven't, nor that you ever record as ostensibly paid a sale that in fact wasn't, nor that you ever initiate a job that doesn't end in a properly documented sale with funds collected, etc.

Let us first examine the last-mentioned security need: how do we assure that for every job created, there is an internally-documented resolution showing its proper conclusion and sale amount?  This purpose is met, most conveniently, by the WorkInProgress system.  Quite simply, once any job is initiated in ServiceDesk, its newly-created JobRecord goes, unavoidably, into the JobsCurrent file—and there it stays, inexorably, until it is finally released by the act of it's recording to the SalesJournal.  If some tech absconded with a job you initiated and called it his own, therefore, or if he simply lost it, the result is that the invoice doesn't come back for recording to the SalesJournal.  And without this act, the job's record remains in the JobsCurrent file, attracting attention as it gains quickly in age (particularly if you use the WipAlert system, see page 118).

For our next security need, let's consider how ServiceDesk assures that no sale is ever recorded as paid, unless in fact it has been paid.  This security need is provided somewhat differently depending on whether the job is being recorded as already paid at time the sale is recorded, or as being first recorded as billed, then later paid.

In the first context, ServiceDesk fulfills its automatic sentry function by making its own little check each time your operator attempts to make a PayCode 1 sales entry (the type indicating a job is already paid).  Quite simply, it peruses the FundsJournal to assure adequate receipts can there be found, for the indicated invoice number, and matching the amount indicated for the sale.  If it cannot find such amounts, it simply disallows the entry (if too much is found, on the other hand, it provides notice of the fact so corrections can be made).

In the second context, it should be understood that ServiceDesk automatically creates a unique Accounts Receivable record, for each and every billed job, each time a billed sale is recorded (PayCode 2 in the SalesJournal).  Significantly, this A/R record can never be credited with any payments (absent use of the owner/manager password, at least) unless it's done, by ServiceDesk, through the specific process that's provided, in the FundsForm, for reporting on billed funds received (see description several paragraphs back).  Of course, this process in itself results in appropriate and matching entries being made (reflecting receipts adequate for any A/R credits) to the FundsJournal.  And further, a billed item can't be finally recorded to the SalesJournal as paid (a PayCode 3 entry) absent the same process.  In consequence, in both this context and the first, it's impossible for any non-password-equipped staff member to credit any sale with payment, in any context, unless in fact there are entries in the Funds Journal reflecting at least ostensive receipts in an adequate amount.

An incidental concern involves the fact that many times billed jobs are already partly paid when the sale is initially recorded (particularly in the case where you've received home-warranty deductibles).  As an item's Accounts Receivable record is created via the SalesEnter system (see following section), it must show that partial payment.  At the same time, we want to assure that no greater partial payment is shown than has actually been received (or at least as is shown for claimed receipts in the FundsJournal).  This is done, quite simply, by ServiceDesk performing the same kind of perusal as when a paid job is initially entered.  It checks the FundsJournal and will not allow the entering operator to claim more, for recording as partial payment in the item's Accounts Receivable record, than is reflected there.

By these various means, we assure with great certainty that we'll know about any job which doesn't make it to final and proper recording via the SalesEnter system.  And further, for all jobs that are recorded as having been paid before or at time of completion, we assure they cannot be so recorded unless there are corresponding entries, reflecting adequate receipts, in the FundsJournal.  And, for all jobs that are recorded as being billed, we assure they cannot be so recorded absent creation of a specific Accounts Receivable record for each (which cannot show even partial payment absent adequate receipts showing in the FundsJournal).  And, before any Accounts Receivable record is credited with subsequent payments and then closed (with corresponding final entries being made to the SalesJournal), we again assure that the FundsJournal must show at least ostensive receipts adequate for the specific application.

Thus, and in consequence, the FundsJournal becomes the place where we maintain record of, and verify, the adequate collection of funds in connection with every sale.  At least, we should say, it's where we have entries reflecting claimedreceipts that are adequate for such purpose.  Whether you actually have the ostensive funds in possession or not, of course, is quite another question, involving still another step in the verification/security process.

This additional step is achieved without the slightest additional effort on your part, as a built-in aspect of the last thing you typically must do, regardless, in specific reference to funds received: depositing them.

Specifically, within the Funds form ServiceDesk provides a dedicated process for preparing your bank deposits (whether consisting of cash, check or bankcard).  To use this procedure, begin by loading the form (press Ctrl-F9), then select its 'Assemble deposit/items report' option.  At this point, you'll be asked what type of money you wish to make a deposit on, then shown a list of all such items that are awaiting deposit, and asked to click on those you actually intend to deposit at present (or you can simply enter a name or check number and have the item selected for you).  At conclusion of the sequence, ServiceDesk will print a deposit document for you, listing each of the items and total, with a statement at top indicting your business name, date, and bank account number.  Typically, it's a good idea to print two such copies, one for the bank and another to provide a hard copy in your own records.

Security flows from at least two factors here.  First, because your operator sees a listing of all pending receipts during the deposit process, it's immediately obvious if any are physically missing (of course, she should immediately bring this to your attention).  Second, because no item will check-off in the FundsJournal as having been deposited absent its journey through this process, it follows that its listing will remain in there, under 'undeposited' status, until and unless the process is actually completed for it.  Thus, if the process is not completed for any particular item of claimed receipt, it will continue to show there, attracting ever-more attention as it gains in age—refusing to die until someone pays proper attention to the fact that you have, as a claimed item of receipt, an item which never has made it through even ostensive deposit/disbursal.

Of course, absent still additional measures, it would be conceivable that an unscrupulous operator might go through the deposit-preparing process itself (thus checking-off several receipts as having been supposedly deposited), without actually taking the money to the bank (or even that the bank might itself lose the deposit).  Thus, still more verification is needed.

This last purpose is achieved by virtue of the fact that, when your operator completes that deposit-preparing process within the FundsForm (with ServiceDesk simultaneously checking-off each included receipt as having been supposedly deposited), at the same time it makes still another FundsJournal entry.  Specifically, it makes a 'deposit' entry: a line indicating that on such and such a date so many checks (or other kind of receipt item) were deposited, totaling such and such amount.  This new entry then becomes something else that must be checked-off, or else it will attract attention as it gains in age.  And significantly, a mere operator does not have the power to check this item off.  On the contrary, this process requires use of the owner/manager password.

Specifically, it is the responsibility of the owner (or other completely-trusted person) to periodically run, from within the FundsForm, the procedure labeled 'Confirm deposit/item reports'.  Typically, you should complete this ritual on a monthly basis as part of the process when reconciling your monthly bank statement.  Quite simply, ServiceDesk will display a list (within any category, whether cash, check or bankcard) of all claimed deposit/item reports that an operator has ostensibly made, and which has not heretofore been confirmed by you.  You can simply look at your statement and confirm if, in fact, that item was received by the bank (or received by you, if that's how it was disbursed).  If so, indicate the confirmation.  The item will then be checked-off (only with use of the necessary password), and of course will not re-appear during subsequent procedures.  The beauty is that if any claimed deposit process didn't actually get where it was supposed to go, you won't be checking it off, and thus will see the fault right away during completion of this process.

Thus, we have complete security, assuring there are actual funds for all ostensive collections listed in our FundsJournal, and that all these are properly deposited—or we'll know about.  Of course (and by virtue of other measures described), we also are confident that, once initiated, all jobs will eventually be recorded to our SalesJournal—or we'll know about it.  And, naturally, we’re also certain there will be entries within our FundsJournal adequate for each sale recorded—or we'll know about it.

It would be difficult, to say the least, for an unscrupulous employee to find a way around these means (providing you keep the owner/manager password secret), or even for losses by carelessness to go unnoticed.  That's security very few small businesses possess (at least in the absence of an owner who personally, and with great care, handles every item of money, every deposit, every claimed sale for adequacy of payment, and so on).  Indeed, since even a careful owner might lapse into occasional oversights, security would still be less complete, in such a case, than ServiceDesk automatically provides.

The above was a broad overview, and will provide sufficient knowledge for most of the situations you’ll encounter when managing your funds.  Even so, there are some abnormal situations you may sometimes need to deal with.  If so, you’ll need to know how.

As one complicating factor, for example, you may have a client that routinely pays amounts different than you've billed (G.E.'s home-warranty administration is infamous for this).  Sometimes they might pay too little, sometimes too much.  You may find you're able to apply excesses on some invoices toward deficiencies on others, and keep a tally that's approximately adequate, at least, for overall needs.  It may be, indeed, that it's much easier to simply keep a tally of their overall pluses and minuses, and check-off each item as though paid for the right amount, so long as the net position stays reasonable.  ServiceDesk accommodates this need with what it calls an Errors and Discrepancies account.  The process is self-explanatory, in the FundsForm, from the context of reporting on payments received on a billed job (an EDA account can be viewed, for any client on which you're created one, from the Applications form, accessed by pressing Alt-F9).

Aside from customers that simply "goof up" on the amount paid, you may have some to whom you routinely grant a discount in return for rapid payment (AHS, for example, offers more rapid payment in exchange for a 2% discount on each invoice's face amount). This complicates the process of reporting on payments received, because you'll be wanting to check-off each applicable invoice as "Paid In Full"—even though, in fact, you've received 2% less than its face amount.  The solution: When reporting the check's amount, simply include a plus sign (i.e., '+') after the entered number (as prompted on the form during the procedure).  This tells ServiceDesk the payment is a discounted one, and in response it asks you the discount rate.  Then, for purposes of crediting each applicable item with payment, it pretends the check was for the full, non-discounted amount.  Following this, as you conclude reporting on each item to which the check should apply and approve recording the transaction, ServiceDesk makes an entry in your SalesJournal reflecting the discount you granted the customer.  This is a PayCode 5 entry.  When you generate a SalesReport later on, the total of such discounts, if any, will be included as part of the report.  How you handle this figure within your own financial accounting is up to you (see page 302 for tips on how to input such information to your own separate system).  Simply be sure it's factored in.

Another complicating factor arises when you're working on two invoices for the same customer at once, and they pay for both simultaneously with just one check.  Or, you might be finishing one job and at the same time open a new invoice for something else, and they pay for both the completion and a deposit on the second invoice with one check.  In either case, you've got one check that needs applied in part to one invoice, and in part to another.  While there are easy, built-in provisions for dealing with multiple fund applications in the post-completion, billed job context, nothing is inherently built-in to handle such realities when the appropriate fund-entering context is via the PostVisitReporting system.  Of course, in this context the need for multiple application of a single fund happens only rarely, so we get by with a mere Band-Aid approach.

Specifically, we create a supplemental pair of FundsJournal entries.  The first is labeled "MoveAppFrom" and the second "MoveAppTo."  Essentially, if a single receipt applies to two invoices (remember, we're only talking about the context of non-billed, COD jobs here), we'll have one FundsJournal entry that credits it, initially, to just one of the two—then, in addition, this pair of adjusting entries that transfers an appropriate portion of the receipt's application from the first invoice to the second.  These "MoveApp" entries will be made automatically in result of queries made at the time the receipt itself is entered through the PostVisitReporting process, but can also be added, should the need become apparent, directly from the FundsJournal.  You’ll see an option provided there for the purpose (this is another operation, incidentally, that requires use of the Owner/Manager password).

Another special situation arises when you’ve made refunds to customers.  Obviously, you’ll want to document having done this.  The Funds form provides an option for the purpose, and it too is self-explanatory.

Still another situation  arises when some item of money proves to be uncollectible.  Perhaps you attempt to run a charge against someone’s bankcard, for example, and the charge is denied (and you’re unable to get the customer to give you a better number).  Or maybe a check bounces irretrievably, or an item of cash is physically lost.  In any such case, you need a means to document the sad outcome.  As in many other ServiceDesk contexts, you can delete an item in the Funds form simply by right-clicking on it.  Of course, if writing-off a bad fund, mere deletion is not adequate.  While we don’t want the item to remain in our list demanding deposit, we don’t want it removed, either, without documenting the fact that we’ve incurred such loss.  For this reason, when you right-click on an item from in the Funds form, you’ll see three options.  One, as in other contexts, is for simple deletion of the item (see following section for explanation of circumstances where you might want this).  In the alternative, you may “Write-off the item as Uncollectible,” or to write it off as “Missing.”  If you choose either option, the item will be marked as requested—plus the system will make an entry in your SalesJournal indicating the loss.  This is a PayCode 6 entry, and the total of such losses is another matter that will be reported, for use in your accounting, whenever you compile a SalesReport.

A final situation involves the occasional need for entry of some fund receipt, into your SalesJournal, absent any of the more automated means previously described.  Perhaps, for example, you received a bad check which was replaced either with a new check or some other form of replacement money.  This new item needs entered to your FundsJournal (for proper tracking and deposit), yet neither of the normal entry-creation venues (see section I, this division) are appropriate.  For this and any other miscellaneous need to manually create a new receipt-of-fund entry, you’ll find facility in the Funds form for such purpose (a command button in lower-right corner labeled ‘Add items’).  If you’re adding a new entry in replacement of an old, incidentally, be sure that you also delete the old entry.  

‍

For the most part, keeping your FundsJournal neat and tidy will involve nothing more than routine use of the operations described above.  However, you should understand that doing this involves something of an ongoing housekeeping task.  It’s something you have to pay attention to.

In particular, and in addition to attending to the various processes already described, you’ll probably notice the same thing we have: occasionally spurious entries will appear in your FundsJournal.  These are not spurious in the sense that they came out of nowhere.  Instead, what typically happens is that someone is making a PostVisitReport.  They report on a fund received, then realize they did it wrong, so report again.  In consequence, the Journal ends up with two entries for the fund receipt, one accurate and one spurious.  When your processing person prepares a deposit, she’ll find an actual fund item that corresponds with one entry, but not with the other.  In the context involved, it will be fairly apparent to her that one entry is a spurious duplicate, and she’ll logically not attempt to include that one in her deposit.  If she’s clever, however, she’ll add some notation to its text. indicating her conclusion (as in many other contexts, left-click on any item in the list to edit it).  In consequence of not being included in the deposit, naturally, the item is not so checked-off.  Thus, until something more is done, the item remains in the list as (supposedly) needing to be deposited.

This is why, as the password-equipped owner/manager, you should periodically check the listings in your FundsJournal for such items, and remove any that are verified as being spurious duplicates.  To do this is fairly self-explanatory.  First select the ‘View/Edit Items’ option, then ‘All’ as the Kind of Fund to be viewed, then ‘Receipts,’ then ‘Undeposited/Unverified’.  Look toward the top of the list (spurious items will eventually migrate there as all contemporaneous and older items get moved out of the category by virtue of having been deposited) for items that should have been included in previous deposits but were not.   Hopefully, your deposit preparer will have added some notation indicating he belief that the item is a duplicate or otherwise in error.  You’ll want to verify the conclusion before deleting the entry.  To do so, you’ll want to see what other entries have been made in connection with the same job.  Just note the invoice number the payment is connected to (part of the entry information), then do a “search” in the form to find all entries pertaining to that number.  Maybe, for example, you’ll see there’s two entries of $40 each.  If you then hit SHIFT-F3 and search on the same InvoiceNumber in your SalesJournal, you may confirm that the total sale was only $40.  Thus you’ll know that the second of two entries must have been a goof by the entering person, and you can go back to its listing, and right-click on it to invoke a deletion.

On the other hand, of course, you might find there are older items in the listing, that should have been deposited already, that are legitimate entries.  This, obviously, will incite a prompt discussion with your deposit preparer.  What’s the deal, you’ll ask?  Why is that item still lingering there, without showing deposit?  Preferably, if there was cause for any legitimate item to linger (for us, it’s sometimes been a missing check and the preparer has been trying to get a replacement from the customer, or maybe a bankcard number that wouldn’t clear, and she’s still hoping for eventual success), your deposit preparer will have informed you already, so there’ll be no surprises.  However, you can see that it’s important for you to go through this inspection process, periodically, just to make sure.

At any rate, you may note that several ServiceDesk contexts have systems for policing you, attempting to cajole (and sometimes coerce) you into keeping on top of various tasks.  The Funds form (and its associated FundsControl system) is no exception, except here it’s as a mere incidental byproduct of how the system is setup.  As in many other systems that keep track of records over time, there is also the need here to separate the newer, actively working area of records from that which is merely historical.  In this case, however, rather than having separate files (i.e., a current file for active records and archive file for historical ones), we thought it more convenient to use a single file and moveable partition.  Basically, the system tries to keep track of how far back, in the list, is the oldest unresolved (i.e., not checked-off, written-off, deleted or otherwise disposed of) item.  All entries more recent than that are considered current area, and all older considered, well, oldarea.  It helps the system perform many tasks more quickly than otherwise when it knows that any current items must be on one side of the dividing line.

The reason this system helps to police you is because, if you allow older and older items to accumulate without resolution, the system will not be able to move the Current-Area Partition forward as it would like to.  Every time you attempt to load the Funds form, in consequence, it will inform you the CurrentArea has grown to large.  It will ask for permission to attempt to move the Partition forward.  If you’ve left old items back there, however, it will be unable to, and will so inform you.  Thus, next time you go to load the form, it will inform you again.  This gets to be very annoying, and should prompt you to start cleaning out those old, unresolved items (perhaps it’s simply deposits you haven’t confirmed yet; regardless, it’s easy to find out by designating the appropriate display).

We are, quite frankly, proud of how our FundsControl system ties together so many other elements in ServiceDesk, providing such positive security, along with convenience for your funds control.  We hope you enjoy it too.

‍