ServiceDesk 4.5.68 Update 01/31/12

Tax Liability Report Very Much Improved In Appearance:

Almost a year ago (see entry accompanying Rel. 4.5.3), we introduced a compiled Tax Liability Report.  We emphasize the word "compiled" to distinguish from the pre-existing situation.  The concern is for users that must report on tax liabilities to different jurisdictions and at different rates.  We'd long provided exported data via which these separate obligations can be deduced and reported, but did not prior do the actual compiling of summaries for you.  That's what our new report (almost a year ago) introduced.  However, it was not a good looking report.  It placed plain text into a simple Excel spreadsheet that otherwise lacked any formatting to enhance clarity and easy understandability.  That's what is now improved.  The Excel spreadsheet as produced by this report now looks like this:

(The old one looked so bad we're embarrassed to show it even for contrast.) 

You'll notice the little red comment flags next to each jurisdiction title.  When you open the comments provided, you'll see they provide a listing of the zipcodes that, for the sales reported on, were found to exist within each such jurisdiction.  Other appropriate contextual notes are also provided, for the sake of any assistance you may need in interpreting the report. 

Tax Jurisdictions May Now be Defined at the Sub-Zip Level:

The above-described presentational improvement was triggered when we were working on a more substantive improvement, as we'll now describe. 

Almost three years ago we introduced the ability in ServiceDesk (again, we're dealing with users that have different tax rates in different jurisdictions) for you to define the rate as applicable within each jurisdiction via creation of what we call a Tax-Rates file (see entry accompanying Rel. 4.4.5).  The simple concept is you list each zipcode, and for each indicate the jurisdiction that's applicable, and tax rates.  ServiceDesk (and SD-Mobile) consult this file when needing to ascertain which rates should be applied to a job within each such zip area.  So does the above-described report. 

It seemed like a great plan, but with one caveat.  We soon received reports indicating that in some areas a single zipcode area will actually span across one or more different tax jurisdictions.  So, if I define a particular zipcode as belonging to one jurisdiction (as per the plan we developed), the result will be wrong for those residences that, though within that zip area, are actually in a different tax jurisdiction.  Dang!

This release provides a solution for that.  In essence, our new method allows you to have split-zipcodes.  Details are in a new chapter, as just added to our "How to Create Your Tax-Rates File" handbook.   One way to open that handbook is via a button provided in the ServiceDesk Settings form:

Or (perhaps more convenient for the moment), just click here.  When you open the little handbook (and assuming you want to know how to split zips), look for its Chapter 4. 

Occasionally over the last few years, we've had users express a particular conundrum.  It arises in connection with ShopJobs, and when using any of our DispatchLink utilities (or CyberLink) to keep outside entities (such as ServiceBench, ServicePower or your own online scheduling interface) apprised of availability status.  The conundrum is that, most typically at least, servicers do not want ShopJobs to decrement against availability.  This is because, in contrast to field-appointments, the time that's needed for shop work can typically be pushed around as needed to accommodate acceptance of much more time-critical field appointments. 

To be somewhat more specific, the issue arises only in the particular case where a company decides to create pseudo "appointments" for their ShopJobs.  Often companies find that a pseudo appointment is needed as the mechanism to put the intended/needed work on a tech's roster, to assure it's addressed in a reasonably timely manner (absent such "appointments," shop work can tend to be put off off forever and ever).   

The question then becomes: when creating these pseudo appointment for ShopJobs, how do you avoid having them decrement availability in zones that are setup to manage availability on field work? 

This release (actually, it was in the last release, but we forgot to announce it then) offers a solution. 

First, we made it so the system will accept (for the appointment's designation of applicable zone) Zone 0.  Zero is not a true zone.  It's a fictional one -- meaning that any appointment assigned to Zone 0 does not count against any real zone's availability (please note the underlying JobRecord may still be assigned to a real zone, and it's the only appointment's independent designation that potentially decrements availability status). 

Second, we added a new query that injects when you go to make an appointment in connection with a ShopJob:

The query is needed because what's sensible, in terms of what should be done concerning the zone-assignment, will vary with circumstances.   In some cases the appointment may be intended as one that's delivering the product back to a customer; in such a case, you'll want to accept the middle option (above): to insert the true/actual zone as applicable to the consumer's address (this is pulled from what's already designated within the JobRecord).  In another case, you may be pulling in a technician who's otherwise assigned to field work (within a true/outside zone) to do the in-shop work -- in which case it would make sense to pick the third option, and then indicate (as the subsequent dialog asks) the particular zone within which that tech works.  And, of course, there are the instances where you do not want the appointment to count against true zone, in which case you'll pick the first option above. 

Please note again this remedy applies only if you're setup with multiple zones.  If you're setup with a single zone (or with no zones at all), none of this will affect you.