Вы находитесь на странице: 1из 15

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.

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 unidirectional) 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 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, Work
Centres, PPMs and Source of Supply. The same methodology is applicable for transaction data. Typically
Transaction Data Integration Models are segregated 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.
CIF Activity after System Refresh
The objective of this document is to list and explain the activities to be Performed to Make the CIF
workable after system Refresh.

Activities to be performed in ECC side


1. Delete the Integration Model with Old logical system: The inbound and outbound scheduler determine
the logical systems based on the inactive and active IM models and hence delete the IMs after the system
refresh as the copied IMs will have the old system as the logical one.

2. Change the IM variant logical system: Execute the program RCIFVARIANTCHANGE for the
reportsRIMODGEN,RIMODAC2 and RIMODDEL.

3. Check the RFC connection perform connection and authorization check.

4. Run the RCIFIMAX program with the option of Deactivation, generation and consistency check. Ensure
that the old logical system is not appearing in the list.

5. Generate and activate the all IM with new logical system.

6. Check the number range of planned, production and sales orders and reset the current number range
to the reference system number range.

Activities to be performed in APO side

1. Delete all publication setting with old logical system

2. Generate publication type with new logical system.

3. Check Inbound and outbound queue scheduler and ensure that no old logical system entries are
available.

4. Perform the RFC connection check.

5. Perform the DELTA report (/sapapo/ccr).

After upgrade to SCM7.02, some customers reported incidents that didnt happen in earlier releases.
From integration area, Ive found the following two notes are quite often recommended:
1751405 Process order integration results into LiveCache error RC 43 valid for: SAPKY70201 SAPKY70205
>> Its also applicable if you see error messages during planned order conversion. The error message
can be

backward scheduling (enter finish date)

Forward scheduling (enter start date)

Dump MESSAGE_TYPE_X in program SAPLCXTK


1794856 PO or STO dates incorrect in SCM or not visible in APO valid for: SAPKY70201 SAPKY70207
>> Its also applicable when CCR can detect/correct the missing PO. If youre using
BAPI_POSRVAPS_SAVEMULTI3, it should be implemented as well. Its solved similar issue about
purchase requisitions and PO memo.

Very often when analyzing issues in APO I find it useful to read order details from the liveCache.

We can see from the order data stored in the liveCache when it was created, whether it was already
transferred to ECC, what is the net processing times (in seconds) of the modes of the activities and, of
course, compare all that information to the interactive screens we use all the time, be it Master Data (like
PDS display) or application-specific (like Product View or a Planning Book).

One way to do this is by executing Function Module /SAPAPO/OM_ORDER_GET_DATA, as described


below:

1) Get the OrderID number of the order.


At the Product View, execute ok-code GT_IO and then copy the value of the field Internal Order
corresponding to the order you want to get the details on:

Another way would be to open the Order View (/SAPAPO/RRP2) for the order, then enable the debugger
with ok-code /h and press enter twice to open the debugger. Then, copy the orderid from field
GT_ORDERS[1]-ORDERID

2) Get the GUID of the Planning Version


(you can skip this step if you are reading order data from the Active Version / Planning Version
000).
This can be done in transaction /SAPAPO/OM16. There, specify the name of the Model and the
name of the Planning Version and execute. Then, copy the value of field Guid of Planning Vers.

3) Execute in transaction SE37 the Function Module /SAPAPO/OM_ORDER_GET_DATA.

At the selection screen of the transaction, specify the Function Module and click in Test/Execute button
(F8)

On Test Function Module screen, set the indicator Uppercase/Lowercase

In the Details View of Import Parameter IS_GEN_PARAMS, specify the GUID of the Planning Version
(always 000 for the Active version)

Press Back button. Then, in the Details View of IT_ORDER, specify the OrderID

Press back button and then execute the Function Module. Then, click on Save button in the popup and
check the results:

4) Analyze the data

You can check, for example, the date and time this order was created in APO, in export
parameter ET_ORDERS, field CREATION_TIME (all dates are displayed in UTC, exactly as stored in the
liveCache).

