3 Transaction Flow from Xstore to Sales Audit

Xstore is the source of Point of Sale (POS) transactions, including but not limited to the following:

• Sales

• Returns

• Voids

• Cash management transactions

• Many store activity transactions

All transactions produced in Xstore are sent to Sales Audit. Sales Audit processing is primarily concerned with transactions that alter inventory or contain payment. Sales Audit loads other types of Xstore transactions (such as entering training mode, gift registry creation, and so on) into an OTHER transaction type for full visibility and to avoid gaps in the transactions sequence, but will not out of the box perform any audit functions on these OTHER types of transactions.

Sales Audit validates Xstore transactions that impact inventory (such as sales, returns, and customer orders) and exports the information to Merchandising to record the full financial and inventory impact.

Conceptual Data Flow

Figure 3-1 illustrates the transaction flow from Xstore to Sales Audit.

Figure 3-1 Xstore to Sales Audit Transaction Flow

The following steps describe the flow shown in Figure 3-1:

1. All Xstore registers replicate, or persist, all transactions to Xcenter. Note that this includes both customer related transactions (sale, return, void, and so on) and cash management/store operation transactions (paid in, no sale, change to training mode, and so on). Xcenter uses these transactions for activities such as cross location returns.

2. Xcenter broadcasts all transactions to Sales Audit in the form of RTLogs generated multiple times per day. For more information, see "Sales Audit saimptlog/i".

3. After successful totaling and auditing, Sales Audit sends all sale/return transactions to Merchandising, where the transactions impact perpetual inventory. For detailed information about uploadsales_all.ksh, see Oracle Retail Merchandising Operations Guide, Volume 1 - Batch Overviews and Designs.

   
   

   Note: Integrating sales and returns data directly to Merchandising, bypassing Sales Audit, is not a supported integration.

   
   

Technical Implementation

The technical implementation of the data from Xcenter/Xstore to Sales Audit consists of three main components:

• Xstore Broadcaster

• Xstore RTLog Generator

• Sales Audit saimptlog/i

Xstore Broadcaster

The broadcast system in Xcenter provides a means to transmit POSLog data to other systems. The data is transmitted just as Xcenter receives it from the registers through the replication system, which is approximately in real-time. The temporal ordering of the POSLog data is also preserved, just as it is with the replication system.

There are a few systems which the base version of Xcenter can readily broadcast data to, simply by making configuration changes.

For more detailed information, see the following documents:

• Retail Reference Architecture available on My Oracle Support

• Oracle Retail Xstore Technical Guide available on My Oracle Support

• Oracle Retail Xstore Suite Implementation Guide

Xstore RTLog Generator

RTLog generator is a component that collects and aggregates broadcaster transactions and transforms them to the RTLog file format.

The on premise RTLog generator is packaged with Xstore, but is generally deployed in the same file system as Sales Audit.

For more information, see Chapter 6.

Sales Audit saimptlog/i

Sales Audit is the gateway for POS transactions to integrate to Oracle Retail headquarter systems. There are two Sales Audit sub-processes that can upload POS files:

• saimptlogi.c is used when loading sales incrementally throughout the day from stores, instead of just once per day. It validates files and directly inserts the transactions into the Sales Audit tables. This includes (as necessary) creating errors for the auditors to research and correct.

• saimptlog.c is used for the once a day import of data from stores. It validates POS files and creates Sql*Loader Files. This includes (as necessary) creating errors for the auditors to research and correct. A subsequent Sql*Load process loads the transactions and errors into the Sales Audit tables.

saimptlog and saimptlogi are built with the same shared code and vary only in their approach to physically loading data into the database. The programs are collectively referred to as saimptlog/i.

There are a number of regular prerequisites in the Sales Audit batch schedule which must be completed before POS transactions can be loaded. For more information about supporting batch jobs, see Oracle Retail Merchandising Operations Guide, Volume 1 - Batch Overviews and Designs.

For more detailed information about saimptlog/i and the RTLog file format, see the following documents:

• Oracle Retail Merchandising Operations Guide, Volume 1 - Batch Overviews and Designs