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 toursists depending on the destination
(different Integration Models for different type of data) to minimise 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 followup 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.

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.