Skip to Content

1. Introduction

APO core interface (CIF) is a standard interface which connects an APO & a standard R/3 system. CIF interface enables the data exchange between an SAP ERP system (SAP R/3, SAP R/3 Enterprise, or SAP ECC), and a connected SAP SCM system. CIF enables the integration of master data from SAP ECC to SCM APO (one way only) and the integration of transactional data in both ways, from ECC to APO and vice versa. The basic idea of the integration is to write events for each planning relevant change – e.g. the creation of an order – and use these as trigger point for the data transfer. Technically the transfer is performed via qRFC. Which objects (i.e. planned orders, stock) should be transferred from SAP ECC to SCM APO is controlled by the integration models, which could be regarded as something like the master data of the CIF.

2. Business Objective

The main objective of configuring the ECC core interface is to integrate the centralized source of master data from ECC to APO & publishing planning result from SCM planning system (APO) to SAP OLTP system (ECC) & vice versa. It is essential to maintain the consistent data & its flow between planning and execution system for better planning result & optimum inventory level.  This configuration also suffices the objective of real time transactional data transfer between planning and execution system & delta transfer for master data changes.

CIF provides the following central functions:

  1. Supply the master and transaction data, relevant for planning, in SCM APO system.
  2. Techniques for initial, incremental, and real-time data transfers from ECC to SCM APO
  3. Techniques for publishing planning results back from SCM APO to ECC system

3. Key Design Areas

  • Technical Integration between ECC and APO (CIF Configuration)
  • Integration of Master data and Transactional data (Design of Integration Models)
  • CIF Error Handling and Queue Management

4. Technical Integration between ECC & APO (CIF Configuration)

  • As of SAP ECC 6.0, CIF is an integrated part of the system. (If you use SAP SCM 5.0 with ERP systems up to SAP ECC 5.0, you receive CIF via the relevant SAP R/3 Plug-In. The SAP R/3 Plug-In is a combined Plug-In used to link SAP components such as SAP SCM to the ERP system up to and including SAP ECC 5.0) .
  • SAP ERP Central Component 6.0 (SAP ECC 6.00) and later releases will directly contain all the interfaces necessary for the technical integration with other SAP components. These interfaces were previously part of the SAP R/3 Plug-In.

/wp-content/uploads/2015/01/1_629451.jpg

5. CIF Set-up & Related Configuration Task

5.1.      Configuration in R/3

    • Define logical system (Transaction code- BD54)

We defined logical system for both ECC and APO system. To enable the transfer of data via APO Core Interface (CIF), you need to name both                    the ERP system in which you are working and the SAP APO system to which you want to transfer data as logical systems.

/wp-content/uploads/2015/01/2_629452.jpg

Note:-The above activity is dependent upon the target system concerned. For this reason, there is no transport to the production system. As a result, you need to also make the settings for the relevant target system in the production system manually, Or Alternatively, you can maintain the entire ECC & APO logical system name (as per SAP system landscape & client strategy) in Development client  and include them in a transport. This will make all the logical system available across ECC system landscape & minimize the manual activities.

  • Assign logical system to client (Transaction code- SCC4)

         In this step, assign the logical system to a client. All the fields like City, Std. currency, logical system should be maintained. Otherwise there will be           some futile CIF error during the data transfer from ECC to APO.

          /wp-content/uploads/2015/01/3_629457.jpg

Note: – These settings cannot be transported. When a new system is being set up, these settings must be made after the system installation has been completed.

  • Specify APO release (Transaction code- NDV2)

In this step, you have to specify the release level of the SAP APO system that is defined as the target system. The release level will activate the compatible functionality for the data transfer.

/wp-content/uploads/2015/01/4_629500.jpg

Note: – The above activity is dependent upon the target system concerned. For this reason, there is no transport to the production system. As a result, you need to also make the settings for the relevant target system in the production system manually or

Alternatively, you can maintain the all of the logical system name (as per SAP system landscape) in Development client and include them in a transport. This will make all the logical system available across ECC system landscape & minimize the manual activities.

  • Setup RFC destination (Transaction code- SM59)

