WE02 — IDoc Display and Status Analysis
WE02 is used to display IDocs with control record, data segments and complete status history for interface troubleshooting. It is most useful when an inbound or outbound IDoc is missing, failed, stuck, duplicated or posted with unexpected application data. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
This practitioner page covers WE02, IDoc Display and Status Analysis. It explains the transaction's operational purpose, the evidence to capture, the data or configuration objects that matter, and the failure patterns that commonly mislead SAP support teams.
Published 19 Sept 2026· 746 words
Purpose
display IDocs with control record, data segments and complete status history for interface troubleshooting. The useful way to think about WE02 is as part of an end-to-end business or technical flow, not as an isolated screen. Capture the exact organizational context, business object, user and timestamp before drawing conclusions, because those values determine which data and configuration the transaction reads.
When it is used
WE02 is typically used when an inbound or outbound IDoc is missing, failed, stuck, duplicated or posted with unexpected application data. It is also valuable during test cycles because it provides a repeatable way to prove what SAP processed, selected or rejected. In production, narrow the selection to the affected population first and separate diagnostic/display actions from functions that can post, retry, clear or change system state.
How to use it in practice
- Search by IDoc number, date, status, message type or partner and narrow the result before opening a record.
- Read the control record first to confirm sender, receiver, direction, message type and basic type.
- Read status records chronologically; the latest status is important, but earlier statuses explain how the IDoc reached it.
- Inspect only the segments relevant to the business error and compare them with the source document.
- Fix the root cause, then use the appropriate reprocessing path rather than editing productive IDoc data casually.
Key data objects
These are the strongest anchors for a WE02 investigation. Record the values in the incident or test evidence so another consultant can reproduce the same conclusion and distinguish master data, configuration, authorization and transaction-state problems.
- IDoc number — verify the exact value, organizational context and relationship to the affected document or interface.
- direction and status — verify the exact value, organizational context and relationship to the affected document or interface.
- message/basic type — verify the exact value, organizational context and relationship to the affected document or interface.
- sender/receiver partner — verify the exact value, organizational context and relationship to the affected document or interface.
- status records and segment data — verify the exact value, organizational context and relationship to the affected document or interface.
How to prove it in the data
Use a three-part proof: first establish the source document or request and its exact keys; second show the status, accounting/interface record or runtime evidence produced by SAP; third show the corrected result using the same selection. Cross-check neighboring transactions and logs rather than relying on a single screen message. This prevents a successful retry, changed selection or unrelated master-data edit from being mistaken for the real fix.
ECC vs S/4HANA
WE02 remains a central IDoc support transaction in S/4HANA landscapes that use ALE/EDI. Modern APIs coexist with IDocs, so it is common to support both integration styles in the same program. Availability does not automatically mean it is the preferred design for new work. On S/4HANA, pair familiar SAP GUI diagnostics with Fiori apps, Universal Journal, ODP, RAP/CDS or released APIs where those are the strategic surface for the process.
Common pitfalls and how to diagnose them
- Looking only at the current status and ignoring the earlier status history. Recheck the exact keys and chronology before changing configuration or reposting data.
- Changing an IDoc manually when the mapping or master-data source is wrong. Recheck the exact keys and chronology before changing configuration or reposting data.
- Reprocessing status 51 repeatedly without correcting the application error. Recheck the exact keys and chronology before changing configuration or reposting data.
Whose problem this is
Primary ownership normally sits with the BTP INTEGRATION team. Bring in Basis for infrastructure/runtime issues, Security for authorization evidence, and ABAP or integration developers only when the transaction evidence points to custom logic or mapping. A useful escalation includes exact keys, timestamp, expected result, actual result and checks already completed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/we02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.