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 one of two ways.

   In the form of RTLog files generated multiple times per day. This is the legacy approach. For more information, see Technical Implementation - RTLog Files Integration.

   Direct REST call to Sales Audit endpoint to post each incoming transaction. This is the new approach introduced since v21. For more information, see Technical Implementation - Sales Audit REST Integration.

   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.

   For more detailed information, see the following documents:

   • Retail Reference Architecture available on My Oracle Support

   • Oracle Retail Xstore Point of Service Technical Guide available on My Oracle Support

   • Oracle Retail Xstore Suite Implementation and Security Guide

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 - Sales Audit REST Integration

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

• Sales Audit REST Xstore Broadcaster

• Sales Audit REST Endpoints

• Scheduled Job to Query Sales Audit Rejected Transactions

• Xadmin UI to View and Republish Sales Audit Rejected Transactions

Sales Audit REST Xstore Broadcaster

Through Xadmin UI, create a broadcaster of type “Oracle Retail Sales Audit, REST Service" and specify Sales Audit REST endpoint as its endpoint url.

Note:

The endpoint url is in the form https://<host>:<port>/<tenancyId>. Do not specify endpoint url with full service path like following: https://<host>:<port>/<tenancyId>/ResaRestServices/services/private/ReSA/salesService

A Sales Audit REST broadcaster translates a transaction poslog xml to a JSON request, and posts it as payload to ResaReSTServices/services/private/Resa/salesService service. While out-of-box implementation of the translation is provided, the broadcaster gives a retailer the flexibility to customize the JSON request.

The broadcaster configuration wizard has a tab called Customize (see screen capture below). A user can provide custom mapping in yaml format to customize the JSON payload. A Preview feature is also provided to diff a transaction's JSON request with or without the custom mapping. Once the custom mapping passes the preview, a user can save it with the broadcaster configuration. After an initial delay of about 30 minutes, Xcenter will detect the mapping change and apply it to all transactions broadcasted out to Sales Audit.

Note:

For more information on how to write custom mappings in yaml, see the Oracle Retail Xstore Sales Audit REST Extension Guidelines (Doc ID Doc ID 1994467.1) on My Oracle Support.

Figure 3-2 Edit Broadcaster Screen - Customize Tab

Sales Audit REST Endpoints

Two Sales Audit REST services are used by Xcenter. ResaReSTServices/services/private/Resa/salesService: A POST service called by Xcenter broadcaster to post a transaction to Sales Audit. Its payload is the JSON representation of the transaction. A success response is returned if it passes initial validation and is accepted by Sales Audit.

ResaReSTServices/services/private/Resa/getRejectedTransactions: Once a transaction is accepted into Sales Audit, it is placed in staging tables. A batch process will generate the RTLOG file and the file will get consumed by saimptlog/saimptlogi batch. While generating RTLOG, if any validation fails, then that respective transaction will be moved to reject tables. Reject tables would act as the base for this Reject Query Service.

Scheduled Job to Query Sales Audit Rejected Transactions

The Query Sales Audit Rejected Job is scheduled to run hourly in Xcenter if a broadcaster of type “Oracle Retail Sales Audit, REST Service" is enabled for at least one organization. The job iterates through each distinct Sales Audit REST endpoint configured across all organizations to query for rejected transactions through its ResaReSTServices/services/private/Resa/getRejectedTransactions service, and updates the rejected transactions' WORK_STATUS column to “REJECTED" in Xcenter's poslog work item queue table TRN_POSLOG_WORK_ITEM.

Xadmin UI to View and Republish Sales Audit Rejected Transactions

To view rejected transactions, a new View Error Log button is introduced in Xadmin SystemTools > Publish PosLog Data. Once clicked, it displays all rejected or otherwise errored out transactions within the range of a user specified criteria for each broadcaster (See below for a screen capture of the UI). It provides error details, and allows a user to republish all or a subset of them once the underlying problem is fixed.

Figure 3-3 POSLog Search - Sales Audit Rejected Transactions

Technical Implementation - RTLog Files Integration

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

• RTLog File Xstore Broadcaster

• Xstore RTLog Generator

• Sales Audit saimptlog/i

RTLog File Xstore Broadcaster

Through Xadmin UI, create a broadcaster of type “Oracle Retail Sales Audit, RTLog File" and specify RTLog generator url as its endpoint url.

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 RTLog Generator On-Premise.

Sales Audit saimptlog/i

Sales Audit is the gateway for POS transactions to integrate to Oracle Retail Merchandising 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