Point-of-Sale operations

As described in this chapter’s introduction, Rossware came late into the POS world. As recently as September ’11, we realized our POS mechanisms still needed significant upgrading (which was done at such time). What will be described here is the state-of-the-art technology that was developed at such a point in time.

Generally, any FinishedForm type — except Mobile — could be used for POS functionality. Practically, however, it’s impossible to imagine anyone would want to use the NARDA for the purpose. Most companies use either the POS form itself or the Generic. Some use the two alternately, depending on circumstances. A few use the Custom.

Regardless of which form type is used, all (again, except Mobile) are designed to accommodate essential POS functions. In other words, you can pull items from inventory and sell them. You can create special-order requests. You can watch as the system self-totals items being sold and automatically adds sales tax. You can collect items of money. You can make the SalesJournal entry. And, of course, you can print the ticket. Additionally, you can optionally tie/integrate the latter functions. If you’re a merchandise re-seller and use our SD-Dealer serialized inventory application, you can also integrate with it.

Before March ’08, every POS transaction required initiation via the exact mechanisms as when creating a ServiceDesk JobRecord. In other words, you needed to put at least the customer’s name into a Callsheet, do the Job/Sale transition to create a JobRecord, then (and based on said JobRecord) go to the FinishedForm to do the actual transaction.

Around that time, we had some new clients who were heavily into POS operations and rightly complained that such procedures were too cumbersome for situations where they wanted to do a rapid succession of simple sales and did not even desire to track each purchaser’s name. They requested a dedicated POS interface that would stay on the screen constantly, instantly ready to conduct simple sales quickly and without the simultaneous creation of a JobRecord (an instrument designed to manage service performance).

This was when we created the POS form type, combined with a new mode of interaction within the Finished-Forms interface (we call it “Direct-POS”). Specifically, when the POS form type is selected, the interactive mode changes to make it more amenable to the kind of abbreviated interaction our new clients want. It’s a mode that makes a dedicated, POS-operations-only window of a kind you can have “always-on” at any station dedicated to a part-sales counter. It’s expressly designed for that circumstance, and particulars are described in the following sub-section.

The old method is still available and remains preferred by some users (some find it optimum to switch back and forth, depending on circumstance). The old method has been enhanced to make it more direct. Specifically, suppose you are right-clicking on the Job/Sale button from a Callsheet (as opposed to left-clicking). In that case, It will take you directly to the Finished-Forms interface rather than down the standard “I’m creating a JobRecord” path (which it still does in the background; you’re just not stopped on the way for approval).

To ensure we’re clear, the Finished-Forms interface is placed into its dedicated Direct-POS mode simply by bringing up the interface (Alt+F4) and picking POS as the form type. With that simple action, the interface is instantly posed for direct and abbreviated POS operations.

Among other differences (vis-à-vis other modes), please notice the box where otherwise you’d see a place for typing a target JobRecord’s InvoiceNumber. Instead, the same box invites you to type a salesperson's ID in this mode. This is how any direct POS transaction is initiated: with two keystrokes by an operator typing his two-letter abbreviation. By such means, the system simultaneously knows how to begin a new transaction and who the operator is conducting it.

Upon such initiation, you’ll see the POS form filled with beginning info and place the cursor in the appropriate box for the operator to begin listing items being sold. At this point, your within-POS operations are as described in this chapter.

Underlying, though, is a significant substantive difference.

With conventional POS initiation (via entry to a Callsheet, then Job/Sale-to-the-POS), a JobRecord is created for each transaction. With this method (and with one exception to be described), there is no JobRecord. There is just the POS ticket only. Rest assured; it can be searched for and reviewed later via its ticket number and specifically within the Finished-Forms interface window. However, that will be the only method. Unlike in the case of JobRecords, there will be no integration with ServiceDesk’s CstmrDbase index system (for as-you-type matches by name, address, telephone, etc.).

The exception from the absence of associated JobRecord occurs if you flag one or more line items within your POS for ordering parts. In such a case, the system will demand the creation of a JobRecord (and will likewise require the provision of at least the customer’s name, if not already provided) before executing.