In this step, create the RFC destination which has the same name as the target logical system. This RFC enables the connection to the SCM APO system.

/wp-content/uploads/2015/01/5_629501.jpg

Performance Tip: – By activating the load balancing & defining the logon group, you can use the load balancing procedure while connecting to the APO system. This logon group needs to be assigned to the various servers in transaction code RZ12.

/wp-content/uploads/2015/01/6_629502.jpg

When ECC is connected to APO system it always uses ALEREMOTE user in order to process any CIF queues.

  • Assign RFC destinations to various application cases (Transaction code- CFC7)

You assign various application areas to the logical system and the RFC destination. This is optional configuration & purely depends on the business requirement & guidelines for the type of RFC user to be used for security reasons. Some of the applications only work with RFC dialog user e.g. GATP availability check, but from security point of view, most of the clients e.g. life science, FMCG doesn’t allow to create the RFC user as dialog user which can be misused.

To meet the business requirement, there is a need to create a new RFC destination with different RFC user of type either Dialog or Service user with very limited & restricted authorization. The authorization has to be provided for the type of application to be use.

/wp-content/uploads/2015/01/7_629503.jpg

The below applications can be triggered from ECC into APO

/wp-content/uploads/2015/01/8_629507.jpg

  • Set target system and queue type (Transaction code- CFC1)

In this step, you can set the queue type for the target system specified. It is always recommended to use the inbound queues in the target system to control the processing of the CIF queues with heavy data load.

The queue type (inbound or outbound) determines whether the queues processing is controlled by the sending or receiving system

/wp-content/uploads/2015/01/9_629508.jpg

  • Set user parameter (Transaction code- CFC1)

    In this IMG activity, you can make user-specific entries for the following parameters:

    • You can use this to set whether and how data records should be logged in the application log for the user specified
    • User can use this functionality to debug in case of any queues get created for that user. Any master data or transactional date created by that user will be stuck in the CIF queue which the user can debug and analyze the issue
    • Here, you should maintain entry for user name as “*” for normal or detailed logging of the application log.
    • RFC user should be maintained with the normal logging.
    • CIF administrator id should be maintained for detailed logging along with Debugging mode “ON”.

          /wp-content/uploads/2015/01/10_629509.jpg

  • Determine Number Ranges for Parallelization (Transaction code- CFC8)

          /wp-content/uploads/2015/01/11_629510.jpg

  • Define filter and selection block size (Transaction code- CFC3)
    • You determine the number of filter objects that are processed in one block in the APO Core Interface.
    • Also you determine the number of data objects that are transferred to SAP APO in a remote function call (RFC) at the initial data transfer.
    • In normal cases, it is recommended not to change the above Filter & Block size.
    • You can use these settings to improve system performance during the initial data transfer. The optimum values for improved performance vary from case to case and are largely dependent upon the client data situation. Therefore, you are recommended to experiment with the settings in individual cases in your system. 

              /wp-content/uploads/2015/01/12_629511.jpg

   

                /wp-content/uploads/2015/01/13_629512.jpg

         

                /wp-content/uploads/2015/01/14_629516.jpg

                    Note: – Refer to OSS note # 436527 for the block size recommendation.

  • Configure Change transfer for master data (Transaction code- CFC9)
    • All the master data changes e.g. material, customer, vendor & resources are configured as periodic transfer to APO.
    • During the initial transfer of the resource, it is defined to create external capacity for the resource for 30 days in past and 730 days in future.
    • It is recommended to create single-mixed resource in APO for the resources having single capacity and for which the indicator “can be used by several operation” is not set.
    • It is recommended to configure to create Multi-Mixed resource in APO for the resources having multiple capacities or for capacities for which the indicator “can be used by several operations” is set.

          /wp-content/uploads/2015/01/15_629517.jpg

              Note: –

      • Master data change transfer from ECC to APO can be configured as immediate or periodic, which is completely depends on client requirement.
      • If SNP & PP/DS both are in scope then it is always recommended to use the resource type as mentioned above. This is very critical setting & cannot be altered later neither in ECC nor in APO. You need to delete the resource in APO to change the resource type. This cleanup can be a mini project.


  • Activate ALE Change Pointers Generally (Transaction code- BD61)

          This configuration is a prerequisite for transferring master data changes with change pointers.

            /wp-content/uploads/2015/01/16_629520.jpg


  • Activate ALE Change Pointers per Message Type

          The following change pointers are important to be activated e.g. Vendor master, Customer master, Set-up group and Source of supply, material           MRP area, Subcontracting PDS.

