金蝶调入单备注回写旺店通单号:一条轻量策略的实战拆解

这个策略解决什么问题

在零售与分销链路里,某零售企业同时跑着前端电商仓的旺店通与后端财务库存的金蝶云星空。调拨入库时,金蝶这边落了一张「调入单」,旺店通那边有一个出库单号,两边靠人工在备注里互相补号,跑个两三周就会对不上账——仓管说单号漏填,财务说系统里查不到,排错只能靠翻聊天记录。

这条策略就是把这步「补号」自动化:把旺店通的单号自动写到金蝶调入单的备注或自定义字段里,不需要人参与,账也自然对得上。

数据流向与字段映射

整条链路是「MySQL → 轻易云 → 金蝶云星空」,方向是单向回写。

源端那一步看似只是 QUERY,没有请求体,但它真正的作用是「从 MySQL 把记录拉到轻易云上下文里」——idCheck=true 让 order_no 充当主键,保证同一条单据不会被反复拉起。

目标端是金蝶云星空的 batchSave,关键字段两个:FID 决定改哪一张调入单,F_PBLH_WDTNO 是承载旺店通单号的自定义字段。IsAutoSubmitAndAudit 默认 false,只改备注、不强行审核,把节奏留给上游业务流程。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略可以拆成两个节点串成一根线。

源节点(平台 → MySQL):选 MySQL 数据源,新建一个查询 SQL,把要回写的记录按主键 order_no 查出来,字段直接平铺到上下文,不做复杂加工。这一步的调度是 02 4 * * *,每天凌晨四点跑一次,覆盖前一天没写上的异常单据。

目标节点(平台 → 金蝶云星空):选金蝶云星空数据源,API 选 batchSave,FormId 写死 STK_TRANSFERIN,Operation 写死 batchSave,IsAutoSubmitAndAudit 留 false。字段映射只有两行:FID ← {{Id}}、F_PBLH_WDTNO ← {{order_no}}。调度 6-59/5 7-22 * * *,工作时间每五分钟跑一轮,做到分钟级闭环。

编码映射集中管理:金蝶的内码 FID 跟旺店通的 order_no 在轻易云里建一张映射表,后续任何回写策略都共用它,别在每条策略里重复维护。

实施步骤

分三段走,稳妥为先。

第一步,跑通单点。 手工在 MySQL 里挑一条调入单记录,在轻易云里配置源 SQL、目标 batchSave,点击「单次执行」,到金蝶前台核对 F_PBLH_WDTNO 是否被正确改写。这一步先不接调度。

第二步,接全量。 全量触发一次,把历史积压的「备注为空的调入单」一次性刷上旺店通单号。来源是 MySQL 里的对账视图,按 update_time 拉取,idCheck 保证幂等。

第三步,切增量。 全量跑完之后,改 SQL 的过滤条件,只拉「备注仍为空且创建时间在最近 N 小时」的记录,接上 6-59/5 7-22 * * * 的工作时段调度。凌晨四点的 02 4 * * * 作为兜底,弥补白天偶发的漏写。

表头表体分阶段:先把表头(FID + 备注字段)写稳,再考虑要不要把行项目里的某个号段也同步过去。别一上来就整单 batchSave,金蝶的批量接口对字段顺序敏感,一改一个坑。

踩坑复盘

1. 源端别以为是「空跑」就松懈。 没有 request 并不等于没有逻辑,主键字段、idCheck、SQL 拉数范围都得认真配,否则目标端拿不到上下文,直接报空指针。
2. FID 别用单据编号代替。 金蝶的 FID 是内码,业务单号在并发下会重,稳妥的做法是先用「单据编号 → FID」的映射查一次,再以 FID 写入。
3. IsAutoSubmitAndAudit 默认关。 这条策略只补备注,审核动作应该由上游业务流程触发,这里打开会让金蝶端出现「单据状态不一致」的脏数据。
4. 工作时间调度别 24×7。 6-59/5 7-22 * * * 是很多客户现场验证下来的折中——白天密、晚上停、凌晨再补一次,既不会把金蝶压得太狠,也能保证次日账目是齐的。
5. 增量与全量双轨。 全量用来救历史,增量用来保日常,两条 SQL 分开维护,别混在同一个过滤条件里,否则一次改动两边都炸。

适用场景与不适用场景

适合「需要把外系统单号回填到金蝶调入单备注/自定义字段」的场景,典型如电商仓与 ERP 的对账闭环。

不适合行项目级别的明细回写、需要触发审核或工作流的场景,也避不开金蝶自定义字段没建好的情况——先在金蝶端把字段建出来,再谈自动化。