Getting Started

1 Getting Started

System Options

Sales Audit contains a set of system options that are either defaulted at the time of the installation, or are configured manually from the UI by a System Administrator. These system options control the various functionality in Sales Audit, starting from the import of transaction logs, to audit and finally, export to the different systems. They are configured based on the requirements/rules of the business. They tend to remain fixed unless a business practice is changed which necessitates a change.

System Constraints

Below are system constraints used by Sales Audit; most of them are mandatory to be configured, while some are optional. One of the important system option parameters is the balancing level, which impacts the way that the auditing rules are applied to a store day. 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 these system options settings.

System Option	Optional?	Re-configuration Restricted?	Default Value	Description
Balancing Level	No	No	R	Used to determine the level at which balancing of declared totals to system summarized totals is performed. Valid values are Store (S), Register Summary (R), and Cashier Summary (C). Changes to this parameter are permitted but care should be taken to ensure any open store/days are audited and closed out prior to making the parameter update. The updated parameter value will not be used by open store/days unless the Re-total/Re-audit process is manually re-executed.
Cash Management	No	No	Y	Controls whether or not the batch export to ACH will process or not. If set to Yes, then Sales Audit will export to an ACH system. If set to No, then it won't perform any export. Valid values are Yes (Y) or No (N).
Check for Duplicate and Missing Transactions	No	No	Y	Indicates whether the auditing process should check for missing and duplicate transactions as part of the auditing process. Sales Audit can accept duplicate transaction numbers from OMS and POS. See the Customer Ordering section for more details on this functionality. If this field is set as Yes, then Sales Audit filters duplicate transactions when the transaction is originating from the same system. If set to No, then neither duplicates nor missing transactions will be audited for. Valid values are Yes (Y) or No (N).
Execute Automated Audit After Import	No	No	Y	Indicates whether or not to execute the automated totaling and audit processes after each import of data. If this is set to Yes, the automated totaling and audit will occur after each import. If this indicator is set to No, the automated totaling and automated audit processes will not occur until Sales Audit receives a transaction verifying that all data for the store day has been transmitted. Valid values are Yes (Y) or No (N).
Locking Level	No	No	S	This indicator will indicate the level at which locking occurs within Sales Audit. Valid values are Store Day (S) or Transaction (T). Locking at the store day level will not allow more than one user to update the transactions for the store day at the same time. While, locking at the transaction level will allow this to happen.
Post Positive Debits and Credits	No	No	N	This new system option allows the retailer to specify whether the financial postings should always post only positive debits and credits. If checked (Yes), only positive values will be posted to the General Ledger. If not (No), the former behavior of posting negative amounts will continue. This parameter can be edited by the appropriate admin user. If updated, the changes will be reflected in GL posting batch runs subsequent to the change. Valid values are Yes or No.
Transaction Appended with Workstation ID	No	No	N	Identifies if the workstation ID will be appended to the transaction number sent from POS or OMS. It will determine how missing or duplicate transaction processing should audit transactions. If you have multiple tills per workstation, then it is recommended that you set this to Yes and send transaction numbers in the following format: workstation id \|\| transaction no. Valid values are Yes (Y) or No (N).
Transaction Navigation	No	No	R	Determines how users will navigate in the Transaction Maintenance screen when clicking the previous and next buttons. Valid values are Next Transaction Sequence Number (P) or Register Transaction (R).
Unit of Work	No	No	T	Indicates whether your auditors will work at the Transaction level (T) or the Store Day level (S). It determines when Sales Audit will export the data to the external systems. For transaction level, an individual transaction is exported from Sales Audit as soon as it is imported and is free of errors. For store day level, the error free transactions are exported only once the entire store day is processed.
Credit Card - Masking Character	No	Yes	*	Sales audit only accepts masked credit card numbers on transaction data. This system option indicates the character that will be used by your POS or OMS to mask a credit card number.
Determine Comp Store Status By - Date	No	No	R	Comp stores are used to identify those stores which have been newly remodeled, acquired or opened. The comp stores are separated from regular stores to facilitate analysis - when looking at sales figures and trends. This system option setting will be used to determine which data should be used to determine a store's comp status. Valid values are Store Open Date (S), Remodel Date (R), or Acquire Date (A).
Determine Comp Store Status By - Elapsed Days	No	No	999	Indicates the number of days since past the Comp Store Status date defined above that must have elapsed in order for a store to be normalized and be included in sales reports.
Inventory Reservation - For Layaway	No	No	Y	Indicates whether or not inventory should be reserved for layaway transactions. If this is set to Yes, then an update will be sent to Merchandising to reserve the desired inventory when a layaway transaction is initiated, without processing a sale. Valid values are Yes (Y) or No (N).
Inventory Reservation - From SIM	No	No	N	Indicates whether or not inventory should be reserved for an in-store customer order sent from the store inventory system (e.g. SIM or SIOCS). If this is set to Yes, then an update will be sent to Merchandising to reserve the desired inventory when an in-store customer order is initiated, without processing a sale. Note: this is used only for customer orders not going through an Order Management solution. Valid values are Yes (Y) or No (N).
Maximum Number of Days - Post-Dated Transactions Allowed Days	No	No	999	This parameter is used to define the number of days before post-dated sale transactions are allowed in the system to be processed. Note: if the store days are closed, they will need to be reopened to process the backdated transactions.
Maximum Number of Days - Sales Audit Data Stored	No	No	1	Used to determine how many days sales audit data should remain on the database after posting to other systems.
Maximum Number of Days - To Compare Duplicates	Conditional	No	30	Maximum number of previous day's information to use when determining if a transaction is a duplicate. If the Check for Duplicate and Missing Transactions option is Yes, it is mandatory to give it a value. If not, then this field will be disabled.
Maximum Number of Days - Close Month After	Yes	No	0	Used to define the number of days for which the fiscal month would be kept open to accept late or missing postings from the Sales Audit application. If set to a value greater than zero, then that many days will be added to the end of the fiscal period to determine when the month will be closed.
Online Store- Create Store Days – Days Prior	No	No	1	Used to define the number of days prior that store days should be created for online stores by the sastdycr batch

