5 Configuring Totals and Audit Rules

Totals and audit rules are two functions in Sales Audit that allow you to configure the auditing process specifically for your business. Totals are the summation or count of two or more entities based on activities that occur in your selling solutions, whereas rules can be based on totals or raw data and provide a way for you to add additional validations to be used when auditing transactions or a store day over and above what is part of the base Sales Audit processes.

Totals

Totals can come from the selling solutions themselves, under the transaction type POS declared totals, or can be based on Sales Audit data. Within Sales Audit, totals are used for evaluating and consolidating data, performing store balancing, over/short analysis, and can be used as part of audit rule definitions. Totals are also used to create data for external systems, such as the General Ledger. The systems that a total is exported to is configured as part of the total definition, where appropriate.

Totals can be calculated based on raw transaction data or can be based on another total. For example, you may have totals for each tender type in the tender group Credit Card and then another total that combines each of those totals for total credit card transactions in a store day.

Totals are grouped into categories that determine the details that can be included in the calculation and how it is displayed for a store day in Sales Audit. Below are the different categories for totals and a common example for each type.

Sales

Generally, totals in this category are used to total sales by register or cashier to be used in either reporting or an audit rule's definition. Sales totals are not typically interfaced to external systems, like the General Ledger, from Sales Audit, as Merchandising is responsible for that communication in order to incorporate cost of sales, along with the retail value.

Tax

Tax category totals are used to summarize the item or transaction level tax information for a store day to be used in communicating to the General Ledger or to a government reporting agency.

Transaction Type

This type of total is usually created for use in audit rules. An example of a total for this category might be a count of No Sale transactions for a store day. Then the audit rule could look for cases where the count of No Sale transactions for a store day exceeded a certain threshold and raise an error, if that situation is found.

Tender Type

Tender type category totals are generally used to create the components used in an the Over/Short type totals. For example, it could be used to create a total for a specific tender type (Personal Check) that is either sourced from the selling solution or Sales Audit. These totals are also commonly used to integrate the tender information to the General Ledger.

Payment Total

This type of total is generally related to payment for customer orders where a liability is incurred due to taking money from the customer prior to shipping their order. An example would be totaling payment for transactions with an item status of Order Initiate (ORI) in order to map that liability to the General Ledger.

Over/Short

This type of total is usually used for summarizing tender type totals across tender types so that they can be compared to declared totals from the store. Totals in this category are not typically integrated to the General Ledger, but are used for store day processing in Sales Audit.

Although no totals are initially loaded into Sales Audit, there are two totals that are expected to be created in this category - Store-level Over/Short (OVRSHT_S) and Balance-level Over/Short (OVRSHT_B). The latter should be based on either register or cashier level - depending on how you have the Balancing Level system option set. Although the description for the total can be anything, the total ID needs to be the two noted above. These totals are used in two ways - in the Over/Short Summary dashboard report, as well as to display the Register (Cashier) Over/Short amount on the Register (Cashier) Summary page and the store level over/short total on the Store Day Summary page.

These two mandatory totals are generally created based on other totals. For example, for the Over/Short Store total, you could start by creating two store-level totals for each tender type - one for the store declared totals of that tender type and one for the Sales Audit calculated total for the tender type. Then, use each of those individual totals to create the over/short total for the store by adding all the store declared values and subtracting the Sales Audit calculated values.

Frequently Asked Questions

What is the difference between a Total and an Audit Rule?

Totals can either come from the POS or other external systems through the RTLOG. Sales Audit can also calculate the total itself based on raw transaction data or existing totals. Totals are used in performing store balancing (over/short), analysis within Sales Audit, and exporting.

Audit Rules are a set of rules defined to detect any error or exception in the data imported from external systems. Based on the given conditions if a rule fails, Sales Audit generates an exception. As part of the audit rule definition, you will define if the error can be overridden, as well as what systems the error impacts. This system impact prevents a bottleneck in the export process by only prohibiting the export of transactions and totals to the systems defined in the system impact. Even if the transaction or total is in error, Sales Audit still exports the data to systems not defined in the system impact for the given error.

When defining a total, how is the answer to the "Is this total a component of the Over/Short or Miscellaneous total?" question used?

This is only used to define the tab that displays the total for a store day, Over/Short or Miscellaneous Totals. Usually those defined as Over/Short Totals are used to perform tender balancing for stores.

When defining a total how is the answer to the "Does this total correspond to a value in RTLOG?" question used?

If this is set to Yes, it indicates the total is expected from your selling solutions, such as a declared tender total. These totals will appear in the RTLOG Reported column in the Accountable For or Accounted for tables for a store day. If this is set to No, it indicates that it is a Sales Audit calculated value based on either raw data or existing totals. These will be displayed in the System Reported column.

How is the Display Group used as part of the total definition?

The Display Group defines in what order the total is displayed within the selected Total Category. Clicking on the Details button displays all other totals that are defined for the total category along with their selected display order. This will provide visibility to where the new total you are defining will be shown amongst previously defined totals for the same category. All totals are displayed in the Store Day Summary screen on either the Over/Short tab or the Miscellaneous Totals tab, based on the total definitions.

What is the difference between Accounted For and Accountable For?

Accounted For totals represent what is physically counted in the till, for example total cash on hand, total checks, and so on. Accountable For totals represent what should be in the till based on the day's activity. These totals can either come from the RTLOG or Sales Audit calculations. This is applicable only for Over/Short type totals. The difference between the summed Accounted For and the summed Accountable For totals represent the trial over/short value for a store/day.

What is the impact on store days when a total is edited?

If you make any changes and re-approve the total, then all the store days that fall in the total date range will get re-audited. Only totals in Approved status are used during the store day audit process.

Audit Rules

Audit rules are a way for you to configure additional validation by store day or at any level of the transaction that is specific for your business. For example, you could create a rule that flags an excessive number of return transactions for a particular cashier by store day - with the number that is considered excessive specific for your business or a subset of your stores.

Audit rules run on transaction data and totals during the automated and interactive audit processes. When a rule is broken, an exception error is thrown that must be corrected or overwritten by the auditor. Only after resolving the errors, can the store day be audited, which can be a prerequisite for the transactional data to be exported to dependent systems like Merchandising or the General Ledger.

Creating your own audit rules is an optional step and should be added only where needed for your business requirements. They can be defined to be evaluated at the store or register/cashier level (depending on the Balancing Level defined in system options), and can be applied to any level of the transaction or at the store day level. As part of the audit rule definition process, you are essentially building a query to do the validation. This query can look at the key Sales Audit tables and views, as well as some tables in Merchandising. As previously mentioned, it can also be based on a total. A rule can be applied to all stores or a subset through the use of location traits.

Each rule can be assigned one or more error codes to help guide the auditor through the resolution process when the error occurs. If you want to define your own error codes to use for a rule, you would do this using the spreadsheet upload process described in the Error Codes section.

For more information on creating totals and audit rules, see the Oracle Retail Sales Audit Foundation Data User Guide.