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.
Errors arise when the conditions of a rule definition are not met. You can either correct these errors or you can override them.
Errors arising out of the transaction data validation performed by Sales Audit may have impact on the export of data to the external systems. At times, the data should not be exported to the external systems until the error is corrected. At other times, the impact of the error may be very negligible and limited only to the internal Sales Audit application. In such situations, the data can be exported to external systems.
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.
A method of restating data by sending a negation of the entire first statement, then a second complete statement.
There are some errors that cannot be corrected. For such errors, you need to acknowledge the error and then override these errors.
Allows you to generate reports, such as, the Flash Sales Report and the Flash Totals Report.
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.
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.
By providing a Rule Definition in the Sales Audit system, you are actually defining the conditions that the Sales Audit system should meet to perform an additional level of transaction data validation.
Sales audit is essentially the process of reviewing the point-of-sale transaction data for accuracy.
A store day is the time spent between opening cash registers at the start of a calendar day and closing the registers at the end of the day. For some retailers, a store day spans over more than one calendar day.
A total is a summation or count of two or more entities. For example, a total can be a summation of the quantity of items sold in the store on a particular store day.
Totals 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.
By providing a Total Definition in the Sales Audit system, you are actually defining from where the total values will come into the Sales Audit system.
Total level indicates the level at which the totals are calculated. The total level relates to the balancing level that is chosen for the system.
This refers to the actual numeric value produced when the Total Definition is run against the transaction data.
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