WE60 — IDoc Type Documentation Display

WE60 renders the documentation for a basic IDoc type or an extension type: the segment tree, mandatory/optional and min/max occurrence for each segment, and the field list with type, length and long text pulled from the underlying dictionary structures. Output can go to the screen as a navigable tree, as a printable structure graphic, or downloaded as a Word or HTML document for handover packs. The one fact that causes most confusion: WE60 is purely a reader. It has no save button and cannot add a segment, change a field length, or extend a type. Consultants who click around looking for an edit option are in the wrong transaction; segment and type maintenance lives in WE31 and WE30, not here.

WE60 gets used before writing or reviewing an IDoc mapping, when the interface analyst needs to see exactly which segments and fields a given basic type carries, including custom Z-segments added through an extension. It is also the standard output for interface documentation packs handed to a partner or to an offshore development team, since the Word/HTML export gives a static reference independent of system access. It is not the tool for checking a live instance - that is WE02 or WE05 - and it is not the tool for building a new type, which is WE30/WE31. Reach for WE60 specifically when the question is 'what does this type look like', not 'what did this specific IDoc contain'.

There is nothing to prove by looking at WE60 output alone, since it never writes data. To confirm a discrepancy, take a real IDoc instance from WE02/WE05, note its segment names and the basic/extension type from the control record fields, then reopen WE60 against that same type and version and compare the segment list and occurrence counts field by field. A mismatch usually means the instance was generated against an extension type or a segment version that differs from what WE60 is currently showing.

WE60 is unchanged on S/4HANA; the ALE/IDoc layer it documents is retained for backward compatibility and for interfaces that have not been migrated to API-based integration. There is no Fiori equivalent, since this is a technical documentation tool aimed at developers and interface analysts rather than business users. New interface work on S/4HANA and BTP integration scenarios increasingly favors OData or event-based APIs, but existing IDoc-based interfaces still rely on WE60 for structure review.

Reading WE60 output is a functional/interface analyst task; changing what it displays is an ABAP/dictionary task done through WE30 and WE31, usually by a development resource with authorization to change segment definitions. A clean handover states the exact basic type, extension type, and segment version being reviewed, plus whether the discrepancy was found against a live instance or against a partner specification.

WE31 and WE30 are the transactions that actually create and change the segments and IDoc types that WE60 only displays; anyone confused by WE60's lack of a save button should look there next. WE02 and WE05 show real IDoc instances, useful for cross-checking WE60's structural output against what actually moved through the system. WE19 and WE21 support test generation and port configuration once the structure is confirmed correct, and WE41/WE42 cover the process code side of outbound and inbound processing that consumes the type documented here.