Another difference is that when you first type in your two-letter abbreviation to initiate a sale, the POS form’s InvoiceNumber box auto-populates with the phrase “ToBePulled.” This signifies nothing is yet official. The system has not yet pulled an invoice number to assign. Even as you begin filling in boxes with items you intend to sell, nothing is recorded (and no invoice number is pulled) until you execute (by clicking on any operation-specific buttons). When you do, you’ll see that the “ToBePulled” text is replaced with an actual number. Simultaneously, the system saves a copy of your ticket, so there’s an instant and permanent record of the ticket associated with that invoice number. You could still abort the sale at this point, but the record will remain regardless.

Regarding the InvoiceNumber that’s pulled, you’ll notice that (unless parts are being ordered or the sale is being billed) the system makes it a negative number (i.e., puts a minus sign in front). This is so that internally, ServiceDesk can distinguish the reference from one where there’s no expectation for an accompanying JobRecord. To state it differently, the negative number denotes it as involving a Raw/Direct-POS, no-JobRecord situation.

Please remember the above if you want to look up a ticket created using this method. To emphasize, the only place you can look up a bare, no-underlying-JobRecord POS ticket (i.e., negative InvoiceNumber) is directly from the FinishedForm interface — by typing in its invoice number there as a target in the target box. And when you do, including the leading minus sign is critical. If you do not include it (and if it’s an item with a minus that you’re looking for), the system won’t find the ticket.

Aside from the above, please notice that as soon as you conclude a Direct-POS transaction, the interface goes back into a mode, waiting for input of a salesperson’s two-letter code to begin the next transaction. It is thus a system that is always ready to perform a never-ending succession of such transactions.

Another detail concerns the option to customize the text as presented under the POS form’s signature line. You might want to add your text (e.g., “NO RETURNS ON ELECTRICAL PARTS”). To do so, create the text you want and save it in a plain-text file named PosDisclaimer.TXT. Place this into the \sd\netdata folder on your server. ServiceDesk will do the rest.

Regardless of which FinishedForm type (and context) is used, each has a section for line items that are being sold. Within each line item are multiple boxes or fields (the succession of several line items, each with fields, forms a series of columns). The first field within any line item is for the quantity of items. The second is for the part number (or, in the case of merchandise sales, the model number) as involved. The third is for description, and the fourth is for per-item price.

Regarding the second field, whenever the Windows focus first shifts into it (typically when you click into or tab to it), you’ll see a little grey selection window appear to its right:

This is the integrate-selection window. Its purpose allows you to pick what source you’ll be integrating with as you type a part or model number. As you can see from the above, there are three choices. The first is appropriate if you are selling parts inventory directly from stock. The second is the correct choice to input an item to special-order. The third and last choice will be if you sell merchandise — specifically, serialized inventory — as managed by the SD-Dealer program.

Based on your selected source, the system will display an as-you-type dropdown containing matches that fit whatever you’ve typed with each keystroke. Thus, you can typically type but a few characters before seeing the desired item. At such point, select it, and the system will do a full insertion for you.

This is how integrations work regarding using the dropdown to aid in populating any particular line item with appropriate text. But there’s another, potentially more critical function. As earlier alluded, we want to use the POS interface as a mechanism for actually pulling items as used from our inventory (i.e., if I used one widget from a stock of three, I need to have the system log such usage and decrease its count of widgets down to two). We likewise want to use it to create special-order parts requests, which involves our POS transaction. How does this occur?

In a nutshell, it’s a two-step process.

Any such operative transactions (operative in creating transactions within our inventory or parts-process systems) begin with an applicable line item flagged for such an event. Flagging is shown by any line item being shifted in color, with a particular color standing for each flagging. The flagging of a line item is done for you when you select an item from the offered dropdown. Thus, if you choose from the Parts-Inventory connected dropdown, the resulting line item will “flag” as yellow (the color that designates flagging for potential pull from parts inventory). If you select from the SmartParts-Listings dropdown, the resulting line item will “flag” as blue (the color for the potential creation of a special-order part request). Finally, if you select from the Serialized-Inventory dropdown, the line item will “flag” as orange (the color for potential pull from SD-Dealer-managed merchandise inventory).

