SAP WLF_IDOC — IDoc Processing
The `WLF_` prefix belongs to Agency Business, which makes this transaction easy to dismiss as a niche retail tool. It is not. WLF_IDOC is a general-purpose IDoc workbench, and on systems where it is available most integration consultants prefer it to the classic transactions.
It does in one screen what WE02, WE05 and BD87 do in three: select IDocs flexibly, read them, reprocess them in bulk. Its distinctive capability is mass status change — for example moving a batch from 51 (error) to 68 (no further processing).
That capability is also why it deserves respect. Setting an IDoc to 68 does not fix anything; it declares that nobody will ever fix it. Used well, that is how you retire genuinely dead messages so the monitor stops crying wolf. Used carelessly, it hides real business transactions that someone was waiting for.
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 WLF_IDOC
- Clearing a backlog of failures that the classic transactions make tedious.
- Retiring a batch of IDocs that genuinely cannot be reprocessed — a partner resent them, a test flooded the system.
- Selecting IDocs on criteria the standard screens do not expose well.
- Doing monitoring and reprocessing in one place rather than switching transactions.
What the screen looks like
Selection
| Sel | IDoc number | Status | Message | Partner | Created | Error text |
|---|---|---|---|---|---|---|
| X | 0000000004471955 | 51 | ORDERS | CUST_NORTHWIND | 02.08.2026 | Material 4182 not listed |
| X | 0000000004472010 | 51 | ORDERS | CUST_BALTIC | 03.08.2026 | Material 4182 not listed |
| 0000000004469881 | 51 | ORDERS | TEST_PARTNER | 14.07.2026 | Obsolete test data |
The fields, in plain English
EDIDC-STATUSSame status values as everywhere else. 51 inbound error and 64 waiting are the ones you will select on most.
The practical advantage over BD87: the failure reason is shown per row, so you can triage a hundred IDocs without opening each one. Sorting by it groups everything sharing a root cause.
Select rows and reprocess them together. Same underlying action as BD87, with more precise selection.
Watch out: Still the same rule: fix the cause first, or you reproduce the same errors with new timestamps.
Sets a chosen status on the selected IDocs — most often 51 to 68 to retire messages that will never post.
Watch out: This is the dangerous one. Status 68 abandons the IDoc: the business transaction it carried never happens and the monitor stops reporting it. Use it only when you know the transaction is genuinely dead or has been resent.
Step by step
- 1Select by date range, direction and status.
- 2Sort the result by error text to group failures sharing a cause.
- 3Fix the underlying data for the largest group first.
- 4Select those rows and reprocess.
- 5Re-run the selection to see what remains.
- 6Only for genuinely dead messages, consider mass status change to 68 — and note why somewhere durable.
Errors you will hit, and what they mean
Transaction WLF_IDOC does not exist
Why: The component providing it is not active on this system.
Fix: Use WE02, WE05 and BD87 together instead. They cover the same ground with more screen-switching.
Time-out when selecting
Why: Date range too wide against large IDoc tables — a documented complaint about this transaction.
Fix: Narrow the date range and add message type or partner. Run wide selections in background.
IDocs set to 68 that should not have been
Why: Mass status change applied to a broader selection than intended.
Fix: There is no clean undo, and a 68 cannot simply be reprocessed. The business transaction has to be re-sent by the partner or rebuilt with WE19. Expand and verify the selection before every mass status change.
Common questions
How is WLF_IDOC different from BD87?
It combines monitoring and processing in one screen, shows error text in the list so you can triage without opening each IDoc, and adds mass status change. BD87 reprocesses but cannot change status in bulk.
Is this a retail-only transaction?
No. The WLF_ prefix comes from Agency Business, but the transaction is general-purpose IDoc management and works on any IDoc.
When is it right to set an IDoc to 68?
When the message genuinely cannot and should not post — obsolete test data, a duplicate the partner already resent, a transaction cancelled commercially. Never to make a monitor look clean.
Transactions that go with WLF_IDOC
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 →