How To Best Understand The CIF Aka The Core Interface

1/21/22, 1:05 AM How to Best Understand the CIF aka The Core Interface - Brightwork Research & Analysis
Brightwork Research & Analysis

100% Independent Information
SAP CORE INTERFACE
How to Best Understand the CIF aka The Core Interface

By Shaun Snapp May 21, 2008
Reading Time 21 mins
Last Updated on March 1, 2021 by Shaun Snapp
Executive Summary
CIF is the integration component between APO and SAP ERP. We cover how to
create integration models in the CIF, understanding outbound and inbound
queues, how to interpret CIF errors, and the CIF Queue Manager.
There is much to learn about the CIF regarding the real story and the
importance of the CIF administrator.
https://www.brightworkresearch.com/cif/ 1/111
Introduction: Understanding the CIF

1/21/22, 1:05 AM
g
How to Best Understand the CIF aka The Core Interface - Brightwork Research & Analysis
The CIF is the integration between APO and ECC. You will learn how the CIF is
configured and used.
Lack of Financial Bias Notice: The vast majority of content available on the Internet
about SAP is marketing fiddle-faddle published by SAP, SAP partners, or media
entities paid by SAP to run their marketing on the media website. Each one of these
entities tries to hide its financial bias from readers. The article below is very
different.
First, it is published by a research entity.

Second, no one paid for this article to be written, and it is not pretending to
inform you while being rigged to sell you software or consulting services. Unlike
nearly every other article you will find from Google on this topic, it has had no
input from any company's marketing or sales department.
Go to top
What is the CIF?

The CIF integrates SAP ERP and APO. The CIF (or core interface) is the standard
method by which you move data between APO and ECC. The systems are “loosely
method by which you move How
1/21/22, 1:05 AM
data between APO and ECC. The systems are loosely
to Best Understand the CIF aka The Core Interface - Brightwork Research & Analysis
coupled.” That is that master data and transaction data must be transferred
between the systems periodically and in only a few situations (such as GATP) is
immediate interaction necessary. APO becomes increasingly transactionally

oriented; we can see the CIF being increasingly transactionally real time.
Whether the CIF is ready for that is hard to say. It is by in large not a very effective
solution to many problems, especially in the area of error checking (which has been
significantly enhanced in 5.1, but its functionality still lags open even source tools).
And is the worst middleware software I can recall using or ever seeing
demonstrated.
The CIF is both a frontend (GUI) and a container where multiple (Remote Function
Calls) RFCs that are batched into logical units of work that are collected for a data
transfer using the core interface CIF. CIF has its configuration transaction (PIMG)
This is a highly recommended transaction to go into for managing the CIF; it is
much more efficient than going into SPRO and does not waste your time navigating
through items that have nothing to do with the CIF. However, it does not have any
extra functionality over that of SPRO; it is just a specialized transaction to give you
access to all ECC CIF functionality and nothing else.
Here you can see the CIF is the central integrating component for all the APO
modules.
SAP makes a big deal about the CIF but is doing nothing more sophisticated than
what other people who work in integration or I do with simple AWK scripts and
UNIX batch jobs. Companies are live for years and have the CIF as a continual
maintenance item. For years SAP used the Core Interface (CIF), an adapter between
SAP ERP and APO, to convince companies that they were offering a truly integrated
solution. And that businesses should never use best of breed applications that were
better than APO’s modules because they were not “integrated to SAP.” However, as a
person who moves between different SAP accounts, often attempting to improve
APO implementations, I can say unequivocally that the CIF has been nothing like
advertised by SAP sales or by large consulting companies.
As much as everyone hates working with the CIF is an unfortunate fact of life for
APO projects, and this post is assuming you decide to use the CIF. It is going to be
painful, but let’s get on with it.
I found a nice slide on the CIF from SlideShare so we thought we would start there
I found a nice slide on the CIF from SlideShare, so we thought we would start there.
One of the advantages of using A is that you can “CIF” or send over data from SAP
ERP, where it is often maintained as the system of record (although that can change
per implementation). CIF always requires configuration and often some
enhancements. However, it is the standard integration harness between APO and SAP
ERP. The integration includes:
From SAP ERP to APO Master Data

