Home > Technical > Processes > Pending Transactions

Pending Transactions

Pending transactions are an extension of basic sale transaction, the processing of which is described here. A pending transaction is any transaction that needs to be stored for future activity. Examples of pending transactions are:

The pending transactions can be divided into two types -held transactions and customer transactions.

Held transactions are simply put on hold with the intention of retrieving them later for payment. Table tracking is the main example of held transactions. They do not impact on stock at all and do not generate any auditable transactions until they are finalised when they are simply seen as a sale transaction.

Action

Impact

Start a sale. Add a drink item and put on hold.

1. Sends the transaction immediately to MCS. MCS will write records to the CUSTORDERHDR, CUSTORDERITEM and CUSTORDERTENDER tables to record the specific transaction details.

Note: The transaction can be sent to either MerchantCentralServer (MCS) or MerchantLocalServer (MLS), depending on which option you have configured. MLS has a similar set of tables stored in DBISAM format. In either case, the server must be available or the user will receive an error. In a high traffic environment, MLS is a good option because it removes the network connection to head office as a point of failure.

Recall the transaction, add a food item. Put back on hold.

1. Sends the transaction immediately to MCS. Now, MCS cannot really determine what has changed about the customer transaction. So it will delete the entire transaction to show it never existed and then it will reinsert the transaction again (just like it did in the previous step).

As part of the deletion, MCS will delete the existing records from CUSTORDERHDR, CUSTORDERITEM and CUSTORDERTENDER tables.

Recall the transaction and do a print bill.

1. Sends the transaction to MCS. It is deleted and reinserted as above.

2. Generates a PRINTBILL transaction which will be written to the POS statistics directory to be sent back to back office and processed as a transaction. This will generate DAILYSALES records to audit the fact that a print bill has been done.

Recall the transaction and pay it out.

1. Tells MCS/MLS to deletes the transaction from the CUSTORDERHDR, CUSTORDERITEM and CUSTORDERTENDER tables

2. Generates a SALE transaction which will be written to the POS statistics directory to be sent back to back office and processed as a transaction. This will generate DAILYSALES records to show the transaction took place. Because this is a completed sale, a STOCKAUDIT record is written and the STORERNG.dblStockOnHand is adjusted to show the stock has been used.

Customer transactions are similar but have extra requirements. They will generally have a part payment on them so that has to be recorded and they generally have an impact on stock figures. Unlike held transactions, they MUST be written to MCS. They cannot be written to MLS.

Action

Impact

Start a customer order transaction. Add an item. Make a deposit payment. Complete transaction by paying with the Order tender.

1. Sends the transaction immediately to MCS. MCS will write records to the CUSTORDERHDR, CUSTORDERITEM, CUSTORDERSERIAL and CUSTORDERTENDER tables to record the specific transaction details. It will also create a STOCKAUDIT record and adjust STORERNG.dblAllocatedQty to show the stock has been allocated for use by this transaction. For customer orders, a CUSTORDERCHG will be written for any new or changed records.  

2. Generates an ORDER transaction which will be written to the POS statistics directory to be sent back to back office and processed as a transaction. This will generate DAILYSALES records to show the transaction took place.

Recall the transaction to make another payment.

1. Sends the transaction immediately to MCS. Now, MCS cannot really determine what has changed about the customer transaction. So it will delete the entire transaction to show it never existed and then it will reinsert the transaction again (just like it did in the previous step). When the transaction is reinserted, CUSTORDERCHG will be written for any new or changed records. If the quantity of an item was changed from 3 to 5, a CUSTORDERCHG would be written out for 2. Its recording the delta (change) of the item. This is only done for orders, not laybys or CODs. As part of the deletion, MCS will delete the existing records from CUSTORDERHDR, CUSTORDERITEM, CUSTORDERSERIAL and CUSTORDERTENDER tables. For each item deleted from CUSTORDERITEM, it will write a STOCKAUDIT record  and decrease STORERNG.dblAllocatedQty to show it is no longer allocated.

2. Generates an ORDER transaction which will be written to the POS statistics directory to be sent back to back office and processed as a transaction. This will generate DAILYSALES records to show the transaction took place.

Recall the transaction to finalise order.

1. Unlike held transactions, the details from CUSTORDERHDR, CUSTORDERITEM, CUSTORDERSERIAL and CUSTORDERTENDER are not actually deleted. The CUSTORDERHDR.strStatus  is changed to 'FINAL' to show the transaction is completed. We don't actually delete the transaction so we have an audit of the finalised instance of the customer transaction.

2. Generates a CORDER transaction which will be written to the POS statistics directory to be sent back to back office and processed as a transaction. This will generate DAILYSALES records to show the transaction took place. Because this is a completed order, a STOREAUDIT record is written and STORERNG.dblAllocatedQty is adjusted to show the stock is no longer allocated. At the same time a STOCKAUDIT record is written and the STORERNG.dblStockOnHand is adjusted to show the stock has been adjusted.

Layby transactions and COD's work in basically the same way. Its only the CUSTORDERHDR.strType that changes to distinguish between the different transactions. Quotes are almost the same. The one thing they don't need to do is adjust the allocated quantity for stock.

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)