This content has been marked as final. Show 3 replies
At our site we put quite some effort in getting this right, we had to send the changes a day before effect to our POS.
If the requirements allow, you could use the rms.price_hist table to get some information about regular, promotional and clearance (price) changes, and a few more varieties. This table is filled by I believe the priceeventexecution batch.
One could also access the (deprecated/bypassed) RIB topics to get the changes.
Also studying the RPM download SQL script for POS (see the RPM Operations Guide) may help in getting those changes.
The hardest thing is to get future prices correctly, as the RPM datamodel is a bit tough, e.g. in case your POS requires to receive price records one or more days in advance of the effective date.
We also implemented an Oracle Stream based feature, Change Data Capture (CDC, based on Logminer, read the online redologs and posting any changes to a table to a special change table, recording, old and new images of the rows for updates, the new image for an insert and the old image for a delete) on e.g. rpm_future_price table to process all the changes and report them to our stores at the moment the price changes was approved.
There may be simpler ways, but this is what we came up with.
But if you can wait untill the price changes have gotten into effect and your pricing model is not too complex (re. complex mix&match promotions), price_hist may be the easy way out, or the vanilla RPMtoPOS scripts.
Hope this helps,
Thanks Erik, for your inputs! I will explore this option and get back to you in case I have any questions. Appreciate your quick response!
I agree here with Erik,
the simplest way would be to check the active prices (action_date=vdate) from the rpm_future_retail table, and sent them to the any Legacy or whatever.
If your customer tries to manage the Retail prices at Zone level, then the rpm_zone_future_retail maybe used.
If I remember correct, RMSPriceEvenExecution batch is responsible to actualize the selling prices in the rpm_future_retail. (with rpm_zone_future_retail it is little bit different).
So, you either have to wait until last run of the batch to extract the prices or implement incremental approach to sent the retail prices.
For the clearances there should be additional table...
Hope it helps