CIF Voodoo – Mastering the Dark Art of APO Integration

For those of you that have worked with the CIF in APO, you know that at times it can seem like someone (or something) has put a powerful Curse on both you and your system.  Try as you may, you just can’t seem to get out from under its spell, and anything short of a Witch Doctor stuffing a Voodoo Doll of Hasso in the server is going the reverse the hex and get the data moving again.    We’ve been there, and although it sometimes it seems like the Dark Arts are running amok in your system, the reality is that a bit of housekeeping and a few “magic” transactions will help demystify the CIF and restore your faith in technology.

Monitoring Activities

To keep up the continuous and almost real-time data transfer between the APO and the connected R/3 OLTP system(s), several jobs must be scheduled to run regularly and some monitor activities must occur on an ongoing basis.

Jobs Necessary to Ensure Data Transfer (R/3)

Generate and activate integration models with reports RIMODGEN and RIMODAC2, respectively. These reports can be scheduled in two steps of a single job.  They must run for those integration models that include master data as well as for those containing transactional data (which should be separated from each other).

Usually, new transactional data, for example: orders or stocks, are transferred automatically to APO without running a job, provided there is an active integration model for this type of data with selection criteria that match the respective material. However, to include new orders for new materials (so-called delta supply), the respective integration models must be generated and activated. These reports also must run in order to ensure the delta supply for new master data records themselves.

Detect and correct inconsistencies between material master and integration models with report RAPOKZFX. In rare cases, inconsistencies can occur between data in integration models and field APOKZ in table MARC. They may occur if you activate a model that refers to a material master that is being changed at the same time. In this case, the activation is finished successfully but the APOKZ is not set correctly, and an error message is displayed. The inconsistency can result in an error during the ATP check and when transferring production and planned orders.

Report RCIFIMAX should be scheduled regularly to find inconsistencies between the integration model sources and their run-time versions. The user creates the runtime version once by using the RCIFIMAX report and then it is automatically updated by the system every time an integration model is activated.  This report must not be run in parallel with activations of integration models.

Compared to the CIF_IMOD database table, the runtime version offers the following advantages:

  • Improved performance because only object data for a specific object type needs to be loaded for an integration model
  • As a result, database accesses that reduce performance are not needed for online transfer and the target system can be determined faster. Also, the performance for online transfer is not linked to the number of active integration models when the runtime version is used.
  • Improved usability because integration model construction now only has a small influence on performance. The speed at which the runtime version is generated depends on the number of integration models.

If you cannot rule out that, during a planning run like SNP heuristic, CTM run or PP/DS scheduling, data will be transferred from an SAP R/3 system to the SAP APO system (or from APO to R/3) over the CIF, you can lock inbound or outbound queues in the SAP R/3 system from the SAP APO system.   This should prevent inconsistencies occurring in the planning and / or locking problems during the planning run. To lock outbound queues, you can use the /SAPAPO/CIFSTOPQUEUES and  /SAPAPO/CIFSTARTQUEUES reports in SAP APO.


Jobs Necessary to Detect and Analyze Problems in the Data Transfer (APO)

qRFC-Alert with report /SAPAPO/RCIFQUEUECHECK. Sends a mail to the selected recipient, if one of the given local (outbound APO system) or remote (outbound of one of the connected R/3 systems) queues is in error. Normally, the recipient should be the responsible administrator located in the software monitoring team. In the case of the local system, it can also be the user who entered the object in error, except for user IDs used by the RFC connection or where technical errors occur that cannot be solved by users in a business department.

If you have activated qRFC inbound queues, run qRFC-Alert with report /SAPAPO/RCIFINQUEUECHECK. This works in the same way as the report /SAPAPO/RCIFQUEUECHECK mentioned above but is for inbound queues of APO and connected R/3 systems.


Valid from SCM 4.0:

If CIF error handling is activated, run CIF post-processing alert with report  /SAPAPO/CIF_POSTPROC_ALERT to check whether post-processing records were generated during CIF error handling. When errors occur, this report sends a message to the system administrator or the initiator of the error to allow rapid error correction via CIF Post-processing (transaction code /SAPAPO/CPPA).

