Powered by Blogger.
Showing posts with label Oracle Retail Sales Audit. Show all posts
Showing posts with label Oracle Retail Sales Audit. Show all posts

Sunday, August 14, 2016

Oracle Retail Sales Audit - Understanding Store/Day Auditing Process in ReSA!

So  you know the basic fundamentals of ReSA and understand how to create new custom rules and totals, but thinking how to put all these together? How these are used in Auditing Process? How ReSA User does Auditing? In this post I'm going to take you through the final Store Day Auditing process in ReSA, what kind of Forms used for different Roles defined with various types of Auditing Statuses.


I would suggest you to go through following previous posts in case you are new to ReSA.

1.       What is Store Day in ReSA?


The sales audit function with the Oracle Retail Sales Audit (ReSA) system is performed at the Store/Day Level. ReSA & RMS use the 4-5-4 calendar. The definition of a store/day is simple for retailers whose hours of operation are within the same calendar day (e.g. 9 am to 6 pm Monday through Friday); however, this definition becomes complicated when the retailer operates in a 24X7 environment because their “Business Day” may span multiple “Calendar Days”.  Retailers who operate in a 24X7 environment are open 24 hours a day and 7 days a week which is common in the convenience store and grocery verticals. 
In order to support this, ReSA uses the concept of a “Business Day” in defining a store/day.  Many retailers define their “Business Day” dynamically based on customer traffic in the store.  They may have a target of 6 am as the time to perform the day close functions on the registers; however, this may vary day to day (e.g. 5:54 am one day and 6:36 am another day).  Since the definition of the “Business Day” is dynamic, ReSA uses the Day Close transaction from the Point of Sale (POS) to define the close of the Business Day. 
When loading POS transactions 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 transactions will be associated with the next Business Date.
Refer below scenario to understand what would be the Business Date:
Transaction Type
Transaction Date  and Time
Business Date Calculated by ReSA
Sale
10-AUG-2016; 11:45:03
10- AUG-2016
Return
10- AUG-2016; 11:48:42
10- AUG-2016
Sale
11- AUG-2016; 01:24:56
10- AUG-2016
Deposit
11- AUG-2016; 01:30:25
10- AUG-2016
Day Close
11- AUG-2016; 02:30:45
10- AUG-2016
Sale
11- AUG-2016; 02:45:45
11- AUG-2016
Sale
11- AUG-2016; 3:05:01
11- AUG-2016

2.       Multiple Status Types for Store Day


Three status types are used to clearly define the current state of the store-day as well as determine which employee type can access the data.  The three status types are:


2.1       Store Status

Stores level Status indicates whether the Store Day data is editable in the POS system. Following are the different types of Store Statuses:

·         Worksheet - Store/days are created in a “Worksheet” status. Store employees can edit store/days in this status; however, if the store exports to the Oracle Site Fuels Management (SFM) system the store employee cannot edit a store/day until the status has been updated to “Fuel Closed”.  In this scenario the store employee is required to review the fuel data totals in the SFM forms and perform an interim close in this system before they can edit the data in ReSA. 

·         Fuel Closed - Once the day is closed in SFM, ReSA will update the status to “Fuel Closed”.  When the store status has been set to “Fuel Closed”, the store employee can edit store/day data. 

·         Closed - Once the store employee has corrected or overridden all errors for a store/day they must close the day in ReSA.  This function sets the status to “Closed”.  Once the status is “Closed” the headquarter auditor is granted edit access to the store/day and the store employee can no longer edit the store/day. 

2.2       Data status

Data level Status indicates whether the data has uploaded to the ReSA system, or if the data is in the process of uploading, and so on. Following are the different types of Store Statuses:
·         Ready for Import - Store/days are created in this status.  This status notifies the user no sales data has been loaded for the store/day
·         Loading - This is status indicates ReSA is loading data for the store/day
·         Partially Loaded - In the case of trickle polling, this status indicates only a portion of the transaction data for a store/day has been loaded 
·         Fully Loaded - This status indicates ReSA has received all transaction data for a store/day.  ReSA sets the store status to “Fully Loaded” when it receives the Day Close transaction from the POS indicating all transaction data has been imported.
·         Purging - This status indicates ReSA is in the process of purging the store/day record.

2.3       Audit status

·         Unaudited - Store/days are created in this status.  This status indicates that the totaling/auditing process has not yet been run for the store/day
·         Audited - This status indicates no errors are outstanding for the store/day.  Either no errors were generated during the totaling/auditing process or the errors were corrected or overridden
·         Store Errors Pending - This status indicates there are outstanding errors for the store/day and the store status is not “Closed
·         HQ Errors Pending - This status indicates there are outstanding errors for the store/day and the store status is “Closed

