12）¶

最后变更：2026-10-12 15:22

给开发的一句话：操作判别从「字段」改为「端点」，Request 微调，Response 完全重做。Host/凭据不变，三操作三个 URL。依据：Loi 2026-10-12 交付 txt（Integration Suite - SO Creation_20261012.txt）vs 9/21 六份 JSON 样本，逐字段脚本 diff，非肉眼比对。

0. 不变的部分¶

项	值
Host (Dev)	`https://dev-cqg6dbov.it-cpi012-rt.cfapps.ap21.hana.ondemand.com`
Auth	Basic（凭据见 txt，Dev 环境）
Method	全部 POST
ItemNumber 格式	请求仍发 `000010`（6 位），TPM 侧归一化逻辑保留
日期格式	ISO `2026-04-29`

1. 端点变化（核心）¶

操作	9/21 旧版	10/12 新版
Create	`/http/TPM/SO_CREATE` + 请求头 `OrderStatus="01"`	`/http/TPM/SO_CREATE`，无判别字段
Change	同一 URL + `OrderStatus="02"`	`/http/TPM/SO_CHANGE`
Reject	同一 URL + `OrderStatus="03"`	`/http/TPM/SO_REJECT`

⚠️ 命名陷阱（务必周知团队）：Loi/Eko 口中的 "Order Type" 指请求类型判别，其 JSON 字段名实际是 OrderStatus（已移除）。请求体里另有 OrderType（SAP 单据类型，ZF00/ZF01…）是另一个东西：Create 请求仍必须传，照字面删掉 SAP 定不了单据类型。

✅ 2026-10-12 11:49 已闭环：Eve 邮件质疑「Order TYPE 是建单必要条件」后，Loi 邮件书面改口「对不起。Eve 说的对。不是 OrderType。是 OrderStatus=01/02/03 已被移除」。Eve 的表述同时印证本表 §2.1/§2.2（Create 带 OrderType、Change 不带）。

2. Request 逐字段对照¶

2.1 Create SO（`SO_CREATE`）¶

变化	字段	说明
❌ 移除	头 `OrderStatus`	判别改由端点承担
❌ 移除	Item `ConfirmQuantity` / `MessageType` / `MessageText` / `RejectReason`	9/21 样本混入的响应字段，正式版清除
➕ 新增	头 `FlexibleField4` / `FlexibleField5`	启用范围待与 SAP 对齐
➕ 新增	Item `CrmSalesOrderNumber`	Item 层冗余携带 TPM 单号
➕ 新增	Item `Currency`	行级币别
✅ 保留	头 `OrderType`（ZF00）及其余全部头字段	单据类型照传

2.2 Change SO（`SO_CHANGE`）——瘦身最多¶

变化	字段	说明
❌ 移除	头 `OrderStatus`、`OrderType`	端点定操作；改单不允许换单据类型（语义合理）
❌ 移除	头 `SalesOrganization` / `DistributionChannel` / `Division` / `ReferenceSalesDocument`	销售组织等创建后不可改，改单不再携带
❌ 移除	Item `SoldTo`	改单不可换售达方；`ShipTo`/`Payer`/`BillTo` 保留
❌ 移除	Item `ConfirmQuantity` / `MessageType` / `MessageText` / `RejectReason`	同 Create
➕ 新增	头 `FlexibleField4` / `FlexibleField5`；Item `Currency`、`SapSalesOrderNumber`	Item 层冗余携带 SAP 单号

2.3 Reject SO（`SO_REJECT`）¶

变化	字段	说明
❌ 移除	头 `OrderStatus`	判别改由端点承担
➕ 新增	Item `SapSalesOrderNumber`	行级冗余携带 SAP 单号
✅ 保留	头 `SapSalesOrderNumber` + Item `ItemNumber`/`RejectReason`	极轻结构不变

3. Response：三操作统一重做（变化最大）¶

9/21 版 Response = 整包回显请求（全部头/行字段 + RequestNumber + SAP__Messages）；10/12 版改为瘦回执 + 消息明细：

{
  "@odata.context": "...",
  "@odata.metadataEtag": "W/\"20261009063751\"",
  "LogId": "000d3a08-...",              // ➕ 新增：本次调用日志 ID
  "SapSalesOrderNumber": "IX1D000222",  // ✅ 保留：成功回 SAP 单号
  "MessageType": "S|E|W",               // ✅ 保留：整单结果
  "MessageText": "...",
  "_MsgItem": [                          // ➕ 全新：逐条消息明细
    { "LogId": "...", "Sequence": "1", "MessageType": "S",
      "MessageId": "V4", "MessageNo": "233", "MessageText": "..." }
  ]
}

变化	字段	对开发的影响
❌ 移除	整包请求回显（头+行全部字段）	旧解析代码全部作废
❌ 移除	`RequestNumber`（头+行）、`SoDeletionFlag`、`SAP__Messages`	不再有
➕ 新增	`LogId`（头级+行级）、`_MsgItem[]`（Sequence/MessageType/MessageId/MessageNo/MessageText）	TPM 落库建议：LogId+全部 _MsgItem 存表，报错时凭 LogId 找 SAP 查日志
⚠️ 语义	`MessageType=E` 时 `SapSalesOrderNumber` 为空串	判空逻辑保留

消息明细样式（10/12 样本实测，V1=MessageId、239=MessageNo）： E V1 239 "Condition ZP01 cannot be entered manually" / E V1 415 "Reason for rejection Z2 is not defined"。

4. 联调前必须 SAP 关闭的两个配置问题（样本实测报错）¶

#	报错	影响	状态
1	`Condition ZP01 cannot be entered manually`（V1 239，Create/Change 都报）	0903 映射要求 TPM 传 ZP01 出厂价，当前定价过程禁手工录入。等 SAP 答复：改定价配置 or 改传参	🔴 开放项
2	`Reason for rejection Z2 is not defined`（V1 415，Reject 报）	S/4 未配 Z2 拒绝原因，值表也未交付	🔴 开放项

5. 状态查询（#6，新增交付）¶

端点：/http/TPM/GET_DO_BILLING（POST）
入参：SapSalesOrderNumber + CrmSalesOrderNumber
回参：CreditCheckStatus / DeliveryBlockStatus / DeliveryStatus / DelRelBillgStatus + _Items[]（SO 确认数量 / FreightOrderNumber / DONumber / DeliveryQty / PGITime / BillingNumber / InvoicedQty / 逐行 Message）
样本即信用冻结场景（CreditCheckStatus="B"，确认量 0）——TPM 侧按「W/E 均阻断取消」处理

6. 样本与依据文件¶

文件	说明
`Integration Suite - SO Creation_20261012.txt`	三端点+样本（本表唯一依据）
`Integration Suite - DO & Billing Status_20261012.txt`	#6 查询端点+样本
`Create/Change/Reject SO Request\|Response.txt`（9/21 版）	旧版对照基准
`Eko_OrderType澄清截图_20261012.jpg`	"Order Type=请求类型判别" 口语佐证（早期 IM 证据）
Loi 2026-10-12 11:49 邮件改口	书面确认：移除的是 `OrderStatus`，`OrderType` 保留（见 §1 命名陷阱闭环）

🔗 关联¶

SO接口规格变更_多端点交付_20261012 — 变更邮件全记录
决策_TPM-SD接口 — 技术口径权威记录