场景2 · 本地供应商采购 — Pentana vs 新POTD 系统对照(代码级验证版)

执行摘要

本地采购场景链路已通可切换(配置/迁移为准)

核心结论(已代码级验证):新POTD本地采购链路从下单到SAP记账全链贯通,0个致命缺陷。两处关键SAP落点(建在途采购PO、GR记账)由 order-tool 承担(营销服中台的订单工具服务),已代码级验证。剩余均为配置/迁移/行为对齐事项。

致命Gap 🔴

配置/迁移项 🟡

链路节点已验证

涉及系统数

范式级差异:Pentana是单体系统(采购/库存/AP/GL在一处闭环);新链路是分布式——POTD薄编排(下单) + 订单中台(交易/履约) + order-tool(SAP推送补偿) + OTWB(仓储) + SAP(业财一体) + 商品中心(主数据) + GODP(总部网关)。从1个系统变成7个系统协同。

一、切换收益:本地采购链路的能力跃升

先看结论——切换后本地采购链路能带来哪些 Pentana 做不到的能力提升(均代码级可证);其后各节为得出此结论的过程证据。本节列本场景独有能力;推送失败自动补偿、CQRS 读写分离查询、多品牌多租户并行等为全链路通用能力(与总部采购共享),不再单列。

下单即流转、免多道手续

本地采购提交即 SUBMITTED→DELIVERY_PROCESSING→DONE,中台状态机无审批闸门、无独立下达环节,链路精简、流转快。

Pentana:本地采购仍走 APRT/02+HE201 审批 + PU802 打印下达两道手续,人工节点多。

供应商编码三端一致

8 开头 7 位间采平台码在 POTD / SAP / OTWB 三端保持一致,主数据一处申请、全链共用,杜绝各系统各自维护导致的不一致。

Pentana:供应商主档(AP404)在本系统内维护,与外部系统编码各自管理、易脱节。

状态变更实时事件驱动

MQ(mcs_order_status_change)将状态变更广播到所有下游(OTWB / SAP / 查询),下游自动响应,业务无需手工触发或轮询单系统。

Pentana:状态全靠人在单系统内查询、手工推进下游动作。

入库自动推送 OTWB、收货动作下沉

创建 ASN 履约单后自动下发 OTWB 入库单,入库回调自动回写签收数量(outboundQuantity),收货动作下沉专业仓储系统执行。

Pentana:收货靠人工在 SH204 操作 Land→Receipt→Binning 全流程,采购/库存/AP/GL 挤在同一系统。

二、代码级链路验证(本次核心增量)

备件本地采购 LOCAL_PURCHASE(orderType=7)端到端链路,每步标注实现系统 + 代码证据。✅ 全部已验证。

Pentana → 新链路 8步对照(含证据)

🔑 审批环节坐实(代码级):订单中台侧备件LOCAL_PURCHASE无审批闸门——状态机 SpareLocalPurchaseEMOrderStateMachine(CREATED→SUBMITTED→DELIVERY_PROCESSING→DONE)所有transition的perform全为null,approve_status字段不初始化,MSS财务审核零命中。SUBMITTED=已提交即可履约/可推SAP,非"待审"。POTD侧有UNDER_MSS_FINANCE_REVIEWING等审核状态枚举,但LOCAL的confirm/resubmit是空实现。即备件本地采购在新链路里无自动审批(对比Pentana APRT/02+HE201审批闸门)——这是真实差异,见 Gap-3。

建采购单 + 提交 [新POTD → 订单中台]

POTD调订单中台 createOrder 建 orderType=7/LOCAL 采购单(CREATED),提交后 CREATED→SUBMITTED。订单中台侧无审批闸门(状态机perform全null,提交校验只做渠道/付款/商品)。采购单本体落订单中台,POTD是薄编排层。

POTD: LocalPurchaseOrderStrategy.createOrder → 中台 /v2/order createOrder;状态机 SpareLocalPurchaseEMOrderStateMachine(CREATED→SUBMITTED);提交校验 OrderSubmitCheckPotdLocalPurchaseExtPt

建ASN履约单(=运单) [订单中台]

POTD再调中台建履约单,类型 SendTypeEnum.LOCAL_PURCHASE(40,"本地采购ASN-Local")——印证 ASN-Local 即本地采购履约。

