Show TOC

Process documentationSales Day Data Flow

 

Throughout the sales day, transactions are run through the terminal where customers pay for their goods. The following describes the basic flow of data during a typical sales transaction.

Prerequisites

This process assumes that the server is online with the Point of Sale (POS) application, and that the system is configured to use server data first in the case of Local PLU or Backup Server configurations.

Process

  1. After the cashier scans an item, the POS application sends the PLU to the server requesting product and pricing information.

  2. The server accesses the PLU tables in the SQL database and returns information such as price, description, taxes, and so forth.

  3. The returned information is immediately placed into memory and posted to the LD.jrn file (in ASCII format) located in the terminal’s \rdata directory.

  4. Steps 1 to 3, inclusive, are repeated until all of the customer’s items are scanned or entered.

  5. As the cashier totals the transaction and accepts tender from the customer, more information is placed into memory and posted to the LD.jrn file.

  6. If the tender is a credit card, the card information is sent to the server where it is transmitted to an application-specific credit service provider.

  7. Once the server receives a response from the credit service provider, it transmits the answer back to the POS application, which then posts this additional information (masked card number, credit verification) into memory and into the LD.jrn file.

  8. The transaction in memory is then posted to the binary LD.txn file.

    Note Note

    Credit verification requests and responses are in accordance with Payment Card Industry Data Security Standards (PCI).

    End of the note.

    Everything done at the POS is captured in the LD.txn and LD.jrn files, including sales, manager code functions, open and close actions, and reports.

Recommendation Recommendation

If you enable the powerfail option in the POS.ini file, you can have a file called Powfail#.sus in your \rdata directory. This option copies each line of the current transaction record to the Powfail#.sus file. Then, if there is a power outage, when the POS comes back online it can retrieve the current transaction data from the Powfail#.sus file and place it back into memory. The cashier can then complete the transaction in progress.

End of the recommendation.
The trickle process

The data for inclusion in the LD.txn file and LD.jrn file is continually fed, or trickled, to the server throughout the day. The trickle process is initiated by the server as it pulls both the LD.txn and LD.jrn files from the registers’ \rdata directory during idle time in the day.

If the server is busy performing a consolidation request, or an exit terminal request, the trickle will pause; otherwise, the trickle process is continuous.

Data from the LD.txn file (also known as the TLOG) is received from the POS and written to the server’s sdata directory (see below for naming convention).

Another process is responsible for reading and posting this data from the .txn file to the SQL database.

TLOG renaming

As the TLOG data reaches the server, it is written to data files in the \sdata directory using the following convention:

  • LD.txn becomes SSSSTT00.txn

  • LD.jrn becomes SSSSTT00.jrn

where

  • ‘SSSS’ is the store number

  • ‘TT’ is the terminal number

  • ‘00’ indicates that this is the current day’s file for that terminal (00 always means today)

Totals files and reports

At the end of a transaction at the POS and after the information has been posted to the TLOG, Totals files are updated in the \rdata directory of every register.

There are several different Totals files built from information in the TLOG, with each file name beginning with rd, which stands for Register Daily. The format of each of the Totals files is binary.

If you request a Store Sales report from Store Manager, the Store Manager requests the server to initiate a consolidation request. A consolidation request triggers the server to request and consolidate the appropriate rd.* file from each online POS device. This consolidated file is then posted to the SQL database, which the Store Manager uses for the report.

If you request a Store Sales Report for a POS terminal, the appropriate rd.* file is pulled from each online POS terminal and consolidated to an sc.* data file (sc stand for Store Consolidation). The process follows a pull, consolidate, pull, consolidate pattern until the data from all of the POS terminals has been processed.