Why I No Longer Recommend Using the CIF

Posted on May 19, 2011 by Shaun Snapp

Background

For years SAP used the Core Interface (CIF) which is an adapter between SAP ERP and APO to convince companies that they were offering a truly integrated solution, and that companies should never use best of breed applications that were better than APO’s individual 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 a nothing like what was advertised by SAP sales or by large consulting companies.

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 in addition to building custom adapters between SAP ECC and planning systems. In my opinion, the CIF is the least reliable and most poorly designed middleware product I have worked. It combines a bad user interface with poor 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 be frequently manually cleared. The errors that are produced by the CIF can also be quite inaccurate.

I am surprised myself how badly CIF performs at companies, because as a person who has worked in SAP integration off and on since 1998 and has connected 5 planning systems to SAP, I know that planning system to ERP adapters are not very difficult to create. So when you are discussing the limitations of really 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 of the APO implementation. It is only recently, that I have begun to question if this is actually beneficial.

Why Is the CIF so Problematic

One reason is simply quality. The CIF has always been a poorly developed product. I directly question the integration knowledge of the developers of the CIF and suspect they lacked experience in adapter development or were unduly influenced by the product managers that wanted too much put into the interface.

One of the major problems, which should have been caught early on by SAP development, is that SAP made the integration system overly complex. This means that there is a large 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 that was 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. This issue is explained in the post below.

http://www.scmfocus.com/sapprojectmanagement/2011/02/understanding-the-complexities-of-the-standard-sap-erp-to-apo-integration/

Since this article I have worked on two more clients, both with continual 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.

The Current SAP Position on the CIF

SAP knows it has a maintenance problem with the CIF, and is proposing to customers that there is a new transaction which can be used to show records that did not go through with better transparency, however, I think this is missing the point. The CIF is so flawed it needs to be replaced with something else. If I were setting up an APO project, there is no way I would include the CIF in the solution.

How to Create a CIF Replacement

So if I would not use the CIF, what would I recommend. An adapter can be written with the following components:

Standard SQL for extracting and importing the data to the system that is to be connected to SAP
UNIX Awk scripts for transforming the data into the right format for import or extact
ABAP coding for extracting or importing the data into SAP
WinShuttle Transaction for extract and upload directly from SAP transactions.

While I used to work with ABAPers to write extract and import programs, I no longer think this is the best way to go now that I have come to use WinShuttle. WinShuttle Transaction allows the user to obtain data from SAP without having to even know the table because the data can be extracted using the SAP transaction. More can be read about WinShuttle at the link below:

http://www.scmfocus.com/supplychainmasterdata/2010/11/winshuttle-for-sap-master-data-maintenance/

This article describes its use for master data maintenance, but it can equally be used to create adapters to SAP to any best of breed application.

Conclusion

The companies that purchased APO were told this integration harness would be solid, and have been mislead. After years of working with the CIF, I have concluded that it is a disabler for projects, and should no longer be implemented. Companies that are evaluating APO need to choose it because they really think the applications or modules within the system (DP, SNP, PP/DS, etc.) are the best fit for their needs. The argument that APO in integrated to SAP ERP is no longer a valid reason because the CIF is not of sufficient quality to be part of any solution.

For new implementations, no value is added from using the CIF. For existing APO accounts, the decision is more complicated. For companies that find the repetitive CIF issues manageable, it might be better to simply leave the CIF in and deal with it. However, there are a number of companies that need to remove the CIF and custom code a solution. It must be understood that the CIF will consume part of a resource as long as APO is running. It can never be expected to simply run all by itself without long-term hand holding.

Transportation Lanes in SCM

Posted on June 20, 2009 by Shaun Snapp

What Are They?

We found a great description of a Transportation Lane by a Rajendra on the SCM-APO forum at www.sdn.sap.com.

Transportation lanes control the material flow along the supply chain. Defines the transportation method, ie., means of transport( might be Truck, Plane, Ship etc ) Also determines the transportation cost, transportation capacity by volume, weight etc. Defines the transportation cost per unit, product and transportation method.You can find the scheduling agreements that you had created in R/3, the planned delivery time etc..

Important Features About Transportation Lanes

The transportation lanes and product assignments that are created must only represent valid planning options, however a location/product record must exist at both the source and destination location for specific products to be assigned to a transportation lane. Location/product combinations are maintained in SAP ERP. However, not all locations are linked by transportation lanes and as a practical matter if all locations were linked via transportation lanes the number of lanes would be significant and difficult to validate. One of the most common planning exceptions is where supply (product or stock) exists to fulfil a demand (sales order, forecast) but no valid transportation lane/product assignment exists to link the two, therefore the transportation lanes must be setup for all valid location combinations. This is easy to do to setup using the mass maintenance transaction.

Transportation Lane Data Included

Transportation Lanes allows you to define the product procurement parameters like lot sizes, cost functions, unit costs, and lane priorities. To define the transportation methods for each lane and related parameters like transport costs, distances and times. Assign product specific transport methods, assign carriers to the lanes. You can use transport bucket resources to model the capacity of transport fleets in order to avoid overloading them.

The Supply Network

Transportation lanes, along with locations combine to form the supply network. They come across from SAP ERP – in the translation of purchase order info records and scheduling agreements. However, they can be created in SCM individually and in batch. They are used in the following SCM modules:

SNP
TPVS
SPP
GATP

They are not used in the other SCM modules because the other modules do not deal with the problem of the overall network. The modules above are multi-location decision modules. To see where transportation lanes have their effect in SCM, see the following posts.

Transportation Lane Config

