Historically, the SD-Dealer program has been so simple as to virtually need no manual. Prior to November ’08, our recommendation was that users simply watch the little promo video, and proceed from there. Fact is, everyone seemed to get along fine on this basis (at
least aside from needing some very basic added instruction on how to integrate with ServiceDesk POS, which is not covered in the video).
But with release of Ver 1.0.24, we added a basic ability—that really should have been there all along. It’s to allow you, simply, to make the sale first, and indicate later which serial number is actually delivered to the customer.
In the interest of getting this feature (and basic instructions regarding same) into your hands sooner rather than later, we are not presently going to create a full-fledged handbook. For now, it will contain just two chapters: first, on the POS process (again, not covered in the
video); and second, on the new Sell-Now-But-Pull-Serial-Later feature.
We’ll endeavor to turn this into a full-fledged manual at a later date.
You can use either of two methods for inserting dealer-items, to be sold, into a ServiceDesk POS form. We encourage you to use whichever is most convenient for the circumstances.
In SD-Dealer, select the item (or items) you’re intending to sell to the present customer. You can select a single item by simply clicking on it. You can select additional items (i.e., to add to the prior selected item or items) by doing a Ctrl-Click. By this means, select all the items involved in the current sale. After selecting the item(s), leave SD-Dealer open, and move your focus to ServiceDesk.
In ServiceDesk, use any of the standard methods to initiate a POS situation (i.e., within the FinishedForms context).
Though the forms in SD’s FinishedForm context are arranged with an array of boxes oriented for parts, the same array works just fine for selling merchandise.
Click in the second column of the line (which would normally contain a part number) where you want ServiceDesk to insert the first item you are selling. Now, hit Alt-D on your keyboard (use the mnemonic that ‘D’ stands for Dealer).
Now, ServiceDesk inserts, to the form, the items that you selected in SD-Dealer.
This method was added late 2009, based on the feeling among some users that the whole process should be capable of being self-contained with the ServiceDesk POS environment, and not require flopping back and forth between it and the SD-Dealer interface.
To use this method, begin in any ServiceDesk POS form, and click in any box in the part-number/model-number column. In result, the little 'Integrate input from' box comes up — from which you should select "Dealer 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.
Once the to-be-sold intentory items are in your POS form, you may click on the ‘Enter to Inventory’ button to have ServiceDesk actually pull the items that you selected from inventory. Or, you can wait for prompting, on the same, as you go to print the ticket, or escape from the form.
When ServiceDesk so “Enters the Inventory,” what it’s doing, essentially, is to mark within your inventory the fact that the item was sold. It does some other work too, such as attaching the applicable UIS (or UISs) to the JobRecord involved, making an appropriate notation in the narrative JobHistory, and so on. Of course, it also maintains an electronic copy of the ticket.
Prior to creation of this feature, ServiceDesk simply pulled the particular instance of an item that you selected in the SD-Dealer program. In other words, even if you possessed multiples of a particular model, it would pull the particular instance (with particular serial number, etc.) that you’d happened to select.
Now, your method for initiating work in the POS process will be exactly the same—subject to one exception only: where there are multiple instances of a given model, and where you don’t want to worry about selecting a particular one at the precise time of the sale—make it a point to not concern yourself in the least. Just select any, among the multiples, that’s handiest.
Here’s what will happen.
When, a few moments later, you reach the stage in the POS process where formerly ServiceDesk would have unthinkingly pulled the particular item you’d selected (and its serial number), it will now be considerably more intelligent.
Specifically, it will note the fact that you have multiples of that model, and ask you (as an added part of the dialog that takes place as it’s pulling from inventory) if, for the time-being, want to leave open the question as to which particular serial number is being sold. Please note, it also assumes (as the pre-selected default) that this will be what you want to do.
More importantly, it will proceed to keep track, within its underlying data system, of the fact that of the multiples you possess in stock for that model, they are subject to the fact that one of them (at this point an indeterminate one) has been sold (or perhaps more than one, if applicable).
It will then, essentially, go into a mode of waiting for you to eventually inform it of which of the particular items actually get yanked from the warehouse and delivered to the customer.
In the meantime, as you review your inventory within SD-Dealer, you’ll see that all instances of that model have their text in the first column rendered in bold magenta.
This is to signify to you that one or more such items (as so rendered) are subject to one or more already-completed sales. If you desire more information, simply float your mouse pointer over the boldmagenta text. A ToolTip will appear, informing you of how many instances of that model are presently sold (but not yet pulled).
All this raises an obvious question. Once an actual instance of a "sold" model is pulled and delivered to your customer, how do you inform the system of which particular instance it was?
The method for accomplishing this varies, depending on context.
This is the situation, in other words, where, from within ServiceDesk, you made an appointment for the delivery, and your delivery crew uses SD-Mobile to receive and manage the delivery assignment. Where this is the context, your delivery crew should proceed with the PVR portion of management from within SD-Mobile, and in that context should fill-in the UIS section with the model and serial of the particular unit they have delivered.
With the above done by your delivery crew, the remainder is up to the SD-MobileLink program. What it does is as follows:
First, per normal, it finds the particular UnitInfoSheet (UIS) within ServiceDesk that fits with the model and serial the delivery crew provided. Having done this, it likewise (again per normal) links that UIS to the job. Then it does some further things.
In particular, it looks to see if the model in question is internally listed as having been sold on the job in question, yet without simultaneous identification of which serial number was involved (i.e., it looks into that internal list that's created in consequence of the process first described in this section). If it finds a matching entry there, it will: (a) remove that entry from the list (i.e., so that this sale no longer flags that model as subject to pending serial identification); (b) set your company as the selling dealer if not already so set; (c) set the date of purchase as the delivery date; and (d) mark that particular instance of the model/serial as having been sold from your dealer inventory.
Thus, via this method this stage of the process is virtually automated for you.
Please note this method was added early 2020, and we realize that success in using it depends on your delivery crew accurately placing the model and serial into SD-Mobile's UIS interface. If they mistype, SD-MobileLink will not find a match, and the automated further functions (as above-described) will be frustrated. Given this, it might be wise if such delivery persons use a barcode scanner for such insertions, so as to assure accuracy.
Beyond that, we are at Rossware contemplating a potential further enhancement (we'd have done it already, but it involves building a fair amount of added infrastructure). Anyhow, the idea is we create a new online table in SD-Mobile data system. This table is engineered to contain data from your internal SoldButNotPulled data, combined with a list of serial numbers from your inventory that pertain to each of its line items. When the tech opens any particular job, mechanisms in SD-Mobile look in this table to see if there's a line item matching its JobRecord number. If yes, a new interface in SD-Mobile will ask the tech to simply indicate, from a list, what is the particular serial number it is that he's delivering.
If you find you have major need for this further enhancement, please let Rossware know.
In this context use either of the two methods (methods that have been built into SD-Dealer all along) to indicate, via its interface, that an item has been sold. Those methods are: (a) locate the item in the main listing, and right-click on it; or (b) click on the ‘pull item as Sold’ button, and follow the prompts (this method allows you to simply type in a serial number, with drop-down assistance, etc.).
With use of either method (and in an applicable circumstances), SD-Dealer will note that one or more sales, on the model in question, are waiting to be pulled, and so will ask you which particular sale you want the pull connected to.
Simply click appropriately, and you’re done.
Very likely, there will be some instances where this process is not completed via SD-Mobile and/or it's not done manually from within SD-Dealer. Given this probability, we suggest you make it a matter of routine housekeeping to periodically page through your SD-Dealer listings, looking for items in bold magenta that, perhaps, should have seen this second stage in the process, but did not. If you find such items, take care of them.
A simple trick, if you want to know what particular sale (or sales) are waiting to have specific serials pulled, is to right-click as though intending to do the pull. This will give you a message conveying the information. It’s the same message (as illustrated above) that you’d get if actually intending to do the pull, but in the case of simply wanting information, you’ll just escape back out of the process.
In April ’09 we added a couple of new fields, as shown below:
This was on the basis of feedback from:
Please note that, besides providing checkboxes for these new status indications within each applicable Dealer Info Sheet, the main display has two added columns, used to indicate (in respect to each line-item listing) whether such boxes are checked:
As you’ll note, the columns don’t have any explicit labeling (it’s a tight space in which to fit a real label). You’ll just have to train yourself (and employees) to remember, an “X” in the first such column means “On Order.” An “X” in the second means “Pending Sale.”
It will be important, of course (and is solely up to your careful management) to assure that boxes are appropriately unchecked as statuses change (e.g., items arrive and thus are no longer “on order,” or a customer changes his mind about a promised purchase).