These are not the only mechanisms for flagging. They are handy mechanisms if you pull from the associated dropdown anyway. There is also a method for more volitionally flagging (or de-flagging, if that’s the desired operation). If you want to manage the color flag volitionally, right-click in a line item’s description box. Doing so will produce another dropdown:

As you can see, this dropdown includes a complete set of flagging/de-flagging options and an option to delete the entire line-item, if that is your preference.

Our overall point is that you can use such mechanisms to populate line items within your POS form to accurately reflect what you’re selling to your customer and how the interaction of such sales should relate to other elements managed within ServiceDesk. However, nothing operative happens until you tell it to.

This occurs during the next step when you execute the POS transaction.

We've had many clients who, in the POS environment, wanted the ability to insert line items to POS tickets, but as pulled from other than the inventory system's MasterPartsPlan, SmartParts listings (as typically applicable to special-order parts) or to serialized inventory as pulled from the SD-Dealer setup (these are the three pull/line-item-insertions that have formerly been available).

So, we've now added this ability.

You may make a custom list of the insertion options you want for your setup. Your list will need to have four columns. The first is an item identifier (roughly equivalent to a part number) and will (when selected from the POS context) be inserted into the part number column in the POS ticket. The second is for item description and will be inserted (obviously) in the description box. The third is for price and will (again, obviously) be inserted into the POS form's price box. The fourth column indicates whether the item is to be deemed non-taxable. If yes, you should place within this column/box the expression "NO TAX."

Once you've made your list (and as described), save it in comma-delimited format as PosInsertionsList.csv. Save to the \sd\netdata folder on your server. ServiceDesk will see your file there and then make use of it.

Specifically, you'll see a new option come up (this option will be activated only if ServiceDesk sees the indicated file) when clicking into the part number box in any POS line item:

You can pick this option, and your dropdown insertions option will be pulled from your created list.  If you pick an option for which "NO TAX" was designated (assuming you've picked one of the FinishedForms that includes the line-item-based tax-exempt checkboxes), that line item will automatically check for you.

Functionality for these insertions exists in the Android, iOS, and Windows versions of SD-Mobile.

We added an option that allows you to create a list of non-inventory and non-special-order-parts items that you may want to insert in a POS context to a ServiceDesk FinishedForm.

We added line-item tax-exempt checkboxes to the Mobile instance of ServiceDesk's internal FinishdedForms interface. This was particularly important because one of the properties you can specify in your POS-Insertions list is that an item should be treated as tax-exempt. With checkboxes to register this, that specification could be honored in this context:

We previously referred to “flagging” line items for action because flagging is just that: it only flags and does not do the underlying action for which the item is flagged.

To do the set of actions as flagged, there’s a separate button on the form that must be clicked (whether virtually or directly). Not surprisingly, the button is labeled (with a bit of implicit abbreviation) “execute LnItms:”

But you should notice that there are other buttons, which are likewise associated with going forward with a transaction as prepared within and described by what you’ve set up within your POS form. Again, the button setup is structured to allow you to integrate multiple actions (according to preference) within a single click or to click on any such action individually.

Quite simply, if you click on the “Execute Sale” button, you’ll be offered all execution actions (whose checkboxes are checked) plus the SalesJournal entry itself (thereby allowing what is essentially a single-click execution of all actions associated with the sale). If you click on the “Do Inclusions Only” button, you’ll be offered execution of all the sub-actions (whose checkboxes are checked) but not a corresponding SalesJournal entry. This latter would be appropriate if you’re ordering a part, in which case (as a formal accounting principle) a complete sale should not be entered until the part is received and delivered to the customer.

Regardless, the general concept is you’re going to finish a POS transaction by executing it, designing your execution to include whatever steps should properly be involved.

A related topic is raised regarding “delivering” your part to a customer. Assume you previously used POS execution (as described above) to, among other things, create the internal special-order request. Then, via the PartsProcess system, you ordered the part from your vendor, checked it in upon its arrival, and then called your customer to indicate they should come in and pick it up. When the customer comes in for the pickup, what do you do? You’ll want to bring up the JobRecord form F7 as involved in the sale, choose its PrintOptions command, and from there, pick FinishedForms. Choose a “Fresh Import” of information to the form, which will bring information regarding the special-order part as received. In particular, the part will show double-carets accompanying its part number, which signifies it has not yet been checked off as delivered to the customer. This check-off is needed as part of the cradle-to-grave parts management system. A simple double click accomplishes that check-off.

You sold a part. The customer comes back and wants to return it. Though there are a few ways the situation can be handled (including various schemes that involve re-using and editing the prior ticket), all are subject to annoying quirks except the exact method we recommend here. We think you’ll be happiest if you abide by the following prescription.

Create a new ticket for the new POS transaction you are now conducting.

In such regard, please understand that even though any return relates to the prior “ticket” on which the item was sold, as an accounting and operational matter, it is nevertheless a new transaction and, from that standpoint, deserves to be treated as such. As it happens, such treatment is not only superior as a conceptual fit. Turns out it’s also better operationally.

In such regard, on your new ticket, enter any items being returned, much as you’d enter if you were selling them. The major textual difference is that, in any return-item’s quantity box, you’ll provide a negative value instead of providing a standard positive value. In other words, if you accept the return of 1 widget, use a quantity of “-1”.

Please also feel free to include items you are newly selling to the customer on this new ticket. In other words, there is no problem with a single new ticket involving both items being accepted in return (negative quantities indicated) and items currently being sold (positive quantities indicated).

It’s also true that if you want the POS mechanism to manage corresponding inventory movements for you (i.e., document movement of that widget back into inventory), any applicable line items must be “flagged” for such movement (just as with a sale). The movement must be “executed,” as discussed in the prior two sections. Regarding such movements, we have two caveats:

1. Our POS return-acceptance machinery has automated ties only to parts-inventory and not with the other two functions where it auto-ties on the “sale” side. In other words, while it auto-ties to the PartsProcess system on the sale side (i.e., it will create a request there when you sell a special-order part), it will not find such a prior request and cock it for vendor-return if/when you accept the part back (meaning you’ll need to attend to this separately). Similarly, while it auto-ties to Dealer/Serialized Inventory on the sale side (i.e., it will “pull” items from there when selling), it’s not yet configured to “pop” such items back into dealer inventory if/when you accept return (meaning, again, you’ll need to do such work manually within its operative area).

2. Since you are using a new ticket (with its unique Invoice/Ticket Number), any inventory-system return (i.e., the kind the system does direct-manage for you) must know the ticket number as involved in the original sale. You will be auto-prompted to provide this number directly within the line item involved:

Regardless of what’s auto-tied (or not) for physical item movements, financial/accounting elements will work exactly like in a regular sale POS sale, except they’ll (typically) [7] involve negative rather than positive values. In other words, as you invoke the “receive Funds” action, you’ll be giving money back to the customer (and simultaneously documenting the same). Applicable new insertions to your FundsJournal will be for negative (rather than positive) values. You can manage cash as being given back to the customer, or “plastic” credits, in the same direct, no-complications manner (in other words, proceed as if collecting, only with the negative rather than positive values; if you’re using our Virtual Terminal, it will know, with a negative value, to go into Credit mode). Similarly, invoking the SalesJournal entry will work the same as with a standard entry, except on returns, which typically involve a negative value.

Two potential rough spots may arise on the financial/money side of returns.

First is if you decide to refund money back to the customer by writing a company check. It’s rough only in the sense there’s no auto-integration — and can’t be — since ServiceDesk has nothing to do with managing your company’s checking account. If you decide to accomplish the refund in such a manner, do it separately, on your own, outside ServiceDesk. Go ahead and record the negative sale, but do not enter any movement of funds (it would not make sense because the money movement is one you’re managing separately). At least one client expected ServiceDesk to compile a list of checks that needed to be written from this context. Sorry, it’s not an element ServiceDesk manages.

Second is if you made your prior sale on credit (i.e., Paycode 2 with a still outstanding A/R). We have not configured an integration that will reach into the prior A/R and auto-decrement its amounts (or eliminate it if you’re making a complete return) based on your present return. So, suppose your present return ticket ends up at a negative value, and you have a present A/R for the customer where as much or more is owed; how do you handle that? Our suggestion is: (1) record your negative amount as a “paid” sale; (2) immediately open the prior A/R; and (3) add the negative total from your return ticket as a positive value to that prior A/R’s PaidToDate field. It’s a bit of manual work, but it should end with an accounting-perfect result.

Again, we want to distinguish FinishedForms from the up-front ticket-creation context. In the latter, we’ve invested intense programming capital to make an almost infinitely (and very easily) output customizable to user preference. FinishedForms are much less easily customizable beyond a few easy elements.

Among the easy elements, we’ve already explained how you can customize text that fits under the signature in the POS form. In addition, it’s also straightforward to specify particular graphics you might desire, instead of plain text, for your company’s header at the top of any specific form or, in some instances, as the form background. A small document explains how to set up and manipulate such graphics. You can access it via one of the instructional buttons that display when you first direct-display the FinishedForms interface Alt+F4):