中台: FulfillmentNoteCreateCmdExe / FulfillmentNoteCreateV2CmdExe,SendTypeEnum:35

OTWB入库单下发 [订单中台 → OTWB]

中台主动下发OTWB创建待入库入库单(非OTWB自建)。

中台: SendNoteServiceImpl.syncOtwb → OtwbManager.sendSync(sendNoteNo)

SAP建在途采购PO ✅ [order-tool → SAP/GBOP]

order-tool的XXL-Job定时拉 orderStatus=SUBMITTED 的备件本地采购单,组装DTO走GBOP调SAP ZMM_RECEIVE_LCLPO,request_system=POTD。BSART按国家配置(注释ZNB=本地化采购),与整车ZSTO区分。LIFNR=sellerId透传(样本8100000,8开头7位)。

order-tool: BspLclpoInfoSyncJob(functionLclpoInfoWithSyncJob) → BspLclpoOrderPushComponent → GbopDataRemoteWrapper.pushLclpoDataToSap, interfacename=ZMM_RECEIVE_LCLPO

OTWB入库完成回调 [OTWB → 订单中台]

OTWB完成入库后回调中台,v1/bizevent(scenario=otwb)。

中台: InOutBoundLocalPurchaseHandleExt.handle(@Extensions scenario=LOCAL_PURCHASE=7)

签收累加(支持部分签收) ✅ [订单中台]

入库回调type=0(入)→actualQty累加;状态机 45=部分签收 / 50=已签收。非必须全量——证伪了原Gap-5。

中台: ExternalSignedTask/handleQuantitySigned, QuantitySignBodyBuilder(cumQty/signNum), SendNoteHead状态机

中台落GR待推表 [订单中台]

签收后中台按配置(sap.bizTypes.23.localPurGrPushCountries)写 ThirdPartyPushData,bizType=23(SEND_NOTE_TO_GR),ext含inboundTime/orderItems(actualQty/actualNGQty)。中台到此为止,不直接调SAP。

中台: InOutBoundLocalPurchaseHandleExt.createThirdPartyPushData, PushBizTypeEnum.SEND_NOTE_TO_GR(23)

推SAP GR记账 ✅ [order-tool → SAP/GBOP]

order-tool的XXL-Job扫bizType=23待推数据,组装GoodsReceiptDTO调SAP ZMM_01_GRGI_INFO_SAVE(=EVO_MM_GRGI_INFO_SAVE接口族,存表ZTSD_WTS_*),逐条按sendNoteNo推送,支持部分签收actualQty/actualNGQty。三种场景:本地采购GR/国际采购GR/本地内部非转直发GR。

order-tool: SyncByBizTypeJob(sapSyncByBizTypeJob) → SyncByBizTypeCommonExtPt(@Extensions bizId=23) → SapRemoteWrapper.pushGoodsReceipt(@Retryable maxAttempts=3)

✅ 链路判定:Pentana单体闭环(采购/库存/AP/GL)映射到这条分布式链路上是齐的。下游 SAP VIM 三单匹配+付款+GL在SAP侧闭环(财务全切SAP)。

⚠️ 两个触发时机特点:①建PO和②GR记账都是 order-tool 的 XXL-Job定时拉取(非实时事件驱动),有延迟;失败有补偿Job和HTTP重推入口。需确认业务对延迟的容忍度。

三、营销服中台全景(本次新识别)

此前6系统全景里未包含"营销服中台"。本次考古确认其4个项目各自角色——其中 order-tool 是本地采购SAP推送的真正落点。

order-tool 核心·已验证

极氪"订单工具"微服务。订单数据向三方系统(SAP/GODP/OTWB/履约/商品/价格)的同步推送与补偿重推层,本身不做订单核心交易。代POTD把本地采购单推SAP(request_system=POTD)。承担:①建在途采购PO(ZMM_RECEIVE_LCLPO)②GR记账(ZMM_01_GRGI_INFO_SAVE)。主动外调型,入站靠RocketMQ+HTTP补偿入口。

order-boss(=order-query) 读侧·不参与写链路

订单/履约/发票/附件的CQRS查询聚合读侧。消费订单中台+履约中台的数据同步MQ(boss_order_data_sync/boss_fulfillment_data_sync)→写入MySQL+ES,对外暴露查询Feign。不参与LOCAL_PURCHASE写链路。

data-factory 运输聚合·不参与

