| Oracle® Retail Sales Audit Cloud Service User Guide Release 19.3.000 F83171-01 |
|
 Previous |
 Next |
| Oracle® Retail Sales Audit Cloud Service User Guide Release 19.3.000 F83171-01 |
|
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. Sales Audit 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.
Sales Audit 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:
Sales Audit accepts POS and OMS data and provides audited data to downstream applications such as, Merchandising System, Retail Insights, 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.
Sales Audit 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. Audited POS and OMS data, exported from Sales Audit, provides a single version of data across downstream solutions. It can support reporting and analysis to help reduce losses.
Automatic auditing is done in Sales Audit 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 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.
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 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, override or revalidate 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.
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 Sales Audit:
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. |
Sales Audit 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 Xstore Point Of Service
You can also set up Sales Audit 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 Sales Audit:
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. Sales Audit 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 Sales Audit is driven by the hierarchy of Store, Issuer, Recipient, and HQ. When performing escheatment, Sales Audit 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 Sales Audit. 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, Sales Audit 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 Sales Audit checks the next level, Issuer, and so on. If no matches are found after Sales Audit 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 Sales Audit. 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 Sales Audit system to control losses, generate reports, and to export audited data to external systems. Totals can either be defined in Sales Audit 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.
Sales Audit status: Sales Audit 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 Sales Audit process includes the following procedures:
Setting up Sales Audit – For more information, see Chapter 3, "Setting up Sales Audit".
Generating totals – For more information, see Chapter 4, "Define Totals".
Defining audit rules – For more information, see Chapter 6, "Define 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".
The audit process performs the following steps:
At the end of the day or by trickle-poll method, transactions are transmitted from the store to the head office. This data includes order initiation, order complete, and order return transactions from both OMS and POS.
The duplicate records received from OMS and POS are filtered within Sales Audit.
The transmitted transactions are loaded to the database, totaled, audited, and reviewed.
Any errors that are generated as part of the validation process must be corrected or overridden.
Once the audit is complete, the data is exported.
As a Sales Audit auditor, your responsibility is to review all exception errors related to your stores and either correct or override these errors.
The following is a standard auditing workflow for an auditor within Sales Audit:
Find and select the store/day containing and navigate to either Balancing Level Summary or Store Day Summary.
Use the Store Day Summary to review and audit the following:
Error List
Miscellaneous totals
Over short totals
Missing transactions
Import and export log
Use the Cashier/Register Level Summary to review and audit the following:
Error List
Miscellaneous total
Over short total
You can also perform data analysis such as, reviewing the audit trails. You can use the following screens for the analysis:
Transaction Search
Item Summary
Tender Summary
Transaction Audit Trail
Total Audit Trail
General Ledger Transactions
Import/Export Log
Bank ACH Maintenance
Store ACH Maintenance
|
Note: Once all errors are corrected or overridden, sales audit sets the store/day audit status to Audited. The store/day audit is then available for export to an external application. |
