| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.029 E99968-01 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.029 E99968-01 |
|
Previous |
Next |
This chapter is an overview of Oracle Retail Sales Audit Cloud Service.
The following information is maintained in the Sales Audit Cloud Service application.
Oracle Retail Sales Audit Cloud Service contains a set of system options that is different from the Merchandising Foundation Cloud Service system options set. These system options control functionality in Sales Audit Cloud Service. One of the important system option parameters is the balancing level. The balancing parameter could be Cashier or Register. If the balancing parameter is Cashier, the totals are balanced for each cashier. If the balancing parameter is Register, the totals are balanced for each register. Another important option is the unit of work. This determines whether transactions are exported prior to the elimination of all errors for the store/day. Other parameters include defining the escheatment party and the details of the clearinghouse. Certain business rules like duplicate and missing transaction number checks are also controlled through the system options setting.
Sales Audit Cloud Service requires a certain amount of foundation data to start working. Sales Audit Cloud Service shares some of its foundation data with Merchandising Foundation Cloud Service, while the rest of the foundation data needs to be maintained in Sales Audit Cloud Service.
Foundation data in Sales Audit Cloud Service includes company/location close dates, location traits, bank setup, tender types, reference maintenance, error codes and store-specific foundation data.
Sales Audit Cloud Service allows the retailer to define the Totals needed for their business. Totals in Sales Audit Cloud Service can be a Sales Audit Cloud Service-calculated value from raw transaction data or a total that comes from the POS/OMS through the RTLog. Sales Audit Cloud Service calculates a total based on raw transaction data or on existing totals. Totals are used for performing store balancing over/short analysis within Sales Audit Cloud Service. Totals are also used to create data for external systems such as General Ledger. By assigning an audit rule to the total, business validation is built in Sales Audit Cloud Service. For example, the retailer defines a Sales Audit Cloud Service-calculated total of total cash tendered at a register for a store/day. He defines another total, a POS/OMS-declared total, for the total cash declared at the register for a store/day. He defines an audit rule to compare both the totals for over/short analysis. Totals are used to export consolidated data to an external system. So, while defining a total, the retailer defines the systems to which the total is exported.
Rules are used in Sales Audit Cloud Service to perform custom data validation against transactions and totals. Audit rules run on POS/OMS transaction data and totals during the automated and interactive audit process. When the rule is broken, an exception error is thrown that must be edited or overwritten by the auditor. Sales Audit Cloud Service comes with some standard pre-configured rules and also provides flexibility to the retailers to define rules needed for their business.
Error codes provide information to the auditor about the type of error and the remedial action needed to solve the error, thus increasing the effectiveness of the audit process. When setting up audit rules for automated audit process, an error code is associated to the rule. The error code contains an explanation of why the rule failed, as well as a recommended solution. The error code also contains security settings to determine if the error can be overridden at the store or headquarters. When a rule fails, the error code is available to the auditor in the error list. Additionally the specific location where the error has occurred is available in the transaction details, thus helping the auditor to quickly understand and correct the error.
Automatic auditing is done in Sales Audit Cloud Service using batch programs. The goal of the automatic audit process is to accept transaction data from point-of-sale (POS/OMS) applications and move the data through a series of processes that culminate in clean data. Sales Audit Cloud Service uses several batch-processing modules to perform the following activities:
Import POS/OMS transaction data from the RTLog.
Perform initial validation of data during upload of data from the RTLog to Sales Audit Cloud Service.
Produce totals using user-defined totaling calculation rules that are user reviewable during the interactive audit.
Validate transaction and total data with user-defined audit rules and generate errors whenever data does not meet the criteria. The user reviews these errors during the interactive audit.
Create and export files of clean data in formats suitable for transfer to other applications.
Update the Sales Audit Cloud Service database with adjustments received from external systems on previously exported data.
Auditors use the interactive audit process to view and correct errors. This process is done after the automated audit is completed. This process allows the auditors to view errors at summary or detail level, fix or override errors, update the totals and close the store/day. In addition, it is also possible to review and edit data of missing transactions or transactions that have passed automated audit, add transactions and delete invalid or missing transactions.
Sales Audit Cloud Service provides summary views for the auditor to identify and fix the problem areas quickly. A Store/Day Summary View screen contains the following information about a store/day: The audit status, the data status, the number of transactions, the number of errors and the over/short amount. The auditor has access to other options in the Store/Day Summary screen such as: The error list, the balancing level summary, over/short, miscellaneous totals, missing transactions and the import/export log.
Sales Audit Cloud Service provides two other summary views: Tender Summary and Item Summary.
Automated Clearing House (ACH) is a U.S.-based banking network used to electronically transfer funds. Retailers use ACH to enable them to have access to funds before the funds have been physically deposited in the bank. This is done by estimating the following day's bank deposit and sending this amount to the consolidating bank through the ACH network. In this way, the cash to be received from the stores is hedged.
Escheatment is the process of forwarding monies of outstanding, non-expiring vouchers to the proper government authorities (state or country) after a defined period of time from the date of issuance. Some government authorities require that unredeemed vouchers be escheated after a specific period of time has passed. When a voucher is escheated, an invoice is generated that initiates payment of the escheated voucher amount to the government authority. The government authorities then attempt to locate the consumers owed the monies.
To accommodate Escheatment, a new total should be added to Sales Audit Cloud Service to create escheatment totals. Sales Audit Cloud Service automatically totals sales transactions based on calculation definitions set up for the total.
The audit trail functionality provides the users with the capability of tracking all changes to transactions and totals. Sales Audit Cloud Service maintains versions of all modified transactions thus enabling easy tracking of changes.
Totals for General Ledger that are impacted by a revised transaction are reversed and both the reversal and the new total are extracted for the General Ledger.
Sales Audit Cloud Service provides some basic online reporting that allows users to view sales audit data that is in the system. The following reports are available in Sales Audit Cloud Service:
Flash Sales report
Flash Totals report
Voucher Activity report
Dashboard and In-context reports
A system option controls whether Merchandising Foundation Cloud Service and Sales Audit Cloud Service are systems of record for customer information associated with customer orders or other POS transactions.
If Merchandising Foundation Cloud Service and Sales Audit Cloud Service are the systems of record, any information that the customer provided at the time the order was created or at the time the transaction occurred will be stored in the respective Merchandising Foundation Cloud Service and Sales Audit Cloud Service tables. If they are not the systems of record, Merchandising Foundation Cloud Service and Sales Audit Cloud Service will only store customer identifiers on the tables, and any required fields on the tables will contain generic default values (e.g. XXXX). These customer identifiers may be used to request the customer information from a third party order management system or customer engagement system that holds the complete customer information.
Oracle Retail Sales Audit Cloud Service interfaces with the following Oracle products:
Oracle Retail Merchandising Foundation Cloud Service
Store Inventory Management Cloud Service
Oracle Retail Invoice Matching Cloud Service
Oracle Retail Insights Cloud Service
This figure displays the Sales Audit interfacing products:
Oracle Retail Sales Audit Cloud Service also interfaces with the following third-party applications:
Automated Clearing House.
Universal Account Reconciliation System.
Sales Audit Cloud Service and Merchandising Foundation Cloud Service share the same database. Sales Audit Cloud Service shares some of its master data with Merchandising Foundation Cloud Service data such as items, stores, company/location close dates, location traits, bank setup, and tender types are maintained in Merchandising Foundation Cloud Service and used in Sales Audit Cloud Service.
Current reference data is retrieved from Merchandising Foundation Cloud Service into Sales Audit Cloud Service by the batch program SAGETREF. The data is extracted into multiple data files. The data in the files are used by the batch program SAIMPTLOG as reference data for doing validation checks on the POS/OMS transaction data during the data upload from POS/OMS to Sales Audit Cloud Service. Having the reference in data file formats increases the performance of the SAIMPTLOG process. SAGETREF generates the following reference files: Items, Wastage, Sub-transaction level items, Primary variant relationships, Promotions File, Currency File, Warehouse File, Inventory Status File, Variable weight PLU, Store business day, Code types, Error codes, Store POS, Tender type, Merchant code types, Partner vendors, Supplier vendors, Employee IDs, Banner IDs.
All clean and audited sales and returns data is extracted from Sales Audit Cloud Service into a POSU file by the batch program SAEXPRMS. All corrected sale and return transactions that do not have Merchandising Foundation Cloud Service errors are extracted into the file. The sales audit system options parameter work unit controls the export of data into file in case of presence of Merchandising Foundation Cloud Service errors in the POS/OMS transaction data. The shell scripts UPLOADSALES.KSH and SALESPROCESS.KSH load data from the POSU file into the Merchandising Foundation Cloud Service tables.
Sales, returns, and other transaction data are loaded into Sales Audit Cloud Service from a Point-of-Service application, such as Oracle Retail Xstore Point of Service, for in-store transactions and an Order Management System Cloud Service, for ecommerce orders fulfilled from non-store locations. These applications should provide a standard RTLog file. The RTLog data is loaded into Sales Audit Cloud Service either in trickle mode or once a day. If the data is uploaded in trickle mode, then corporate inventory reflects a more accurate intra-day stock position. The data from the RTLog is loaded into Sales Audit Cloud Service using the batch program SAIMPTLOG for end-of-day. If trickle processing is used the final RTLog for the day must include a count of all RTLog files for the store/day.
In the normal course of business, payments are made to vendors at the store level. Payments for merchandise purchases done at store level are booked against a corresponding merchandise invoice. Payments of non-merchandise purchases or miscellaneous services availed at the store are booked against a corresponding non-merchandise invoice. These transactions are passed from the POS/OMS to Sales Audit Cloud Service as specially designated PAID OUT transactions (sub-transaction type of EV - Expense Vendor or MV - Merchandise Vendor). All these invoices are assumed paid. The batch program SAEXPIM transfers the PAID OUT type of transactions to the Invoice Matching Cloud Service staging tables.
The batch program SAEXPIM is also used for escheatment processing. Unclaimed monies of outstanding, non-expiring vouchers are totaled after a defined period of time from the date of issuance of the voucher and posted to the Invoice Matching Cloud Service staging tables as a non-merchandise invoice by SAEXPIM. The unclaimed amount is paid out as income to the issuing Retailer. In some U.S. states, it is paid out to the state (based on configuration). Sales Audit Cloud Service determines who receives this income and accordingly posts a non-merchandise invoice for the partner. These invoices are assumed not paid.
The batch job EDIDLINV is used to extract the invoices from the Oracle Retail Invoice Matching Cloud Service staging tables and load as EDI invoices to Invoice Matching Cloud Service.
The batch program SAEXPGL transfers the sales data from Sales Audit Cloud Service into the financial staging tables in Merchandising Foundation Cloud Service. This batch program executes only if the external financial system is set to O (for other), E-Business Suite, or some other external financial application based on system options configuration.
SAEXPGL directly inserts the data into financial stage tables of Merchandising Foundation Cloud Service.
Sales Audit Cloud Service determines the estimated bank deposit for each store/day. The batch program SAEXPACH posts the store/day deposits into a database table and creates the standard ACH format file. The output file is sent to a Clearing House. The output file conforms to the requirements imposed by the National Automated Clearing House Association (NACHA). The nature of the ACH process is such that as much money as possible must be sent as soon as possible to the consolidating bank. Any adjustments to the amount sent can be made front-end. This batch assumes that there is only one total to be exported for ACH per store/day.
The batch program SAEXPUAR extracts specified TOTALS to a flat file that is interfaced to an account reconciliation application. For each store day, all specified totals are posted to their appropriate output files. All the stores and totals with usage type starting with UAR are exported.
Sales Audit sends audited data to SIM which helps SIM to be synchronized with Merchandising Foundation Cloud Service with respect to inventory levels. The batch program SAEXPSIM extracts information from transactions with changed item quantities, item deletions, item addition, change in item status to VOID, and change in transaction status to PVOID. This information in the form of a file (SIMT) is uploaded and processed by SIM.
