7. CIF Error Handling and Queue Management
Here we choose the error handling method as Post-processing of errors. No splitting of LUW in order to activate the post-processing of the logical systems.
If you are transferring a large amount of data from SAP APO to SAP R/3, and you want to be ensure that an even system load is placed on SAP R/3, choose Inbound Queues.
Since we choose Inbound Queues in SAP APO, We did the necessary settings for the QIN Scheduler (Queue-In Scheduler) in the qRFC monitor in SAP R/3(As explained above). Queues that are to be processed automatically by SAP R/3 must be registered in the QIN Scheduler.
7.2. CIF Error Handling (Post Processing)
This functionality in APO will allow the CIF user to see all the logged CIF error messages centrally in APO. This process is independent of the queue type (inbound or outbound) and CIF errors in both the system (ECC and APO) can be handled from this one transaction in APO.
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 post processing records in the relevant target system for the data transfer. You can then call these post processing records at a later point in time in CIF Post processing. Once the error has been corrected you can then send the objects to the relevant target system again.
If a change to transaction data cannot be posted in the target system due to an error, the system creates a post processing record with the error status Faulty for the object concerned.
CIF error handling is not available in the following situations, which means that CIF queues hang when errors occur:
You can find information about restrictions to CIF error handling when using certain applications and functions in SAP Note 602484.
Since not all errors are included in CIF error handling, faulty queue entries may continue to exist once CIF error handling has been activated. Faulty queue entries can also block objects that are resent by CIF post processing. Therefore, you still need to monitor CIF queues by using the qRFC monitors for inbound or outbound queues, or by using the SCM Queue Manager.
7.3. Queue Management
As mentioned in the restrictions of CIF post processing, all the errors did not get captured in the CIF post processing. We still need to monitor the CIF queues.
Transactions to check for Errors (R/3 and APO)
SMQ1 - qRFC Monitor (Outbound Queue)
SMQ2 - qRFC Monitor (Inbound Queue)
Note: The indicator for expand mode is performance incentive. The Transaction will take little bit longer time if you set this indicator.
Note:
Sometime the error message does not provide the detail information like product, location etc. The additional detail information can be seen in the CIF application log. Please proceed as following:
> In APO: Double click on the CIF error message within the CIF entry(Transaction SMQ2 and SMQ1) or execute transaction : /n/SAPAPO/C3
> In R/3:
In order to get the details of the Error message:
Transaction in R/3: CFG1 - Display CIF Application Log
It will give the details of the error message displayed in the SMQ2 or SMQ1 transaction.
There are various challenges which CIF admin or functional consultants will encounter while integrating the ECC & APO systems. Based on various project experiences, the following are some of the issues which are encountered.
If you are using the inbound queues both in ECC & APO system, then you might get into this issue.
When the data is transferred from ECC to APO the data is not visible in APO. Similarly, when the planning results from APO are transferred to ECC, the results are not visible in ECC & not returned to APO with ECC order number range. This is applicable for master & transaction data, both.
All the transferred data will be blocked in CIF inbound queue (SMQ2) with “Ready” status & you need to manually activate each LUW individually. This may take long time to clear all the queues
These queues will not be displayed in CIF queue manager (/SAPAPO/CQ). If you will run the reconciliation report (/SAPAPO/CCR) report, the differences between ECC & APO changes will reflect. But if will again transfer the differences from CCR report then it will again add one more record in the APO inbound. So it is always recommended to check the CIF blocks, clear them & then use the CCR for reconciliation.
.
Root Cause: - This issue mainly pops up when the inbound schedulers are either not registered in SMQR or if registered but inactive (Type= “U”, it should be “R”) in ECC & APO system.
Example: - Inbound scheduler is registered but inactive (Type-U) in APO.
You have made some changes in the existing purchase requisition in ECC & saved. This change should transfer to APO immediately. But when you look into APO, the changes are not reflecting.
The changes are blocked in the APO inbound with “Ready” status & need manual intervention to clear them
8.2. Master & Transaction Data change transfer to APO is not real time
This issue is applicable for all type of transaction data & only those master data objects which are configured as immediate transfer, e.g. material master, vendor & customer master, resource.
When there are any changes in the existing master data objects or transaction data which are integrated with APO & part of active integration model, still the changes are not reflecting in APO. You will not find any queue blocks for these changes. If you will run the reconciliation report in APO for transaction data consistency check (/SAPAPO/CCR), you will not find any record with differences. These changes will transfer to APO when the CIF job will run for respective integration model.
Root Cause: - This issue mainly pops up when you have not activated the online transfer using business transaction events for application “ND-APO” & NDI.
For master data, you can additionally check the “change pointers” are active or not, for the message type for the objects mentioned above.
8.3 Change pointers for master data changes are not recorded
This issue is applicable for all type of master data objects which are relevant to APO planning.
When there are any changes in the existing master data objects which are integrated with APO & part of active integration model, still the changes are not reflecting in APO. You will not find any CIF queue blocks for these changes. These changes will not even transfer to APO when the CIF job will run for respective integration model.
If you will check the table BDCP & BDCPS (for change pointer), you will not find the change pointer that you are looking for.
Root Cause: - This issue mainly pops up when you have not activated the “ALE change pointers” globally in the transaction code BD61, or the change pointer for specific message type for the master data object in the transaction code BD50 shown below.
8.4 Master Data Changes are not getting transferred to APO
This issue is applicable for all type of master data objects which are relevant to APO planning.
When there are any changes in the existing master data objects which are integrated with APO & part of active integration model, still the changes are not reflecting in APO. You will not find any CIF queue blocks for these changes. These changes will not even transfer to APO when the CIF job will run for respective integration model.
You have checked that the master the change pointers are active globally & for all the required master data message types.
Root Cause: - This issue mainly pops up when you have multiple integration models active for the same object. You should check the active integration model for the master data object by using the transaction code- CFM5 in ECC.
Conclusion: - you should have only one active integration model for any unique master data object.
8.5 Custom field value change in material master is not triggering change transfer to APO
This issue is applicable for all type of master data objects which are relevant to APO planning and enhanced by adding Z custom fields.
When there are any changes in the Z custom field value (Enhanced master data objects with Z fields relevant to APO planning) in the existing master data objects, the changes are not recorded & transferred to APO. The objects are integrated with APO & part of active integration model. There are no CIF queue blocks for these changes. These changes will only transfer to APO when there is an initial transfer for the respective master data objects.
You have checked that the change pointers are active globally (T.code-BD61) & for all the required master data message types (T.code-BD50).
Root Cause: - This issue mainly pops up when there is Z custom fields added in the APO relevant master data object but these tables & fields are not added in the transaction code BD62 for the specific message type.
Conclusion: - All fields of the required master data objects should be maintained in the transaction code- BD62, which should trigger the change transfer upon any change in ECC.
8.6 APO orders are not getting transferred from APO to ECC
This issue is only applicable to the transaction data which are planned in APO & to be sending back to ECC system.
Planning run has created procurement proposals in APO. These procurement proposals have to be send back to ECC. The new or changed proposals are not reflecting in ECC system. The transaction data is integrated with APO & part of active integration model. There are no CIF queue blocks for these changes. These changes are not reflecting even in the reconciliation report (/SAPAPO/CCR).
You have checked that the all the basic CIF configuration is maintained.
Root Cause: - This issue mainly pops up when the publication definition have not been maintained for the Plant & ECC logical system combination in APO. /SAPAPO/CP1
8.7 Poor performance of CIF background job
8.8 Common configuration objects are not in sync between ECC & APO
There are various common configuration objects in ECC & APO which should in sync. This is one of the prerequisites before you initiate the master data transfer from ECC to APO. If the configuration is not in sync (object missing in APO) then there will be initial error in CIF data transfer.
Some of the common configuration objects are:
Root cause: Standard configuration has been changed in ECC for the UOM, Calendars, or new configuration objects have been added. These changes must be updated in APO.
Solution: - you can update the UOM, Currency & Calendars using the RSA1 transaction if the connected ECC system is created & active under the SAP source systems. You can use the “Transfer global settings” from the context.
For other configuration object, either compares and maintains it manually, if missing, or use the compare tool under the Utility menu bar to compare the objects from concerned ECC system & update all differences in one shot.
9. CIF Housekeeping Job
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
As of R/3 Plug-In 2002.1, report RCIFIMAX should be scheduled regularly to find Inconsistencies between the integration model sources and their runtime versions. This report must not be run in parallel with activations of integration models.
You can activate qRFC queues using the reports RSQOWKEX (outbound queues) and RSQIWKEX (inbound queues). In normal operation, however, it is not necessary to run these programs regularly because almost all queue entries are processed without errors. In case of queue errors, these should be detected by the procedures described below, and analyzed and corrected accordingly. The error analysis should suggest preventive measures to reduce the number of future exceptions. In exceptional cases, or, for example, on test systems, you can use reports RSQOWKEX and RSQIWKEX. If you start these reports at an inappropriate time or with too many queues selected, they may cause an excessive additional system load.
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:
Internal consistency between APO DB and live-Cache is checked by transaction /SAPAPO/OM17. If it is necessary to reconcile the internal consistency, for example in case of a recovery, we recommend doing this first before checking and reconciling external consistency.
10. Performance Optimization Job
To optimize the performance of the data transfer between the APO and the connected R/3 OLTP system(s) and to prevent accumulation of useless data in the systems, several reorganization jobs must be scheduled to run regularly.
a) Deleting change pointers may cause inconsistencies, as the corresponding order changes are not transferred to R/3.
In SAP APO database tables, the tables expand with data from SAP R/3 documents. However, this data is no longer required; no corresponding information exists in liveCache. In addition, the performance of the initial data supply or of other transfer processes with a high data volume is affected negatively. The obsolete records need to be deleted regularly to control the size of certain tables (e.g. /SAPAPO/SDFIELD and /SAPAPO/POSMAPN) and to improve the performance of the Sales order updates on SAP APO side. For details, see SAP Note 504620.\
11. Real CIF Error encountered in various project
Cause:- There is no internal number range maintained for purchase requisition document type “NB”.
Solution:- Create pur req no range in ECC & enter it into the Document types under purchasingàPur Req for type NB “internal no rng”
Cause:- Purchasing Group is not maintained in ECC system for the given material.
Solution:- Maintain the Purchasing group in the material master & reactivate the queue.
Cause:-The planning calendar validity is ending in 2010 while the orders dates are lying in 2013.
Solution:- Extend the planning calendar.
Cause: The Production supply area has not maintained in the resource or in the BOM. System first picks the Prod Supply area from the resource master & if that is not maintained in the Resource then it will look in the BOM component.
This is used if the Warehouse management is active.
Note:- In the SPRO (Log Exe:--Wh mgmt àinterfaceàdefine production) production supply area is maintained or use trxn code OMK0.
Solution:-Maintain the Production supply area & should be assign to the Resource (for the master recipe for which component is assigned) or assign directly to the BOM component. Ensure that the storage location assigned in the Production supply area for a component should be assigned in the MMSC trxn.
Cause: The Backflush indicator in the material master is “1” always backflush. While the valuation class in the material master is WIPS – WIP inventory stock.
Hence while converting planned order into process order system reads the accounting view data to calculate the cost & determine the accounts using the valuation class. That time system is giving the CIF error.
Note:- The Qty & value updating field in the material type config is not relevant to this error.
Solution:-Either changes the Valuation class in the accounting view of material master or else change the back flush indicator from 1 to blank.
Cause:
Process Order directly created in ECC system & sent to APO. In ECC Master Recipe is created but the production version is not created & also not CIFed to APO. Hence the error occurred.
Note: - Following observations:-
Resolution:-Create the Production version in ECC & send it to APO.
Solution:-
Here please make sure that
12. CIF- Important T-codes
R/3: | |
Transaction code | Description |
CFM1 | Create integration model |
CFM2 | Activate/deactivate integration models |
CFG1 | View CIF application log |
CFC2 | User parameters for CIF |
CFC3 | Block sizes for initial transfer |
CFM5 | Filter object search in integration models |
CFC1 | Define logical systems as APO systems |
NDV2 | Setting of release level of APO systems |
SMQ1/SMQ2 | qRFC monitor incl. functions start, stop, execute |
SM59 | Definition of RFC destinations |
SALE | Definition of logical systems |
APO: | |
Transaction code | Description |
/SAPAPO/C3 | View CIF application log |
/SAPAPO/C4 | Setting of user parameters CIF |
/SAPAPO/C5 | Send planning results to R/3 |
/SAPAPO/C1 | Create business system group |
/SAPAPO/C2 | Assign logical systems to a business system group |
/SAPAPO/CQ | SCM Queue Manager |
/SAPAPO/CCR | Comparison/reconciliation tool |
SMQ1/SMQ2 | qRFC monitor incl. functions start, stop, execute |
SM59 | Definition of RFC destinations |
SALE | Definition of logical systems |
/SAPAPO/CPP | CIF Post processing |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |