Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
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). |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| Check for Duplicate and Missing Transactions | No | No | Both | Indicates whether Sales Audit 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. Valid values are Both, Only Duplicate, Only Missing, or None. If this option is set to Both, then Sales Audit will audit for both duplicate transactions as well as missing transactions. The Duplicate check or the Missing transaction check can be individually opted for by setting the option to ‘Only Duplicate’ or ‘Only Missing’ respectively. If set to None, then neither duplicate nor missing transactions checks will be carried out. |
| 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. |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| 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 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. |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| 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 Store Inventory | 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 | Condition al | 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 |
| Documentation Summarization | No | No | Unchecked | Used to control whether Oracle Digital Assistant (ODA) access should be made available within the Sales Audit application. When set, ODA will be enabled for use within Sales Audit. |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| Consignment Sales Review Days | No | No | 0 | Used to define the review window in hours/days from the point of upload of consignment sales within which an external system can review and update the consignment rate (or cost) for the items to be reviewed. These items will not be exported to Merchandising till the transaction has been reviewed or the review window has elapsed. Rate review functionality will be deemed enabled if the Review Days is set to a non-zero value. |
| Merchandising Sales Export Integration | No | No | File Based | Used to define whether the mode of Sales integration from Sales Audit to Merchandising should be File based or Table based. |
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? | Default Value | 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. |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| 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? | Default Value | 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 | Condition al | 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 | Condition al | 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? | Default Value | 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. |
| System Option | Optional ? | Re- configuration Restricted? | Default Value | Description |
|---|---|---|---|---|
| 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