ServiceDesk 4.5.38 Update 09/13/11

Let's face it.

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. 

Improvements are as follows:

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. 

Welcome to a new world.

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).

2.     Improved Actions Interface and Integration Options:

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. 

3.     Numerous Other Fixes and Improvements:

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.