电商采购入库对接财务VMI采购入库（单号回写）实战教程

这个策略解决什么问题(场景与价值)

某零售企业的电商采购入库单下推到金蝶云星空后,会生成一张财务 VMI 采购入库单。如果不把金蝶侧生成的单据编号回写到 SQL Server 那一侧,两边数据就彻底断了:财务查账要翻两套系统,业务追溯也要靠人工对单号。这条策略只做一件事——单号回写,把金蝶 VMI 采购入库单号写回 SQL Server 采购入库单的集成单号字段,让源端和目标端随时可以互查。

数据流向与字段映射(源 → 中间层 → 目标)

策略的数据流向清晰:源端是轻易云集成平台(datahub)内部的回写记录,由 _autoFillResponse 自动填充;目标端是 SQL Server 的采购入库单表 T_STK_InStock。

关键字段对照表:

整个回写没有明细行(children),因为它只更新表头的一个字段,不做单据体的下推。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)上配置这条策略,有几个典型要点:

1. 源端接口选「请求空操作(QUERY)」,并把 autoFillResponse 设为 true。这样源端不需要外部请求,平台会自动从流程上下文中取出 sId、number、BillNo、Id、strategyId 这些字段。
2. 目标端接口选 update(EXECUTE),用 otherRequest.main_sql 写参数化 UPDATE 语句,而不是逐字段映射:
   sql复制代码

   update a1
   set F_CDPS_INTEGRATIONNO = :number
   from t_STK_InStock a1
   where a1.FID = :sId
   

3. main_params 由平台根据源响应自动组装,只要源字段名和 SQL 参数名一致(:sId、:number),即可完成绑定,不需要额外写脚本。
4. 编码映射集中管理:把 sId → FID、number → F_CDPS_INTEGRATIONNO 这类映射统一放在策略里维护,后续如果 VMI 单据类型变化,只改这一处。
5. 无需脚本逻辑(scripts):本策略所有映射都是 DIRECT 直接取值,不写 Python/JS 脚本,降低维护成本。

实施步骤(分阶段调度)

上线时建议按以下顺序推进:

• 阶段一:增量起点确认。前置策略「电商采购入库 → 金蝶 VMI 采购入库」必须先跑通,确保金蝶侧能生成 VMI 单号,平台流程上下文里才有 number 可回写。
• 阶段二:全量触发一次。首次上线时手动触发一次,把历史未回写的采购入库单一次性补齐,验证 SQL 是否正确执行、字段是否更新到位。
• 阶段三:调度频率配置。源端 cron 1 1 6 6 *(6 月 6 日 1 时 1 分,作为回写记录的产出节奏参考);目标端 cron 5-59/35 * * * *(每小时第 5、40 分钟扫描并执行 UPDATE)。这种增量与全量双轨的节奏,既保证日常低延迟回写,又能在异常后快速补单。
• 阶段四:对账验证。回写完成后,跑一段 SQL 校验 F_CDPS_INTEGRATIONNO IS NOT NULL 的覆盖率,以及与金蝶侧 number 的匹配率。

踩坑复盘

1. 典型错误是把回写当成「下推」。 这条策略只更新表头一个字段,没有 children。如果误以为它要带明细行,会写出循环映射,导致策略空转甚至报错。
2. sId 和 number 不能混用。 sId 是 SQL Server 的内码 FID,只走 WHERE 条件;number 才是金蝶侧的单据编码,只走 SET 赋值。一旦位置写反,会把别人的单号写到自己头上。
3. 空值回写会覆盖原值。 如果金蝶侧生成失败,number 为空,直接 UPDATE 会把已有的集成单号清空。稳妥的做法是先在 SQL 里加 AND :number IS NOT NULL,或者在策略里加前置过滤。
4. 调度频率要和前置策略对齐。 如果金蝶侧的下推策略是每小时一次,回写策略要晚于它启动,否则容易取到空 number。
5. 私有化部署下注意数据库权限。 SQL Server 账号需要对 T_STK_InStock 有 UPDATE 权限,以及对 F_CDPS_INTEGRATIONNO 字段所在 schema 的写权限,否则在轻易云上看不到失败明细,排查很费劲。

适用场景与不适用场景

适用:主表级单据号回写、跨系统单据关联追溯、对账字段补录、跨系统编码映射集中维护。 不适用:需要带回写明细行的场景、需要复杂业务校验(如金额、税额)的场景、以及一次性大批量初始化(应走全量同步策略而非单号回写)。