金蝶收料通知单表单同步到MySQL:实战配置与踩坑复盘

这个策略解决什么问题

收料通知单是供应链里非常基础却最容易出问题的一类单据——上游 ERP 一旦审核,下游仓库、MES、BI 都要第一时间拿到明细。在一次实际项目里,客户的金蝶云星空每天会新增几百张收料通知单,审核时点分散,下游 MySQL 报表如果靠人工导出再导入,延迟大、口径乱。这条策略的目标就是:按单据编号增量拉取,审核通过即落库,让 MySQL 始终和金蝶保持“同口径”。

数据流向与字段映射

整体流向是 金蝶云星空 → 轻易云 → MySQL,中间层只做路由、映射和调度,不沉淀业务数据。

源端调用金蝶的 executeBillQuery,按 FBillNo 增量拉取,关键字段包括:分录ID FDetailEntity_FEntryID、单据编号 FBillNo、单据状态 FDocumentStatus、单据类型 FBillTypeID、业务日期 FDate,以及物料编码、收料数量、仓库等业务字段。

目标端是 MySQL 的 batchexecute,走批量 SQL 执行,主键 id,并启用 idCheck。字段一一对应落表,典型对照关系如下:

编码类字段(单据类型、物料编码)建议在轻易云上做映射表,集中维护,而不是写死在脚本里。

在轻易云上如何配置

进入 轻易云数据集成平台,新建源端连接选“金蝶云星空”,目标端选 MySQL。新建策略,策略类型选“表单查询+写入”。

源端配置:API 选 executeBillQuery,把 FBillNo、FDate、FDocumentStatus 等字段加进请求体,过滤条件里把 FDocumentStatus 限定为“已审核”,避免把草稿也拉过来。

目标端配置:batchexecute 走批量 SQL,主键 id 设为 idCheck=true,这样同一条记录重复到达时会走更新,不会插出脏数据。

调度上,源端 crontab 是 */8 * * * *,目标端是 3-59/8 * * * *,两个时间点错开 3 分钟,避免源还没拉完目标就开始写。

实施步骤

1. 建表与字段对齐:在 MySQL 端先把目标表建好,字段类型先按字符串处理,跑通后再按需收紧。
2. 增量起点:用一个起始 FBillNo 跑一轮全量,作为基线。轻易云常见的做法是“增量与全量双轨”,全量只跑一次,后面全靠增量。
3. 配置策略:按上面字段映射把源、目标连起来,先手工触发一次,验证一条记录是否能落库。
4. 调度上线:源端 */8 分钟拉一次,目标端错开 3 分钟执行,先观察 24 小时。
5. 异常监控:在轻易云里把“失败重试”“主键冲突”告警打开,前三天人工盯。
6. 表头表体分阶段:如果后续要扩到其他单据,建议先跑表头,稳定后再加表体。

踩坑复盘

1. 把草稿也拉过来:不在 FDocumentStatus 上加过滤,源端会带回大量未审核单据,下游报表口径直接乱。
2. 目标端没开 idCheck:同一条收料单被审核两次,MySQL 里就出现两条,数字对不上账。
3. 源端和目标端同时点:都设成 */8,两边撞在一起,目标表会出现“半批”——一批只插入了一半。稳妥的做法是错开 3-5 分钟。
4. 编码映射写死在脚本里:某次物料编码在金蝶端调整过一次,改了十几条 SQL 才补齐。后面改成在轻易云映射表里集中管,改一处就生效。
5. 自定义字段没加前缀识别:金蝶自定义字段以 F_xxx 开头,容易和标准字段混在一起,做表结构的时候建议单独建列或加注释。

适用场景与不适用场景

适用:金蝶云星空收料通知单、送货单、入库类单据需要实时或近实时落 MySQL 做报表、对账的场景。不适用:需要跨组织、跨账套汇总,或单据体量极大(单日十万级以上)需要走流式写入的场景——这种更适合走数仓或消息队列。