Lesson 4 of 6
Fix, reprocess, and when not to edit
9 min
Listen to this lesson
Once you know the cause, the order of work is always the same: fix the cause, reprocess the IDoc, verify the business result, and record what you did. Teams that skip the first step and go straight to reprocessing just generate a second error status. Teams that skip the third step close incidents that are not resolved.
- DiagnoseRead the status long text and confirm the cause, not only the symptom
- Fix the causeMaster data, customizing through a transport, partner profile, job, or a partner resend
- ReprocessBD87 for selected IDocs, or the matching report as a job for many
- VerifyStatus 53 or 03, then the business document: PO confirmation, invoice, delivery
- RecordIncident note with IDoc numbers, cause, fix, transport and evidence
BD87 and the reprocessing reports
BD87 groups IDocs by status and lets you select a node or individual IDocs and choose Process. BD87 calls the right program for the status behind the scenes, and its result list shows the old and new status of each IDoc. For volume, or to make reprocessing part of operations, schedule the underlying reports as jobs with variants limited to a message type and partner.
| Report | Typical statuses | Transaction |
|---|---|---|
| RBDMANI2 | 51 (application document not posted) | Run as a job or through BD87 |
| RBDAPP01 | 64 and 66 (waiting for application or predecessor) | BD20 |
| RBDAGAI2 | 56, 61, 63, 65 (inbound IDocs with errors) | BD84 |
| RBDSYNEI / RBDSYNEO | 60 inbound / 26 outbound (syntax errors) | Run as a job or through BD87 |
| RSEOUT00 | 30 (ready for dispatch) | WE14 |
| RBDAGAIN | 02, 04, 05, 25, 29 (outbound IDocs with errors) | BD83 |
| RBDAGAIE | 32 and 69 (edited IDocs) | Run as a job or through BD87 |
Standard reprocessing reports by status. Confirm names and transactions in your release with SE38 and SE93 before building jobs.
Two rules keep reprocessing safe. First, reprocess the original IDoc rather than asking the partner to resend, unless the partner's data was wrong; a resend creates a second IDoc for the same business document, and if the first one is later reprocessed by a job you get a duplicate order or invoice. Second, respect serialization: for ORDCHG after ORDERS, or for inbound IDocs in a serialization group, reprocess in the original order.
Editing IDocs: possible, audited, and usually wrong
You can change the data records of an IDoc in WE02 or WE05 if you have the authorization. SAP keeps the original as a separate IDoc with status 70 (inbound, original of an edited IDoc) or 33 (outbound), and the edited IDoc gets status 69 (inbound, IDoc was edited) or 32 (outbound). So the system keeps evidence, but the edit is still a change to a business document outside the business process.
Editing is acceptable only in narrow cases: the partner sent a single wrong value that it cannot resend in time, the value has no financial effect, and the change is approved and recorded. Editing amounts, tax data, prices, bank details or quantities on invoices is not acceptable at Contoso: those IDocs are closed and the partner sends a corrected document. Editing to work around missing customizing is never acceptable, because the next IDoc fails the same way.
- Is the cause in SAP master data or customizing?Yes → fix it and reprocess; do not edit · No → next question
- Is the wrong value financial (price, amount, tax, bank, quantity)?Yes → do not edit; close and ask for a corrected document · No → next question
- Can the partner resend before the business deadline?Yes → close the IDoc and take the resend · No → next question
- Is the edit approved by the process owner and recorded?Yes → edit, reprocess, keep the 70 original as evidence · No → do not edit
Closing an IDoc: status 68 and 31
Sometimes an IDoc must never be processed: the partner sent a duplicate, the business document was created manually, or a resend replaced it. Then you close it so jobs do not pick it up, typically by setting the deletion flag in the IDoc list, which sets status 68 (error, no further processing) for inbound or 31 for outbound. Closing is an operational decision and belongs in the incident record with the reason and the replacement document.
What would you do?
A Great Lakes Fleet Services ORDERS IDoc failed with 51 because of a blocked customer. Maria created the sales order manually to meet a delivery date. The customer block has now been lifted. What should happen to the failed IDoc?
- Fix the cause first, then reprocess, then verify the business document, then record it.
- BD87 reprocesses by status; schedule RBDMANI2, RBDAPP01, RSEOUT00 or RBDAGAIN as jobs for volume.
- Editing keeps the original (70 inbound, 33 outbound) but is still a business change; never edit financial values or to dodge customizing.
- Close IDocs that must not post with status 68 or 31 and record why.
Check your understanding · not graded
Lesson check
1. Which report reprocesses inbound IDocs in status 51 after the cause is fixed?
2. You edit an inbound IDoc in WE02. What does SAP do with the original data?
3. A duplicate inbound invoice IDoc must never post. How do you take it out of processing?
4. Why prefer reprocessing the original IDoc over asking the partner to resend?