ServiceDesk 4.7.70 Update 01/02/14

This new option relates to Flowing-Pipes, those instruments that allow unused capacity in one zone to be accessible for use in another (for details see the FlowingPipes-Handbook).  Potentially, these pipes can be confusing.  They allow excess burden in a "flow-from" zone to effectively move into the unused capacity of a "flow-to" zone.  What is potentially confusing is that, as burden flows in one direction, capacity consequentially travels in the opposite.  The thing you must remember is that any such pipe in itself points in the direction of burden flow.  If you keep this well in mind (and remember that capacity moves oppositely) you should be in good shape to avoid the kind of confusion that easily results otherwise. 

 Anyhow (and in regard to our new feature option), it turns some of our users had found it useful to put all capacity into one of more flow-to zones, and zero capacity in a particular flow-from zone.  Logically, they expected that the capacity of the flow-to zones would effectively transfer back into the flow-from zone.  This indeed worked just fine so long as the flow-from zone was setup with a capacity of at least 1.  If setup with 0, however, it did not work.  It turns out the reason for this is we'd coded in some logic governing the potential flows.  It essentially said: "If the user has specified zero capacity for this zone, that indicates a definite no, and we should not allow any effective flow of capacity back into it.  But, for some users pursing a particular strategy, that's not the logic they wanted. 

Hence, this new option is now added:

As you can see, the descriptive text is tiny, so as to fit within the space available.  Unabbreviated, it reads:

"0-allocated zones show available if flow-tos have capacity"

If you leave the option unchecked, the system will behave the same as it has historically.  If you check it, it will allow any unused capacity from a flow-to zone to effectively fill-in to flow-from zone, even if it's otherwise allocated as having zero capacity. 

Often folks are anxious to verify that SB-DispatchLink (and similar utilities, such SP-DispatchLink, LG-DispatchLink, and so on) are uploading correct dispatch-availability info to the third-parties involved.  Generally, this can be done quite readily by online review via the third-party's provided interface, to see what availability values have resulted there, then comparing to what's shown within SD's ZoneScheduler form (Shift-F5).  With but minor exception, this has worked quite well. 

However, there have long been certain machinations, with availability, which the DispatchLink utilities perform (along with SD-CyberOffice, for the purpose of exposing scheduling availability to your own direct customers), which SD's internal ZoneScheduler did not. 

For example, the utilities have each long been programmed to automatically do a burden flow between time-segments within a given zone-and-date-pocket.  To illustrate, suppose for a given zone-and-date pocket you've allocated 5 slots for morning, 5 for afternoon, and 10 for all-day.  Suppose you've actually booked 9 for morning, 8 for afternoon, and 4 for all-day.  Technically, you are now overbooked for total capacity (9+8+4=21, which exceeds the summed capacity of 20 as achieved by adding capacities of 5+5+10=20).  If a utility was to consider only the afternoon segment, it would conclude you still have 6 all-day slots available, and would then upload that.  Obviously, it would not be a good result for you.  To prevent that, the utilities are coded to flow excess burden from one time-segment (within any given zone-and-date pocket) into any unused capacity of another. 

Somewhat similarly (albeit with a somewhat opposite result), imagine the same capacity setup as above described, but where you've ended up with burdens of 13 all-day appointments, against 2 for morning and 1 for afternoon.  In that circumstance, you still have overall capacity of 4 (20-minus(13+2+1)).  If no behind-the-scenes adjustment was made, this capacity would be offered exclusively in the morning and afternoon categories (since you're already overbooked on your all-day allocation).  But that's not good.  You'd rather have folks choose all-day, if they are willing.  Given this preference, the system is coded to see where (in such scenario) you have availability across the spectrum of time segments overall (even if not for all-day specifically) and, in such a case, artificially notch up all-day availability to 1, hoping that is the category a consumer will select. 

Anyhow, these kinds of machinations were not being managed within SD's own Shift-5 ZoneScheduler form, and it sometimes resulted in confusion when folks sought to reconcile what they were seeing there with what they were seeing (and after an applicable utility uploaded) via online review with an applicable third-party.  Particularly because we'd just added an option to accommodate further machination on the utility side, we decided we should upgrade SD's ZoneScheduler form so that it might with greater precision show what is expected to be uploaded to third parties. 

While we were at it, we made a plethora of other improvements. 

The upper-right-hand corner of the form has been changed as follows:

OldNew

We have highlighted the changed area to focus on.  The general idea is, previously you could check the provided option and see the graphs change to show the result of your own-created zone-to-zone flowing pipes.  Now you may check another option to show the result of time-segment-to-time-segment flows (as above-described), and/or a third option to see where exposed availability will be notched up, in a scheduling pocket, based on availability in associated pockets (again, see above for explanation).  You will also find if float your mousepointer over any of these areas, a ToolTip will appear with further explanation.  All of it is so you can more particularly judge what is being exposed to others via various online mechanisms. 

In regard to such better-seeing, we have also added a new row of numbers in the display, as here shown:

As you can see, this row does the math to indicate remaining availability in each applicable pocket.  More particular, if you enable the options to allow the same internal machinations as the DispatchLink utilities perform, this row of numbers should show the very same values as are uploaded by those utilities (i.e., no more confusion). 

And there's more. 

If you've setup one or more zone-to-zone flowing pipes, do you ever struggle to remember (as you look at this ZoneScheduler interface) which pipes you've setup, running from which zone to which zone, and in what direction?  We figured there should be a graphic to assist you, in this regard.  (In fact, we'd planned to create it when this form was first envisioned and created back in 2002, but we never got around to creating it until now.) 

Now (and finally), the pipes become graphically real. 

I just now took a moment, and setup pipes from zone 1 to 2, from 5 to 3 and from 5 to 7.  Then, I re-displayed my ZoneScheduler form.  Look at what it now displays:

See those new pipe graphics?  Aren't they cool! 

BTW, the overburden in Zone 1 (as seen immediately above) shows as such because I did not have the option checked to show the result of flowing-pipes.  Look how it changes when I check that option:

To be clear, that particular option-to-show-flow has long existed.  However, with benefit of the pipe-graphic, it is now much more contextually obvious what is occurring, plus you have immediate, visual verification if you have setup your FlowingPipes.txt file as per end-result wanted. 

One other matter is, where applicable, there will now be an indication of whatever job-counts you have assigned to Zone-0 ShopJobs (for more details on the underlying method, see entry regarding Rel. 4.5.68). 

Aside from these very functional improvements, the interface has been improved aesthetically.  The colors are now much more refined.  The form more properly fills its space.  There is more vertical space above the "Max Load" line in which an overfilled graph can fully display, before intruding beyond available space.  Overall, we think you'll find it to be a much more enjoyable interface to use.