Powered by Blogger.

Saturday, January 17, 2015

Tag: , , , , , , , , , ,

Oracle Retail Sales Audit (ReSA) – Quick Reference Guide Series – 2



Here is the second installment of Oracle Retail Sales Audit Quick Reference Guide. With this and previous post, once should get the quick  and high level overview of complete Oracle Retail Sales Audit (ReSA) Business Offerings and it's key functions: (Do share your feedback or if you have any question on below. Watch out this blog further for complete sets of FAQ's on ReSA which you would never want to miss)

1.     Key Sales Audit (ReSA) Transaction Validations

ReSA Uploads the fine details of every transaction (items, discounts, tenders, taxes, etc) at every location and uses two types of validation which are built into the batch processes and GUI
  a.     System required validation:          
        Checks validation against Foundation Data  e.g. Item, Location during the import of the RTLOG

  b.     User defined validation:
        Implements Business rules e.g. Value of Credit Card based transaction should be more than $5.

2.     Understanding ReSA Store Day Concept

ReSA uses the concept of a Business Day in defining a store/day. ReSA captures the following data for each transaction:  store number, transaction date/time, business date.

When loading POS transaction into ReSA, all transactions will be associated with the given business date until the day close record is received. Once the day close record is received, the following transaction will be associated with the next business date

Transaction Type                 Transaction Date/Time     Business Date

Sale                                          10-JUL-2001 11:45:03       10-JUL-2001
Sale                                          10-JUL-2001 11:48:42       10-JUL-2001
Sale                                          11-JUL-2001 01:24:56       10-JUL-2001
Day Close                               11-JUL-2001 02:30:45       10-JUL-2001
Sale                                          11-JUL-2001 02:45:56       11-JUL-2001       

Important Transactions: SALE, DCLOSE , OPEN , NOSALE , RETURN,EEXCH

3.     Full Disclosure in ReSA

Full disclosure is the process of restating data that was initially fed incorrectly into the receiving applications. It is ideally used when the Store Day is closed and then you realize the need for editing the data in ReSA and updating it in the receiving applications.

Full disclosure means that previously exported values, such as quantity, price, Totals, and so on are fully backed out before the new value is sent. Data is restated by sending a negation of the entire first statement, then a second complete statement.

The ReSA batches that use full disclosure are:
          SAEXPRMS               
          SAEXPRDW


4.     Audit Trail in ReSA

The Audit Trail functionality provides the store employees and the HQ auditors with the capability of tracking all changes to transactions and Totals. If modifications are made to a transaction or Total, upon saving these changes, the original version is moved to revision tables and the modified transaction or Total tables are updated with the modified record.

ReSA maintains versions of all modified transactions thus enabling easy tracking of changes. An audit trail is central to any auditing system.

If you modify the transactions during the interactive audit process, you should run the auditing processes run again to recalculate Store Day Totals. After you have run the audit processes again, you should run the SAPREEXP.PC batch file to export the fresh data to the exporting systems. This batch file tracks all changed Totals for the Store Day since the last export. The module writes the changes to revision tables.

How does the SAPREEXP.PC batch file works?
The batch file works in such a way that it does not actually update the existing record in the ReSA system. Instead, it creates a new version of the record and moves the old record to the revision history table within ReSA.

  •  When you update a transaction detail, your ID is inserted into the transaction table. All versions of a transaction or Total are stored on these revision tables until the data meets the purge criteria and is removed.
  • After modifying the information for a Store Day, you may view the information through audit trails or summaries. After you view the summaries, you may return to the Transaction Maintenance option on the RMS Start Menu window to update any outstanding issues that you may have found while reviewing the Store Day.
  • Totals for GL system that are impacted by a revised transaction are reversed and both the reversal and the new Total are extracted for the GL.
  • There are no reports directly associated with transaction audit trail or sales audit Totals functionality in ReSA.
  • There are no system administrative functions directly relating to transaction audit trail or sales audit Totals functionality in ReSA.

5.     ReSA Totals

The ReSA totaling process allows users to sum or count any data. Totals can be used to roll up data for export to external systems, as part of loss control schemes and for general reporting.

Totals always relate to one business date at a time. Any ReSA Total contains following informations:

o   Total Definition  
o   Total Level : Store,Register,Cashier
o   Total Values

o   Total Sources  : POS Uploaded, Store User Updated,HQ User Updated , System Calculated
  
A view is built on the database for the total definition, named V_TOTAL_.

