Automating CIF Delta Report Reprocessing
CIF is the standard interface between APO and ECC used to transfer master data (uni-directional) and transaction data (bi-directional). But very often due to some master data issue transaction data does not flow through and gets stuck in CIF queue. SAP provides CIF Delta Reconciliation Report (commonly know as CCR) that compares transaction data for given product-location between APO & ECC to list the differences. This output result is typically reviewed by production support team and necessary processing action (one of Send to ECC, Send to APO, Delete in ECC and Delete in APO action button) executed to reconcile the transaction data differences. Any APO consultant doing CIF monitoring on regular basis knows the effort required and also over time turns monotonous. However the choice of action to be taken is limited (most of the cases only 1 of the 4 actions possible) based on the transaction data object type (like Purchase Requisition, Purchase / Stock Transfer Order, Planned Order, Production Orders, Stock, Sales Order) but still needs manual intervention to reprocess. Considering volume of data (Product-Location Master Data being primary criteria multiplied by average number of order elements) the number of CIF Delta Report Reconciliation records can be quite high. Remember one master data issue can cause CIF queue block for entire set of order elements i.e. each order line is part of single LUW of qRFC but shows up in CIF Delta Report as individual error records. Loading such a long list of Delta Differences records in CCR takes time (typically run done in background mode) and further selection / reprocessing can turn out quite time-consuming.
Thus it was quite natural to ideate and see if this tedious, manual activity can be automated using custom developed program. A CCR Automated Reconciliation Tool is expected to provide business benefits – by significantly reducing time spent for daily manual task of CIF Delta Records Reconciliation and ensure accuracy of CIF Reconciliation Action as it is handled through centralised action to order and error type mapping. The accuracy is critical as you are dealing in a live Production system and incorrect action may result in deletion or duplication of transaction data causing business disruption. Of course there is no point trying to reconcile by brute force mode just after running CCR Reconciliation Report without taking any corrective action of impacted Location-Product master data.
So the design architecture work started. The core development is a custom table by transaction data Object Type, Error Code mapped to one of the four Reconciliation Actions. For example this can be the table structure – note the Object Type can be either text (will need validation during entry creation / updation and mapping) or better to use R/3 Object Type like T_MARD is Stock, T_PLO is Planned Order, T_ORD is Manufacturing i.e. Production or Process Order etc.
The Message No. comes from the CIF Delta Error Record entries and points to appropriate error message in /SAPAPO/CIF message class.
Once this custom table is maintained, as first step create CCR Variants with suitable transaction data objects and product-location selection along with name of Save Results. It is very important to have meaningful and unique name for Result Save as it will be main input of custom CIF Delta Records Reprocessing report selection apart from RFC Destination of connected ECC system. Save this custom report selection as a variant so that it can be also scheduled in background at certain frequency (say every 6/8 hours) following CCR execution with Results Saved with mentioned name.
If you debug CIF Delta Report program after selecting error records and clicking on reprocessing action button, internal table type /SAPAPO/CIF_DELTA3_DOCS_TBL provides all CIF Error Records details. Some relevant fields will be TYP which is mapped to Object Type to determine transaction data type for which CIF Delta Records are coming, MSG_NO is the error message number. Using these two values for CIF Delta Error Record search for matching combination in custom table to determine Reprocessing action to be taken.
The custom CIF Delta Records Reprocessing program is based on class /SAPAPO/CL_CIF_DELTA3_HANDLER that has methods for different reprocessing options like DATA_SEND2APO for Send to APO, DATA_SEND2R3 for Send to R/3, DATA_DELAPO for Delete in APO and DATA_DELR3 for Delete in R/3 options. Standard SAP processing also executes method CHECK_SEND_METHOD to validate if the selected option is correct or not.
Function Module /SAPAPO/CIF_DELTA3_REFRESH will provide the CIF Delta Record update after reprocessing. Based on this data the custom report output lists by Object Type i.e. Transaction Data type, Error Message No. with total count of errors that were tried for reprocessing, Reprocessing Action i.e. Send to APO, Send to R/3 and if no Reprocessing Action found in Custom Table then mentioned as No Action Found. For such cases manual analysis of the CIF Delta Record is required and corresponding action option maintained in the custom table. Then onwards such CIF Delta Error records will also get selected for reprocessing automatically.
This program upon development and necessary testing if used regularly in background mode should reduce the effort of manual reprocessing of CIF error records significantly. It is not expected manual CCR Reconciliation will not be required at all but should significantly reduce the effort put in by Production Support Team who can focus on more essential tasks.
Source: https://blogs.sap.com/2015/04/30/automating-cif-delta-report-reprocessing/
I just did some debugging to see how SAP handles all that in online CCR:
- read table /SAPAPO/CIF_DTCL to get the saved results from CCR
- use import to read cluster data and get table with CCR results (error code, object type, etc)
- loop on imported table and trigger corresponding action for those which shall be done automatically
Keys for error codes , send methods etc. can be seen in includes /SAPAPO/CIF_DELTA3_INCFORM and /SAPAPO/CIF_DELTA3_INC0. Used functional modules are:
/SAPAPO/CIF_DELTA3_ORD_DEL for deletion of orders in APO
/SAPAPO/CIF_DELTA3_DEL_STOCK for deletion of stock
/SAPAPO/CIF_DELTA3_REFRESH_STK for re-send of stock to APO
/SAPAPO/CIF_DELTA3_REFRESH for re-send of orders to APO
/SAPAPO/CIF_DELTA3_REFR_APO_R3 for re-send of orders to R/3
You can run CCR in background only to determine the inconsistencies.
This way when you go to CCR you can pick the inconsistencies in a few seconds (those inconsistencies previously determined by your background job). Now the final decision is done interactively. You have to decide what to do: what should be moved from APO to ECC, what from ECC to APO, what should be deleted,etc.
Note that if your master data is correct and you have a robust process, the number of inconsistencies should be minimal.
In case you want to automate the CCR, check also these FM and try with a custom program:
- /SAPAPO/CIF_DELTA3_ORD_DEL (not released by SAP) Comparison Tool: Delete APO Orders
- /SAPAPO/CIF_DELTA3_REFRESH (not released by SAP) Module for Refresh Mechanism for Delta Report 3
- /SAPAPO/CIF_DELTA3_REFR_APO_R3 (not released by SAP) Comparison Tool: Refresh Module APO->R/3
- /SAPAPO/CIF_DELTA3_DEL_STOCK (not released by SAP) Delete Stock in APO DB and liveCache (Delta Report 3)
Now, I think it is convenient to take a look and analyze the error instead of automate the correction.
Comments
Post a Comment