If the above measures do not provide sufficient customization — and you require direct modification of an actual FinishedForm form layout — a much more intense investment will be required. If you’re determined, we can make a custom FinishedForm form layout for you. However, there will be a significant fee (usually several hundred dollars or more, depending on the degree of customization you seek).

If you’ve activated ServiceDesk’s Departmentalization feature, we highly suggest you create a department called “Counter Sales.” Among other things, the presence of a department of precisely that name will facilitate this right-click express transition from Callsheet to the FinishedForms/POS interface. Specifically, when you do that right-click, the system will look to see if you have a department called “Counter Sales,” and if so, will auto-assign the new JobRecord to that department. This avoids you needing to select and allows the system to shuttle straight to the FinishedForms, with no stop along the way. On the other hand, if no such department exists (and if you have Departmentalization activated), it will have to make the stop.

On the prior page, we noted a special consideration connected with Callsheet-initiated POS tickets, where you have ServiceDesk’s Departmentalization feature turned on. There is also a special concern regarding Departmentalization where you’re using Direct-POS. It is that (where Departmentalization is turned on) each sale must be assigned to a department. Yet, there is no interface within the Direct-POS interaction to pick the applicable department. The solution is for the system to auto-assign all Direct-POS sales to a department called “Counter Sales.” It’s hard-coded. If you turn on Departmentalization but have not created such a department yet and have conducted your first Direct-POS sale, the system will add that department for you.

SD-Dealer is one of the supplemental programs that may be acquired to work with ServiceDesk but is not part of it. It’s designed to manage serialized inventory and is basic but elegant. If you are interested, please get in touch with Rossware for details.

As a rule, the inserted line will include sell-for pricing on the part. It raises the question: how does the system know what price to insert? This is a reasonably complex topic because we provide much flexibility in structuring the underlying strategy. There is an entire document on the subject. You can access it via a button that’s visible when you first direct-display the Finished-Forms interface:

With every price insertion, the system attaches a ToolTip to the price box in question, which explains the basis used for the insertion. When you want to know the basis, you can just float your mouse pointer over, and the ToolTip will pop up to explain.

Our use of the word “ticket” here is deliberate. In general, “ticket” is a poor word for describing precise actions because it can mean many different things. In this particular context, though, we need a word with flexible meaning, and it’s here in this footnote that we’ll provide more precision. If you are using the direct-POS method (i.e., using the POS form directly and with no underlying JobRecord), for that context, a “ticket” would be defined as simply a new (completely new, fresh-initiated) POS invoice. Suppose you are conducting the transaction based on a JobRecord. In that case, it means an entirely new JobRecord, with a new invoice for that as generated via everyday creation purposes, etc.

We’ll admit that these added auto-ties should be present for truly integrated completeness. It’s also true, though, that ServiceDesk is primarily a service-management system, as opposed to being the utmost/best-possible POS system. If not for the fact so many other developmental demands tug us toward other priorities, we’d address these elements of incompleteness immediately. We are leaving them for the time being because, for now, there are higher demands on our developmental resources. This is particularly true because (a) regarding special-order parts, we feel the only sensible policy is not to allow such returns in the first place, and (b) returns of items back into dealer inventory are likely a very infrequent event.

Exceptions will occur where you’re also selling new items on the same ticket, which sum to a greater value than items being accepted in return. In such cases, you’ll still collect money and enter a sale for positive (though reduced by the return amount) values.