Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
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. The direct integration to ReSA via the RESA Web Service is the go forward integration approach that should be used by customers. 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.
| Org Nod Date | e : Nov 19, 2021 To No | v19,2021 | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Delete | |||||||||
| Trans# | Type | Register# | Store# | Date | ServiceId | LastUpdate | Status | Error | |
| 6685 | SystemOpen ystem Oper | 1 | 2324 | Nov 19, 2021 jov 19, | RESA_REST_SERVICE J rs | Nov 19, 2024 lov 19, | RESA_ERROR… ORMORE TRANSACTION ARE ERROR OUT | {“status’.”ONE status”: we | |
| 6685 | ‘SystemOpen | 1 | 2324 | Nov 19, 2021 | XBR_1000 | Nov 19,2021 | XBR_EXCEPTION RESA_ERROR: | —com.micros_reta… | |
| 6686 | Session Control | 1 | 2324 | Nov 19, 2021 . | RESA_REST_SERVICE _ - | Nov 19, 2021 ° | ORMORE TRANSACTION ARE ERROR OUT | {“status""ONE . ~ | |
| 6686 6687 | Session Control Session Control ssion Control | 1 1 | 2324 2324 | Nov 19, 2021 Nov 19, 2021 jov 19, | XBR_1000 RESA_REST_SERVICE J rs | Nov 19,2021 Nov 19, 2021 lov 19, | XBR_EXCEPTION RESA_ERROR:.. ORMORE TRANSACTION | com.micros_reta… " ""ONE {“status”: oe |
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 SqlLoader Files. This includes (as necessary) creating errors for the auditors to research and correct. A subsequent SqlLoad 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