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 :
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?
Post a Comment