ACH Information

Automated Clearing House (ACH) is a U.S.-based banking network used to electronically transfer funds. You can 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. Sales Audit has several system options used to configure this functionality, if you choose to use it.

System Option	Optional?	Re-configuration Restricted?	Description
Sender ID	Yes	No	Contains the ID used by the originator to identify itself to the Originating Financial Depository Institution (ODFI). Required only if using Sales Audit automated clearing house (ACH) functionality to transfer payment information to a bank.
Company ID	Yes	No	Contains the alphanumeric code to identify the company. The first character may be the ANSI one-digit Identification Code Designators (ICD). For example, 1 IRS Employer ID Number or 9 user-assigned number. Required only if using Sales Audit automated clearing house (ACH) functionality to transfer payment information to a bank.
Name	Yes	No	Contains the name of the Originating Financial Depository Institution (OFDI). Required only if using Sales Audit automated clearing house (ACH) functionality to transfer payment information to a bank.
Routing	Yes	No	Contains the routing number of the consolidating bank. Required only if using Sales Audit automated clearing house (ACH) functionality to transfer payment information to a bank.
Account	Yes	No	Contains the account number of the consolidating bank. Required only if using Sales Audit automated clearing house (ACH) functionality to transfer payment information to a bank.

Escheatment

Escheatment is the process of forwarding monies of outstanding, non-expiring vouchers to the government authorities (state or country) after a defined period of time from the date of issuance, which is required by some government authorities. 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.

Note:

To accommodate escheatment, a new total should be added to Sales Audit to create escheatment totals. Sales Audit automatically totals sales transactions based on calculation definitions set up for the total.

The escheatment functionality in Sales Audit is driven by the hierarchy of store, issuer, recipient, and HQ. When performing escheatment, Sales Audit checks if 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 (see "Escheat Options") in Sales Audit. If the state or country exists on the table it then checks to see if the store indicator for that state or country is set to yes. If so, Sales Audit escheats these monies 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 you claim the voucher as income. This income will be claimed by using a non-merchandise type of invoice.