1. Plant
2. Material Master
3. BOM / PPM / iPPE
4. Schedule Agreement
Transaction Data
1. Requirements
2. Planned Orders
3. Production Orders
4. Purchase orders
5. Confirmations
From APO to SAP ERP Transactional Data

1. Purchase Order Req
2. Stock Transfer Order Req
3. Production Order
4. Planned Order
5. ATP Request
Integration Models
There is also a primary organizing principle, the integration models that should be
followed. SAP recommends the following:
1. ATP customizing and product allocation customizing

2. Plants
3. Characteristics and Classes
4. Material Masters and Characteristics and Classes
5. MRP Areas, Material Masters for MRP Areas, Characteristics, and Classes
l i
https://www.brightworkresearch.com/cif/ d 9/111
6. Planning Product
7. Availability Check
8. Product Allocation
9. Customer and Suppliers
10. Work Centers
11. PPM
12. Schedule Agreement, Contracts, Purchase Info Records,
CIF uses a queuing system (like other middleware products) and comes with a
consistency checking transaction that allows for the monitoring of the transfer.
Often much of the following paragraphs have been set up already if you arrive on a
site. However, if not, this work has to be done before you even go into the CIF and
start creating integration models. They are both on the APO side and the ECC side.
We will address the ECC configuration first.
ERP Side of the CIF

The SAP ERP side of the CIF is much bigger with more transactions and much more
feature rich. The first we will look at is Name Logical Systems.
https://www.brightworkresearch.com/cif/ i i l i id i i h h 10/111
SAP ERP SPRO – SAP Customizing Implementation Guide – Integration with Other
MySAP Components – Advanced Planning and Optimization – Name Logical System
Next is assigning to a client.
Next, setting up an RFC destination is SM59.
After the RFC destination has been created, we assign it to application cases.
Go to this path…
Go to top
ECC SPRO – SAP Customizing Implementation Guide

– Integration with Other MySAP Components –
Advanced Planning and Optimization – Assign RFC
Destination to Different Application Cases
Go to top
Next is setting the target system model type. This is between (transactional events,
down or initial transfer active). Transactional events are the standard and are most
the time what we see.
There are other settings, such as setting number ranges, but these were the major
ones for setting up the system. Now we will move on to the APO side of the CIF.
The APO Side of the CIF
Transfers happen between logical system names. Typical logical system names
would be SCMCLNT400, ECCCLNT40 and are first created with the program
SAPLBD41.
Goto this path…
Go to top
SAP SCM Implementation Guide – Advanced

Planning and Optimization – Master Data –
Integration with SAP Components
Go to top
Integration via Core Interface (CIF) – Name

Logical Systems
Then the logical names assigned then to physical clients.
Go to this path…
Go to top
SAP SCM Implementation Guide – Advanced

Planning and Optimization – Master Data –
Integration with SAP Components – Integration
1/21/22, 1:05 AM g p
How to Best Understand the CIF aka The Core Interface - Brightwork Research & Analysis g
via Core Interface (CIF) – Assign Logical

Systems to a Client
Go to top
Next is setting up RFC destinations…..
As a planning application and APO box can be integrated into multiple ECC boxes,
although the opposite would probably never happen. In these cases, a master data
issue comes up, particularly with the material master. Integrating multiple ECC
systems and normalizing master data is one of the reasons for the application of
MDM. However, if MDM is not in the footprint, there are other ways of performing
his normalization with customer exits.
Go to this path…
Go to top
SPRO – Integration with other mySAP Components

– Advanced Planning and Optimization –
Application Specific Settings and Enhancements

Go to top
Also, Business System Groups (BSUs) allow you to group physical systems. This
enables the segmentation of their master data within a single Planning Version and
Model. Of course, another option is to create another Planning Version and Model
for the second SAP ERP system data. Creating a BSG is easy.
However, the complexity comes with assigning the BSG to a logical system. We get
there by following the path below.
Go to this path…
Go to top
SAP SCM Implementation Guide – Integration with

