ServiceDesk 4.5.50 Update 11/20/11

If you're bored by historical context, skip the next three paragraphs. 

The first PVR interface in ServiceDesk was what we presently call the PostVisitReport Type-I (Shift-F7).  It collects PVR information via a dialog (Q & A) type interface.  It was the only PVR method for the first few years.  It was designed primarily with intent to accommodate a technician sitting at a console in the office and making his own PVR.  In 2002s we recognized the need for an interface where an operator (more typically an office person doing the PVR on behalf of a tech, rather than the tech himself) could simply click or tab into each area as relevant, as opposed to running through an entire dialog in every instance.  Thus, we developed SD's PostVisitReport Type-II, which is much more a fill-in-the-blanks type of interface. 

When first introduced, our new Type-II PVR did not have quite all the added bells and whistles as had been developed in the old and more mature interface (such as, for example, being able to report that a part as used from stock came from a different location than the applicable tech's truck).  Gradually, we added them in, eventually bringing Type-II up to full par.  Then, as folks began asking for even more bells and whistles, we began neglecting the old interface.  We would, in short, add a new bell or whistle into our shiny new interface (such as the system which warns if a part, as being special-ordered, is actually in stock), while neglecting to add into the old.  Thus, over time the PVR Type-II became a much more capable agent, as compared to the old interface. 

Approximately three years ago we introduced a new (and third) PVR interface, as incorporated in SD-Mobile.  Its history follows a trajectory similar to the Type-II PVR within ServiceDesk: first it did not have all the bells and whistles, but we gradually improved and augmented until it did, then as the process continued it eventually eclipsed the within-SD PVR in terms of the total power and utility it offers. 

With that as context, what's involved now is retroactively bringing SD's own Type-II PVR up to current SD-Mobile standards -- in one particular respect.   

Specifically, some 13 months back we augmented our cradle-to-grave parts management system (see 10/12/10 entry in the SD-Mobile WorkDiary).  Prior to that, Mobile's "check-off usage" section had nothing better than an almost perfect parallel to the section that's existed (until this release) in SD's Type-II PVR: a place where the user is permitted to check-off indication of usage, and in absence of such action the system assumes non-use.   We altered the Mobile interface to make it so the tech is required either to check-off usage, or to otherwise indicate a specific reason why he did not use the item. 

We had a request to add the same enhancement into SD's Type-II PVR, and that is what's accomplished in this release.  Now, where there are one or more items showing in this particular Type-II PVR box:

and if the operator clicks to save the PVR without having first indicated disposition of each such item, this interdicting message will appear:

 The user will be returned to the main PVR interface, to complete the required work.   Just as in the Mobile interface, a double-click should be used, on any line-item, if needing to indicate non-use and the reason why.  It triggers a box like this:

where the particular reason can be indicated.  The specific listing of options in this box will be precisely the same as in Mobile.  What's shown above is the default, but if you've customized the list for Mobile, the same customization will be seen in ServiceDesk (for instructions on how to customize, see this document).   

One more enhancement, to mimic current Mobile standards:  If there was a core on the item involved, the operator will be informed, and not permitted to proceed unless indicating the core return was placed into proper channels:

In general, we do not intend to bring SD's internal/built-in PVR interfaces up to every standard that has developed (and will certainly develop further still) in the Mobile context.  We feel our more advanced users (the ones more in need of and more likely to use advanced bells and whistles) should be migrating (most have already done so) into Mobile regardless -- so it is where we are logically putting most of the advanced power as regarding information flow between office and technician.  In the circumstances involved, however, it seemed sensible to migrate this particular enhancement back into the older environment.  

We work "stinking" hard here, striving constantly, with enormous energy and determination, to make the system better for all of you, our beloved users.  We think of it as a virtual partnership.  We're working for you, and you (in turn) help us with your input.  But the fact is (I am sorry to say), some of our users are a little less effective in helping us than we'd like.  When we receive communications that lack specificity and context, it is sometimes worse than receiving no communication at all (consumes our time reading them, but with no benefit in understanding).  In general, where you're initiating a communication and expect to put us to work in responding (typically via an improvement in the software) we need you to be willing to put in sufficient work to make your communication effective. 

Recently, I received an improvement/fix request from a user that struck me as the perfect model I wish all would strive for.  Given that it concerned a somewhat complex topic, the sender had first taken the time to fully explore and familiarize himself with what he was encountering in ServiceDesk.  Then, he further took the time to formulate his description in a manner that made it totally easy for me to understand -- and with great precision -- what he'd encountered.  I can't tell you how much easier this made it for me to go right to the underlying fault, and fix it.   

With the author's permission, I am here providing a copy of that email for all to view (click here). 

Though Paul Manning happens to set the highest possible standard (in communication excellence), many of you likewise do superbly in making your communications precise and readily understandable.  I cannot tell you how greatly I appreciate that. 

I also immensely appreciate when, like Paul, you are considerate in choosing to direct requests to persons other than me (Glade Ross) when accurately anticipating it is not a matter that requires my personal attention.  We've grown large enough here that it's not practical, any longer, for users to expect my direct attention on matters where other staff are competent to assist.  I can't be stretched that thin, so appreciate where people have the insight to leave me free for the matters where I am truly and uniquely required. 

If any of you do not know, unless there is a specific reason why I should be particularly addressed, email requests should instead go either to a particular staff person other than me, or to our general support mailbox (support@rossware.net).  If everyone chose to go direct to me in every instance (as some do; I've been on a campaign to try to break this habit), I'd be spending all day every day -- doing nothing but attempting to keep up with emails.  That would not a productive Rossware make.