Demystifying CIF

To begin the story let's assume there is the mainland named ERP world and an island - APO. The
island is connected to the mainland by a multi-lane bridge. The bridge (RFC connection) has toll gates
at both ends. You have tourists (transaction data) and workers (master data) who need to get over
from one island to the other through coaches or buses (Integration Models). Interestingly workers
(Master Data) can go from the mainland to the island only and not other way round. Tourists
(Transaction Data) can go either way but they cannot go from mainland to the island till there is
infrastructure built by workers (Master Data). There are designated buses/coaches to transfer workers
and tourists depending on the destination (different Integration Models for different type of data) to
minimize confusion and mismatch. Depending on the route number (type of master or transaction
data) the buses/coaches travel in dedicated lanes of the bridge. And if one of the bus/coach breaks
down (CIF queue) then that entire lane is stuck with no further bus (more follow-up CIF queues in
WAITING status after the ERROR queue) able to travel to the other island. So here are the steps for
commuting between the mainland and island. Taking cue from the above description the initial
infrastructure setup to be done in respective systems is explained below. First the bridge needs to be
built - this is normally done by the BASIS team who can be considered as the bridge-building
engineers. Once this is done you start creating the routes and assign them to workers or tourists -
Integration Model "creation". Integration Models variant are created in transaction CFM1 and saved.
This is like defining who can go in the particular coach/bus. You then use the same transaction CFM1
to "generate" the Integration Model by pulling up a suitable variant and executing it (F8). Save the
"generated" model. The Generated Integration Model can be considered as the bus/coach filled in
with workers/tourists and waiting at the toll gate before the bridge. This Integration Model is now ready
for "Activation" using transaction CFM2. This can be thought as actually starting the bus/coach and
cross over the bridge to the other island and ultimately reach its destination on other side. However
this may not always be so smooth. So the bridge authorities use a monitoring mechanism called SCM
Queue Manager (transaction /SAPAPO/CQ) and other tools (SMQ1 - Outbound Queue and SMQ2 -
Inbound Queue) to keep track of the bridge and clear any breakdowns. To compare who all toursists
(transaction data only) have arrived at APO island there is another tool called Delta Report
(transaction /SAPAPO/CCR). In case someone is left behind she can be resent. This is in short a
story board way of explaining CIF.

Demystifying CIF - Part II

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 intuitive - 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 Info records
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, Work Centres, PPMs
and Source of Supply)from a troubleshooting purpose. But if you have multiple manufacturing plants,
distribution centers 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.