/wp-content/uploads/2015/01/17_629521.jpg


Note: – Activation of change pointer is only needed if the corresponding master data is used in system.


  • Activate online Transfer Using BTE (Transaction code- BF11)
    • We activate BTE for the integration with SAP APO in order to activate the online transfer of both transaction data changes and some master data changes like Material master and Resource. We Set the ND-APO (New Dimension Plug-In APO) and NDI (New Dimension Integration) application indicators to active.

/wp-content/uploads/2015/01/18_629528.jpg

              Note: – This is not the default setting; hence make sure both the above mentioned indicators are set.


  • QIN Scheduler (Transaction code- SMQR)
    • When APO sends the planning results to the connected ECC system, it generates the CIF queues in the inbound of the ECC system as per the configuration. Those inbound Queues that are to be automatically processed by the target system must be registered in the QIN scheduler.
    • The below settings used for QIN scheduler worked for most of the clients. Changes can be done based upon the queue processing.

/wp-content/uploads/2015/01/19_629529.jpg


  • QOUT Scheduler (Transaction code- SMQS)
    • Outbound qRFCs (outbound queues) are processed by the QOUT scheduler. The QOUT scheduler is configured using transaction code SMQS. The targets system to which the outbound qRFCs are to be sent are registered in the QOUT scheduler.
    • The below settings used for QOUT scheduler worked for most of the clients. Changes can be done based upon the queue processing.

/wp-content/uploads/2015/01/20_629530.jpg



5.2.    Configuration in SCM APO System

      • Define Logical System (Transaction code- BD54)

We defined logical system for both ECC and APO system. To enable the transfer of data via APO Core Interface (CIF), you need to name both the ERP system in which you are working and the SAP APO system to which you want to transfer data as logical systems.

/wp-content/uploads/2015/01/21_629559.jpg


              Note: – The above activity is dependent upon the target system concerned. For this reason, there is no transport to the production system. As a                     result, you need to also make the settings for the relevant target system in the production system manually, Or

Alternatively, you can maintain the all of the logical system name (as per SAP system landscape) in Development client and include them in a transport. This will make all the logical system available across ECC system landscape & minimize the manual activities.

  • Assign logical system to the Client (Transaction code- SCC4)

In this step, assign the logical system to a client. All the fields like City, Std. currency, logical system should be maintained. Otherwise there will be some futile CIF error during the data transfer from ECC to APO.

/wp-content/uploads/2015/01/22_629545.jpg

Note: – These settings cannot be transported. When a new system is being set up, these settings must be made after the system installation has been completed.

  • Setup RFC Destination (Transaction code-SM59)

In this step, create the RFC destination which has the same name as the target logical system. This RFC enables the connection to the ECC system.

/wp-content/uploads/2015/01/23_629579.jpg

Performance Tip: – By activating the load balancing & defining the logon group, you can use the load balancing procedure while connecting to the ECC system. This logon group needs to be assigned to the various servers in transaction code RZ12.

/wp-content/uploads/2015/01/24_629580.jpg