If you are in a scenario with alternative sequences, you can see in ET_MODES, field
PROC_TIME, what is the net processing time of that mode, in seconds.

You can see the time-continuous and the bucket capacity requirement for each of the modes in
ET_CAP_REQS.

In the example above, you can see this order was not sent over to ECC yet as ET_ORDMAPS is
empty.

If there are activity relationships in the order, they will be shown in ET_INTERN_CONSTRAINTS.

Many other informations can be checked, if required, and then compared to the values displayed
in interactive transaction (like the /SAPAPO/RRP3 or /SAPAPO/SDP94).

What does CIF stands for?


CIF stands for Core Interface. It is the interface for data transfer between an ERP system (SAP R/3 or
SAP ERP) and a connected SCM system, such as SAP Advanced Planning and Optimization (SAP APO)
or SAP Supply Network Collaboration (SAP SNC).
The basis for the data transfer is the Integration Model on the ERP side.

How should I start on the Integration of the Systems?


The Integration is made by using Integration Models, which are packages of data to be transferred.
Examples of objects an Integration Model can contain:

Material/Plant information

Planned Orders and Production Orders

Purchase Requisitions and Purchase Orders

Sales Orders

Stocks

Batches
You should generate Integration Models for all data you want to be present in the SCM system.
Depending on the volume of data, you might have to split your Integration Models.
How do I generate Integration Models?

To start, go to transaction /CFM1 (report RIMODGEN) on the R/3 side.

Select your logical system (maintained in /SM59 and in /CFC1).