SAP Components – Integration via Core Interface
– Basic Settings for Creating the System
Landscape – Assign Logical System and Queue
Type
Go to top
However, a logical system can only be assigned to one BSG, as you can see from the
error below.
Go to this path…
Go to top
SAP SCM Implementation Guide – Integration with

SAP Components – Integration via Core Interface
– Basic Settings for Creating the System
Landscape – Maintain Business System Group
Go to top
Inbound vs. Outbound Queues

You can use either inbound or outbound queues. Inbound queues can handle a
much bigger data volume than outbound queues. What this means is that the
receiving system controls the data transfer. The transfer between the two (inbound
vs. outbound) takes place in ECC (CFC1).
Important CIF Transactions in ECC
After the base transfer settings in SPRO have been initialized, the next step is to go
to the CIF GUI. The CIF transactions can be conveniently segmented into those
initiated from ECC and those initiated from SCM. The major transactions for
integration model management are the following:
(All of these transactions are initiated in ECC where all model management is

performed. The APO CIF transactions are primarily deal with troubleshooting the
CIF, so the majority of CIF code resides in SAP ERP, and not in APO)
1. CFM1 – Create the model

2. CFM2 – Activate the model
3. CFM4 – Display the model
4. CFM5 – Search for the model
5. CFM6 – Change the model
6. CFM7 – Delete the model
Now I will post the screenshots for these. The integration models are created and
activated in ECC.
CFM1: Create an integration model. Notice from this screen that multiple
categories of items can be selected, and that each combination of selections
can be saved as a different variant.
There is no change integration model. The way to change is to use the same
transaction (CFM1) but to call up a saved variant by selecting the Goto menu item
and then open a saved variant. It is different from how variants are used in SAP.
Essentially variants are different integration models. Which, of course is confusing.
CFM2: Activate or deactivate integration model

CFM3: Activate integration model
During activation, a consistency check can be performed for the model.
CIF Errors
However, the problem with this is that while the CIF may show errors, it still will
often bring over the objects in any case. The CIF errors say more about the ability of
the objects to be used once they get into APO than about whether CIF intends to
bring over the objects. You can find out by activating the model. See below.
Importance of the Variant to the CFM1

Transaction
Transaction
You can also create a variant on the CFM2 transaction. However, that variant will
have to do with the options on this screen and will not affect the combination of
product location or the objects to be brought over. That is controlled by the
integration model. Those items are set as variants on the CFM1 transaction.
Because the model defining options are on the CFM1 screen, that variant is much
more essential and, because there is no CIF change transaction (at least in SCM
5.0), a variant should be created every time you make a model in CFM1. The variant
is the model, particularly if you ever want to change it, which you certainly will.
However, I do not suggest that you create multiple variants per integration model.
This is because, to activate and run a model, you type in the model name into
transaction CFM2, you do not grab a variant. Therefore, it is less confusing to save a
single variant per integration model simply.
If you want to make a different, but similar integration model, name it a new
integration model rather than using the variant function. The variant function, at
least, in this case, is best used to bring up and save and change a single integration
model.
CFM4: Display Integration Model
This takes you to this screen, which shows you how many of each type of data is part
of the integration model. You can drill into any of these to see an itemized view.
Double-Click the numbers.
CFM5: Filter Objects in the integration model

CFM6: Change integration model
CIF Transactions in APO

All of the qRFC transactions are centralized here in the APO directory structure.
They are primarily error checking and monitoring in nature:
/SAPAPO/CC
/SAPAPO/CW
/SAPAPO/CQINW
SMQ1
SMQ2
RZ20 – CCMS – Commonly, the admin will lock you out of this. The area that is
of great interest is called error handling.
CIF Errors
There are two types of errors that are distinguished for the processing of qRFC
calls. With RFC, the triggering application does not have to wait for the update to
be completed in the target system. However, this means that the return parameters
cannot be based on, and possible error messages cannot be directly returned to the
application.
1. Communication errors – this includes network problems, non-existent RFC

