WE05 — IDoc List Monitoring Transaction

WE05 lists IDocs matching a set of selection criteria: message type, partner number, direction, date range, and status code or status group. It reads the same control, data and status tables that WE02 reads, and in most systems the two transactions are functionally interchangeable for a single IDoc. The structural fact that causes confusion is that WE05 defaults to a status-group selection (for example all error statuses, or all successfully processed statuses) rather than a single status value, so a consultant searching for one exact status code sometimes gets an empty or an overly broad list depending on which radio button and status grouping was left selected from a previous session. WE05 is built for scanning volume, not for reading one IDoc's segment content, which is what WE02's double-click drill-down is for.

WE05 is reached for whenever there is a batch of IDocs to triage rather than one document to inspect: a nightly interface run that produced a wall of status 51 errors, a partner complaining that a range of documents never arrived, or a post-go-live check that all IDocs for a given message type and date are sitting at status 53 as expected. It sits downstream of the interface configuration transactions (partner profiles, ports) and upstream of the reprocessing tools. For a single known IDoc number, WE02 or WE19 is faster. For PI/PO or cloud integration scenarios where the IDoc is only the ABAP-side leg of the flow, WE05 shows only that leg; the middleware monitor is needed to see the rest of the journey.

In SE16, query EDIDC filtered on message type, direction, and date, to get the candidate IDoc numbers and their current status. Join those numbers against EDIDS to see the full status history rather than only the last status shown on the WE05 list, since a document can pass through and out of an error status before landing where it now sits. Filter EDIDS on the status code range associated with errors to confirm whether a spike is a single bad batch or an ongoing pattern across dates.

WE05's selection logic and the underlying tables are unchanged on S/4HANA. The transaction remains available and is still the fastest route for a bulk status scan; there is no dedicated Fiori app that replaces the specific status-group filtering WE05 offers, though general interface monitoring apps exist for broader integration landscapes. Consultants working S/4HANA projects use WE05 exactly as on ECC.

This is functional territory first: message type, partner and status meaning are interface configuration knowledge, usually owned by the relevant module consultant (SD, MM, FI or the middleware team). Basis gets involved only if the issue is queue processing capacity or background job scheduling rather than the content or status of the IDocs themselves. A good handover states the message type, the exact status code observed, the date range, and whether the pattern is a single batch or ongoing.

WE20 and WE21 are worth reviewing next since a WE05 list that is unexpectedly empty is frequently a partner profile or port misconfiguration rather than a WE05 problem. WE19 is the natural next step for reprocessing or replaying a specific IDoc found through WE05 without re-triggering the whole upstream interface. BD21 is relevant when the IDocs in question originate from change pointers rather than a direct interface call, since the selection there determines whether an IDoc was created at all. For scenarios where the IDoc is only the ABAP-side leg of a broader integration flow, the middleware monitor equivalent to SXMB_MONI shows the rest of the message journey that WE05 cannot see.