窄义物流运输状态聚合管道。从 chennault-core(TMS) 拉发运状态→聚合表,供运输状态查询。不参与备件本地采购链路。

data-correct-script 运维工具·不参与

Python运维刷数/批量接口调用工具集(非应用服务)。通过HMAC签名HTTP调 order-tool/order-query/chennault-core 网关API。有EU备件SAP同步/OTWB行号等运维补推脚本,但非采购下单链路。

四、角色 / 组织映射

Pentana 角色/对象	新链路对应	映射说明
澳洲子公司(买方)	`buyerId`→KUNNR	子公司=买方,SAP公司代码BUKRS
本地供应商	`sellerId`→LIFNR	间采平台8开头7位(样本8100000),POTD/SAP/OTWB三端一致;order-tool透传sellerId
收货仓库	WarehousePO + OTWB仓库 + `WERKS/LGORT`	Pentana单仓;新链路仓库经OTWB执行,映射SAP工厂/库存地点
计划员码 HE407	数据权限走NDR公司列表	Pentana用计划员码闸门,新链路用公司数据权限
AP录发票员/出纳	SAP VIM/付款侧	财务全切SAP
多品牌隔离	`tenant_id`+`brand_code`(GEELY/ZEEKR/LYNKCO)+市场(EM/EU)+`ZBRAND`(G/L/Z)	Pentana无多品牌多租户概念

五、端到端流程对比(Pentana vs 新分布式链路)

步	Pentana	新链路(已验证)
0	主数据:AP404供应商(TRCR/BANK);IC402物料;INPR026采购价;HE407计划员	商品中心主数据/价格(orderType=ZF01);SupplierPO;间采平台供应商code三端一致;WERKS/LGORT配置
1	PU202建PO(Order Type=L),PO号APO-#####,PO就是采购凭证本体	POTD调中台createOrder建采购单(orderType=7);采购单本体在中台;order-tool后续推SAP建在途PO
2	PU802打印下达给供应商	建ASN履约单(SendType=40 ASN-Local);POTD的release方法对LOCAL无害(下达语义由采购单SUBMITTED+履约单承担)
3	SH204收货:Land→Receipt→Binning→ActualCost;POCT控制完成时机	中台下发OTWB入库单→OTWB入库完成回调中台→签收累加(状态机45部分/50已签收)
4	AP202三单匹配(PO+收货+发票),INVVARTH容差	SAP VIM侧闭环;中台落GR待推表→order-tool推SAP GR记账(ZMM_01_GRGI_INFO_SAVE)
5	AP208授权(Payment authorised闸门)	SAP付款侧配置授权环节
6	AP210付款批→AP212释放→AP214支票→AP207呈兑	SAP付款侧闭环
7	自动GL AP批:DR费用/DR税/CR TRCR;收货过SIT→INAC	order-tool推SAP GR记账触发入账;发票/付款/GL全在SAP
8	PO关闭标志Y;PU602欠交	签收状态机50=已签收;部分签收45

六、状态机对比

Pentana(单体三段式)

PU202建PO ──(APRT/02+HE201审批)──> PU802打印下达 │ ▼ SH204收货[Land→Receipt→Binning→ActualCost] │ POCT: 1=落地完成/2=收货完成 → PO关闭Y ▼ AP202三单匹配 → AP208授权(闸门) │ ▼ AP210付款批 → AP212释放 → AP214支票 → AP207呈兑 │ ▼ GL AP批(EOD自动) PO: open/closed(Y) AP发票: O→Q→P / A / C

新分布式链路(多系统协同)

POTD建采购单 ──> 中台createOrder(orderType=7, CREATED) │ POTD提交 → SUBMITTED(无审批闸门!状态机perform全null) ▼ SUBMITTED → MQ msc_fulfillment_created 通知履约 │ POTD建ASN履约单 ──> 中台(SendType=40 ASN-Local) │ order-tool定时Job拉SUBMITTED │ ──GBOP──> SAP ZMM_RECEIVE_LCLPO 建在途采购PO ✅ │ ▼ 中台OtwbManager.sendSync ──> OTWB待入库单 OTWB入库完成 ──回调中台──> InOutBoundLocalPurchaseHandleExt │ actualQty累加, 状态机 45=部分签收/50=已签收 ▼ 中台落ThirdPartyPushData(bizType=23)待推 order-tool SyncByBizTypeJob定时拉 │ 逐条按sendNoteNo推送(支持部分签收) ▼ ──GBOP──> SAP ZMM_01_GRGI_INFO_SAVE GR记账 ✅ SAP VIM三单匹配 + 付款 + GL(财务全切SAP)