destination.
2. Application errors – program errors, missing master data at a transaction date.
The way to view this is:
Go to top
Logistics – Central Functions – Supply Chain

Planning Interface – Core Interface Advanced
Planner and Optimizer – Monitoring – qRFC
MonitorThe qRFC Outbound Queue
Go to top
This is critical because, just like a printer queue, once you have one wrong item in
the queue, it blocks any other items from being processed. Occasionally, it becomes
necessary to delete the items in the queue using this transaction (SMQ1).
Here you will see queues that are blocked. Select the queue that is related to your
material and selects Display Selection
Application logs for error processing. Go to this path…
Go to top
Logistics – Central Functions – Supply Chain

Planning Interface – Core Interface Advanced
Planner and Optimizer – Monitoring –
Application Log
Go to top
The CIF Cockpit (/SAPAPO/CC) is supposed to be easy to read, but in reality, it is

anything but easy. Below is a snapshot of the CIF Cockpit. Really, what was SAP
development thinking when they created this interface. Someone, please guess what
the donut icon means
the donut icon means.
This CIF Cockpit is a container for CIF background jobs, qRFC (remote function call,
the CIF is a way of setting up remote function calls), CIF Comparison, etc..
This transaction is strange and gives many false errors when you attempt to login
(for some reason, you need to login to this transaction). However, if you hit the
green checkbox several times and get rejected, simply hit the yellow up arrow, and
you will be allowed in.
CIF Postprocessing
CIF Postprocessing transaction = /SAPAPO/CPP2
Here you can see we have no records processed, which is a concern because we
should put several POs through in our CIF model. No sign of them yet.
The CIF Queue Manager

/SAPAPO/CQ– Queue Manager – this is a strange transaction and brings up login
issues. You are supposed to log in to a remote system, but we had repeated
problems using it.
The errors come when you try to login to the remote system.
Even when we get it to work, it is not amazingly detailed in information. It seems to

show nothing in the queue (what we have up is from a different user number)
The CIF usage typically starts with configuring CFM1 in ECC. This makes sense as the
initial master data, and even transaction data transfer is from ECC to SCM. SAP calls
ECC the dominant master data system. Not that master data cannot be created in
APO, and not that APO does not have master data that does not exist in ECC (it
does) only that it is primarily configured in ECC. After planning is complete, there has
to be a way to get the results from APO back to ECC.
Thus it becomes necessary to configure the second leg – or back to the mother
ship. For this to occur, first, it is required to configure SCM SPRO.
Go to this path…
Go to top
APO SPRO – Integration with SAP Components –

Integration Via Core Interface – Basic Settings
for Data Transfer – Publication – Maintain

Distribution Definition
Go to top
This is a clumsy transaction. It asks for me to enter the types of objects we want to
come over to each location. It also gives a strange error when we first insert our
object and logical system.
However, eventually, I was able to enter all of our locations.
Now I should be able to move these objects between the systems. This is a location-
specific setup. So it can not be configured for the entire Planning Version or Planning
Model.
The Calendar Setup

Underestimated and possibly overlooked, the calendars need to be synced between
ECC and SCM. This way, both systems use the same assumptions. We need to go
to RSA1, select the source system, and transfer global settings.
Then select factory calendar.
There are many different calendars to transfer. There is a production calendar, a

shipping calendar, etc…. These different calendars are associated with different
locations. Here you can see the calendar options at our Vendor in San Diego.
Here you can see we are on the production calendar.
Here we assign this calendar to this location

Here we assign this calendar to this location.
There is a lot more to the calendars and a lot more to how the systems are synched,
and we will build out this article as time passes.
The Real Story Behind the CIF

In addition to consuming significant resources during implementations, 4 to 5 years

after go-live, the CIF is still consuming support time. I have considerable
experience in middleware and interface development over the years seeing