3.       Store Day Audit Process


ReSA supports multilevel auditing where Store Employee (Cashier and Store Manager) as well as HQ Employee audit the Store Day. Audit Process flow to audit any Store Day depends on Employee Type setup in ReSA. Follow are the Store Day Audit Process Flow in ReSA based on Employee Type:

3.1       Cashier

If a retailer requires cashiers to use ReSA, they will typically be granted limited access to the system due to security concerns.   Cashiers will only have visibility to the data (i.e. transactions, errors, totals, etc…) related to their shifts. 
The responsibility of the cashier within ReSA is to review all exception errors related to their shift and to either correct or override these errors.  The following is a standard workflow the cashier would be required to complete within ReSA:
     
    §   Store Day Find

The cashier will use this form to select the particular store/day containing their shift and navigate to the Balancing Level Summary.

    §   Error List

The cashier will use form to review and resolve the exception errors or override the errors.  In order to review or investigate a particular error, the cashier will use this form to any one of the following forms that contain the exception error:
§  Transaction Detail
§  Miscellaneous Totals
§  Over/Short Totals
§  Missing Transactions
    §   Balancing Level Summary

This form will identify to the cashier if any of their shifts contain exception errors.  If no exception errors exist, the cashier does not perform any other functions within ReSA; however, if errors do exist, the cashier must navigate to the Error List to review and resolve the errors.

3.2       Store Manager

If a retailer requires store managers to use ReSA, their responsibility is to review all exception errors related to their stores and either correct or override these errors.  The following is a standard workflow the store manager would be required to complete within ReSA.

    §   Store Day Find

The store manager will use this form to identify if any store/days they are responsible for contain exception errors.  If no exception errors exist, the manager does not perform any other functions within ReSA; however, if errors do exist, the manager will navigate to either the Balancing Level Summary or the Store Day Summary to review and resolve these errors.

    §   Store Day Summary

The manager will use this form to navigate to the Error List to review/audit the entire store/day.

    §   Error List

The manager will use form to review and resolve the exception errors or override the errors cashier, register or store level.  In order to review or investigate a particular error, the manager will use this form to any one of the following forms that contain the exception error:

§  Transaction Detail
§  Miscellaneous Totals
§  Over/Short Totals
§  Missing Transactions

    §   Balancing Level Summary

The store manager will use this form if they want to review/audit the store/day by cashier or register.  This form will identify which cashiers or registers contain exception errors, the manager must navigate to the Error List to review and resolve the errors for the particular cashier or register.

In addition to correcting the outstanding exception errors, store managers may also perform additional data analysis such as reviewing the cashier audit trails.  The following forms would be available to the store managers to use during the audit process; however, the system does not require they use these forms during the audit process.

o    Transaction Find
o    Item Summary
o    Tender Summary
o    Transaction Audit Trail
o    Total Audit Trail

3.3       Headquarter Auditor

The responsibility of the headquarter auditor is to review all exception errors related to their stores and either correct or override these errors.  Depending on how the retailer uses ReSA, the headquarter auditors may be the only users of the system or may be reviewing/auditing store/days after the store employees. The following is a standard workflow the headquarter auditor would be required to complete within ReSA.

    §   Store Day Find

The headquarter auditor will use this form to identify if any store/days they are responsible for contain exception errors.  If no exception errors exist, the manager does not perform any other functions within ReSA; however, if errors do exist, the manager will navigate to the Store Day Summary to review and resolve these errors.

    §   Store Day Summary

The headquarter auditor will use this form to navigate to the Error List to review/audit the entire store/day.

    §   Error List

The headquarter auditor will use form to review and resolve the exception errors or override the errors at the store level.  In order to review or investigate a particular error, the headquarter auditor will use this form to any one of the following forms that contain the exception error:
§  Transaction Detail
§  Miscellaneous Totals
§  Over/Short Totals
§  Missing Transactions

In addition to correcting the outstanding exception errors, headquarter auditor may also perform additional data analysis such as reviewing the store employee audit trails.  The following forms would be available to the headquarter auditor to use during the audit process; however, the system does not require they use these forms during the audit process.
§  Transaction Find
§  Item Summary
§  Tender Summary
§  Transaction Audit Trail
§  Total Audit Trail
§  Import/Export Log
§  Bank ACH Maintenance
§  Store ACH Maintenance

Feel free to drop a note in case you have any questions or comments. More to come on Sales Audit.
Published: By: Nagesh Mishra - 8:00 AM

