Journey from POSDM to POSDTA(CAR)

Most retailers/customers who are having SAP Retail(ECC) as an ERP system are using POSDM(Point of Sales Data Management) as a Sales Audit Tool that receives, enriches, processes and sends Point of Sales data to various SAP and Non SAP Systems. Now we all are aware that POSDM will be out of product support from 2020 onwards(as per SAP) and that brings us the question of “what next”? Well this is exactly the time for the retailers especially the IT team, to understand how they can onboard the POSDTA(CAR) journey(if they haven’t’ done so) and what are the Do’s and Dont’s in doing so !

Approach A

If the retailer/customer decides to go with a parallel(dual) feed of Point of sales data into both POSDM and POSDTA below are the steps that can be followed.

1.Get the inbound sales into POSDTA and replicate the master data from ECC into CAR for basic validation of master data as part of the Sales Auditing. This helps to validate whether both the systems(POSDM and POSDTA) receives the same number of transactions and there are no new errors

• Most of the retailers are using SAP PI as a middleware in which case it can be configured to dual feed sales data POSDM & POSDTA.However if the volume of inbound sales transactions are significantly high, due diligence needs to be done from performance perspective to avoid any processing bottlenecks.

2.Enable all the one-step and two-step processing tasks within POSDTA and validate/ compare if the common tasks between POSDM and POSDTA are processed successfully.

•  Here you can validate the aggregates between POSDM and POSDTA to ensure they are comparable and also if immediate processing is enabled, we can validate the idocs content from POSDM and POSDTA
• At this stage, if you are not ready for outbound integration then the partner profiles for ECC should not have been configured, this is to ensure the idocs to ECC are not duplicated both from POSDM and POSDTA.

3.We can enable outbound integration where the data will be sent out from POSDTA to both SAP and Non SAP systems(depends on the customers’ system landscape)

•  In this approach the partner profiles need to be deleted in POSDM for those stores that are going live and they need to be configured in POSDTA to enable idocs to flow into ECC.
•  In case of BW integration, they should be able to differentiate whether the data is coming from POSDM or POSDTA (as a source system) and accordingly the required sales data can be published to further layers for reporting(RDL/IDL/CML etc)

Approach B

If the retailer/customer decides to go with a phased rollout/cutover approach with an intention to Go-Live with POSDTA all at one go(inbound/processing/outbound)

1.Go with one or few pilot stores based on the sales org or any specific business function and then do all the above 3 steps at one go.

• Even then prior functional/integration testing is highly recommended before Going live with POSDTA.

2.The sales data from POSDM should be stopped for these set of pilot stores which can be achieved by one of the below approaches

• a) SAP PI stopping the sales into POSDM(in this scenario no changes are required in other downstream systems) using store numbers.
• b)SAP POSDM to control the tasks processing based on store profiles(store numbers), by doing so the data will not be sent to any downstream systems.

3.Once the end to end data is verified by IT/business in all the downstream systems, other set of stores can go-live based on range of store(s) or by sales org etc.

Pre requisites for both the above approaches.

1.Relevant configuration in POSDTA(if you are going with CAR POSDTA RDS package, then YR01 standard profile will be readily available with the customizing tasks)

2.SLT master data replication from ECC

Thanks,

Aram Kalyanasundaram