In a recent project, I had to delete components from a released (REL) production order programmatically.
At first, the task looked simple: just call CO_XT_COMPONENT_DELETE with the right parameters.
But I ran into a strange issue:
When I debugged my report, the deletion indicator was getting set on the components.
When I ran the same report in the foreground, nothing happened – no error, but the deletion flag wasn’t applied.
After some investigation, the root cause became clear.
Root Cause
In my scenario, I was also doing a PP master data re-read via BDC (CO02 → Functions → Read PP Master Data).
This step updates the internal buffers (CAUFV_BT, RESB_BT, etc.) for the order. When I immediately called CO_XT_COMPONENT_DELETE in the same report and LUW:
The buffer still held the old snapshot.
The FM executed “successfully” but changes were overwritten or not persisted.
That’s why it looked fine in debugging (step-by-step buffer refresh) but failed in real execution.
Solution – Use Job Submission / Separate LUW
Instead of calling CO_XT_COMPONENT_DELETE directly in the same LUW as the BDC, I wrapped it in a custom FM and submitted it as a background job right after the master data re-read.
PERFORM reread_pp_master_data.
“ Step 2: Schedule deletion wrapper as background job
SUBMIT zdelete_components_report
WITH p_aufnr = lv_aufnr
AND RETURN.
This way:
The BDC commits its changes and releases the buffer.
The deletion report runs in a fresh LUW and updates the components reliably.
Now the deletion indicator is set consistently, even without debugging.
Key Takeaways
Be careful when mixing BDC (CO02, master data re-read) with direct function module calls on production orders.
Internal buffers (*_BT) can cause unexpected overwrites.
For reliable results, always execute sensitive updates (like component deletion) in a separate task, background job, or RFC process.
With this approach, I was able to delete components of released production orders successfully after master data re-read.
In a recent project, I had to delete components from a released (REL) production order programmatically.At first, the task looked simple: just call CO_XT_COMPONENT_DELETE with the right parameters.But I ran into a strange issue:When I debugged my report, the deletion indicator was getting set on the components.When I ran the same report in the foreground, nothing happened – no error, but the deletion flag wasn’t applied.After some investigation, the root cause became clear.Root CauseIn my scenario, I was also doing a PP master data re-read via BDC (CO02 → Functions → Read PP Master Data).This step updates the internal buffers (CAUFV_BT, RESB_BT, etc.) for the order. When I immediately called CO_XT_COMPONENT_DELETE in the same report and LUW:The buffer still held the old snapshot.The FM executed “successfully” but changes were overwritten or not persisted.That’s why it looked fine in debugging (step-by-step buffer refresh) but failed in real execution.Solution – Use Job Submission / Separate LUWInstead of calling CO_XT_COMPONENT_DELETE directly in the same LUW as the BDC, I wrapped it in a custom FM and submitted it as a background job right after the master data re-read. ” Step 1: Do BDC for PP master data re-read in CO02 PERFORM reread_pp_master_data.” Step 2: Schedule deletion wrapper as background jobSUBMIT zdelete_components_reportWITH p_aufnr = lv_aufnrAND RETURN.This way:The BDC commits its changes and releases the buffer.The deletion report runs in a fresh LUW and updates the components reliably.Now the deletion indicator is set consistently, even without debugging.Key TakeawaysBe careful when mixing BDC (CO02, master data re-read) with direct function module calls on production orders.Internal buffers (*_BT) can cause unexpected overwrites.For reliable results, always execute sensitive updates (like component deletion) in a separate task, background job, or RFC process. With this approach, I was able to delete components of released production orders successfully after master data re-read. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
