ServiceDesk 4.7.8 Update 11/29/12

Tanner Andrews (Andy's Appliance Repair, Lincoln, NE) works very hard to assure he's stocking each of his trucks in the most optimum manner possible.  His was among the voices that drove us to create our "Usage Rates" Report (Ctrl-F8-->U) way back in October of '08.  Recently, he wanted better definition than this report has prior provided.  Specifically, we wanted to easily see not merely the frequency of each part's usage for his operation as a whole: he wanted to easily see usage for each location (so as to better define which locations should sensibly be stocking which parts). 

It made good sense, so we have delivered. 

If you run the main report, the portion that displays onscreen will appear just the same as before.  But if, after the main report is displayed, you click on this button over toward the right:

the resulting export/spreadsheet will have several new fields, not prior provided.  Specifically, it will have as many more columns as you have different inventory locations.  Each such new column will indicate, for each part-number/line-item listing, the quantity as used by that respective location. 

The concept of including these columns may seem pretty obvious and basic (to such an extent to make it seem embarrassing they were not already there).  Sometimes it takes a really smart guy like Tanner to realize where something so basic has been missed.  Thank you Tanner. 

New "Print" option for same content as prior available in Large/Detailed Email of Dispatches:

Based on the fact we so strongly consider SD-Mobile as the mode via which modern service offices should be dispatching jobs, we are less than anxious to keep pouring resources into updating and improving older and more legacy methods.  However, we're not always good at saying no. 

There are a plethora of dispatch methods that arise when, from within the DispatchMap, you click on a tech's name at the top of his list of jobs.  Among these is one designed to send the tech his entire roster (including rather exhaustive associated details) in a single/large email.  We purposely optimized text within this email for -- well -- the email context.  Back to that list of options, there is also one designed to locally-print the tech's roster, similarly with exhaustive detail (but here optimized for printing). 

Lo and behold, if there weren't some users who preferred the email formulation of contents, but wanted it in a printout, rather than an email.  As we said, we're sometimes not good at saying no. 

So, right on the face of the dispatch-methods menu, you may now see subtle changes in wording, to indicate our newly enhanced flexibility:

OldNew

From this point forward, when you click on the beloved "E" option, instead of simply being presented opportunity to email, you'll instead get the Printer-Select dialog box, configured to allow specification of email or printing:

It should at first default for email, which means if you want printing instead you have to check that as the alternate function. 

When, just two weeks ago (see entry accompanying Rel. 4.7.5), we did a complete rebuild of machinery that constructs a mailing list for you (making it dramatically more efficient), we felt very good about it.  Alas, no good deed goes unpunished.  It turns out the old method had one distinct virtue that did not survive the new improvement: it allowed you to directly select how far back the system would look, among completed JobRecords, for names to insert to the list. 

Our old and inefficient method was conducive to that kind of selection.  The new method is not.  Given this, we've added a dialog, when you choose to make a MailingList (Alt-F3-->M), as follows:

So, you can now revert back to the old method, if wanted for its one virtue.