Cif Post processing

What is it ?
Error handling Faulty queues no longer lead to queue blocks CIF Post processing is mainly used to avoid stoppage of business transactions. The faulty queues can be saved and actions like corrective and preventive actions can be taken for those queues by correcting master data or transactional data at our own convenience via cif post processing. CIF post processing will automatically delete errors from the queue and we can process them later. This is only applies for Transactional data. Generate CIF post processing alerts in system via /SAPAPO/CPPA - CIF Error Handling: Alert which can be mapped to send mails to the users to take actions. transaction /sapapo/cpp1. The times for post processing records are given in UTC.

Advantages
In the Queue manager ( CQ) you see the faulty Ques which can be deleted. The logs are maintained in CPP. You can delete the Que from SCM Queue manager, but the logs will be there in CPP. In CPP, we can delete the Que which will allow other ques to clear. Than we can go back to the Product for which Que has stuck, correct the master data for example and again send data from APO to ECC using CPP.

In CPP you will have all these entries for multiple times, so you can also obsolete the old entries once you fix the issue and transfer the data correctly.
CCR : does the reconciliation online and give you the inconsistencies to be corrected & CPP just store all these inconsistencies from the past. If CIF error handling is active, you first check whether postprocessing records exist, then call the SCM queue manager, and then the CIF comparison/reconciliation of transaction data.

Prerequisites
Check with your basis team whether all RFC settings and target system settings are perfect CIF error handling is connected to authorization object C_APO_CFPP. An authorization profile with the relevant settings must be assigned to this authorization object for the user.Wecan use this object to specify authorization for displaying, processing, or deleting post processing records within CIF error handling Check under the menu scm basis menu, integration > monitor > application log > activate logging is done check in /SAPAPO/C2 have you assigned the both Logical systems ..

1) R/3 Logical system, R/3 flag X, R/3 release (ex: 50 for ECC-5.0) Based on the size Inbound or Out bound Queue error Handling 1 Postprocessing for Errors, No Splitting of LUWs and role not specified. 2) APO logicasystem R/3 flag blank, APO release (ex: 41 for SCM-4.1) Based on the size Inbound or Out bound Queue error Handling 1 Postprocessing for Errors, No Splitting of LUWs and role not specified.

Prerequisites
We have to decide queue processing is controlled by the receiving system (SAP R/3) or sending APO system

We have to decide : Default block size is 100 orders. Block size may have been altered to a different value in your system.

Error Handling
CIF error handling ensures that all CIF queue entries are processed during the data transfer. Faulty queues no longer lead to queue blocks. Instead, they are logged in postprocessing records in the relevant target system for the data transfer. You can then call these postprocessing records at a later point in time in CIF Postprocessing. Once the error has been corrected you can then send the objects to the relevant target system again Postprocessing, No Splitting of LUWs is set in the Error Handling column in SAP APO Customizing under Basic Settings Integration Business System Group Assign Logical System and Queue Type (transaction /SAPAPO/C2). The standard setting is Strict (that is, CIF error handling is not active as standard).

Restrictions
restrictions to CIF error handling when using certain applications and functions in SAP Note 602484. CIF error handling is not available in the following situations, which means that CIF queues hang when errors occur: At the initial data transfer At the transfer of master data (initial and change transfer) At short dumps or when liveCache is unavailable When the target system is unavailable When an object is locked in the target system (as before for the repetition of the transfer) If errors occur in customer exits or BAdIs that run in CIF inbound function modules during integration When posting terminates in SAP R/3 inbound. If posting terminates in SAP R/3 when transfers are being made from SAP APO to SAP R/3, the CIF queues are processed as before and they are no longer displayed in the queue monitor. Processing by CIF is already complete by the time the data is posted in SAP R/3. Therefore, CIF error handling does not take into account terminations in posting in SAP R/3 and does not generate any post processing records.

Additional functionality surrounding it

Default block size is 100 orders. Block size may have been altered to a different value in your system. /SAPAPO/CP3 To avoid such problems, you have several choices. You can decide to collect changes, and then publish planning results to ERP periodically instead of directly. /SAPAPO/C4 http://help.sap.com/saphelp_scm70/helpdata/EN/ab/4f6c39c71c0324e10000000 a114084/frameset.htm Or, you can decide to turn on Error Handling. /SAPAPO/C2 http://help.sap.com/saphelp_scm70/helpdata/EN/f4/85ece6da3ba745b595c194c 52903f5/frameset.htm Or, you can just monitor the queues more frequently. For an established system, with well controlled master data, and direct publishing of planning, I generally reduce my monitoring to once a day. For newer implementations, or systems with inconsistent master data, I will monitor more frequently, until the underlying problems have been managed.

Sap notes
954354 1342776