solutions such as SeeBeyond, Informatica and building custom adapters between
SAP ECC and planning systems. It combines a lousy user interface with reduced
error checking, and with a degree of complexity, which makes it very easy for a
small irregularity in either system (SAP ERP or APO) to upset the apple cart. The CIF
has errors that require troubleshooting, and the queues must frequently be
manually cleared. The errors that are produced by the CIF can also be entirely
inaccurate. SAP consultants think the CIF is a decent tool that often has never been
exposed to “real” middleware.
I am surprised myself how the CIF performs at companies because, as a person

who has worked in SAP integration off and on since 1998 and has connected five
planning systems to SAP, I know that the planning system to ERP adapters is not
very complicated to create.
So when you are discussing the limitations of actually existing SAP to SAP
integration, realize that this is supported by a large number of client experiences.
For almost a decade, I accepted the official SAP position that CIF needs to be part
f th APO i
https://www.brightworkresearch.com/cif/ l t ti It i l tl th t I h b g t ti if thi 68/111
of the APO implementation. It is only recently that I have begun to question if this
is beneficial.
Why Is the CIF so Problematic?

One of the biggest problems, which should have been caught early on by SAP
development, is that SAP made the integration system overly complicated. This
means that there is a significant amount of logic in the CIF that, in most cases, is
not desired or needed by the client. I extensively documented one issue related to
sales order integration recently in this post. The decision to include this level of
detail in the field pulled for consumption logic was never going to be a good trade-
off and should have been recognized as a long-term maintenance item during the
initial CIF development.
Since this article, I have worked on two more clients, both with persistent problems
with the CIF. I understand that it is sacrilegious to say things that oppose SAP sales
and product management, but one would have to be blind not to see the pattern.
Setting up the models is straightforward. However, troubleshooting the CIF is a

serious issue that can consume many hours of troubleshooting. Really, at this late
date, the CIF should be far better, and many of the errors simply require experience
and cannot be troubleshot through logical means I am very disappointed in SAP
and cannot be troubleshot through logical means. I am very disappointed in SAP
development for not improving this when there are so many easy ways to improve
it. If SAP would outsource its middleware to someone like Informatica, everything
could be so much more simple. It’s difficult to buy things like the new SAP
integration products when things like the CIF sit with little improvement year to
year.
Anyone who works on SAP APO projects knows that the CIF is hugely unappealing
to work with, has a poor and confusing user interface, and constitutes a long-term
maintenance problem for clients. The problem that you say distributed to other
parts of APO and ERP is also related to the CIF itself. However, I would ask you to
review the 99% value that you quoted. The CIF has far more than 1% of the blame
for its maintenance woes.
SAP has designed a solution with the CIF that has so many options for how data
will be represented in APO that it creates significant problems and makes for a
fragile interface. At the heart of it, I don’t trust SAP development to make the right
decisions with integration products, because they have proven themselves to be not
very good at it. I can point to SAP XI/PI as another integration product that SAP has
had major issues. The problem is that companies are not buying the CIF or XI/PI
because it competes well with companies that do integration well, but because the
d t
https://www.brightworkresearch.com/cif/ ith th SAP b d Th i l l t f thi g th t SAP d 70/111
products come with the SAP brand. There are simply a lot of things that SAP does
not do well. Integration, data management, document management (i.e., Solution
Manager).
If you rely on products that could not survive outside the SAP universe, you end up
disabling your company’s abilities to accomplish its goals. This must be
differentiated from IT’s or a consulting company’s goals. As long as their budgets
increase, even if poor functioning products are provided to the business, IT and
consulting companies are usually pretty happy. However, I am proposing to broaden
the analysis of what is “good.”
A qRFC is not fundamental to any design; many interfaces have no qRFC and run
much better than the CIF. RFCs are known as slower than direct table connections.
(of course, this is impossible in SAP) The problem many SAP consultants have is
they consider SAP an innovator in every area. SAP is not a respected company in
integration. The only integration business they have is integrating into its products. I
should not have to do much more than bring up the work “IDoc” to illustrate this
point. Look at Informatica’s products sometimes to see what a real integration
vendor looks like.
When the CIF Administrator is Necessary

