First, let us make a little clarification in regard to how, within in its FundsJournal system (Ctrl-F9), ServiceDesk handles credit card transactions.
Way back in the day, most offices did not have electronic terminals of any kind, and for credit card transactions you’d actually have a paper “charge slip” on which the transaction information was partially stamped (with a physical imprinter) and partially hand-written. You’d collect and assemble these much like checks, and deposit them at your bank in exactly the same fashion. Thus, the general FundsJournal process—wherein first an entry is made to the FundsJournal denoting that you’ve received the item of money (whether cash, physical check or physical charge slip), and later you assemble and make a deposit (using FundsJournal tools, which simultaneously check off each item as having been deposited) made just as much sense for bankcard transactions as for cash and check receipts.
But now, with electronic terminals prevailing (whether real or virtual), you likely don’t collect any paper slip, and certainly don’t go through the process of physically depositing a batch of such slips with the bank. Yet, the same basic collect-individual-items-and-then-deposit- as-a-batch structure has persisted, as an imperfect fit, within our system. Our suggestion, as the underlying substance has changed, has been that you continue entering bankcard “receipts” as per normal (regardless of whether you’ve already “ran” the transaction or not). Then, on likely a daily basis, go through each of the bankcard collection/transaction items that you’ve actually ran, and do a pseudo deposit process in their regard (i.e., even though you’re not physically taking a batch of slips to the bank, you sort of pretend like it, which causes the items as so indicated to be checked off appropriately).
To be candid, we’ve felt increasingly guilty about the above arrangement, suspecting it is less than convenient at the end of each day to clarify which bankcard transactions, as still not checked off as “deposited” within the FundsJournal, actually have been run (and so should be included in a current pseudo-deposit process), versus ones that may still need be run. As part of the current upgrade, we’re providing a remedy for that very conundrum. As of ServiceDesk Ver. 4.3.112, you can now explicitly designate, within the FundsJournal, that any particular bankcard entry has actually been run (and, as an event/process separate from doing the pseudo-deposit).
To do so, simply right-click on any such entry (you’ll need to be in the display mode: View/Edit Items ? Bankcard ? Receipts ? Undeposited/Unverified). Now, you’ll see some new options presented, including one that reads:
When you select that option, the system will ask you for the reference number from the actual credit card transaction. When you provide it, it willchange the reference in the line that formerly read as simply:
to read instead as:
(assuming that 123456 is the reference number you provide). This change in content then serves as an at-a-glance indication that the charge process has actually run for the item in question. And, when at the end of the day (or other convenient time) you go ahead and run the pseudo-deposit process for the day’s bankcard transactions (a process that we highly recommendyou continue to pursue), it will provide an on-its-face its indication of which items have (at least supposedly) actually been run.
To put this in a more real-world perspective, suppose you’re not using our new Virtual Terminal. Your techs “collect money” from some percentage ofjobs simply by getting the applicable credit card information, which is brought back with the ticket, with intent that you’ll manually run the transactions at the office (by manually keying into a terminal, using PCCharge, etc.). As you thus run each transaction, you can go to the FundsJournal and use the above-described process to sort of “log” there the fact, in regard to each such item, that it’s physically been run.
We think this brings “up to snuff” the general structure of handling bankcard transactions in the ServiceDesk FundsJournal. Conveying an understanding of the improvement was also an important foundation to the next discussion.
The primary context in ServiceDesk where the new Virtual Terminal is invoked is from the FundsJournal form (Ctrl-F9), when creating a new item entry of “Bankcard” type.
As always from that form, you can create a new entry by going directly there, clicking on the “Add New Item” button, and appropriately filling in the boxes.
However, that method is very seldom used.
Much more typically, you arrive at essentially the same place via other methods, such as:
In all such contexts, you find yourself at the top of the FundsJournal form with a simple row of editing boxes. The first is pre-filled with Invoice Number, and second with Customer Name. The third and fourth are blank, and ServiceDesk has you pre-positioned in the first of these latter two, where it expects an indication of money type.
This is all as per normal, and has been the structure for a long time.
So far, nothing has changed. Just as always, you’ll type a simple letter to indicate money type (e.g., “c” for cash, “b” for bankcard, etc.), then ServiceDesk tabs you to the next (fourth) box, where you type in the amount. With all four boxes now filled in, you hit ‘Enter’ on your keyboard to save.
That is now the magic point where, with this new addition, it’s time to be excited. At this point (i.e., of hitting “Enter” to save, and assuming you’ve indicated it’s a “b” for bankcard transaction), the Virtual Terminal will appear.
At such point, you can simply swipe a card (assuming you’ve equipped your computer with a swiper), or manually fill-in card number and other data,* then run the transaction. After you do so, Esc from (or otherwise close) the form. ServiceDesk will now appropriately “toggle” the underlying FundsJournal entry to show the transaction has run (i.e., will add the applicable reference number).
It’s just that simple. And, please note you’ll automatically find yourself in this appropriate context based on having easily transited there from any of the above-described operational contexts (i.e., POS, Type-II PVR or entering funds directly from a JobRecord).
What could be nicer than that? There are two added contexts via which you can display the Virtual Terminal:
This is very simple. The ‘Print’ page in SD-Mobile has a new button labeled “Run charge on CC.” If the tech wants to run a charge, he clicks on the button, and sees the same Virtual Terminal you enjoy back in the office. Naturally, in this context too, it auto-fills appropriately. He can either type in card data or swipe. And when he runs a charge, appropriate info regarding the same plugs automatically into SD-Mobile, and is in turn appropriately transmitted back to the office.
The feature is present in SD-Mobile Ver. 1.1.4 and later. You’ll need SDMobileLink Ver. 1.1.3 or later to successfully process back to the office, and you’ll need ServiceDesk Ver. 4.3.112 or later to accurately display such facts there (in all likelihood, you’ll be auto-updated to each of these versions, or later, regardless).
Not to be immodest (okay, maybe so), but it’s in the SD-Mobile context where we believe the new Virtual Terminal is a totally “Killer App.”
As mentioned in prior text, our Virtual Terminal leaves you free to either key-in card data or swipe the card. If you’re keying (only choice if the card is not present), you need to be aware of a simple assist the system provides.
In most cases, you should notice that three added little yellow boxes appear, when you open the keyed-entry window, as follows:
.png)
The simple idea is, those little yellow boxes are populated, for you, with customer name, number-for-street-address, and zipcode—as pulled from the underlying JobRecord. The system refrains from automatically inserting this text to applicable boxes—based on the fact the Underlying card may have different credentials than involved in the JobRecord. So, the little yellow boxes serve as a prompt for your operator to ask the customer, for example, "Is the name on the card 'Jackie Smith.'" If the customer answers yes, then your operator should simply click on the little yellow box, at which point Virtual Terminal will insert the provided name to the operable box (otherwise, your operator should simply type the correct name as per normal). Same thing is true in regard to number-for-street-address and zipcode boxes.
Quite simply, we're trying to make it as easy as possible to insert the info, while nevertheless prompting your operator to verify its accuracy for the particular card that's involved.
As of March 9, ‘09, we’ve not yet added Virtual Terminal capability to this program. We’ll make it a priority to the extent users indicate a desire for it there.
This little section echoes a section, bearing the same title, in the main Virtual Terminal Handbook. We place the “echo” here to explain a corollary point, as regards the process of reviewing your transaction the Merchant Warehouse’s On-Line interface.
Specifically, we want to bring to your attention that, as you do the pseudodeposit process of bankcard transactions in ServiceDesk at the end of each day (or perhaps at the end of each week), a valuable cross-check is to do a tally of total transactions for the same period on-line, and confirm that the total there precisely equals the amount that, in ServiceDesk, you’re entering the pseudo-deposit for.
Make sure the two figures match.
If they do, obviously, you can be happy. If they do not, you’ll need to hunt down the reason for discrepancy.
This is a cross-checking method, in other words, to assure everything is accurate on both ends.
