Extension types in WE30

A segment on its own goes nowhere. To use it, you append it to an SAP basic type through an extension (older documentation calls it an enhancement or extension type). The basic type plus the extension together form the IDoc type that partners receive. You build extensions in the IDoc type editor, WE30, choosing Extension rather than Basic type.

Building the extension

1. In WE30, select Extension, enter a name in the customer namespace, for example ZCMCINV1, and choose Create.
2. Link it to the basic type it extends, INVOIC02, and give it a description such as "Contoso core return data on invoice items".
3. SAP shows the basic type's segment tree. Select the reference segment, here E1EDP01 (invoice item), and append Z1CMCCORE as its child.
4. Set the occurrence: minimum 0 (optional, because many invoice items have no core agreement) and maximum 1 per item.
5. Check the extension for consistency, save it on the same transport as the segment, and release it once tests pass.

Extensions attach to reference segments of the basic type. Because SAP never removes segments from a released basic type, the parent you hang your segment on will still be there in future releases. That is the core of the upward compatibility SAP's documentation describes, and the reason an extension is preferred over copying the basic type into a new custom basic type.

Extension or new basic type?

Naming, versions and limits

Keep extension names short and meaningful, with a version digit at the end, because a later change usually means a new extension rather than an edited one once partners rely on it. One extension extends one basic type. If both Great Lakes and another fleet customer need different custom data on invoices, consider whether one shared extension with optional segments can serve both; every additional extension is another IDoc type to document, map and test.

Extensions can only add segments. You cannot change fields of SAP segments, change SAP occurrence rules, or remove segments. If a partner needs a longer field than the SAP segment offers, the extra data goes into a custom segment, not into a modified SAP segment.

Hierarchy in the data records

In the IDoc's data records, every segment carries its hierarchy level and the number of its parent segment. Because Z1CMCCORE is defined as a child of E1EDP01 in the extension, SAP knows that each Z1CMCCORE belongs to the item segment immediately before it. Middleware and partner translators rely on the same hierarchy: Process Orchestration reads Z1CMCCORE as a child node of the E1EDP01 node in the IDoc XML, so the mapping can place the core agreement reference in the correct 810 item loop. If the exit appends the segment after the wrong item, the reference lands on the wrong invoice line, and only a content check catches it.

Inbound extensions

Extensions work the same way for inbound IDocs. If a customer sent a value in its 850 that no ORDERS05 segment carries, the middleware would fill a custom segment in an extension of ORDERS05, the inbound partner profile would name the extension, WE57 would register the inbound function module for it, and an inbound exit would read the segment and move the value into the sales order. The structure work is identical; only the direction of the exit code changes.