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.
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.
0 comments :
Post a Comment