WE30 — IDoc Type Editor for Basic Types and Extensions

WE30 maintains IDoc types: the tree structure of segments that an IDoc instance follows at runtime. A basic type (like ORDERS05) or a customer extension is built here by attaching existing or newly created segments under parent nodes, setting each segment as mandatory or optional and defining minimum and maximum occurrence. The structural fact that causes most confusion is that WE30 never defines what is inside a segment. Segment fields, data element assignments, and lengths are all maintained in WE31. WE30 only arranges segments into a hierarchy and controls how that hierarchy behaves - order, nesting, repetition, mandatory flags. Anyone trying to add or change a field from inside WE30 is in the wrong transaction.

WE30 is reached for during interface development, not during operations. Typical triggers: extending a standard message type (ORDERS05, DESADV01, MATMAS05) with custom segments to carry Z-fields, building a fully custom IDoc type for a non-standard EDI or ALE scenario, or reviewing an existing type's structure while debugging a segment-not-found or field-mapping issue. It sits upstream of WE20 (partner profile configuration), WE21 (port setup), and the actual data mapping in a user exit or BAdI. It is not used for monitoring live IDocs (WE05, WE02) and not used for partner-specific routing. In cloud integration scenarios it is the point where a classic ALE/IDoc contract is shaped before being exposed through an integration flow or proxy layer.

To confirm which IDoc type and extension a failing interface actually ran with, pull the control record from EDIDC for the affected document number or date range and read the IDoc type and extension fields directly off it, then compare against the segment names present in EDID4 or EDIDD for that same document number. If a segment name appears in the data table that does not exist in the WE30 hierarchy currently displayed for that type, the sender and receiver are running different versions of the type - a transport or release mismatch, not a data problem.

WE30 is unchanged on S/4HANA; the transaction, the hierarchy model, and the release behavior are identical to the ECC version. There is no Fiori app that replaces it - IDoc type development remains a SAPGUI, backend-only activity. What has changed is the strategic direction: for new integration scenarios SAP steers toward API-based approaches (OData services, event-based integration, proxies) rather than new custom IDoc types, so WE30 work today is more often maintenance of existing extensions than greenfield design, with classic IDoc structures increasingly bridged into cloud middleware rather than replaced outright.

This is functional/interface-development territory, typically an ABAP-capable functional consultant or an integration developer, not Basis. A clean handover includes the IDoc type name, the extension name if one was created, the exact segments added with their release status, the message type the extension was linked to, any partner profile changes required downstream in WE20, and the transport request number carrying the segment and type objects together.

WE31 is the direct companion transaction and should be understood first, since every WE30 change ultimately depends on segment definitions built there. WE20 is the next stop after a type is released, to attach it to a partner's inbound or outbound parameters. WE60 gives a readable printout of a finished IDoc type's documentation, useful for handing a structure to a receiving team without making them navigate the tree themselves. BD64 matters when the extended type feeds an ALE distribution model, since the model has to reference the same message type the extension was built against.