ServiceDesk 4.4.71 Update 07/18/10

If you do not know, "CE" stands for Consumer Electronics (these days, mostly big-screen TVs).

You likely do know that, in general, ServiceDesk was born and bred within an appliance service operation -- a fact which (and with apology to the rest of you) gives it something of a bias in that direction.  This is also a factor we are endeavoring to overcome.  We are very determined, in other words, to make ServiceDesk just as perfectly suited for other industries (in particular, HVAC and CE service) as it is for appliance repair. 

Quite a while back, we learned that HVAC servicers wanted some other fields in the UnitInfo form (shortcut access for that form is via Shift-F12) -- fields to keep track of details such as unit fuel type (gas, electric, etc.), flow direction (up, down, sideways), and so on.  To accommodate, we made the UnitInfo form vertically expandable (via a little arrow button at the bottom), and added the desired fields within the expanded space. 

Recently we realized CE servicers need a field to keep track of particular units' Chassis Numbers (considered a model sub number), and the ability to search on that field as well.  To accommodate this, we figured we needed to make the expansion area work in an alternate fashion: to show supplemental fields as needed for an HVAC operation if that was the kind of user, or to show CE-supplemental fields if that was the kind of user (or perhaps no expansion at all if neither user-type was applicable). 

To implement this strategy, ServiceDesk needed a means by which to be informed as to the type of user applicable.  For that reason, in this release we revise the Settings form (Ctrl-F1) to accommodate a new setting:

Depending on which option you pick for the above new setting, the UnitInfo form will be expandable (or not) in an appropriate manner.  If, specifically, you pick "CE," it will be expandable (from this release forward) as follows:

If you are either an HVAC or CE servicer, please be sure to activate that new setting option as needed.   

Way back in '05 (in Ver. 4.1.103), we introduced a mechanism that allows you to speculatively transfer parts, from your in-office inventory and to a tech, for potential use on a particular job.  The notion is you may have items on the shelf, not normally kept on the tech's truck, and during the pre-screening process you may realize that a particular job will very likely need such a part -- making it sensible to pull it from the shelf and send the tech out with it.  

Over time it's become evident that, though very beneficial, there were elements in this system we might have designed better.  In particular, the implementation sequence invited you to transfer the part to a tech, at the same time you were tagging it (for potential/speculative use) on a particular job.  This was based on the notion you'd likely know, at the time, which tech would be doing the job.  As it turns out, however, this assumption was very flawed. 