Sunday, August 7, 2016

Understanding ReSA Audit Rules and Setup Process!



I'm sure you all must have heard a lot about ReSA Rules but might still be wondering how effectively this functionality can be used. Creating custom rules in ReSA is one the best functionality available with which we can almost validate anything. In this post, I'm going to take you through Step-by-Step on how to use Rules functionality in ReSA, explaining each and every screen/application forms and it's Fields. 

Feel free to contact me or drop a note in case you have any question or comments.

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. 

Defining rules is very similar to defining totals – they work on the same principal of building SQL select statements to find data on the database. The main difference is that instead of actually selecting the count () or sum () of a column, the query will can select the appropriate unique key to create a uniquely identifiable:

·         Transaction Header Level Error         
·         Transaction Item Level Error           
·         Tender Level Error         
·         Transaction Tax Level Error            
·         Item Discount Level Error  
·         Transaction Customer Level Error        
·         Total Level Error                
·         Store Day Error            
There are several concepts that must be understood before rules are examined in detail. In this post I’m going to cover following:
o   Understanding Audit Rule Concepts       
o   How to setup Audit Rules in ReSA           
o   Submit Audit Rule Definition for Approval           
o   Approve Audit Rule Definition  
o   How to View and Edit Rule Definition

1.     Audit Rule Concepts

1.1      Rule Definition

The user defines a rule through a GUI wizard.  The rule definition is held on tables in the database.  Rules can be based on data in the database, including transactions and previously defined totals.

1.2      Errors

Errors are associated with rule definitions.  When the rule condition is found, the error is associated with the data.

1.3      Error Impacts

Multiple error impacts can be associated with each error.  An error impact prevents the data from being exported if the error exists.

1.4      Overriding Errors

Some errors simply can’t be fixed.  ReSA requires that they at least be acknowledged and over ridden.  When errors are defined, the user specifies whether a store and/or HQ employee can override them.  It is recommended that all errors are override able by HQ employees so that data can always be exported to external systems.

2.     Audit Rule Setup

Audit Rule Search Window

1.    From the Action menu, select New to set up a new audit rule definition in the wizard.
2.    Click OK. The Rules Calculation Definition Wizard window opens.
Entire Audie Rule Setup is divided in following sections/wizards:
a)    Page 1 - Rule Overview

Rules Calculation Definition Wizard Window
1.       In the Rule field, enter the ID and description of the total definition.
2.       In the Start Date and End Date fields, enter the dates the total definition is effective, or click the calendar button and select dates.
Ø  Note: If User leaves the End Date field blank, the total is calculated indefinitely.
3.       Click Next to navigate through the wizard. Help for selected fields and buttons is displayed in the section on the right side of the screen.
Form Fields Detail
§  Rule Id - A unique ID for the Rule
§  Rule Description - Recommended that the description contain the business objective the user is trying to achieve with the Rule
§  Start Date - The first business date from when the Rule will be evaluated
§  End Date - The last business date from when the Rule will be evaluated. This is an optional field. User may leave this field blank
§  Status
       The status field displays the current status of the Rule
       Status of a Rule can be changed via the Options menu
       The option menu enables the Options which are valid based on the current status of the Rule
       Rule can have following different Status:
o   Worksheet: A Rule definition can be created or edited only when the Rule is in ‘Worksheet’ status
o   Submit: After creating a Rule, the user can change the status to ‘Submit’
o   Approve: Only ‘Approved’ Rules are processed. Right to ‘Approve’ a Rule can be accessed controlled
o   Disable: ‘Disabled’ Rules are excluded from processing. But the Rule definition details are maintained in the system
o   Disable: ‘Deleted’ Rules are flagged for the deletion from the system. Rule definition details are purged in the next purge cycle
§  Version
       When creating a Rule definition for the first time, the Version will always be 1
       This field is populated automatically
       The version changes if an existing Total definition is updated
       Details of all previous version are maintained
       Creation or edit of every Rule is tracked
§  Update Id
       Displays the User ID of the person that created this version of the Total
       Tracked for every version
§  Update Date / Time
       Shows the time and date when this version of the Total definition was created
§  Should failing this rule stop all other rule processing for a store/day?
        The user can define the rule as stopping all rule processing. 
       This is generally used for rules that determine whether basic data exists for a store/day
       “Yes” indicates that ReSA should stop further processing of the POS data if the rule fails
o   e.g. invalid store number
       “No” indicates that the ReSA should continue processing the POS data even if the rule fails