When APO is connected to ECC system it always uses ALEREMOTE user in order to process any CIF queues.

  • Assign RFC Destinations to Various Application Cases (Transaction code- SPRO)
    • You assign various application areas to the logical system and the RFC destination. This is optional configuration & purely depends on the business requirement & guidelines for the type of RFC user to be used for security reasons. Some of the applications only work with RFC dialog user e.g. display application log from APO into ECC system, but from security point of view, most of the clients e.g. life science, FMCG doesn’t allow to create the RFC user as dialog user which can be misused.
    • To meet the business requirement, there is a need to create a new RFC destination with different RFC user of type either Dialog or Service user with very limited & restricted authorization. The authorization has to be provided for the type of application to be use. So that while accessing the data from the target system through a Remote function call, the system will use the specified RFC destination specified in the configuration of “Assign RFC destinations to various Application cases”.

              /wp-content/uploads/2015/01/25_629581.jpg


  • Maintain Business System Group (Transaction code- /SAPAPO/C1)
    • This configuration determines the assignment to a business system group of this system and the respective ECC systems that are to be connected.
    • If this APO system is connected with multiple ECC system using the same number range of material master, plant, vendor & customer master, then we need to define multiple BSG groups to bring master data from each system.

/wp-content/uploads/2015/01/26_629597.jpg

  • Assign Logical system to Business System Group (Transaction code- /SAPAPO/C2)

In this step, to enable error-free communication, every source system (ERP system) must be assigned to a BSG. We assign the logical system to the BSG group & the queue type.

Here, we have also activated the CIF post processing functionality for CIF error handling of transaction data.

/wp-content/uploads/2015/01/27_629598.jpg

Note: – It is recommended to use the Inbound Queues if transferring a large amount of data to the ERP system to ensure an even load on the ERP system. Ensure to maintain settings for the Queue-In (QIN) Scheduler in the qRFC monitor on the ERP side.

  • Set User Parameter (Transaction code- /SAPAPO/C4)

In this IMG activity, you can make user-specific entries for the following parameters:

    • You can use this to set whether and how data records should be logged in the application log for the user specified.
    • User can use this functionality to debug in case of any queues get created for that user. Any master data or transactional date created by that user will be stuck in the CIF queue which the user can debug and analyze the issue.
    • Here, you should maintain entry for user name as “*” for normal or detailed logging of the application log.
    • RFC user should be maintained with the normal logging.
    • CIF administrator id should be maintained for detailed logging along with Debugging mode “ON”.

              /wp-content/uploads/2015/01/28_629599.jpg


  • QIN Scheduler (Transaction code- SMQR)
    • When ECC sends the master and transaction data to the connected ECC system, it generates the CIF queues in the inbound of the APO system as per the configuration. Those inbound Queues that are to be automatically processed by the target system must be registered in the QIN scheduler.
    • The below settings used for QIN scheduler worked for most of the clients. Changes can be done based upon the queue processing.

              /wp-content/uploads/2015/01/29_629606.jpg

  • QOUT Scheduler (Transaction code- SMQS)
    • Outbound qRFCs (outbound queues) are processed by the QOUT scheduler. The QOUT scheduler is configured using transaction code SMQS. The targets system to which the outbound qRFCs are to be sent are registered in the QOUT scheduler.
    • The below settings used for QOUT scheduler worked for most of the clients. Changes can be done based upon the queue processing.

          /wp-content/uploads/2015/01/30_629608.jpg

  • Maintain Distribution Definition (Publication) (Transaction code- /SAPAPO/CP1)

In order to publish the planning results from APO system to ECC system, we have maintained all the publication types for the required locations forwhich we wanted to publish the order to ECC system. This is maintained for both in-house and external procurement.

              /wp-content/uploads/2015/01/31_629630.jpg

                  Note: – If the distribution definitions are not maintained then the planning results will not transfer back to the connected ERP system. The data                     inconsistency between ECC & APO system will even not be captured in CCR report.


5.4.  qRFC queue names for CIF

        QRFC queue names for the CIF are always set up according to the following rules:

        CF<CIF object ID><serialization character string>

        The CIF objects that are transferred from an ERP system to the APO system are listed below:

CIF object

ID

Serialization Character string

Batch

BTC

CHARG+(10) + MATNR+(9)

Resources

CAPA

