ServiceDesk 4.7.49 Update 07/12/13

This is an item that's been slow in coming -- in the particular sense that a couple of users have been requesting it for a very long time.  To those users, I am sorry it took so long. 

Anyhow, it's now here. 

In any of the FinishedForm formats (Alt-F4), a tiny new button will be visible in the box that totals the parts boxes.  From the POS form itself, for example:

If you wish to add a discount to your ticket, click on the button.  It will query as to the desired discount percent (defaults the first time at ".15" for a 15 percent discount, and will default all subsequent times to whatever you picked the prior time).  In response, the system will on the bottom parts-listing line insert a discount line item, describing the discount and inserting its amount:

 If you edit other parts-listing line items after this insertion, the insertion will remain unaffected.  This means, if you want to update the insertion, you'll need to click on the Discount button once again (essentially, it will re-calculate and re-insert the discount, based on whatever is now the otherwise totaled amount of parts-item listings).  This item can also be removed (just as can any other parts-item listing) by right-clicking on it. 

Recently a user pointed out that, where ServiceDesk reads in a JobRecord's history to assemble a description of the tech's work and insert it into a FinishedForm (particularly and especially into the NARDA, as needed for warranty claims), it was sometimes including text that really was not needed (and in some instances very much not wanted).  Especially not wanted were recitations of money collected. 

Indeed, we've learned significant resources are in some cases being expended by humans, to manually edit what it's fully possible, instead, to code for machine editing. 

This release provides such improved machine editing.  Any money-collected recitations, at the least, you should now find are auto-removed for you.  If you find there are other elements you would similarly like to see better machine-edited, please let us know. 

Two releases back (see notes accompanying Rel. 4.7.47), we added a file-export option for PartsPick data as assembled via the PartsPick (Shift-Ctrl/F8) form.   This was based on a direct client request. 

Turns out, it was not the context where the export was truly wanted.  It was wanted, instead, in the much-older context for assembling PartsPick data, which is one of the "Send-To-Tech" options available from within the DispatchMap (F5, to get this option in general, right-click on a tech's name, at the heading of his list of jobs there).  Grudgingly, we now offer the option in this context too (both efforts involved a lot of coding work). 

More specifically, it's offered when you use the alternate "Send-To-Tech" method -- the one as provided to invoke a "Send-To-Tech" option, but for all techs (i.e., as opposed to just one, whose name you otherwise clicked on).  This method is invoked from the DispatchMap via the shortcut-sequence Alt-P-->D-->P.  At such point the PrinterSelect dialog comes up, and you simply need to choose for the output to go to file, rather than the printer:

If you're curious, a major difference between the two PartsPick contexts is the older one (from the DispatchMap) was designed to simply to provide a list of what needs moved to the tech.  It provides no means to simultaneously tell the system what movements you are (or are not) making.  It also does not indicate items that need to be received back from the tech.  Overall, the much-newer PartsPick form is far more powerful -- though each may have their particular place, depending on your mode of operation. 

RSS is our acronym for Rossware Server Solutions.  It's the option where you can pay us to host a server for you, which makes it easy for each of your office personnel to log into ServiceDesk from any computer at any location.  It's still a reasonably new offering, and we are still learning to tweak things in its regard.  Until now, we have not tweaked  elements directly in ServiceDesk.  Recently, we realized a need. 

First (and as you may know), if you're not actively running the SD-Backup program, ServiceDesk makes rather a pest of itself in seeking to persuade you it ought to be done.  This, and all the pester elements we engineer, are done for your ultimate benefit -- based  on what we've seen users suffer, by not doing things they ought to. 

Regardless, RSS users do not need to be running SD-Backup.  It's because the RSS system itself provides its own very robust backup elements, so others are not needed.  Thus, such pestering in the RSS context made no sense.  This release fixes that. 

Another little change is, when RSS clients now connect for assistance, we'll be direct-alerted to the fact you're an RSS user.  This will, in many cases, help to better direct our efforts (there have been cases, if you wish to know, where we're helping an RSS client with some issue in SD; we conclude the problem is "in the environment," and tell the user they need to take it up with their IT provider; oops, it's us). 

This is one that will likely interest only a very few, but if you have the need, you'll like it.  If you use the Departmentalization feature, and if you'd like the underlying-assigned department to be listed on parts labels, it will now happen if you pick the "Jumbo" style Dymo label. 

Over the years, a great deal of sophistication had been added into SBDL (stands for SB-DispatchLink; it's our integration utility for ServiceBench) -- in particular for how it figures uploading of availability. 

Among such elements is a function slightly akin to "flowing-pipes," but it happens without any setup by the user, and is between day-segments instead of between zones. 

Example:  Suppose that for a given zone you have allotted 5 jobs for morning, 5 for afternoon, and 5 for all-day.  On a particular day, you've scheduled 9 for morning, 8 for the afternoon, and zero for all-day.  Thus, you have 17 total total bookings against 15 allocations.  Obviously, you're overbooked.  SBDL has long been smart enough (just as is the "All" view from within the SD's ZonePlanner form) to see such overbooking, and to refrain from offering availability for any segment (even though, essentially, you have zero all-days booked against allocation of five slots, meaning, looking at that segment alone, it might appear you should have five slots open there).  Essentially, where one day-segment area is overbooked, SBDL "flows" that "overbookingness" (nice word, eh?) into another segment area.  This is but an example.  We've added a number of similarly-sensible IQ elements. 

Until this now-announced release of SPDL (stands for SP-Dispatchlink; it's our SBDL-equivalent utility for ServicePower), the latter did not possess this and a few similar elements of enhanced IQ.  In other words, SPDL would, for the described example, look simply at the fact you've allocated five for all-day, you have zero scheduled for all-day, and would therefore offer five all-days as currently open).

Why was such added IQ not formerly there? 

These added IQ elements were added into SBDL gradually over time, as (from experience) we realized various needs.  Until recently, nothing jogged our realization that the same needed to be done in SPDL.  Just about as soon as that realization came (it was last week), we brought it up to par.

Why was there formerly nothing to jog our realization?

Until recently, the online availability review, at ServicePower, was knowingly erroneous, so far as its ability to accurately reflect true availability values uploaded.  Because of this, there was no easy/direct way for users to verify if values as uploaded were a good reflection of what they wanted uploaded, and to inform us if otherwise. 

Regardless of explanation, if you are using SPDL, please update it at once.  You'll have better availability-upload results.