A function, named SA_T___ is also written and compiled on the database.  This function actually calculates the total value using the information that was chosen in the totals wizard.

 SELECT COUNT (sa_tran_head.tran_type),
         sa_store_day.store_day_seq_no
    FROM sa_tran_head,
         sa_store_day
  WHERE sa_tran_head.store_day_seq_no = sa_store_day.store_day_seq_no
  GROUP BY sa_store_day.store_day_seq_no

6.     ReSA Rules

The ReSA Rules process allows users to supplement the validation built into ReSA and define their own validation criteria.   Rules always relate to one business date at a time.

Rules in ReSA are also dynamic. They are not predefined in the system—retailers have the ability to define them through the online Rules Calculation Definition Wizard.
 
 Rules and errors are only produced by the system. Any ReSA Rule contains following information:

o Rule Definition

o Errors

o Error Impacts

o Overriding Errors        

7.     ReSA User Accesses

The user access within ReSA is classified into the following categories:

     Cashiers - In some retail organizations, Cashiers may also have access to the ReSA application data. However, their responsibility within ReSA is limited to reviewing all the exception errors related to their shifts only. They have the necessary access rights to correct or override the errors displayed in the ReSA system. The ReSA forms that are accessible to Cashiers are:
  •        Store Day Find window
  •        Balancing Level Summary window
  •        Transaction Detail window
  •        Miscellaneous Totals window
  •        Over/Short Totals window
  •        Missing Transactions window

      Store Managers - Store Managers use the ReSA application to review all exception errors related to their respective stores only. The ReSA forms that are accessible to a Store Manager include:

  •        Store Day Find window
  •        Balancing Level Summary window
  •        Store Day Summary window
  •        Transaction Detail window
  •        Miscellaneous Totals window
  •        Over/Short Totals window
  •        Missing Transactions window
  •       Transaction Find window
  •       Item Summary window
  •       Tender Summary window
  •       Transaction Audit Trail window
  •       Total Audit Trail window
      HQ Auditors - HQ Auditors use the ReSA application to review all exception errors related to one or more stores assigned to them.

Both Store Managers and HQ Auditors have the necessary user access rights to:

  •         Correct or override the errors
  •         Perform additional data analysis, such as, reviewing the Cashier audit trails.

8.     ReSA Audit
  • Virtual Back Office (VBO) audit is one in which the designated store employee accesses the ReSA system (forms) to perform audit functions. When both the Store and HQ auditors access the ReSA forms then the organization follows a multi-level audit process and the audit process is known as Virtual Back Office (VBO) audit.
  • Interactive audit is one in which the only Headquarter (HQ) auditors access the ReSA system to perform audit functions.
  • Automated audit is one in which the auditors build a Total definition within the ReSA system. They also define the audit rules within the system, based on which the system performs the transaction data audit.
9.   The Systems Variable module allows to set up the following information for Sales Audit:

  •       System options: System validation methods, including escheatment, voucher options, and information related to the automated clearing house.
  •       Error code definitions: Error codes that will appear, and where in Sales Audit that you can fix them.
  •       References: References that you may attach to a transaction in order to better explain what occurred.
  •           Field level access: Allows you to define the fields a user may access.

10.   The Sales Audit Maintenance module allows you to define the following information for Sales Audit:

  •       Employee information: Identify who the user is and what permissions they have in Sales Audit.
  •           Company closings: Indicate when the company is closed and create exceptions at the store level to the closing.
  •       General ledger account maintenance: Create accounts to which Sales Audit will report the results of the store day.

11.   ReSA Security Levels:  ReSA supports following three security levels for the credit cards which needs to be setup at the install time (updating the CC_SEC_LVL_IND field in the SYSTEM_OPTIONS table):
  •        None: Credit card data from the RTLog is saved to the ReSA database. Any valid user has access.
  •           Restricted Access: Credit card data from the RTLog is saved to the ReSA database, but only specified users have access.
  •     Discard Credit: Card Data Any credit card data in the RTLog is ignored. It is not saved to the ReSA database. Any subsequent extracts from ReSA will not contain the credit card information.

About Nagesh Mishra

Nagesh Mishra - A Passionate Oracle Retail Certified Professional with more than 17 years of overall experience in IT industry and more than 15 years of domain expertise in Oracle Retail Applications. Worked extensively in diversified fields of Product Implementation, Business Consulting, Pre-Sales, Application Software Development, Maintenance and Support and Re-Engineering Oracle Retail projects.

1 comments :

Anonymous said...

Please let me know if we can run saexpgl job more than once in a single day. I want to run this job in adhoc outside the batch window. Is that possible?