IDoc与XML映射必须显式配置字段级映射，因二者无默认语义关系；扩展字段、控制记录、空值、长度不一致等均需手动处理，否则导致丢失、报错或截断。
IDoc 与 XML 的映射不是自动对齐的，必须显式配置字段级映射，否则扩展字段、控制记录、空值处理都会出问题。
为什么不能直接“转换”？
IDoc 是 SAP 特有的二进制/结构化数据容器，XML 是通用文本格式。两者之间没有默认语义映射关系——SAP 系统导出的
XML 并不天然包含你定义的
，也不保证
控制段字段被正确填充到目标 XML 的对应节点中。
XML Schema（XSD）由 IDoc 类型 + 扩展类型生成，但仅反映结构，不携带业务逻辑或默认值
IDoc 扩展字段（如
）在 XML 中表现为嵌套子元素，若未在消息映射中显式拖入，就会被忽略
控制记录（
）字段如
、
默认不参与数据映射，需单独启用
或通过 ASMA 配置
PO/CPI 中映射扩展字段的实操要点
以 SAP PO（Process Orchestration）为例，IDoc 扩展字段丢失最常见于消息映射（Message Mapping）漏配：
确认源结构中已展开
和
（注意命名空间和层级）
目标 XML 中对应字段必须手动拖入，不能依赖“自动匹配”——工具不会猜你想要
映射到
若字段在 IDoc 中为空，且目标是必填项，需在映射中加
或默认值函数，否则生成 XML 时该节点可能完全缺失
字段长度不一致会静默截断：比如 SAP 中
是 CHAR(30)，但目标字段只定义为
，PO 可能丢弃超长部分而不报错
JCo 解析 XML 到 IDoc 时的扩展字段报错
错误如
，本质是控制记录声明与实际 XML 根节点不一致：
React Native For Android 源码编译 中文WORD版
本文档主要讲述的是React Native For Android 源码编译；希望对大家会有帮助；感兴趣的朋友可以过来看看
下载
值必须严格等于 XML 根元素名（如
），不能是
或
字段必须填入扩展类型名（如
），且该扩展必须已在 SAP 系统中注册并激活
JCo 的
不跳过根节点校验，所以即使你用这个 flag，只要
和根标签不匹配，仍会失败
CPI/XSLT 场景下定长输出的映射陷阱
当用 XSLT 把 IDoc XML 转成定长纯文本（如发送给 legacy 系统），映射逻辑必须处理填充、截断、
编码
三件事：
不要用
简单截取——要先
去首尾空格，再补足空格至固定长度
IDoc 中日期字段如
是
格式，但目标系统可能要求
，需用 XSLT 函数重排，不能靠字符串位置硬切
中文字符在 UTF-8 下占 3
字节
，但定长文件常按字节计长；若目标是 GBK 编码，一个汉字只占 2 字节，映射前必须明确编码上下文
最容易被忽略的是：IDoc 控制记录字段（如
）在 CPI 的 XSLT 里默认不可见，除非你把整个
当作源结构传入，否则连读都读不到——它不在业务数据段里，得单独从消息头或 ASMA 提取。
DEBMAS05ZEXT_FIELD2EDI_DC40ZDEBMAS3EDI_DC40RCVPRNRCVPRTApply Control Records from PayloadidocData/EDI_DC40idocData/ZDEBMAS3ZEXT_FIELD2/Customer/ExtField2ifWithoutElseZEXT_FIELD2xs:string maxLength="10"IDocParseException: IDoc type extension ZDEBMAS3 within the EDI_DC40 control record segment does not match the IDoc-XML root tag EDI_DC40/IDOCTYPDEBMAS05DEBMASZDEBMAS3EDI_DC40/EXTENSIONZDEBMAS3PARSE_IGNORE_UNKNOWN_FIELDSEXTENSIONEDI_DC40 segment example:
DEBMAS05
ZDEBMAS3
substring()normalize-space()CREATyyyymmdddd.mm.yyyyEDI_DC40/SNDPRNidocData