The CIF Administrator must be available before go-live to support all of the
troubleshooting that proceeds go-live. They will then need to support the APO
applications post-go-live.
The Skills Set and Behavior of the CIF

Administrator
The CIF Administrator is primarily a technical role. They must be technical enough
to fix problems in the CIF, but for more fundamental issues, they must
communicate with functional resources. This is because many issues that crop up
in the CIF are often related to problems in the functional module. While technical,
they must also communicate out to the broader business community when there
are issues. One common complaint at other SAP APO clients is that the business
community can feel left in the dark when there are problems. This should not be
the case. The CIF Administrator needs to be ahead of the planners, and challenges
should not be discovered in planning books that the CIF Administrator does not
catch beforehand. There will be problems with the CIF and challenges with APO in
general post-go-live.
However, the interpretation of these inevitable problems is quite different when

1/21/22, 1:05 AM
, p p q
discovered and communicated by the CIF Administrator versus being discovered by

the planners. When planners are told which parts of the product location database
are having a problem, and the steps and timeline that are part of the solution, they
can adjust and not waste time. They can work on other things and return to APO
when it is functioning correctly. Simply the knowledge that the CIF Administrator is
on top of the problem increases confidence in the system.
Regarding communicating both general APO and specific CIF problems, the CIF
Administrator must talk to the planners in business terms that mean something to
them. Comments to the effect that.
“ Inbound queues are now up to 250,000 records,

causing data inconsistencies…
Is not translating the technical problem into a business language. The planners will
want to know when the system has the correct output for the products they are
responsible for. I have seen various emails sent from CIF Administrators to the
business, some getting into detail on the CIF and showing screenshots of the CIF
queues. I have also seen it debated as to whether a report should be sent out every
week, which communicates the state of the system and the CIF to the business.
Generally, what I have seen work best is for the assumption to be that the system
is working correctly unless the business receives an email outlining a problem with
the CIF. When an email is sent, it should outline not the issue, but the implications
of the problem. One example might be.
“ APO is having some issues will prevent the

following product groups (A, B, C) from displaying
proper values. We are currently working on the
problem and as soon as we know more we will
send out a new email.
While the role is titled “CIF Administrator,” the individual who fills the role must
work in all of the transactions, both in APO and ERP, to troubleshoot
problems, though they may first appear in the CIF. Because the role of the CIF
Administrator is a support function, the individual filling the role should have a
support background. A support resource is a very different resource than,

for instance, an SAP implementation resource or an SAP training resource.
The CIF Administrator is a role that is required for companies that are serious about
having a successful APO implementation. The more APO modules
a company implements, the more effort is needed on the CIF Administrator.
Implementing a single module does not make the role of a CIF Administrator a full-
time role, but few companies that implement APO are satisfied with implementing
just one module.
The CIF Administrator must be technical, but if they are supported in their
communication by another resource, they must be able to explain to the business
when there are problems. They must find the issues before they do, and also
communicate when the issues will be rectified. SAP has a hard time communicating
the huge support needs of the CIF because they are tied to their sales message
that the CIF is a great middleware product that is easy to use.
The “ease of integration” is part of SAP’s master strategy to keep companies afraid
of using other applications, even though in many cases writing a custom integration
product would be superior to the performance and stability of the CIF. Therefore,
they are not a reliable source of information on the staffing requirements for the
CIF th
https://www.brightworkresearch.com/cif/ gh it i th i d t 75/111
CIF, even though it is their product.
Issue of Integration
One of the most frustrating things about getting EWM or any SCM component up is
the work required to get ECC working correctly. As EWM is transactionally focused
(rather than planning oriented), it has a high degree of traffic moving between ECC
and SCM. SCM has only a few things that it wants from ECC. Yet it requires all types
of setup that the SCM consultant is not interested in getting into. Often, there is a
CIF consultant on staff (most projects to not see the CIF as requiring a separate
consultant but expect the knowledge to come with a functional consultant).
If you are on a project, then you can ask a fellow ECC consultant to do this.
However, if you are not or can’t get their time, you will have to do it yourself. We
tried to create POs using the Purchasing Org and Company Code that we did not
create. We ran into problems because of the validity period of the company. You
can see this below. Notice how a number of the Company Code’s validity periods
are in the past.
Company Code (Hijacking)
1/21/22, 1:05 AM
p y ( j g)
This in SPRO, is where you create the Company Code.
We tried creating our company code but ran into problems, so instead, we decided
to use an existing company code. (which is 3000)
Next, we want to assign a plant to this company code.
This is where you assign the Plant to the Company Code. By choosing an existing
company code, we don’t have to worry about assigning the company code to the
purchasing organization.
However, we do want to assign the purchasing org to the plant.
Sales Org Assignment
We used an existing company code as the company code we tried to create

