Prior to March ’08, each and every POS transaction required initiation via exactly the same 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 on the basis of 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 who rightly complained that such procedures were too cumbersome for situations where they simply 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, one that would stay on the screen always, instantly ready to quickly conduct simple sales, and without simultaneous creation of a JobRecord (an instrument that is really designed, obviously, to manage performance of service).

This is 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 wanted.  It’s a mode, specifically, that makes what is essentially a dedicated, POS-operations-only window, of a kind you can have “always-on” at any station that’s dedicated to a part-sales counter.  It’s expressly designed for that circumstance, and particulars are described in the next 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, too, has been enhanced to make it a little more direct.  Specifically, if from a Callsheet you right-click on the Job/Sale button (as opposed to left-click) 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 make sure 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.  In this mode and instead, the same box invites you to type the ID of a Sales Person.  This is, in fact, 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 to begin a new transaction, and who is the operator conducting it.

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

Underlying, though, is a major 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, and telephone, etc.).

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

As another difference you will notice 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.  In fact, even as you begin filling-in boxes with items you’re intending to sell, nothing is recorded (and no invoice number is pulled) until you execute (by clicking on any of the 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.

In regard to 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, internally, ServiceDesk can distinguish the reference as 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 keep the above in mind if you want to look up a ticket that was created via this method.  To emphasize, the onlyplace 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, it’s critical to include the leading minus sign.  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 just as soon as you conclude a Direct-POS transaction, the interface goes right back into a mode waiting for input of a sales person’s two-letter code, to begin the next transaction.  It is thus a system always-ready to perform for a never-ending succession of such transactions.

One more detail concerns the option to customize the text as presented under the POS form’s signature line.  It’s obvious you might want to add your own particular text there (e.g., “NO RETURNS ON ELECTRICAL PARTS”).   To do so, simply 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/or context) is used, each has a section for line-items that are being sold.  Within each line-item, there 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 quantity of items.  The second is for the partnumber (or, in the case of merchandise sales, the model number) as involved.  The third is for description, and fourth for per-item price.

In regard to 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 is to allow 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 when you’re intending to input an item to special-order.  The third and last would be the choice if you’re going to sell merchandise — specifically, serialized inventory — as managed by the SD-Dealer program.

Based on which source you select, 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, simply select it, and the system will do a full insertion for you.

This is how integrations work in regard to using the dropdown to aid in populating any particular line-item with appropriate text.  But there’s another, potentially more important 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 decrement its count of widgets down to two).  We likewise want to use it as a mechanism for creating special-order parts requests, where that’s a situation involved with our POS transaction.  How does this occur?

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

Any such operative transactions (operative in the sense of creating transactions within our inventory or parts-process systems) begin by having an applicable line-item flagged for such an event.  Flagging is shown by virtue of any such line-item being shifted in color, with a particular color standing for each kind of flagging.  The flagging of a line-item is done for you when you select an item from the offered dropdown.  Thus, if you select 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 potential creation of a special-order part request).  Finally, if you select from the Serialized-Inventory dropdown, the resulting 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 simply handy mechanisms, if you happen to be pulling 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 volitionally manage the color flag, simply right-click in a line-item’s description box.  Doing so will produce another dropdown:

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

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

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

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

To actually 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 implicit abbreviation) “execute LnItms:”

But you should notice, there are other buttons too, which are likewise associated with actually going forward with a transaction as prepared within and described by what you’ve setup within your POS form.  Again, the button setup is structured so as 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 single-click execution of all actions associated with the sale).  If you click on the “Do Inclusions Only” button, you’ll simply 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 really 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 as should properly be involved.

In regard to “delivering” your part to a customer, a related topic is raised.   Assume you prior used POS-execution (as above described) 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, then called your customer to indicate they should come in and pick it up.  When the customer actually comes in for the pickup, what do you do?  Simply, you’ll want to bring up the JobRecord form (F7) as involved on the sale, choose its PrintOptions command, and from there pick FinishedForms.  Choose to do a “Fresh Import” of information to the form, as this  will bring in information regarding the special-order part as received.  In particular, the part will show with 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.  This subject is further discussed within the chapter section that discusses PartsProcess management (see Page 133).