七、10维度差异全景(修正版)

原评级经代码级验证后修正。🟢已验证对齐 / 🟡配置/迁移/行为对齐 / 🔴缺失(本次:0)

维度	评级	核心差异(修正后)
1 触发与前置主数据	🟡	供应商code三端一致✓;IC406参数体系(TRCR/INVVARTH)→SAP科目映射;WERKS/LGORT配置
2 单据创建	🟢	POTD→中台建采购单已验证;采购单本体在中台是设计
3 审批流	🟡	订单中台侧备件LOCAL无审批闸门(状态机perform全null,提交即SUBMITTED);POTD侧审核状态枚举存在但LOCAL空实现。真实差异:Pentana有APRT/02+HE201审批,新链路无自动审批——需确认业务是否需要
4 状态机	🟢	签收状态机45/50已验证;状态分散在POTD+中台+order-tool+OTWB+SAP
5 库存动作	🟢	OTWB入库单由中台下发✓;入库回调+签收累加✓;架构设计成立
6 物流/运输	🟡	本地供应商运输是否走OTWB/data-factory(chennault-core)待确认
7 财务记账	🟢	AP 应付职责迁移:Pentana 自持 AP(AP202录发票/AP208授权/AP210付款/内部GL)→ iParts 无财务能力,建PO(ZMM_RECEIVE_LCLPO)+GR(ZMM_01_GRGI_INFO_SAVE)在order-tool,发票/付款/VIM/GL全在SAP
8 上下游集成	🟡	7系统分布式,集成链路稳定;order-tool有@Retryable+补偿Job兜底;建PO/GR为定时Job有延迟
9 异常处理	🟡	部分签收支持✓;order-tool补偿重推入口;mismatch机制培训
10 查询报表	🟡	order-boss读侧聚合查询✓;跨系统对账取数

八、关键差异点解析(代码级)

备件本地采购链路的5个关键差异点,均已代码级验证。🟢已验证对齐/设计如此;🟡真实差异,需业务决策。

SAP建在途采购PO 由 order-tool 承担

order-tool的 BspLclpoInfoSyncJob 定时拉 SUBMITTED 状态的备件本地采购单,组装DTO走GBOP调SAP ZMM_RECEIVE_LCLPO(request_system=POTD)。BSART按国家配置(注释ZNB=本地化采购),与整车ZSTO区分。LIFNR=sellerId透传(8开头7位,样本8100000)。

下达由采购单SUBMITTED + ASN履约单承担

下达语义由"采购单提交(SUBMITTED)+ ASN履约单创建(SendType=40 ASN-Local)"承担,order-tool拉SUBMITTED建SAP PO。POTD的release方法对LOCAL无害(LOCAL不走该状态转换)。

审批订单中台侧无审批闸门(真实差异)

订单中台 SpareLocalPurchaseEMOrderStateMachine(CREATED→SUBMITTED→DELIVERY_PROCESSING→DONE)所有transition perform全null,approve_status不初始化,MSS财务审核零命中。备件LOCAL提交即SUBMITTED,无审批环节。POTD侧有UNDER_MSS_FINANCE_REVIEWING枚举但LOCAL的confirm/resubmit空实现。真实差异:Pentana有APRT/02+HE201审批闸门,新链路无自动审批——需确认业务是否需要审批闸门(若需要,在POTD或中台补;若不需要,提交即生效也合理)。

收货 OTWB入库+回调,设计如此

OTWB入库单由中台下发(OtwbManager.sendSync);入库回调→签收累加;PartInventoryPO作可用量缓存是设计;库存权威在OTWB。

GR记账逐条推送,支持部分签收

采购GR记账在order-tool:SyncByBizTypeJob扫bizType=23待推数据→SapRemoteWrapper.pushGoodsReceipt调SAP ZMM_01_GRGI_INFO_SAVE(=EVO_MM_GRGI_INFO_SAVE族),逐条按sendNoteNo推送,支持部分签收actualQty/actualNGQty。状态机45=部分签收/50=已签收。