ourselves had problems getting to work properly. We just want to get things working
from a supply chain perspective, and we are not concerned about financial
postings.
Next, we want to assign the Sales Org to the Plant. You can find this by searching.
However, even after doing this, we still were not able to extend the material to our
new plant. It did not bring up plant SNA5 as an option. However, when it finally did,
we were not able to extend the material because it did not have an MRP Controller
assigned to the plant.
We forgot to document this step last time for the first four plants that we created.
Next, we go through entering various fields into the material master, and we get an
error on the Scheduling Key and we find that it is not assigned to the material
error on the Scheduling Key, and we find that it is not assigned to the material.
Then to this.
MRP Areas and Transfer
Next, we create storage locations.
Go to top
Enterprise Structure – Definition – Materials

Management – Maintain Storage Location.
Go to top
Now when we goto MRP Areas.
Go to top
SPRO – Materials Management – Consumptive Based

Planning – Master Data – MRP Areas – Define MRP
Areas
Go to top
We can see that the storage location creation essentially creates an MRP Area for
us.
We want to assign these MRP Areas to the correct material and plant combination.
To do this, we go into (MM02), to the MRP 1 tab and select the MRP Area button
towards the bottom of the screen.
Now we will fill in the next screen.
Now we will want to transfer the MRP Area to SCM with CIF.
St g l hil thi i d
https://www.brightworkresearch.com/cif/ t d (t t g l ti i f MRP 93/111
Strangely, while this is documented (to use storage locations as proxies for MRP
Areas), this did not work when we put in into practice. However, if we add the MRP
Areas in the screen below, then they do show up in the integration model.
You can see them in the integration model.
After we check the CIF model that only transfers MRP areas (as recommended by
SAP)
Why Variants?
Just because you create an integration model does not mean that you only have to
type in the integration model and change it. It is necessary to save integrations
models as variants to bring them up in the future and modify them. You do this by
selecting the save button after you have configured your integration model.
Without doing this, we do not know if it is possible to alter the integration model
after first creating it. There is no CFM* transaction for modification. It is transaction
CFM1 with the variant.
When you get back into the CFM1 transaction, it necessary to select Goto the menu
and then choose your variant.
Here you can see there is a log of changed integration models when you go into
transaction CFM2.
Unfortunately, we got the same errors.
However, we have gotten errors before, and the CIF still went through. The way we
check is to go to the Location Master in SCM and type in the MRP Area.
After all those errors it the storage location came across fine!! The big lesson from
this is to take the CIF errors with a grain of salt. Also, notice the location type is
1007.
So it is a 1007 location inside of a 1002 location (distribution center plant).
Customer Creation and Transfer
Next, we will want to create a customer. The customer must be picked up as a 1010
type (VMI), which is the only location that will be modeled in SCM. Later we will
test this to see if it was the case.
Now, after filling in a few fields, our customer is created. This next part is crucial, so
we wanted to quote directly from SAP documentation.
“ “As of release 4.0 of SCM the maintenance of the

sales area shifted from the customer location to
the CIF. You assign the sales area to your sold to
and delivering plant.” – SCM215
It is located here:
Go to top
Integration with Other mySAP com Components –

