| Oracle® Retail Sales Audit (ReSA) User Guide Release 16.0 E78113-02 |
|
 Previous |
 Next |
In retail, the sales audit function describes the process of reviewing the Point-of-Sale (POS) and Order Management System (OMS) transaction data for accuracy. ReSA provides a simplified sales audit process while ensuring the integrity of audited data and smooth integration with other retail applications. The retail sales audit function also allows for balancing out cashiers, cash registers, or an entire store day. This process validates the totals from POS and OMS against the calculated totals of transactions. If these totals are not equal, you can report this variance as an over or short value.
ReSA is a part of the Merchandise Operations Management (MOM) product group, which helps retailers to reduce shrinkage, reduce integration costs, improve internal control, increase productivity, and improve visibility to sales. Using real time inventory information, this system calculates need based on set parameters for any product, store or other category. It also manages foundation data, purchasing and cost, inventory, price, and financial processes.
This chapter contains the following topics:
ReSA accepts POS and OMS data and provides audited data to downstream applications such as, Retail Management System (RMS), Retail Analytics (RA), Retail Store Inventory Management (SIM), and General Ledger applications. It allows a single entry point for sales data from external systems into Oracle Retail applications and other financial systems. It accepts and validates transaction data while detecting and correcting errors according to pre-defined rules which are both system defined and user defined. It allows users to view and audit data at the store/day level or the cashier/register level selected by the user. This process results in correct data that you can export to other applications.
ReSA reduces shrinkage because it provides regular comparisons of inventory levels and sales. It can isolate irregularities at the point of sale. It reduces the cost of integration between sales audit functionality and other applications such as the Oracle Retail Merchandising System (RMS) and Oracle Retail Analytics (ORA). Audited POS and OMS data, exported from ReSA, provides a single version of data across downstream solutions. It can support reporting and analysis to help reduce losses.
The user roles provide a means of grouping privileges together for granting access to a user. The retailer can modify the roles to suit their business needs. The following are the default roles set up in ReSA:
Sales Audit Analyst
A Sales Audit Analyst is responsible for the daily reporting of company sales, auditing, and verifying accuracy of store sales. They are also responsible for coordinating month end closure, ensuring department deadlines are met, assisting with quarterly general ledger reconciliations, and researching unusual transactions.
Sales Audit Manager
A Sales Audit Manager is responsible for a team of Sales Audit Analysts. They serve as the main point of contact and represent finance in meetings that involve POS register issues and sales processing procedures.
Finance Manager
A Finance Manager is responsible for the financial accounting of a region.
Sales Audit System Administrator
A Sales Audit System Administrator is responsible for maintaining the administrative functions of the application. They are also responsible for the sales audit system functioning such as employee maintenance and reference field maintenance.
|
Note: For more information on merchandising security, see the Oracle Retail Merchandising Security Guide. |
ReSA can integrate with the following applications:
Oracle Retail Management System (RMS)
Oracle Retail Invoice Matching (ReIM)
Oracle Retail Analytics
Oracle Retail Store Inventory Management (SIM)
Oracle Retail Point-Of-Service (ORPOS)
You can also set up ReSA to interface with third-party applications including general ledger applications or any financial institutions such as, Account Clearing House (ACH) Order Management System (OMS), and Universal Account Reconciliation System (UAR).
The following is a list of terms used in ReSA:
Store day: A Store Day is the time between opening the cash registers at the start of a business day and closing the registers at the end of the day.
A business day is a calendar day except for the retailers running 24x7 operations. The retailers who operate 24 hours a day and seven days a week may have their Store Day spread to more than one calendar day. ReSA uses the Day Close transactions from the POS application to define the close of business day.
Transaction: A transaction is a record of events at a location, which may include sale, return, and exchange of items. The following is an illustration of the list of attributes that a transaction record may contain:
Date and time of transaction
Salesperson ID
Register number
Cashier
Invoice number
Item details
Item quantity
Item taxes
Discounts
Transactional taxes
Tender details
Customer details
Paid out details
Revision: Revision is an archive of updates made to transactions. Before updating the current data in transaction tables, a snapshot of the data is maintained as revisions to historical data. This process includes the following steps:
Creating a new version of the transaction record.
Keeping the older version of the record unchanged.
Moving the older version of the transaction record to a revision table.
Moving the older version to a separate version history table maintains a complete audit trail and also minimizes the amount of data held in main transaction tables.
Escheatment: Escheatment is the process of forwarding money of outstanding, non-expiring vouchers to the proper governing authorities after a defined period of time from the date of issuance.
The Escheatment functionality in ReSA is driven by the hierarchy of Store, Issuer, Recipient, and HQ. When performing escheatment, ReSA checks to determine whether there is an address for the first level of the hierarchy, the Store. If so, it checks if the state or country is defined in the Escheatment table in ReSA. If the state or country exists on the table, it then checks to determine whether the Store indicator for that state or country is set to yes. If so, ReSA escheats the money to that state or country. If no state or country exists for the store, or one does but does not exist on the Escheatment table, or it does exist on the table but the Store indicator is set to no, then ReSA checks the next level, Issuer, and so on. If no matches are found after ReSA checks all four levels of the hierarchy, then the retailer claims the voucher as income.
Full disclosure: A method of restating data by sending a negation of the entire first statement, then a second complete statement.
Totals: A summation of one or more entities that are captured in the POS or OMS system and imported into ReSA. For example, summation of the quantity of items sold in a store during a particular store day. Totals are used to perform store balancing, perform analysis within the ReSA system to control losses, generate reports, and to export audited data to external systems. Totals can either be defined in ReSA or imported as reported by POS or OMS.
Report data: Allows you to generate reports, such as, the Flash Sales Report and the Flash Totals Report.
ReSA status: ReSA maintains status at three different levels, store status, data status, and audit status. The status associated with Stores level indicates the status of the store, like worksheet, fuel closed and closed. The status associated with Data level indicates the progress of data upload, like ready to load, loading, partially loaded, fully loaded, and purging. The status associated with Audit level indicates whether the sales data is audited, or is in the process of auditing, or if errors were identified at the store or headquarter for correction.
The ReSA process includes the following procedures:
Setting up ReSA – For more information, see Chapter 3, "Setting up ReSA".
Generating totals – For more information, see Chapter 4, "Defining Totals".
Defining audit rules – For more information, see Chapter 6, "Defining Audit Rules".
Importing data – For more information, see the section on Importing Transactional Data in Chapter 5, "Importing Transactional Data".
Auditing transaction data – For more information, see Chapter 7, "Auditing Transactional Data".
Exporting data – For more information, see Chapter 8, "Exporting Data".
