ServiceDesk 4.5.45 Update 10/23/11

Even when first introduced on the market, ServiceDesk had a lot of awesome features.  There were several particular and significant functions people reasonably expected, however, that did not exist.  When asked about such expected elements, I've candidly referred to them as "holes."  As a general development strategy, we've gone after the hard things, occasionally skipping past an element that seemed less immediately important.  Over time, we've made it back to most such areas, filling in such holes as were initially left behind.  But one in particular has remained, until this release. 

In the inventory control system, we've long had several superb systems for ordering stock replenishment.  We've also had a superb interface for checking in stocking parts as they arrive.  We have not, however, had a mechanism for keeping track of what's on order for restock and waiting for arrival (referring here specifically to stock replenishment, as opposed to special-order where in fact such details have long been very precisely tracked). 

For persons migrating from other systems where they had such an ability, this hole has at first seemed shocking.  At least on initial discovery, they've typically thought the hole would be untenable.  For years, though, I've had the same reply.  Please try the system as is.  If after real use you find this hole is an issue for you, it will then be a priority for me to fill it.  Otherwise, I need to spend my time on projects real-life users are actively clamoring for. 

To be candid, I've wished somebody would later tell me the hole had proven to be untenable, because I've grown tired of confessing to its continued existence.  It did not happen, though, until last week.  A user in Newfoundland called and said for them it's an average of ten days between placing their order for restock and receiving the shipment.  During that time, they need to order restock again -- and, obviously, need to know what's presently pending in that ten-day order queue.  

As had long been promised, I turned my attention immediately to the matter. 

From this release forward, ServiceDesk will automatically keep track of re-stock orders when you create them via the F10 form's items-presently-deficient method (keyboard shortcut is F10→O→D).  It will also automatically check-off items, as prior placed into this new ItemsOnOrderQueue, as you check in parts using the F10 form's receive-items-into-stock method (keyboard shortcut is F10→R).  In fact, while working in these two environments, you won't notice this activity.  It's simply done behind-the-scenes, for you. 

Where you'll see a difference is where you go again to that same order-on-the-basis-of-items-presently-deficient environment, and view items on which you are still deficient, and where an order is presently pending.  In that circumstance, text in the right-third of any applicable line-item will appear in a magenta color, as opposed to the normal black.  This is to alert you to the fact an order is actively pending on that item.  And, if you simply float your mousepointer over the item, a ToolTip will appear that details precisely what order is pending (or, if multiple orders, it will detail the multiples):

There are certainly enhancements we might make in the future, now that we've created this particular structure.  For example, we might make it so you can receive a shipment simply by direct-matching it to the prior order.  For now, though, the above is as far as we've gone.  It meets the minimum need.  

This is one that's likewise been a long time coming, but -- hey -- we got there.

WipAlerts are a totally awesome feature.  If you've not been taking advantage of them, I stoutly, strongly, and with huge emphasis recommend you change that omission post-haste.  Really, they're totally powerful, and if you're at all past the beginning stages of ServiceDesk implementation, you should be using them. 

Regardless, as awesome as WipAlerts are, they've long suffered from a particular limitation in IQ.  It concerns either of two situations:

1.    You have an appointment pending for some date rather far into the future; or

2.    You've ordered one or more parts, and the expected delivery date is rather far in the future. 

In either case, the customer is not really expecting to hear from you for some significant time.  Regardless, it's been the structure of the WipAlerts system to periodically pester you, even while you're waiting for that far-off event.  On the one hand, this is not all bad.  In my service business, we learned that even when we told a customer it would be at least two months before a part would arrive, if we did not call them at least occasionally during the intervening period, they'd conclude we'd neglected them.  WipAlerts are a great tool to help assure that occasional contact.  However, they do not need to remind you as often as otherwise. 

Until now, they've had no IQ to distinguish between that circumstance and others.  With the present release and forward, they'll be smarter. 

Specifically, where either an appointment or expected parts-delivery date are still pending, the WipAlert system will multiply whatever is otherwise the specified grace period, for the category, by a factor of five.  As an example, suppose you've left the grace period as applicable to the "Waiting for Parts" status category at the default value of 3 days.  If so, and if the system finds the anticipated arrival date of any pending special-order order part is still in the future, it will multiply that three 3-day grace period by a factor of five, changing it to 15 days instead.   In consequence, you'll not receive a WipAlert in such such circumstances unless its been 15 days (as opposed to a mere 3) since the date of the most recent entry in the underlying JobRecord's historical narrative. 

To assist you (and, frankly, we here at Rossware too) in remembering what is the structure of this enhanced WipAlert IQ, we have also augmented the ToolTips that show when you float your mousepointer over any JobRecord's status selection.  Instead of merely showing whatever is the applicable grace period for that status, the ToolTips as particularly applicable to the status categories of interest will additionally have some added text to explain this added IQ.  Here's an example:

As with any ToolTip, this one comes up when you float our mousepointer over the underlying object that triggers it (in the above case, the "Waiting for Parts" check category). 

Recently we were asked to add a couple of figures to the "Tech's Revenue" report (keyboard shortcut to get there is F11→T→R.  The new figures are shown (circled) here:

The first-circled section is obvious in meaning.  The second breaks down the tech's average per-day sales in Materials (M) and in Labor (L). 

A database-cleanup routine (for the UnitInfo.mdb file) was added to the regular nightly archive sequence.  It will help keep your UnitInfo database performing in top trim.