This is a short snippet on Oracle Retail Store Inventory Management (SIM) and its ability to handle stores in different time zones.
SIM Server is usually in a central location. Stores could be located in single or multiple time zones. In either case, the time zone of the store(s) could be same or different from the SIM server time zone. If they are different, it creates a challenge in terms of how the transactions have to be recorded in the SIM database - whether at the stores local time or in the server time. Following is a configuration possible in SIM to handle this situation without any complex customizations.
SIM has a feature to configure the time zone of each store in one of its database tables. There is also a configuration available to indicate whether the actual local time has to be sent to the SIM server or the time needs to be converted to GMT and sent. When these two parameters are used it cleanly handles the stores location in multiple time zones.
For example, a store in Zone 1 performs receipt of items. Another store in Zone 2 does an inventory adjustment. Both of these transaction times are converted to GMT time and then sent to SIM server. SIM server converts the time back to its time zone and performs necessary postings to manage it uniformly. But, when stores access these transactions, they display in store local time. That is neat.
Pls share your questions, comments on usefulness of this short article and your comments or suggestions to minameissri@gmail.com
Sunday, 6 March 2011
Saturday, 5 March 2011
Oracle Retail Price Management - known painpoints
This is a short snippet on some of the known pain points of Oracle Retail Price Management (RPM) and recommendations to overcome these pain points. This case study assumes Oracle Retail Point of Service (ORPOS) used in conjunction with RPM (both v12).
Painpoint 1: Same event published multiple times by RPM to ORPOS
Description: RPM tends to publish the same event erroneously sometimes. For example, Clearance event published 10 times to ORPOS. The issue that is caused in the Point of Sale is that, the event really never ends, even after reaching the end date. Items continue to sell at the lower clearance price. Cause of this issue is, ORPOS updates the end date of only one of the event records, out of the many duplicates. So, when end date is not updated for others, it really thinks it is not ended.
Solution: Make data fix in ORPOS to manually update the end date for all duplicate entries.
Painpoint 2: Overlapping Price Change and Clearance - pay attention
Description: When a Clearance event is published for some items to ORPOS and on top of that, when overlapping Price Change event is published, the price point goes out of sync between RPM and ORPOS. This is caused because ORPOS really goes by latest published event. RPM knows to wait for previous event to end before kicking off next event, in the case of overlap between Clearance and Price Change.
Solution: It is prudent to change business processes to revolve around this issue until Oracle fixes this bug. If not publishing another clearance event to bring the price back is the only way to resolve it.
Paintpoint 3: Rare occasions, price events out of sync
Description: Very rarely, the price event dates go mismatch between RPM and ORPOS. It is hard to trace back a root cause. This will set the price out of sync between these two applications.
Solution: Surveillance or monitoring dashboard is needed to monitor the price events on a daily basis and give a health report. When anomalies arise, they need to be handled as data fixes.
These are some of the well known painpoints. For your feedback on usefulness of this article, pls write to minameissri@gmail.com
Painpoint 1: Same event published multiple times by RPM to ORPOS
Description: RPM tends to publish the same event erroneously sometimes. For example, Clearance event published 10 times to ORPOS. The issue that is caused in the Point of Sale is that, the event really never ends, even after reaching the end date. Items continue to sell at the lower clearance price. Cause of this issue is, ORPOS updates the end date of only one of the event records, out of the many duplicates. So, when end date is not updated for others, it really thinks it is not ended.
Solution: Make data fix in ORPOS to manually update the end date for all duplicate entries.
Painpoint 2: Overlapping Price Change and Clearance - pay attention
Description: When a Clearance event is published for some items to ORPOS and on top of that, when overlapping Price Change event is published, the price point goes out of sync between RPM and ORPOS. This is caused because ORPOS really goes by latest published event. RPM knows to wait for previous event to end before kicking off next event, in the case of overlap between Clearance and Price Change.
Solution: It is prudent to change business processes to revolve around this issue until Oracle fixes this bug. If not publishing another clearance event to bring the price back is the only way to resolve it.
Paintpoint 3: Rare occasions, price events out of sync
Description: Very rarely, the price event dates go mismatch between RPM and ORPOS. It is hard to trace back a root cause. This will set the price out of sync between these two applications.
Solution: Surveillance or monitoring dashboard is needed to monitor the price events on a daily basis and give a health report. When anomalies arise, they need to be handled as data fixes.
These are some of the well known painpoints. For your feedback on usefulness of this article, pls write to minameissri@gmail.com
Subscribe to:
Posts (Atom)