ServiceDesk 4.8.113 Update 09/03/19

[Special Note: Both entries in this date's posting involve matters that are quite esoteric. In other words, unless you happen to be involved with the special and unusual need that they address, the matters will not at all concern you. Stated otherwise, it's possible these are two entries that you do not want to bother with reading.]

If you expand your company's territory definition and then, to fit your expanded definition, we rebuild for you your company's set of custom ServiceDesk files (e.g., DispatchMap and StreetList), the work may simultaneously entail a change in the underlying coordinate system. If so, your existing grid coordinates (within JobRecords and appointments) will no longer be accurate.

Until now, this has meant that, after such a rebuild, there was need for a human to manually go through each pending JobRecord and update its grid reference (along with any attached pending appointment) to the new reference system.

Several months back, we added a feature to make this easier.

Now we've added feature that all but fully automates it:

The "all but fully" expression was included above because there may be some instances where the automation fails to determine what grid reference should be auto-inserted for you. For this reason, in instances where the automation succeeds, the expression "*****UPDATED GRID COORDINATE*****" will be added at the bottom of the applicable JobRecord's narrative history. Thus, after that process completes, a user should quickly review each pending JobRecord to assure this expression has been added. If it has not been, then the user should use the semi-automated method (as again described here).

Hopefully, this never happens to you.

Usually it happens when a ServiceDesk user is new. You have been using ServiceDesk elements that cause creation of accounts receivable records (A/Rs), but have not yet been using methods to indicate when payments are received on those A/Rs. In consequence, a bunch of A/Rs have accumulated which are in fact paid, but (since it's not been told) the system does yet not know it, so those A/Rs are not going away.

If there are many hundreds of these, it would be too laborious to go through each and correct manually. So (both in this arena and in many others), there has long been provision for what we call a "wholesale checkoff" -- an operation you may invoke where the system goes through and programmatically puts items to bed for you. This allows you to get a relatively fresh start within the involved area of operation.

In the A/R arena, another possibility is that you're not a new user, but have had someone responsible for managing A/Rs, and discover to your horror this person has not been diligently doing the work. Maybe you find there are now thousands of old A/Rs, dating back pretty far in time. A large quantity are so old that, unless particular amounts are large enough to justify an extraordinary effort, it's likely not practical to even try to collect (or to determine if you really were paid but the indicative process was never performed).

We hope none of you will ever let this happen, but we know for some of you sometimes it does.

The present enhancement is designed to help, in particular, with this latter situation. Rather than asking you simply to specify a threshold "older-than-date" for which items will be included in the wholesale checkoff, the enhancement allows you to additionally specify a "balance-less-than" threshold, and it gives you a preview summary of how many (and what is the total dollar volume) of what will be checked off, if you proceed with such parameters as you have tentatively specified.

Because they are considered to be extraordinary operations, we purposely do not publish the otherwise hidden methods by which to access each of the wholesale checkoffs. If you need one, please contact our support staff, and they will provide specific direction.