ServiceDesk 4.6.36 Update 09/23/12

Some two-and-a-half years ago (see entry accompanying Rel. 4.4.7) we introduced a new report, designed to itemize (categorized by collection source) each item of money as ostensibly collected, throughout your system, for any given date or date range.  This was to provide a direct means by which to easily reconcile the money that's actually turned in by each source, for such period, with what easily reconcile the money that's actually turned in by each source, for such period, with what should have been  turned in.  It's been a popular report, but recently we were asked for something different. 

For context of consideration here, we have always had a method whereby ServiceDesk is primed to give you notice if any item of money -- as supposedly collected -- does not ultimately show up for processing.  The original (and still in-place) method is rather on the back-end.  It assumes you've used some means of direct-checking as tickets are turned in, to assure appropriate matching monies are there (such as, for example, that new report we added two-and-a-half years ago).  It then watches after the fact.  Essentially, PVRs (and similar processes) create entries in the FundsJournal regarding each money item supposedly received.  When deposited (or similarly processed), these items are "checked off."  If any items persist without being checked off, they bring visible notice to themselves, by virtue of their growing and obvious datedness.  If still not checked off, they ultimately trigger a direct complaint, that positively forces notice.  This is our back-end assurance.  Your own vigilance is the front-end. 

In a nutshell, our two-and-a-half-year-ago-added report provides a very nicely augmented means to assist you in exercising due diligence at the front end.  Essentially, it gives you a front-end check-off list.  On a daily basis, you can print the report, and easily verify that each item of indicated money indeed shows up. 

Our new report gives you a middle check.  Suppose an item gets by you at the just-described front end.  Maybe you did the front-end check, noticed an item missing, intended to follow up, but then got distracted by other matters, and forgot.  Or, perhaps you have techs that turn in monies at such disparate times as to make that front-end check (at least via a single report) not very practical.  Suppose any of the above, and you don't want to wait for our traditional back-end method to give you notice of items that did not show up.  Again, we're talking a middle check. 

Our new report is designed, simply, to list money items not yet checked-off as deposited.  More specifically, lists them with the same "source""categorizations as the traditional front-end report (i.e., a section for each tech, one for POS, one for monies received in payment on A/as the traditional front-end report (i.e., a section for each tech, one for POS, one for monies received in payment on A/Rs, etc.).  The obvious underlying logic is that if an item has not been checked-off as deposited, there is not yet verification (via such means) you have indeed collected if from the source involved. 

Navigation to this new report is simple.  Our report from two-and-a-years ago has been accessed, directly, via this item in the FundsControl (F9) form:

Now, if you pick that same option, you get a choice between that longstanding (front-level) report and the new (middle-level) one as now offered:

The second of the above-highlighted choices will give you the new report.   

This report involves an addition to the InventoryControl (F10) form.  Before discussing the report itself, we'll first disclose we did at little rearranging in this form's main functions menu.  Here is a comparison:

OldNew

As you can see, aside from the fact a new item is added (the real subject of this entry), there is also some re-sequencing of items.  On adding that new item, we realized the prior sequencing of functions had been less logical than it should have been.  So, we worked on that logic, and added a little line divider to separate functions into two logical groups. 

Now for our real topic.  Do you see which item, above, is the new one?  Here is some help:

This report was long requested by Bob at GRA-NEVA Appliance Service.  He calls it a "Receiving Report."  The idea is to provide an easy means to see precisely what was ostensibly received on a given invoice from a given vendor.  It allows an easy means to verify what was entered as received corresponds with what the vendor has on his invoice.  When you run the report, it will initially display on-screen.  However, the form's PrintList button will appear, and you can just click on it if wanting to print.