Detect and correct external inconsistencies between APO and R/3 with report /SAPAPO/CIF_DELTAREPORT3 (transaction /SAPAPO/CCR). To ensure that all relevant transaction data objects (such as purchase, production or sales orders, and stocks) for which there are active integration models exist in both APO and R/3, this report should be scheduled to run:

  • Periodically, and preferably daily, to detect and reconcile possible inconsistencies as soon as possible. This is important because otherwise further inconsistencies can be generated and cause subsequent planning to be based on incorrect data.
  • In case a recovery of your liveCache or your APO database had to be executed, but was incomplete (point-in-time recovery, loss of data…)
  • In case you have evidence of inconsistencies between your APO and your R/3 OLTP system
  • In case queue entries have been deleted erroneously or background jobs with data transfer have ended with an error.

This report cannot be used for regular data supply of the APO system. It may run for several hours. This depends on the data volume in your system and the number of objects selected for comparison. To reduce the overall runtime, it can be run in parallel with disjoint selections of objects. This is recommended if you encounter high runtimes with a single run selecting all relevant objects. The degree of parallelization that is possible depends on the system resources available.

In background mode, the check for inconsistencies is executed without automatic error correction. Therefore, if the background run detects an inconsistency, call APO transaction /SAPAPO/CCR, execute it with the same selections as in background mode, and then browse, evaluate, and possibly correct the error by executing the send object function.

As of APO release 4.0, it is possible to save the results of a /SAPAPO/CIF_DELTAREPORT3 run (dialogue as well as background processing), and to later re-load and process these results. Therefore it is possible, for instance, to run the program in the background during the night, load the results in the morning and reconcile the inconsistencies found with dialogue interaction.

In addition to the check of existence of orders as done by the previous versions of this report,  /SAPAPO/CIF_DELTAREPORT3 also checks some (but not all) attributes e.g. header quantity, position quantities, and dates.

As of SAP SCM release 4.0 there are some new features in /SAPAPO/CIF_DELTAREPORT3:

  • New objects quality inspection lots and planned independent requirements are checked by the report.
  • As of SAP R/3 Enterprise (core release 4.70) with R/3 Plug-in 2003.1 or add-on  Discrete Industries Mill Products (DIMP) 4.71 (and newer), scheduling agreements (SD) are also checked.
  • As of SAP R/3 Enterprise (core release 4.70), work packages for APO Maintenance and Service Planning are checked.
  • There is a new indicator for comparing receipts and requirements as well as operations for production and process orders in SAP R/3 and SAP APO.

As of SAP SCM release 4.1 there are the following new features available in  /SAPAPO/CIF_DELTAREPORT3:

  • As of SAP R/3 Release 4.6C, project orders and maintenance orders are also checked.
  • It is possible to compare configuration data of orders in R/3 and AP

The extended configuration check (content of the configuration data is the same in

R/3 and APO) is selectable as additional option. If this option is not chosen, the simple configuration check is executed (the same configuration data is referred to in the order) for the desired orders.

Beside general performance improvements provided within SCM 4.1, parallel processing profiles can be maintained for the data access in the CIF Delta report for both systems – SAP R/3 and SCM (customizing path or transaction code /SAPAPO/CCR_PAR). The parallel selection of data works block wise via RFC based on material/plant combinations and has to be maintained in the selection screen of CIF Delta report (variant). Parallel profiles are applicable to documents (not stocks) and improves performance significantly. The functionality was down-ported from SCM 5.0 to be available as of SCM 4.1 SP 5.


For more information, watch the on-demand webinar recording: Core Interface: Key Understandings: From Implementation to Troubleshooting.

Share the knowledge

Share on linkedin
Share on twitter
Share on facebook
Share on email

Fresh supply chain knowledge delivered straight to your inbox

By signing up you agree to receive our quarterly newsletter

Don't Miss our next Webinar!


Thurs., Sept. 26  ||  11AM-12PM CST
Share on linkedin
Share on twitter
Share on facebook
Share on email