This is a big one. 

It addresses a need that has long been on Rossware's agenda, and which for too long has been left un-served. 

The need is as follows: 

You have several instances of a particular part in inventory.  Perhaps there is one on each of your trucks, and perhaps there are a few in your office storeroom.  Regardless, in some cases you will have paid different prices for different instances of this part.  Occasionally, the difference may be large, especially where some instances were purchased prior to a price increase, and some were purchased after. 

So, the tech uses a part, indicates his use in the SD-Mobile PVR, and, in reaction, SD-MobileLink pulls it from the tech's inventory.  But, what if it was on a warranty job, and what if the instance ServiceDesk reckons was in the tech's inventory happened to be one that you paid a small price for?  That's not good, because the following warranty-credit will be based on that small price.  You'd have been better off if the system reckoned it was the costliest instance (and from your overall inventory, as opposed to just from the tech's inventory) that was used, regardless of where that instance actually resides.  This is true, particularly, because it would save the cheaper instance for application on a COD job, where you could then effectively get a much larger margin from the sale. 

The opposite arises where the tech is on a COD job, and indicates having used a part from inventory.  Now, you are better off if the system will exercise such intelligence as to reckon it was the cheapest instance from your overall inventory that was used, regardless of actual location. 

Until now, the system has never exercised this kind of IQ. 

It does now, but (and of course) it also does so with some finesse. 

Finesse is needed, for -- obviously -- you'd not want the system to find that, though Bob used a part from his inventory, a better cost-optimized instance was found in Bill's truck, therefore it simply does a normal pull from Bill's.  This would be bad, for now the system would reckon Bill had fewer than he actually did, and that Bob had more.  So, in essence, the system needs to first do a swap, between Bob and Bill's indicated instances of the part, of just the acquisition information (vendor from whom acquired, acquisition date, acquisition invoice number and acquisition cost), then do a normal pull from the actual indicated location.  Effectively, this makes the pull into a cost-optimized one, while nevertheless making the physically-indicated movement appropriate to the true location. 

The logic and programming rules on this are simple. 

When going to pull an inventory item (i.e., remove it from inventory on the basis of indicated use), SD-MobileLink now looks to see if the underlying/paying client/customer is QET-designated as "OEM-Warranty" or with a "Markup Strategy" that directs toward a fixed-percent markup from cost.  If yes, the system biases toward seeking the highest-cost instance of the part.  If no, it biases toward seeking the lowest-cost instance. 

Based on this bias, the system will, for each indicated use, look to see if there is a better cost-optimized instance of the part, as opposed to the particular one (or perhaps more than one) as indicated within the tech's own inventory.  More particularly, it will look to find whatever instance within your entire inventory is best cost-optimized for the circumstance.  Assuming it finds a better-cost-optimized instance than what would have otherwise been pulled from the tech's own inventory, it does a behind-the-scenes swap of that acquisition information, before then pulling from the tech's inventory. 

Aside from updating to current, there is nothing you must think about or do in order to make the above occur.  It will simply happen on your behalf, no fuss or muss required.  

When SD-Mobile was first launched, the bottom-right section of a Mobile ticket had boxes labeled like this, and with no other option:

It was not long before a number of users wanted the option for the "Other"-labeled box to be explicitly labeled instead as for a Service Call, so we added this option in SD-MobileLink:

. . . and, in consequence if you have that box checked, that same section in the Mobile ticket changes to look like this:

(In addition to the label change, ServiceDesk also does something different.  Specifically, when going from the Mobile FinishedForm to auto-populate a SalesJournal entry, it treats any amount that's in this box as an actual service call (i.e., populating to that particular field in the auto-populate), whereas otherwise it would combine any "Other" amount with Labor when doing that auto-populate.)

The ability to change that one label (and only to a particular other label) was, obviously, a tiny allowance for customization.  Recently a user pled for more.  So, we've provided it.

Specifically, you can change all five labels to whatever you'd like them to be.

To do so, open any text editor (MS NotePad is a good one) and type each of the five labels you want, as separate lines of text.  Make sure you have precisely five lines.  Save to the \sd\netdata folder on your server, with this precise filename:

MyCstmBxTtlsForMblTckt.txt

(the name is intended as abbreviation from "My-Custom-Box-Titles-For-Mobile-Ticket").

When you have done the above, SD-MobileLink will see the file, and know to use your text as labels for the corresponding ticket boxes.  It will also upload the file-information to each of your tech's instances of SD-Mobile itself, so those interfaces will also know to use your substituted text.

A few matters to note:

1. If you are setup to use separated GST and PST in Canada, those labels will continue to prevail (and for the two separated boxes) over the single box otherwise normally-labeled as Sales Tax (in other words, whatever is the text in the fourth line of your new file, it will be ignored, because you're getting two boxes that are labeled GST and PST instead).
2. The differentiated treatment when ServiceDesk auto-populates a SalesJournal entry will continue on basis of whether you have selected, within SD-MobileLink, the option to have the "Other" box treated as "S.Call" (though your customized labeling will prevail so far as labeling itself is concerned).
3. To be effective, this change requires updates of both SD-MobileLink in the office and of SD-Mobile by each tech.
4. Your techs in Mobile will not see the difference until the day after you've added the file in your office.