ServiceDesk 4.8.0 Update 08/15/16

We owe this one to a new client in Canada (Michael Moncada of Northern Electronic & Appliance Services, Inc.).  He explained that he has many contracts with third-parties that specify varying mileage rate schemes, and, absent any method to automate accurate insertion of the correctly-applicable amount in each instance, he would likely end up failing to claim for significant amounts of otherwise collectible sums. 

We would not want that to happen.

If with this update you go to your QuickCommonEntries form (Shift-F1) and choose to edit for any entry, you'll see  some new boxes:

The obvious concept here is, if you have any QCE client in regard to whom you have an agreed-upon mileage rate, you should use these two new boxes to put in the non-surcharged unit-radius and the rate-per-unit that applies beyond that radius (I use the expression "unit" because it is kilometers that will apply for Canadians, miles for the rest of us). 

Equipped with this new information, something new and wonderful will happen anytime you import new information into an on-screen Narda.  The system will see the mileage-rate structure you've setup for the underlying client.  It will grab the address for the underlying service location and it will grab the address for your service office.  It will then make a behind-the-scenes call to a Google API that will rapidly return a driving-distance figure.  Based on this driving-distance figure (and your underlying values), the system will look to see if the Google-indicated driving distance exceeds the indicated radius.  If so, it will insert to your on-screen Narda like this:

For claims to most entities, we believe this is exactly the fill-in you will need.  However, we know that some of the underlying third-parties use the applicable fields differently (i.e., one might expect the mileage-fee to be in one box, while one might expect it to be in another).  If you encounter a situation where these insertions need to be configured differently for a particular entity, please let us know and we will alter accordingly. 

We do need to provide a little caveat in regard to this release.  You might notice that with this release the versioning series has gone from 4.7.x to 4.8.x.  We reserve such series changes for instances where there is a significant structural change in one or more underlying files.  In this case, to accommodate the two added boxes, we had to alter the structure of the file that contains your QuickCommonEntries data.  On first use, the system will automatically build a new QceFile in the new structure (the new filename will be QceFile.4P8 as opposed to the old QceFile.4P3).   Each other instance of ServiceDesk will be prompted to close and re-open in updated mode, so as to use the new file.  The caveat is this: each of the utilities that also use your QceFile (e.g., SD-MobileLink, SB-DispatchLink, SP-DispatchLink, etc.) will still be using the old file, until you update each to its respective latest release (which, naturally, will cause them to likewise use the new file).  What this means, bottom-line, is older copies of those utilities will not see any post-4.8-series changes you make in your QCE data, until and unless they are updated to their own post-change versions. 

(FYI, versions of utilities that are updated to use the new QceFile are SDML Ver. 2.0.54, SBDL Ver. 4.8.0, SPDL Ver. 5.1.0, LGDL Ver. 2.1.0, SSDL Ver. 2.1.0, EDR Ver. 4.7.0.  There is no need to worry about any such utility-update if you are not actively using it.)

Does it ever feel like your system is running slow?  Do you ever feel like you'd like to have an objective measurement, to tell you just how quickly it is or is not performing? 

We must confess, our RSS clients (those who lease cloud-hosted servers from us) have sometimes found themselves feeling this way.  Sometimes, on investigation, we've concluded the problem is solely because of a slow internet communication on the client side (nothing we can do about that from here).  On a number of other occasions, however, we've found there were issues causing slowness right within the systems we provide, and of course those are matters we have had to directly address.  Regardless, it has sometimes been difficult to determine which is the case.  It's especially difficult when our users are trying to make this determination on their own. 

This new tool is designed to let you directly see just how well your system is doing (or ours on your behalf), and regardless of context.  It runs a series of processes, and times how long the system takes to perform them.  Based on a comparison to some benchmarks, it then gives you an indication of the result. 

To run the new tool, navigate via the ServiceDesk MainMenu, as shown here:

The next thing you'll see is this:

. 

When you click to run the test, you'll see something like this:

Please note the caption at top indicates actual time as elapsed when performing the test.  The blue bar indicates your system's time as a graphic (shorter is better), compared to a typical-fast (but not blazingly-fast) system (green), and as compared to a typically-slow (but not abysmally-slow) system (red).  If your result is almost as good or better than typical-fast, you're doing pretty well.  If your result is closer to the typical slow, you're not doing so well.  If your result is beyond the typical slow, you are doing quite badly. 

Please also note that besides the standard (Test functions equally) option as above shown, you may select to Emphasize Disk Access or Emphasize Processor Operations.  The general idea is, if your system is slower than it should be, you can try each of the lopsided tests and see if it's more likely one area versus the other that's slowing things down. 

We think this will be useful for all users.  Regardless, especially for our RSS users, we suggest you run it when things are working well, so as to form a benchmark of what to expect.  Then, if it feels like things are running slowly, run it and compare.  Reported results will NOT BE AFFECTED by internet speeds, so this test can be quite definitive in letting you know if the server systems in themselves have an issue that needs to be addressed, versus there potentially being some problem in the communication between them and you (please note that in some instances there can potentially be a communication bottleneck at our end, in which case it will still be incumbent on us to address).  

I must sadly confess we were slow to perfect this.  We added basic direct-LG claims functionality some while back, but it required real-world testing (and real-world debugging) to truly make it fully succeed.  Thanks in significant part to longstanding and patient assistance as provided by Heather Michaelis at J&M Appliance, Inc. (in Redlands, CA), you should find the functionality is now perfect.  Thank you Heather!