v.         Accepting Returns

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-use and editing of 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, in fact, 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 item or 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, rather than providing a standard positive value, you’ll provide a negative value instead.  In other words, if you’re accepting return of 1 widget, use a quantity of “-1”.

Please also feel free on this new ticket to include items that you are newly selling to the customer.  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 itself 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), and the movement must be “executed” as per discussion in the prior two sections.  Regarding such movements, we have two caveats:

1.                   Presently, 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 go 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 own operative area). [6]

2.                   Since you are using a new ticket (with its own 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 actually be giving money back to the customer (and simultaneously documenting the same).  Applicable new insertions to your FundsJournal will simply 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, as you invoke the SalesJournal entry, it will also work just the same as with a normal entry, except on returns it will also typically involve a negative value.

There are two potential rough-spots that 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 manner, just 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).  We had at least one client that expected ServiceDesk to at least 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 did your prior sale on credit (i.e., Paycode 2 with a still outstanding A/R).  We have not at this time configured an integration that will reach into the prior A/R and auto-decrement its amounts (or eliminate it entirely, if you’re doing a complete return) on the basis of 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 tiny bit of manual work, but should nevertheless end with an accounting-perfect result.  

We want to again distinguish FinishedForms from the up-front ticket-creation context.  In the latter, we’ve invested intense programming capital to make an output that is almost infinitely (and very easily) customizable to user-preference (see page 269).  FinishedForms are much less easily customizable, at least 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 very easy to specify particular graphics you might desire, in lieu of plain text, for your company’s header at the top of any particular form, or in some instances as the form background.  There is a small document that explains how to setup 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):

In the alternative (and at least in the PDF version of this manual), you can use this link.

If the above measures do not provide sufficient customization — and in fact you require direct modification of an actual FinishedForm form layout — a much more intense investment will be required.  If you’re determined in such regard, we can make a truly-custom FinishedForm form layout for you, though there will be a significant fee (usually several hundred dollars, or more, depending on the degree of customization you seek).  In the alternative, if you’re intrepid and have a bit of programming bent, you can do it yourself.  We have a complete instruction document for the purpose.  It’s  contained within a folder on your installation CD, which also contains other elements you’ll need.  The folder is called “VbUtility.”  The instruction document, within, is called “Instructions.pdf.”

If you’ve activated ServiceDesk’s Departmentalization feature, we highly suggest you create a department called “Counter Sales.”  Among other things, 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 said department.  This avoids you needing to select, and allows the system to shuttle straight to the FinishedForms, with no stop along the way.  If no such department exists, on the other hand (and if you have Departmentalization activated), it will have to make the stop.

On the prior page we had a note regarding a special consideration as 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 by which to pick the applicable department.  The solution is the system auto-assigns all Direct-POS sales to a department called “Counter Sales.”  It’s hard-coded.  In fact, if you turn on Departmentalization but have not created such a department, yet conduct 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 actually part of it.  It’s specifically designed as a mechanism to manage serialized inventory, and is basic but elegant.  If you are interested, please contact Rossware for details.

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

Or (at least if within the PDF version of this manual), you may click here.    Please also note that, with each and every price insertion, the system attaches a ToolTip to the price box in question which explains that basis as used for the insertion.  When you want to know the basis, just float your mousepointer 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 so 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.  If you are conducting the transaction on basis of a JobRecord, on the other hand, it means an entirely new JobRecord, with new invoice for that as generated via normal creation purposes, etc

We’ll readily admit that for true integrated completeness, these added auto-ties should be present.  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 particular true because: (a) in regard to special-order parts, we feel the only sensible policy is to not 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 be collecting money and entering a sale for positive (though reduced by the return amount) values.