Welcome all ReSA Fans. This is in continuation to my previous post for OracleRetail Sales Audit (ReSA) - Deep Dive - Way Beyond User Guide. So, buckle up and let's have deep dive and in ReSA.
This post of focused on understanding the complete Foundation Setup required in ReSA. I'll be taking you through the entire ReSA Application, it's Form's, fields, navigation, usage and it's other functional impacts. Since Foundation data is spread across multiple functional areas, I'm going have grouped this into few series.
Do let me know your feedback or if you have any question on any of below details.
Following are the various types of Foundation Data can be setup in ReSA using several User Interfaces:
- Store Setup for ReSA
- ReSA System Options
- Escheatment Options
- Voucher Options
- ACH Options
- Role and Field Level Access
- Employee Setup
- Reference Fields
- Error Code Maintenance
In this series, I’m going to cover setting up following two:
- Store Setup for ReSA
- ReSA System Options
1. Store Setup for ReSA
§ Unique Tran. No By
Unique Tran. No By controls the level at which unique POS transaction numbers are generated. If the store has one sequence number that is used for all registers, then the value in this column will be 'Store’. Otherwise the store has unique sequence numbers for each register and the value in this column will be 'Register’.
§ Integrated POS
This flag indicates if the POS system is integrated with RMS. If enabled, it indicates that the store produces the RTLOG file with sales data which is loaded into ReSA & RMS. Store can be setup as not-integrated e.g. virtual stores. This flag can be leverages for phased roll-out to stores.
§ Store Data
This form is only used for ReSA, but as it relates to stores, it is accessed through the RMS STORE form. This form allows the user to define which systems he expects to import from and export to for each store.
The systems that can be defined for import (in the code type SYSI) include:
- POS System
- SFM Import
- UAR Import
The systems that can be defined for export (in the code type SYEX) include:
RDW Export
GL Export
ACH Export
UAR Export
SFM Export
§ Location Traits
ReSA also uses RMS location traits for totals and rules. Location traits are a means of grouping stores together. A location trait for sales audit needs to be assigned at each store level. This Controls the access of the HQ Auditor based on trait mapping.
2. ReSA System Options
System Option variables are the parameters that controls application behavior. The system variables provide a means of maintaining the relatively static information about a retailer's business. These variables need to be configured at the beginning. Any change of system options after resuming operations should be evaluated for impact.
Viewing Sales Audit System Options
Following are the details for the System Option variables:
§ Balancing Level
• Level at which Totals should be summarized
• Potential values: Cashier, Register and Store
• Configured at start of operations
• Change of value will require significant system re-configuration in form of Totals, GL Mapping etc.
- Note: If the balancing level is store, totals will be considered across an entire store to ensure the cash on hand is correctly balanced with expectations (meaning one register could be $50 over and another register could be $50 under but there would be no problem because the store as a whole would balance). If the balancing level is register, totals would be considered for each register over the course of an entire business day (meaning one cashier could make an error for $20 over and another for $25 under, but the register would be evaluated as being only $5 under for the day – there would be no visibility to the performance of individual cashiers within the day). If the balancing level is cashier, each cashier will be balanced on each register, meaning that all errors and discrepancies could be tied to a specific cashier on a specific register
§ Unit of Work
• Controls how data gets exported to RMS
• Possible values : Transaction and Store Day
o Transaction
• Transactions are ready for export as soon as each record is validated and error free
• Can have multiple uploads to RMS for a store day
o Store Day
• Transactions are exported at one go after the entire Store ~ Day is validated and error free
• In both cases, records are extracted at ITEM > STORE DAY> PRICE POINT level
§ Max No Days Sales Audit Data Stored
• Determines the number of days data should remain in ReSA after posting to other systems
• Possible values : User defined value
• Storing data for large number of days will affect system performance
• Recommended that this value be set as low as possible
• Value depends on business requirements to hold data
• Change of value does not have any negative impact
• Change of value is applicable on future data
- Note: ‘Active data’, meaning data with errors that has not been exported to other systems, will not be purged. Only data that is audited and closed will be deleted
§ Max. No. Days Post-Dated Trans. Allowed
• Determines the number of days after a transaction has occurred that it can be uploaded into the system
• Possible values : User defined value
• Postdated sales can be uploaded as long as a store ~ day is not closed
• Business to determine the number of days to keep store ~ day open
• Open store ~ days impacts stock ledger closure
• Change of value does not have any negative impact
• Change of value is applicable on future data
§ Credit Card Security Level
• Control the access of customers’ credit and/or debit card data
• Possible values : None, Restricted Access and Discard Credit Card Data
o None: Credit Card data coming from the POS system is saved in ReSA database. Any valid ReSA user can access the information in ReSA.
o Restricted Access: Credit card data coming from the POS system is saved in ReSA database. Only specified users can access the data in ReSA.
o Discard Credit Card Data: Credit card data coming in the POS system is ignored by ReSA. The Credit Card information is not saved in the ReSA system.
§ Check for Credit Card Validation Required
• If enabled, during RTLOG import the credit card number is validated
§ Execute Automated Audit After Import
• Relevant under trickle feed environment
• Indicates whether or not to execute the automated t audit processes after each import of data
• If set to 'No', the automated audit processes will not occur until the system receives a transaction verifying that all data for the Store Day has been transmitted
• If set to ‘Yes’, data will be audited after each import
• Change of value does not have any negative impact
• Change of value is applicable on future data
§ Store / Days Must Be Worked in Order
• Specifies whether data for current store ~ day can be audited, if a previous store ~ day is still open
• Valid values are 'Y','N‘
• Change of value does not have any negative impact
• Change of value is applicable on future data
§ Check for Duplicate and Missing Transactions
• Determines whether ReSA will check for duplicate and missing transactions
• Valid values are 'Y','N‘
• Setting depends on the transaction sequence number generation logic at Point-of-Sales and the number recycle frequency
• Duplicate checks ensures that same data is not loaded twice
• The check happens during RTLOG import, and is checked with values saved in a file at server level
• Change of value does not have any negative impact
• Change of value is applicable on future data
§ Auto Validate Trans. Employee IDs
• Valid values are ‘Y’,‘N’
• If this is enabled, then cashier and salesperson IDs are validated during data import as well in the transaction maintenance screen
• If this is not enabled, employee information will not be validated
• This should be enabled if Cashier level balancing is enabled or if salesperson performance tracking / incentive scheme is required
• If this is enabled, store employee data needs to be maintained in ReSA
• If enabled, recommended to have an interface that populates the user IDs from external system, else can be problem as store personnel churn is usually high in retail environment
§ Tran No. appended with Workstation ID
• Valid values are ‘Y’, ‘N’
• Works in tandem with duplicate check system option
• Used in the scenario where a store has multiple registers and all registers use similar sequence number
• Change of value can cause problems, proper impact analysis should be done before changing this system option
§ Max No Days to Compare Duplicates
• Determines the number of previous day's information to use for determining if a transaction is a duplicate
• Valid values are ‘Y’, ‘N’
• Depends on the frequency of re-setting the transaction sequence at Point-of-Sales
• This value resets the entries in the file on the server
• Change of value will have impact, as the duplicate checks happens with data stored on the server
§ Default Chain
• Indicates the default or primary chain for the retailer
• Can be left null if the retailer has multiple chains and none of them can be considered primary
• This value is pre-populated into ReSA forms to save time and effort
• However, the data pre-populated can be manually overridden
• Change of value does not have any negative impact
• Change of value is applicable on future data
§ Fuel Merchandise
• Indicates whether the ReSA should handle fuel sale transaction
• Valid values are:
§ Yes: indicates that retailer sells fuel and ReSA needs to handle fuel transactions
§ No: indicates ReSA need not handle fuel transactions
• This field is used to interface to Oracle’s Site Fuels Management system
§ Fuel Department
• Contains the department number of the fuel department
• If the retailer sells fuel and plans on using Oracle’s Site Fuels Management system, all fuel SKUs must be in this department.
§ Date to Determine Comp. Store Status
• Drives Flash Sales Reporting
• Allows to define the criteria for comp store reporting
• Valid values are:
o Store Open Date: to compare from the date when the store opened
o Remodel Date: to compare from the date when the store was remodeled
o Acquire Date: to compare from the date when a store was acquired
§ No. Elapsed Days to Determine Comp. Status
• Allows to define the minimum number of days that must elapse before a store can be considered for comp store comparison
• User defined value
§ View System Calculated Total
• Controls the type of Totals that the user can see in ReSA
• Possible Values:
o All: Selecting this option displays all type of Totals to all valid ReSA users
o HQ only: Selecting this option displays Totals to HQ employees only
o HQ and Store Manager only: Selecting this option displays Totals to both HQ and store employees
o None: Selecting this option displays Totals to none of the ReSA users
• Change of setting does not have any negative impact
• Change of setting is applicable on future data
§ Escheatment Indicator
• Indicates whether or not to escheat unclaimed vouchers (gift certificates and credit vouchers) back to the state after a defined period of time
• The value in this field will depend on the laws of the state / area where the headquarters of the company is located
§ Partner Type & Partner
• Used only if the Escheatment Indicator is enabled
• If escheatment is used, the retailer will need to be set up as a partner
• The partner information is used in processing income adjustments of vouchers
Above are the high-level details of ReSA System Options. Do let me know if you still have any questions. I’m going to cover the following foundation in next series:
- Escheatment Options
- Voucher Options
- ACH Options
Pls follow this link for the second installment of ReSA Foundation Data Setup
 - Deep Dive - Way Beyond User Gu...){kind=link}
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