SD-Dealer Guide

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

• If you do not know about a handy little Windows feature for switching between running applications, now is the time to learn. Hold down the Alt button on your keyboard, and hit Tab. It’s called “Alt-Tabbing” and is a convenient way to flop back and forth between multiple applications.

In ServiceDesk, use any standard methods to initiate a POS situation (i.e., within the FinishedForms context).

Though the forms in SD’s FinishedForm context are arranged with boxes oriented for parts, the same array works fine for selling merchandise.

Click in the second column of the line (typically containing 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 the items you selected in SD-Dealer into the form.

This method was added in late 2009, based on the feeling among some users that the whole process should be 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. As a result, the little 'Integrate input from' box comes up — from which you should select "Dealer Inventory."

Next, type any model number (as it 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, which is just as nice.

Once the to-be-sold inventory items are in your POS form, you may click on the ‘Enter to Inventory’ button to have ServiceDesk pull the items you selected from the 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, 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.

Before creating this feature, ServiceDesk pulled the particular instance of an item 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 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 the 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, you want to leave open the question as to which particular serial number is being sold. Please note that it also assumes (as the pre-selected default) that this will be what you want to do.

• Please note this dialog will only be offered when the system notes that you possess more than one of the model in question. If you have just one, it will just proceed.

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 go into a mode of waiting for you to eventually let it know which of the particular items 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 that one or more such items (as so rendered) are subject to one or more already-completed sales. If you desire more information, float your mouse pointer over the bold magenta text. A ToolTip will appear to inform 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, as usual, it finds the particular UnitInfoSheet (UIS) within ServiceDesk that fits the model and serial the delivery crew provided. Having done this, it likewise (again, per usual) 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, this stage of the process is virtually automated by this method.

This method was added in 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 described) will be frustrated. Given this, it is wise for such delivery persons to use a barcode scanner for such insertions to ensure 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). The idea is to create a new online table in the SD-Mobile data system. This table is engineered to contain data from your internal SoldButNotPulled data and a list of serial numbers from your inventory pertaining to each line item. When the tech opens any particular job, mechanisms in SD-Mobile look in this table to see if a line item matches its JobRecord number. If yes, a new interface in SD-Mobile will ask the tech to indicate, from a list, the particular serial number they're delivering.

If you find you have a significant need for this further enhancement, please let Rossware know.

In this context, use either of the two methods (methods 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 either method (and in any 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.

Click appropriately, and you’re done.

There will likely be instances where this process is not completed via SD-Mobile and is 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 may have seen this second stage in the process but did not. If you find such items, take care of them.

If you want to know what particular sale (or sales) are waiting to have specific serials pulled, a simple trick 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) you’d get if you intended to do the pull, but in the case of simply wanting information, you’ll escape from the process.

In April ’09, we added a couple of new fields, as shown below:

This was based on feedback from:

• A new user explained that they like creating Dealer Info Sheets when items are on order and before receiving them. There’s now a checkbox where he can explicitly indicate such status.

• Another user explained that he often gets calls from long-time customers, telling them they want to buy a certain unit and that they won’t be able to mark it as “sold.” Note that at such point, they've not yet done the POS process, which would otherwise provide documentation that the item is no longer available for sale to another party. So, we provide this other means—based on simply checking the applicable box.

Please note that, besides providing checkboxes for these new status indications within each applicable Dealer Info Sheet, the primary display has two added columns used to indicate (with 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 have to train yourself (and employees) to remember that an “X” in the first such column means “On Order.” An “X” in the second means “Pending Sale.”

It will be necessary, 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).