Filling and reading custom segments

The extension defines where the data goes; ABAP in a customer exit puts it there. SAP's outbound and inbound IDoc function modules call customer exits at defined points, and those exits are where custom segments are appended (outbound) or read (inbound). Searchers know them as the ORDERS05, INVOIC02 or DESADV "user exits".

Where the exits are

Customer exits are activated through an enhancement project in CMOD: you assign the SAP enhancement (for example LVEDF001) to a project, implement the include behind the function exit, and activate the project. SAP's documentation for extending outbound function modules walks through exactly this for MM06E001: project, component EXIT_SAPLEINM_002, include ZXM06U02, and the custom segment declared in the customer TOP include.

Finding and testing the right exit

Start in SMOD with the enhancement name and read the documentation of each function exit: when it is called, what it receives and what it may change. Then confirm the call point in practice. For outbound exits, output a test document in CMD and set a breakpoint in your include; for inbound exits, use WE19 with the inbound function module option in debug mode, which SAP provides exactly for developer tests of extended types. Some exits are called through dynamic calls, so a breakpoint in the calling function module is often the quickest way to see where the exit fires.

Write down what you found in the extension register: exit name, call point, the parameters you rely on. That note is what the next upgrade test checks first.

The outbound pattern

The data-segment exit is called once for every segment SAP adds to the IDoc. Your code therefore checks which segment was just added and appends the custom segment right after the right parent. SAP fills hierarchy level and parent segment number from the extension definition, so you only provide the segment name and data.

CASE int_edidd-segnam.
  WHEN 'E1EDP01'.
    " read the core agreement for this billing item (illustrative)
    DATA(ls_core) = zcl_cmc_core_agr_reader=>for_billing_item( ... ).
    IF ls_core IS NOT INITIAL.
      CLEAR int_edidd.
      int_edidd-segnam = 'Z1CMCCORE'.
      int_edidd-sdata = ls_core.
      APPEND int_edidd.
    ENDIF.
ENDCASE.

The sketch shows the shape, not a copy-paste solution: the exact parameters of EXIT_SAPLVEDF_002 and how you identify the billing item differ by release, so Kenji's developers read the exit documentation in SMOD first. Note the design choice: the include calls a small class, ZCL_CMC_CORE_AGR_READER, which reads the agreement through Contoso's own CDS view ZI_CMC_CoreAgreement. The include stays a two-line adapter; the logic sits in a class that can be unit-tested and checked by ATC.

The inbound pattern

Inbound exits work the other way round: SAP's inbound function module loops over the data records, and the exit receives segments it does not know so your code can read them and move the values into the application document, for example into a custom field on the sales order item. Two rules keep inbound exits safe: never let the exit raise an unhandled error (return a proper error status so the IDoc goes to 51 with a readable message), and never write SAP tables directly; use the document's own update logic or released interfaces.