| Oracle® Retail Merchandising Implementation Guide Release 16.0 E80776-04 |
|
 Previous |
 Next |
This chapter is an overview of Oracle Retail Sales Audit (ReSA).
The following information is maintained in the ReSA application.
Oracle Retail Sales Audit (ReSA) contains a set of system options that is different from the RMS system options set. These system options control functionality in ReSA. 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.
ReSA requires a certain amount of foundation data to start working. ReSA shares some of its foundation data with RMS, while the rest of the foundation data needs to be maintained in ReSA.
Foundation data in ReSA includes company/location close dates, location traits, bank setup, tender types, reference maintenance, error codes and store-specific foundation data.
ReSA allows the retailer to define the Totals needed for their business. Totals in ReSA can be a ReSA-calculated value from raw transaction data or a total that comes from the POS/OMS through the RTLog. ReSA calculates a total based on raw transaction data or on existing totals. Totals are used for performing store balancing over/short analysis within ReSA. 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 ReSA. For example, the retailer defines a ReSA-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 ReSA 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. ReSA 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 ReSA 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. ReSA 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 ReSA database.
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 ReSA 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.
ReSA 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.
ReSA 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 to create escheatment totals. ReSA automatically totals sales transactions based on calculation definitions set up for the total.
The audit trail functionality provides the store and headquarters employees with the capability of tracking all changes to transactions and totals. ReSA 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.
Oracle Retail Sales Audit interfaces with the following Oracle products:
Oracle Retail Merchandise System
Store Inventory Management
Oracle Retail Invoice Matching System
Retail Analytics
This figure displays the ReSA interfacing products:
Oracle Retail Sales Audit also interfaces with the following third-party applications:
Automated Clearing House.
Universal Account Reconciliation System.
ReSA and RMS share the same database. ReSA shares some of its master data with RMS. Foundation data such as items, stores, company/location close dates, location traits, bank setup, and tender types are maintained in RMS and used in ReSA.
Current reference data is retrieved from RMS into ReSA 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 ReSA. 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 ReSA into a POSU file by the batch program SAEXPRMS. All corrected sale and return transactions that do not have RMS 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 RMS errors in the POS/OMS transaction data. The shell scripts UPLOADSALES.KSH and SALESPROCESS.KSH load data from the POSU file into the RMS tables.
Sales, returns, and other transaction data are loaded into ReSA from a Point-of-Service application, such as Oracle Retail Xstore, for in-store transactions and an Order Management System, for ecommerce orders fulfilled from non-store locations. These applications should provide a standard RTLog file. The RTLog data is loaded into ReSA 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 ReSA 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 ReSA 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 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 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). ReSA 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 (ReIM) staging tables and load as EDI invoices to ReIM.
The batch program SAEXPGL transfers the sales data from ReSA into the financial staging tables in RMS. 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 RMS.
ReSA 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.
ReSA sends audited data to SIM which helps SIM to be synchronized with RMS 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.
Access to ReSA and access to stores an auditor can take action against, is controlled by privileges available to the user's application role and RMS data level security.
To access ReSA, the user must be mapped to one of the available ReSA roles. There are four default application roles:
Sales Auditor
Sales Auditor Manager
Finance Manager
Administrator
Each of these roles have multiple privileges attached to them. The privileges are defined at granular level and restrict access to a particular screen, or access to take specific audit action, or access to view specific fields. The privileges get directly assigned to the user once a user is mapped to the ReSA roles. A user can be assigned multiple roles.
ReSA shares the database instance with RMS. RMS location level data security is also applied to ReSA users. The location level security is assigned to every ReSA user. This controls the Organization Hierarchy locations the user has access to.
|
Note: RMS also supports Item and Merchandise Hierarchy level data security to restrict user access to specific products. Item level security is not applicable for ReSA. |