System Option	Optional?	Re-configuration Restricted?	Description
Escheat to Government Authorities	No	No	This field indicates whether or not the retailer would like to escheat vouchers back to the state after a defined time period. The value set depends on the local or state laws regarding escheating vouchers, and the current business practice followed for dealing with unused vouchers. If this is set to Yes, then an escheatment partner must also be defined.
Partner for Income Adjustments	Conditional	No	The partner type that you have chosen as the escheatment authority. This can be either Escheat-State or Escheat-Country.
Partner for Income Adjustments	Conditional	No	The ID for the state or country escheatment partner that will be used as the escheatment authority.

Vouchers

For each voucher type that is subject to escheatment, configuration must be made to setup the timing for escheating and ultimately removing the voucher from sales audit. This is also done in the system options screen in Sales Audit. One or more vouchers types can be configured as described below.

System Option	Optional?	Re-configuration Restricted?	Description
Escheat Days	Yes	No	Indicates the number of days between issuance of a voucher of this type and its escheatment.
Purge Days	Yes	No	Indicates the number of days between redemption or escheatment of a voucher of this type and its deletion from the database.
Tender Type	Yes	No	Contains the ID for a tender type for which the escheat and purge options are being defined. The valid values are tender types that have been configured in Sales Audit in the Voucher group. Tender types in this group can be viewed or modified by accessing Data Loading > Download from the task list and selecting the template type Finance Administration and the template Tender Types.

Fuel Management

Sales Audit supports the audit of Fuel Merchandise. A single department can be setup in the merchandise hierarchy under which the fuel merchandise will be associated. Sales Audit has the below system options that are needed to be configured for the import and audit of such merchandise.

System Option	Optional?	Re-configuration Restricted?	Default Value	Description
Fuel Merchandise	No	No	No	Indicates whether or not fuel merchandise exists in your business. If so, then set this to Yes and enter a fuel department. If not, then set this to No. Fuel department is required if set to Yes. Note: this option is not in the database, it is just used to control the System Option page behavior.
Fuel Department	Yes	Yes		Contains the department number of the fuel department. This field will only contain a value if you sell fuel. Note: all fuel related items must be in a single department in Merchandising.

Report Options

Sales Audit has three dashboard reports available in the Sales Auditor's dashboard that can be used to help surface key issues that need addressing during the auditing process. These reports are based on the data for the past store days, and Sales Audit provides the option to set the number of days that the user would want to look at. The reports can be viewed for a maximum of 14 days. To provide configuration for these reports, several system parameters can be set, as described below.

For more information on the reports, see the Oracle Retail Sales Audit Reports User Guide.

System Option	Optional?	Re-configuration Restricted?	Default Value	Description
Open Store Days	No	No	7	Allows configuration of the number of days that will be displayed in the Open Store Days report in the Sales Audit dashboard. Valid values are 1-14 days.
Open Transaction Days	No	No	7	Allows configuration of the number of days that will be displayed in the Open Transactions report in the Sales Audit dashboard. Valid values are 1-14 days.
Over/Short Summary Days	No	No	7	Allows configuration of the number of days that will be displayed in the Over/Short Summary report in the Sales Audit dashboard. Valid values are 1-14 days.
Over Threshold	No	No	0	Allows configuration of the threshold for overages shown in the Over/Short Summary report in terms of primary currency. Only overages that exceeds this threshold will be displayed in the report. Positive numeric values are allowed to be specified.
Short Threshold	No	No	0	Allows configuration of the threshold for shortages shown in the Over/Short Summary report in terms of primary currency. Only shortages that exceeds this threshold will be displayed in the report. Positive numeric values are allowed to be specified.

There are also some additional system options that still exist on the table in the database but refer to older functionality that has been removed from the solution and so are no longer used. These include:

AUTO_VALIDATE_TRAN_EMPLOYEE_ID
CLOSE_IN_ORDER
DEFAULT_CHAIN
VIEW_SYS_CALC_TOTAL