ServiceDesk 4.5.18 Update 05/06/11

Not far back (see Ver. 4.3.62 entry from 4/18/10) we vastly improved our method for designating those particular jobs that involve in-shop (as opposed to in-field) work.  Since then, we've made occasional additions to the operations where ServiceDesk appropriately distinguishes between ShopJobs versus not.  This is a related such improvement. 

Specifically, someone pointed out that you should be able to readily distinguish, within the DispatchMap, between references to appointments that involve in-shop work, versus those that do not.  And, if you're wondering, yes, many operations do schedule in-shop work.  For those operations that lack a dedicated, in-shop technician, it's often found that scheduling the work is the only way to get it done. 

Based on this improvement, you'll now see ready visual, within-DispatchMap distinctions, as per above. 

We heard from a particular client they'd just lost a a thousand bucks based on having ordered a wrong part (someone looked up the part number wrong, and the item was not returnable) from Viking. 

Oooouuuuucccchhh!  

Understandably, this client wanted the ability to determine precisely who had actually done the lookup on the part number, and who may have edited it thereafter (if, in fact, anyone had).  As all seasoned users know, a wide variety of events are automatically documented in the narrative history as applicable to any underlying JobRecord.  The kind of event as we're discussing here could, in theory, also be placed there, but as a matter of general strategy we want maintain that narrative in a form that reads well (and easily) as a broad overview of major events, and without so much excessive detail as to defeat that as its purpose.  Thus, we needed such historical documentation elsewhere. 

Enter the "Log" file.  From this release forward, ServiceDesk will write to a file (called PartsProcessWorkLog.txt and located in the \sd\netdata folder on your server) each time any user creates or edits a part number in the PartsProcess system.  Each entry will indicate the operator involved, date and time of the event, and precisely what the operator did.  At the conclusion of each day, entries in this file will be moved to a more permanent file (PartsProcessWorkLog_Archv.txt, also located in the same \sd\netdata folder on your server). 

Based on the above, if you need to find out after the fact who specifically is responsible for having provided (or changed) particular part numbers that were involved in the PartsProcess system, you should be able to easily determine the answer by looking in one of the above-described files (the first one if you're looking for actions that occurred in the current day, the second if looking for actions more in the past). 

Having created the machinery for this particular log, we invite you to let us know of operational areas where you think there'd be a significant reward for creating similar logs.  The way we've structured the machinery, there is almost zero overhead involved, as cost in such logging efforts.