AP 应付职责迁移 Pentana 自持 AP → SAP(四场景统一)

Pentana 自持 AP、自己录发票/付款,内部 GL 闭环:供应商发票 AP202 录入→AP208 付款授权闸门→付款 AP210 批→AP212 释放→AP214 支票→AP207 呈兑(本币);自动 GL AP 批(DR费用/DR税/CR TRCR,收货过 SIT→INAC)。AP/付款/GL 全在 Pentana 内部 GL Interface 闭环,无外部财务对接。iParts 无财务能力,AP 全推 SAP:建 PO(GODP/DCS_BJORDER)+ GR 记账(order-tool ZMM_01_GRGI_INFO_SAVE)在 iParts 侧,供应商发票/付款/VIM 三单匹配/GL 全在 SAP。迁移含义:AP 应付职责从 Pentana 内部迁到 SAP;AP 录发票员/出纳从 Pentana 转 SAP VIM/付款侧;历史 AP/付款/GL 数据迁移。联动场景3(正向发票)/场景4(红冲):Pentana 自持 AR/AP → iParts 财务全切 SAP,四场景统一职责迁移点。

九、切换必做动作(均为🟡配置/迁移,无🔴开发断链)

确认备件LOCAL是否需要审批闸门:订单中台侧已坐实无审批(提交即SUBMITTED,状态机perform全null);对标Pentana APRT/02+HE201——若业务需要审批,在POTD或中台补审批节点;若不需要,提交即生效
SAP侧配置:VIM三单匹配规则+容差(对标INVVARTH)、付款授权闸门(对标Payment authorised)、GR多次接收策略
科目映射:Pentana IC406/IC408(TRCR/BANK/TAXC/SIT/INAC/PVAR)→SAP科目完整映射表(财务迁移核心交付物)
配置澳洲:companyCode/brandCode/市场(EM/EU?)/WERKS/LGORTF;BSART按国家配置(Nacos smpCompareSapProperties.bspLcl..bsart,确认澳洲值)
数据迁移:供应商主档(sellerId/LIFNR已一致✓,TRCR应付科目需配)、物料主档(→商品中心)、未清PO/收货/发票余额
确认触发时机容忍度:建PO和GR记账是order-tool定时Job(非实时),有延迟;确认业务可接受+补偿Job配置
培训:mismatch机制、状态分散查询(POTD+中台+order-boss+OTWB+SAP)、跨系统对账
AP 应付职责迁移培训(四场景统一):Pentana 自持 AP(AP202录发票/AP208授权/AP210付款/内部GL)→ iParts 财务全切 SAP(VIM三单匹配+付款+GL);AP录发票员/出纳从 Pentana 转 SAP 侧操作;历史 AP/付款/GL 数据迁移。联动场景3(正向发票)/场景4(红冲)职责迁移

十、待确认问题

备件LOCAL采购是否需要审批闸门?订单中台侧已坐实无审批(提交即SUBMITTED,状态机perform全null);Pentana有APRT/02+HE201审批——业务是否需要在新链路补审批环节?
澳洲子公司在POTD的companyCode/brandCode/市场(EM还是EU)?BSART澳洲配置值?
本地供应商运输是否走OTWB/data-factory(chennault-core),还是直接子公司仓收货?
SAP VIM三单匹配容差如何配置(对标INVVARTH)?付款授权(Payment authorised)在SAP如何对应?
order-tool定时Job的推送延迟(建PO/GR记账)业务能否接受?补偿Job频率配置?
Pentana IC406/IC408科目→SAP科目映射由谁出(财务团队)?
AP 应付职责迁移(四场景统一):Pentana 自持 AP(AP202/AP208/AP210付款/内部GL)→ iParts 财务全切 SAP。AP录发票员/出纳从 Pentana 转 SAP VIM/付款侧,操作流程/对账/历史数据迁移如何承接?联动场景3正向发票/场景4红冲职责迁移
部分签收的GR推送:SAP侧是否接受多次GR(逐批),还是需聚合?
ZMM_01_GRGI_INFO_SAVE 与文档侧 ZSDI_WTS_MIGO/EVO_MM_GRGI 的字面等价(代码无直接证据,仅从存储表ZTSD_WTS_*推断同族)需SAP侧确认

场景2 · 本地供应商采购 — Pentana vs 新POTD 对照(代码级验证版)