SdWorkDiary

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:

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.

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 not affect you.

Though we've long had excellent reports for evaluating technician productivity (indeed, a whole set of them), we kept getting requests for some different kinds of numbers, as compared to what we were directly providing. In particular, folks wanted to more directly see, from among the quantity of appointments as assigned to each tech (aka "dispatches"), how many within a particular period resulted in completions, how many resulted in ordering parts, how many no-shows by the customer, etc.

It's called the DispatchesPerformanceReport, and is situated within (sensibly) the Reports form (F11), within its "Performance - Techs" sub-category.

As you can see, it's somewhat more raw-numbers oriented than are some of our other reports (this is what we heard some users wanting).

This report does require installation of Microsoft's Excel to contain its results, so if you do not have that application installed on the machine where you want to run the report, it would be a good idea to do so.

Our Reports/Online Handbook (available via provided button within the Reports form) does have an added section to describe more specifics about this new report (new Chapter 8 therein).

In November of '09 (see notes accompanying release of Ver. 4.4.38) we added the ability within ServiceDesk's FinishedForms context (Alt-F4) to directly open a ticket, as created by a tech within SD-Mobile. This made it possible for an office person to have complete edit-ability over Mobile-created tickets. Most particularly, an office person could now edit such tickets, add pricing and otherwise finesse, for the tech's reuse upon a return visit. (Of course, the opened Mobile tickets also became useful tools for ultimate entry to the SalesJournal.)

Though great this addition was, there is a significant element we did not at the time include.

Specifically, we did not make possible for a person in the office to initially create a Mobile ticket, prior to the tech ever having made one himself, as applicable to the job. This might be appropriate, for example, if the office receives a request for service and is able to tally up everything that will be involved prior to sending the tech out. This might be done for the sake of giving the customer a direct and precise quotation. Supposing the customer accepts, it's best to have that same document the one which the tech will then use, upon performing the work, for presentation to the customer.

With this release of ServiceDesk, that is now possible. Whereas, if you previously went to create a Mobile ticket on a job where none prior existed, you would have seen this message:

Just confirm you want to make the new ticket, and the rest is child's play. Upon your "saving" the new ticket, ServiceDesk uploads it to Rossware's online Mobile server, where it is then available to the tech, when he goes out on the job.

I thought we were doing a good thing by adding built-in screening, to prevent sending of reminder/confirmation-requests in circumstances where the underlying appointment is in a status that indicates it's already beyond such a stage (i.e., a request was already sent, the item was already dispatched to the tech, etc.). That intended "enhancement," however, resulted in a storm of protests, and so has been highly modified with this release.

In current state, the system will check when you request to send reminder/confirmations, to see if any applicable appointments appear to be already beyond that stage. If so, it will present a message like the following:

Since our introduction two days ago of Robo-Calling, it's been a whirlwind here at Rossware. It's possible this feature has generated more immediate excitement than any prior. Early adopters found bugs we needed to fix, and produced a nearly instant flood of ideas for improvements. We have tried to implement all as quickly as we can. This release fixes all known bugs, and incorporates all requested improvements, as needed within SD itself, that we are aware of to date.

Corresponding with this release of SD is a new release of SD-CyberLink, Ver. 4.5.8. You'll need to update to that to take advantage of the ability of your customer to choose to cancel (as opposed to confirm) the appointment via robo-call communication option.

One new ability that will not be contextually apparent (absent notice here) is a new option placed into the Confirmation/Options form. Current with the last-prior release, that form looked like this:

As you can see, the new section on the right gives you an option that is self-explanatory.

There's a new method to accommodate the need to record SalesEntries with dates that correspond with when the work was actually done, as opposed to when the entry was made (which has been the default date used in all circumstances, prior to now). There's a new button in the F9 SalesEnter form for the purpose:

This option may be particularly useful if you pay your techs on a commission basis, and want to assure their commission reports match perfectly with the reporting period (and contain solely work that was physically done within that period, as opposed to when the SalesEntries were entered).

We have people wanting to get ever more kinds of data out of the PartsProcess system. We decided to create a comprehensive export, that simply provides all fields for all records from that context:

If you do not recognize, this new option is in the F8 Archived-PartsProcess form.

At Rossware, we hate to move backward. Some five years ago, we introduced the truly modern and (in our opinion) correct method for reminding your customers of their upcoming appointments, and soliciting their confirmations. The function is part of our CyberOffice suite of options, and works with incredibly efficient, super-silky smoothness. Quite simply, ServiceDesk sends an email the afternoon prior to each appointment. This email reminds of appointment details, and invites the customer to click on a hyperlink to confirm. That link, in turn, takes your customer to an interface on your website (we provide as a plug-in) where he/she can either click to confirm, or re-schedule if need be. Full results feed automatically back into ServiceDesk. This is, quite simply (and, again, in our opinion) "the way" your reminder-and-confirmation process should work.

However, we've encountered a bit of push-back from some of our users. The refrain insists that there remain a significant percentage of jobs where it's impossible to effectively communicate with the customer via email, and so more old-fashioned communication modes must be retained. In particular, the desire is pressed for a system that, instead of using automation via email, would use automation via telephone calls instead (aka "robo-calling").

Again, we've been somewhat reluctant, because we feel it's a step back in technology, but we now nevertheless offer robo-calling as a method for auto-reminding appointments with your customers, plus to allow their automated confirmation.

Prior to this release, if you picked DispatchOptions from SD's F5 DispatchMap (either by clicking on a tech's name at the top of his list or by keying Alt-P then picking the "Invoke for All Techs" option), down near the bottom of the resulting list of options, you'd see this:

The option as shown highlighted above invoked our long-standing CyberOffice/Email/Hyperlink mode of reminding on applicable appointments (plus triggering for confirmation, etc., as described above). Within the same set of options from this release forward, you'll see the following instead:

As you can see, the option wording is changed to encompass a broader purpose. It's not just emails now that can be used as the method. The option can be used, as well, to trigger robo-calls. When the option is picked, the differences continue. This is what you saw before:

As you can see, you can still choose to use what we consider the modern method (emailing). Or you can choose robo-calls. Or you can choose to prefer emailing on jobs where an email address is present, with the system primed to robo-calling otherwise. Finally, you can choose to both email and robo-call in each case where appropriate targets (email address and/or telephone number) exist in the underlying JobRecord.

You may notice that the old options gave you a couple of different parameters from which to pick in regard to emailing (customer confirms via email versus hyperlink, and with emails user-reviewed first versus not). Those email-method options still exist, but have been moved out of the every-time dialog into more of a set-once-and-forget context. Specifically, if you right-click in the DispatchMap to bring up its CheatSheet, there's a new menu option there:

As you can see, it's a micro-settings form -- a place where you can set once what would have been the particulars of your choice within the old email-appointment-reminder/confirmation-request dialog (with the choice thus separated, it does not have to be offered to you each time).

When you choose to robo-call a reminder/confirmation request to your customers, within 15 minutes a telephone call will be made to whatever telephone number is in the first telephone number position for the consumer (e.g., CustomerTel1 if it's a COD job, LocationTel1 if it's a third-party-payer job). If there is no pickup of the call, the effort will repeat at 15 minute intervals thereafter -- until one of three conditions arise: (1) a person or device on the other end finally picks up; (2) the appointment is otherwise confirmed within SD; or (3) the date/time of the appointment moves into the past. Outgoing calls will go into wait mode during any period outside of reasonable calling hours (specifically, they are allowed only between 7:30 am and 8:30 pm, local time).

When/if the call is answered by a human, an electronic voice will remind of the appointment (with appropriate details), and ask the consumer to press 1 to confirm. If the call is instead answered by a voice-mail type of device, the electronic voice will leave a message with appropriate details, and ask the recipient to call an 800 number to confirm.

Regardless of how confirmation is produced, within minutes of its occurrence you'll see the appointment reference in SD's DispatchMap change to the appropriate symbol showing confirmation (it should happen within the next-cycled update of the SD-CyberLink program), plus there will be a notation in the JobRecord's narrative history describing the confirmation (very similar to if it was an email/hyperlink-based confirmation, but with text modified accordingly).

This is considered an extension of our CyberOffice suite of functions, and requires a CyberOffice subscription to enable. In fact, it's very important that you update to the latest SD-CyberLink release (Ver. 4.5.5) before using this new feature. There is a fee of 10 cents for each robo-call that is completed (i.e., if/when picked up on the other end; there is no fee for outgoing calls that are not picked up). We are paying the service that does the actual calling, and must be reimbursed the expense. We will charge the amount as part of your standard monthly billing.

Auto-Application of Discounts Via Transition from FinishedForm to SalesJournal Entry:

A new client in Canada does a lot of work for Sears. Sears pays the client 15 percent less than the amount invoiced. In other words, Sears expects the invoice to show one amount, while what they actually pay is 15 percent less than that. How to accommodate?

What we've done is, when you're using amounts as populated in a FinishedForm to auto-insert to a SalesJournal entry, the underlying code will now look for some key phrases and amounts in the underlying JobRecord.

Specifically, in the CustomerAddress box, it will look for the phrase "Materials Adjust". If it sees that phrase, it looks to see if there is a numeric expression following it. If there is, it will apply that numeric value, as an adjustment ratio, to the two materials figures as involved in the sale (merchandise and parts), when doing the auto-fill to a SalesJournal entry.

Similarly, in the CustomerCity box, it will look for the phrase "Labor Adjust". If it sees that phrase, it looks to see if there is a numeric express following it. If there is, it will apply that numeric value, as an adjustment ratio, to the two labor figures as involved in the sale (scall and labor), when doing the auto-fill to a SalesJournal entry.

Based on the above, this Canadian client should setup his Sears QuickEntry template in a pattern something like this:

Based on the QuickEntry template being setup in this fashion, those key phrases will be inserted to any applicable JobRecords as created with Sears as such a client. Thus, when it's time to do the SalesJournal entry, the phrases will be in the applicable JobRecord. You'll assemble total/face amounts of the sale (as per usual) within the FinishedForm. Then, when you click on the ExecuteSale button, ServiceDesk will see the adjustment amounts, and adjust accordingly when inserting figures to the SalesEnter form.

A long while back, we introduced an option in our MarginPlanner system to allow, in essence, MSRP to rule, in terms of what SD inserts via its auto-pricing mechanisms. This need was registered, in particular, by a client who felt that if he varied from MSRP he'd lose the loyalty of his client base. The formal title for this option is DeferToPublishedPricing. It depends on having SmartParts data installed (the source of such "published" pricing), and is triggered by simply checking an appropriately-labeled box within the MarginPlanner form (Shift-F10):

The thing is, until now this option has had effect only within SD itself, and not within Mobile -- where the tech is in fact often inputting parts that must be priced then and there. With this release, implementation of the option will potentially carry through into Mobile as well. In particular, when you now check the main option within SD, a new sub-option will appear immediately under it:

As intimated via the contextual labeling, if you leave the indicated box blank, your DeferToPublished pricing option will not carry through into Mobile (i.e., the default/status-quo that's prevailed until this release will be maintained). If you place a value there, however (even a value of zero), it triggers for the option to carry into Mobile. The underlying logic is, you may want your Mobile pricing to be tied to MSRP, but perhaps just a bit more (the above-illustrated setting, for example, would result in Mobile-created pricing being inserted at 10 percent above MSRP). You can pick whatever percent difference from MSRP you want Mobile-created pricing to be, including precisely at MSRP (in which case you'd insert a value of 0).

Yes, if you're a client in the US, you're indeed among the overwhelming majority of SD users -- but it doesn't mean we can overlook our dear friends to the North. As mentioned in an earlier release, they have some special tax needs there, owing to the fact they have provincial sales tax (PST) and federal sales tax (GST). In some of their provinces, both are effectively charged as one entity (HST), but in others they're fully separate. Back with release 4.5.44 (see relevant entry below) we had a major upgrade within Mobile to accommodate the separation. This release concerns an enhancement within SD itself.

In particular, we recently learned from a client in Saskatchewan that, at least as configured there, some sale items are exempt on one of the two taxes, some on the other, some on both and some on neither. This is relevant to SD's FinishedForms POS interface (Alt-F4), where the Generic and Custom form types have long been configured with a column of line-item checkboxes, to indicate whether each corresponding line-item is tax exempt. For Canadian users as just described, two different such columns are needed.

The first of the two columns should be checked to indicate that a corresponding line-item is PST-exempt, and the second to indicate GST-exempt (if you forget which is which, float your mousepointer over the top of any checkbox for a ToolTip reminder). With this release and forward, the two columns will appear (within the Generic and Custom FinishedForm types) for any user whose SD installation is setup to indicate separate PST/GST treatment.

Upgrade for the Within-SD Type-II PostVisitReport -- Bringing it up to the Current SD-Mobile Standard in Regard to Checking-Off Usage (or Why Not?) of Special-Ordered Parts:

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.

Even when first introduced on the market, ServiceDesk had a lot of awesome features. There were several particular and significant functions people reasonably expected, however, that did not exist. When asked about such expected elements, I've candidly referred to them as "holes." As a general development strategy, we've gone after the hard things, occasionally skipping past an element that seemed less immediately important. Over time, we've made it back to most such areas, filling in such holes as were initially left behind. But one in particular has remained, until this release.

In the inventory control system, we've long had several superb systems for ordering stock replenishment. We've also had a superb interface for checking in stocking parts as they arrive. We have not, however, had a mechanism for keeping track of what's on order for restock and waiting for arrival (referring here specifically to stock replenishment, as opposed to special-order where in fact such details have long been very precisely tracked).

For persons migrating from other systems where they had such an ability, this hole has at first seemed shocking. At least on initial discovery, they've typically thought the hole would be untenable. For years, though, I've had the same reply. Please try the system as is. If after real use you find this hole is an issue for you, it will then be a priority for me to fill it. Otherwise, I need to spend my time on projects real-life users are actively clamoring for.

To be candid, I've wished somebody would later tell me the hole had proven to be untenable, because I've grown tired of confessing to its continued existence. It did not happen, though, until last week. A user in Newfoundland called and said for them it's an average of ten days between placing their order for restock and receiving the shipment. During that time, they need to order restock again -- and, obviously, need to know what's presently pending in that ten-day order queue.

From this release forward, ServiceDesk will automatically keep track of re-stock orders when you create them via the F10 form's items-presently-deficient method (keyboard shortcut is F10→O→D). It will also automatically check-off items, as prior placed into this new ItemsOnOrderQueue, as you check in parts using the F10 form's receive-items-into-stock method (keyboard shortcut is F10→R). In fact, while working in these two environments, you won't notice this activity. It's simply done behind-the-scenes, for you.

Where you'll see a difference is where you go again to that same order-on-the-basis-of-items-presently-deficient environment, and view items on which you are still deficient, and where an order is presently pending. In that circumstance, text in the right-third of any applicable line-item will appear in a magenta color, as opposed to the normal black. This is to alert you to the fact an order is actively pending on that item. And, if you simply float your mousepointer over the item, a ToolTip will appear that details precisely what order is pending (or, if multiple orders, it will detail the multiples):

There are certainly enhancements we might make in the future, now that we've created this particular structure. For example, we might make it so you can receive a shipment simply by direct-matching it to the prior order. For now, though, the above is as far as we've gone. It meets the minimum need.

This is one that's likewise been a long time coming, but -- hey -- we got there.

WipAlerts are a totally awesome feature. If you've not been taking advantage of them, I stoutly, strongly, and with huge emphasis recommend you change that omission post-haste. Really, they're totally powerful, and if you're at all past the beginning stages of ServiceDesk implementation, you should be using them.

Regardless, as awesome as WipAlerts are, they've long suffered from a particular limitation in IQ. It concerns either of two situations:

2. You've ordered one or more parts, and the expected delivery date is rather far in the future.

In either case, the customer is not really expecting to hear from you for some significant time. Regardless, it's been the structure of the WipAlerts system to periodically pester you, even while you're waiting for that far-off event. On the one hand, this is not all bad. In my service business, we learned that even when we told a customer it would be at least two months before a part would arrive, if we did not call them at least occasionally during the intervening period, they'd conclude we'd neglected them. WipAlerts are a great tool to help assure that occasional contact. However, they do not need to remind you as often as otherwise.

Until now, they've had no IQ to distinguish between that circumstance and others. With the present release and forward, they'll be smarter.

Specifically, where either an appointment or expected parts-delivery date are still pending, the WipAlert system will multiply whatever is otherwise the specified grace period, for the category, by a factor of five. As an example, suppose you've left the grace period as applicable to the "Waiting for Parts" status category at the default value of 3 days. If so, and if the system finds the anticipated arrival date of any pending special-order order part is still in the future, it will multiply that three 3-day grace period by a factor of five, changing it to 15 days instead. In consequence, you'll not receive a WipAlert in such such circumstances unless its been 15 days (as opposed to a mere 3) since the date of the most recent entry in the underlying JobRecord's historical narrative.

To assist you (and, frankly, we here at Rossware too) in remembering what is the structure of this enhanced WipAlert IQ, we have also augmented the ToolTips that show when you float your mousepointer over any JobRecord's status selection. Instead of merely showing whatever is the applicable grace period for that status, the ToolTips as particularly applicable to the status categories of interest will additionally have some added text to explain this added IQ. Here's an example:

As with any ToolTip, this one comes up when you float our mousepointer over the underlying object that triggers it (in the above case, the "Waiting for Parts" check category).

Recently we were asked to add a couple of figures to the "Tech's Revenue" report (keyboard shortcut to get there is F11→T→R. The new figures are shown (circled) here:

The first-circled section is obvious in meaning. The second breaks down the tech's average per-day sales in Materials (M) and in Labor (L).

A database-cleanup routine (for the UnitInfo.mdb file) was added to the regular nightly archive sequence. It will help keep your UnitInfo database performing in top trim.

In the Reports form (F11), when you a run Sales-Summary there has long been button for exporting extended data, including in particular a table that itemizes each sale with significant accompanying data (zipcode where each sale occurred, department, etc.). We have just added three more fields to that export (exempt materials, exempt labor, and exempt total). These values could always be derived, but now they are there explicitly.

Full Accommodation for PST/GST Separation -- as Needed in Some Canadian Provinces:

If you operate in a province that requires separation of PST and GST on your invoice, we hope you have known there is an alternate version of the Generic FinishedForm that's designed to accomplish this. If you need this and have not been setup for it, please contact our office and we'll help you make the change.

If you also are using SD-Mobile, this will especially interest you. Until now, there has been no ability to separate PST and GST in the Mobile ticket format. Now there is. For details, please look in the SDM-WorkDiary for the entry carrying the same date (10/10/11) as this one.

I must confess I am sometimes slow to finally get something right. I thought I had POS returns management fairly well "nailed" when rolling out the improvements as announced on 9/13 (see entry below of that date). Turns out, that area of operation was less well "nailed" than I thought. This release seeks to address that

I have, in fact, worked out a whole new (and much better-streamlined) procedure for managing returns, and I've done a completely new re-write of the manual section (the prior re-write was only a couple of weeks old) that's devoted to the topic. You'll need to read that section, please (it's very short), to know how the streamlined/easy method is intended to work.

You can open the entire FinishedForms Mini-Manual, if you wish. Use this link, or the button as provided for the purpose within SD's FinishedForms interface (see first graphic in the preceding entry below, to know where that button is at). The whole mini-manual document is about 17 pages, however (excerpted from the main SD manual) and for returns in particular it's only about two pages (near the end) that will concern you. We suggest you go to the very bottom of the document, then up three pages. The section of interest begins in the middle of that third-from-the-bottom page.

Expedited Initiation of POS Transactions when using the "From-Callsheet-Mode:"

Back in 2008 we introduced our Direct-POS system, which allows maintenance of a POS-Window from which point-of-sale transactions can be conducted with no need of initiation from Callsheets. Regardless, it remained possible to initiate via the old method, via Callsheets, and many users preferred to stay in such mode.

In such connection, we've also long had an option where, from a Callsheet, you can optionally right-click on the Job/Sale button as a means of telling the system that, upon creating an underlying JobRecord via the little yellow "Create Job/Sale" form, you want to transit immediately from thence to the FinishedForms interface (as needed when you're doing a POS). Recently, a user pointed out that the momentary stop in that little yellow form served no significant purpose. He wanted express passage straight past, direct into the FinishedForms interface. It seemed like a smart idea, and with this release the change is implemented.

With all the work as recently done in connection with POS operations, there was a very serious need to update the manual accordingly. In fact, upon going to complete this task we found the applicable manual section was so out-of-date as to be piteously embarrassing. It wasn't just it's contents. The entire FinishedForms discussion (encompassing both warranty claims and POS) was but an add-on section in a chapter otherwise devoted to other topics. That reflected developmental history. The FinishedForms interface and all its related functions began small, and only over time grew into such proportions as exist today. At any rate, given today's proportions, it's a subject area that deserved its own chapter, and the manual has not been re-organized to make it such. And it wasn't merely re-organized. The entire chapter has been written fresh, to accurately reflect today's state of the art in terms of what exists in the underlying systems (the old section was tossed).

The current manual re-write is available for download (in pdf format) from the ServiceDesk downloads page. Additionally, we've altered the buttons that first appear when you do a direct load of the FinishedForms interface.

The button as highlighted above will open the newly-written section from the manual, as an excerpt specifically on the topic of the FinishedForms interface, and the details of its particular warranty-claims and POS functions. It's there to be handy for you, as a Mini-Manual, whenever you need it.

You might think it would be nice for me (as the President of a software company) having no bosses to answer to. Hardly. I've got at least 520 bosses. When I try to please some, I aggravate others, and vice versa. Sometimes it seems like a no-win situation. In the present case, I thought I'd engineered the new POS "command" interface in a manner that would satisfy every desire, but I was naive.

In a nutshell, I provided means (and as particular to any form type) to accommodate any combination of sub-actions as integrated with a single-click for Sale, and with either sequence of Sale-first or Sale-last. Of course (and as always), any sub-action can be individually clicked, too. But that wasn't good enough. Some people wanted a single-click option that would do a collection of selected sub-actions, but excluding (as opposed to including) the Sale. Remember that Burger King slogan ("Have it your way")? That's me. Therefore, the just-introduced new interface has gone from this:

As you can see, the "Execute Sale" button has been changed in color and moved to the right. In it's place on the left is a new "Do inclusions only" button. I believe the structure speaks for itself.

POS operations have not been Rossware's forte. It may have been overstating it, even, to call our past POS functionality a "system." It was made from bits and pieces, cobbled together from elements first built for other purposes. The overall result has been workable, but not many would have called it pretty. With the present release, we are at least several steps closer to having a system that, if still short of "beautiful," you might at least find worthy of affection.

1. Improved Methodology for, and Immediate Visibility on Items Flagged for Inventory-Transfer and/or PartsProcess Action:

Here's a place where the prior design was truly dumb. There were mechanisms that allowed any line-item in the applicable FinishedForm to be "flagged," as applicable, for an actual transfer to/from inventory or creation of a special-order request in the PartsProcess system. Intended inventory movements were flagged by selecting an item from the as-you-type dropdown (specifically, with it keyed to internal inventory). Special-orders were flagged by manually typing a double-asterisk somewhere in the line-item. In the first case, there was no immediate visibility as to whether an item was flagged, and drop-down selection was the only method to accomplish flagging. Plus, there was no direct way to turn off a flag. In the second case, the double-asterisks might have seemed a good visual indicator, but even this was not always true, for the system was programmed to ignore double-asterisks if present from a prior session. In either case, whether an item was truly flagged, or not, only became apparent when the "Enter to Inventory" or "Create Order" process ran, as applicable, typically at end of your POS session.

All for-action flagging is now immediately visible, and remains so in real-time. If something changes to remove a flag, you'll immediately see it. If something changes to add one, you'll see that too. Flagging visibility is accomplished, simply, by coloring the line-item that's flagged, and with a particular color, depending on the flag type.

It is also now easy to manually flag (or un-flag) any item. Just do a right-click in the description box:

Upon right-clicking (and as you can above see), you're presented with a simple set of flag-related options (plus the same opportunity to delete the line item, which used to be all you'd get with a right-click). The flagging options also include the same colors as the flags themselves, so the dropdown can simultaneously serve as a "key" to remind you of what each color means. As far as operation is concerned, just pick what you want. It's that easy.

