# SAP ECC IDoc Extension and Custom Segment Checklist > Source: https://netray.co/tools/sap-ecc-idoc-custom-segment-extension-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Design, build, fill, configure and test a custom IDoc segment in SAP ECC: WE31, WE30, WE82, user exits, WE20 partner profiles and WE19. ## Category developer ## Erp SAP ECC 6.0 ## Audience - ABAP developer - SAP integration consultant - EDI analyst ## Tool **Kind:** checklist **Groups:** #### Design **Items:** Extend the existing basic type (for example ORDERS05, MATMAS05) rather than copying it to a new basic type Name the segment type in the customer namespace (Z1...); its definition gets a versioned name (Z2...000) **Text:** Define all fields as character-type; the segment data area is limited to 1000 characters **Critical:** true Decide the parent segment, minimum and maximum occurrences in the extension Agree the field mapping with the partner or middleware before building #### Build **Items:** **Text:** Create the segment in WE31 and set it to released (Edit > Set release) once final **Critical:** true Create the extension type in WE30 (choose Extension), link it to the basic type and add the Z segment under the right parent Release the extension in WE30 **Text:** Assign message type, basic type, extension and release in WE82 **Critical:** true Check the structure in WE60 (IDoc documentation) Put the segment, extension and WE82 entry in one transport request #### Fill and read logic **Items:** Inbound sales orders (ORDERS, process code ORDE, IDOC_INPUT_ORDERS): read the Z segment in enhancement VEDA0001, for example EXIT_SAPLVEDA_001 Outbound purchase orders (ORDERS from MM, process code ME10): fill the Z segment in enhancement MM06E001, EXIT_SAPLEINM_002 Outbound material master (MATMAS via ALE): fill the Z segment in enhancement MGV00001, EXIT_SAPLMV01_002 **Text:** Confirm the exit name and its interface in SMOD on your release before coding **Critical:** true Append the Z segment after its parent segment with the correct SEGNAM and HLEVEL handling the exit expects Use segment filtering (BD56) or reduced message types (BD53) only where they do not drop your new segment #### Partner profile and runtime **Items:** **Text:** Enter the extension name in the outbound parameters of the partner profile in WE20 **Critical:** true Inbound: the extension comes from the control record field CIMTYP sent by the partner; check the partner sends it Check the port in WE21 and the process codes in WE41 (outbound) and WE42 (inbound) For ALE, check the distribution model in BD64 and regenerate partner profiles if needed #### Test and transport **Items:** Test with WE19 using an existing IDoc as a template and the new extension Monitor in WE02 or WE05; check the Z segment appears with the expected data **Text:** Status 26 (outbound) or 60 (inbound) means a syntax error: check segment order, occurrence and extension name **Critical:** true Reprocess test IDocs with BD87 after a fix Transport segment, extension, WE82 entry, exit code and CMOD project activation to QAS and PRD together Create the WE20 partner profile entries in each system if they are not transported **Scoring Note:** Critical items are the usual reasons a new segment never appears: unreleased segment, missing WE82 assignment or extension in WE20, a wrong exit or a syntax error from segment order. ## Content **Intro:** This checklist covers adding a custom segment to a standard IDoc in SAP ECC 6.0: designing the segment, building it in WE31, WE30 and WE82, filling or reading it in a user exit, setting up partner profiles and testing. It is written for ABAP developers and integration consultants extending ORDERS, MATMAS and similar IDocs. **Sections:** #### How IDoc extensions work **Body:** A basic type such as ORDERS05 is SAP's fixed structure. An extension type adds customer segments to it without changing SAP's definition, so upgrades are unaffected. The segment is created in WE31 as a segment type (Z1...) with a versioned definition (Z2...000). WE30 builds the extension: you choose the basic type, add the Z segment under the right parent and set occurrences. WE82 ties message type, basic type, extension and release together. At runtime the control record carries the basic type in IDOCTP and the extension in CIMTYP, which is how the receiver knows to expect the new segment. **Bullets:** - WE31: segment editor - WE30: basic types and extensions - WE82: message type assignment - WE20: partner profiles, WE21: ports #### Filling and reading the segment **Body:** Standard function modules do not know your segment, so you fill or read it in an exit. For inbound sales orders through IDOC_INPUT_ORDERS, enhancement VEDA0001 offers EXIT_SAPLVEDA_001 to read segment data into the order structures. For outbound purchase orders created through message control, enhancement MM06E001 offers EXIT_SAPLEINM_002 to append segments. For MATMAS sent through ALE, enhancement MGV00001 offers EXIT_SAPLMV01_002. Implement them in a CMOD project, and always confirm the exit and its parameters in SMOD on your release, because interfaces differ between IDoc functions. #### Worked example: ZORDERS05EXT **Body:** A customer sends a line-level drawing revision. The team creates segment Z1DRAWREV with fields DRAWNO (CHAR 25) and REVLEV (CHAR 2) in WE31 and releases it. In WE30 it creates extension ZORDERS05EXT on ORDERS05 with Z1DRAWREV under E1EDP01, occurrences 0 to 1, and releases it. WE82 assigns ORDERS, ORDERS05, ZORDERS05EXT and the release. The partner adds CIMTYP ZORDERS05EXT to its control record. EXIT_SAPLVEDA_001 reads the segment and fills a custom field on the item. WE19 testing shows status 53 with the revision on the order. #### Common mistakes **Body:** Forgetting to release the segment, so it cannot be transported or used in production. Adding the extension in WE30 but not in WE82, which produces syntax errors. Leaving the extension field blank in the outbound WE20 parameters. Using non-character field types. Coding in the wrong exit and seeing nothing in the IDoc. Testing only in WE19 without a full end-to-end run through message control or ALE. **Cta:** If you want your integration team to ask ECC about IDoc volumes, errors and segment contents in plain English on your own servers, we can set that up. **Faq:** #### How do I add a custom segment to an SAP IDoc? **Answer:** Create and release the segment in WE31, create an extension in WE30 on the basic type with the segment under the right parent, assign message type, basic type and extension in WE82, fill or read the segment in the relevant user exit, set the extension in the WE20 outbound partner profile, and test with WE19. #### Which user exit is used for inbound ORDERS IDocs? **Answer:** Inbound ORDERS uses function module IDOC_INPUT_ORDERS. Its customer exits are in enhancement VEDA0001; EXIT_SAPLVEDA_001 is commonly used to move custom segment data into the order. Check the exits listed in SMOD for VEDA0001 on your release to pick the one called at the point you need. #### Why do I get status 26 after adding an extension? **Answer:** Status 26 is a syntax error in an outbound IDoc. Typical causes are a segment in the wrong position, too many occurrences, an extension not assigned in WE82 or not named in the partner profile, or an unreleased segment. Compare the IDoc in WE02 with the structure in WE30 or WE60. #### Should I copy a basic type or create an extension? **Answer:** Create an extension. Copying a basic type to a Z basic type cuts it off from SAP's later versions and from the standard IDoc functions, while an extension keeps the standard processing and only adds your segments. A new basic type makes sense only for fully custom message types. ## Search terms sap idoc custom segments, sap idoc extension, sap idoc configuration, sap idoc customizing, sap idoc integration steps, sap user exit for inbound idoc, we30 extension we31 segment, exit_saplveda_001 --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json