Oracle® Retail Sales Audit Oracle® Retail Sales Audit Implementation Guide Release 22.1.401.0 F72953-01 |
|
![]() Previous |
![]() Next |
Sales Audit requires a certain amount of foundation data in order to configure totals, rules, and to start auditing transactions. This includes data that it uses from Merchandising and Pricing, as well as foundation data that needs to be configured and maintained in Sales Audit.
Sales Audit relies on Merchandising for the following data elements:
Organizational Hierarchy, including stores and warehouses
Location Traits
Banners and Channels
Suppliers - for the Paid Out - Merchandise Vendor Payment transaction type
Partners - for expense vendors and banks
Items - sellable, approved transaction level and reference items
VAT Codes
Non-Merchandise Codes - used for Paid Out transactions for merchandise or expense vendors
Currency Codes
See the "Configure Stores in Merchandising" section for more on configuring stores to use Sales Audit.
Sales Audit also has a dependency on the Oracle Retail Pricing in order to audit promotions that are included on sales and returns transactions. Only those promotions that are flagged with a discount type of 9999 will be audited against the Pricing data. If you are not using the Pricing or choose to not have Sales Audit validate promotions you can use the discount type 2000 instead of 9999.
Constants are values that can be used as part of the rules and totals definitions. These optional attributes can be added, updated or deleted as needed through spreadsheet download and upload processes. These processes are accessed through the main Sales Audit task list under Foundation Data > Data Loading. To download the sheet, click on Download and select Administration in the Template Type, and Constants in the Template option, then click the Download button and when prompted, choose to either open the .ods file that is generated or save the file and open it separately in the spreadsheet application of your choice.
Once opened, there will be two sheets that can be modified - Constants and Constant Translations. The Constants tab will show all the existing constants in the system currently. The Constant Translations tab will show existing constants with their translations in other languages, as applicable for your implementation. Both the tabs allow for the addition, deletion and update to existing records.
Create a Constant
To create a new constant, select Create as the action, and then enter a Constant ID of up to 30 characters and a Constant Name of up to 250 characters entered in the primary language. You must also specify the Constant Value and Value Data Type for the constant you defined and whether or not it can be deleted. Select Yes if the constant can be deleted in the future, otherwise select No.
Adding translations for your constant can be done in a similar manner from the Constant Translations tab. This facilitates the ability to translate the constant description in multiple languages. Add one row for each language where a translation is required, using the Constant ID added in the Constants tab.
Update a Constant
If you would like to update any details for a previously defined constant, a similar process will be followed as that described above for creating new constant. First, download the Constants spreadsheet, and then navigate to the record where you would like to make your updates.
The following columns can be updated in each tab:
Constants - Constant Name, Constant Value, Value Data Type, and Delete
Constant Translations - Constant Name
In the row where you are going to make your updates, select the action type of Update, and then correct the value in the spreadsheet.
Delete a Constant
If you wish to remove a constant, select the Delete action on the row of the constant you which to delete on the Constants tab. Removing a constant translation can be done in a similar manner on the Constant Translations tab. Note that removing a constant is not allowed if it is in use or if the Delete flag is Yes.
Uploading the Changes
For all actions defined above, once all the updates have been made to the data in the spreadsheet, save the file and close it. Then, return to the Sales Audit screens and select Foundation Data > Data Loading > Upload from the main task list. In this screen, select the template type as Administration and the template as Constants. This will generate a process description automatically, but this can be updated if desired. Lastly, select the Browse button and navigate to the directory where you saved the updated spreadsheet.
The status of the changes made can be reviewed under Data Loading > Review Status, with the Process Name provided during the upload process.
Error codes provide information to the auditor about the type of error and the remedial action needed to solve the error, thus increasing the effectiveness of the audit process. When setting up audit rules for automated audit process, an error code is associated to the rule. The error code contains an explanation of why the rule failed, as well as a recommended solution. The error code also contains security settings to determine if the error can be overridden.
There are a large number of pre-defined error codes that are automatically created during system set-up. Further retailer-specific error codes can also be defined during implementation if extra codes are required, such as for custom rules. These updates can be made through spreadsheet download and upload processes. This functionality is accessed through the main Sales Audit task list under Foundation Data > Data Loading.
To download the sheet, click on Download and select Administration in the Template Type, and Error Messages in the Template option, then click the Download button and when prompted, choose to either open the .ods file that is generated or save the file and open it separately in the spreadsheet application of your choice. Once opened, there will be three sheets that can be modified - Error Codes, Error Codes TL, and Error Impact. The Error Codes tab will show all the existing error codes in the system currently. The Error Translations tab will show existing error codes with their translations in other languages, as applicable for your implementation. The Error Impact sheet will show the impact of the errors on the systems to which Sales Audit exports data to. All the tabs allow for the addition and update to existing records. Deletion of an Error code is not allowed. The 'Used' field can be modified as per the requirement to stop the usage of an error message.
Create an Error Code
To create a new error code, navigate to a blank row in the spreadsheet and select Create as the Action. Then, enter a code in the Error column of up to 25 characters, a Description for the error of up to 255 characters and a Short Description of up to 40 characters, both in your primary language. Indicate the area the error is related to in the Form column and, if you've chosen Transaction Detail as the Form, you can also specify the Tab, which will determine which section of the transaction detail the error will be used. Next, enter the Recommended Solution that should be performed in order to resolve the error. This should also be entered in the primary language and can be up to 255 characters. All custom added error codes should be added as System Required No, but you can choose whether or not they can be overridden in the HQ Override column. Select the Used as Yes to indicate that the error code is valid for your implementation (selecting No will hide the error).
If you wish to add translations for the error code in languages other than the primary language, this can be done in the Error Codes TL tab. Navigate to a blank row and select the action type of Create and the language in which the translated description will be entered. Then, enter the error code for which the translation applies. Finally, enter the translated description, short description, and recommended solution. The translated description can also be up to 255 characters long for the description and recommended solution, and up to 40 characters for the short description. This is an optional step.
Lastly, in the Error Impact tab, navigate to a blank row, and then select Create as the Action and enter the Error code you created. Next, select the System where data will be exported from the list of suggested values and System Required as Yes or No depending on whether the presence of the error would restrict the export of the data to the corresponding system. Select the Used as Yes to indicate that the error code is valid for your implementation.
Update an Error Code
If you would like to update any details for existing error codes, a similar process will be followed as that described above for creating new error codes. First, download the spreadsheet, and then navigate to the record where you would like to make your updates. To update/modify an existing record, the corresponding record needs to be updated with the required change.
The following columns can be updated in each tab:
Error Codes - Description, Short Description, Form, Tab, Recommended Solution, System Required, HQ Override, and Used
Error Codes TL - Description, Recommended Description, Short Description
Error Impact - System Required, Used
In the tab where you are going to make your updates, select the action type of Update, and then correct the value in the spreadsheet.
Uploading the Changes
For all actions defined above, once all the updates have been made to the data in the spreadsheet, save the file and close it. Then, return to the Sales Audit screens and select Foundation Data > Data Loading > Upload from the main task list. In this screen, select the template type as Administration and the template as Error Messages. This will generate a process description automatically, but this can be updated if desired. Lastly, select the Browse button and navigate to the directory where you saved the updated spreadsheet.
The status of the changes made can be reviewed under Data Loading > Review Status, with the Process Name provided during the upload process.
Transactions in Sales Audit include a number of specific attributes of a transaction at the header and detail levels. In addition to these, there are a number of reference fields that can be used, where additional details can be captured for the transactions, as required for your business. Reference fields are available for the header, item, discount, item tax, transaction tax, and tender levels.
Table 3-1
Transaction Level | Reference Numbers |
---|---|
Header |
1-4, 25-31 |
Item |
5-8 |
Tender |
9-12 |
Discount |
13-16 |
Transaction Tax |
17-20 |
Item Tax |
21-24 |
They can be configured by transaction, transaction/sub-transaction, or transaction/sub-transaction/reason code. Configuration of reference fields is done through a spreadsheet download and upload processes, which is accessed through the main Sales Audit task list under Foundation Data > Data Loading > Download and Foundation Data > Data Loading > Upload.
To modify reference field configurations, select the template type of Administration from the Download Data screen and then the template Reference Fields. Click the Download button and when prompted, choose to either open the .ods file that is generated or save the file and open it separately in the spreadsheet application of your choice.
Once opened, there will be one sheet that can be modified - Reference Field. This will show all the existing references number configurations by transaction type and sub-transaction type. This tab allows for the deletion of existing reference configurations or the addition of new configurations.
Create a Reference Field
To add a new reference configuration, start in a blank line in the template and select an action of Create. Then, select or enter the transaction type, sub-transaction type and reason code that you wish to configure, as appropriate. Then, select which reference number you want to configure and the label for the reference. The valid label descriptions are found in code type REFL. See "Sales Audit Codes and Descriptions" for more details on configuring the label descriptions. Once all new reference configurations have been defined, save and close the spreadsheet.
Update a Reference Field
If you would like to update an existing reference configuration, a similar process will be followed as that described above for creating new configurations. The following columns can be updated:
Reference Number
Reference Label
Select the action type of Update, and then correct the value in the spreadsheet. Once your updates are complete, save and close the spreadsheet.
Delete a Reference Field
If you wish to delete a reference configuration because it is not used by your business, select Delete as the action, and leave the other fields unchanged. Save and close the sheet.
Uploading the Changes
For all actions defined above, once all the updates have been made to the data in the spreadsheet, save the file and close it. Then, return to the Sales Audit screens and select Foundation Data > Data Loading > Upload from the main task list. In this screen, select the template type as Administration and the template as Reference Fields. This will generate a process description automatically, but this can be updated if desired. Lastly, select the Browse button and navigate to the directory where you saved the updated spreadsheet.
The status of the changes made can be reviewed under Data Loading > Review Status, with the Process Name provided during the upload process.
An important function of Sales Audit is the integration of totals to the General Ledger. To support this function, a mapping must be done in order to configure which accounts the totals should be mapped to in the General Ledger. From a Sales Audit perspective, the source data has the following data elements that identify what the information is from a retail perspective: store, total ID, set of books, and roll-up levels. Each combination of those data elements will need to be mapped to a set of GL accounts segments for both a debit and a credit. How many segments need values and what those values are will depend on how the GL has been setup.
While a record should exist for every combination of retail data elements where you expect transactions to exist, the mapping can be done at a higher level. If for example, all stores for a total will have the same mappings, then rather than set up a record for each store, a single record for the total can be entered with "-1" for the store. Using -1 can be done for store, total, and each of the three rollup levels.
This mapping is done through a spreadsheet download and upload processes, which is accessed through the main Sales Audit task list under Foundation Data > Data Loading. To download the sheet, click on the Download option and then select Finance Administration as the Template Type and GL Cross Reference as the Template. Optionally you can choose to filter your results based on store or total. Then, click the Download button and, when prompted, choose to either open the .ods file that is generated or save the file and open it separately in the spreadsheet application of your choice. Once opened, there will be one sheet in the document. The SA GL Cross Reference tab will show all the existing mappings.
Create a GL Cross Reference
To add a new GL cross reference record, navigate to a blank row in the worksheet and select the action type of Create. Next, enter the Store, Total ID, Roll-up Level 1-3, and Set of Books for the mapping. Values will also need to be added in the Debit Account and Credit Account fields, and depending on the number of GL segments being used, values will also need to be entered into the Debit Segment and Credit Segment fields.
Update a GL Cross Reference
If you would like to update an existing reference configuration, a similar process will be followed as that described above for creating new configurations. The following columns can be updated:
Debit and credit accounts
Debit and credit sequences
Select the action type of Update, and then correct the value in the spreadsheet. Once your updates are complete, save and close the spreadsheet.
Delete a GL Cross Reference
If you wish to delete a mapping because it is not used by your business, select Delete as the action, and leave the other fields unchanged. Save and close the sheet.
Uploading Changes
For all actions defined above, once all the updates have been made to the data in the spreadsheet, save the file and close it. Then, return to the Sales Audit screens and select Foundation Data > Data Loading > Upload from the main task list. In this screen, select the template type as Finance Administration and the template as GL Cross Reference. This will generate a process description automatically, but this can be updated if desired. Lastly, select the Browse button and navigate to the directory where you saved the updated spreadsheet.
The status of the changes made can be reviewed under Data Loading > Review Status, with the Process Name provided during the upload process.
Sales Audit provides a set of tender types as part of the initial installation, but it is expected that you will configure them as appropriate for your business. Tenders are used for validation during the import process, and also during the manual creation/update of transactions from the UI. It is important to coordinate the tenders configured in Sales Audit with those used in your selling solutions, such as POS and OMS.
Sales Audit allows new tender types to be created, and existing records to be updated through spreadsheet download and upload processes accessed through the main Sales Audit task list under Foundation Data > Data Loading. To download the sheet, click on Download and select Finance Administration in the Template Type, and Tender Types in the Template option. Then, click the Download button and when prompted, choose to either open the .ods file that is generated or save the file and open it separately in the spreadsheet application of your choice. Once opened, there will be two sheets that can be modified - Tender Type and Tender Type Translations. The Tender Type will show all the existing tenders in the system currently. This tab does not allow for the deletion of existing tender types. The Tender Type Translations tab will show existing tenders with their translations in other languages, as applicable for your implementation.
Create a Tender Type
To add a new tender type, navigate to a blank row in the Tender Type tab and select the action type of Create. Next, enter an ID for your tender type of up to 6 characters and a description in the primary language of up to 120 characters. Then, select which tender group the new tender belongs to. Tender groups are managed on the Merchandising codes table under code type TENT, and adding new tender groups is not supported, but the valid groups can be configured to display only those appropriate for your business. See the "Sales Audit Codes and Descriptions" chapter for information on configuring this list. Next enter an effective date in the DD-MON-YYYY format for the tender type and indicate whether or not you want it to be used. The effective date must be today or later. For a new tender type the Used column will usually be Y, otherwise set to N.
If you wish to add translations in a language other than the primary language for this tender type, then in the Tender Type Translations tab, navigate to a blank row and select the action type of Create. Next, select the language for the translation, enter the ID for your tender type, and then the translated description.
Update a Tender Type
If you would like to update a tender type, a similar process will be followed as that described above for creating new tender types. The following columns can be updated in each tab:
Tender Type - Tender Type Description, Tender Type Group, Effective Date, Used
Tender Type Translations - Tender Type Description
Select the action type of Update, and then correct the value in the spreadsheet. Once your updates are complete, save and close the spreadsheet.
Note: The tender types cannot be deleted through this process. The Effective Date or Used flag can be modified to stop the usage of a tender type. |
Uploading the Changes
For all actions defined above, once all the updates have been made to the data in the spreadsheet, save the file and close it. Then, return to the Sales Audit screens and select Foundation Data > Data Loading > Upload from the main task list. In this screen, select the template type as Finance Administration and the template as Tender Types. This will generate a process description automatically, but this can be updated if desired. Lastly, select the Browse button and navigate to the directory where you saved the updated spreadsheet.
The status of the changes made can be reviewed under Data Loading > Review Status, with the Process Name provided during the upload process.
Auditors in Sales Audit need to be associated to locations based on location traits defined in Merchandising. This association drives the accessibility of the auditors to the locations while managing the audit process on the different screens of the application. Sales Audit provides a screen to perform this setup which can be navigated under Foundation Data > Application Administration > Employees. Through this screen an administrator can add/modify the association of employees to locations. For more information on configuring employees, see Manage Employees in the Oracle Retail Sales Audit Foundation Data User Guide.
Escheatment is the optional process of forwarding monies of outstanding, non-expiring vouchers to the proper government authorities (state or country) after a defined period of time from the date of issuance. Some government authorities require that unredeemed vouchers be escheated after a specific period of time has passed. 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. 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.
Sales Audit provides a table to define the individual state or country's escheat rules. For every country or state the funds escheat to, associated partners can be setup with the below indicators:
Store: Indicates whether or not the partner escheats monies to the state for the store where the voucher was issued during escheatment. Valid values are Y or N.
Customer: Indicates whether or not the partner escheats monies to the state for the customer the document was issued to during escheatment. Valid values are Y or N.
Recipient: Indicates whether or not the partner escheats monies to the state for the recipient of the voucher during escheatment. Valid values are Y or N.
Headquarters: Indicates whether or not the partner escheats monies to the state for your headquarters where the voucher was issued during escheatment. Valid values are Y or N.
Note: There is not currently a screen for managing this information in Sales Audit. If you wish to utilize this functionality, an SR will need to be logged to load or modify the data. |