Home > Technical > Processes > Sales From POS To Database

Sales From POS To Database

You've made a sale at POS and now you've got data in the database. But how did it get there?

Process 1

When a sale is completed at DynaPOSTouch, the main thread will write a text file to the \drsapps\dynapos\statistics\x\sales and \drsapps\dynapos\statistics\x\tillread directory (where x is the till number). The sales directory is used to record the transactions that need to be sent to the head office while the tillread directory contains the files used for tillreads (and is of no further interest in this discussion).

The name of the file has the following format:

yyyymmddhhnnss-aaaaaaaaaa-bbbbbb-ccccc-dddddd-ttttt-A.POS

yyyymmddhhnnss is the current date/time.

aaaaaaaa is an internal transaction number at POS. It starts at one when POS is started and will increment by one each time.

bbbbbbb is the location code.

ccccc is the till code.

ddddd is a GUID number and is guaranteed unique

ttttt is the transaction type. This will generally be POSTRANS.

Example: 20060404101013-0000000001-BSHP2-TILL1-4D9664A8FAA840688040E8F6529B1142-POSTRANS-A.POS

A background thread in DynaPOSTouch will poll the sales directory every 10 seconds looking for files. When it sees a file it will try to open it in exclusive mode. If it can't open the file, it assumes the file is still being written and will leave it until the next cycle. If the file can be opened, the thread will call the SendPOSTrans in MerchantCentralServer to move the contents into the INCOMINGTRANS database table and to update the TILLSTATUS table. When POS sends the contents of the file, it also sends the GUID part of the file name. MCS will use this to determine if the file has already been received. If records already exist in INCOMINGTRANS for this GUID, MCS will ignore the records and tell POS it was successful. The background thread will then move the file from the \ drsapps\dynapos\sales\x directory to \ drsapps\dynapos\sales\x\backup to show the file has been sent. POS will delete the files from \ drsapps\dynapos\sales\x\backup after three days.

All transactions sent from POS to MCS are CRC checked. The CRC is generated by the POS and sent to MCS along with the transaction. MCS then calculates the CRC and compares it against the one the POS generated. If they are different an error is logged to AUDITTABLE.

Process 2

When DynaPOSTouch sends the file, the files end up in the INCOMINGTRANS table. The Tillincoming service will read the records from INCOMINGTRANS and send them to MCS for further processing. Firstly, Tillincoming does a query to determine all unique INCOMINGTRANS.INTTRANSCODE values which have not been processed. The list is processed in alphanumeric sequence. For each number, TillIncoming will read all the INCOMINGTRANS records. It will then pass that set of records to MCS for actual processing.

When MCS gets a transaction from TillIncoming, it will check to see if the location has been locked for a stocktake. If it is not locked it will process each line and update the appropriate records. This includes:

These details are all done within one transaction. If an error occurs, the INCOMINGTRANS.intStatus will be updated to 2, to show the records were processed but with an error.

If the location was locked for a stocktake, the INCOMINGTRANS will simply be updated so intStatus is 4. This effectively puts the transaction on 'hold' for later processing. When the location is unlocked, all records with intStatus of 4 are updated to 0, so they will be picked up again for processing.

The basic processing can be summarised with the following pseudo-code:

try

  if location is locked for stocktake then

    update INCOMINGTRANS intStatus=4   // see below for more details

  else

    update DAILYSALES

    decrease stock

    adjust accounts

    set INCOMINGTRANS intStatus = 1   // successfully processed  

except

  set INCOMINGTRANS intStatus = 2  // bad sale

end

Periodically, TillIncoming will update any INCOMINGTRANS with intStatus of 2 to intStatus of 0. This allows the system to reprocess the records in the hope that the conditions causing the error have been fixed. If the error occurs again, the records are simply updated to have intStatus of 2. The interval between these updates is usually 60 minutes but this can be controlled by the Bad Sales Check option in System Settings.

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