Custom segments in WE31

An extension starts with the smallest piece: a segment that defines the fields you will add. Segments are maintained in the segment editor, WE31, and they live in the ABAP Dictionary like other structures, but you never create or change them in SE11. The segment editor keeps the rules: one segment definition per release, generated dictionary structures, and a release flag that freezes the definition.

Designing the segment

For Great Lakes, Kenji's team designs one segment for the core return data, to sit under each invoice item. Keep segments narrow and purposeful: only the fields the partner needs, each based on a data element with a clear domain, so field lengths and documentation come from the dictionary.

Two design notes. First, IDoc segment fields are character-based in the data record, so amounts and dates travel as text; define them as character fields and agree the format with the partner (decimal point, no thousands separator). Second, name the segment in the customer namespace. SAP's own segment types start with E1; customer segment types start with Z1, so the segment here is Z1CMCCORE.

Data elements matter more than they seem. The segment documentation in WE60, which becomes the partner specification, takes each field's description from its data element. A field typed with a generic character data element documents nothing; a field typed with a Contoso data element named for the core agreement number explains itself to every future reader, including the partner's EDI analyst.

What SAP generates

When you save a new segment type in WE31, SAP creates three dictionary structures for it automatically: the segment type itself (Z1CMCCORE, release-independent), a segment definition for the current release (Z2CMCCORE000, version 000), and a documentation structure (Z3CMCCORE). The data record of an IDoc stores the segment type name; the segment definition is what changes if you ever add fields in a later release, which then creates a new definition version rather than changing the old one.

Release: the safety catch

After you activate the segment and test it, you release the segment definition. SAP's documentation calls the release a safety concept: once released, the definition cannot be changed. That protects every partner using it from a field that silently changes length. Release only after the field list is agreed with the partner and reviewed, because the next change means a new segment definition version and a retest of every interface that uses it.

Changing a segment after release

Partners change their minds. If Great Lakes later wants the core agreement's expiry date too, you do not edit the released definition Z2CMCCORE000. In the segment editor you add the field, which creates a new segment definition for the current release, and the extension and partner profiles then decide which version a partner receives. Partners that never asked for the new field keep receiving the old layout until their mapping is ready. That is why fields should be added at the end of a segment and never reordered: a receiver that reads by position must still find the old fields where they were.

Removing a field is harder still, because any partner may read it. In practice teams leave obsolete fields empty and document them as unused, and only retire a whole segment or extension after every partner profile has stopped using it. Contoso's rule is simple: no field leaves a released segment while the extension register lists a partner for it.