How to delete partially confirmed orders in APO PP/DS (Automotive Industry)
The blog post covers various resolution options for the problem which is related to the deletion of partially confirmed orders in APO PP/DS. (The explanations are particularly intended to be valid in the automotive environment.)
I also added a piece of information to the end of the blog post, which is about procedure and workarounds related to finally confirmed order deletion in APO.
Before starting, let me write also the following assumptions:
*The topic is mostly common in the Automotive and High-Tech industries.
*The confirmation is created in the SAP APO system. The subsequent processes, that is, the posting of goods movements and production activities are carried out separately in the DI (R/3) system.
*We assume that the connection between DI (R/3) and APO system is healthy, meaning that the technical CIF integration is working properly.
*There are not many explanations about the topic in blog posts, particularly in the scope of the automotive environment in APO PP/DS.
*The topic can be regarded as being hard to handle.
*partially confirmed orders, /SAPAPO/PPC1, /SAPAPO/PPC0_OCD, /SAPAPO/DELETE_PP_ORDER, /SAPAPO/POM1, PPCGO, finally confirmed orders, Livecache, Discrete Industries
We cannot directly delete the partially confirmed orders normally in the standard environment of APO. However, you want nevertheless to delete partially confirmed orders in APO but cannot do it because of various reasons.
Considering my own experiences, I can state that there are some ways to cope with the issue as follows:
1.Confirmation status for reporting poinst are reset, so that the orders can now be deleted by using the standard report /SAPAPO/DELETE_PP_ORDER.
Note: The standard report /SAPAPO/DELETE_PP_ORDER cannot delete the partially confirmed order in APO, since it is input firmed. (please see the OSS Notes 2390793 & 1782073).
1.a. The reset status can be set by using the t.code /SAPAPO/PPC1.
By using t.code /SAPAPO/PPC1, the confirmation status for each reporting point is reset. Please keep in mind that after the report PPC_CONF_GO (t.code PPCGO) on DI(R/3) side has run, the status is also updated in APO.
(check the t.code PPCSHOW in DI(R/3) system to see whether the postings are synchronized, the system should synchronize the GR postings, after the report PPC_CONF_GO (t.code PPCGO) in DI(R/3) system has run.
*goods movements for goods receipts and activities are not synchronized immediately, and saved to a buffer on the database before the report should process them.
The report: /SAPAPO/DELETE_PP_ORDER
The selection should be very limited to avoid mass deletion!
Please keep in mind that the “Send deletion” checkbox does not delete the postings in DI (R/3) system. To delete also the postings, deletion flag should be also set in DI (R/3) System, so that the goods movements posted are deleted also there.
To be able to do that;
*BAPI_MNFCTCONFRCVR_DELETE is used to set the deletion flag in DI.
*Then, some reports related to archiving object PP_CONF for archiving confirmation data can be run. For more information please see the following link from help sap:
(check again later calling t.code PPCSHOW, after the archiving has been done).
1.b. If you are using any non-SAP source system which is sending the cancellation, the reset status should firstly be set there.
2.The partially confirmed order can be deleted in APO by using the report /SAPAPO/OM_DELETE_INCON_ORDERS.
-> This report should be used carefully!! (please see the reason explained in OSS Note 1867390 – Order cannot be deleted in APO)
->Only for very few orders, it should be used on purpose (such as in the case of absence of any order in the database, which is existing in the livecache, though)
-> Also check the DI System to see, whether the postings are done, in order to avoid inconsistencies between both of the systems.
The selection is based on guid that can be found from product view or /SAPAPO/OM16 t.code showed as below:
This report deletes the order only from Livecache, not from database tables such as /SAPAPO/ORDFLDS & /SAPAPO/OPR etc. If you are using the report for the records for which the orders are existing in the database tables;
To be able to delete the records also from database tables, we need to use any custom report. (please see the reason explained in OSS Note 2925793 – Explanation about table /SAPAPO/ORDFLDS)
Some hints on the custom report:
*selection options can be copied from custom fields used in /SAPAPO/ORDFLDS.
*to check if the orders are existing in LCA -> FM: /SAPAPO/OM_ORDER_GET_DATA. If so, do not delete.
*You can modify another table from /SAPAPO/ORDFLDS for recording archived records.
Additionally, here are also some notes for how to delete finally confirmed orders:
Normally, the confirmation needs to be set to the status “finally confirmed”, so that the standard report /SAPAPO/PPC0_OCD can archive these orders. (Best practice of SAP)
a.The interactive tool called Planned Order Management (t.code /SAPAPO/POM1) can be useful to post the confirmations related to the active reporting points.
I suggest that you set the status to finally confirmed by using t.code /SAPAPO/POM1 which I find more practical.
For each active reporting point, the yield can be entered as “1” and immediately posted.
After the report PPC_CONF_GO on DI Side have run, the postings are done and the status is updated so that the order has now the “finally confirmed” status in APO.
Before PPCGO, the postings for good receipts are asynchronized.
b. If you are using any non-SAP source system which is sending the confirmations, the final status should be updated in APO, after the source system has sent the data.
Workaround for final status:
The following OSS Note explains that a report to correct order status can be used to set the final status in APO.
(-> you must make sure that the goods movements are done on the R/3 side.) -> I have never tested it but according to the OSS Note 1479186, it can be beneficial to use it, if you are thinking the status can not be updated in APO, because the queue was somehow accidentally deleted.
The report can be activated by implementing the note mentioned.
1479186 – Report to correct orders if queue from R/3 was deleted
The blog post covers various resolution options for the problem which is related to the deletion of partially confirmed orders in APO PP/DS.
The notes for archiving finally confirmed orders in the both APO and DI(R/3) Systems were also added.
I anticipate the notes being beneficial, particularly for those who are working in the automotive industry and new to SAP APO implementation for Automotive or High Tech industries.