SAP BD87 — Status Monitor for ALE Messages
WE02, WE05 and WE09 only look. BD87 acts. It shows IDocs grouped by status and lets you select failures and process them again.
The distinction that governs everything here: an IDoc in status 51 failed because of something outside the message — a material that did not exist, a customer who was blocked, a closed period. The IDoc itself is usually fine. Reprocessing without fixing that cause simply produces status 51 again.
So the sequence is always the same: find out why, fix the data, then reprocess. BD87 is the last step, not the first.
Every IDoc carries a two-digit status. Inbound: 53 posted successfully, 51 application error, 64 waiting to be processed, 68 abandoned. Outbound: 03 passed to the port, 12 dispatched, 02 port error, 29 ALE service error. 56 means no partner profile was found.
When you would actually use BD87
- A batch of inbound IDocs failed on master data that has now been created.
- IDocs are sitting in status 64 waiting for a processing job that did not run.
- An outbound message failed at the port and the connection is now working.
- Daily interface housekeeping: clear yesterday's failures.
What the screen looks like
Selection
| Status | Description | Message | Count | Action |
|---|---|---|---|---|
| 51 | Application document not posted | ORDERS | 12 | Process |
| 64 | IDoc ready to be transferred | ORDERS | 3 | Process |
| 53 | Application document posted | ORDERS | 486 | — |
The fields, in plain English
The date range to monitor. Required in practice — reprocessing needs a bounded set you have actually looked at.
The tree groups by status. Selecting a node and choosing Process reprocesses everything under it, which is powerful and worth being deliberate about.
Watch out: Selecting a high-level node can reprocess hundreds of IDocs. Expand and check the count before acting.
Inbound reprocessing retries creating the business document. Outbound retries the dispatch. Different mechanisms, same button.
The action itself. For inbound status 51 it re-runs the posting; for status 64 it passes the IDoc to the application for the first time.
Watch out: Reprocessing a 51 with the root cause unfixed just recreates the 51, adds a status record, and wastes time.
Step by step
- 1Investigate first in WE02: open a failed IDoc and read its status records.
- 2Fix the underlying cause — create the missing material, unblock the customer, open the period.
- 3In BD87, select the date range, direction and message type.
- 4Execute to get the status tree.
- 5Expand the error node and confirm the count is what you expect.
- 6Select the node and choose Process.
- 7Re-run the selection. Successful ones should now be in 53; anything still in 51 has a different cause.
Errors you will hit, and what they mean
IDocs return to status 51 immediately after reprocessing
Why: The root cause was not actually fixed, or a second problem is behind the first.
Fix: Open one and read the newest status record — the error text may have changed. Fix that, then reprocess again.
Status 68 — No further processing
Why: Someone marked the IDoc as abandoned. This is a deliberate act, not a failure.
Fix: A 68 cannot simply be reprocessed. If the business transaction is genuinely still needed, ask the partner to resend, or build a fresh IDoc with WE19.
Reprocessing created duplicate business documents
Why: An IDoc that had actually posted was reprocessed, or the same message was received twice.
Fix: Reverse the duplicates through the relevant application. Before reprocessing, always confirm the current status really is an error — this is the specific risk of selecting a high-level node without expanding it.
Common questions
What is the difference between BD87 and WE02?
WE02 displays; BD87 displays and reprocesses. If you only need to look, use WE02 — it cannot change anything by accident.
Can I reprocess a status 53 IDoc?
You should not. 53 means the business document was created. Reprocessing risks a duplicate. If the resulting document is wrong, correct it in the application instead.
What creates status 64 and how do I clear it?
The partner profile is set to collect IDocs for background processing rather than posting immediately. If the job has not run, BD87 processes them now — but check why the job did not run, or they will pile up again tomorrow.
Why do the same IDocs fail every night?
Something structural: a partner sending an obsolete basic type, master data never created, or a partner profile pointing at the wrong process code. Reprocessing treats the symptom. Fix WE20 or the source system.
Transactions that go with BD87
Reading about it only gets you so far
Practise SAP transactions in a safe simulated environment and keep what you learn.
Practise SAP transactions hands-on
Interactive modules, games, and an AI tutor — free to start.
Get started free →