o   e.g. invalid item code
§  Execute Order?
       The execute order determines the order in which rules will be processed
       Rules are placed into various execute groups
       Specifying a value in this field  indicates the execute order group for the rule
       This helps to schedule rules in priority in case they are dependent on each other
       If multiple rules have the same execute order group, then the rules are applied in alphabetical order of the Rule ID
§  Will you use the wizard to create this rule?
       Like totals, rules can either be defined with the rule definition wizard, or through a manually written rule definition function
       “Yes” indicates that the Rule is created using the wizard
       “Yes” will enable the screens to define the criteria for the Rule
       “No” indicates that the Rule is not created with the wizard functionality
       “No” indicates that the Rule is created backend by a developer
§  Should this be evaluated at the store or system balancing level? This relates to the balancing level that has been chosen for the system 
       If a company balances by store, rule will be evaluated for entire store/day
       If a company balances by register, rule will be evaluated for each register during the store/day 
       If a company balances by cashier, rule will be evaluated for each cashier during the store day

Ø  Clicking on the “Next” button loads the Rule Characteristics Form to add rule characteristics

b)    Page 2 - Rule Characteristics

Form Fields Detail
§  Does the presence or absence of this condition constitute an error?
       Presence: Selecting this option indicates that if the POS data satisfies the rule then the system will record an error
       Absence: Selecting this option indicates that if the POS data does not satisfy the rule then the system will record an error
o   Absence rules are restricted to the store level e.g. “Are there No Bank Deposit Total for the Store”
o   Cannot apply the “Absence” rule to transaction or item
§  Record Type
       This is informational only field
       It is used to indicate the section of the data the rule is trying to evaluate
       This field is not enabled for the “Absence” rule
§   What errors are produced by this condition?
       This section is used to link an error with the rule
       ReSA will record this error every time the rule satisfies the rule criteria
       Error codes need to be pre-defined for use in this screen
       One or more error codes can be linked to a rule
       The LOV icon can be used to select the error
       The “Add Error” button can be used to add one or more errors
       The “Remove Error” button can be used to remove an error that is already associated
       Clicking the “Error Details” loads the Error Code screen

c)     Page 3 – Realms

Form Fields Detail
§  The Realms window works in the similar fashion to the Total Realms window
§  One or more realms can be selected to configure a rule
§  Views created for Totals are also available for selection

d)    Page 4 – Joins


Form Fields Detail
§  The Joins screen in the rules wizard functions the same way as the Joins screen in the total wizard
§  Joins are system defaulted
§  These are presented simply for user review
e)     Page 5 – Parameters

Form Fields Detail
§  This section is used to select the parameters to define the rule
§  The Parameters screen in the rules wizard functions the same way as the parameters screen in the total wizard
§  Only parameters linked to the selected realms are available for selection
§  The system will default the parameters needed to log the error against the correct day and record type

f)      Page 6 – Restrictions

Form Fields Detail
§  The Restrictions screen in the rules wizard functions the same way as the restriction screen in the total wizard
§  The user should indicate any restrictions that should be applied to the data set
g)    Page 7 – Location Traits

h)    Review & Finish the Totals Definition
To review and make any changes to the definition, click Back to return to the appropriate area. User can also directly go to the appropriate page by selecting it from the Skip to Page dropdown field.



1.    Click Finish. The Rule Definition is saved.
2.    Clicking on the finish button, creates the Rule in “Worksheet” status

3.     Submit Audit Rule Definition for Approval


Rules Calculation Definition Wizard Window
1.    From the Options menu, select Status > Submit. User is prompted to confirm the submission
2.    Click Yes. The status is changed to Submitted
3.    Click Finish to save your changes and close the window

4.     Approve Audit Rule Definition


Rules Calculation Definition Wizard Window
1.    From the Options menu, select Status > Approve. User is prompted to confirm the approval
2.    Click Yes. The status is changed to Approved.
3.    Click OK to save your changes and close the window

5.     View Audit Rule Definition


Rules Calculation Definition Wizard Window
1.    Navigate to all pages of Total wizard
2.    Click Finish to close the window

6.     Edit Rule Definition

In order to make any change in the definition of Rule, it must be in “Worksheet” status. Making changes in Rule is same as setting up new Rule through Rule Definition Wizard.

Rules Calculation Definition Wizard window
1.            From the Options menu, select Status > Worksheet. User is prompted to confirm the submission
2.            Navigate to required page of Rule Wizard to edit the detail
3.            Once changes made, Click Finish to close the window
Ø  Note: Rule needs to be resubmitted and approved after making any changes to the definition. ReSA maintains the version history of each change made to the definition.


 Do drop a note in case of any questions or comments!
Published: By: Nagesh Mishra - 1:24 PM