Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 6

Extend or map?

7 min

Listen to this lesson

0:00 / 7:29

Sooner or later a trading partner asks for a value SAP does not send. Great Lakes Fleet Services wants Contoso Motor Co.'s core return agreement number on every alternator line of its 810 invoices, so its accounts payable can match the core deposit to the old alternator it will send back. Lakeside Components wants Contoso's Detroit dock number on every 850. Both requests sound alike. They need opposite answers, and this lesson is about telling them apart.

Three ways to supply a missing value

Middleware mapping (lightest)The value is a constant or can be derived from data already in the IDoc: a value mapping, a lookup table in middleware, a concatenation. No change in SAP S/4HANA.
Standard IDoc field you are not filling yetThe basic type already has a field or qualified segment for it, and SAP fills it if master data or customizing is maintained. Check WE60 before anything else.
IDoc extension (heaviest)The value exists only in SAP and no standard segment carries it: a custom segment, an extension type, and ABAP in an exit to fill or read it.
Three ways to get a value the partner needs into the EDI message, from lightest to heaviest.
The Sign-Off Table · thesignofftable.com/academy/sap-edi-209

The dock number is the easy case. Plant 1710 Detroit has one receiving dock for Lakeside's trucks, so the value is a constant per plant. Process Orchestration already receives the plant in the ORDERS IDoc and can map plant 1710 to the dock number with a value mapping. No SAP change, no transport, no regression risk in SAP S/4HANA.

The core agreement number is the hard case. It lives in Contoso's own table ZCMC_CORE_AGR, the custom core return agreement object carried over by the conversion (about 2,600 agreements). Nothing in the billing document or in INVOIC02 carries it. Middleware could call back into SAP to look it up for every invoice line, but that turns an asynchronous interface into a chain of synchronous calls that fails whenever either side is slow. The clean answer is to put the value into the IDoc where it is created: an extension.

Deciding between mapping and extension for a requested value.
The Sign-Off Table · thesignofftable.com/academy/sap-edi-209

A clean-core lens

An IDoc extension is classic extensibility: customer segments in the Z namespace, assigned to an SAP basic type, filled by ABAP in a customer exit. SAP designed extensions to be upward compatible (basic types cannot lose segments, so your appended segments keep working), but the ABAP that fills them is custom code that must be maintained, tested and upgraded. Under SAP's clean core guidance, how an extension is classified depends on what that code uses: reading Contoso's own tables and SAP's documented interfaces keeps it on the safer side, while reading SAP internal tables or changing SAP objects pushes it toward the levels SAP discourages. Run the ATC clean core checks on the exit code like on any other custom code.

CriterionMiddleware mappingIDoc extension
Change in SAP S/4HANANoneSegment, extension type, assignment, exit code, partner profile
Who maintains itIntegration team (Theo)Integration team plus ABAP developers (Kenji)
Upgrade exposureNone in SAP; middleware changes need retestExit code and data sources retested after upgrades
When it is the only optionNever needed if the value is derivableValue exists only in SAP and no standard field carries it
Partner reusePer partner mappingSame extension usable by every partner who needs the value
The extend-or-map trade-off in one table.
The Sign-Off Table · thesignofftable.com/academy/sap-edi-209

Questions to ask the partner first

Before choosing, ask the partner precisely what it needs and why. Which EDI segment and qualifier should carry the value, on which level (header or line)? Is it mandatory for every document or only some? What happens on their side when it is missing? Great Lakes' answers shaped the design: the core agreement reference goes into a reference segment in each 810 line loop, it is needed only for alternators sold with a core deposit, and invoices without it are still accepted. That last answer made the segment optional and kept every other invoice unaffected.

SAP S/4HANA Cloud Public Edition does not give you the classic IDoc development transactions; integration there runs through released APIs and communication arrangements. Everything in this course applies to SAP S/4HANA Cloud Private Edition and on-premise, where Contoso runs.

Key points
  • Three options, lightest first: middleware mapping, an unused standard field, an IDoc extension.
  • Map when the value is constant or derivable from IDoc data; extend when it exists only in SAP and no standard field carries it.
  • Avoid synchronous lookups from middleware back into SAP for asynchronous interfaces.
  • Extensions are upward compatible, but their exit code is custom code: check it with ATC clean core checks.

Check your understanding · not graded

Lesson check

  1. 1. Lakeside wants Contoso's dock number on every 850, and Detroit has one dock for Lakeside. What is the better choice?

  2. 2. Why does the core agreement number for Great Lakes need an extension?

  3. 3. What should you check before creating any custom segment?