NAME+(18)

Characteristic

CHR

ATNAM+(19)

Class

CLA

KLART+(3) + CLASS+(16)

Inspection lot

LOT

PRUEFLOS+(17)

Material master

MAT

WERKS+(4) + MATNR+(14)

Planned order

PLO

ORDNR+(12)

Confirmation

PPC

ORDERNR

Reservation

RSV

ORDNR+(12)

Purchase order

PO

DOC+(10)

Purchase Requisition

PO

DOC+(10)

The CIF objects that are transferred to an ERP system from SAP APO are listed below:

CIF object

ID

Serialization Character string

Delivery confirmation

CD

ORDERNO

Confirmation

CF

GUID or ORDERNO

VMI Sales order

CO

ORDERNO

Delivery

DLV

001

Purchase requisition

EP

GUID or ORDERNO

Purchase order

EP

GUID or ORDERNO

Planned order

IP

GUID or ORDERNO

Process/Production Order

IP

GUID or ORDERNO

Production campaign

PC

GUID or ORDERNO

  1. Man. Reservation

RV

GUID or ORDERNO

Shipment

SHP

001

Stock transport order

TO

GUID or ORDERNO

5.4.  CIF Interface Configuration Checklist

          Below is the CIF configuration checklist or tracker which can be maintained to monitor the CIF configuration in ECC & APO system          simultaneously. This will avoid any configuration to get missed.


  1. S.no

Configuration Nodes

APO

APO Status

ECC

ECC Status

1

Name Logical System

Basis

Completed

Basis

Completed

2

Assign Logical System to a Client

Basis

Completed

Basis

Completed

3

Specify SAP APO Release

NA

NA

Basis/Functional

Completed

4

Create RFC User

Basis

Completed

Basis

Completed

5

Set Up RFC Destination

Basis

Completed

Basis

Completed

6

Set Target System and Queue Type

CIF Functional

Completed

CIF Functional

Completed

7

Set User Parameters

Basis/CIF Functional

Completed

Basis/CIF Functional

Completed

8

Configure Application Log

CIF Functional

Not Started

CIF Functional

No Change

9

Determine Number Ranges for Parallelization

NA

NA

Basis

No Change

10

Set Filter and Selection Block Size

No Change

No Change

No Change

No Change

11

Configure Change Transfer for Master Data

NA

NA

CIF Functional

Completed

12

Activate ALE Change Pointers Generally

NA

NA

CIF Functional

Not Started

13

Activate ALE Change Pointers for Message Types

NA

NA

CIF Functional

Not Started

14

Activate Online Transfer Using BTE

NA

NA

CIF Functional

Completed

16

Activate Cross-System Update Logic

NA

NA

CIF Functional

Completed

17

Maintain Business System Group

CIF Functional

Completed

NA

NA

18

Assign Logical System and Queue Type

CIF Functional

Completed

NA

NA

19

Maintain Object-Specific Settings

CIF Functional

Not Started

NA

NA

20

Maintain Publication Settings

CIF Functional

Not Started

NA

NA

  1. S.no

Activities

APO

APO Status

ECC

ECC Status

1

Setup Outbound scheduler

Basis

Completed

Basis

Completed

2

Setup Inbound scheduler

Basis

NA

Basis

NA

3

Activate outbound scheduler for CIF

Functional

Completed

Functional

Completed

4

Activate Inbound scheduler for CIF

Functional

NA

Functional

NA

5

Create Integration model

NA

NA

Functional

Completed

6

Activate Integration model

NA

NA

Functional

Completed

7

Maintain Publication Settings (After Master Data transfer)

Functional

Completed

NA

6. Integration of Master data and Transactional data (Design of Integration Models)

