WE31 — IDoc Segment Editor

WE31 maintains the definition of an IDoc segment: its name, its short text, and its ordered list of fields with their data elements or types and lengths. A segment on its own does nothing; it becomes useful only once it is assembled, together with other segments, into a basic IDoc type through WE30. Saving a segment definition in WE31 generates a DDIC structure behind the scenes, and that generated structure is what actually carries data at runtime. The single fact that explains most confusion around this transaction is versioning: a segment definition can be edited freely while unreleased, but once released for use in a live basic type, further changes produce a new version number rather than modifying the existing one, and old IDocs continue to reference whichever version they were built against.

WE31 is reached for during custom IDoc development, either building a brand-new basic type from scratch or extending an existing SAP-delivered one with a Z-segment to carry additional fields. It sits early in the build sequence: segments first, basic type assembly second, function module and process code linkage after that. It is not a transaction touched during routine interface operation or monitoring; a consultant chasing a failed IDoc in production goes to WE02/WE05 or the monitoring tools, not WE31. It only comes back into play when a business requirement needs a new field on an existing interface, or when a partner sends a custom segment that must be modeled on the receiving side.

Segment definitions are metadata, not master data, so there is no SE16 table with rows to browse for this. The concrete recipe is: open WE31 in display mode against the segment name and read the release status and current version shown on the initial screen; compare that version against the version referenced inside the basic type via WE30's segment hierarchy for the same basic type; then open SE11 on the generated structure name to confirm the field list and lengths physically match what WE31 shows. Where the segment is used across systems, repeat the WE31 display in the target system and compare release status and version to confirm the transport actually landed.

WE31 is unchanged on S/4HANA; segment definition, generation and release work exactly as in ECC, and there is no Fiori app replacing it because it is a development-time tool rather than an operational one. IDoc technology itself continues to be supported on S/4HANA for both inbound and outbound interfaces, so custom segment work in WE31 remains a normal part of extending ALE-based integrations even where newer scenarios are built on APIs instead.

This is development work, not functional configuration, and normally sits with an ABAP or integration developer rather than a functional consultant, though the functional consultant usually defines what fields are needed and where. Basis owns the transport path once the segment is released. A clean handover states the exact segment name, the full field list with types and lengths, the target basic type and segment version, and confirmation that release and generation both completed without errors.

WE30 is the natural next step, since a segment built in WE31 is only useful once assembled into a basic type there; reviewing WE30's segment hierarchy view is the fastest way to see how a given segment version is actually being used. WE60 produces readable documentation of a segment or basic type, useful for handing the structure to a partner or another team. WE57 links the basic type to the function module that processes it, relevant once the segment content needs to reach an application table. WE19 is the practical way to test a released segment inside a real IDoc before trusting it in an interface.