ServiceDesk 4.7.67 Update 12/05/13

Sometimes I receive a nasty reward for having created an awesome new feature.  It is someone responding with: "Oh yeah, we love that, but now you must make an option for us to do it differently." 

It happened with the new feature described just two items below.  In creating that feature, we assumed you need to be receiving a part at least the day prior to appointment date.  Turns out this is not true for some operations.  In particular, there are some that have their parts vendor managing parts for them (indeed, filing each tech's tote before a messenger delivers to the tech's residence, on a daily basis).  The ETA for any part that's put into the F8 screen is the date they expect the vendor to be populating the tech's tote with that part.  So, for this situation, it's perfectly fine if the date-of-arrival on the part is the same as the appointment date. 

Given the above, we now have a new Settings option in the F8-form's Cheat-Sheet (right-click in any non-operative space of the form to get its Cheat-Sheet), as follows:

picking this Cheat-Sheet optionproduces this settings dialog

The result of this option setting is, we think, self-explanatory.  However, if not clear, it's this.  With the second setting (which is default) you'll be warned if an appointment is the same date as ETA on the part, or sooner.  With the first setting, you will only be warned if appointment is sooner than the part's ETA. 

If you use SD-Dealer for managing serialized inventory (and SD's POS system to conduct sales of such inventory), you may have lamented the fact that, when linking from there to make a sales journal entry, the system did not separate your serialized-inventory sales into the "Merchandise" category of sales.  Instead, it would place the value into the "Parts" category, along with any other line items from the ticket.  That is now corrected (turns out it had formerly been coded to appropriately separate out merchandise, but without us realizing it that element of functionality was broken when we upgraded another matter, quite a long while back). 

When we designed the ticket format for use in SD-Mobile, we strived for a layout that would be useable across a very broad range of charge-structure preferences.  This was needed because, for the Mobile context, it is far less practical to provide a structure that allows for infinite user customization of the ticket, such as we do within ServiceDesk itself.   One element, in seeking to allow such breadth of use, is the ticket was not designed with inclusion of a box labeled "Service Call."  Instead, we made a box labeled "Labor" and a box labeled "Other."  We figured this would allow a reasonable fit for both those companies that refrain from charging a separate "Service-Call"-labeled fee, and for those that do (where it can simply be placed in the "Other" field. 

By and by, however, we had requests from folks who wondered if we could program an option where, with a simple settings change, that "Other" field could have it's label changed to say "S. Call" instead.   We assented and created the option.  It's in the MobileLink program, as shown here:

But, we only programmed to make the option effective within SD-Mobile itself.  Nothing was changed within ServiceDesk.  In consequence, SD's FinishedForm-context representation of the Mobile ticket continued to show a "Labor" field and an "Other" field, even if you checked the option above shown. 

That is changed in this release (i.e., now SD's FinishedForm-context representation of the Mobile ticket will comply with the option you set above).  There is another element of change that is perhaps even more important. 

When you link from the FinishedForm context to an auto-filled sales journal entry, there must be a translation from which boxes are filed-in on the particular FinishedForm you're linking from, to which fields are populated in the sales journal entry.  For going from the Mobile ticket, we've had it programmed so that both "Labor" and "Other" are summed together -- into the Labor category of the sales journal entry line.  The reason is because we did not know whether "Other" was used as a service call, or for something else.   

However, now that we are bringing into the Mobile/FinishedForm context information about whether that "Other" field is being used, explicitly, as ServiceCall field, we can so handle it.  Specifically, if you've picked that option, the system will now translate that box into the sales journal entry's ServiceCall field, just as you'd expect.