Name your Integration Model (e.g. "EMEA Data") and its Application (e.g "Sales Orders", "Prod.
Orders").

Select the data you want to send. Maintain additional information in the right panels (Material,
Plant, etc.).
You might have to click the right arrow to expand specific panels for each option.

Click Save. Models will be generated.


Please note that the Models are generated in a inactive mode. You have to activate the models to transfer
the data.
How do I activate my Integration Models in foreground?

Go through transaction /CFM2 (report RIMODACT) on the R/3 side.

Enter your Integration Model data (Logical System and Model name is enough)

Execute

Double click in the model you want to activate

Click the red "X" icon. It will change to a green checkmark.

Press "Start"

Data will be transferred and Model will be active.


How do I activate my Integration Models in background?

Go through transaction /CFM3 (report RIMODAC2) on the R/3 side.

Enter your full Integration Model data (Model name, Logical System and Application)

Choose the option "Activate Newest Version"

In the Program Menu, select the option "Execute in Background (F9)".

Data will be transferred and Model will be active.


You can also create a (periodic) job for this task in /SM36
My Material Master objects have changed. What do I do?
The objects already in an active Integration Model are automatically transferred to APO when changed in
R/3 if you have activated the Immediate Transfer of Objects in the /CFC9 transaction. In this case the
objects are immediately updated in APO.
My Transactional Data has changed. What do I do?
All transactional data that refers to a Material Master object that is in an active Integration Model is
automatically transferred to the APO system.
I have created new data. Will this be transferred automatically to APO?
No. Your new data must be in an active Integration Model. For this, you will have to generate and activate
your Integration Model again.
By generating the model again and by activating it, you will be able to transfer the objects that were
changed or created since the last run.

Important! Note that the activation of the IM must be done in one step.

Generate new IM (/CFM1)

Enter RIMODACT (/CFM2). In the next screen, click on the red "X" of the first entry (just created).

Hit save.
If you do this procedure in two steps (deactivate old model, save, activate new model, save), you will be
doing an initial transfer one more time, which can lead to high volumes of data being transferred again.
How do I transfer all data again?

Using the two-step Integration Model activation explained above or

Running report RIMODINI


Can I schedule a job to update my Integration Models and transfer new data?
Yes, you can!

Create a /CFM1 Variant

Create a /CFM3 Variant

In transaction /SM36, create a new job

Add as step 1 the RIMODGEN execution

Add as step 2 the RIMODAC2 execution


It's recommended that you also create a job for report RIMODDEL. There is no need create a variant to
execute it. This job will clear the entries of the Inactive IMs in Table CIF_IMOD
Which operations of a routing or recipe in R/3 or ERP are transferred to APO PPMs?
When PPMs are created in APO from Receipes in R/3 only those phases containing non-zero machine
times are brought over. Other phases having only labour (resource category 003) or machine time
(resource category 001) = 0 does not come through.
What determines the validity period of a resource in liveCache?
CFC9 parameter in R/3 does not set the From/to validity date for Resources when Work Centres are
CIFed from R/3 to APO. Actually that is set as per entry in table /SAPAPO/RESLCT - Length of Time
Stream or Bucket Vector in liveCache.
What needs to be done to debug CIF related enhancements?

In order to debug CIF related user exits or other CIF queues, set the R/3 RFC user (e.g. STGUSER) to
Dialog user and then set queues to Debugging On/Record T/QRFCs in the transaction CFC2 in R/3. This
is for queues coming inbound to APO. For queues coming inbound to R/3 set the APO RFC user id (e.g.
APSUSER)
How can transaction data be reconciled with APO from R/3 or ERP side?
Program RCIFORDT can be used to reconcile transaction data form R/3 side. Refer 733110 - as a long
term solution implement this BADI on APO side
OSS Notes 627630, 804034 on R/3 side and with the BADI OSS note 800286 to be applied
Which table stores Change Pointers in ERP or R/3?
The table BDCPV is to store Change Pointers in both APO and R/3. Refer OSS Note 329110.
Which report can be used to clear Change Pointers in ERP or R/3?
Program RBDCPCLR can be used to clear change pointers from the Change Pointer table. The message
type CIFSRC is for changes to Source of Supply (i.e. Purchasing Inforecords). The CIF Change Transfer
program (CFP1) can fail due to a large number of records in the Change Pointer table. Other message
types are CIFMAT for material, CIFVEN for Vendor Master, CIFCUS for Customer master.
What is Customer Consignment Stock and how is it transferred to APO?
Consignment stock at Customer is stock at customer premises but owned by the supplier. Prerequisite to
have Consignment Stock at Customer is Customer as a Location and Product Master at that Customer
Location. To transfer Customer Consignment Stock from ERP to APO both "Customer" and "Special
Stock at Customer" should be part of an Integration Model during Initial Transfer. For Consignment Stock
Batches "Storage Location Stock" object must be included in the Integration Model.
Reference: Note 409298
What is Vendor Consignment Stock and how is it transferred to APO?
Vendor Consignment stock is stock at the plant location and treated as normal storage location stock but
owned by vendor. Vendor Consignment Stock is transferred from ERP to APO as part of "Storage
Location Stock" Integration Model. However the Vendor must be part of an active Integration Model.
How is Stock information stored in APO?
Stock in SCM APO system (upto 4.1) consists of Stock Anchor stored in Database and Stock Item stored
in liveCache. The liveCache Consistency Check (transaction /SAPAPO/OM17) carries out the consistency
check between the APO Database and liveCache. It should be executed periodically to delete obsolete
stock anchors from the database.
Reference: Note 492591
As of SCM 5.0 Stock information is stored in liveCache table /SAPAPO/STOCKANC.
Reference: Note 837744
What are the userexits for Integration of Stocks?

On R/3 side the userexit is enhancement CIFSTK01 while on APO side it is enhancement APOCF011.
The source code in the userexit should be copied to the CIF Compare/Reconcile Report (Delta Report)
BAdI (method RELEVANT_FOR_COMPARE_R3_STOCK of BAdI definition /SAPAPO/CIF_DELTA3) for
correctness of the report.
Reference: Note 492591
How is Inspection Lots handled in APO?
From SCM 4.0 Inspection Lots are separate objects in APO retaining the end dates. Hence Inspection
Lots quantities does not shows up as Stock in Quality Inspection.
How is Cross-company Stock In Transit handled in APO?
Cross-company Stock In Transit is determined dynamically in R/3 and hence not transferred to APO. In
APO Stock In Transit at the receiving plant can be handled by transferring Inbound Shipping Notification
or Goods Confirmations from R/3.

Вам также может понравиться