Learn about SAP SCM software from firsthand experiences of community members. Share your own post and join the conversation about supply chain management.
If you have already read the Demystifying CIF in this series then the context is known. Before getting into today's subject I would like to highlight a point mentioned by Pedro Lima as a comment to the previous blog. "At the bridge toll gate there are policemen (workprocesses) checking the documents of each worker or traveller. The number of policemen is limited, and some must be left to protect the island. But having too few policemen in the gates can originate big queues. One can check these settings in transactions SQMS and SMQR. " In this blog we shall try to answer some fundamental questions when designing the Integration methodology between APO and ERP systems. So without wasting more words let's start with today's story. Let's assume the Head of State (you are free to choose as President, Prime Minister, King or Queen) is to travel from the mainland (ERP world) to the island (APO World). But the Head of State does not travel just like that - there will be security and other officials travelling in advance to ensure everything is setup properly. Then the Head of State will travel with an entourage with say the Press, Personal Staff, Security, Industry Big Shots etc. and most importantly Family. So everything needs to be detailed out and planned for the visit to be smooth and without mishaps. Likewise before you start doing actual data transfer from ERP to APO/SCM you need to plan out, identify the data and more importantly the sequence in which to transfer initially followed by regular change transfer. This planning becomes all the more important when its a single instance serving multiple production plants, distribution centers, customer, vendors and so on. So how do we do it. Firstly you have to realise not everything (like everyone in the Head of State's entourage) get sent or travel together. This is both due to a limitation of the transportation capacity (the entourage will travel in several cars/vans) and also timings (outer ring of security and other officials need to travel ahead of the entourage). Secondly some basic infrastructure is required at the visiting sites even for the advance parties to reach like rooms, restrooms, communication equipment etc. Likewise before you start doing initial transfer of any master data from ERP to APO you first need to ensure sending some customization data. Examples of such data are - ATP Categories, Factory Calendars, Region Codes, MRP Controllers etc. Once these are in APO then the first Master Data object to transfer will be the Plants. Next will be materials. You may choose to combine them in the same integration model but not suggested. If you have MRP Areas and Materials extended to MRP Areas then these will be the next to transfer. Once Plants and Materials are successfully transferring to APO the next set of master data would be work centers. Then only you transfer PPMs (or Production Versions). The reason for this sequence is intutive - PPM consists of Header and Component products as well as Resources. So unless the location-products and the resources are in APO, Production Versions cannot be transferred from ERP to APO as PPMs. Also if the PPMs are having reference to Setup Groups and Keys these need to be created in APO system before PPM transfer. Among the different types of master data PPMs can be the most difficult to transfer successfully due to the dependencies mentioned. The last set of APO Master Data transferred from ERP is Sources of Supply and Procurement Relationships which is a combination of Contracts, Purchasing Inforecords and Scheduling Agreements in ERP. Here again the vendors need to be transferred from ERP (normally done in the same Integration Model as the Sources of Supply) for the Procurement Relationships to get created in APO. Upon transfer of Procurement Relationships in APO, Transportation Lanes are automatically created. One then needs to manually update the created Transportation Lanes with Means of Transport and Transportation Duration. In APO most master data objects have additional fields that are APO specific. While CIF from ERP transfers the master data objects and basic fields the APO-specific fields need to be populated separately after transfer. Alternatively you can customise relevant CIF User-exits to populate appropriate values to the APO specific fields directly during transfer from ERP to APO. Now that you have successfully transferred Master Data, the next step is to setup and activate the Transaction Data Integration Models. Unlike Master Data (where the data transfer is uni-directional) Transaction Data transfer happens bi-directional to and from ERP. Please note for Transaction Data you setup and activate the Integration Models so as to establish the channels of communication. Actual data transfer may not happen at that point in time (no transaction data in system for transfer) but only in a future time. Once Transaction Data transfer starts it is vital to keep the channels of communication (Integration Models) active. If the Integration Models get inactive then there will be a breakdown in Transaction Data transfer causing inconsistencies between the Planning (APO) and Execution or Transaction Processing (ERP) systems. Before concluding this blog we shall quickly try to answer a common question - how many integration models and how to combine different types of data into same integration model. The decision for this depends on the volume of master data to be transferred. It is always better to have different integration models (Plant, Materials, MRP Areas & MRP Area Materials, WorkCentres, PPMs and Source of Supply)from a troubleshooting purpose. But if you have multiple manufacturing plants, distribution centres etc. that also leads to a profusion of master data objects. From a risk minimization and easier/controlled troubleshooting purpose in such cases it is suggested to have Integration Models per Master Data Object per plant. All plants will be in a single Integration Model, but each manufacturing plant has its own Integration Model for Materials, WorkCentres, PPMs and Source of Supply. The same methodology is applicable for transaction data. Typically Transaction Data Integration Models are seggregated by plant and by transaction data types like one for Sales Orders, Planned Independent Requirements another for Purchase Requisitions and Purchase Orders, Shipments etc. another for Stock and yet another for Planned and Production (or Process) Orders. In future blogs we shall understand how to troubleshoot data transfer issues, what to do if transaction data integration model becomes inactive, how to ensure change transfers and new master data are transferred and so on.