The transportation lane seems like kind of an afterthought in an implementation. The concept being that the data is CIFed over, the lanes come and and end of story. However, when you actually open up a transportation lane in SCM, it becomes apparent how much there is to the lane in terms of configuration fields. Here we have a screen shot of the lane configuration.

Transportation Lane

Transportation Lane 2
SNP and Lane Setup

http://www.scmfocus.com/sapplanning/2008/09/14/snp-transportation-lane-and-transportation-resource-setup/

SPP and the Bill of Distribution

http://www.scmfocus.com/sapplanning/2008/09/28/spp-bill-of-distribution-bod/

EWM Hardware and Technical Setup

Posted on October 14, 2008 by Shaun Snapp

Transactional Orientation

EWM has a high amount of transactional integration with ECC due to the necessity to pass real time information such as delivery processing (through BAPIs, which means they do not need to be configured with the CIF). For this reason, it is really quite different from the planning applications in APO, which deal with aggregated data (and thus lower in volume). This means that the integration between SAP ERP and EWM needs to be analyzed on a project to determine the load for the CIF vs. the load for the BAPIs. It is recommended that EWM sit on its own server and it can integrate to SAP R/3 4.6C through ECC 5.0 with service pack SP06.

CIF Change Pointers and Transactions

Posted on September 20, 2008 by Shaun Snapp

CIF Change Pointer The CIF change pointer lists any inconsistent objects it identifies. Here is the path.

Advanced Planning and Optimization – APO Administration – Integration – CIF Compare Reconcile Function – Execute Compare Reconcile

The path for setting background jobs for master data transfer is the following

ECC – System – Services – Jobs – Define Jobs (SM36)

Next enter program RIMODGEN

With master data changes, the system can transfer just the master data records. For a transfer of data changes, you must set in customizing in the SAP ECC system that ALE change pointers are written for master data changes. First you activate change pointers (BD61)

In order to initiate real time transfer of master data change, use the following transaction…

(CFC9)

Integration Model Organization

There should be an organized manner that will make master data integration efficient and concise. SAP recommends organizing the integration models according to the following list:

ATP Customizing and product allocation customizing
Plants
Characteristics and classes
Material masters and characteristics and classifications
MRP area
Planning product
Availability check
Product allocation
Customers and suppliers
Work centers
Production Process Models
Scheduling agreement and contract and purchasing info records

Important Features of the CIF

In the CIF you can specify in the integration model that the ATP check in the sales order is to be performed in APO rather than ECC.
(PP/DS) The lot size always indicator is set in the APO product master and if you do not set the indicator, a lot for lot order quantity is always used in make to order planning and the system ignores additional constraints. This indicator is transferred via the CIF.
When data is brought over to SCM via the CIF it is automatically assigned to the active model (000).
Inactive models, including any model that we generate, is only used for strategic planning. Planning that has results CIFed back to ECC is only in the active version, hence the name. Also changes to the inactive models can not be copied to the active model, only changes to the active model can be copied to the inactive.
Even small changes to master data are copied over to the receiving system in an incremental fashion. However, this must be configured properly for SAP to do this. Change pointers must be activated in ECC with transaction (BD61).

We can carry out the real time changes for the following master data elements with the transaction (CFC9)

There is a program that will setup auto data movement for when Material Master, Customer Master or the Vendor Master are created or changed.

In the entry screen you should insert (RIMODGEN) for creating integration models, the variant, counter,

Changes to the PPM or production process model can be setup with transaction (CFP3).

Reference

SCM215 Integrated Master Data in SAP SCM

SCM212 Integrated Supply Chain Model

SCM250 PPDS

CIF Calendar Setup

Posted on September 12, 2008 by Shaun Snapp

What Are They?

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 goto 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 into the production calendar.

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.

SAP ERP Org Setup and the CIF

Posted on September 1, 2008 by Shaun Snapp

Issue of Integration

One of the most frustrating things for getting EWM or any SCM component up is the work required in order to get ECC working properly. 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, and often there is 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 if you 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 the 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)

This in SPRO is where you create the Company Code.

We tried creating our own 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 we had problems getting to work properly. really, we want to just 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 doing a search.

However, even after doing this, we still were not able to extend a 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 a MRP Controller assigned to the plant. For some reason 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.

Then to this.

MRP Areas and Transfer

Next we create storage locations Enterprise Structure – Definition – Materials Management – Maintain Storage Location.

Now when we goto MRP Areas.

SPRO – Materials Management – Consumptive Based Planning – Master Data – MRP Areas – Define MRP Areas

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.

Strangely, while this is documented (to use storage locations as proxies for MRP Areas) this actually 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. In fact it is necessary to save integrations models as variants in order 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 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 for 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. It is very important that the customer be picked up as a 1010 type (VMI) as that 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 very important 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:

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 Orderting Party/Plant

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 for 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) Lets start by creating our Supplier.

Now we will transfer to CFM2 by typing /nCFM2.

However we keep getting an error on the address of the Vendor. This error is critical as it prevents the activation of the integration model. However, we do have the address field filled in, so the actual problem is not apparent to us. What we did learn is that we had left over errors and a blocked message queue even after we changed vendors we received the old error.

So we goto the qRFC Monitor and delete the queue.

Skeptical of Changing Integration Models

We had some problems with the different CIF models that we created for just the vendor. We also became skeptical of changing an integration model, and instead created new integration models. However, through trial and error we eventually got one to work. However, one thing very confusing is that ECC uses different numbering than SCM for vendors. So Vendor Master 2222 in ECC is actually 0000002222 in SCM.

SAP SCM Planning

Explanations and and Unbiased Information on SAP APO / SCM

Category Archives: CIF