Wiring the extension

A released extension is still invisible to processing until three assignments tell SAP when to use it: the message type assignment, the partner profile and, for inbound, the function module assignment. Middleware then needs the new structure too. Missing one of these produces the classic symptoms: no custom segment, or IDocs failing the syntax check.

WE82: message type, basic type, extension, release

In WE82 you assign the logical message type to the basic type and extension for a release: INVOIC, INVOIC02, ZCMCINV1 and your system's release. SAP's IDoc type editor reminds you of this step because the partner profile checks it later; without the assignment, WE20 refuses the extension for that message type.

WE20: the partner profile names the extension

The outbound parameters for Great Lakes Fleet Services (KU 17100001, message type INVOIC) get the extension in the Extension field next to basic type INVOIC02. Only partners whose profile names the extension receive the custom segment; every other customer keeps receiving plain INVOIC02. That is how one extension serves one partner without affecting others.

Inbound: WE57

For inbound extensions, SAP's checklist adds one step: in WE57, assign the inbound function module to the basic type, extension and message type, with direction 2, so the function module is registered to process the extended type. SAP's own example assigns IDOC_INPUT_ORDERS to ORDERS01 with an extension for message type ORDERS. Without this, extended inbound IDocs cannot be passed to the application.

Middleware and documentation

Process Orchestration 7.5 works from the IDoc structure it imported. After the extension is released in CMD and transported to CMQ, Theo's team reimports the extended IDoc structure for INVOIC02 with ZCMCINV1 into the Enterprise Services Repository and refreshes the IDoc metadata the adapter uses, then extends the 810 mapping: Z1CMCCORE-CORE_AGREEMENT becomes a reference in the item loop of the 810, using the qualifier Great Lakes specified. The partner specification is generated from WE60, which documents the basic type with the extension, including the segment documentation written in WE31.

Testing the wiring before the first real invoice

Each assignment can be tested on its own in CMQ before any partner sees the extension. Check WE82 by opening the partner profile line in WE20 and entering the extension; WE20 rejects it if the assignment is missing. Check the outbound side by outputting a test billing document for Great Lakes and opening the IDoc in WE02: the control record must show basic type INVOIC02 with extension ZCMCINV1, and an item with a core agreement must show Z1CMCCORE as its child. Check middleware by sending that IDoc through XQ1 and reading the 810 in the message monitor.

Partner profiles deserve a note on transports. Many teams maintain partner profiles directly in each system rather than transporting them, because partner numbers, ports and destinations differ between CMQ and CMP. Contoso keeps a partner profile checklist per system for exactly that reason, and the extension's rollout plan includes a dated step to switch the production profile to ZCMCINV1 on the day Great Lakes is ready, not on the day the transport is imported.