Integration with Other mySAP.com Components
Advanced Planning and Optimization –
Application Specific Settings and Enhancements

– Settings and Enhancements for Sales Orders –
Settings for Vendor Managed Inventory VMI –
Assign Sales Orders and Order Type to Ordering
Party/Plant
Go to top
While this functionality has been moved to the CIF, interestingly, another portion
does not move through the CIF – that is, the sales transactions.
“ “Similar to that of the plant, stock movements

will be modeled via stock transport requests in
SNP and PP/DS. When it is time to deploy and

ship, SAP SCM can instruct SAP ECC to convert
stock transports to sales orders. This functionality

is the reason for the addition of the VMI tab.” –
SCM215
Now we will want to create an integration model to move the customer over to
SCM and see if it is picked up as a location type 1010. Underneath Material
Independent Objects, we find the selection of Customers. We want to CIF our one
customer over.
We will activate and run the model with (CFM2) and not bother looking at the error
log as the CIF error log always seems to have some problem. Now we can see the
customer has been created.
Supplier/Vendor Creation and Transfer
The supplier is just another location (type 1020). Let’s start by creating our Supplier.
Donate

How To Best Understand The CIF Aka The Core Interface - Brightwork Research & Analysis

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Best Understand The CIF Aka The Core Interface - Brightwork Research & Analysis

Uploaded by

Copyright:

Available Formats

1/21/22, 1:05 AM How to Best Understand the CIF aka The Core Interface - Brightwork Research & Analysis

Brightwork Research & Analysis

SAP CORE INTERFACE

Reading Time 21 mins

Last Updated on March 1, 2021 by Shaun Snapp

Introduction: Understanding the CIF

First, it is published by a research entity.

What is the CIF?

immediate interaction necessary. APO becomes increasingly transactionally

From SAP ERP to APO Master Data

From APO to SAP ERP Transactional Data

1. ATP customizing and product allocation customizing

ERP Side of the CIF

Next is assigning to a client.

Next, setting up an RFC destination is SM59.

ECC SPRO – SAP Customizing Implementation Guide

The APO Side of the CIF

Goto this path…

SAP SCM Implementation Guide – Advanced

Integration via Core Interface (CIF) – Name

Then the logical names assigned then to physical clients.

SAP SCM Implementation Guide – Advanced

via Core Interface (CIF) – Assign Logical

Next is setting up RFC destinations…..

SPRO – Integration with other mySAP Components

Application Specific Settings and Enhancements

SAP SCM Implementation Guide – Integration with

SAP SCM Implementation Guide – Integration with

Inbound vs. Outbound Queues

Important CIF Transactions in ECC

(All of these transactions are initiated in ECC where all model management is

1. CFM1 – Create the model

can be saved as a different variant.

CFM2: Activate or deactivate integration model

During activation, a consistency check can be performed for the model.

Importance of the Variant to the CFM1

CFM4: Display Integration Model

Double-Click the numbers.

CFM5: Filter Objects in the integration model

CIF Transactions in APO

1. Communication errors – this includes network problems, non-existent RFC

2. Application errors – program errors, missing master data at a transaction date.

The way to view this is:

Logistics – Central Functions – Supply Chain

Logistics – Central Functions – Supply Chain

The CIF Cockpit (/SAPAPO/CC) is supposed to be easy to read, but in reality, it is

The CIF Queue Manager

Even when we get it to work, it is not amazingly detailed in information. It seems to

APO SPRO – Integration with SAP Components –

for Data Transfer – Publication – Maintain

However, eventually, I was able to enter all of our locations.

The Calendar Setup

to RSA1, select the source system, and transfer global settings.

Then select factory calendar.

There are many different calendars to transfer. There is a production calendar, a

Here you can see we are on the production calendar.

Here we assign this calendar to this location

The Real Story Behind the CIF

In addition to consuming significant resources during implementations, 4 to 5 years

experience in middleware and interface development over the years seeing

I am surprised myself how the CIF performs at companies because, as a person