Additionally, there is now an option to automatically flag an item for special-order creation. It follows the pattern of auto-flagging-for-inventory-transfer that's long existed (e.g., as occurs where an item is selected from the inventory-integrated dropdown). Logically, this new auto-flagging works in parallel fashion, but where you've set the dropdown to integrate with SmartParts data (as is typically used when typing in a non-stocking item). One difference is that this automated flagging is optional. It defaults to On. If you prefer to have it Off, pay attention when the "Integrate Select" box comes up (just after you've clicked into any previously empty partnumber box):

As you can see, it's easy to turn this automation off (or back on again) as preferred. Please also note the preference setting is specific to user and FinishedForm type involved.

One more note about these new methods. This does not concern anything new, but we want to be sure there is no misunderstanding. Simply because an item is flagged for action, does not mean the action has occurred. In fact, it almost means the opposite (once the action does occur, the item is automatically de-flagged). Please do not mistake flagging for actual action. The actual actions occur only in conjunction with, as applicable, the "Enter to Inventory" and/or "Create Order" processes (typically as invoked at the end of your POS session on a particular ticket).

As is true of many long-in-use systems, our FinishedForms/POS interface is the product of many evolutions. Believe it or not, it's first incarnation had one function only: to enable printing of text to a paper Narda! That was it. Thus, at the time, this interface needed (and had) but one action button, and its descendant still exists today: it's the button labeled "Print ticket." Next in evolution was adding the "Transmit claim" button (to accommodate that new-fangled, hoity-toity method of conveying a claim to a manufacturer that we now take for granted).

Then someone wanted ability to print the entirety (not just initiating information) on their own form (i.e., not to the Narda, and not using SD's up-front ticket-printing method, which only does initiating information), so we added the first alternate form. Then someone thought, since they were assembling sales numbers in the FinishedForm context anyway, wouldn't it be nice if that was used as the basis for filling in a sales-entry, so we added an action button for that. Then someone said, maybe you should make it so I have the option, if I'm choosing to print or transmit anyway, that it automatically offers to make the sales-entry (essentially self-clicking on the "Record Sale" button), so we added that (making the option particular to each form type).

And it continued. By and by our first client came along who was doing significant POS work, and it became evident we could adapt these mechanisms for the purpose. But if so, the interface needed integration with parts inventory and special-ordering, so we added built-in flagging for such actions (though they were very clumsy until now, as above-noted), along with buttons to accomplish the actual events. It was also realized, in regard to these new action buttons, it would be nice if their "click" events were also optionally auto-integrated with doing a print or transmit, (i.e., just like "Record Sale") so this also was duly programmed into the system.

Evolution does not always make for pretty. Below is what the resulting structure looked like, just prior to this release:

On reviewing the above, it became evident that an improvement was long overdue. Here is what you will now see:

Formerly, the "Record Sale" button was but one of many. Now, please observe it is instead labeled "Execute Sale," and is given the due prominence that seems logical for a POS interface. Additionally, instead of it being potentially integrated with other actions as before, other actions may instead be integrated with it (we think, for POS operations, this is the logical emphasis). Plus, the mode of integration is now much more explicit and selective.

Specifically, the former method for integrating actions (i.e., to tell the system you wanted one particular button-click to auto-include others) was by right-click-toggling-to-red the form-selection-radio-button as pertinent to the form type on which you wanted this (referring, of course, to the one, "vanilla" form of integration as was formerly offered). That does not happen any more. Instead, each of the action buttons (aside from "Execute Sale") will show a little checkbox on its top-right corner at any time that the "Execute Sale" button is activated (again, please see above). With any particular form type selected, you can simply check (or uncheck) the button/actions you want included when the "Execute Sale" button is itself clicked. These settings are again local, and particular for each form type (in fact, each will default to a check state we deem as most typically wanted for the form type involved).

Please note there is also an option as to sequence (i.e., whether the sales-entry occurs before the integrated clicks, or after). If you do a simple left-click on the "Execute Sale" button, the integrated clicks will occur before the sales entry. If you do a right-click, they'll occur after (no need to memorize this fact; a simple float of your mouse-pointer over the button will bring up a ToolTip to remind). Of course, you should also note that each of the potentially auto-included buttons may be clicked-on individually, in their own right.

Another change is that the "Enter to Inventory" and "Create Order" actions (formerly accommodated via two separate buttons) are now accommodated via a single button only, labeled "Execute LnItms." It's another button that, if you forget exact meaning, you can float your mouse-pointer over for assistance.

Really (I'm not just bluffing), there are tons and tons of smaller improvements. One example: if you fail to fill-in a quantity yet select an item from the dropdown, the quantity box will automatically populate at 1. It's a small convenience, but such matters add up.

Our resident "geek extraordinaire," Josh Smith, gets direct credit for this one. If you've updated ServiceDesk even once, you've learned the actual update file (as downloaded from our website) is a single, self-extracting zip folder. In other words, all files as contained in the update overall are "packed into" this single file, which is equipped to self-extract those files into your computer (it's the self-extraction utility you're seeing when that "Winzip Self-Extractor" window pops up).

The thing is, the location where the files need extracted to can vary, depending on how ServiceDesk is installed in your computer and network, and I'd never managed to discover a method via which ServiceDesk can dynamically tell that Winzip Self-Extractor what "Unzip-To" path it should offer. For such reason, it is simply hard-set to the most typically needed path ("c:\sd"). To compensate, the update-dialog within ServiceDesk has been programmed to tell you, the user, that you'll need to manually change the path to, when that is fact the circumstance. The problem is, people tend to not read the dialog, and end up unzipping to the improper location. Even for those that do it right, it's an unwelcome added step to have to make that change.

Good ol' Josh managed to find the trick that my research had failed to discover: namely, a way to programmatically (and on-the-fly) tell that WinZip self-extractor what unzip-to path it should offer. Based on this, the ServiceDesk-managed update sequence is now much improved. There are no longer any steps in the sequence telling you what you need to do to manually change that default path. Instead, it will default just as needed for the circumstance. In fact, there's not even a need for you to click on its Unzip button. That, too, is automated. Overall, you should find the update sequence much more automatic, and fast.

By popular demand, the archived-PartsProcess form (Ctrl-F8) has a new report. Here is where you request it:

In short, it's a summary, itemized by vendor, of everything you purchased over a specified period of time. Like its cousin Ctrl-F8 reports, when this one displays there are buttons to the side that allow you either to print the results, or to open an underlying Excel file that contains the underlying, item-by-item records on which the report is based. If you've had a need for something like this, we think you'll love it.

One of our CE (consumer electronics) clients recently brought to my attention that the system was doing a poor job with the particular needs as involved with transmitting Panasonic claims to ServiceBench. Three particular needs were expressed:

1. Some Panasonic claims involve the need for a special (otherwise non-standard) WarrantyType designations. This is a field-value that most often indicates whether the claim is Parts-Only, Labor-Only or Both, and ServiceDesk has heretofore handled those distinctions implicitly (i.e., behind-the-scenes, without you needing to worry about it). For this Panasonic need, however, we needed to make a method for the a Panasonic servicer to set it explicitly. That need is met via a new box in the on-screen NARDA:

Please note this new box will self-populate with the same value as would have always been implicitly-deduced on your behalf (i.e., behind-the-scenes, within the system). We're simply making that deduction visible now, and providing a place where you can manually change it, if wanted/needed. Please note, in such regard, the system internally re-calculates what's normally-appropriate in this box anytime the total-tallies in the form change (i.e., if parts were added or taken away, labor added or taken away, etc.) -- so, if you need to set it manually, do so after the other items have all been setup.

2. Panasonic needs a CaseNumber in each claim (which is pulled at the SB end from their claims-transmission Other Item2 Code). We are accommodating this via our on-screen NARDA's Contract/Service Agreement Number box:

Please note it is a special-treament for the system to place the contents of the above-identified box into SB's Other Item2 Code field. It will apply only when the system sees "PANASONIC" as the underlying client on the job.

3. Panasonic needs round-trip-mileage in each claim (which is pulled at the SB end from their claims-transmission Other Item1 Code). We are accommodating this via our on-screen NARDA's Miles driven box:

Again, please note it is a special-treatment (only where Panasonic is the underlying JobRecord client) for contents of this box to be placed into SB's Other Item1 Code.

If you're wondering why things must be so complex, it's becase ServiceBench uses various of its claims-transmission fields differently, depending on who is their underlying client. We have to cope with those differences from our end. Regardless, in addition to the actual operational special-adjustments as are described above, the contextual Translation-ToolTips have also been modified to explicitly describe what's being done (and in what circumstance) with the contents from each box.

We have adopted a new strategy for managing the ServiceBench DispatchID. For some, the old method was fraught with frustration. It depended on you maintaining an appropriate setup of text (DispatchID in the right place and with appropriate flags), and if you broke the rules, ServiceDesk would not capture and interpret the DispatchID correctly. Beginning with ServiceDesk Ver. 4.5.31 and SBDL Ver. 4.5.5 (both posted on the morning of Monday, 8/22), there's an improved method.

In a nutshell, SBDL will now place the DispatchID into an added and protected location (some have referred to this concept as "hard-coding" the number). Specifically, it will go into the underlying MoreInfo notes. Formerly such notes were configured by SBDL to read as follows:

And, if any user tries to do any edit on this section of text, the edit will be disallowed. They'll encounter this dialog instead:

The DispatchID is thus kept in a secure and protected location, where ServiceDesk can in all instances accurately capture it.

If you examine the following image as extracted from a DispatchMap, you'll see some objects you've not seen before:

If those new objects are not jumping out at you, look specifically for smiley faces (though, actually, not all are smiling). There are three of them. They are the new feature being announced here. What are they for?

Quite simply, they are to equip the person who arranges your technicians' scheduling and routes with a feedback mechanism that encourages real diligence in achieving optimization. It makes a lot of difference to your operation's profitability, after all, if those routes are efficiently arranged. It makes a huge difference. Since pretty much the beginning in ServiceDesk, we have provided mileage figures within the DispatchMap, hoping operators would use such numbers as a means to self-score their finesse, seeking (we've always hoped) to whittle each tech's average-miles-per-job figure to the smallest level possible. But (and alas), the sad news is many simply ignore those figures. For such reason, something more concrete has been needed by way of encouragement -- to reach into the operator's psyche, as it were, with a more pungent encouragement to optimize.

That's exactly what the smiley faces are for. Next to the mileage-summary at the bottom of each tech's listing of jobs, you may now have a smiley face (varying between happy, neutral and sad) that applies to that particular tech's route. In the top-left corner of the map as a whole is another, larger smiley face, which similarly varies in expression depending on whether the day's entire roster of jobs meets specified targets for mileage efficiency.

Based on the above, anyone in the office can have instant and obvious visual feedback regarding whether efficient routing has been achieved.

Even more concretely, they can be encouraged to fix things. Just a glance at the frowny face in the above image, for example, suggests that Arthur Manoogian's route needs a fix. Look over at his route, and you can see, instead of sending him from the Smith job to Bazooka to Ross, it would be more efficient to put Ross in the middle. A quick mouse action would do this . . . and, instantly . . . his mileage-summary's frowny face would turn to a smile!

To implement this new capability requires a little setup on your part. Specifically, ServiceDesk cannot know what "mood" to put on a particular smiley face without knowing what is a reasonable mileage target, for efficiency, as applied to the tech involved (techs that work in predominantly rural rural areas will obviously have higher per-job "par" figures than those working in condensed metropolitan areas). You're going to provide that information to ServiceDesk in a new box as available within the Technician-Properties window of the Settings form. To bring up this window, go to your ServiceDesk Settings form (Ctrl-F1), look in the Tech-Roster section, and click on the technician of interest. That opens his Properties window. The new box to fill-in is shown here:

Just to be clear, what we're referring to here is what you want your operators to consider as a par figure, for the tech involved, in terms of average per-job-miles in his route. For example, if you were to estimate that 80 miles is typically about what the driving distance should be for ten jobs, you'd figure an average of 8 miles-per-job, and place that figure (i.e., 8) into the above box.

Beyond setup is the matter of how the system actually works, within the DispatchMap.

In such regard, please be aware that smiley faces will not appear for any tech for whom you have not specified (as per above) a "Target average miles" figure.

Very simple. If, for the tech's actual route as planned, the system predicts an average miles-per-job figure that's within 10% of the tech's target figure, ServiceDesk will present a neutral face for that tech. If the predicted figure is better than that 10% margin, it will present a happy face. If it's worse, it will present a frowny face. A similar strategy inheres for the larger, roster-wide smiley face in the Map's top-left corner. The difference there is that it's roster-wide comparisons that are made, so you can judge if on average a particular day's routes merit a smile, a neutral face, or worse.

As a further aid, the system offers supplemental information if you float your mousepointer over one of the visual indicators. If you float your pointer over a tech's mileage summary area (or the smiley face itself), for example, you'll get a tooltip that informs you of what is the target figure for that tech (for easy and quick comparison to the actual/operational figure):

Similarly, if you float your pointer over the smiley face in the map's top-left, you'll get a cogent summary regard the data underlying its "mood:"

We hope you'll make extensive use of this new tool, and profit exceedingly from it.

Installment Two on Improved Specification for Tech's Begin-Route and End-Route Locations:

Since we added automated route-optimization via-call-to-MapPoint, some few years back (see entry here accompanying Rel. 4.3.76), there's been a mechanism to specify, for any given tech, whether you want the system to figure his driving begins at his home, at the office, or at the first job otherwise picked for him. Same thing, essentially, in respect to where his driving ends for the day (both specifications can be referred to as "route end-nodes). This specification was actually part of the route-optimization dialog. Just a few releases back, though (see entry accompanying Rel. 4.5.25), we announced an improved method that makes the specification independent of the routine dialogue.

It turns out that was a short-lived improvement, for it's superseded by what's announced here. Both prior incarnations of this feature saved the relevant settings to the applicable station's local registry, which meant it was a local setting only, and even if set at one station, there'd be no effect on what happened at others. For the new "Smiley Face" feature, we needed better than that. In fact, prior to this release, all of the per-tech mileage estimates have assumed each tech begins and ends at the office (regardless of settings for route-optimization) -- an assumption that in this age is increasingly untrue. We needed to fix that to make this feature all that it should be, and with such expanded use it was also important that such specifications take effect throughout all stations in your network, and not just locally.

That is the precise improvement that's being described in this entry. A few short paragraphs above (scroll up a tiny bit to see), we highlighted a particular new control within the Settings form's Tech-Properties window. Right next to it are two others, now highlighted here:

As above hinted, this is now the place where you can make specifications system-wide, regarding expected end-nodes in a tech's route. Indeed, though on the face of the new controls it appears you can only select from among two options ("Home" or "Office"), you are in fact free to select neither, which in effect gives you a third choice. (if you've prior selected one and want to de-select, just click again). If you do select neither, the system will refrain from implicitly adding such a leg to the tech's route.

Regardless of what you pick for a tech, the system will apply your selection when: (1) calling to MapPoint for its automated route-optimization; (2) calling to MapPoint to load and display a route; (3) calling to GoogleMaps to load and display a route; (4) exporting route data to a file; and/or (5) calculating a tech's predicted total miles and average-miles-per-job.

Please finally be advised that, from this release forward, ServiceDesk will ignore any such local specification on a tech's route-end-nodes as was formerly provided. If you have in the past been relying on such specs, we strongly suggest you go into your Settings form, click on each tech, and re-specify what's wanted for him.

With almost five weeks since the last prior entry here, you'd expect a more celebratory headline. It just didn't happen that way. We've been totally busy with tweaks and minor fixes. For example, we just learned that the AHS-dispatch-insertion feature was broken. It's fixed. We just realized today that the POS system could be improved if, when creating a s/o request via the POS context, the sell-for price was auto-inserted to the underling PartsProcess record. That's presently done. Last week we were pressed (this required a lot of time) to better accommodate the situation in some Canadian provinces where two elements of tax must be separated. That's presently done. Etc. Etc. Etc.

Y'all can thank Perry at A-1 Appliance, in Pearl, Mississippi, for this one. Debit cards (as distinguished from "Credit" cards) are becoming increasingly common. Our Virtual Terminal has been programmed to process sales as Credit-Type transactions, even if a Debit card is what's actually involved. In some instances, it's preferable to have the sale configured as Debit-Type instead, and from this release forward you can do that.

Of course, one of the critical elements in making a Debit-Type transaction fit the definition is that a PIN (Personal Identification Number) must be obtained from the customer. More than merely obtained, it must be punched in via an accepted PinPad entry machine (in other words, it is not possible to simply punch-in the number on your computer's keyboard; the credit card industry does not permit that). This means, bottom-line, if you want to run transactions as Debit-Type you must do more than merely update to this release (or later) of ServiceDesk: you also need an appropriate PinPad entry device.

In a nutshell, I have done my programming to integrate with a Verifone PINPad 1000SE, with it connecting to the computer via serial port). So far as I know, it's possible other PinPad devices might also work (at least assuming they also connect via serial port), but I make no guarantee; nor have I any present intent to expand the programming to accommodate other machines. Regardless, you may obtain the Verifone model in question direct from Merchant Warehouse at a reasonable price ($79).

Once you have your device, you'll need to determine what port number it's connecting on. With that number in mind, click on the Virtual Terminal's new Setup button:

That will open the new Setup frame, where you can set that port number accordingly.

With the above done, you should be ready to do Debit transactions. At this point, we've not provided a special button for the purpose. Instead, please signify you're choosing the Debit (as opposed to Credit) method by choosing to Right-Click on the Execute Sale button, as opposed to the standard Left-Click. If you float your mousepointer over, a tooltip will remind you:

Please note that you cannot run a keyed-in transaction as Debit-Type. It requires a swipe.

Again, TAT is an acronym for Turn-Around-Time, and of course an objective in the service business is to keep your TATs as tiny as possible. Four releases back (see entry accompanying Ver. 4.5.22), we introduced a new "Quiescing" feature, associated with the JobsPerusal form (Shift-F7), and designed as a powerful new tool to assist in minimizing TATs. This release features two more such tools.

First, the JobsPerusal form now has a new filtering category, as shown in this comparison:

Second, we have added a "day-counter" window the the JobRecords-current form (F7). In its bottom-center area, it will display a box indicating how many days-old the job is. The indicator will change in color and emphasis, depending on quantity of days old (the coloring/emphasis scheme is based on age categories as listed in the dropdown shown above):

Again, this "day-counter" box will appear in the bottom-center of every still-pending JobRecord.

Overall, the first new option (as provided with this release) gives you the chance to easily review jobs within particular age categories. The second provides an on-its-face reminder, any time you glance at a job, of how old it is, plus provides an increasingly-acute visual alarm, as the job gets older and older. Overall (and if appropriately used), we think these two new tools can do much more to assist you in making your TATs as tiny as they can be.

Potentially (depending on in what degree you've chosen to use automation), ServiceDesk and its utilities can be involved in sending many kinds of emails to your customers.

These emails fall into two broad categories: those that are reviewed first (i.e., the email is first opened into a "Compose" window, where the user may review, add comments, etc., before clicking on Send); and those that simply go, without intervening user review.

In the first category, there has always been built-in potential for your emails to be formatted according to preference. In other words, you may pick the wanted font, setup for a specialized "signature" at the bottom, etc. (the capacity is automatically built-in, because its programmed into the email compose window that's opened for user review). This has not been the case, however, for non-reviewed-first emails. Whether sent via the Windows Mail Client (old method) or via the Rossware-Direct method, these emails have sported plain-text only, and no signature. We simply had not created technology that allowed otherwise in that context. Indeed, when we recently added the ability to include a "signature" when working via the Rossware-Direct method, application involved review-first emails only: not direct-sent items.

Now we have added such customization options to the direct-sent (i.e., non-reviewed-first) context -- at least assuming you use the Rossware-Direct (as opposed to the Windows Mail Client) method.

It can mean a significant difference in the quality of imagery as presented to your customer.

We have even included options that allow you to specify different "signatures" for different kinds of emails -- so that, in other words, the signature that's used for a particular context can be highly customized to that context. It allows you huge flexibility.

In such regard, one of the factors that drove us to make this improvement was a user (not to mention any names, but it was Tanner Andrews) explaining how he wanted to do things, within his email "signature," such as advertising specials, inviting customers to go to his website to purchase accessories, or to answer a survey, etc. Even, potentially, including coupons for future service. Of course, to fulfill so ambitious a strategy the signatures need to be selectable for context, so that is exactly what we've setup the system to allow.

In particular, with this release ServiceDesk itself is configured to accommodate two different "signatures," depending on context, and SD-MobileLink (with simultaneous release) three added signature contexts (SD-CyberLink has not yet received the improvement). Details are in the (also newly-revised) Email-Integration Handbook, available via the reference just provided, or via a linking button within the Email-Setup Window as available from within any applicable Rossware application. (The particular pages there that are most applicable to these enhanced capabilities are 10-13.)

If you're wondering, by the way, why the word "signature" is often placed in quotes here, it's because in the context involved the word does not have its normal meaning. It does not mean your name in cursive (though it might in fact include that). It refers to the entire section that may optionally be inserted/added at bottom of an email. Typically, this section (if added) has your company's logo, website reference, perhaps telephone numbers, etc. Sometimes it has disclaimers, injunctions regarding confidentiality, etc. It can be as big or small, simple or involved, as you want to make it.

As you likely know, all of ServiceDesk's operative appointment info is stored in what we call the ScheduleList. Two interfaces are used to directly view and manipulate this data. One, the (F6) "ScheduleList form," is textual in orientation. The other, the (F5) DispatchMap, is more graphical, and offers several kinds of manipulation not available within the first. Regardless, either may be used to achieve a variety of appointment-editing results. And, no matter which is used, it's the exact same underlying data (i.e., from within that ScheduleList file) that's being accessed and managed.

A number of other forms have links to those two specific ones, as needed to conveniently invoke various of their management functions. From a Callsheet, for example, you may right-click on an address to view its location within the DispatchMap, and may then setup a new appointment from there (this is called the "ItemLocate" feature). You may do the same from a current JobRecord. Also from a current JobRecord (F7), you may invoke it's "scheduling" option This provides a link to an underlying appointment (if any) as loaded for you within the ScheduleList form. There you may easily edit it, or create a new one.

What's been lacking (until now) is a similar from-the-JobRecord link to an already pending appointment as-loaded-within the DispatchMap.

In other words, suppose you're looking at a JobRecord in the F7 form; it has a pending appointment; and you decide you want to see (or do something to) that appointment -- not within the ScheduleList form, but within the DispatchMap. (Perhaps you want to see it because you want to check-off that the customer confirmed, for example, which is not a function the ScheduleList form is setup for.) Until now, there was no direct method for that. Instead, you had to independently open the DispatchMap (i.e., hit F5), page to the day of the appointment, pan to the needed TechList area, then eyeball-search to find the appointment's reference.

The control we are using to invoke this new link, within the JobRecords form, is its Appointment box.

Prior to now, that box had just one operative function, and it was superfluous (exactly the same as when you click on the form's dedicated "Scheduling" button). Why have we had two different objects on this form produce the same result? If interested, please read here:

Regardless, the JobRecord's Appointment box now has a real (and not merely duplicative of another button) function: it's to serve as a link to the underlying appointment in the DispatchMap (it's something of a mirror, in other words, of the Link-to-appointment-within-the-ScheduleList-form function that's been there, now, for years).

1. For simple such linking, do a right-click in the box. ServiceDesk will find the underlying appointment (on whatever day it happens to fall), and display it in the DispatchMap for you.

2. If the action you want in the DispatchMap is one of changing the appointment's check-off status (e.g., checking off that the customer confirmed, or anything similar), do a Shift-Click in the appointment box. This is the same action you'd do, if already within the DispatchMap, for the same result there.

3. If you want to invoke the DispatchMap's "Dispatching Options" list (i.e., as specifically connected with the appointment, but without going to the Map first), do a Ctrl/Alt-Right/Click in the appointment box. Again, this is the same action as is involved for the same result, if done within the DispatchMap itself and clicking directly on the appointment reference there.

So, those are the new "Link" functions as now available on the F7 form's appointment box. If you float your mousepointer over the box, there is a ToolTip to remind you. Please enjoy.

Since release of Ver. 4.3.76 some three years back, ServiceDesk has had the ability to integrate with Microsoft's MapPoint to optimize the sequence of jobs within a route, and to simply load/open that route within MapPoint. Those are great features, though with one significant negative: most folks don't already own MapPoint, and it's somewhat pricey to obtain. It wasn't so bad three years ago, when typically you could buy the program once (typically about $300) and install on as many computers as you wanted, but since then Microsoft tightened the internal mechanisms as designed to force you into buying added licenses.

In the meantime, Microsoft's main competitor and threat, Google, has continued to improve its online (and free) mapping system, called GoogleMaps, and we decided it was time to integrate with it. In fact, we already added such integration into SD-Mobile (so, with a single button click from their mobile apps, your techs can open their entire routes into GoogleMaps), with result that a webpage such as the following shows, and within but a second or so:

A longstanding feature in the DispatchMap is the ability to export the tech's route (essentially the list of addresses he is expected to visit) to a file. This file may be plugged into any mapping program or even into a GPS system that's setup for such import.

Another longstanding feature (associated with the above-described MapPoint integration) is the ability to add beginning and ending waypoints to a route, consisting (at the user's option) of either, in each instance, the office location or the tech's home. This makes it so such routing features may accommodate the full route, starting at whichever location he actually begins at, and terminating at whichever he actually ends at.

With this release, your specification of these add-on beginning and ending waypoints (sometimes I simply call them "end nodes") is no longer limited to MapPoint integration. The specification interface is separated from those specific actions, made independent, and now what you specify there will apply not merely to the MapPoint integration, but also to what's loaded into GoogleMaps (if/when you use that option) and to what's exported to the above-described file.

Another improvement, in regard to what's stuck into an exported file or loaded into MapPoint or GoogleMaps, is if the underlying job is specified as a ShopJob, it will be the office address that's used, and not the consumer's.

It was impossible for us to add all of the above-described improvements without altering some of the corresponding access methods, as involved in the DispatchMap. Here are changes as made in the DispatchMap's CheatSheet (accessed by right-clicking in any otherwise inoperative DispatchMap space):

The Dispatch-Options menu (as arises when you click on a tech's name at the top of his roster of jobs) is also changed

Instead of explicitly describing here which commands have changed, we urge you please to just examine the above illustrations.

It's a nice acronym for turn-around-time. It's the quantity of days between when you receive a job order and when you complete the job. The shorter your average TAT, obviously, the better. This is particularly true if you have one or more large clients that score you on TAT, and dispatch more jobs to you when your TAT is tiny.

This new feature is about helping you trim your TAT to the very smallest possible size. Rather than telling you more here, we'll simply suggest you read the micro-manual we also created to acquaint you with this feature. There's a button on which you can click, for this micro-manual, from within the (Shift-F7) JobsPerusal form:

The new feature (announced three releases back) that exposes within the DispatchMap when an "appointment" is connected to a ShopJob ended up being a little less than perfect. I won't bore you with details explaining why, but the bottom line is that a number of users ended up with a number appointments in the DispatchMap claiming to be ShopJobs, when in fact they were not.

More importantly, there is also now better integration with SD-Mobile (also requires updates in SD-Mobile and SD-MobileLink). It will now be very visible to the tech using Mobile if a particular appointment is setup as a ShopJob (no more mistakenly driving to the customer's location).

In the SB-DispatchLink program, for a long time, we've been capturing a maximum of two phone numbers, and no email address. It's all we could get, based on the fact ServiceBench's communication protocol did not provide more. Or, rather, their old protocol did not. A while back, however, they came out with a new protocol that added several fields not formerly available (among them, a third telephone number and email address). We needed to re-program the SB-DispatchLink program to use this new protocol. With SB-DispatchLink Ver. 4.5.0, that is done. If the dispatch from ServiceBench has a third telephone number and/or email address (and assuming you've appropriately updated), those will now be plugged in for you.

In regard to work that comes from NEW (and if you're a servicer who does such work), we were formerly handicapped (with that old communication protocol) in regard to our ability to get some extra fields that are "kind-of" needed for NEW claims. Owing to the absence of those fields, NEW claims have involved some extra work for users. Yes, as core philosophy we hate extra work, and are very sorry you had to endure that.

Anyway, the good news is that Ver. 4.5.0 of SB-DispatchLink (using that new communication protocol) is now able to grab the extra fields as needed for NEW claims. It puts these in the ExtraNotes section of the Callsheet it creates. They get transferred from there to the JobRecord when you make one, and when ServiceDesk fills-in the on-screen NARDA for you (preparatory to transmitting a claim), they'll be placed into its needed boxes, such that when you transmit, everything needed should go appropriately to its needed place, just as with claims to OEMs.

In other words (if you did not get the above), there is now no need for you to separately obtain NEW's AuthoNumber, or to re-arrange how any of the NEW-specific fields are setup for you. In fact, it's important that you do not re-arrange them. Leave them just as inserted by the SB-DispatchLink program. Based on that precise arrangement, ServiceDesk's insertion to the on-screen NARDA will be just as it needs to be (in regard to those particular elements, at least) for a successful claim.

If you're a SB-DispatchLink user, please assure you update to 4.5.0 (or newer if present when you get there). Dispatches as received via pre-4.5.0 versions will not grab the extra data, as needed for fully-automated NEW claims.

1. SBDL places NEW's CRM/SR # and its Authorization # (embedded within what is esentially narrative text) into the ExtraNotes section of the underlying Callsheet (from whence, of course, it gets transferred to the JobRecord).

2. When SD auto-fills the on-screen NARDA from such a job, it extracts those two numbers (i.e., from the underlying ExtraNotes, and inserts, respectively, into the NARDA's Contract/Service Agreement Number and Special Authorization # fields.

3. Those boxes, in turn (and upon transmitting a claim), insert into SB's Service Agreement Number and Authorization Number fields

4. At the SB end, those two claims-transmission pockets get translated as needed right back into NEW.

The form that manages our UnitInfoSheets (Shift-F12) has long had facility for editing the dropdown lists of item Types, Makes and Selling Dealer. In other words, you may add new listings, change existing ones, or delete existing ones. Typically, that last operation requires a little more than just requesting deletion, because often the item you want to delete already has underlying data sheets claiming it as their applicable Type, Make or Dealer. The system can't permit you to simply delete it, because then any such "sheets" would be missing their references. So, the system formerly put you through a clumsy dialog, instructing you to pick the substitute listing that any such prior dependencies would be switched to. This release fixes the "clumsiness" in that dialog, making the process much more obvious, and with fewer intruding message boxes:

We recently encountered a client who had a very weird problem in his network that severely impacted ServiceDesk performance.

In terms of symptoms, throughout the day users would frequently see the infamous "pink screen" (the one that announces ServiceDesk is waiting to access a file). And, there were often significant other pauses in performance. Bottom line, with these issues, is that one or more stations in the network were lagging for significant periods as they opened and closed files. To help isolate which stations were causing the issue (at least as applicable to the condition as was occurring in this client's network), we developed a diagnostic tool. It proved to be so definitively helpful, we decided to improve it's interface, and incorporate it directly into ServiceDesk:

If you're running with multiple stations and think there's even a chance you may be subject to a similar network issue, we suggest you run this test at each station -- and, in particular, read the document as available via its "About this test" button.

Mary at Landers' Appliance said their operation needed more fine-tuned control on password protections within the SD-Dealer program (prior design had all password requests demanding the Master password). Within ServiceDesk's "Security" form (Shift-F11), you may find three new listings:

The effect of what you do with those, of course, is felt within the Dealer program itself, and you'll need to update it as well (Ver. 1.0.37) to experience the improvement there.

If you do not know, this is our utility (abbreviated as "EDR") for automating reception of dispatches that are received by email. This morning we release Ver. 4.5.0 of that utility, featuring these major improvements:

If you've been reading here, you know that, since introducing our new, direct-mail option, we've gradually increased the scope of Rossware office applications that offer it. Just a month or so ago, we filled-in the roster to include all such applications that send mail. This left out our EDR, for its use of emails is not sending; it's receiving, and that's a very different function.

Regardless, we have now added the direct-mail option there. We think, in fact, it will be particularly useful there, because integration with the standard Windows Mail Client, for receiving purposes, has become increasingly problematic in recent years. Our direct-mail agent promises, in contrast, to be completely problem- and hassle-free.

If you're an EDR user, we strongly urge you to update, and switch to use of the direct-mail agent. There are some particular things you need to know about the transition. They are covered in a newly-added section of the Rossware Email-Users Handbook. Look for Section F in Chapter 3, beginning at the bottom of Page 12.

The heading speaks pretty much for itself. FYI, the roster of dispatch formats the EDR is prepared to parse now include: Custom Answering Service format, American Home Shield, National Electronic Warranty, Fidelity National Home Warranty, Old Republic, PC Richard and (with this release) Warrantech. The latter is also offered (with this release of ServiceDesk) in the QuickEntryTemplate's list of company Types (something you'll need for perfect integration with Warrantech dispatches via the EDR).

One of the improvements announced in the last-prior release concerned a new underlying log the system maintains. Its a log that typically you'd have no interaction with. But if, after the fact, you wanted to do some investigation seeking to determine who looked up (or changed) part numbers as involved in special-order parts, it's there for you. In announcing that feature, I volunteered that, having built the machinery for that log, it would be relatively easy for us to add logs into other processes, and I invited requests.

We have now added a second underlying log. This one will have entries indicating changes as made in the SalesJournal, FundsJournal and A/R records. As with the log prior announced, there is one file where entries as made during the course of a day get entered, and then a long-term file. For this new log, the files are called SlsAndFndsEdits.txt and SlsAndFndsEdits_Archv.txt, respectively.

Since it appears we're going to end up with a whole set of such log files, we also deemed it best to make, and start placing them into, their own folder. Thus, instead of using the common \sd\netdata folder; henceforth, these files will be placed (and used within) a new subfolder called \sd\LogFiles. Please look for them there.

Not far back (see Ver. 4.3.62 entry from 4/18/10) we vastly improved our method for designating those particular jobs that involve in-shop (as opposed to in-field) work. Since then, we've made occasional additions to the operations where ServiceDesk appropriately distinguishes between ShopJobs versus not. This is a related such improvement.

Specifically, someone pointed out that you should be able to readily distinguish, within the DispatchMap, between references to appointments that involve in-shop work, versus those that do not. And, if you're wondering, yes, many operations do schedule in-shop work. For those operations that lack a dedicated, in-shop technician, it's often found that scheduling the work is the only way to get it done.

Based on this improvement, you'll now see ready visual, within-DispatchMap distinctions, as per above.

We heard from a particular client they'd just lost a a thousand bucks based on having ordered a wrong part (someone looked up the part number wrong, and the item was not returnable) from Viking.

Understandably, this client wanted the ability to determine precisely who had actually done the lookup on the part number, and who may have edited it thereafter (if, in fact, anyone had). As all seasoned users know, a wide variety of events are automatically documented in the narrative history as applicable to any underlying JobRecord. The kind of event as we're discussing here could, in theory, also be placed there, but as a matter of general strategy we want maintain that narrative in a form that reads well (and easily) as a broad overview of major events, and without so much excessive detail as to defeat that as its purpose. Thus, we needed such historical documentation elsewhere.

Enter the "Log" file. From this release forward, ServiceDesk will write to a file (called PartsProcessWorkLog.txt and located in the \sd\netdata folder on your server) each time any user creates or edits a part number in the PartsProcess system. Each entry will indicate the operator involved, date and time of the event, and precisely what the operator did. At the conclusion of each day, entries in this file will be moved to a more permanent file (PartsProcessWorkLog_Archv.txt, also located in the same \sd\netdata folder on your server).

Based on the above, if you need to find out after the fact who specifically is responsible for having provided (or changed) particular part numbers that were involved in the PartsProcess system, you should be able to easily determine the answer by looking in one of the above-described files (the first one if you're looking for actions that occurred in the current day, the second if looking for actions more in the past).

Having created the machinery for this particular log, we invite you to let us know of operational areas where you think there'd be a significant reward for creating similar logs. The way we've structured the machinery, there is almost zero overhead involved, as cost in such logging efforts.

"Default-To-Definite" (on Appointment-Assignments) Now Available on a Per-Tech Basis:

This addition was prompted by a call from JD at Guinco Service in Texas. That operation has some techs working in remote regions, and as JD in the office pre-screens jobs he'll often order parts before the tech ever goes out. Pointedly, he has the vendor ship said parts directly to the particular tech -- a factor that, obviously, makes it rather important that when an appointment is created for that tech, its assignment status be set as "Definite," as opposed to "Tentative."

To accommodate this kind of need, you'll now see a new settings area within any tech's Profile sheet, as displays when you click on his name within the TechRoster section of the Settings form:

At least with benefit of description as above-provided, I believe meanings in these new options are obvious. The default selection ("never") leaves functions the same as always. It's only be selecting another option that you'll notice any change in operation.

In the title of this entry, you'll notice, when referring to this new default-setting option, we're ballyhooing the fact it can be done on a "per-tech" basis. The reason for this specific "ballyhoo" is because (and we need to explain it here for full context), a couple of years back (see Ver. 4.3.40 entry from 12/10/09, below) we added on option where, from the Create-Job/Sale form, you can change the default as applies in all instances (i.e., across-the-board). That old (much more of a "blunt knife") option still persists. And it's true, obviously, that If you did have your default set to "Definite" via that old/broad method, any new-option setting via individual techs would be superfluous.

Credit for this one goes to Krystle at Folsom Lake Appliance, in California. Krystle was sometimes getting email replies from customers, triggered by them (and generally containing specific inquiries) on the basis of emailed tickets as generated via SD-Mobile. The replies did not contain the originally attached ticket, and it's that ticket (in the context of these emails) that would contain information disclosing who the customer is. Absent knowing who the inquiring customer was, it was difficult for Krystle to respond. Indeed, her only basis for identification in this context was the customer's email address.

In regard to such email addresses, ServiceDesk of course has fields to track them very nicely. However, it's often the case that you do not have the customer's email address prior to sending the tech out. In such a case (and assuming he's using SD-Mobile, and using e-tickets within SD-Mobile), he will acquire the customer's email address in-the-field, as a pre-requisite to sending the e-ticket. This email is then automatically inserted back into the JobRecord, via operations of the SD-MobileLink program.

So, in theory, when Krystle receives the customer's email reply, she should be able to find the JobRecord in ServiceDesk that contains the sender's email address. That will then be the correct customer. Problem is, though email addresses have in general been fully searchable in ServiceDesk, the ability has depended solely on the CstmrDbase Index set, which is typically updated once each night. Thus, if the email had just barely/same-day been obtained (via the tech's getting it for sake of sending the e-ticket), that email address would not yet be discoverable via the long-standing search method. That's why we added a new option to the record-by-record searches, as offered from within the F7 form:

As intimated, this new item is one of the set of searches that does not depend on the once-per-night-updated Index set, and thus it can locate an applicable JobRecord on basis of email address even if that address was only added in the current day. In regard to all these searches, please always bear in mind that you are permitted to type only a portion of the search target. Often we see people thinking they have to type the entire thing. That's too much work.

As is the case with most every release, this one too contains improvements you should manage to enjoy without needing to first learn of their existence, via reading here. In general, we don't announce such matters here, as there is little need. But some matters are almost the opposite, in that you might think something is wrong, absent an explanation here. One is as suggested by Adam at Fred's Appliance. As you open a current JobRecord, the history box will now automatically scroll down (if needed) to show the bottom/most-recent entries. Please don't think this is a malfunction. It is intended.

Yes, this one gets a much bigger announcement-heading than most, because it truly is BIG NEWS.

It was some four years ago when we introduced our CyberOffice suite of functions, which involve Rossware-provided plug-in interfaces for your website, combined in several instances with emailed hotlinks. From almost the get-go, we envisioned six core elements in the system: (1) initial online booking of jobs by a customers who browse to your website; (2) online scheduling of first visit on basis of hotlink-equipped email (e.g., you get an order from a third-party for the service and email the location-party with a hotlink to schedule); (3) re-booking appointments after parts arrive; (4) confirming appointments on the day or evening prior; (5) online job-status checking by customers; and (6) online technician tracking by customers.

Scenarios 1 through 4 (as above-listed) were working with our very first roll-out of CyberOffice. We'd intended to add scenarios 5 and 6 soon after, but complications with our online programmer and other priorities intervened. Of course, we did not forget -- and, though later than expected, we are now very pleased and proud to announce that our full CyberOffice vision is now deployed and ready for your use, enjoyment and profit. Scenarios 5 and 6 have been added, and they are beautiful.

In fact, Job-Status checking has been available for about two months, and we have just now opened Tech-Tracking to general use. Here is a comment received after our first beta user had been using the feature for just four days:

"Glade, we started using the technician tracking tool this week and we already have had 119 people visit this page!!! We have also had several compliments from customers who have used this tool. I figured you might like to hear."

Yes, I indeed do love to hear such good news, and I encourage the rest of you to make haste in the effort to likewise benefit via the implementation of these great new features.

For more detailed information, we invite you to consult resources. The first is our CyberOffice Handbook. Second (especially if you are not already familiar with kinds of interfaces that CyberOffice offers your customers) is the CyberOffice section on our website.

This particular release of ServiceDesk is especially pertinent to announcing such new capabilities in CyberOffice, by the way, because it includes an internal enhancement to fully accommodate the last fundamental element. Specifically, when emailing the customer with a request to confirm the next day's appointment, it now uploads a couple of added data elements. It's on the basis of these that, when the customer confirms, the SD-CyberLink program is then able to email the customer a follow-up. Essentially, that follow-up says:

"Thank you for confirming . . . and, by the way, if you are curious how your tech is running tomorrow, click on this link [link actually provided in genuine email]. You'll see progress in his route on the way to you."

Of course, the actual list and details will vary according to the actual situation.

Simultaneous with the above-announced release of ServiceDesk, we are also releasing Ver. 4.5.0 of the SD-CyberLink program. Besides itself accommodating the above-described email response when a customer confirms, it also now adds integration with the Rossware-Direct Email Agent.

This is the alternate emailing system that we added several months ago as an option in SD-MobileLink, after that into ServiceDesk itself for non-user-reviewed emails, and just recently (two releases back) we enhanced its implementation to accommodate user-reviewed, compose-window-needed emails.

To review, this facility allows emails to be sent using solely Rossware programming, and without reliance on the Windows mail client. It thereby circumvents all the frustrations that were in some instances associated with using the Windows mail client. Much as in the SD-MobileLink program, the new SD-CyberLink features an "Email Setup" button on which you may click to specify your preference to use the Rossware Direct-Mail-Agent, in preference to the default Windows client.

Based on feedback from those who've switched to using the the direct-mail agent, we can certify it is a great advancement over using the standard Windows mail client.

The inventory system has long offered three methods via which to order stock replenishment. In the F10 form, you may choose to order on the basis of: (1) deficiencies (i.e., where stocked quantities have fallen below planned minimums; (2) recent usage (i.e., simply re-fill based on what was used in a recent/defined period; or (3) simply by picking from the general stock plan the particular items you want to order.

Our new option concerns what is actually an enhancement to the second method. It's designed to fulfill a purpose as revealed by user who does a lot of its work for AHS and NEW, under accounts that require ordering all replacement parts via their own particularly-authorized avenues. To further complicate, this company stocks its trucks very well, and on a high proportion of its jobs (as performed for these clients) the tech uses a part directly from stock. Typically, the particular parts as used from stock was not prior-acquired via the authorized channel for the underlying client -- which means, to effectively acquire payment for the part as used, the company must order its replenishment on that part (i.e., its replenishment back into stock) via the client's particularly authorized channel. This complicates the stock-replenishment scenario vastly, because in general (and until now) it's been designed with the assumption that stock replenishment will be ordered from the vendor who happens at the time to be most "convenient" in terms of pricing and similar factors. Now, regarding particular items as used, replenishment on those particular items must come from particular vendors, and with the order including, too, provision of the underlying client's SWO Number as attached to job on which the prior part was used.

In sum, this client has a need -- in regard to re-stocking inventory -- making a situation that very much resembles special-ordering parts, yet the situation nevertheless involves replenishing stocked inventory, and its after job-completion, rather than during the course of it. In a nutshell, it's a "hybrid" situation: not quite special-order parts, and not just stock inventory, either.

Our solution of the moment is what this new feature is about. Again, it's an enhancement on the prior-existing method for ordering stock replenishment on the basis of items recently used. If you select that option in the F10 form now (i.e., after this update; the series of keystroke-shortcuts to get there is F10, "O", then "R"), you'll see a new sub-option:

While the prior sub-options are designed to print or fax an order request for your vendor, the new one (as its wording implies) creates a file that may be opened in a spreadsheet, and this contains added fields that allow you to see who was the HighVolumeClient (if any) in regard to the prior parts as used, and as connected with each item that now needs ordered for re-stock. Plus there is a fields for the applicable client's SWO Number on the job where used, and for which tech used the part (and hence, presumably needs re-stocked). Our thinking is you can use the spreadsheet to determine which parts you have to go through AHS to replenish, which you must go through NEW, etc. The additional information allows you to frame your orders with needed underlying SWO Numbers, etc. We think, with creative use of the spreadsheet machinery (particularly if you're a bit adept in using Excel or similar), you can likely make this work very well.

Many readers know that, historically, Rossware systems have "farmed-out" email functions. Rather than handling them directly in other words, they've "called" on Windows to perform wanted email tasks. Windows, in turn, calls on whatever email program is installed and setup as default, if any.

This is precisely how Microsoft has long intended that applications should manage their email-related functions, and in general it works, albeit with occasional frustrations as encountered within particular installations (in other words, you may or may not be fine with that scheme, depending on your setup).

In the effort to once and for all overcome all potential obstacles, last year we introduced a direct-send option. When using this method, Rossware systems perform email tasks directly, using their own mechanisms, and without calling on the Windows Mail Client in any manner. It was first introduced in the SD-MobileLink program, then added to ServiceDesk itself with Rel. 4.4.93 (you may search below to find that release announcement).

At that point, however, there was a limitation. The direct-send method only worked for emails that were sent-off for you directly, behind-the-scenes, and without user-first review. In other words, it did not work for those emails that ServiceDesk opens for you first, in a compose Window, for you to review, perhaps add your own text, and then send. This limitation was because we simply had no compose window of our own, and thus had to refer you to the Windows Mail Client, for use of its compose window.

We have now created our own, ServiceDesk Compose-Email Window, which will be applicable if you opt in the Email Setup form to use the Direct method. Here is what it looks like:

With this addition, you can now totally abandon use of the Windows Mail Client for all emailing as associated with ServiceDesk. It's quite flexible. You can even include electronic signatures. All details are in an also-revised Email Handbook, accessible via button from within ServiceDesk's Email Setup form, or from this link.

A Series of Improvements in the New "PartsPick" On-Screen Management Window:

You might notice there have been five releases since the last prior (just below) announcement here. These have included been many small, incremental improvements (and in multiple areas). In particular regard to the new PartsPick interface, experience disclosed certain initial weaknesses (in particular, circumstances where the system might have indicated a potential need for a part to be returned by a tech, but did not), that have now each been addressed. Additionally, Adam Butcher pointed out that it would be nice to see the Bin/Hold Location of a part, right within the interface. That now occurs. Assuming such a field is applicable, as you float your mousepointer over any parts-listed item,

For those of you who attended Glade Ross's class at the ASTI convention, this is the feature Steve Merriam has been seeking for three long years (the one in connection with which he told the class: "Don't hold your breath!").

I do apologize, Steve (and likewise to everyone else who should have been enjoying the benefits of this kind of tool) that it's taken so long. I have two excuses. First, it really was a very large project. Second, it truly needed as foundation the kind of improvements I've made, in underlying structure, during the past half year or so (see the many, many entries below regarding that series of improvements).

This new interface can be accessed via the Main Menu (under the Parts Management heading), as follows:

Or, as you can see via the menu-item listing itself, the QuickKey shortcut is Ctrl-Shift/F8.

The basic idea in this new interface is it gives you a single location to see all parts that need assembled for going out with a particular tech for a particular day's work, and to indicate by simple clicking action if in fact you're moving each such item from office to the tech. It further provides a basis, within the same interface, to see what should be coming back from the tech, and to likewise indicate via single click if in fact such items came back.

We believe that overall this brand new interface is a huge -- nea massive -- improvement over what SD systems prior afforded in regard to these particular processes. In fact, we likely should increase the cost of our support in exchange for bringing such a huge improvement to you. Nah. Just kidding.

Seriously, there's a real and serious reason why Steve Merriam has campaigned so assiduously for this feature. He had the vision, way back, realizing what a value it could have. And, now, his vision is realized. Please be sure you take advantage of it.

To use the new interface -- we think -- will be fairly self-explanatory. There are a plethora of tooltips within it, if you just float your mousepointer over various objects (we urge you to do this, as you'll learn things as you do). There are links and cross-links to virtually anything your heart might desire. I'll shortly be adding a section in the manual describing more specifically how all the details work, but I'll bet most of you can figure it out regardless. I'll place a new entry here indicating when the manual revision is ready.

A couple of months ago, we introduced mechanisms via which techs are required, if they do not end up using a special-ordered part, to indicate the specific reason why not (see, e.g., notes accompanying Rel. 4.4.88). With that new element of data having since been in a state of being constantly generated, a few users got to thinking they'd like to see an at-a-glance, across the board analysis of which techs were ordering parts without using them, at what rates for each, and for what reasons.

Much like its cousin, the Usage Analysis report, this new report is accessed from the archived-PartsProcess form (Ctrl-F8):

Simply pick the new option, follow the prompts, and in a moment you'll be looking at the new analysis.

One note: Just like the Sales Tax Liability Report as just-prior-to-this introduced, this one also requires Excel or similar spreadsheet program for good viewing. Please be sure to open the results within such a viewer.

Another area we've been a little slow with ServiceDesk is in management of sales tax liabilities. This likely stems from the fact that in SD's germinating office there was but a single tax jurisdiction (and corresponding single tax-rate scheme) to worry about. For this, a simple SD-management structure was totally adequate. Most other users have not had it so easy. For the sake of our very first new users, we made an option where, in the Settings form, you can indicate that you have varying rates depending on location, but until Rel. 4.4.5 there was no provision for you to explicitly inform ServiceDesk as to what rate existed in each particular locale (instead, ServiceDesk simply relied on the amounts as filled in to any ticket by the tech at the location).

That provision -- for jurisdiction specific rates -- was added just over two years ago. However, we left a significant hole. While ServiceDesk could now know the rate that should properly apply depending on job location, it did not give you any kind of compiled report informing you of what your accrued liabilities were for each jurisdiction. Instead, the interim expectation was that you'd export the underlying and nearly raw data (via Sales Summary add-on in the F11 form), then manipulate in a spreadsheet to self-calculate your various liabilities.

Specifically, if you first run a Sales Summary report in the F11 form (for any period of interest), then click on its "Export with Extended Data" button, you'll see the options as then presented have gone . . .

The newly-added option will create a compiled report detailing your total tax obligations in each jurisdiction (as per specification in your TaxRatesFile, which is the provision we added a couple of years ago). For instructions on how that file is setup, you can click on the little button as provided in your Settings form:

The compiled report is too big to illustrate here. But we think you'll like it. One thing you'll notice is that, unlike all our other compiled reports, this one is deliberately made to display within a spreadsheet program, such as Excel or similar. If you attempt to display it otherwise, you're not likely to get good results.

Another note: though the compiled report is designed to give you segregated liabilities among multiple jurisdictions, even a company that reports to a single jurisdiction might find it useful. If yours is such an operation and you'd like to try the report, you'll need to create that TaxRatesFile first. Just because you have but a single jurisdiction, doesn't mean you cannot create the file regardless.

All Moderate-Level Requests Fulfilled (as per List of Items Requested in My ASTI Class):

Last Tuesday in San Diego, we had a fantastic set of three classes at the United Servicer's Association annual convention (aka the Appliance Service Training Institute, or ASTI). In my own class (and as is now tradition), discussion brought out the need for a number of improvements. Michael Basich (of Michaelson's Appliance Repair of Tampa) kindly tallied 16 such requests, and emailed me the list. Though I only got back on Friday afternoon, I've already mostly killed the list. Here is my general report:

Out of 16 items tallied, 4 involved supplementary products rather than ServiceDesk (and I still must get to those). One involves a very large project I intend to conquer soon. Two were for fixes that, upon going to address, I found ServiceDesk was already behaving exactly in the manner requested (read near bottom of this entry for details on those). This leaves nine items, total, that I was able to conquer this weekend, as now available in this (Monday morning's) release:

In the class, I always show-off new features as added since the prior class a year earlier. When I showed the new DTR-Viewer (see entry as pertaining to Rel. 4.4.68), someone pointed out that the Viewer works only for TimeCards as compiled by a tech working in SD-Mobile, and not for someone that does his TimeCard punches via ServiceDesk itself. I'd not intended such a limitation when I created the feature, and was surprised by the report. On review, I found the Viewer's disability in regard to within-ServiceDesk created TimeCards was the unintended consequence of a coding variation, which has now been addressed.

2. Auto-Add to JobRecord Historical Narratives When User Changes Tech Assigned to Appointment:

Suppose you're in the DispatchMap and change the tech assigned to an appointment. I've never thought this kind of event should be automatically documented to the JobRecord's history, because to me it's not particularly significant as concerns performance on the job. But many have asked for it, and in the class I was persuaded to at least make it an option. So now, if you go to your Settings form (Ctrl-F11), you'll see a new checkbox where you can set to activate this new offering:

Obviously, if you go to your Settings form and check that new option, you should see these new historical narratives added, any time someone changes the tech as assigned to an appointment.

We also discussed the DispatchMap's auto-popup feature, as added with Rel. 4.4.53. During discussion it was agreed the popup would be better if moved to the right of the underlying text:

I was surprised to learn that, somehow, I'd evidently neglected add an option to enable the above-indicated protection. It's there now. Just open your Security-Actions form (Shift-F11), and click on the Actions radio button. If you sort on the Action/Process column, you'll see there already were, in fact, several categories of optional protection as applicable to the MasterPartsPlan, but only now (with addition of the highlighted item below) is there one to optionally protect against editing, there, in general.

You'll need to toggle the password protection on this item to True, if you want it to take effect (default is False).

5. Prevent ServiceDesk from Emailing an Appointment Confirmation Reminder When the Underlying Item is Designated as a ShopJob:

6. Allow for Deletion of Daughter Bands as Added to Archived-PartsProcess Records:

For obvious reasons, I'm always reluctant to change QuickKey or Mouse action users have become accustomed to. However, since adding the SD-Rolodex feature about a year ago, I've often felt it deserves its own direct F-Key access (i.e., without combination with a modifier key). For a form that a user wants to so frequently bring up, Shift-F3 (the action to-date) seemed way too difficult. At the same time, I did not think the SalesViewer form needed access all that often, and so did not think it really deserved F4 sweet spot it's always (until this date) enjoyed. Given the above, I put it to the class, asking how they'd feel if I swapped the two. They voted in favor, so now it's a reality. F4 gives you the SD-Rolodex. Shift-F3 gives you the SalesViewer form.

SDRB stands for SD-RevenueBuilder. If you do not know, it's a supplemental program designed to assist you in managing your own service contracts and/or maintenance agreements, and to integrate with ServiceDesk while doing so. More than a year ago, someone mentioned that a tech in the SD-Mobile should have a visual indicator if the property that he's working at is subject to an SDRB account. We added a visual indicator there, but for some reason did not think of doing the same within ServiceDesk itself. That oversight has now been corrected. Specifically, any current JobRecord that's subject to a pending SDRB contract at the address in question will show with a visual indicator as follows:

This indicator will appear next to whichever section (Paying-Party or Go-To) as has the matching address. As another benefit, you can simply click on the reference to immediately link to the SDRB account in question.

In the interest of using data space efficiently, ServiceDesk packs JobRecords somewhat tightly when moving them to the Archive. Specifically, for the last two or three years, its been leaving just 250 spaces between each record -- 250 spaces where characters can be added, if, after the record is archived, you find yourself wanting to add new text (in any context aside from AfterNotes, which don't count because they are stored separately). In the class we talked about how sometimes this is less room than needed for some purposes. Since storage space is so much more liberally available today, we decided it was time to be less stingy. Now, JobRecords will be packed to the archive with 500 extra spaces allotted for each.

As mentioned, there were two items in the list that, upon going to address, I found ServiceDesk was already doing precisely as requested. At least, it sure did so far as my testing is concerned. It's possible users have found contexts where it's otherwise, and I describe the items here so that, if so, hopefully such users can tell me how to replicate whatever failure they are experiencing:

With release of Ver. 4.4.72 we added a new Profitability Report. Someone in the class said the report was including values of parts sales as conducted across-the-counter -- which would not make good sense, since the report is intended to analyze profitability of service operations. On reviewing, though, I found my program code was already very deliberately written to exclude POS transactions. If anyone truly encounters any experience to suggest otherwise, please let me know.

11. When Scheduling a ShopJob, There Should be No Dialog Complaining about Absence of Grid Coordinates:

Someone said they got this dialog. I found my program code specifically designed to prevent its occurrence in the ShopJob situation, and my tests show it working. Again, if you can find a scenario where it's otherwise, please let me know.

To remind, there were 16 items from the class total. Another four (work still pending) involve programs other than ServiceDesk. The remaining one is a big project, one which I happen to have actually been working toward for three years now. I'm hoping to have it out soon.

In its standard default mode, ServiceDesk assumes each tech as listed in its TechRoster is an inventory location (or, more properly, that he drives a truck that's an inventory location). For a good share of companies, this assumption works great. For those companies where the assumption fails, we have long had an option whereby you can turn off that default by instead explicitly listing your inventory locations.

That's the background for our new feature. It arose when we got a call from a new client whose techs (or, rather, some of them) own and use their own inventory. When items are used by these techs, it's the office's duty to "reimburse" them by replacing the part they've used. But the office is not otherwise tracking what's on these techs' trucks, so how can it easily manage this replacement process?

My first answer was to suggest using the re-stock method (in the F10 InventoryControl form) that reviews usages and generates a re-stock list on that basis (i.e., rather than comparing remaining stock to minimums, as is the more typical method). But there was a catch. If the tech attempts to indicate he used a part from stock, and if the system doesn't recognize he has the part (because, obviously, it's not tracking his inventory as all), it's going to balk at the claimed usage. Moreover, if you'll actually be pulling from the office to replace what the tech used, that's from whence the indicated usage must come (so that, in other words, there's an appropriate reduction of stock there).

We have accommodated the above-expressed need via a new option, as below indicated, in the (Ctrl-F1) Settings form:

If you check that box for a particular tech, ServiceDesk then knows to NOT treat him as an inventory location. This works independently of the feature that allows you to explicitly list locations, and in response to the setting here, if in a PVR a tech claims to have used a part from inventory, the system will assume it was actually office inventory he used, rather than seeking to find it within his own (non-existing) inventory.

Behind the scenes (and for the above-described scenario) ServiceDesk will actually be making two simultaneous entries in the Journal of Inventory Movements. One moves the item from the Office inventory to the tech in question. The other, instantaneously thereafter, moves it from the tech to sale on the job in question.

While instigated by that new client (and to accommodate the need to replace parts as used by technicians who carry their own inventory), this solution should also be effective for shop techs -- who typically do not have their own inventory and are regularly pulling from office stock regardless. Either way, we think you'll find it a great solution.

BTW, the MobileLink program has also been modified to recognize and appropriately respond to this new option (so that tech's working via the Mobile interface, and designated as having no inventory, can likewise benefit). You will need to be updated to Ver. 1.4.46 of MobileLink to have the benefit there.

For quite a long while we've had a report in the archived-JobRecords form that's designed to provide you with analysis and data regarding your frequency of use for all parts, both stocking and special order. Turns out some folks have wanted to do some kinds of analysis that do not exist in the report directly, and wanted more item-by-item type raw data than the existing report provided. So, we created a new option:

When a little while back we improved the method of displaying search results in this context (making the interface more one of paging up and down), we produced an unintended downside. Turns out the old and less sophisticated interface had one benefit. If your data set is so large so there's a long delay before the entire file is searched, and if your search target finds matches within the data so infrequently that it takes a significant wait before a page is filled, it turns out you could wait quite a while before seeing any search results.

This release addresses that. Now, the system will show interim search results just as it did before (but with a background color of pink, to make it visually apparent that you're not yet seeing a formatted page). If you see what you're seeking and want to terminate the search, just strike Enter on your keyboard.

You might notice it's been five releases since the last-prior announced one. Sometimes, I go through a stage where I'm very busy making a large series of small, behind-the-scenes improvements, but with none so noticeable to the typical user as to really warrant description here. That's been largely the case during the last 30 days, encompassing the prior four releases.

Several Rossware applications use email (I'm referring to normal, internet/based mail here, rather than to ServiceDesk's internal "SD-Mail" system). Always, Rossware email access has been via what's called the Windows Mail Client -- which is simply the email program you have installed, at the station in question, to manage emails, and which is designated within Windows as its "default" email program.

To put the above another way, Rossware programs have never directly performed email-related tasks. Instead, they hand the task off to Windows, which (in turn) hands it off to the separate email program (e.g., Outlook Express, Outlook, Eudora, etc.) -- if any -- that you have setup for the purpose.

Given the above, if you have not appropriately setup such another program at any particular station, Rossware programs cannot perform email tasks at that station. Even then, there may be issues, because (and for a number of reasons) such other programs may refuse to cooperate as perfectly as wanted.

This release provides a direct bypass around any/all such issues. Now ServiceDesk can perform email tasks directly, without relying on the Windows Mail Client. Or, if you prefer, you may continue in the traditional fashion.

To invoke (or even just explore) the new option, click on File Functions within the ServiceDesk MainMenu, and pick the new menu item now listed there:

This is where you can change from the default email mode (i.e., using the Windows Mail Client) to using the direct method instead. Please also note there is a large button you can click, which opens a handbook that explains greater detail.

1. Added still another search-and-report criteria in our "To-the-Grave" management/monitoring system (as available from the Ctrl-F8 archived-PartsProcess form). This is for items that have been sent back to the vendor, and which are "Past-Due" for credit being received. Since this increased the quantity of such criteria to nine, we also added some categorization to the relevant menu sections, so as to improve ease of review/choice:

2. Improved the new "Manage-Return" daughter-band creation (see #4 in entry for 4.4.89) with the following dialog:

The middle option, from the old, has been replaced with two options in the new. The effect is self-explanatory, if you simply read the text.

3. Reconfigured supplementary filtering, in the archived context, to encompass both the view/search and create-document modes of managing items "to-the-grave"

This one requires some background. As the first item under Rel. 4.4.89, you'll see where we announced "much enhanced filtering." In general, it was much enhanced. However, with the transition to a more modern interface we unwittingly gave up something. In the older methods, you'd typically be typing in your filtering targets. Under the new, we only made ability for you to pick from dropdowns (such as, for example, illustrated under item #3 above). This robbed you of the flexibility that's involved in entering a target that does not exist in the dropdown. That's fixed with this release. If you want a target that's not in the dropdown, just type it into the dropdown box.

I'm sure we'll get though this series of improvements some day, but it turns out we're not actually done yet. The latest improvement involves how ServiceDesk presents search results in the archived PartsProcess form (Ctrl-F8). Since it's showing you search results, and since the search direction has historically been programmed to begin at the bottom/most-recent position in the data, the traditional method of presentation has been as follows:

As the system reads in the file and finds each match to your search target, it displays the first match at top of the form. The second match displays in the next line position, and so on, until a page of matches is filled (assuming there are enough matches to fill a page or more). At that point the search pauses, giving you a chance to examine the page. With press of any key, the search resumes, potentially filling a new page, and so on. This method had several disadvantages if you're doing intensive work in the archive -- in particular, the kind of work that our prior recent improvements have now made practical.

Given that we're now doing serious work in the archive, we realized there is now serious need for a better method of reviewing searched archive results. This release provides that.

Most importantly, you can now use PgUp and PgDn on your keyboard to move up and down within search results (i.e., it's no longer limited to pressing any key for the sake of moving up only).

Additionally, under the old method results were always inverted in comparison to the order items were archived (i.e., newer items were at the top of any display, progressing to older toward the bottom). This was backward from how the items actually fit in the file, and as you progressed to the next page (presenting successively older items), it resulted in repeated inversions between the order in which the pages came and the order of specific items as presented on each page. With the present improvement, each page shows its member items in exactly the correct sequence, regardless of whether the page is reached by perusing in PgUp or PgDn mode.

We recently learned of some particular fields as involved in LG claims that could be better formulated to achieve successful processing. This applies particularly on the CE side. That applicable TranslationTip-ToolTips have been revised to guide you regarding the improved treatments.

We must thank David and Paul Manning, at Sharper Electronics in Portland, for this continuing series of improvements. Their intense need, for perfect and complete PartsProcess management, is what's spurred this flurry of activity. Aside from one added report (to tally reasons why ordered parts ended up not being used), I believe this installment fulfills their needs -- and likely almost anyone else's, as well.

1. We now have much-enhanced secondary filtering of items displayed, in both the current PartsProcess form (F8) and for when reviewing items "not-yet-in-the-grave" via the archived PartsProcess form (Ctrl-F8). To properly accommodate these enhancements, there was a need to totally re-do the menu system as applicable in both contexts. It is, indeed, now much modernized. Here's a comparison in the current context:

The archived context is similarly changed, though in a manner unique to that venue. In lieu of illustrating here, please, just check it live, yourself.

2. Core-return management has been added to the SD-Mobile context. When we first created explicit core-return management back in August, we intended to immediately follow by placing into the Mobile context some corresponding functions. For example, if for any part you've created a core-return daughter band within ServiceDesk, it's logical that if a tech working via Mobile indicates usage on the part, he should immediately be confronted with an extremely strong message informing him that it's a core-return item, and soliciting his affirmation that he has indeed retrieved the old part for return. As it happened, I got sidetracked on other projects and did immediately get this related work done. However, it is done presently.

3. Created a "Resurrection" facility to deal with the situation where you forgot to add a core-return daughter band, and the parent process item was already archived. Just locate the archived item in the archived PartsProcess form (Ctrl-F8), right-click within the right two-thirds of the info-band, then follow the prompts.

4. Created a "New-Daughter-Band-In-Archive" facility to assist in better tracking of steps as taken in managing a needed parts return. The general idea is that you can use the various date boxes, and such, in a manner that parallels what you do in managing a core return (i.e., document when you requested an RMA, when when you shipped, tracking number, precisely when credit was received (and on what invoice number), etc. -- all via an added daughter-band that you add for the purpose. To invoke, begin by using precisely the same click action as described for #3, above, then just follow the menu in an appropriate alternate fashion.

In the last release we made a new category for parts disposition: "RA Rqstd" (see Item 4 in the entry below, from 11/30/10). But we did not make a new search category for it. That oversight is now corrected. In fact, while in the course of of adding that as another search criteria, we overhauled the overall organization as involved in those criteria selections. The sequence now has greater logic and clarity:

Also tweaked a few things as connected with the recent add-ons. Example: a user discovered that the "Returned to Vendor and Awaiting Credit" category improperly included items marked with the new "RA Rqstd" designation. That (among other things) has been finessed.

As another improvement, there is a new dropdown via which office persons can insert reasons why a tech did not use a part (see 10/12/10 entry in the SD-Mobile WorkDiary for explanation of how we there created provision for a tech to explain his reason for non-use).

If you float your mousepointer over the Notes editing box, the Tooltip will inform you of the method to get the new dropdown (just double-click). Once you, do the dropdown appears, and all you must do is select from it.

1. We discovered that if you're doing a search function in the archived-PartsProcess form (Ctrl-F10), and if you tried to PgUp or PgDn after reaching the final page of search results, the system erroneously went into an attempted (but not properly-operational) page-change mode. Fixed.

2. Also in the archived-PartsProcess form (Ctrl-F10), added a new search/selection criteria to the "Review Items Not Disposed Of" category.

More specifically, we took what had been a single category selection (above-left), and split it into two more specific categories (above-right). The above labelling is likely self-explanatory.

3. As another refinement connected with the above-circled category, the system now properly excludes from the result items that are shown as in possession of the office (OF).

4. Added a new category to the that provides potential insertions to the bin-loc/status box.

As is likely obvious, this is used to indicate that you're requested a Return Authorization from your vendor.

5. For Core Returns (current PartsProcess form, F8), added a new display category, as follows:

Again, the function is likely self-explanatory, if you simply look at the above.

6. Also in regard to Core Returns, modified the applicable filtering to prevent the second category (in this listing as above shown) from including items where the tech has not yet used the parent part.

That above-quoted and familiar phrase is from an 18th century poem by Robert Burns. I'm not normally one to like poetry (actually, never), but when I was thinking about the subject of this entry the indicated phrase entered my mind as seeming apt. The notion the phrase evokes, of course, is that, whether you're a mouse or man, you can lay very grand plans, and yet in spite of all determination and hope, they may nevertheless come to naught. I'll get to that actual happenstance (as regards a couple of schemes within ServiceDesk) in a moment, but first, more about the poem.

Probably like you, I had no idea where that "Best-Laid Plans" phrase came from, so I Googled it, and quickly arrived at http://en.wikipedia.org/wiki/To_a_Mouse. It revealed the origin, and provides full text of the short poem (both original and translated into more modern English). I read the modern translation, and, dang, I like it. It's a really cool poem. Check it out.

In the last few months, I've made some major improvements in the PartsProcess system's "To-the-Grave" elements of management. Notably, in such regard:

It turns out that when you add a core-return daughter band to a parent PartsProcess request (pursuing Number 2, above), it prevents the parent from being moved to the archive -- until, of course, the core-return daughter in itself is complete and ready for such movement. This is perfectly fine so far as managing the core is concerned, but throws a wrench into the works of reviewing received items to assure all reach a proper destination (Number 1 above). At least, this is true if you use the new core-return function.

The reason for this frustration is because (and until now) the review-non-fully-disposed-of-items function has been designed to look solely at items in the PartsProcess archive. This formerly made perfect sense, because items received and appropriately priced are automatically moved to the archive, and there they are ready for the indicated type of review. The problem is that the added/new core-return strategy prevents applicable items from being so moved -- for the duration of the time it takes to get the core returned and credit received. In the meantime, there may be unused and un-returned items that are not showing up in the very review where you want to see them.

Hopefully, you can now see how these two schemes collided. We can thank Paul and David Manning at Sharper Electronics for bringing the matter to light (they ploughed up my nest, so to speak).

In a nutshell, the review-non-fully-disposed-of-items function (Number 1 above) will now look in both archived and current PartsProcess locations.

For the export/report option, making the report function additionally look in the current PartsProcess file is a simple, behind-the-scenes change (you'll simply see more stuff, if applicable, in the resulting report).

For the on-screen review mode, it's more complex. The archived view of the PartsProcess form is designed solely to show archived records, and vice versa in regard to the current view of the form -- yet, you need to see results (for the review we're concerned with here) from both sources at once. In theory, we could make a hybridized machinery that would simultaneously show records from both and within a single form view (plus allow editing, etc.), but the mechanisms would be very difficult from a programming perspective. Also, the result might be confusing to the user.

Instead, we've added an option. When, from the archived view of the PartsProcess form you pick the display category "items Received but not disposed of," you'll now have a checkbox option labeled "Include items from current file."

If you proceed with that option checked, the ServiceDesk interface will maximize to use the entirety of your screen. This is to make room for both archived and current views of the PartsProcess form to simultaneously display (and without one covering the other), each in a mode to show you items-not-fully-disposed-of. Thus, you can truly see (and work upon) the entire set of such items at once.

Take that, you unforgiving universe. Perhaps we should now consider a new title for this section: maybe "Rodent Brain Strikes Back!"

In the ServiceDesk ScheduleList form (F6), the box as normally used for the customer's name can serve an occasional alternate purpose. If you want to make an entry indicating that a tech will be absent, for example, particular expressions can be used to fit the situation. Historically, there was a quick-key shortcut for inserting these, but about eight months ago we easy insertion available via a dropdown (see second description accompanying release of Ver. 4.4.55).

Recently, we realized that our new dropdown should have included another special expression:

You can see our new addition (as the fourth/bottom item) in the dropdown illustrated above.

The "Hlpng" expression has been a tool in ServiceDesk for a long, long time. It's used where you're sending a second (or third or fourth) tech to a job, and need to make an appointment entry for that tech. However, you want this entry to be distinguished in a manner that shows the involved tech's role is secondary -- one of merely "helping" the primary tech. It also tells ServiceDesk that, in connection with that particular appointment entry, there should be no expectation of a PostVisitReport, and things of that nature.

The fact is, any of these expressions could always be typed in. However, the dropdown gives you an easier means of insertion, along with assurance that the expression will be inserted with precisely the spelling, as required (vowels eliminated), via which ServiceDesk will recognize the intended operative purpose. In specific regard to the "Hlpng" expression, BTW, you will find it helpful to add (via your own typing) an applicable two-letter abbreviation for the primary tech who's being "helped" (for example, the full resulting text might read "Hlpng DS" where a guy named Dave Somer is the primary tech).

Yes, if you check the prior release/version number, you'll see we did two whole releases with no announcements here. Rest assured, there were indeed improvements -- just none that warranted particular descriptions here. The more announcement-worthy improvements during this period have been on the Mobile side (for details, see our Mobile-WorkDiary).

One of our newer users (David Lange from Oak Valley Appliance) doesn't like to type in dates (can't blame him really), and noticed a few places the system could have (but did not) provide a date-picker calendar. We have now added the accommodation to those locations, as follows:

This last context has always had the "date-hence" option (type "3d" for example, and the system inserts a date 3 days in the future), but for some situations the calendar is likely to be easier.

This one is also from David Lange. Turns out (we did not know this), LG evidently has a method via which you can upload a file specifying the items you wish to order -- as the simplified means of creating an order. Since we're always fond of any means for creating labor-saving automation, we quickly created an option to create an order file in LG's format.

The above option is obtained, from the PartsProcess form (F8), by selecting items to order in the standard fashion, then hitting Enter to proceed with the order.

Some three-plus years ago (see announcement accompanying Rel. 4.3.11) we introduced our Hyperlink feature: the ability to have in-text links in a variety of ServiceDesk venues that reference other objects (picture files, text files, websites, etc.). You can drag and drop and create such links, and a simple double-click on any such link (once it's created) opens the object for you.

In general, the system creates files for the objects as linked to a subfolder of the \sd folder on your server. The subfolder is called HLinks (thus, if ServiceDesk is installed on your server's c: drive, the full path for the folder would be c:\sd\HLinks).

As time has passed, some of our users have accumulated tens of thousands of files within their HLinks folders. Typically, most of these files are images of tickets as created by SD-Mobile. Regardless, when a large a quantity of such files are of images, a potential issue is born. It's because many image viewers (the programs that open such a file and display the image for you) do something behind the scenes, when asked to open a particular file. This "something," evidently, involves surveying all other image files within the same folder. Where there many thousands of them, the opening operation can become rather (perhaps even unbelievably) slow.

With this release of ServiceDesk, you can now create subfolders within your HLinks folder (as many as you like, and named in whatever manner you like), and move some portion of the files into each. If it was us, we'd likely use a strategy such as making a subfolder for each past year (labeled as such), and move all the files as created within that year to that subfolder.

Naturally, even prior to this release you could have created such subfolders, and moved some portion of the file population into each. The difference with this release is that, prior, ServiceDesk would look for a file only within the root level of the HLinks folder. From this release forward, it will look both within the root level, and within immediate subfolders it happens to find there.

Please notice the emphasis, above, on the word "immediate." ServiceDesk will not look to subfolders of subfolders. If you bury files in hierarchy that deep, ServiceDesk will not find them.

Two releases back, we described an improvement in how the system looks at availability, via the ZoneScheduling system, to decide whether to warn an operator against overbooking. Specifically, we'd found that if day-portion vacancies (i.e., morning or afternoon) were available for a particular zone/day socket, but not all-day vacancies, the alert would trigger if an operator attempted to schedule an all-day appointment. This didn't seem logical, since all-day appointments are more liberal to internal management than mere day-portion ones, if day-portion slots are available, it stands to reason, a fortiori, that all-day ones should be permitted.

So (and via a significant internal rebuild) we fixed it. Then we got calls. Lots of them.

Turns out the old system had been being liberal in the opposite way (one that, arguably, logic dictates against). Specifically, it had been permitting (without alert) scheduling of day-portion appointments in the presence of available all-day allocations, but absent any applicable day-portion allocation. Our rebuild incidentally fixed this. In other words, via the improvements as made, an operator could no longer schedule for a day portion, absent warning, unless there were unused allocations for that day-portion.

Logical or not, people did not like this "improvement." So, with this release, the old (arguably less logical) liberality is back. Regardless, the new and added (more logical) liberality, as added two releases back, of course endures.

Customizable Text for Emailed Appointment Reminder/Request-for-Confirmation:

For a few years now, ServiceDesk has had the ability to auto-email appointment reminders (and corresponding requests for confirmation) to your customers. It works great, whether configured so the email asks the customer to confirm via email/phone reply, or via on-line interface as part of the CyberOffice system.

A small rough spot, however, has concerned verbiage as used in the email. About a year ago, we received reports that some customers were not taking the request to confirm with sufficient seriousness. In response, we strengthened the language, adding a statement indicating that if a response was not forthcoming, the appointment might not be held open. After that, we received reports that some customers were offended by the "threat." Aside from such difficulties in our own efforts to get the language "just right," there's also the fact you might want to have elements in the language that are particular to your own policies, preferences and situation.

Given such matters, we have now added this email context to the array of those you can customize, according to your own company preference. For details on how, please see the CyberOffice Handbook, beginning in the section that starts (about two-thirds down) on its Page 13.

Aside from allowing you to now completely customize, we have also improved the stock language (with the language having been at first too nice, and then too mean, we believe we may now have stopped the pendulum about right in the middle, where it should be):

Perhaps, with this improved stock language, you may not feel there is any need to customize. But, at least if you want, customization is definitely now available.

NSA is the National Service Alliance, an organization formed by a consortium of leading servicers in the CE industry to perform a package of services that, in some respects is, is similar to those performed by ServiceBench and ServicePower. At any rate, member servicers have the need to regularly upload certain elements of data concerning job status to the NSA server. This new export is meant to facilitate that. It's accessed via the Export Customer Data form (Alt-F3).

Presently, the export is configured to create references solely to jobs that are setup with "COSTCO" or "SONY" as the underlying client (it's possible in the future we'll need to make this client-filter customizable, but for now it's hard-coded). It will also be necessary, at present, for you to manually upload/ftp this file to NSA (we'll create a self-FTPer as our next improvement).

Please also note that, while the dialog asks you to specify a name/path for the main output file, the process will actually build that file, plus two others. NSA wants three files in total: the main one, plus a second that details parts-on-order, and a third that details parts-used. You'll find the added files named similarly to the main one, and in the same folder location.

For a particular date and zone, you have slots open for AM and/or slots open for PM, but none allocated for All-Day. A call-taker wants to book a job for all-day. As he attempts to do so, he gets a warning that indicates no slots are available.

The above is thinly rational -- in the very technical sense that, indeed, no specifically-designated all-day slots are available. But, as a matter of practicality, if I have morning or afternoon-specific slots available, I ought to be able to book all-day without the system complaining.

This is, obviously, a really basic matter, and considering how long the Zone-Scheduling system has been in play it seems pretty shocking that it never prior came up -- so shocking that when it did come to my attention yesterday, I felt determined to address it immediately. As part of the improvement, I rebuilt a great deal of the underlying program code (what with flowing pipes, and all, it's very complicated stuff) and improved the overall dialog that results when an overbooking situation exists.

Sometimes, it's just a series of things that are too small and too numerous to merit individual description, within a venue like this. That was the case with these releases.

Further Improvements in the "To-Grave" Segment of our "Cradle-to-Grave" Parts Management System:

Back with release of Ver. 4.3.99 (posted 8/31/08, you may peruse below to find), I thought I'd completing programming per the subject as described in this section's heading. As it turns, however, we've periodically learned of need for added improvements. This release introduces four more:

"To-Grave" Improvement #1. Among the "final disposition" checkoff categories we allowed for in Ver. 4.3.99 design, there was one called "RtrnCrdt" -- intended to show, alternatively, either that a part had been returned with expectation that you'd receive credit, or that return credit had actually been received (the choice of which way to use it was up to you). I should have realized at the time this was really a poor design. You need to be able to distinguish between the two modes. To that end, the "RtrnCrdt" choice has now been eliminated. In its place are two options: "RtToVndr" and "CrdtRcvd" (why couldn't I have been that smart from the start?).

You should note there is an important distinction between the old "RtrnCrdt" designator, and the pair of new ones. The old one was an in-the-grave categorization. So is one of the new designators ("CrdtRcvd"). The other ("RtToVndr"), however, is not. This latter is considered a still living-in-the-system, still in-process category.

FYI, any old records that have already been recorded with the old designator will stay as such, but from here on out you can use either of the much more descriptive pair (depending on which applies). For reporting/review purposes (see below), the system will treat the old designation as equivalent to "CrdtRcvd" (meaning, for those older items, it will still be up to you to verify via other means that credit was actually forthcoming).

"To-Grave" Improvement #2. As part of the above-described Ver. 4.3.99 release, we introduced a new filter and new report in the archived-PartsProcess form (Ctrl-F8) -- a pair designed to let you review, for appropriate management, those particular s/o items that had been ordered and received, but had no entries indicating a final and proper disposition. As per original design, those showings were somewhat general in that they included all items not yet in the grave, without segregation as to category. With this release, segregation is now offered. Specifically, when you pick either of those options, you'll next see a dropdown that asks what sub-categorization you'd like.

Thus (and as an example), if you want to specifically review items that have been returned to the vendor and on which you're awaiting credit, that specific category can be selected.

This brings up the point: to effectively harness the benefits as provided by Improvement #1 (described above), you should make it a practice, as you box up and send items back to your vendor for return credit, be sure to place them into the "RtToVndr" category. And, when you receive credit, be sure to go into the "RtToVndr" review category, eyeball the items on which you've received credit, and change their categorization to "CrdtRcvd"(this is the way to internally police, and truly assure the part is finally and fully "put to bed" every time, with credit having truly been received).

"To-Grave" Improvement #3. Recently a client pointed out that it would be very valuable to have a "Reverse PartsPickList." I was immediately and highly enamored of the concept. The notion is, it's a simple list (as provided to you on Tuesday morning, say) that shows everything that should be coming back from the tech, because not used from his work on Monday. Great -- I'd even say fantastic -- concept. I was immediately thinking, "Man, I want to make this ASAP!" But then, I thought, our "Parts Received But Not Disposed Of" report (above discussed) might actually (indeed, already) fulfill almost the same purpose. I pointed this out to the client, and he agreed that, yes, likely it would. However, he called back a short while later (having in the interim tried it), and indicated it really was not effective for the purpose -- by reason of the fact between techs that should have come back from the tech, versus others in the not-yet-in-grave category.

To redress that, besides the new sub-categorization described above, this release adds another: "In Tech's Possession" (see illustration above). It's not quite a Reverse PartsPickList, but (and for the time-being) it's a reasonably close facsimile.

Of course, there is the matter of how is the system to know that you actually (and physically) moved an item into the tech's possession? Until this release, there has been no formal designator of such fact built into ServiceDesk. However, many users have used the same BinLoc box (e.g., as used for designating "RtrnCrdt") for the purpose. More specifically, as they transfer a s/o part to a tech, they change that reference to his simple two-letter abbreviation. With this release, ServiceDesk will now recognize such a designator -- in particular, when applying the reporting/display filter that is the main subject of our "To-Grave Improvement #3."

FYI, as soon as I can do it, I'll create a new PartsPickList on-screen interface -- where you can simply click to indicate that items are being moved into the tech's possession, or back again. I'll also make a purpose-built Reverse-PartsPickList (as requested by that fine client) into an inherent part of it. Until then, you'll just have to do those changes manually.

"To-Grave" Improvement #4. This one, actually, goes beyond "to-the-grave" matters, but it was requested by another very clever client in the context of such concerns. He expressed the need for a method via which a tech can document why he ends up not using a part as prior ordered. My initial thinking is that such comments will likely go into the underlying Request-Item's Notes section.

Thinking about that particular Note section's use (for this added purpose), brought to mind two complaints users have made in its regard. To clarify, I'm referring to the large Notes section as found in the underlying Request (Alt-F8 form), not the smaller Notes section as found within a Process-Item (F8) band. One complaint has been that, when you're in the PartsProcess area, that larger section (which may have info you really need to know about) is not readily or automatically visible (you have to right-click in the Reference section to bring up its containing/underlying request). Another is that, once the Request item is archived (Ctrl-F8 form), those larger notes are no longer available at all.

This release address both matters. Regardless of whether you're in the Current- or Archived-PartsProcess forms, ServiceDesk will now display any underlying Request-Notes, in a ToolTip-type fashion, as your mouse floats over a process-band to which such notes are applicable.

Provision for the tech to document why he did not use an ordered part will be made in SD-Mobile (watch for updates there, along with mechanisms for such info to also auto-insert into these now much more available Notes.

When you're checking a shipment of new inventory via the F10 form, the dialog asks if you want to print labels for the items checked in. As a rule, it's best to do the printing at this point, because we've lacked a means to specify specific/particular items for label-printing thereafter. To clarify, you've been perfectly able -- after the fact -- to print labels for all of the parts in a given location, or all of a particular part number. You could even print one label as pertaining to a particular number, but with no ability to specify which instance (of multiples you might have in stock) that particular printout would pertain to.

This release solves that. Specifically, when you choose to print labels as pertaining to a particular part number (from the F10 form use the option sequence "Review existing inventory" and "Find qty and locs of specific item," pick an item, then click on the "Print list/labels" button), you'll get a list showing each instance.

Just pick the particular listings you want labels for. To select multiple items, user the standard Windows multi-select tricks (i.e, use Shift-Click on other item to select a range, Ctrl-Click to include or exclude an added item individually).

These days technology moves fast, and we'll admit that even here at Rossware we are somewhat surprised to have so soon reached the point where -- viewing you guys out there -- we see printing tickets for service (at least prospectively from the office) as a bit quaint and old-fashioned. Most modern, we feel, is to have no paper tickets at all, and instead E-Tickets are provided to the customer via Mobile (a shameless plug here for that product). A large number of users have migrated to this model, and, if you have not, we encourage you to do so.

Regardless, we're not yet ready to stop injecting improvements into such tried and true methods as printing a beautiful ticket in the office, and sending the tech out with it. For a comparison, eye glasses are now a very old technology. But if you're going to use eye glasses, certainly you want the best that current technology can deliver.

Recently a user pointed out that it would be useful if he could specify particular colors for particular items of text within the up-front ticket. It seemed to make a lot of sense. Current updates in both ServiceDesk and the SD-Tools utility allow you to do this (both will need updated, the latter to Ver. 4.3.7; it's part of the SD-Update download unzip, but unlike ServiceDesk itself will not automatically copy from station to station). Additionally, you can now specify FontUnderline and FontStrikeThrough as characteristics. Just use SD-Tools for such setup, as per standard. Of course (we should not need to say this, but you'd be surprised), you'll need to use a color printer to make it work.

Occasionally, we've had requests to make ServiceDesk operation subject to a password protected LogIn (i.e., you can't open it unless you provide a LogIn password). This release adds the option to setup any station to operate in such manner.

The setup and operation is similar to a function we added a few years back, to allow password protection for a particular tech's LogIn to TechWindow mode (see notes accompanying Release 4.2.22). Basically, you need to go to the Security/Password form (Shift-F11). Within that form's Users page, provide a unique password for each/any user whose SD-LogIn you wish to protect. In the second column (next to each such password), type the user's name precisely as it's listed in the Settings form (Ctrl-F11).

That's all that is required for setup. To test, go to the station as setup for any person for whom you've just done the above. When you go to open ServiceDesk, you should find there's a demand to present the password as setup for that user, or ServiceDesk will not open. (Actually, your Master password will also work, and potentially some others for other-user-LogIn purposes; see below.)

We've also had occasional requests from users to better accommodate the situation where you have a single computer that's used by multiple persons (e.g., on the morning shift it's Sue, while on the afternoon it's Bill).

For nomenclature context, a parallel situation arises sometimes on vessels at sea (ships, submarines, etc.) where there are fewer bunks than sailors. What happens is, two (or potentially even three) sailors end up sharing the same bunk. But not at the same time. :) Each of the bunk mates has staggered "watch" times -- so that, as one sailor goes off watch, he awakens his bunk-mate, who tumbles out as he tumbles in. This has historically been called "hot bunking," and of course you hope your bunk mate has excellent hygiene.

ServiceDesk has long had various forms of hot bunking. There, is, for example, the Temporary Desk Reassignment feature (Alt-K). It's also easy to change the directly-registered user via the Settings form, on an as-frequently-as-needed basis. And, you can handle such needs via the Windows Users feature, where -- under any particular Windows LogIn -- ServiceDesk recognizes a unique setup/user, as tied to the Windows User, and reacts accordingly.

But aside from and beyond the above, some users have wanted ServiceDesk to offer the ability to do a direct LogIn -- to itself and under one and same Windows "User" LogIn -- wherein the ServiceDesk LogIn, in itself, recognizes a unique ServiceDesk user. This likely should be called "Native" hot bunking.

To implement, just setup your hot-bunking station with a general Password-Protected LogIn (i.e., for a primary user, as described above). Make sure the intended bunk mates are in your Settings' form "List of Station Names," and that you've setup the same kind of unique password for each.

Here is the trick. Let's suppose Sue is setup as the primary/designated user at your hot-bunking station. Sue does her morning shift and closes ServiceDesk. Bill arrives for his shift, and goes to start ServiceDesk. He's presented with the demand for Sue's password. He doesn't know Sue's password, so obviously cannot present it. He does know his own, however, and so types it instead. ServiceDesk, upon seeing Bill's password, knows that it cannot open itself with Sue as a user, but figures -- "Hey, I might as well open with Bill as the user," and does so.

Except . . . one more thing. You might want to advise Sue that, if she doesn't want to get blamed for things that stupid Bill does during his shift, she'd better be sure she closes SD as she leaves (otherwise, of course, Bill might happily work under her LogIn).

One more matter, closely aligned with the above two improvements, concerns the fact that some people have wanted to have the Time-Card punch-in tied to logging into ServiceDesk. That's another thing that will happen with this release forward -- assuming just two simple elements in your setup: (1) you must setup the user for password-protected login, as per description above; and (2) you must have them designated, within the Earnings Rate form (Alt-F2), as an employee who is paid on an "hourly" basis.

Back with release of Ver. 4.4.57, we added feature in our "to-the-grave" parts management system where, if you were an established user and been processing parts in an earlier era, you could auto-clean your old legacy history, so items not marked as fully sent to the grave -- back then (there was not mechanism for doing so back then) -- would not come up in a current report. It turned out that cleanup process did not fully do the intended job in some circumstances. That is now addressed. You can access the check-off procedure from the PartsProcess form's (F8) CheatSheet (right-click in any otherwise unused space of the form, then look for the very bottom item in the menu).

In the last couple of years, we've been working with increased vigor to "invade" the CE market. We feel determined, eventually at least, to attain the same dominance there that we've worked so hard to earn on the appliance side. Yet, even on the appliance side we've been subject to a small deficiency in that ServiceDesk has had no element specifically designed to manage core returns. Since core returns are relatively uncommon with appliances, it's not been a major fault there (back door approaches, though less than ideal, have largely sufficed). But on the CE side, by contrast, core returns (and whether they're managed with competence versus poorly) can easily make or break a company. HUGE dollars can be tied up in cores, so the lack of a feature explicitly designed to manage cores has been a serious matter.

To specifically acquaint you with how the matter is addressed, we have added a new section to the manual's chapter-division on the PartsProcess system. As it happens, this particular division is already excerpted for you in a .pdf document that's contextually convenient by clicking on a little provided button in the top-left corner of the F8 form (look for the last sub-section within the document), or here's a hyperlink. Please read the added section in that division, as it will provide all needed details.

We thank Don at Dependable Services for this addition. He insisted that a method was needed to have an instant snapshot of profitability on each job. Makes sense when you think about it. Man, you mean we didn't have that?

At this time the report should be considered Ver. 1.0. On the one hand, it may presently have flaws. On the other hand, it will likely be subject to significant improvements as time goes by. We expect to have input on both matters, and updates in the future.

One thing to note is that, like many of the reports, this one also features an export. The export offers some details that are not in the direct printout.

If you do not know, "CE" stands for Consumer Electronics (these days, mostly big-screen TVs).

You likely do know that, in general, ServiceDesk was born and bred within an appliance service operation -- a fact which (and with apology to the rest of you) gives it something of a bias in that direction. This is also a factor we are endeavoring to overcome. We are very determined, in other words, to make ServiceDesk just as perfectly suited for other industries (in particular, HVAC and CE service) as it is for appliance repair.

Quite a while back, we learned that HVAC servicers wanted some other fields in the UnitInfo form (shortcut access for that form is via Shift-F12) -- fields to keep track of details such unit fuel type (gas, electric, etc.), flow direction (up, down, sideways), and so on. To accommodate, we made the UnitInfo form vertically expandable (via a little arrow button at the bottom), and added the desired fields within the expanded space.

Recently we realized CE servicers need a field to keep track of particular units' Chassis Numbers (considered a model sub number), and the ability to search on that field as well. To accommodate this, we figured we needed to make the expansion area work in an alternate fashion: to show supplemental fields as needed for an HVAC operation if that was the kind of user, or to show CE-supplemental fields if that was the kind of user (or perhaps no expansion at all if neither user-type was applicable).

To implement this strategy, ServiceDesk needed a means by which to be informed as to the type of user applicable. For that reason, in this release we revise the Settings form (Ctrl-F1) to accommodate a new setting:

Depending on which option you pick for the above new setting, the UnitInfo form will be expandable (or not) in an appropriate manner. If, specifically, you pick "CE," it will be expandable (from this release forward) as follows:

If you are either an HVAC or CE servicer, please be sure to activate that new setting option as needed.

Improvement for "Anticipatory Parts Transfers" (Now Titled "Pre-Screened Parts Tagging"):

Way back in '05 (in Ver. 4.1.103), we introduced a mechanism that allows you to speculatively transfer parts, from your in-office inventory and to a tech, for potential use on a particular job. The notion is you may have items on the shelf, not normally kept on the tech's truck, and during the pre-screening process you may realize that a particular job will very likely need such a part -- making it sensible to pull it from the shelf and send the tech out with it.

Over time it's become evident that, though very beneficial, there were elements in this system we might have designed better. In particular, the implementation sequence invited you to transfer the part to a tech, at the same time you were tagging it (for potential/speculative use) on a particular job. This was based on the notion you'd likely know, at the time, which tech would be doing the job. As it turns out, however, this assumption was very flawed.

In reaction to the above, some of our more savvy users have taken to performing a little trick. When in the process and invited to pick a "Transfer To" target (i.e., which tech's inventory location the item is being moved to, from the office, for speculative use on the job), they've picked the office itself (i.e., "OF"). This results in no net transfer of location, but nevertheless allows the other part of the process (tagging the part to the job) to nevertheless take hold. It's a great expedient, but is also one that the involved language and processes would not normally lead a person to consider. This is so true that, even here at Rossware (and when consulted on the conundrum which the expedient solves) we have sometimes failed to remember it, and have occasionally instead been misled -- ourselves -- into thinking the structure allowed no such solution.

First, we have changed the caption as found on the button, within the JobsCurrent (F7) form, that initiates the involved process. The old caption ("Antcptry Prts Trnsfr") was misleading for a process where, in immediate consequence at least, no true "transfer" was necessarily involved. Now the button instead reads "Tag Part for Visit" -- a phrase that much more accurately suggests that your purpose, when clicking on the button, is (necessarily) to tag a part in such manner as to facilitate its presence with the tech -- with any tech -- when he next goes to the site on that job.

Second, as title for the overall set of processes, we are changing from the term "Anticipatory Parts Transfer" (or sometimes "Speculative Parts Transfer") to the more accurately descriptive: "Pre-Screened Parts Tagging" (as per title/header for this WorkDiary entry).

Third, when you actually click on the involved button, there is a new query, as follows:

As you can see, you are now invited to choose, explicitly, whether you want presently to Tag-Only, or Tag-plus-Transfer. This makes the alternate potentials much more apparent.

Fourth, if you choose the Tag-Only option, the system will (logically) skip what was otherwise a following window in which your were formerly asked to pick the "Transfer-To" location.

Fifth (and perhaps most importantly), there is a newly-augmented process as now connected to the system. Assuming that in fact you've "Tagged-Only" while pre-screening, this process recognizes a subsequent need. Specifically, sometime prior to the tech heading out on any particular day's set of jobs, you'll likely be printing a PartsPickList, and using it as the basis to actually pull tagged items from the office, placing them into an applicable tech's pickup bin. Once this is done, it's imperative to inform the system of this physical transfer event (i.e., so it can properly tally where the item is now at -- referring, specifically, to those instances where you did not claim a transfer initially).

Ultimately, what we really need to do to -- to optimally accommodate this purpose -- is to have an interface that will likely be called (at least something like) the "PartsPickList-Reconcile" form. The vision is for this form to provide a one-stop place for a parts-puller to assure he's assembled all the parts a tech should be taking with him for his day of jobs, whether as special-ordered, speculative-tagged, or simply needing restock to inventory (and, of course, to seamlessly document the movements from one location to another). It may be that the current Parts-Crossover form can be optimally adapted for this purpose, rather than creating a new interface in its entirety.

Regardless, in an anxiousness to "deliver" on the current project, we have for now refrained from creating an entirely new interface. Instead, we've added enhanced functionality to a pre-existing function.

Specifically, in the InventoryControl form (F10) there has long been a function to facilitate transferring parts to a tech for the purpose of restock (in particular, using as basis examination of items on which he's fallen below minimums). It's a very smooth and well-developed process. Our new function allows you, simply, to use this same set of mechanisms, but in a context that's augmented so that the system lists not only regular inventory items as needed, but also any items as tagged for jobs the technician will be doing for the day in question (and which have not already been marked as transferred to him). Thus, it's a solution that allows you to (please pardon the cliche) "kill two birds with one stone" (accommodate ordinary re-stock, plus appropriately move items speculatively tagged).

To invoke this augmented process, you'll notice that when you choose to print a PartsPickList from the DispatchMap, there is a new option box in the resulting Printer-Selection form:

If you print with that new option box checked, you'll find that, besides printing the traditional list, the system takes you directly into the InventoryControl form's newly/specially augmented Transfer-for-Restock mode. In this mode, it will list not only normally-needed restock items (as it always has), but also ones that need moved to him because they've been tagged to a job that is on his schedule for the applicable day. Such items will be distinguished, from normal restock items, via the text being in red.

From that display you can use traditional/normal means to transfer all items, both normal restock and job-tagged items, to the tech as needed.

Besides those particulars above-described, a few other elements of language and interface have likewise been appropriately changed. Even so, please note we have not entirely dropped the "speculative transfer" language. This is because, even if you do not transfer to a tech while tagging a part, you very likely DO transfer the evening prior (or morning of) his dispatch on the job. For such particular operations, the older language is retained.

BTW, we realize there's a downside in changing terminology. Please be assured, we resist doing so except when there's a large purpose to be served. We believe this instance strongly qualifies.

Until now, there's been no distinction by the system when you check-in the final part, as ordered on any ticket -- as to whether it was a POS-context (versus more standard repair context) order. It turns out the distinction is important. Among other things, if in repair context it's natural to assume that, once all parts are in, the underlying JobRecord should be placed into "WorkingToSchedule" status. Not so if it's a POS-context order, where there's no return/repair appointment needing to be scheduled. Similarly, any dialog (such as in an auto-generated email as designed to inform the customer of part arrival) needs to be appropriately different, if it's a POS-context order.

Prior to improvements as made in this release, the system acted as though every order was a repair-context order. But now, with improvements as presently made, the system will distinguish the two contexts, and handle the POS variety much more adroitly. (For the distinction, incidentally, the system looks simply to the underlying JobRecord's narrative history for the phrase "(POS context)"; if that's found, it deduces accordingly.)

Enhancement to DispatchMap's Show-JobsNeedingScheduled Feature:
Now Includes JobsWhereCustomers"Want-Sooner":

First, the general Callsheet/JobRecord structure has a new little check-off square. It's similar (and in fact right below) another tiny check-off that we added a few months back (see entry accompanying release of Ver. 4.4.62). That one was added for the purpose of denoting if a job should be classified as an in-shop repair (i.e., "ShopJob"). This new one is designed to denote if, though having accepted a particular appointment, the customer would nevertheless like to be moved sooner, if possible.

You may note (by reading notations in the above illustration), the RED color as formerly used for the in-shop designator has been usurped by the new check-off (though at least its physical position remains constant). In general, we hate to change a functional color, but it seemed that red made eminently more sense for a designator that really should attract notice (this customer would like to be re-scheduled for sooner) -- as compared to something mundane like designating 'in-shop' status. Thus, the old designator now gets blue.

So far as on-screen labeling and reminders go, just as with the first designator, there are ToolTips available to assist (just float your mousepointer over either item, and the ToolTip should appear).

Aside from toggling the new designator (again, to indicate the customer "Wants Sooner"), you're going to want to employ those toggles.

In your DispatchMap (F5), there has long been a "View-JobsNeedingScheduled" feature. The idea behind it: at any moment and on any day's schedule, you can toggle-on a view of jobs that need to be scheduled. So, if you're looking at a schedule and needing to fill it in (or at the fact some tech is driving a long distance and you'd schedule more jobs in that vector to make his trip more worthwhile), this feature can show you good candidates. The item references appear as little orange "pumpkins" on your map, and you can click on any to display the full/underlying JobRecord.

The feature is toggled on (or off) by hitting "J" on your keyboard (think "J" for "J"obs) . The DispatchMap's contextual "Cheat-Sheet" has long had a little hint reminding of this method (right-click on any otherwise unused position in the DispatchMap to display). That particular hint has now been changed, however, to describe a broader purpose.

Put simply, the old "ShowJobsNeedingScheduled" feature now does more than to show you just the orange pumpkins.

As you can see from this example, the system now shows green pumpkins too. These new pumpkins represent jobs that are presently scheduled, but where the customer would love to be moved to a sooner date ("Wants-Sooner"). Aside from noting that simple difference, you can use them much the same as you do the orange pumpkins.

First, tweak one. A couple of years back, ServiceDesk's Printer-Select form was enhanced to allow (in appropriate contexts) destinations other than actual printing for the the product destination: specifically, Email or File.

At the time, it was setup so that any of the three potential destinations could be independently checked, or not, as to whether the product would go there. In other words, it was not setup to "toggle," such that if your picked Email, say, it automatically un-checked Printer. The thinking was, you might want to do both (or perhaps all three), so the check/activation for each was independent.

That was fine in theory, but in practice it was much more typical that you'd want one function only, which made it kind of a nuisance that, if the form prior had Printer selected, and you now wanted to switch to Email, you needed to do two things: un-check Printer, then check Email.

This release addresses that. Now, selection of any of the three alternates un-checks the others for you. If, in fact, you want to do multiples at the same time, simply hold down Ctrl on your keyboard, while making added selections.

Now, tweak two. If you examine your Callsheets (and assuming you're in an office with multiple users), you're likely to notice a small difference. Callsheets as assigned to others will show with all text in a grey color. This makes it more evident when a Callsheet is not assigned to you, and we think you'll like the difference.

Second, the improvement builds on a feature I added to SD-Mobile some six months ago. There, I made it so each of your techs can easily see (and optionally certify as accurate) a graphic overview of their time spent during the day -- a beautiful image that provides a "mental picture" of the time periods spent "Punched In" on the clock, and -- of that Punched-In time -- which portions were spent working at actual jobs.

When I made the above-described improvement in the mobile interface, it was my intent to quickly provide the same visual overview for managers in the office. Though it's taken me a while, that next step is now ready for your enjoyment.

To use the new DTR-Viewer, first go to your DispatchMap (F5). Page-up to view any past/prior day, then hit Alt-T on your keyboard (think 'T' for 'T'imeCard). In result, you should see something similar to the following:

As you can see, there is a TimeBar for each tech, showing all Punch-Ins and Punch-Outs for the day, with time "on-the-clock" showing in red (any breaks between first punch-In and punch-Out, such as for lunch, are shown in white). Time at actual jobsites is shown via green inserts, appropriately labeled for the jobs to which they pertain. Given this dynamic, you can easily gauge (and at a glance) if, when and where your techs spent significant amounts of time on-the-clock, but not working at actual jobs. In other words, look for large areas of red (such areas being NOT a good thing). Wherever you see such areas, you may logically be prompted to inquire as to whether the tech properly should have been "on-the-clock" during such time.

There are also helpful statistics at the top. Among other things, these help you compare between techs to see which are being the most efficient with their on-the-clock time.

There are more tools still. If a tech manually inputted a punch-In or punch-Out, for example (i.e., rather than allowing the TimeCard system to go by his computer's internal time when he punched In or Out), the corresponding time notation will show in red, to signify this fact. If the technician used the SD-Mobile mechanism to certify accuracy in his DTR (a practice we suggest you insist upon), you'll see a very large check-mark in the white space immediately above the TimeBar itself (just to the right of the statistics). In fact, the check-mark will be green if the presently calculated total of time agrees with the indicated time when he certified, or red if there is now a discrepancy. If you want to change the day that's displayed, use PageUp and PageDn from your keyboard, just like when inside the DispatchMap.

We think you're going to find this is a more than fantastic tool. And don't worry about memorizing the shortcut key to access it. A reminder is in the DispatchMap's CheatSheet.

As one more (and super-handy) feature, if you're looking at any particular job notation (green rectangular insert) and are curious to see details about the actual job, just click on the notation. Instantly, the underlying JobRecord will display for you.

4.4.67 (5/10/10):

QuickLink to Particular/Underlying A/R-Item via A/R-Dunning Form:

For the last three or four years, just about every time I'm working on the line-items list in the A/R-Dunning form (Ctrl-F3), I find myself having the natural urge to be able to right-click on any particular line-item, and have displayed the complete A/R record which underlies it. Sometimes, after all, as you see the simple line-item summary, you want to know more details about that particular A/R. It's just not right that you have to hit F3 (to bring up the A/R form) then conduct a search in it for the item of relevance.

Finally, I made the time to program in this "should-have-been-there" convenience.

As you can see from the illustration, a ToolTip is now available to remind you of the new convenience. Just float your mousepointer on the little grey label area at top of the form, and the ToolTip will appear.

As a moderate little enhancement of this feature, if the line-item that you click on happens to reference multiple A/Rs (i.e., rather than a single one, as is more typically the case), the first quick-linked item as displayed will be the first/oldest. However, the A/R form will be pre-configured for you in "Search" mode, with the 'Resume Search" button showing and pre-selected. This means, to rotate to other A/Rs as applicable to the line-item linked from, all you need to do is hit Enter on your keyboard.

Thus, you have quick and easy access, even to multiple A/Rs as connected with any single Dunning List line-item.

We've been informed that, increasingly, servicers are running into situations where different manufacturers happen to end up using precisely the same part numbers as one another -- but of course each for their own (and different) parts. The underlying structure of SD's inventory system is one that uses the part number as a controlling entity, and without regard to applicable make. This means part number duplication, between manufacturers, has been a potential issue.

This release introduces a solution, though perhaps not quite so perfect as user might have otherwise desired. It's sort of a work-around.

What you need to do, for any part where you're stocking different items but of the same part number for different manufacturers, is append one or both instances with an asterisk then a single letter that indicates the applicable manufacturer.

For example, suppose both Toshiba and Sony have parts bearing part number 123456, and you want to stock each. For the one from Sony, make your within-the-MasterPartsPlan number "123456*S". For the one from Toshiba, make it "123456*T".

The above is, of course, an expedient you could have been using all along, but with one downside. When ServiceDesk fills-in the on-screen Narda for a warranty claim, it uses your part number as provided. Sony won't likely provide credit on claimed use of part number "123456*S". That's where the improvement (as present in this release) comes in.

Specifically, with the enhancement as introduced with this release, when ServiceDesk fills in the on-screen Narda, it will look for part numbers with a "*X" suffix on the end (where "X" is any possible letter). For any found, it will delete the suffix -- thereby smoothing the way to a successful claim on such parts.

Fix for "Split A/Rs" ending up in presentation of multiple "tickets" to consumer:

There have been prior references in this blog to "The Law of Unintended Consequences," and it is, sadly, a merciless (if sometimes slow-to-present-itself) taskmaster. Slightly less than five years ago (see entry for Rel. 4.1.74), I introduced the ability to make interim sales entries: entries to the sales journal for a portion of the sale as already earned, and prior to a completing entry, for the balance, which actually closes out the job. Turns out there as a down side to using this practice. If the interim entries were for billed work, and if you later sent the client a statement for outstanding A/Rs which involved such multiple entries, it was possible for the statement to have multiple line items for what was really a single job. This could potentially be confusing to the customer, and cause unwelcome objection. On top of that, if you happened to be creating a new job for such a customer, there's that little feature that offers to add a note about presently unpaid A/Rs. That note could end up claiming there were multiple A/Rs, even if all involved a single job (and again result in confusion with the customer).

This release remedies both issues. In either of the contexts described, ServiceDesk will combine the multiple A/Rs (as under a single ticket number) and present them as though one.

There are, of course, "two" party-info sections in SD's general Callsheet/JobRecord structure. The second is only used (at least for actual party info) in the event a job actually involves two parties (one for billing, and the second for go-to). Of course, when not used for official party-info purposes, the second section is sometimes used (and at least by some folks) as extra space for added notes. This particular fact creates a quandary for the system when it updates the CstmrDbase Index set each night. If extraneous notes are in the second party-info section, we do not want to have such notes indexed as though they consist of a party's name, address and telephone number, etc.

The solution has been that the Index-updating machinery is programmed to ignore text within the second party-info section -- unless if finds (in the address box) a set of brackets, as involved in the grid coordinate that's inevitably put in if you're sending a tech to a location as involved in that section (bear in mind, while it's easy for a human to look at text and distinguish between text that describes a name, address and telephone numbers, computers are much less capable of so simple a task).

The above works fine, except where you're doing a bill-to-another-party Shop Job (typically, involving a TPA payer). In that case, you need the second party-info section to describe the owner of the merchandise you're repairing, but you do not need brackets in the address line, because there's no need for grid coordinates on an address you're not sending a tech to. For that particular situation, our trusty old strategy fails.

In solution, this release introduces a change. From here on out, the system looks to see if the first-section party info describes a HighVolumeClient. If so, it will index text in the second section, even if no brackets are found there.

One of the oldest exports in ServiceDesk is the MailingList export (available as the first option in the Alt-F3 form). As time has gone by, I've improved my overall export-programming standards. The present standard allows you any of three formats (.csv [comma-delimited], .txt [tab delimited] or .xls (Excel format). Plus, it offers to open the file for you, upon its creation. I recently discovered this old export had not been brought up to the current standard. That is now addressed.

Back in November of last year (with release of Ver. 4.4.38) we added the ability to directly review and edit, in the ServiceDesk FinishedForms context, tickets as created by the tech when operating in SD-Mobile (simple image-based review had always been available). This was a major step forward in terms of integration between the two systems. However, we found there were occasional glitches in the technology we were using to make the connection between ServiceDesk and the remote database that serves as a common information point between ServiceDesk and the Mobile techs. This sometimes resulted in difficulty when seeking such direct-access of the mobile tickets.

With this release, we have switched to an entirely new technology for such connection purposes, and it promises to be much more reliable and fast.

While testing operability of this new technology, I noticed some shockingly severe defects in how the program code was prior loading data into the FinishedForm tickets, and sometimes in saving edits too. I am embarrassed, frankly, to have discovered such large defects were there, and had evidently been there since September. They also have now been fixed.

There's long been ability in both the InventoryControl form (F10) and MasterPartsPlan form (Ctrl-F10) to do a Ctrl/Right-Click on any line item to invoke an immediate show as to locations and quantities for that item. It's extremely handy. Say, for example, you're looking in the F10 form at items that need to be restocked, and you want to how many you've got an where; a simply Ctrl/Right-Click on the line-item will tell you. Or maybe you're reviewing items in your MasterPartsPlan, and are curious to know for a particular line item what you've got and where. Again, a simple Ctrl/Right-Click will tell you.

Recently, I realized another/similar quick-link would be very useful. Instead of instantly showing you locations and quantities for a particular item, it will instead instantly show you the history of movements (purchases, sales and transfers). The command for this new link is Shift/Right-Click.

Don't feel any need to memorize that command on the basis of description here. It's been added to the contextual "Cheat-Sheet" (as applicable in either of the two forms), as follows:

Remember this cheat-sheet (and others in their own applicable contexts) can be displayed by simply right-clicking with your mouse in any otherwise non-functional location on an applicable form.

We find some people don't even know about this form. It's accessed via Shift-F7. The general idea of the form is it allows you to review a limited set of jobs -- such as, for example, only those that are in Working-to-Schedule status. The main filters (i.e., criteria by which to limit the set of reviewed jobs) are JobStatus, but there have long been others, such as applicable technician, for example. If you haven't used this form, we highly suggest checking it out, as it's very handy.

The above illustration is really sufficient, in itself, to tell you what the new filters are.

Until about 30 months ago, there was nothing in ServiceDesk functionality to operationally distinguish between jobs as setup for in-shop work versus those setup for in-field/on-site service. However, a few servicers described the need for certain kinds of distinguishing treatment, so the program code was enhanced to provide the same (see description accompanying Release 4.3.45). At the time, we used kind of a "cheat" method to facilitate designation, of any particular job, as being in-shop (as opposed to the default assumption of on-site). Quite simply, in the LocationName box you'd type the magic phrase "SHOP JOB." In result of seeing such text there, ServiceDesk would realize it was a shop-job, and react accordingly.

This has been the solution until now. It's worked fine, except for the fact the designation method was perceived by some as -- shall we say -- inelegant. Certainly, it has been less elegant than would be having an actual checkbox for the purpose, and that is the matter now addressed.

In fact, I began working on the graphic interface for this improvement a few weeks back (since real-estate in the applicable forms is already tight, I could not simply add-in in a normally-labeled checkbox for the purpose; the applicable forms do not have space for that). You may have noticed my tentative solution when a couple of tiny new boxes appeared in the Callsheets. These were otherwise not-yet-operational, and there was no notice explaining their purpose. It was nevertheless my intent to program the first to default with a checkmark indicating the job was intended for on-site service, while providing the option to user-check the second, instead, to designate the item as a shop job. Initially, I got as far as making that graphic, but did not get any of the underlying programming done.

This past weekend I finally found time to do the underlying programming. Initially, I'd intended to go ahead and use the graphic interface as above described, but soon decided two checkboxes make less sense than a single one (why do you need a box indicating normal status, anyway?). The final scheme is, this single box defaults to a neutral color to indicate a normal, in-field-service job -- but can be user/click-toggled to red for the purpose of indicating in-shop service instead. So, that's what we've ended up with (with, as you'll note, the final/operational box also moved to a slightly different location, as compared to original intent).

Naturally, this new little designator has been added not just in Callsheets, but in JobRecords (current and archived) too. Simply click on the little box in any such context, to toggle it red, any time you wish to designate the job is intended for management as in-shop work. Or, click again to toggle back out. Again, it will show in a neutral color (same color as the surrounding background) if it's a standard job, or as red if toggled for in-shop. Also, if you float your mousepointer over the new little box, you'll see a ToolTip come up to remind you of its purpose.

Ideally, it would have been good for me to include with this release conversion code that would go through all present and past jobs, search for the old mode of designation (i.e., the phrase "SHOP JOB" in the applicable location), and change the new designator to match. Alas, I did not find time for that. However, for a reasonable transition period ServiceDesk will recognize either old or new designator methods as legitimate. In other words, whether it finds the phrase "SHOP JOB" in the expected box, or if you've toggled the new little checkbox to red -- either way it will see the job as being intended for in-shop management. From this point forth, of course, you should use the new designator, and abandon the old.

The "Law of Unintended Consequences" is the programmer's eternal enemy. Turns out, the scheme (as described immediate below) was great for most servicers in most circumstances, but resulted in unnecessary annoyance for others. The biggest immediate issue concerned claims as submitted on extended service contracts, where a purchase date more than one year ago is not an issue.

With this release, the system should detect when it's an extended service contract situation, and refrain from making the "purchase-date-more-than-one-year-ago" warning, if so.

Another issue involves servicers that do large amounts of work for premium companies, such as Sub Zero, where the typical warranty period is more than one year. My intended solution (it will be "Fix 2") for that is to provide a new box, in the Quick-Entry templates, where you can indicate for each manufacturer what their typical warranty period is. Alas, I have not yet been able to get to that added project.

ServiceDesk has long made rudimentary checks as you go to file a warranty claim via the on-screen Narda. It cannot, of course, fully predict if the underlying processor will accept your claim, but at the least it can look for (and warn you about) a few common errors. As mentioned, it has long had this facility.

However, it was recently pointed out there were a few logical (and relatively rudimentary) checks it was not making. Specifically, it was not looking at the DateOfJobInception, DateOfCompletion and PurchaseDate fields -- to cross-compare between those and with the current date -- to assure such date comparisons would not be likely to result in claim rejection and/or embarrassment. Those checks are now made, and (assuming the comparisons indicate a likely issue) can result in messages such as the following:

I'll confess that manufacturers, on seeing we've done the above, might suspect the effort is aimed at facilitating cheating by you, the servicers. Let me assure, however, that is not the case. At Rossware, we generally find our users have a high level of integrity. The real concern is that accidentally-inserted erroneous dates can result in claim rejection and/or embarrassment. These messages give you the opportunity to consider if less-than-sanguine dates might in fact be erroneous, and to advance correct (i.e., prior to actual submission), if so.

In conjunction with Whirlpool Corporation, we have implemented a system to facilitate returning, to them, parts they need back for fault analysis. Basically, any time you check-in or go make a claim on any part within a particular "we-want-it-back" return list, ServiceDesk will automatically produce a message telling you Whirlpool wants it back, and offering to print documents to facilitate the return (specifically, a packing list and postage-paid shipping label).

We believe, in result of this work with Whirlpool, we've created a model of facilitated returns that may eventually be used by other manufacturers, both in appliance service and other repair industries.

ServiceDesk has long possessed a Command Summary in its main menu. A listing of commands is particularly needed for some contexts, because in some (such as the DispatchMap, for example) display space is so much at a premium for operative purposes, and the operations that we wish to do are so many, it simply is not practical to provide on-screen command buttons for every purpose. Instead (and in such forms), we offer a plethora of powerful tricks and tools via various combinations of keyboard and mouse. Among other things (and for each such context), the Command Summary lists what these actions are.

Augmenting that main-menu listing, it has long been easy in several such operative areas to quickly bring up the particular section, from the Command Summary, that's applicable to the context in question. When the apt section is brought up in such manner, we have taken to calling it a "CheatSheet." These CheatSheets can be very, very handy.

Gradually, some of these CheatSheets have been improved for greater organization and clarity, but until now some were still somewhat lousy, and we needed some new CheatSheets in places we did not yet have them. Plus, for each context where a CheatSheet was potentially available, you needed to at least remember the particular magic place, where you could right-click with your mouse, to bring up the Cheat Sheet as applicable there.

With this release, there is a big general improvement. In any context that offers a CheatSheet, you can now right-click in virtually any otherwise un-operative space, and get the CheatSheet as applicable there. The contexts that offer such CheatSheets are as follows:

Callsheets;
DispatchMap;
PartsProcess form;
ScheduleList form;
Inventory Control form; and
MasterPartsPlan

Please note that the last two forms are new, in terms of their CheatSheet participation. For those two contexts (and for some time), we've needed reminders of two or three potential commands in each, and those are now provided in these particular new CheatSheets (if you check in those contexts, you'll see some handy actions you likely did not even know were available).

Please also remember, a right-click in any otherwise un-operative space, in any of these forms, will produce the CheatSheet as applicable there.

In addition to the above general improvement (and added CheatSheet contexts), the CheatSheet as applicable to the PartsProcess form has been strongly improved, in terms of the clarity of its organization:

While the new layout may look a bit more intimidating in size, if you look briefly, you should see it will be a great deal easier to find what you're seeking when you want it.

A year or so ago we completed the "to-grave" portion of our cradle-to-grave PartsProcess system. Specifically, we provided a report that explicitly lists items not checked off as having reached a proper disposition (i.e., used on the job, returned to the vendor, etc.). This was to provide you the basis assure no such items slip through the cracks -- that, ultimately, all reach an appropriate final destination.

For those transitioning from prior times, however, we discovered an issue. If you had not prior been doing check-offs, and yet wanted to use the report, you could find it filled with old items of which you're no longer truly concerned.

To address this, the CheatSheet for the PartsProcess form now has a new option (see bottom item in illustration of "New" above). If you click it, you can run a process to address the above-described concern.

On the first of this month, we added popups in the DispatchMap. If you float your mousepointer over any job reference, a popup shows a bit of added detail regarding the underlying job (InvoiceNumber, and Type and Make of machine being serviced). Based on popular request, we just added a new element. If you do a simple click on the little popup, it will open the underlying JobRecord for you. To be sure, a Ctrl/Right-Click on the underlying reference will do the same thing, but in some instances you may find it just a little handier (and perhaps more intuitive) to do the simple left-click on the popup instead.

Nothing terribly notable in this release so far as new features, but it contains a ton of small fixes and tweaks.

Virtually from its inception, each ServiceDesk package has included a superb backup utility called SD-Backup. The design intent is for this utility to run continuously at any computer aside from the server. In such a state, it automatically maintains five layers of backup (hourly, daily, weekly, monthly and yearly). As just one tool in your backups arsenal, it's an excellent system, and positively should be in deployed in every ServiceDesk office. If you have not been using SD-Backup, please fix that fact now!

Sadly, SD-Backup does not solve every need-for-backup situation. One problem is, some people (in spite of the fact ServiceDesk almost constantly pesters otherwise) choose not to run it. Seriously, we've had numerous people who suffered data loss -- then, to add insult to injury, they had to face our scolding for the fact that, though pestered every day by ServiceDesk to run SD-Backup, they'd still refused to do so. In some cases these folks had other backup systems in place, which they thought obviated the need for SD-Backup. However, the other systems proved to have not been doing what they claimed. Please, do not NOT use SD-Backup.

Of course, even when you're faithfully running SD-Backup just as you should, it may fail to provide a wanted salvation. This is particularly true because each hourly backup overwrites the previous hourly, and each daily overwrites the previous one in its class, and so on. Because of this, if you don't notice there's a fault in data prior to such an automatic backup, its class of backup will have replaced -- what was formerly a good backup -- with a defective copy. It's one of the Achilles' heels of automated backup systems (because of this, if you notice a major fault in any data, it's a good idea to momentarily terminate the SD-Backup program, pending immediate investigation and resolution).

Regardless of whether the issue is SD-Backup having not been running, or because it's already replaced a prior good backup with now defective data, we've often found another salvation when users have had data faults occur (no software, by the way, is immune from data failures when the underlying system hiccups in any of several possible ways). It's based on the fact that many processes in ServiceDesk make their own, in-process backup as the process runs (as a rule, these backups go into the LclData folder for station that's running the process). Virtually all the archiving processes do this, for example (Callsheets, JobRecords, ScheduleList, PartsProcess, etc.). Because of this, it's often been true that when we could not find an optimum backup anywhere elsewhere to use, we were nevertheless able to find a good in-process backup, and restore a user to good operating condition.

Even here, however, the results have sometimes not been as good as wanted. The major problem has been that, after having discovered a data fault, the user again runs a procedure where the same in-process backup is made. This overwrites the prior (and formerly good) in-process backup with a copy of the now defective data -- and very much frustrates our effort to make a good restoration.

Specifically, each station's LclData folder will now receive seven sub-folders, one for each day of the week. All in-process backups will to go the sub-folder that pertains to the day on which the process is running (meaning if there's a fault today and you already overwrote today's previous good in-process backup, there should still be backups in yesterday's sub-folder to look to, and so on).

And that's not all. Within each days' in-process backups folder, instead of each backup (as for that day) overwriting its predecessor (assuming its from the same calendar day), it makes a new one (appended with 001, 003, etc.).

Based on this, any occasion where we can't turn to an in-process backup for these critical files should now be very rare indeed. You still should/must be running SD-Backup as well (when it comes to backups, it's hard to have too many layers), and you positively should also have an off-site backup system as well (we recommend burning critical data to a CD on a daily or weekly basis, and taking those home, assuming home is not the same place as the office).

Another very old ServiceDesk feature involves the fact that, in the ScheduleList form (F6), you can create entries denoting times when a tech is unavailable. The method is to place, in what's normally the customer name space, any of three potential text strings:

(b) "Unvlbl Until" (for denoting he'll not arrive on the indicated day until a particular time); or

Also very old was a shortcut for inserting these key phrases. It involved typing either "U", "UU" or "UA", then hitting Shift-F3 on your keybaord, which made ServiceDesk change the short string into the somewhat longer full one. To be candid, in the last many years I've been embarrassed to show people how this feature works, because the method is so clumsy and un-Windows-like. I'd made the feature in my earliest programming days, when I still had a rather DOS-oriented mindset.

Anyhow, we recently co-opted the Shift-F3 command for displaying the new Rolodex, without realizing it messed up use of the same function for the above-described purpose. This made a perfect opportunity for modernizing the latter. Now, when you're in the F6 form's CustomerName box, you'll see a drop-down with the three magical options, and all you need is to select one.

We introduced drag-and-drop hyperlink creation a couple of years ago, and imbued several of the textboxes (in various ServiceDesk locales) with the capability. We also said, if people wanted the capability in other boxes, let us know. Recently Scott at Carter Services asked for the capability in two new places: (a) the Notes box of the PartsRequest form (Alt-F8); and (b) the Notes box of a SpecialSituationsAdvisory (Alt-F11). The ability is now added to those boxes.

Find Funds Received and Find Parts Special-Ordered buttons added to Archived-JobRecords form:

For quite a while, we've had a couple of handy, half-hidden functions in the Current-JobRecords form (F7). Some of the buttons there do alternate duty if right-clicked on, instead of the standard left-click. Of particular note here, the "enter funds Rcvd" button can be right-clicked for an instant viewing of all monies collected on the job; or you can right-click on the "orDer parts" button for an instant viewing of all connected parts-process items (you can float your mousepointer over other buttons to review their alternate functions, where applicable).

Last week, I got an email from Allison at Dependable Services asking for similar capabilities in the Archived-JobRecords form (Ctrl-F7). It made too much sense to resist, so now has been added (please understand, these are in-context, convenience searches; the same searches have always been available from within their own operational contexts, elsewhere). In the new context (and as you can see below), these "Show Me" functions are not alternate/back-door operations for the buttons involved. They are the exclusive, on-the-face purpose for each.

Since the updated form has the same quantity of buttons as before, you may wonder what we did with the functions those same button positions used to provide. On consideration, we realized those old functions did not need to be in this form. One of them ("Dbs Index Utility") already had separate access via the MainMenu, and we moved access to the other function there as well.

In fact, we did not want to just keep adding items to that menu section (it was already a sufficiently long list as to be potentially confusing). Honoring that concern, you'll notice that an added element of work was to reorganize File Functions, placing several items into fly-out subcategories. This considerably simplifies the main list.

I was given this idea by Steve at Gulgren's Appliance. You're likely familiar with Windows ToolTips: little clues and hints that pop up when you float your mousepointer over various objects (we use them a lot in ServiceDesk). We are now using something similar in the DispatchMap. If your mousepointer floats for more than 1/10th of a second over any job reference there (either graphic or list type), a ToolTip-like window will display, showing some added details on the job.

Currently (as you can see in the example above), the popup provides job InvoiceNumber, along with Type and Make of machine being serviced. I suspect there may be requests to add some more details, which I'll certainly be willing to consider. Please bear in mind, though, all it takes is a Ctrl-right/click to see the entire job, so it certainly makes sense to keep what's shown in this popup comparatively limited.

A couple of years ago we added the ability to direct-email tickets from the FinishedForms context (Alt-F4). Occasionally since, we've had complaints about legibility and clarity in the emailed images. It was generally an issue only if the image included very small graphic-based print, as in the disclaimer section of an underlying ticket image. This release addresses those clarity concerns. In addition to the fact that such tiny print will now be legible, the image files (as attached to the emails which the method produces) will be now be in .PNG format, instead of the .JPG format as was formerly used. PNG is a newer and more efficient graphic standard. Even with much better resolution, it allows use of smaller file sizes.

When you're creating an internal PartsRequest via the Alt-F8 PartsRequest form (this is most typically done while in the context of a PostVisitReport Type-2), it's possible you are not merely the person creating the request: you may also be the one who needs to do the subsequent processing (i.e., inquiring with and/or ordering with a vendor). And it may be the case that rather than taking care of all pending on orders later, as a batch, you'd rather do it directly in-line with creation of the request. If so, this new feature is for you.

Quite simply, if you want to link directly from the creation of the request itself -- to processing of the request -- simply hold down your Ctrl key while completing the request (in other words, while clicking on its "Save" button). On the basis of this variation, the system will take you right to the same item, as loaded into the PartsProcess form, for appropriate further processing.

If you happen to forget the above variation, just float your mousepointer over the form's "Save" button. A tooltip will appear for purpose of reminder:

Early adopters found a few small faults in the new Rolodex, which have been addressed in this release. Most significantly, I realized, for the two yellow Notes boxes that fit to the left, respectively, of the Companies and Persons lists, I'd initially forgotten to put in vertical scrollbars (in case you have lots of notes and need to scroll), and the ability to drag in hyperlinked objects. With the latter fix, you can now drag pictures, documents and files into either note box. As one example of such use, with respect to any company with whom you have a contract, I suspect you may want to drag in a hyperlink to that contract.

A few weeks ago I overhauled ServiceDesk's TimeClock function, where your employees can punch-in and out on an electronic TimeCard. Afterwards, it became apparent I'd left out an important ability: to punch-in or out on the basis of an entered time, as opposed to the computer's system time. This can be needed, for example, if an employee forgets to punch-in on first arriving, and realizes it later in the day. To invoke the method, simply right-click on the applicable "Punch" button, rather than left-click (a ToolTip will remind you of this method if you simply float your mouse-pointer over).

A dialog then ensues for entry of the manual time -- and, when it's inserted to the TimeCard, it's with a flag advertising that the time was manually entered (this is to provide the owner/manager with a method of policing, if the event that an In or Out time happens to become suspect).

Though we recently acquired its maker, fact is we've been converting users from our former competitor's system, LogiSERV, for a long time. These "converts" to ServiceDesk have, of course, been very happy with their conversion -- with a particular and notable exception. Many have lamented the fact ServiceDesk has lacked its own equivalent to a Rolodex-type function that's long been built into LogiSERV. In fact, more than one former LogiSERV user has made it a point to periodically tell me their office continues to run LogiSERV, in the background (even while using ServiceDesk for main operations) -- solely for the sake of using its superb Rolodex.

With this release of ServiceDesk, finally, those users can turn off their old LogiSERV -- and stay exclusively in ServiceDesk.

Yes (and as previewed at the ASTI convention), we now have our own Rolodex-type function.

We are, furthermore, betting users will find our new Rolodex is structured with a far more rewarding, flexible and powerful interface as compared to LogiSERV's, or any surviving competitor's present equivalent. Here's what it looks like:

To bring up this new feature, you can click on File Functions in ServiceDesk's MainMenu and look down about nine items to the menu option titled Rolodex:

Either that, or directly use the suggested quick-key combo, Shift-F3. Upon bringing up the new interface, please note there is a button in its bottom-center area titled "open Mini-Manual." If you click on that button, it will open a little five-page handbook (same as via this link) that provides all needed details regarding how to use this awesome new feature.

Approximately one year ago, Whirlpool introduced a program (often abbreviated as "P4P") that financially rewards servicers if they meet a very simple set of metrics. Yesterday, a certain user suggested it would be helpful if servicers could analyze internally, to see how they are progressing on that precise set of metrics. Seemed very sensible, so we have a new report:

It is the very same set of metrics Whirlpool measures, but may be gleaned at any time you want from your internal, ServiceDesk data. This new report is available from within ServiceDesk's Reports form (F11). Simply go there, pick the 'Performance - Clients' radio button, then 'Pay for Performance.'

Technician Performance Reports -- Announcing . . . "The Mother of all Overhauls!"

We've long had a suite of "powerful" technician performance reports (five in all). They've been subject to occasional incremental improvements over the years, though nothing since their initial inception to (as my dad used to say) "write home about." Please notice, I put the word "powerful" in quotes. It's because these reports were drab, all textual, mono-color and with no graphics. Sure, they worked great if you happened to have the kind of mind that can look at a large quantity of raw numbers and easily divine real and substantive meaning from them -- but most minds don't work that way. So, not everyone celebrated these reports.

I took a first step toward major improvement with Rel. 4.4.43, just a while back. But that was tiny compared to what I've now accomplished. This release includes a true and major overhaul. It will produce tech-performance reports that, finally, are designed for the every man. The basic set of reports has not changed, nor has the data (with some few exceptions) that goes into them. What's really changed is the presentation.

As you can see, it's the same raw numbers at play, but the revised version presents them with a whole lot more pizzazz. And the pizzazz is much more than mere fluff. Color differences, between the first section and others, make much more intuitive the distinction between company-wide figures (i.e., "ALL" in the top section) and the figures in following sections that pertain to specific techs. The colorful and integrated graphs are even more powerful.

In such regard (and using this particular report as an example for potential analysis), please notice the four graphs in the top section provide company-wide (or ”par”) geometries for each key measure, and each tech's graph is purposely arranged to allow easy direct comparison. Glancing at the green graphs, for example, you can see that three of the techs in this report are performing well above-par in regard to total sales (CP looks particularly impressive). Their average totals-per-work-day (yellow graphs) mirror the same fact. However, one of the techs who's strong in total sales, is not so strong in average total-per-ticket (AV, blue graph).

The leftward purple/violet graph is particularly interesting in its ratio-type comparison between labor and materials sold. Glancing at this graph in AV's section may give an immediate clue as to why his average total-per-ticket is below par. It appears, simply, that in comparison to others he is underselling on parts. Perhaps that is all he needs to amend.

Anyhow, the general concept is that with the addition of such integrated graphs and other enhanced visual cuing, these reports can now be a joy to peruse, literally thrusting large elements of meaningful analysis into your brain (and at a mere glance), rather than making you toil to scavenge small elements of meaning.

All five reports in the Tech-Performance series (those reports in the F11-form and under that title) have been similarly upgraded, though the particular visual scheme in each is unique to its purposes. I urge you, please, explore these reports. I think you will be positively delighted by what you find. Please know, too, I have updated the corresponding On-Line Report-Handbook. There is a button to load this handbook in the bottom-right corner of the F11-form, but here also is a link. Discussion about these particular reports begins in that Handbook on page 14.

In regard to two of the upgraded reports (Technician Recall Rates, Unit-Info Method and Technician Recall Rates, Key-Word Method), I did much more than enhance the resulting visuals. In regard to those in particular, I totally re-did the underlying infrastructure. Formerly, these were reports that could take (depending on circumstances) a long, long, long time to run. They are now at least ten times faster. Better still, they're much more logical in their underlying methodology. I'm betting you're now going to be very fond of these reports. For details of what's different, please read in the appropriate section of that On-Line Reports-Handbook.

Now that we have truly outstanding visuals in regard to these reports, I'm betting people are going to want corresponding upgrades on other reports. Alas, my work never ends!

A while back (see entry accompanying Rel. 4.4.7) we added a spiffy new report in the (Ctrl-F9) FundsControl form. Called the Reconcile Items Collected Report, its purpose is to summarize all items of money as ostensibly received (typically on the prior day) -- for the purpose of comparing to monies as actually found in hand, to assure you actually got all the monies you were supposed to.

With this release, we add a beautiful new companion report. As its title (indicated in this section's heading) suggests, its purpose is to provide a summary of all items that were ostensibly deposited to the bank, within any period (typically, we expect, it will be used on a daily or weekly basis). This can: (a) provide a simplified basis for you to enter the amount in your checking ledger; and (b) provide an added cross-check for comparison purposes.

With addition of this report, we had to once again do some re-arranging of the option-selections as initially presented in the FundsControl form. There are now, simply, too many options to place in the initial listing. Instead, two of the initially-presented options will bring up sub-menu options. The one as applicable to this report is logically titled "Deposit-related functions.

Please note this is where to find the new report, and is also the place to now find the "Assemble Deposit" and "Confirm Deposit" functions, which used to be on the initial menu.

It's very difficult to please everyone all the time. It's also true, we've found, that while new users sometimes complain about ServiceDesk being too keyboard-centric (i.e., not enough dependency on the mouse), whenever we make an established function depend more on the mouse, established users quickly lodge a loud chorus in protest.

This happened in regard to the enhanced Checkoff methods, as introduced in Ver. 4.4.45 (see third item in prior entry, as pertaining to that release). In response, I've done the following:

(a) With the list of Checkoff statuses displayed (standard means to invoke is by doing a Shift-Click on the item, within the tech's list of jobs, you want to check off), you can use your keyboard's Up and Down cursor keys to move the mousepointer from one item to the next.

(b) With the mousepointer over any particular item in the Checkoff list, you can hit Enter on your keyboard to make the selection.

(c) There's is also a new/alternate means to first display the Checkoff list. With the mousepointer over a tech's list-item job reference (yes, this particular mousepointer positioning you must do with the mouse), hit Shift-Enter on your keyboard.

Hopefully, these improvements will allow everyone (on both sides of the mouse-vs.-keyboard divide) to be happy.

I should mention (while simultaneously placing a pitch here for two of our major supplementary products), I somewhat resisted making the investment (it consumed a whole morning) programming this very minor tweak. It's because, those of you who are still doing manual check-offs for routine dispatch-related events, in my opinion, should not be!

Optimally, requests for confirmation and check-offs of confirmation should all be handled via automation as facilitated via SD-CyberOffice. When you use that system as intended, these check-offs occur automatically, without any per-item effort required by office personnel.

Similarly, confirmation of dispatching to the techs, check-offs of arrival and departure, and check-off of PVR status should, optimally, all occur via automation with the techs as facilitated by SD-Mobile. In my humble opinion, you should not be consuming separate resources to manually handle these mundane (albeit important) tasks. Automation is much smarter.

To put it another way, this improvement involved polishing the edge on a tool which -- for the fully-advanced user -- has been largely superseded regardless.

Effective on this date, LG has ended its former "CLS" integration system (which provided direct integration, between servicers and themselves, on both dispatch processes and claims) -- in favor of a new system called "GSFS." It's our understanding they have also ended integration via ServiceBench. Most alarmingly, their new system has no "handles" to facilitate the direct integrations (for dispatch processes and direct claims transmission) that were formerly enjoyed. In fact, all that is available now, for integration (at least as we understand it), is the ability for you to upload claims via the old-fashioned file/batch-upload method -- though as connected to the new GSFS system (i.e., SD puts the claim information into a file, and you have to separately upload it via login to the GSFS website).

We don't know anyone that's happy with this, but (and at the least) here at Rossware we've provided you with a "just-in-time" update to facilitate claims creation in LG's new format. Assuming you make your first GSFS claims on the morning of Monday the 4th, we believe it will work. Our output has been tested with LG, and verified to be in the correct format.

So long as I was busy creating a new claim submission format for LG, I figured I might as well tackle another item on my long, long, long list of projects -- which was to create a submission format for Samsung (in case it's not obvious to you, every claim processing entity has its own format into which claim data must be forced; each format is unique, and it requires a lot of program coding to make the data conform perfectly to each).

In regard to this newly-added format for Samsung, I'm considerably less certain you'll enjoy immediate claim-submission success. Samsung's documentation (detailing what's expected for their format) is very sparse in regard to a number of the needed fields -- leaving considerable ambiguity in terms of what must placed where. I suspect further finessing will be required before we reach total success. This finessing will likely depend on feedback from you (we've had no direct testing with Samsung, such as we have indeed had with LG). I encourage you to use the on-screen NARDA's "Translation Tips" to see how, specifically, we are presently translating boxes from the NARDA into Samsung's claim format. Again, I'll look forward to your feedback.

Enhanced Appointment-Check-Off Scheme in DispatchMap -- Including New JobHasBeenPreScreened and JobHasBeenPostScreened CheckOffs:

Evolution is not always the best designer. Way back in the early days of the DispatchMap, we realized it would be good to have a "Check-Off" there -- to visually indicate, in respect to an appointment, if it had been dispatched to the tech (i.e., actually given to him, so it was known that he had it). We used an actual check-mark symbol for this purpose, and a simple Shift/Click action as the means for toggling an appointment to show it with check-mark, or not.

That was terrific, except we soon realized it would be nice to have a somewhat similar (but different) action and symbol to indicate the tech had actually arrived at an appointment, and another to indicate he'd finished there. So, we made added key/mouse-click combinations for these purposes (Ctrl/Click and Alt/Click), along with added associated symbols.

That wasn't too bad: three different (and simple) key/mouse-click combinations, and three different associated symbols. But if it's good to have indicators for those statuses, isn't it better to have indicators for more?

What about showing, for example, if an appointment's PVR was done. Hmmm. That means another symbol (or symbols), and another key/mouse-click combination to toggle. Now, with the simple key/mouse-click combinations already used, we had to resort to a more complex combination. We chose Ctrl-Alt/Click.

Still, a good concept can't quit growing. Before long, someone suggested it would be good to have a check-off action to show a customer had been contacted (typically the evening prior) to confirm their expectation of the next day's appointment. So, we added a "Confirmed-With-Customer" check-off (Shift-Ctrl/Click). Then, as people began using that, they realized it would be good to have a different check-off to indicate confirmation had been sought (i.e.,. voice message left by telephone, email request sent, CyberOffice processes initiated, etc.). We used Shift-Alt/Click.

Finally, someone suggested it would be good to check-off to indicate the tech had arrived on a job, only to face a "No-Show" by the customer (Shift-Ctrl-Alt/Click).

As you may gather, it reached the point where we'd used all the potential key/mouse-click combinations (see illustration of old DispatchMap Cheat-Sheet, about a page-down below), and if a user was interested in doing any of the check-offs manually (in truth, the need for this was typically limited by the fact many check-offs occur via automated means), it was a confusing combination of key/mouse-click combinations to remember. There was of course an always-on-hand, easy-to-instantly access cheat-sheet to remind, but still, the inelegance of all those combinations was undeniable.

In particular, many companies have a person who advance screens each appointment, seeking to predict if particular parts are likely to be needed (intending to send the tech out with such parts, if so). Some such companies asked for a check-off to indicate when such "pre-screening" had been performed.

Many other companies do what might be called "post-screening." That is, periodically throughout each day, someone in the office scans the DispatchMap looking for jobs on which the PVR has been done, but on which the job is not yet complete (i.e., those showing with a circle-X symbol). That person opens the JobRecord, and immediately orders the parts -- which, presumably, the technician requested. This is a rather brilliant practice, because it shortens completion times, and impresses the heck out of your customers. Anyhow, these companies asked for a "this-job-has-been-post-screened" check-off.

As noted, we'd already used all possible key-modifier combinations (as potentially combined with a left mouse-click; right mouse-clicks are used for other things) -- so there was a clear need to change our methods -- if we were going to accommodate such added check-offs.

What I've done is to eliminate all items in that former zoo of key/mouse-click combinations -- except the initial and original one: the simple Shift/Click. Now, when you want to toggle any check-off status on any appointment (in all cases, we're referring to its list reference under the tech to whom it's assigned), do a simple Shift/Click. In result, the system will display a list of all possible check-offs, and you simply must do one more click to pick the one wanted.

Please note that any appointment's existing check-off status will show in the list with a line through it. If you want to un-toggle that check-off (i.e, put the appointment back into a check-off status of nothing), click on the lined-through listing.

Besides the fact you can now use those two new check-off statuses, there is obviously much added simplicity. The DispatchMap's contextual Cheat-Sheet (right-click in any empty space to bring it up) reflects this.

In our view, a shorter Cheat-Sheet (that nevertheless accommodates more functions) is an improvement indeed.

Please note, if you're using SD-Mobile, it's important with this update to also update SD-MobileLink to Ver 1.3.33 or above. Prior versions will not know what to make of the new check-off statuses.

As mentioned in the prior entry, we updated the TimeCard structure, but had not yet updated the WageReport to work with the new structure. This created a brief window of time (turns out it was just two days) in which you could not run wage reports. This release fixes that (i.e., you can again run the reports, and they should work perfectly with the new data structure).

The Problem Customer Advisory (Alt-F11) no longer exists -- at least, not under that name. Turns out, we discovered, many people were using this tool to notate situations with customers who were not "problems." In particular, the tool was sometimes being used to denote customers who were VIPs, and deserving of special, red-carpet treatment. Given such broader use, we decided the name of the tool needed changing. Thus, it's name is now the Special Situations Advisory. You should feel free to use it in connection with any customer that needs to be flagged for something special or unusual in their regard.

The TimeClock function in ServiceDesk (via which employees may Punch-In and Punch-Out on electronic time cards) is one of its oldest functions, and had received virtually no modernization over the space of many years. In the meantime, upon creating a complimentary TimeClock function in SD-Mobile (a year or so ago), we deemed the data-format as used by the SD-TimeClock system too archaic, and so designed Mobile's system with an improved, more modern structure. In result, we had two incompatible TimeCard structures. SD's WageReport continued to work with the old format, while if you wanted to do WageReports for techs using Mobile's TimeCard, you had to open that data in Excel and do some manual work there. It was a situation crying for correction, and this release gets us almost there (the next release will complete the process).

Specifically, with this release ServiceDesk itself switches to use of the same modernized data structure, for each employee's electronic TimeCard, as SD-Mobile has been using for the last year or so. Upon first punching In or Out for any employee, the system will automatically convert that person's TimeCard file from old format to new (more specifically, a new file is made in the new format, with filename TimeClock.xx.TXT [where "xx" is the employee's two-letter abbreviation], and the old file is changed by appending the word ".OLD" to its name [thus changing, for example, TimeLog.xx to TimeLog.xx.Old]). All future punch Ins and Outs will now be done to the new files in the new data format.

The TimeClock form itself has also been substantially improved, for better overall appearance and functionality.

Please note the improved simplicity of now having only two buttons, and it's only the button that reflects the expected action that's enabled (in prior design, the "Okay" button did double duty for both actions, depending on the circumstance -- which sometimes led to be people getting off-synch, thinking they were punching In when punching Out, and vice versa). The new system also has a much improved method for coping with a forgotten prior-punch event (e.g., I need to punch In this morning, but it turns out I forgot punch Out last night, or vice versa). The old system would permit the present needed punch (via its bottom-center button), while leaving as unresolved the prior (and forgotten) opposite punch. With the new system, even though the unexpected of the two buttons appears to be disabled ("punch IN" in the above example) it will still accept a click. If you click on the disabled button, it invokes a dialog where a forgotten "punch" event can be manually provided. In this event the TimeCard file is appropriately marked to indicate that that punch was input manually (thus, as a manager you can know to potentially consider that punch as suspect).

There is one further element of work we did not get to with this release, and that is the WageReport. It has not yet been re-written to work with the new data format. We'll do another release, very shortly, that has that improvement.

It was, in fact, our effort to improve the overall set of reports as available in the F11 form that led to upgrading the TimeClock system, as above-described. Specifically, upon having made several other reporting improvements, I reached the point where I wanted to add a new report to provide specific comparisons between time spent on jobs by a tech as compared to time on-the-clock. To do this, I needed to finally unify SD's internal TimeCard use with what's in Mobile -- which led to the above-described changes. Prior to reaching that point, however, I'd already made several improvements.

In particular, all of the performance reports have been upgraded in some degree. There are presently six such reports overall. Two under "Performance -- Clients," and four more under "Performance -- Techs" (the illustration shows only the two headings, which must be clicked to see the lists of respective reports from which to choose).

In several of the reports, overall appearance has been changed for improved readability and understanding. In some cases, new figures have been added and/or tweaked. In all cases, we have added an "Export Check Data" function. It's a new button that will appear (to the lower-right within the form) as the report displays. If you click on the button, it will create an export file that contains elements of data as relevant to compilation of the report in question. It will even offer to open the file for you (typically in Excel). The purpose is to permit you -- if you have any questions about how the report figures resulted or as to their reliability -- to look at the actual data that produced those figures. You may, if you like, to further analysis on their basis as well.

Until now, there's been a significant potential nuisance when updating ServiceDesk. It arises if you're installed in thin-client mode, meaning a setup where several stations operate from a single SD installation. The difficulty is that the SD program file can't be replaced with the intended newer copy (Windows will not permit it) so long as ServiceDesk is running from any station that depends on that instance of the program file. Thus, it's always been necessary to close ServiceDesk at any and all stations that may be running from the instance of the program file one is attempting to replace. Particularly for large operations (i.e., with many stations) this necessity has sometimes posed a nuisance.

Our favorite geek here at Rossware, Matt, came up with a solution. Turns out, while Windows will not permit you to remove or replace a program file that's in-use, it will (at least on those systems where we've tested it) permit you to re-name the file. So, we've now re-programmed the little ServiceDeskUpdaterX utility to perform some behind-the-scenes sleight-of-hand." This is, essentially, the utility that opens the Winzip Self-Excractor update file after ServiceDesk closes following the update download, and re-opens ServiceDesk after the unzip. The new version of this utility does more. Behind the scenes (and without you even needing to be aware) it re-names the ServiceDesk program file (specifically, to "servdesk_temp.exe"). Thus, when the Winzip Self-Extractor seeks to replace the normal ServiceDesk program file ("servdesk.exe"), there is no objection from Windows because a file by that name is no longer there, and in the way. After the unzip, the temporarily re-named old file is deleted (no objection from Windows, since it's not the file that's being run from). We're pretty sure Microsoft did not intend to permit this loophole through which we're wriggling, but it seems to work regardless.

You will need a new copy of the ServiceDeskUpdaterX utility to take advantage of this improvement. It cannot be included in the standard download/update file -- by reason of the fact it's the very utility that must be running to facilitate opening of that standard download (and thus would be in the way of its own replacement). However, if you watch the dialog upon doing your next update (i.e., the next one after this one), it will coach you through this replacement. Either that, or do it directly now by downloading "Updater Utilities" from the ServiceDesk downloads page.

New "Customer's PO-Number" Field Added to ScheduleJobsReport-Type3 Export:

Password Protection (as described in first-preceding entry below) extended upon:

Password Protection When Changing Tech on Appointment Where Prior Assignment was Definite:

The caption pretty much says it. Until now, if in the DispatchMap you wanted to change the tech assigned on a particular appointment, the system would simply warn you if the prior assignment had been marked as "Definite." It would not prohibit the action. Now, besides a warning, it will optionally require provision of a password before allowing you to proceed. The default setting for this password protection is "ON" -- meaning, if that's your preference, just leave it as is. If your preference is against having the password protection turned on, you'll need to go the Security form and turn it off.

FYI, the immediate impetus in creating this was the need expressed by a company in Vancouver B.C. This company has each of their techs working directly in ServiceDesk via remote Desktop. We vastly prefer to see techs working via the SD-Mobile program. We have not designed ServiceDesk itself with any intent that technicians should work directly within it (well, outside the restricted TechWindow mode), but that is, nonetheless, how this company does it. The problem they were having was techs reassigning jobs, via the DispatchMap, for their own self-interested purposes. The solution we came up with was for all tech assignments, on appointments, to be made Definite, and to then password protect against changes.

In this regard, there is a connected/added new feature. To make the solution effective for the Vancouver company, they'll need to have the assignment status on all jobs set as Definite. For this purpose, there's a new default variance in the Create Job/Sale form, as follows:

We don't think picking Definite as the default will be optimum for any companies except those few that pursue practices such as the one in Vancouver. However, if you are one of them, it's there for you.

We have now completed a massive upgrade of Ticket/Invoice management within the Mobile context (includes features such as "Previewing and Editing, Separate Saves, Re-Loading Prior (and Appending with Present), Save-Same or Save-New," etc.). The Mobile-side elements are described, in depth, in the most recent entry of SD-Mobile WorkDiary, and we encourage you read there, for full understanding.

On the ServiceDesk side (and as announced a couple of releases back), there's a new Mobile form, as one of the options within the FinishedForms (Alt-F4) context. It can be used to review any/all tickets as created within the Mobile context, to revise them for re-use by Mobile, and even to create new tickets, in house, for use by the tech when he goes out later on a job.

Perhaps most usefully, the new FinishedForms Mobile ticket can be used to facilitate making a SaleJournal entry, direct from the Mobile ticket -- eliminating any and all need for an operator to re-type figures as already created by the tech in the field.

One is that, unlike the other FinishedForms, the new Mobile one does not presently offer to import data (into its various boxes) from underlying ServiceDesk data (as do the other forms).

The second caveat concerns a matter of slight ambiguity, when using the Mobile ticket to populate a SalesJournal entry. It's a question of which of its summation figures (Parts-Total, Labor, Other, Sales-Tax and Total-Ticket) get translated (aka "mapped") into which fields of the offered entry. In particular, while the Mobile ticket has a Labor and an Other field, the SalesJournal entry has a ServiceCall and OtherLabor field. It's not necessarily obvious how these fields, with their disparate labeling, should correspond. The answer is, (as presently programmed) they feed in the sequence as just recited. If you need different "mapping," please let us know.

A tiny further caveat is that versions of SD-Mobile prior to 1.3.18 did not include a dedicated InvoiceNumber field, and in consequence will not show up via this new path in ServiceDesk. In other words, any Mobile ticket created in Mobile Ver. 1.1.17 or older will not be offered for you an SD Mobile ticket.

Though Windows is a nice environment to program in, not everything is perfectly easy. With ServiceDesk's layout in particular, it's been a challenge to make sure the four Callsheets consistently fit with perfection within the framed space. What makes it difficult is, depending on preference settings in Windows, the thickness of the surrounding border can vary, as can the caption bar height, and also menu height. If all were known and constant, it would be easy to set an external size that would perfectly accommodate interior elements, with confidence all would consistently fit. But the sizes vary, and it's a matter we've somewhat struggled with (in result, you may or may not have noticed imperfect fits of the Callsheets within their spaces). With this release, I think we've got it perfect, and you'll likely see the Callsheets fitting perfectly in place, regardless of your preference settings.

Six weeks ago (and amid significant fanfare) we introduced a near-instantaneous, single-click method for obtaining a warranty-entitlement and product-history report, on virtually any Whirlpool Corporation-related product. A short time later, we added the same capability, for techs, in SD-Mobile. In either context, it's great -- albeit subject to a small limitation. The entitlement info, as provided by the standard inquiry, is less detailed than may sometimes be wanted, particularly with respect to extended warranties.

To address that limitation, we've now added a second inquiry. Access to this new function, like the original, is via a button on any applicable UIS sheet (i.e., within the UnitInfo form). In fact, we've now fit both buttons into the same space as the original:

As you can see, we've also colored the buttons, to more effectively distinguish them from others on the form. Please go ahead and try the new button (it's the one labeled "SB Web Inquiry"). Be sure to do it on a UIS that involves a Whirlpool-related product. You'll see it opens a very nice web-page that contains a lot of entitlement-related data. Unlike the other inquiry, however, there is no product history. It seems that no matter what (and like the saying goes), you just can't have your cake and eat it too.

Do you ever have to write something, and you just can't figure out how to do it?

That was the case with me, some ten years ago, when I first wrote the manual's section describing how to use the Special-Order PartsProcess system. I knew how it worked, but for some reason could not think of a good strategy for communicating my understanding. In the absence of a better solution, I settled on a description I always knew was lousy. And, I apologize. I think many users have had a tougher time, getting the essence of how to use that element in the system -- than they otherwise would have -- if I'd managed a better description.

The good news is, I finally did it. Though many times (in the intervening years since) I've wanted to do the re-do, it was not until now that I mustered the energy, time and vision to finally make it right. I think the new section does a very nice job. It will be found, contextually, in future publications of the manual, but you can also access it as just an excerpt, right now. I've added a button for the purpose in the top-left corner of the PartsProcess form:

Or, if you want to check out the new section without first going into ServiceDesk, here's a direct link.

ANOTHER MAJOR DRUM ROLL PLEASE . . .
Single-Click Parts Inquiry and Pricing – via Revolutionary MyPartsHelp Service:

Here at Rossware, it's our goal to do stupendous things, and on a frequent basis. Usually, we do pretty well via offerings produced totally “in house.” Sometimes, however, the most awesome stuff involves partnering with others.

Within the last year, for example, we partnered with Merchant Warehouse for integrated credit card processing, then with Whirlpool/ServiceBench to provide single-click warranty entitlement and product history reports.

With this release, we announce a new partnership – with possibly the most awesome result yet.

For background, over the last year a group of your peers (other retail-level servicers) pooled their financial resources to develop a new technology, and a new company to manage it. The company is Service Company Solutions, LLC. The technology is called MyPartsHelp.

Quite simply, it links with ServiceDesk, and on the basis of a single click connects to each of your preferred vendors to inquire about pricing and availability on a given part (i.e., the part you clicked on, within ServiceDesk). It displays the result back to you inside of about one second. Really, you won't believe how effective it is, until trying it.

For each vendor, it not only shows if they have it; it shows how many they have, and at each of their locations. And it's not the vendor's standard/published price that's shown; it's your own particular account price. That's not, remotely, all.

Another click (and just a couple seconds more) shows you nationwide availability on the part. It does so by polling vendors from around the country. You won't believe how often you're able to find NLA parts or someone who's stocking an otherwise backordered item – with just two clicks, and less than five seconds wait time.

You likely know about RepairClinic.com, and how when you lookup a part on that website you're instantly provided with a set of very clear photos showing the part from several angles (dramatically helps to reduce mis-orders). Guess what. That same set of photos shows (along with everything else) in the MyPartsHelp, single-click lookup. On top of that, as one of your MyPartHelp membership benefits, you can order those can't-possibly-get-anywhere-else parts at 15 percent off the price everyone else must pay.

I am (and, as in a few other instances, I apologize to those of you who are in fields other than appliances).

On top of all the other good news, the MyPartsHelp service is downright cheap (about $20/month). Even better than that, it costs nothing to try (also, in a while it may also be available in the electronics field, and after that, who knows?).

There is. Right now you have the opportunity to get in on the ground floor. For a brief time only, MyPartsHelp accounts are being offered in beta (which is why the pricing is presently so low). Features are great already, but are destined to grow, and pricing may too. I suggest getting in while it's cheap.

Or, better yet, let ServiceDesk take you there. For this purpose, open your ServiceDesk PartsProcess form (Ctrl-F8), and right-click in the colorful label area at top to display its contextual "CheatSheet:"

Now pick the menu option labeled "MyPartsHelp Setup." This produces an option where you can choose either to link to the MyPartsHelp account setup page, or to enter your MyPartsHelp login credentials. First, of course, you'll need to do the account setup (after all, you'll have no login credentials until you do). After that's done, go back to the same venue -- only this time choose to enter your login credentials. Now, pat yourself on the back, and say Hurrah, because you're ready to use MyPartsHelp.

Just do the normal stuff, that you'd normally do, within the ServiceDesk PartsProcess form (i.e., responding to internal requests to acquire parts that are not stocked, as displayed for you via line-item listings within that form). Only, when you're looking at any particular line-item (and with part number already determined and inserted), don't go to a vendor's website to ascertain availability and price. Don't call. Don't email or fax an inquiry. Instead, just do a simple Ctrl/Right-Click on the part number.

That's all it takes, and -- inside of a second -- you'll see the magical result!

This is an image capture -- from an actual, single-click display result (assuming particular vendors, as shown, where setup as those preferred, and with a particular servicer account number for each vendor, etc.). Actual pricing is blurred, because the actual page (as used for this image) showed pricing as specific to a particular servicer's account.

Please notice, among other things, only Automatic Appliance has this part in stock -- a fact MyPartsHelp reveals inside of a second -- instead of forcing you to spend who-knows-how-much time making who-knows-how-many-telephone calls otherwise seeking to find it. Please notice, further, there's a "Nationwide Search" button in the top-right corner; if the initial display had not shown any vendor stocking it, the Nationwide Search would stand a good chance, still, of doing so. Finally, please notice it's only for your preferred-setup vendors that the system displays cost; MyPartsHelp is intended as a lookup tool only -- not as a price-shopping tool.

Assuming you're an appliance servicer, please, do not fail to do this. I feel certain you will love the service. It's going to be great for your business.

Hopefully, you are using the Virtual Terminal feature (internal credit card processing) that was added (both in ServiceDesk itself and SD-Mobile) many months back. If not, be assured that you should be using it. It will save you money, directly, via reduced merchant fees. It will save you, indirectly via reduced time in conducting transactions, and because of increased accuracy resulting from its direct integration with other processes. It will also make it just a lot more fun, convenient and easy to conduct credit card transactions.

As one element in that system's design, we made it so each station in ServiceDesk could be configured with a different set of merchant credentials. This was, in particular, to accomodate the situation where you may want to use a different merchant account at different SD stations. However, that's certainly not the typical case. For most users, it's nice to have the same credentials setup at every station, and a nuisance to have to individually enter at each

With this release, that nuisance is eliminated. When the user at one station saves credentials, the system offers to make the same credentials available to other stations. From the point forward, if at another station you even click in a box to begin entering credentials, the system will offer to insert the other-saved credentials for you. By this means, we preserve the potential to have unique credentials at particular staions, if wanted, while simultaneously making it much easier to enter the same set at each station, if that is preferred.

New MyCriteria Feature allows you to create your own Add-On-Info Template for Callsheets and JobRecords:

A few releases back (with Ver. 4.4.24) we announced improved formatting in the general Callsheet/JobRecord interface. Among other things, a new button was added:

We explained that, though this new button did not yet have a function -- in fact, the whole design improvement had been undertaken for the very purpose of accommodating it (or, more accurately, the function it would ultimately fulfill). We promised to create that new function soon (i.e., to give the new button its purpose).

Rather than taking space, here, to describe details, we'll instead link you to a new little Handbook that describes both purpose and implementation. The purpose is described on its first page. If it's not a purpose you want to pursue, that's all you'll need to read.

MAJOR DRUM ROLL PLEASE . . .
Single-Click Service Entitlement and Product History Inquiries via ServiceBench:

For the last three months, or so, there's been a new (but inoperative) button in the UnitInfo (Shift-F12) form. It's been there, with ready-to-go machinery that's designed to let you request -- with a single click -- service entitlement and product history from ServiceBench -- specifically, as connected to any products fitting under the Whirlpool umbrella (e.g., Whirlpool, KitchenAid, Maytag, etc.). We've been waiting, essentially, for the "switch" to be turned on at ServiceBench.

Now, in the ServiceDesk UnitInfo form, that new button is NOT inoperative any more:

Try it. So long as you have a valid Whirlpool account as registered with ServiceBench (and assuming you click on this new button when an appropriate Whirlpool-family product is displayed), you'll quickly get a response from ServiceBench, giving you beautiful information. The UnitInfo form expands vertically to display it for you, as follows:

For those of you who are in fact Whirlpool servicers, may I suggest giving great thanks to your Whirlpool rep for the fact Whirlpool worked behind the scenes, with ServiceBench, to make this great capability available.

Further improvements in Archived-PartsProcess, including a New PO-Number Search:

In conjunction with the last set of improvements (see prior entry, first-item below), we'd intended to add a new search option to the Ctrl-F8 archived-PartsProcess environment: a search on your own purchase order number. Sadly, we discovered this particular element of data was not being saved in the archive -- a matter that had to be addressed before a meaningful search could be created. That is done with this release -- meaning that new search is now also available:

While we were at it, we improved editing in this context a bit more. In particular, when you click on an item to edit (and then the edit boxes display), the boxes that are not going to permit an edit will show in grey rather than white, providing an on-its-face indication of non-editability.

As with the last entry, please note there is also a caveat here. The searches on your own purchase order numbers will only work for items archived after this update.

By their nature, archived records are usually at least somewhat resistant to editing. This is because we deliberately pack the data tight, to minimize resource usage. Even so, it's been our practice to expand editing opportunities when users express a demand for it. In this regard, editing is now more available -- as compared to before -- in the Ctrl-F8 archived-PartsProcess context. Regardless of how many characters were there when archived, you'll always have at least 50 characters of space available in the Notes section, at least 16 in the PartNumber section, and at least 16 in the PurchaseInvoiceNumber section. Additionally, any of the date and/or numeric fields will be fully editable (at least, assuming you're appropriately using a numeric or date value).

Please note there is one small caveat. The extra space for editing will apply only to items as archived after you've made this update. In other words, older-archived items are still packed as tightly as before, and will not offer the extra edit space.

There's long been an option in the DispatchMap's DispatchOptions menu that produces, for applicable jobs, essentially the same output as offered directly via a JobRecord's PrintOptions menu -- and (for the latter) under the title "Job Description/Report." However, labeling for that option in the DispatchMap was not remotely similar. We realized it would aid clarity if it was. So, it's been changed in the DispatchMap's DispatchOptions as follows:

As you'll note, the quick-key letter for this option has been changed from "F" to "J" (please pay attention if you've been using "F"). Also, the option has increased power. It used to be, when you picked the option and the SelectPrinter dialog box came up, there was no option (i.e., from within that box) to choose email. Now there is.

Since (basically) forever, ServiceDesk has had a "Tech-Window" mode. It's a mode into which you can put ServiceDesk that's designed to limit its interface only to those locales that you're likely to want a technician to access (PostVisitReports, JobHistory searches, etc.). You can place it in this mode by hitting Alt-W on your keyboard (think "W" for Window), or, from the Settings form, you can even specify that a particular station will automatically go into such a mode immediately upon startup:

Recently, we've had some users that wanted to limit the SD interface, at certain stations, to just those ServiceDesk interfaces that relate to parts management. So, we've created a new special-Window mode for that purpose (it's called, aptly enough, "Parts-Window" mode).

As you can see below, we've now modified the Settings form so that you can (if desired) make a choice between having a station auto-start itself in Tech-Window mode or Parts-Window mode, if either happens to fit your need.

Likewise, you'll notice that now if you hit Alt-W on your keyboard, you'll get a choice as to the type of restricted mode you wish to enter.

Just like in the Tech-Window mode, the new Parts-Window mode requires use of a password if the user wishes to exit back into the full ServiceDesk interface.

Substantially Upgraded Interface for Callsheets and JobRecords, Combined with New Button for Expanded Future Capability:

Over the years I've received a number of requests for the ability to attach various kinds of added information to Callsheets (of course with expected carry-through, of such info, to the JobRecords that result from them). There have been so many different requests -- for so many different kinds of added information -- that, to individually accommodate all that's been asked for, we could potentially have a Callsheet (and associated JobRecord) design that is three times as large and with ten times as many boxes in it. Since that, of course, is not practical, I have sought another solution. I've decided the general strategy will be to allow customization of input (i.e., you design the added info you want) as triggered by a single new button on these forms.

First step in going down this path was to assure I could artfully accommodate that new button (these forms are already pretty crowded, after all). I began experimenting, and one thing led to another. Via a little re-arranging, I accommodated the new button nicely, and (I believe) improved organization overall.

As you'll note, the new button (bottom-right) is labeled "Criteria." It is not yet functional. That's another step down the road.

Also, the old MoreInfo button, instead of being labeled "Empty" when no contents are present (and "Yes" when there are some), is instead merely labeled "Notes" (just as before, however, it will turn a "warm pink" when contents are present).

Aside from the new button, notice that origin information is now at the top, which is a bit more logical than having it near the bottom.

While I was in the process of doctoring these aesthetics and organization, it occurred to me I might improve the visual cues as involved in a page of Callsheets that involves one or more Callsheets not-yet-used, one that is not-yet-used but has the Windows focus (and therefore is primed for use), and perhaps one or more that are used. By "visual cues," I mean making more intuitively obvious the distinction between these varying Callsheet states. You'll see the result after updating, and I'll not comment further here.

New export provided in ExportCustomerData form, new Handbook about exports, etc:

Over the years I've been very amenable to creating new exports for particular items of data, whenever something new was wanted. In result, ServiceDesk offers a ton of exports, with interfaces (to access them) spread contextually over a multitude of areas. There are so many that even I can lose track, particularly in regard to knowing what are the detailed fields that each export offers.

Recently we had a request from Whirlpool-NarSouth (it's Whirlpool's Latin America division) for several added fields as connected with an export they've been using. They did not identify the particular export, and the only other basis I had to determine which was by running a bunch of exports to see which matched, or by looking laboriously in my program code. Neither was an attractive solution, so I decided better clarity into the exports picture was needed.

To that end, I've created another little "Handbook." If you've not noticed, I've grown rather fond of these in the last couple of years. They're simple little documents that describe a particular area of interest, and can be contextually opened from places within Rossware programs, as needed.

This handbook is called, simply, Exports as Provided in ServiceDesk. As you can see, a simple click (on the link here) will open it for you.

Once having that little handbook assembled, I could easily see that the export in present use by Whirlpool-NarSouth was the ScheduledJobsReport-Type1, as accessed via the ExportCustomerData form (Alt-F3). Given that that export was working well for those employing it, I decided to leave it alone, and create a new export called ScheduledJobsReport-Type3. If you check the handbook, you'll see this new export has "really a lot" of fields -- so many it can be employed for all kinds of fun analysis, if you're so inclined.

While I was at it, I made several other improvements in the ExportCustomerData form, including substitution of the former 'Exit' button (who needs that?), with a button to load that new little handbook:

If you run the new export right with this release, you'll find that three of the new fields are not yet functional. That should be addressed soon.

New integration with DealerInventory via as-you-type dropdown in POS context:

This is for those servicers who are also dealers, and using our SD-Dealer serialized inventory control program. Until now, when you were selling dealer items and using the ServiceDesk POS to do it, the method for inserting items to the POS form (e.g., I'm selling a refrigerator) was to select the items (as being sold) via the SD-Dealer interface, then in the ServiceDesk POS do a keyboard Alt-D function (think 'D' as in Dealer). This would insert, to be sold, each of the items you'd selected.

When, in the POS interface, you click into any box in the part-number/model-number column, and when the little 'Integrate input from' box comes up, go ahead and select "Serialized Inventory."

Next, just begin typing any model number (as exists within your inventory) into the part-number/model-number column. You'll see a dropdown, as illustrated here.

Select from the dropdown just as you would if picking a part from the internal parts inventory or SmartParts dropdowns. You'll get an insertion, just as nice.

Prior to this release, the menu options in the archived PartsProcess form (Ctrl-F8) looked like this:

We had requests for a couple of new search capabilities -- specifically, to search via Vendor-Invoice-Number and Vendor-Name. To accommodate this, we re-arranged the menu, as follows:

As you can see, the new search methods have been added near the middle. There has been a little other re-arranging as well, and some of the QuickKeys have been changed to accommodate the new lineup (for example, a Customer-Name search is now "C" rather than "N"). Please pay attention if you're accustomed to using the QuickKeys on any item now changed (we know, you'll have to do some adjusting, but sometimes that's the price of progress).

Of particular note is the fact old items 1 and 2 are now gone (for specific-page choices, only "Last page" remains). We figured those were little (if at all) used options, and the first page can still be quickly accessed simply by picking "Last page," then using the Windows universal First-Page command (Ctrl-Home).

For some time there have been exports available from the DispatchMap for basic schedule information. Just display the map for any not-in-the-past day of interest, then hit Alt-P on your keyboard. In response, you get this set of options:

The two as circled are self-explanatory, and have been used by some servicers to create a list which then feeds into an auto-dialer program to automatically telephone customers with an electronic voice (sometimes called "robo-calling") to remind them about the next day's appointments. One difficulty for such users has been that ServiceDesk format for indicating an appointment (e.g., "31 MON 2-5") is not easily translated, to voice, by robo-calling programs.

To be candid, we've felt slightly reluctant to help with this -- based on conviction that our CyberOffice method of reminding is infinitely more modern and efficient.

However (and following Burger King's "Have it your way" motto) we believe in accommodating whatever methods of operation our clients choose (at least mostly). For that reason, we've added three new fields to the above-exports, as illustrated here:

To again emphasize, we think you'll be much better off using CyberOffice to confirm your appointments, but if you insist on using a robo-caller, these new fields should help.

A new user (thank you Jeff, at Intrepid) asked for a function that would print a Dymo-type label for attaching to merchandise that's in the shop for repair. It seemed logical to add this to the set of options as offered via the 'Print Options' button in the (F7) current JobRecords form. In fact, we needed to do an overhaul in that option set regardless.

The reason is, among the existing "print" options, there was one to print a Job-Description/Report, and another to email the same. Though differing only in respect to where the text went (i.e., printer vs. email), the two options were (illogically) not even next-to one another in the list of choices. On top of that, there was no longer a logical need to have the emailing option as a separate item. This is because, since it was placed there, we'd developed a more uniform method of offering to email an otherwise printable item, as opposed to sending it to the printer. This new method is via the PrinterSelect form itself (see entry accompanying release 4.3.97 for info on how and when this form was enhanced to allow such flexibility).

As you can see, the email option slot is replaced with the option for the new feature (which, really, is what this Diary entry primarily announces). Now, if you wish to email a Job-Description/Report, you'll pick the general Job-Description/Report option, then, in the resulting PrinterSelect box, just indicate that emailing is the method you want to use.

It's configured solely for the Dymo 30252 label, as printed from a Dymo printer. That's all you have to know. Aside from that, just use it.

There's an interface few people ever use. It's called the ScheduleList-Archive form. It is available under the 'Dispatch Operations' heading on the MainMenu (i.e., no quickkey). In the very early days of ServiceDesk this form had significant use, but other and better functions have relegated it to near uselessness. Nevertheless, we recently had an odd need to see, in table format, contents of the ScheduleList-Archive file (this is where your DispatchMap looks when displaying appointments for past days). Until now, this vestigial form only allowed the ability to search within that old data. For our own needs, we added a full-export function. It's now available from within that form, should any have any need to use it.

We've had a few people who wanted a separate export, for use outside of ServiceDesk, where they could quickly review what happened, for each tech, in regard to each of the jobs assigned to him on a prior day. That export is now available. To reach it, simply go to your DispatchMap (F5), and "PageUp" to the past day of interest (typically, it's likely to be just yesterday). With the day-of-interest displayed, hit Alt-P on your keyboard. That will expose a PrintOptions dialog box, now altered as follows:

The circled item is the new option. Just pick it, and follow the dialog to create your new export. You'll see the resulting file has fields for applicable Date, InvoiceNumber, Customer Name, Tech, Start Time, End Time, Money Collected, Whether the job was completed, and the Descriptive narrative as pertaining to his PostVisitReport.

Long ago we added a method in the UIS form (Shift-F12) where you can easily printout a complete history of service involving a particular machine -- even if the machine happened to have been serviced for a succession of different owners and/or at a succession of different addresses. It's a very nice looking (and informative) printout. To get to it, just find and display the particular UnitInfoSheet that's applicable to the machine in question then click on its 'Show All Linked Jobs' button [1]. This displays a little listing of Invoice Numbers referencing each applicable job [2]. You've always been able to click on any such reference to see the job, or to click on the 'Print Summary' button at bottom of the list [3] to create the above-described printout.

Now, when you do the above and the Printer Selection dialog box comes up, it has a new section that can be checked -- for the sake of directing the output to email instead of (or in addition to) a printer.

Make your choice just the same as you do in any other ServiceDesk context that offers this kind of option.

General Electric has long had a "contract service" program via which they dispatch for service repairs on non-GE products. Many ServiceDesk users are involved in such work, but we only recently became aware there is a problem when auto-filing claims for that situation. The FinishedForms auto-claim-formatting system was designed to list, as "manufacturer," whatever is applicable to the brand of machine being worked on. For OEM warranty work, that strategy is perfectly successful. However, when in a situation like that involving GE contract service (and assuming the underlying machine is not a GE product), it fails. This is because KPI/ServicePower uses the "manufacturer" field to determine which of their clients is ultimately paying.

So (and in short), under our longstanding strategy, if you worked on, say, an LG product under a GE service contract, KPI/ServicePower would end up interpreting your claim as being one for reimbursement from LG. Since LG is not a KPI/ServicePower client, you can't imagine (or perhaps you can) just how fast this resulted in rejection of your claim.

To fix the above, ServiceDesk will now look at the CustomerName (i.e., top box in the underlying JobRecord) to see if it is rendered as "GE," or if it contains the strings "G.E." or "GENERAL ELECTRIC." If it finds any of the above, it will configure your claim to list General Electric as the "manufacturer," even if the underlying "brand" is LG, Whirlpool, Maytag, or whatever (and don't worry, for there is a separate "brand" field in which the actual brand will still be listed).

As it happens, a very similar situation exists with respect to ServiceNet. This is another KPI/ServicePower client, and as we understand it is the entity that took over Maytag service contracts after Whirlpool bought the remainder of that institution. Just as with the GE contract service situation, for a successful claim, ServiceNet must be listed (in the underlying claim string that ServiceDesk assembles) as the "manufacturer," in spite of the product's actual brand. To accomplish this, please be certain that the underlying CustomerName (in any applicable JobRecord) is -- simply -- "SERVICENET."

By special request, the Parts Usage Rates Report (menu option from Ctrl-F8 form) has a new field: Make. You can also sort on this new field.

For several years, we've gotten phone calls with people wondering why PartsProcess items (F8 form) -- where they've ordered the part, checked it in, and used it -- do not get moved to the archive. Over and over, the answer has been because they were failing to put in the 'Sell-For' price, and the system was waiting for this little duty to be performed. With this release, you can now choose whether the system waits, or not. In fact, from this point forward the system will default to not wait. In other words, the new, unless-you-change-it-otherwise protocol is that the system will not require sell-for pricing, and will go ahead and archive when everything else is done, even if that element is not.

If you have any desire to change this new default, it's easy. Just bring up the PartsProcess form's "CheatSheet" (right-click anywhere in the colorful label area on top), and click on the new provided menu option:

In response, the system will present a dialog where you're permitted to choose whether 'Sell-For' pricing is required, or not.

Someone pointed that, if you're looking at an archived-JobRecord that includes several (or a single large) AttnNote, such notes will typically cover significant portions of the narrative history, making the latter difficult to read (until and unless such notes are slid out of the way, which may leave them in a position different than where you ultimately want them, unless they are slid back). Now, to bring the historical narrative to the front, simply click down on it with your mouse, and hold. It will remain at the front (i.e., AttnNotes hidden behind) until you release your mouse button.

'Notes' Box in MasterPartsPlan's Supplemental-Info box Now Hyperlink Enabled:

The title says it all -- at least in regard to this enhancement. I'll take this occasion, though, to remind that for any textbox that you wish to have hyperlink-enabled, it's pretty simple underlying programming to for me to make it happen. Just ask.

The DispatchMap has long used a series of symbols, displayed next to each appointment's reference, to indicate the status the appointment is in (i.e., whether confirmation has been requested from the customer, whether confirmation has been received, whether dispatched to the tech, whether the tech has arrived, finished, and/or completed his PVR, etc.). If you did not know, from your DispatchMap you can display a Map Legend (or Key) to show and explain each of these symbols. From the DispatchMap, simply strike 'K' on your keyboard (for Map Legend/Key), and you'll see the following:

At least, that's what you would have seen prior to this release. If you try it with this update (or later), however, your Key to Symbols will look like this:

As you can see, there's a new symbol. It's a red diamond, and is used to indicate the technician encountered a customer-NoShow when arriving for the job. The thinking is, if your dispatch manager is appropriately keeping tabs on the progression of jobs throughout each day (via the DispatchMap), the red diamond will allow her to easily see when and where a tech has been "stood up," and realize in such instances the tech may very likely have capacity for added jobs.

Please note the above symbols are specifically what's used next to each appointment's list-based reference in the DispatchMap. In addition to such variations in the listings, there are also variations in how the small-rectangular geographic references are displayed -- depending on CheckOff status (e.g., when a tech is at a jobsite its geographic reference shows with a yellow background; if he's completed the visit but has not done a PVR it shows with a large X through it., etc.). To designate this new "NoShow" status, the geographic reference will display with a single slash through it (as seen toward the top-right corner of the following illustration):

As a final note of explanation, please be sure to realize that, as a general rule, these CheckOff statuses are managed for you, as you simply do appropriate underlying actions in ServiceDesk (i.e., with each action, SD appropriately changes the CheckOff status for you). For example, if you do a PostVisitReport and appropriately therein indicate the customer was a NoShow, the appointment's status will automatically be so marked within the DispatchMap. However (and as a potential exception from this), if you ever need to manually change an appointment's CheckOff status, that ability is also there. The DispatchMap's 'Cheat-Sheet' (available by right-clicking in any empty space therein) has full details per subsection below circled:

Just look for the handy reminder-of-method there, if you ever need to do a manual CheckOff status change. Otherwise, don't worry about it.

I've long been slightly embarrassed by the UIS form. In its initial design, I followed the more typical database-interface conventions (instead of going more my own way as in every other SD context). Thus (and for example), if you wanted to edit an existing record in that form, you had to first click on an 'Edit' button. And there was an explicit 'Save' button for saving edits. Pretty much everywhere else in SD, you just make the change you want. It's bothered me that the UIS form has these extra encumbrances, and I've long been anxious to bring it up to the prevailing SD standard. That is done with this release. Gone are the 'Edit' and 'Save' buttons. Now, to make a change, just do it. And don't worry about saving. It's automatic.

When printing statements in ServiceDesk via the A/R-Dunning form (Ctrl-F3), the printed output has always been in the same sequence that line-items are displayed in, which is oldest A/Rs to newest. We had a request to make the statements print, instead, in alphabetical sequence (i.e., sorted by customer name). When you go to print the statements, there's now an option (in the Printer-Selection dialog box) to choose that result:

As all users know, unlike in any other service management system, ServiceDesk treats special-order parts as animals belonging on a totally different planet than do stocking parts (aka "Inventory"). We have entirely separate sets of machinery for managing these disparate animals -- so separate that (and to borrow a phrase) "never the twain shall meet" (at least, that's been almost true, though small connections have indeed been added over time).

Yes, we now have a very explicit (and strong) connection between those two worlds (Shift-F8 is the quick-key command).

At this point it has one major function. It is to address the situation faced by offices that carry inventory items, within the storeroom/warehouse, that are not stocked on the technicians' trucks. Until now, though there were mechanisms for dealing with this, they were less than smoothly streamlined.

Now the basic plan, when your office has a significant quantity of what we might call "extra stock," is to let your techs go ahead and "special order" items they do not carry on their trucks, even if such items are included within the office's "extra stock." Then, your office person will use the Part-CrossOver form to display such items. Essentially (and under its first-offered display category) this form's underlying machinery will go through all special-order requests. For each that are in needing-inquiry status, it will look to see if there is "extra stock" in the office storeroom/warehouse to satisfy the request, and for each such item display to the user. The user can then select items of interest, and employ mechanisms to generate a "Pull Items from Warehouse" request or a "Tech Acknowledge Receipt" form. He/she can further use mechanisms to check-off selected items as having been "Requested from the Warehouse," as having been "Moved to the Tech's Waiting Bin" or as having been "Moved to the Tech's Possession."

In other words, this form facilitates what is essentially a process of special-ordering from within the office's own warehouse (an internal special order, you might call it). With very simple clicks, it does all the underlying entries within each applicable PartsProcess record -- and where appropriate also interacts with the inventory system, to document items as used. It's a true integration between the two contexts.

We think usage of the form is mostly self-explanatory (at least with foundation of the above explanation), but we'll plan to write (and add) a mini-handbook regardless. In the meantime, please simply note that -- to perform any action on a displayed line-item (or set of line-items), you must first use standard Windows selection tools to select the particular line item (or set of line items) that you wish to include in the action. Then, simply click on a button to perform the action of choice.

Also please note the interface allows you to instantly sort on any column by clicking on column header (or to reverse-sort by clicking a second time).

If you're ordering a part and indicate a 'Request' status of Tentative, the system will now offer to put the Job into 'Pending Autho' status. If further provides the option to have this happen in all such cases automatically (i.e., versus in the present instance). And, if you don't want the option at all, you can choose the 'Don't show me this again' option. Numerous other small fixes.

Miscellaneous fixes and improvements (both for this release and preceding, which has no note). A somewhat notable improvement, with this release, is that now if you're doing an update and inadvertently UnZip to c:\sd (even though the correct path would have been elsewhere) the system will detect your error, and help you fix it. Another matter: you can now add notes to the archived PartsProcess records (but only for items archived with this version and newer).

(1) There is now a very nice document that explains the general purpose and methodology behind each of the various reports, as available from within the Reports form. There is also a new button, within the form, that will open this document for you:

Just click on that new button, and the new on-line "Reports" handbook will open for you.

(2) There is a very nice enhancement to the Tech's Performance "Percent of Completion" Report. Besides the figures previously provided, that report will now provide 'Total-Completes' for each tech, 'Avg-Completes/Bus-Day', and "Avg-Days-Start-to-Finish'.

(3) Made significant improvements 'Export with Extended Data' feature. Among other things, it will now better-treat Paycode 4 and 5 inclusions.

Found and fixed a fault in the "Tech's Time On Job" report. This fault resulted in the fact that, for some situations, applicable visits failed to show up in the report (this resulted in under-counting; in some situations it was potentially severe).

Found and fixed a fault where, when a JobRecord is archived, the system failed to copy to the archived version more than one Hyperlink/StickyNote (i.e., any quantity greater than one was simply dropped).

Found and fixed a fault where, when doing a SalesSummary as connected to a particular department, the Adjustments sections included erroneous numbers that did actually pertain to the department in question.

Two releases back we announced a new feature, in the MasterPartsPlan, for auto-removing items that are no longer wanted in stock. There were actually a couple of variations on the option (from which you'd choose, as a user, when picking it), but almost immediately someone pointed out we'd missed one of the most logical: to remove only items where both specified minimums were zero and items remaining in stock were also zero. That option is added with this release.

This was a bigger project than I'd hoped. The idea is, you need a quick summary of all the items of money that supposedly came in, during a given day, so you can make sure you actually have such items at the end of the day. More concretely, you need a list of all the items of money that a tech should have turned in, so you can make sure all such items were in fact turned in.

It's not that we have not previously had very robust mechanisms for assuring that all items of money do not eventually reach the proper location, and, if not, that you're informed of it. We've had such mechanisms since long before ServiceDesk was first marketed. But, we've lacked anything designed with the specific immediacy of direct purpose as described in the first paragraph.

But not anymore. In the FundsControl form (Ctrl-F9), there is a new radio-button (in grouping or radio buttons in the top-right corner) labeled "Reconcile Items Collected." Please simply click on the button, and follow the prompts. This is a feature many of you have asked for, and we think you'll enjoy it.

As an aside, you'll notice we've re-arranged the buttons on this form, slightly, for improved simplicity and logic. Please notice, in particular, the "Search/Find" function has been changed from a radio-button (in the top-right corner) to a command button (in the bottom-right corner).

First, we've simplified the button set as offered in the bottom-right corner of the Ctrl-F10 form. There were seven (so many as to make confusion more likely). Now there are just four, including one entitled 'House Keeping . . .' Four of the buttons that were formerly on the face of the form will now appear as a subcategory -- when this 'House Keeping' button is selected. They are items that reasonably fit under such a "catch-all" description.

A new operation was also added (it's the fifth item in the new sub-category and is labeled 'Remove No-Longer Stocking Items'. What it offers is sort of a cleanup process. If, for whatever reason, you find yourself with a MasterPartsPlan that has a lot of entries for items you really do not want to stock (and, for such reason, you've set the minimums at zero), and now feel you'd like to remove those items from the listing -- but there are so many it would be laborious to go through and do each individually -- this new button offers a solution. It will run a process that does the task for you. Plus (and optionally), if you still have any actual items in inventory, it can create PartsHotList entries for them -- which can then serve as a means of, hopefully, getting such items used in the future, even though (and so far as official accounting is concerned) you've "removed" them from inventory.

Another enhancement is a new sorting scheme. If you pick the new 'House Keeping' button, then 'Set Sorting Scheme', you'll see that among the schemes offered is a new fifth, which sorts (by order of hierarchy) by Type, Make then PartNumber.

Last but not least (in fact, this is probably the greatest enhancement as just made to this form), if you click on the 'Print Options' button you'll see there's a brand new offering there. It is to print labels for your parts bins. The labels will be very much like standard parts labels, but configured specifically to place on the front of each bin where the corresponding parts will be located.

Some of you guys sometimes fulfill an appointment on a day prior to when it was scheduled for. When you go to do a PostVisitReport on such an appointment (and you're doing it, still, on a date prior to the date of the appointment), ServiceDesk gives you a bit of a hard time (it's the Nobel-Prize/Time-Travel message). Still, understanding that sometimes the job is indeed performed early, ServiceDesk permits you to go ahead -- only there was a small, secondary problem. There was nothing built into the system that would automatically change the appointment to the date it was early-performed -- with result that it remained on the scheduled for the originally-scheduled date, and showed still for that date when displayed to the DispatchMap. This release addresses that.

With its original release, our new "Virtual Terminal" facility was programmed to work with three different categories of swiping devices (aka "magnetic card readers, or MCRs): standard USB, devices that via USB but use keyboard emulation, and the Printek-brand printer/reader design that connects via Bluetooth. For each different device, different programming is required for Virtual Terminal to connect. Since that first release, we added the ability for our Virtual Terminal to work with devices that use keyboard emulation but do not broadcast a signature via which the underlying software can recognize their presence.

With this release, we've now added the ability to work with serial-port devices.

A little explanation in regard to this last. We had thought our Virtual Terminal would already work with serial port devices. This is because the Printek-brand Bluetooth devices connect through a virtual serial port, and we figured since we'd programmed to work with those, other serial port devices would work on the same basis. We were wrong. Standard serial port devices require different programming, which is now provided, with this release.

We are, by the way, developing quite a collection of swiping devices here, since we must acquire one of each type in order to assure successful programming with it.

Originally, in ServiceDesk, there just one way to initiate a SalesJournal entry: via direct action in the F9 form. Eventually we added a mechanism that automatically creates a -Zero- SalesJournal entry if you're canceling an appointment along with the underlying job. Around the same time, we added a mechanism that links to the SalesJournal entry from the FinishedForm context. The thing that's particularly nice about this last method is that it auto-fills the SalesEntry line for you, based on what's already in the FinishedForm (making it child's play to hit Enter and complete your entry).

Earlier this week I was connected with a gentleman who, while looking at an actual JobRecord in the F7 form, had the mistaken notion that if he clicked (in the 'JobStatus' area) on the checkbox labeled "Rcrdd-to-SlsJrnl," that in itself would perform the underlying act (i.e., would actually record to the SalesJournal rather than merely changing the check-off status of the job). This gave me an idea.

I'd long thought it frustrating that, when you're looking at a job in the F7 form and want to make a SalesJournal entry on it (and do not want to do it via the FinishedForms context), you have to hit F9 (to load the SalesEnter form), then manually type a technician abbreviation, customer name and invoice number in the entry line, when the same already existed in the context you were just at.

I might have created a special button in the F7 form to deal with the above, but I think most long-time readers are well aware that I try hard to avoid run-away button-itis (there is only so much room on a form for so many buttons, after all). So, when this particular gentleman was thinking that the status checkbox had a button-like operative effect, it gave me the idea.

As of this release, when you click on the F7 form's 'Rcrdd-to-SlsJrnl' status checkbox, you'll have an option as to whether you want to just manually set the status as such (not a normal occurrence), or initiate an actual SalesJournal entry. If you pick the latter, the F9 form will load for you -- with the first three fields (applicable tech abbreviation, customer name and invoice number) appropriately pre-filled.

Though incredibly strong in many areas, ServiceDesk has simultaneously had a few longstanding weaknesses. One by one, we've slowly addressed these. This announcement concerns a big one.

ServiceDesk was born in an office where all our work was done within a single tax jurisdiction, involving a single rate setup for sales tax. It was on that basis that the original sales-tax-handling system in ServiceDesk was designed. Unfortunately, that didn't work too well for companies that must report to different jurisdictions, involving different tax rates. My early solution (which was still current until this release), was to allow you to tell ServiceDesk, basically, to bow out of the tax-calculation business (at least for other-than POS situations), leaving the matter of calculations to be done by the user. It's worked all this time, and not too terribly, but has been less than ideal.

Well, I finally addressed it. You can now create a simple document that tells ServiceDesk what the applicable tax rates are for each zipcode in your area. ServiceDesk will read the document, and know just what to do.

For instructions on how to make this document (and a bit about how it works), please go to your ServiceDesk Settings form, and look for a new little button that's placed between the two boxes where you've traditionally set your sale tax rates:

A click on that little question-mark button (that particular one, not any other) will open a .pdf booklet that contains all the details you'll need.

It was recently pointed out to us that, while we thought we'd finally completed the "To-Grave" portion in our "Cradle-To-Grave" system of managing special-order parts (see 8/31/08 entry), we missed an element. Specifically, since that prior improvement, the "To-Grave" portion has been good in respect to parts used on a job (i.e., in that context there are good mechanisms to "check-off" whether a special order part was indeed used). However (a recent caller forced to realize), we'd not similarly added mechanisms to "check-off" that a POS special-ordered part was indeed (and ultimately) delivered to the customer. So, we've now added such a mechanism.

When ServiceDesk loads data into any FinishedForm (POS or otherwise), if it loads into a parts row a special-order part that has not prior been checked off as having been delivered to the customer, it will append the part number with two carets, as illustrated in the second row, below:

It will also insert a ToolTip to the box, so that if you float your mouse-pointer over it you'll see the following:

As per the ToolTip's instructions, all you need to do is Double-Click in the box to check-off that the item was indeed provided to the customer. When you do so (and confirm in a little dialog that you want to proceed), the text will change as per the following:

Please note that the two carets are removed, and the reference indicating final disposition is added after the part description. That's it. It's all it takes, and you're done.

As any SD user likely knows, at Rossware we're big advocates for the improved efficiency that results from keeping one's hands on the keyboard, for actions that may, at the user's option, be done via done via either keyboard or mouse. Because of this, we felt "caught with our pants down" when it was recently pointed out (by a very keyboard-dedicated user) that virtually any task in a Callsheet can be done via keyboard alone -- except linking to the UIS form for the sake of creating and connecting a UIS-Sheet. There was no way to perform that function except by right-clicking in the Item-Make box. So, we've added one.

The simple method is, if you've typed the first few characters of a make -- to the point where you see the drop-down and the make you actually want is auto-selected, instead of simply hitting Enter to insert that make, modify your action by hitting Shift-Enter instead. In response, ServiceDesk will go ahead and insert the full make in the box (as per normal), but now it will also open the UIS form, ready and poised for creation of a new Model/Serial set.

Don't worry about memorizing that action here. It's been added to the Callsheet "Cheat-Sheet." Hopefully, you're aware you can bring up that "Cheat-Sheet" by simply right-clicking in little blue-label area, as shown here:

We've found many people are not aware of the above (and long-standing) "Cheat-Sheet" feature, so thought we'd emphasize it here.

When you click on a tech's name at the top of this list-of-jobs, in the DispatchMap, one of the resulting print options is as follows:

This release offers significant improvements in formatting of that synopsis, including the fact that note fields, as associated with customer telephone numbers, are now included in the printout.

If you're using the new Virtual Terminal, from within ServiceDesk, and doing a "keyed" (as opposed to "swiped") entry -- and assuming there's an underlying JobRecord that's linked to your entry -- you'll see three added (and little yellow) boxes appear, there, when you open the keyed-entry window, as follows:

The simple idea is, those little yellow boxes are populated, for you, with customer name, number-for-street-address, and zipcode (as pulled from the underlying JobRecord). The system refrains from simply inserting this text to applicable boxes -- based on the fact the underlying card may have different credentials than involved in the JobRecord. So, the little yellow boxes serve as a prompt for your operator to ask the customer, for example, "Is the name on the card 'Jackie Smith.'" If the customer answers yes, then your operator should simply click on the little yellow box, at which point Virtual Terminal will insert that name to the operable box (otherwise, your operator should simply type the correct name as per normal). Same thing is true in regard to number-for-street-address and zipcode boxes.

Quite simply, we're trying to make it as easy as possible to insert the info, while nevertheless prompting the operator to verify its accuracy for the particular card that's involved.

Two updates back, we announced that, if you're in the InventoryControl form (F10) and using its facility to check-in a shipment of stocking parts, and if you happen to attempt to check-in an item that's not yet got an anchor in your MasterPartsPlan, you can now create that anchor listing "on-the-fly." An early adopter then pointed out that, though the added convenience in itself was great, it remained less than convenient to use the MasterPartsPlan's auto-pricing feature (i.e., the one that inserts a "sell-for" price on the basis of your underlying markup-from-cost formula) -- in part, because cost info is not collected until slightly later in the "check-in" dialog that's going on back in the F10 form. We've now done two things to rectify that:

Again, two updates back, we announced improved printing of parts labels. Quickly, we heard from one client that, when using the option to print onto 8 1/2 by 11" sheets, the intended contents for each label failed to properly line-up with the label's actual positions. Upon investigation, we found the problem stemmed from: (1) the particular printer driver, as used by this client, is simply off by a few fractions of an inch -- in regard to where it actually prints as compared to where it's told to print; and (2) our new formatting attempts to print much closer to the label margins, making for a situation where precision is more critical.

To address this dilemma, we've now added an option whereby you can correct for your printer's inaccuracy, if any. Specifically, when you're printing labels (in particular, to that 8 1/2 by 11" sheet size) and the form comes up from which you pick the applicable printer, you'll see there's a new button in the form.

Just click on the new button, and it will take you to a self-explanatory form where you can make the needed adjustments (please note this a "local" setting, meaning other stations are not affected by what's done at any particular station) At present, this option is offered only in connection with printing labels to 8 1/2 by 11" sheets. If you think you need it for other printing modes, please let us know.

HOPEFUL FIX -- NUMBER TWO -- FOR NEWER ServiceBench CLAIMS TRANSMISSION FORMAT.

Three entries back, we announced that we thought we'd accomplished a fix for the fact that the newer ServiceBench claims format sometimes fails. Turned out our fix failed. However, with this release we truly and strongly believe the issue is solved. Please let us know if you encounter any evidence otherwise.

Recently, I was doing some work in the InventoryControl form (F10). As I was looking at a line item or two, I wanted to go the applicable anchor listing in MasterPartsPlan (I wanted to change a minimum quantity). At such a point, I realized, this was not as convenient as it should be (the requirement was to hit Ctrl-F10 to bring up that form, then do a search function for the actual part number).

Now, if you're in the F10 form, looking at any line item and want to go instantly to the applicable MasterPartsPlan anchor listing, just do a Ctrl-Click on the item. You'll likely find it's very convenient.

Since virtually the beginning, ServiceDesk has allowed you to print parts labels that include barcodes. However, it did not do the actual barcode printing itself. Instead, it allowed you to export the parts label data, and merge it into a separate scheme that incorporated barcodes. It worked, and was not difficult if you were somewhat technically inclined, and maybe a tinkerer. However, for everyone else, it was less than optimum.

With this release, ServiceDesk parts label printing is truly optimized. Not only do the labels now include barcodes, but the whole arrangement and formatting has been dramatically improved.

Here are two labels done in the old format (one is for a stocking part, the other for a special order):

As you can see, the new arrangement is more artistic. And, besides the addition of the barcode, the stocking parts label now accommodates more alternate part numbers (up to six).

Two limitations: (1) You won't get the new format without installing the needed barcode font (don't worry, ServiceDesk will prompt you for this, and make the process easy); and (2) The new formatting is NOT offered under any of the dot-matrix-printer/pin-fed-label options. Among other factors, we don't believe dot matrix printers can print with the needed clarity to make the barcodes work, or to make some of the smaller print, as used in the upgraded formatting, legible.

Historically, new entries were added to the MasterPartsPlan by going directly to that form (Ctrl-F10), and deliberately using facilities there provided for the purpose. And, you had to first have such an anchor listing, there, prior to doing anything (in the inventory control system) having to do with such a part.

Two or three years ago, some folks asked us to make it so, if you were using a part from stock that had not previously been entered to the MasterPartsPlan, you could go ahead and indicate the use, and make the anchor/MasterPartsPlan listing on the fly. We did that (specifically, for when stock usage is indicated via a PostVisitReport Type-II).

Recently, other folks asked us to make it so you can, somewhat similarly, make on-the-fly additions when checking in parts (i.e., when receiving a shipment of inventory items). That is done with this release. Quite simply, if you're using the InventoryControl (F10) form's function to Receive Items into Inventory, and if you indicate a part number that's not in the MasterPlan, the system will offer the opportunity to do an on-the-fly addition.

We are continuing to make improvement to our new Virtual Terminal. The latest is its inclusion of a new button, on which you can click to go directly to the underlying Handbook.

BTW, initial reports from early adopters indicate that not only are they finding our Virtual Terminal to be joyously convenient; they are already saving big in terms of their net merchant-fee/processing costs. The processor that we've teamed up with (Merchant Warehouse) is truly doing a bang up job.

No sooner did we release our new Virtual CC Terminal (see two entries back) than certain folks suggested added operational contexts in which, from within ServiceDesk, it should be available. This release accommodates some of those, as follows:

You'll likely notice that with this release we changed the center number in ServiceDesk's Version label (i.e., we've gone from the 4.3.x series to 4.4.x). We generally change that number to designate there's been a change in the structure of one or more underlying files. In this case, we accommodated a need for change in the the Applications Journal, and related EDA files. The system will automatically convert these files on first use in the new version.

Back in July, we released Ver. 4.3.89, programmed to upload claims to ServiceBench in a new format that overcame the old 80-character limit for description of work performed. That limitation had been imposed by the old transmission format, as defined by ServiceBench; it was not something we could get around until they provided a new format, that allotted more space. They created the new one based on our request, and we quickly changed our output to match it.

But there was a sad downside. It turned out that on some uploaded claims, some of the text fields ended up getting scrambled on ServiceBench's end. Evidently, there was some fault in their server's parsing engine, as relating to this new format. Because of that, we brought back the old format, as an option, for anyone experiencing such a problem. In result, ServiceDesk has since offered you two direct transmission options, for ServiceBench, as follows:

The first option sends to ServiceBench in the new format (escaping that nasty old 80-character limit); the second in the reliable (but 80-character-limited) old format.

Anyway, with the above explanation out of the way, I can now further explain that, since July, we've been anxiously waiting for ServiceBench to fix the intermittent problem, on their end, in terms of reliably parsing claims in the new format. Just yesterday, we finally learned the problem was evidently caused by return characters in some of the text, as evidently inserted by users (that's you guys hitting 'Enter' on your keyboard while in some string of text). Given this, we can actually solve the problem on our end -- simply by programming ServiceDesk to look for any such return characters, and remove them prior to transmission.

It means the new format (top option in the list of options) should now work with reliable perfection.

My emphasis is on the word "should," because it's not yet been proven. Assuming we hear, in the coming few weeks, that claims are now going through reliably in the new format, we'll quietly remove the old-format option.

It's been a few months since the last entry here that was worthy of big drum rolls, but this one definitely measures up. It measures up BIG.

You no longer need any separate software, or separate physical "terminals," to run your credit card transactions. You can do it all directly from within the actual operations you're performing anyway -- within ServiceDesk, SD-Mobile or SD-RevenueBuilder.

On top of that, we've made arrangements with a payment gateway (a credit processing company) that will very likely reduce the merchant fees you've been paying (at bare minimum, it will at least meet your current rates).

If you're using SD-Mobile, it will allow your techs to swipe cards directly (after investing in a less than $50 simple swipe device), resulting in large added savings in your bottom-line merchant fees.

Best yet, there is no setup cost (from the payment gateway or Rossware), no contract to bother with, and no added fees of any kind.

We've created a little nine-page handbook that provides all the details and how-to. Please just click on the link to open the handbook, and learn. We hope you'll be enjoying this terrific power (and major cost savings) very soon. Today, if not sooner.

You may note that no entry was made for Ver. 4.3.110. It included only a series of minor tweaks and improvements: nothing to write home about. The same goes for this release -- except, if you're interested in using or enhancing the use of graphics within any of the FinishedForms, there's a new mini-manual on the topic.

If interested, open the FinishedForm interface (Alt-F4), and (prior to selecting any particular form), look at the set of buttons in the lower-right corner. There's a new one labeled "How to employ Graphics." Just click to open the document.

If you're curious, the reason for this lapse in introduction of dramatic new stuff to ServiceDesk is because I've been working on a terrific new functionality, to be introduced shortly. It will be added to both ServiceDesk and SD-Mobile, and will significantly enhance both. I'm referring to built-in Credit Card Processing. You'll no longer have to turn to a separate application -- and, more importantly, your field techs will be able to swipe cards live, significantly reducing your bank processing fees. Development is almost complete within SD-Mobile. Watch for it soon.

There's a new report now available in the F11 form. It's similar in format to the longstanding QOS Report, and is accessed via nearly the sequence of menu choices. But its purpose is to help you analyze what kind of margin (aka direct operating profit) you're receiving from jobs as a whole, non-HVC jobs, all HVC jobs combined, then from each HVC client in particular.

Since it has to go through the system and find all parts as applicable to each job (in order tally parts cost), the report runs pretty slow, depending on how much history you've asked it to go through. But, so long as you allot it sufficient time, you should find the results are highly rewarding.

We've heard from numerous people that they're closing out jobs (owing to cancellation of the underlying customer request) on which parts requests have been created (and are in the PartsProcess system awaiting work). When the jobs are closed (and without further processing of the underlying parts requests), the latter are left hanging, and eventually clog the system.

To address the above, the system now checks when a SalesJournal entry is made to see if any items are pending, and, if so, offers to show the operator such items, auto-close them if appropriate, etc.

Similarly, though there was also a similar check connected with the offer to auto-zero-sale a job when its appointment is canceled, that check did not offer to auto-close the underlying parts requests (i.e., it just informed the user of their existence). That procedure is now modified to do so.

From "day one" when developing ServiceDesk, we've made it an extremely high priority to make all actions as near instantaneous as possible. We are constantly looking for ways to avoid any perceptible delay. Computers are the servants; they should wait for you, and not vice versa.

Recently we discovered that when the computer we use as a server is mapped to itself (and it's the mapped drive letter that ServiceDesk uses for file access), there is a very severe performance hit. It's bad, really bad. It seems odd, because the mapped path should translate just the same (one would think) as a direct path. But it doesn't. Windows is obviously doing something odd (and unexpected) behind the scenes.

Given the above, we got to wondering if there might be some performance hit, in general, when accessing files via a mapped path as opposed to a direct one. We did some testing with our networked computers here, trying various operations with the server accessed via a mapped drive letter, then again via a directly specified network path (an example of the distinction would be: z:\ vs. \\DellServer\c).

For some operations at least, the directly-specified-network-path seems to be faster. We're not sure to what extent the difference, if any, will result in noticeably snappier performance, but given what seems to be a possibility at least, we decided to offer the option of having ServiceDesk use the direct-path option.

If you want to try this, go to the Settings form (Ctrl-F1). You'll see a new checkbox, just below the box where you designate the drive letter for the server. Assuming it's a networked drive you're connecting to (i.e., not a local one), check the box, save, and see if you notice a difference. We'll be interested in any feedback.

UP-FRONT TICKET MAY NOW BE FORMULATED AS WORK-ORDER, WITH INCLUSION OF SHOP-TAG AND CUSTOMER CLAIM-TICKET TEAR-OFFS:

If you do a significant amount of shop work, you've likely thought it would be nice if, in addition to printing a standard ticket, ServiceDesk would also print a "tag" to go on the machine, and a "claim ticket" to give the customer. We've now added provision to make the above easy to achieve.

The basic idea is, design a new form image with all the graphics you want, including tear-off regions appropriate to your purposes (whatever regions you want are just fine).

Next, use the SD-Tools utility to modify your username.PRG file for text to print in spaces, where and in the format wanted, for the the non-tear-off regions of your form (this step is precisely the same as it would be for any normal ticket design, as specifically described in the first section of the manual's appendix).

Now, use SD-Tools again to assemble the particular text-to-print fields that you want, in the particular places that you want them for the first tear-off. But, instead of saving this work as username.PRG (as you did for the first and normal file), save it instead (same folder location) as TearOff1.PRG.

Finally, do precisely the same for your second tear-off area, only this time call the resulting file TearOff2.PRG.

The result is simple. ServiceDesk is now programmed so that, when printing an up-front ticket, it looks for TearOff1.PRG and TearOff2.PRG files. To the extent it finds either, it adds to the printout text fields as specified therein.

The current-JobRecords form has a grouping of eight buttons in the bottom-center region. As time has gone by, we've encountered the need for more functions, without having reasonable space for more buttons. So, we began to make some of the buttons do double-duty.

For example, the 'add AttnNote' button may alternatively be used to create the particular kind of attention note that consists of a JobLink. The 'Scheduling' button may alternatively be used to initiate an emailed request for the customer to schedule (whether via return call or web interface). And the 'orDer parts' button may alternatively be used to request an instant display of items already ordered for the job.

Just recently, we realized that another of the eight buttons was all but crying out for a similar second duty. Specifically, the 'enter funds Rcvd' button is designed for the odd situation where you need to apply money on a job that's not been closed but you're not involved in the more typical context of doing either a PVR or POS (and, since the job's not been closed out, obviously, you're also not applying the money to a A/R record).

Admittedly, it's an odd and unusually need that that button is there to satisfy, and there's a probably more typical need where you're looking at a job and suddenly feel curious to know what funds have been collected on it. To satisfy that curiosity (and until this release), you had to separately open the FundsControl form (Ctrl-F9), and work though a series of options there to initiate a search on the underlying invoice number of interest. Now that is changed. Our new, second function for this button does it for you instantly instead.

The secondary functions on all these buttons can be accessed in one of two ways: (a) instead of left-clicking with your mouse on any such button, for the secondary function simply right-click instead; or (b) instead of using Alt-X as the keyboard shortcut (where X is the designated shortcut/letter for the button), use Ctrl-X instead (thus, for the new feature on the 'enter funds Rcvd' button, the shortcut is Ctrl-R).

Don't worry about advance memorization in regard to any of these dual functions. If you need a reminder, just float your mouse pointer above any such button. A little ToolTip will appear, explaining the details.

(If you do not use ServiceDesk's Departmentalization feature, please don't bother with this entry. Also don't bother if you don't use the relatively new direct-POS system.)

Back in March (it was Rel. 4.3.74, if you want to look) we introduced a vastly upgraded POS system. Among other things, it eliminates the need to initiate the sale process in a Callsheet, to go through Job/Sale sequence, etc. -- allowing you to instead do everything directly from the new POS form.

Sadly, we left something out. On making the new capability, we failed to consider operations that use ServiceDesk's Departmentalization feature. If yours is such an operation (and if you're using the new POS system), you've likely found that POS sales have not been getting assigned to any particular department. This release fixes that.

Specifically, the system assumes direct-POS sales should be assigned to a department called "Counter Sales." If you have the departmentalization feature turned on and yet do not presently have such a department (i.e., one called "Counter Sales"), ServiceDesk will volunteer to create it on the first occasion you go to order parts via the new POS system. Or, you can take the initiative and just do it in the normal, manual manner.

Regardless of how the new department is added (or if it's already there), most of your past direct-POS operations will now be included, in ServiceDesk's SalesSummary report, as belonging to the "Counter Sales" department. This is in spite of the fact they were not officially assigned to that department when done. It will work, simply, on basis of the fact that direct-POS sales are assigned a negative invoice number. On that simple basis, the SalesSummary machinery will deduce that a sale belongs to the "Counter Sales" department.

At least, the above works for direct-POS operations as done prior to this release that did not involve ordering parts. However, for direct-POS sales that did involve ordering parts (where the assigned invoice number was not negative) the past data will, sadly, remain inaccurate -- so far as assignment to the "Counter Sales" department is concerned. But all sales henceforth will be perfect.

As you likely know, when we created our on-screen form in which ServiceDesk assembles (and allows you to review and/or edit) claim information prior to transmittal of warranty claims, we used the same essential layout as is found in the Narda 360. We did this for two reasons: (a) it's the format in which many folks were already in a habit of assembling claim info; and (b) it facilitated actual printing to a true Narda, for any circumstance where that might be wanted.

As time's gone by, some folks have wanted to print this info to plain paper (i.e., rather than to an actual Narda). But the plain paper printout (i.e., without any kind of form imagery in the background) never looked good. We've now addressed that. We could not copy the true Narda (it's copyrighted), but we've created a similar-looking image that allows you to print your warranty-claim text to previously blank paper, with a result that is very presentable.

If you'd like to implement this new capability, click here to download the needed file (which should be copied to the \sd\netdata folder of your server).

A. Report on Rate-of-Parts-Used, Combining Results from Both PartsProcess and InventoryControl Systems:

This new report derives from an earlier one (the former Usage-Rates report in the ArchivedPartsProcess form). But it's totally new in respect to its inclusion of data from the InventoryControl system, and is vastly improved even in terms of its original scope. To use it, go to your ArchivedPartsProcess form (Ctrl-F8), and choose the 'Usage Rates' option (same menu title, but much expanded result).

This export is designed to let you formulate a list of all those customers who own machines of a particular make, or type, or with some portion of their model number matching a particular string, or any combination of the above. Access it via the ExportCustomerData form (Alt-F3).

From its inception, the general scheme in ServiceDesk's PartsProcess system (i.e., that manages special order parts) has embodied a clear separation between the act of creating an internal request (typically via a PostVisitReport) versus processing that request after creation (via facilities in the F8 form). Depending on your office setup and its flow structure, this may or may not have been optimum.

If you're in the PartsRequest form (direct access is Alt-F8, but you'll usually find yourself there in the context of making a PostVisitReport), have entered data for creation of a request, and are about to save/create the request, hold down Ctrl button on your keyboard as you hit Enter or click on the Save/Create button. This tells the system you want to begin processing that item immediately, rather than waiting for later or for someone else to do it.

In result, ServiceDesk will immediately take you to that item in the PartsProcess form, ready for your immediate processing. It will even auto-unload the PartsProcess form when you record your work on the item, auto-returning you to the prior context. This should make immediate processing maximally convenient.

A few months back we introduced a system whereby the sequence of jobs, as involving any tech's roster for a given day, can be automatically optimized on the basis of actual road paths and traffic conditions (see entries posted from 4/12 to 4/15). In days of $4/gallon gas, this can be a huge money saver. However, it turned out usage was sometimes frustrating. If any address in the tech's roster could not be resolved by the underlying MapPoint optimization engine, it threw a monkey wrench into the process.

Specifically, in the event that an address cannot be resolved, ServiceDesk program code now asks the optimization engine to proceed on the basis of zipcode alone. In testing, this seems to resolve the problem very well.

If you've not yet used the optimization feature (or if you tried and stopped because of the above-described frustration), we highly recommend that you try it now. It's an extremely powerful tool -- and is even better now!

First, the background: If you are using any of our automated DispatchLink utilities (SB-DispatchLink, SP-DispatchLink, etc.) you are familiar with the fact that, when these utilities take a dispatch and insert it to a Callsheet, they DO NOT simultaneously create a UIS for the model, serial, and so forth. The reason is because, when the dispatching entities provide Make, Type and SellingDealer info, they do so sloppily -- in the specific sense that "RANGE," say, might be described in 25 different ways. If we auto-created UnitInfoSheets on the basis of such descriptions, your lists of Types and Makes would soon be corrupted with all these disparate (and many times miss-spelled) descriptions. To avoid that, the DispatchLink utilities have been programmed to place UIS-related info (Model, Serial, PurchaseDate and Selling Dealer) into the ExtraNotes sections of the Callsheets into which dispatches are otherwise inserted.

Given this method, there's been a slight burden on you, the user, when wanting to have a UIS based on such info as found in those ExtraNotes. In a nutshell, you've had to create and fill it in manually (and, of course, using the benefit of using your human intelligence to avoid corrupting your lists). Hopefully, you've made the task somewhat easier by using copy and paste to move provided models and serials into your new UIS, but regardless, it's likely been a nuisance.

Our new function rescues you from this burden. Now, if you have a DispatchLink-created Callsheet that contains these kinds of data in the ExtraNotes section, just do a simple Ctrl-Click on any text in that section. ServiceDesk will then read through those notes for you, pull Model, Serial, PurchaseDate and SellingDealer (to the extent any such is provided), open a new UIS for you, and plug those items in. You may need to do a little work to pick the particular Type, Make and Dealer descriptions as preferred, from your drop-down lists, but overall UIS-creation for this context should be much easier.

For any among you that have mice equipped with scroll wheels (and if you don't, why not?) you may have found that in certain ServiceDesk contexts, where you'd expect a reaction to scroll wheel rotation, nothing happens. I won't bore you with the technical reasons, but with many mouse drivers ServiceDesk did not receive any Windows message indicating that the scroll wheel had been rotated. We've now overcome that technical hurdle, and so now should be able to give you appropriate scroll wheel reaction in all expected contexts, and regardless of what mouse driver is installed on your machine.

Most particularly, you should notice that the scroll bars in both the FinishedForm context (Alt-F4) and JobsPerusal form (Shift-F7) will now react, per expectation, to scroll wheel rotation (which will be a nice change, if in fact you were not encountering that before). If you notice other contexts that need to be fixed, please let us know.

Much more dramatically, we've now added Mouse-Scroll-Wheel/Reaction in a place that has no scroll bars, and never before had even a potential scroll wheel reaction: the DispatchMap (if you're curious, we deliberately refrain from placing scroll bars there, because for that context we consider screen space more valuable for displaying elements of your territory and schedule). You can now pan vertically within the map via a simple rotation of your mouse's scroll wheel. To pan horizonatally, move the mouse pointer to any edge of the map, where the pointer image turns to a four-arrows symbol, then rotate the wheel. Please try it. We think you'll love it. It makes moving in the map into a significantly more intuitive operation.

Also in the DispatchMap, we significantly enhanced the appearance of the MiniMap, and gave you the ability to drag it to any position where you'd like it to display. If you had the option to display that feature turned off (it's in the green section of the Settings form, Ctrl-F1), you might want to turn it back on, and see if you don't now like having the MiniMap displayed.

Improved printing of MachineHistory AddOn when printing tickets from the DispatchMap. Now it will include PVR portions of applicable histories only, and will refrain from printing any MachineHistory AddOn unless there were, in fact, prior jobs.

Aside from numerous fixes, there's a new convenience. If you're doing PVRs and auto-linking from there to the claims-submission process, the system will now (once the claim is transmitted) automatically take you back to your PVR form, ready for the next item.

This update also includes a new version of SD-Backup. It will take care of any notices, you may be receiving, in regard to the old version expiring. Be sure, when you do the 'Unzip,' that SD-Backup is not running. Windows will not permit an in-use program to be replaced. You'll get the infamous "Can't create output file" message.

(1) I notice that a lot of these entries, lately, refer to "next-step-taken" type work, as regarding elements that were first added quite far back. This one does too. Way back with rel. 4.1.123 (3/3/06), I created the ability to cross-link two or more jobs (i.e., "tie them together"). We call these JobLinks, and for details please go back to the entry pertaining to that release (scroll in this document a bit past half-way down, or search on the word "JobLinks").

Anyway, until now nothing in ServiceDesk operation explicitly took advantage of these links (they informed you as a user of the linkage, and that was it). Now, an important operation does.

Specifically, prior to now, when a special-order part was checked in and the system looked to see if any other items were pending, it looked only in regard to the particular job the part was ordered for. If it found no other parts still on order for that job, it would suggest the job should be placed in "Working to Schedule" status, offer to email the customer asking them to schedule, etc. That was generally great -- except for one situation: What if you had other jobs for the same address that were still waiting for parts, and you really wanted to hold off on booking the returning appointment until you had the parts in for all jobs, and thus could send the tech back to complete all in one and the same trip? If that was the case, the system (i.e., as ruling up until now), would erroneously suggest that the one job (on which all parts had already arrived) should be scheduled now.

Our new feature fixes that. Specifically, before suggesting you should implement mechanisms to schedule the job on which all parts have now arrived, it first looks to see if it's linked to any other jobs (not yet ready for scheduling), and behaves appropriately on that basis.

(2) In the ExportCustomers form (Alt-F3), added a new export that will create a table listing all customers who purchased a particular part. The idea, for example, is suppose you want to send out postcards telling all persons who've purchased a particular water filter that it's time for them to replace it. This export will serve the purpose.

(3) In the DispatchMap, if you click on a tech's name at the top his list of jobs and choose 'E' (for "Email a fully-detailed, job-by-job summary"), there's now the option to include a comprehensive history of prior service on each involved machine.

(4) I'm a devil, I know. Many have complained about the plethora of messages ServiceDesk presents (not to mention their being sometimes long-winded).

In other programs, you've probably seen where some messages have a little checkbox in the bottom-left corner on which you can click to tell the system to refrain from showing you that message again. I've wanted to do the same, but the Visual Basic programming environment (in which all my programming is done) does not naturally offer that capability.

Given the above, I've now independently created the ability myself. At this point, I've converted a bunch of messages to the new style (i.e., you'll see that checkbox in the bottom-left corner, and if you click on it, that message will be gone for good). I plan to convert other messages over as I become aware of more contexts in which the option is sensible.

If you'd like to nominate any particular messages for inclusion of the "Don't Show this Message Again" checkbox, please email me with sufficient info to identify your candidate. Though I may not in every instance accede, I promise to give every nomination serious consideration.

Way back and a long time ago (if you don't believe just how long, see notes accompanying rel. 4.2.27 on 10/29/06), we introduced a mechanism whereby, as you use and install special-order parts, the system checks off that fact. Among other things, this was intended as the first step in making our PartsProcess system (i.e., for managing special-order parts) a full-fledged, "cradle-to-grave" system -- in other words, a system that manages every detail for every part, from "birth" of the internal request, all the way to assuring it's actually installed on a customer's machine, or that it's returned and you get credit for it, or you deliberately determine to move into stocking inventory, or that it reaches some similar final, "in-the-grave" disposition.

To summarize, since forever we've had cradle-to-"elderly life" management for such parts, but nothing that assures every item ultimately reaches "the grave" as it should.

There are now two new menu options in the archived-PartsProcess form (Ctrl-F8). Under one, the system will search for and display items that do not indicate any final disposition. Under the other, it will create a report (for either printout, file-export, or both) that lists such items.

If you need some slight review, when you indicate via a PostVisitReport that a prior-ordered part was appropriately used on the job for which it was ordered, ServiceDesk inserts simple text in the underlying PartProcess record's BinLoc box, to indicate the same. The simple text consists of the tech's two-letter abbreviation, followed by a hyphen, then a month/date reference (e.g., "GR-8/30"). That's how the majority of PartsProcess items are (or should be) "put in the grave." And that's been going on for some time.

Now, with addition of what we just released, you can use either of the above-described means to review items that never were, via such normal processes, put in the grave. You can then assure they go to the grave via some other appropriate means (such a being returned and credit received, for example). And when this latter is done, you can then mark off the underlying record according to the manner in which you finally killed it.

Specifically, if you bring up any "process" item from the archive-PartsProcess form, you'll find that when you click in it's BinLoc box there's a simple drop-down. It has three items, as follows:

RtnCrdtd (to signify that you've returned it, and appropriately received credit)
MvdToStk (to signify a deliberate was made to move the item into stocking inventory)
WriteOff (to signify a deliberate decision was made to count the part as a loss)

The idea is, you can put an item (not otherwise used by the tech) into the grave by selecting any of these three criteria, as appropriate. For example, if you've returned the item and got credit, you'll select the first, then that item will no longer appear when you go to review, or report on, items not yet shoved into the grave.

The larger idea is, you can easily assure that all your special-ordered parts are reaching appropriate disposition by occasionally reviewing items not yet in the grave (using the new mechanisms), and responding to items that should have been placed there, but have not. For example, a simple review might show several items that should have been returned to the vendor, but are still sitting around somewhere. Upon discovering this, you'd make the returns, and when the credit came mark each item appropriately. Then, when you next ran the report, the items would not show, and you'd be privileged to have a big smile on your face.

A while back, we added a new feature in PrintTicketsFromDispatchMap function. It was an option to include an added sheet of paper (and addendum to the invoice, if you will) that details history on the machine involved. For some users, there was a problem. If you're using pre-printed forms for your invoices, and if the addendums are sent to the same printer location, the addendums end up printing on those forms, which is not a good thing.

To address the above, there is now an option to print the addendums to a different printer than the invoices themselves.

Also, we've now added an option to include the same addendums if you're choosing to email the invoice images to your techs.

In the last large while, there have been a lot of people wanting things that, because of constraints in the existing system, were kind of hard to do. For example, people have wanted the option email to rather than direct-print in a number of contexts, where there was no easy method (i.e., w/o unduly cluttering the interface) to add the option. In other cases, people have wanted new flexibility/change-options when printing existing stuff, and we'd already used all the options space built into the Printer/Setup form. To address these needs, a major overhaul was needed, and that's now been accomplished.

What we have now is a totally rebuilt Printer-Select/Options form. Its nice looking, but more important is way more robust than the prior version.

Most significantly, wherever we design it to do so, this new Printer-Select/Options form will include the option to email the "printed" output rather than sending it to an actual physical printer. At this point, it's been programmed to do so if you opt to print from the FinishedForm context. It's our intent to add the direct/print/email option to other context, per request as made by you as users (now that we've got the interface and underlying machinery built up, the task of adding the ability to new venues is relatively small).

Another benefit is, if it happens to be one of those contexts where, formerly, there was a little option/checkbox that you click to send the output to a file (i.e., rather than a printer), the same option is now presented with an on-its-face place to select the filespec where you want to save the data. This eliminates what was formerly a second step in the process.

A caveat, in regard to these new capabilities, is we're now using a new and more efficient underlying method to keep track of what your preferences were, for each context, when prior choosing print options. Because of this new method, the systems memory of old preferences will be lost. Thus, when now printing for the first time from any context, you'll get the built-in defaults. After the first time, the system will remember what you selected, and default to it the next time around (these defaults are stored locally and are unique to each computer, so please keep that in mind).

In the FinishedForms context (Alt-F4), the Generic form has long been equipped with a box that lists payments received and balance due. The Custom form has not had such a box. We've now made a new Custom form that includes such a box. Since the new box is a single-line in height (unlike the box in the Generic form which is multi-line), this release of ServiceDesk includes a modification in code that will recognize the distinction, and configure text for the new box in a manner that's appropriately suited for a single line.

To obtain the new custom form, open the standard update folder (i.e., when you're doing the update and the Winzip Self-Extractor form appears), and copy the file Custom.frm from there into the \sd\netdata folder on your server, overwriting the pre-existing file of same name that's already there.

When you print service tickets via the DispatchMap, there's now a new option (it shows as a checkbox in the Printer-Select form). It's labeled 'Add sheets with machine history,' and it means what it says. If you check this option, besides printing the requested tickets, the system will also print separate sheets that detail any prior history on the machines involved.

There's a been a growing clamor out there for a more flexible SourceOfBusiness Survey. The long-standing system allows you to customize your list of YellowPage ads, but aside from that the categories and question/answer structures are pre-canned. It's a fixed, take-it-or-leave it approach.

Responding to that growing clamor, there is now a brand-new SourceOfBusiness survey system that can be completely designed (at least in terms of the question and answer structure) according to your preference. For a little three-page handbook on how to use this new system, click here.

On a totally unrelated subject (this one related to the POS system), if you've wanted to add your own disclaimer (or other statement) to the POS form, you may now do so. Simply create the text you want and save it in a plain-text file named PosDisclaimer.TXT. Locate it in the \sd\netdata folder on your server. ServiceDesk will do the rest.

On 7/5 we happily announced that, finally, ServiceBench had given us a new claims-transmission format that transcended the old 80-character limit on description of work performed (Ver. 4.3.89 was changed to use this new format). Well, it turns out ServiceBench did not quite have things perfected on their end. On some claims as done in the new format (some, but not all), their system fails to accurately parse the data. To help you cope, this release of ServiceDesk gives you two ServiceBench "WebDirect" options (i.e., as appear when you go to transmit):

1. The standard/normal option uses ServiceBench's new format (i.e., no 80-character limit, but on some claims their system will goof up); and

2. A temporarily-added option labeled "SB-WebDirect (Old Format)". This will do exactly as it says (i.e., transmit in the old and reliable format, albeit with an 80-character limit).

We're sorry that we can't presently provide you with perfection on this, but we're waiting for ServiceBench to iron things out on their end. They are aware of the problem and are working on it.

New "Server Performance Monitor." If you're like me, you want processes on every computer to be absolutely snappy. If you must wait even a second on routine operations, it's very annoying. If you do experience such delays, it's often tough to pin down the cause. Is it in the local computer, or is it in communication with the server? We've now added a tool to help make the determination.

This tool is accessed by clicking (in ServiceDesk) on File Functions, then Monitor Server Performance. After doing this, look near the top-right corner of your ServiceDesk screen. You'll see a flashing reference. Once per flash, ServiceDesk "pings" your server, and reports whether the ping was successful, and how many milliseconds it took.

To help you with evaluation of the numbers, in our own network (which is NOT super high-end), ping times are ranging from .04 to .22 milliseconds (the lower figure translates as 4/100000 of a second, so it's not much time). We've been connected with users who've had figures ranging up to 5 and 6 milliseconds, still with good performance. Our present suspicion is your network/server performance is probably reasonable so long as you're averaging pings of less than 10 milliseconds (that number translates to 1/100 of a second). If your average is higher, there's likely a performance barrier you should address.

Big news for those making warranty claims via ServiceBench. For several years, we've not been able to include more than 80 characters in the description of work performed, for ServiceBench claims, because their electronic transmission format did not allow it. We've been waiting and waiting for them to provide a new, more liberal format. Finally, they did, and this release of ServiceDesk is modified to use it.

If you're using the direct-upload method for transmitting claims (and if you're not, why not?), there's no need to change a thing -- aside from ceasing to worry about the 80-character limit.

If you're using the comparatively old-fashioned, save-first-to-file-then-upload-your-file method (and if you are, why?), you will need from this version forward to specify a different format for the uploaded file. Be sure that, rather than specifying "ServiceDesk Warranty Claims," you instead pick "ServiceDesk Warranty Claims Delimited."

Major overhaul of mechanisms that react to server connection faults. If a fault occurs, the system will now detect the matter more quickly (i.e., shorter period of freeze-up). In addition, unless new data access is imperative, it will continue to run (and refrain from bothering you) even in the absence of a connection. And, finally, if forced to bother you (i.e., it's not getting access to data that it must have for some operation), it will delineate whether the fault is in the local computer's network connection, or if it's instead at the server itself. This will provide an invaluable aid for your own diagnostic efforts.

In the Settings form, there is a new button (with "?" symbol) inside the frame/box area where you designate the server drive. It's function: if you click on it, it opens your Windows "Map Network Drive" dialog box.

Upgraded Remaining Two Reports (in F11 Reports form) that still had not been brought up to Full-Compliance Standard.

For background, in the now somewhat distant past when I was asked to create some new report, I often did kind of a "quick-and-dirty" approach. Simply, I was able to code for the report more quickly by skipping the stage where you'd input the start and end dates for inclusion. Instead, I wrote several of these reports to simply ask "How many records back?" you wanted to include. Also, I did not code them to allow specification as to whether the output would be printer or screen bound (it all went to the screen, and if you wanted a printout you were relegated to printing, simply, what was on the screen).

Over time someone would ask me to upgrade some particular such report, bringing it up to the standard wherein the user can specify actual date range, and output can be directed in a dedicated manner to either screen or printer. It's kind of been a one-by-one process. Last week I received still another such request (this one for the CompletionAnalysis report). Upon going to fulfill that request, I found there was only one other remaining report that had not so been upgraded (the TimeOnJob report), and so figured I'd get it out of the way too.

Now, there should be no remaining reports (in the F11 Reports form) that don't fully comply with such standards.

New and Improved Connection Tool. For the last fifteen months, we've been using a service called GoToAssist for the mechanism that allows you to click a button, and within moments we can be working on your screen with you. It was a good service, but we think we've found a better one (provided by the LogMeIn.com people, it's called LogMeInRescue). With this change, we made the connect button in ServiceDesk look much nicer, as follows:

To access this tool, click on FileFunctions, and you'll find it as the second option down.

In the Settings form, there is a new button (with "?" symbol) above the 'Save Local Values' button. It's function: if you are interested in configuring our ServiceDesk network in thin-client mode (rather than the more typical thick-client), it opens a document that provides the details.

If you're not aware, the fundamental difference, between the two modes, is having ServiceDesk installed solely on the server (with all stations operating solely off that single install), rather than independently installed (and sharing data only) throughout your network. We've reached the conclusion that pros outweigh the cons, for that setup, if you have more than just a few computers in your network.

This update included many other small improvements, each too minor to warrant description here

1. Added ability to clone zipcodes in the .zpc file. For details on this feature, open the ServiceDesk StreetList form (Ctrl-F5), and click on the 'Clone a Zip' button.

This menu option	This one

Leads to this	Leads to this

Secondary Filtering Options from Old	Secondary Filtering Options from New

Old email as customer might receive, plain text and no "signature-area" inclusion	Email with a possible configuration as customer might now receive. Note "signature-added" space at bottom (please ignore that's it's a Rossware rather than a service company logo: I was lazy in the setup). Also please note the font is specifically-selected, which allows a more modern and appealing look.

First dialog after deletion request	Graphic as appears after hitting OK

Selection for new tool is in "Diagnostics" branch off MainMenu	Actual tool is very simple (please note the "About this test" button; it opens a small document that explains details)

Showing popup as traditionally prior located	As now moved to the right

Prior options as available just prior to this release	With new option added, plus improved organization

relevant section from prior MainMenu section	from Just-Improved

float your mouse for a tooltip reminder	a double-click produces the actual dropdown

Old "File Functions" Menu	Improved and Simplified "File Functions" Menu

New form option in Alt-F4	User picks which of multiple saves should be loaded

Old Dropdown	New Dropdown

Old Form Interface	New/Improved Form Interface

Segment from right-side old form	Segment from right-side new form