In reaction to the above, some of our more savvy users have taken to performing a little trick.  When in the process and invited to pick a "Transfer To" target (i.e., which tech's inventory location the item is being moved to, from the office, for speculative use on the job), they've picked the office itself (i.e., "OF").  This results in no net transfer of location, but nevertheless allows the other part of the process (tagging the part to the job) to nevertheless take hold.  It's a great expedient, but is also one that the involved language and processes would not normally lead a person to consider.  This is so true that, even here at Rossware (and when consulted on the conundrum which the expedient solves) we have sometimes failed to remember it, and have occasionally instead been misled -- ourselves -- into thinking the structure allowed no such solution. 

Because of the above, this release makes some changes. 

 First, we have changed the caption as found on the button, within the JobsCurrent (F7) form, that initiates the involved process.  The old caption ("Antcptry Prts Trnsfr") was misleading for a process where, in immediate consequence at least, no true "transfer" was necessarily involved.  Now the button instead reads "Tag Part for Visit" -- a phrase that much more accurately suggests that your purpose, when clicking on the button, is (necessarily) to tag a part in such manner as to facilitate its presence with the tech -- with any tech -- when he next goes to the site on that job. 

OldNew

Second, as title for the overall set of processes, we are changing from the term "Anticipatory Parts Transfer" (or sometimes "Speculative Parts Transfer") to the more accurately descriptive: "Pre-Screened Parts Tagging" (as per title/header for this WorkDiary entry). 

Third, when you actually click on the involved button, there is a new query, as follows:

As you can see, you are now invited to choose, explicitly, whether you want presently to Tag-Only, or Tag-plus-Transfer.  This makes the alternate potentials much more apparent. 

Fourth, if you choose the Tag-Only option, the system will (logically) skip what was otherwise a following window in which your were formerly asked to pick the "Transfer-To" location. 

Fifth (and perhaps most importantly), there is a newly-augmented process as now connected to the system.  Assuming that in fact you've "Tagged-Only" while pre-screening, this process recognizes a subsequent need.  Specifically, sometime prior to the tech heading out on any particular day's set of jobs, you'll likely be printing a PartsPickList, and using it as the basis to actually pull tagged items from the office, placing them into an applicable tech's pickup bin.  Once this is done, it's imperative to inform the system of this physical transfer event (i.e., so it can properly tally where the item is now at -- referring, specifically, to those instances where you did not claim a transfer initially). 

Ultimately, what we really need to do to -- to optimally accommodate this purpose -- is to have an interface that will likely be called (at least something like) the "PartsPickList-Reconcile" form.  The vision is for this form to provide a one-stop place for a parts-puller to assure he's assembled all the parts a tech should be taking with him for his day of jobs, whether as special-ordered, speculative-tagged, or simply needing restock to inventory (and, of course, to seamlessly document the movements from one location to another).  It may be that the current Parts-Crossover form can be optimally adapted for this purpose, rather than creating a new interface in its entirety. 

Regardless, in an anxiousness to "deliver" on the current project, we have for now refrained from creating an entirely new interface.  Instead, we've added enhanced functionality to a pre-existing function. 

Specifically, in the InventoryControl form (F10) there has long been a function to facilitate transferring parts to a tech for the purpose of restock (in particular, using as basis examination of items on which he's fallen below minimums).  It's a very smooth and well-developed process.  Our new function allows you, simply, to use this same set of mechanisms, but in a context that's augmented so that the system lists not only regular inventory items as needed, but also any items as tagged for jobs the technician will be doing for the day in question (and which have not already been marked as transferred to him).  Thus, it's a solution that allows you to (please pardon the cliche) "kill two birds with one stone" (accommodate ordinary re-stock, plus appropriately move items speculatively tagged). 

To invoke this augmented process, you'll notice that when you choose to print a PartsPickList from the DispatchMap, there is a new option box in the resulting Printer-Selection form:

If you print with that new option box checked, you'll find that, besides printing the traditional list, the system takes you directly into the InventoryControl form's newly/specially augmented Transfer-for-Restock mode.  In this mode, it will list not only normally-needed restock items (as it always has), but also ones that need moved to him because they've been tagged to a job that is on his schedule for the applicable day.  Such items will be distinguished, from normal restock items, via the text being in red. 

From that display you can use traditional/normal means to transfer all items, both normal restock and job-tagged items, to the tech as needed. 

Besides those particulars above-described, a few other elements of language and interface have likewise been appropriately changed.  Even so, please note we have not entirely dropped the "speculative transfer" language.  This is because, even if you do not transfer to a tech while tagging a part, you very likely DO transfer the evening prior (or morning of) his dispatch on the job.  For such particular operations, the older language is retained. 

BTW, we realize there's a downside in changing terminology.  Please be assured, we resist doing so except when there's a large purpose to be served.  We believe this instance strongly qualifies. 

Until now, there's been no distinction by the system when you check-in the final part, as ordered on any ticket -- as to whether it was a POS-context (versus more standard repair context) order.  It turns out the distinction is important.  Among other things, if in repair context it's natural to assume that, once all parts are in, the underlying JobRecord should be placed into "WorkingToSchedule" status.  Not so if it's a POS-context order, where there's no return/repair appointment needing to be scheduled.  Similarly, any dialog (such as in an auto-generated email as designed to inform the customer of part arrival) needs to be appropriately different, if it's a POS-context order. 

Prior to improvements as made in this release, the system acted as though every order was a repair-context order.  But now, with improvements as presently made, the system will distinguish the two contexts, and handle the POS variety much more adroitly.  (For the distinction, incidentally, the system looks simply to the underlying JobRecord's narrative history for the phrase "(POS context)"; if that's found, it deduces accordingly.)