The integration model controls the transfer of master data and transaction data. It is generated in the ERP system and contains all data that is to be transferred to the SCM system. It is uniquely identified by name and application. There are 2 steps in integration models

  • Create & Generate Integration models (Transaction code- CFM1)

          When you generate an integration model, you specify which data objects are to be selected from the total dataset in the ERP system for the                    transfer. To create the integration model, follow the below steps:

    • First select the object types (for example, material masters) to be selected on the Create Integration Model selection screen.
    • Next, you select specific selection criteria (in most cases, a material/plant combination) that further restrict the object types you have already selected. If you have already selected Material Masters, for example, you could now enter an MRP controller. In this way, you define filter objects
    • . Filter objects are used to select which data objects are transferred to a specified SCM system. In the example, all material masters for a particular MRP controller are selected.
  • Activate Integration model (Transaction code- CFM2)
    • The activation of integration models results in an initial transfer. If you work with SAP APO, the online transfer of transaction data is released.
    • As standard, the integration models to be activated are compared with the integration models that are already active. You can generate multiple integration models. However, only one version can be activated for each model at a time.
    • You can activate and deactivate several integration models simultaneously.
    • Integration models must remain active to enable online transfer.
    • Activation of master or transaction data integration model should be followed a logical sequence & recommended to grouped as below

      • ATP Customizing, Setup groups (group/key) and product allocation
      • Plants & distribution centers
      • Change master records
      • Class & characteristics
      • Material master (+ classes, characteristic)
      • Batches
      • MRP area and material master for MRP areas
      • Planning Products
      • Materials for GATP check
      • Product allocation
      • Vendors
      • Customers
      • Work Centers
      • Production data structure
      • Purchase Info Record, scheduling agreement, contracts

Note: – Normally, there are some challenges to generate & activate the material dependent integration model for master & transaction data during initial transfer, when the master data objects to be transferred are huge. In that case we need to do some work to design the integration model to have the optimum no of data objects per IM.

The critical data objects are:

  • Material master
  • Purchase Info record/source list
  • Sales Orders
  • Stocks
  • Batches

The following are the recommendations which can be used to do the initial data transfer successfully.

  • Split the material master integration model  by either material type / MRP controller/ material master number range or in combinations
  • If the data split is not feasible then add data objects in the sequential manner. It means, first create & activate the IM for e.g. material type FERT. Next time, add some more material type in the same variant & activate it. This way, there will not be heavy load on the system at a time & it will be distributed over multiple IM transfer.


6.1. Data Flow between ECC to APO & its Frequency

    • Master Data flow from SAP (ECC) –> APO

Master Data

Daily Batch Job- Once in a Day

Manually

Plant

No

Periodic, Need basis

Vendor, Customer

Yes; Create new, Change existing

Need basis

Material

Yes; Create new, Change existing

Need basis

Info Record

Yes; Create new, Change existing

Need basis

PDS

Yes; Create new, Change existing

Need basis

    • Transaction Data Flow SAP (ECC) –> APO

Transactional Data

Daily Batch Job- Once in a Day

Real Time

Purchase Requisition’s

Yes; Activate IM for new APO relevant materials

Create, Change

Inspection lot

Yes; Activate IM for new APO relevant materials

Create, Change

Purchase Orders

Yes; Activate IM for new APO relevant materials

Create, Change

Stocks

Yes; Activate IM for new APO relevant materials

Create, Change

Stock Transfer Orders

Yes; Activate IM for new APO relevant materials

Create, Change

Sales Orders

Yes; Activate IM for new APO relevant materials

Create, Change

          Note: – The above mentioned data flow frequency from ECC to APO is just a recommendation based on various project experiences. Still, these can           vary from project to project depends on business requirements    .


6.2. Publication of procurement proposal from APO to ECC (Transaction code- /SAPAPO/C5)

    Transactional Data can be transferred from APO to ECC in two ways

  • Periodically – it is recommended to use the periodic transfer of SNP planning result to ECC. It improves system performance, locking issues, & time to review & correct the planning results before publishing to ECC.
  • Immediately/Real Time – This ensures real time data transfer and better consistency between APO & ECC. It is recommended to use this method for short term planning method e.g. PP/DS, CTM.

———Contd… PART-2———————————————————————————————————————————————————————–

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply