ServiceDesk 4.4.66 Update 05/06/10

We've been informed that, increasingly, servicers are running into situations where different manufacturers happen to end up using precisely the same part numbers as one another -- but of course each for their own (and different) parts.  The underlying structure of SD's inventory system is one that uses the part number as a controlling entity, and without regard to applicable make.  This means part number duplication, between manufacturers, has been a potential issue. 

This release introduces a solution, though perhaps not quite so perfect as user might have otherwise desired.  It's sort of a work-around. 

What you need to do, for any part where you're stocking different items but of the same part number for different manufacturers, is append one or both instances with an asterisk then a single letter that indicates the applicable manufacturer. 

For example, suppose both Toshiba and Sony have parts bearing part number 123456, and you want to stock each.  For the one from Sony, make your within-the-MasterPartsPlan number "123456*S".  For the one from Toshiba, make it "123456*T". 

The above is, of course, an expedient you could have been using all along, but with one downside.  When ServiceDesk fills-in the on-screen Narda for a warranty claim, it uses your part number as provided.  Sony won't likely provide credit on claimed use of part number "123456*S".  That's where the improvement (as present in this release) comes in. 

Specifically, with the enhancement as introduced with this release, when ServiceDesk fills in the on-screen Narda, it will look for part numbers with a "*X" suffix on the end (where "X" is any possible letter).  For any found, it will delete the suffix -- thereby smoothing the way to a successful claim on such parts. 

There have been prior references in this blog to "The Law of Unintended Consequences," and it is, sadly, a merciless (if sometimes slow-to-present-itself) taskmaster.  Slightly less than five years ago (see entry for Rel. 4.1.74), I introduced the ability to make interim sales entries:  entries to the sales journal for a portion of the sale as already earned, and prior to a completing entry, for the balance, which actually closes out the job.  Turns out there as a down side to using this practice.  If the interim entries were for billed work, and if you later sent the client a statement for outstanding A/Rs which involved such multiple entries, it was possible for the statement to have multiple line items for what was really a single job.  This could potentially be confusing to the customer, and cause unwelcome objection.  On top of that, if you happened to be creating a new job for such a customer, there's that little feature that offers to add a note about presently unpaid A/Rs.  That note could end up claiming there were multiple A/Rs, even if all involved a single job (and again result in confusion with the customer). 

This release remedies both issues.  In either of the contexts described, ServiceDesk will combine the multiple A/Rs (as under a single ticket number) and present them as though one. 

There are, of course, "two" party-info sections in SD's general Callsheet/JobRecord structure.  The second is only used (at least for actual party info) in the event a job actually involves two parties (one for billing, and the second for go-to).  Of course, when not used for official party-info purposes, the second section is sometimes used (and at least by some folks) as extra space for added notes.  This particular fact creates a quandary for the system when it updates the CstmrDbase Index set each night.  If extraneous notes are in the second party-info section, we do not want to have such notes indexed as though they consist of a party's name, address and telephone number, etc.

The solution has been that the Index-updating machinery is programmed to ignore text within the second party-info section -- unless if finds (in the address box) a set of brackets, as involved in the grid coordinate that's inevitably put in if you're sending a tech to a location as involved in that section (bear in mind, while it's easy for a human to look at text and distinguish between text that describes a name, address and telephone numbers, computers are much less capable of so simple a task). 

The above works fine, except where you're doing a bill-to-another-party Shop Job (typically, involving a TPA payer).  In that case, you need the second party-info section to describe the owner of the merchandise you're repairing, but you do not need brackets in the address line, because there's no need for grid coordinates on an address you're not sending a tech to.  For that particular situation, our trusty old strategy fails. 

In solution, this release introduces a change.  From here on out, the system looks to see if the first-section party info describes a HighVolumeClient.  If so, it will index text in the second section, even if no brackets are found there.