生产入库单同步实战:MySQL 推金蝶云星空的字段映射与踩坑复盘

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

生产入库单从 MES/WMS 类源系统推到 ERP,是供应链集成的关键一环。某制造企业的痛点是:WMS 中已经确认入库的生产订单,需要实时反映到金蝶云星空,作为成本核算和应付/应收的源头数据。一旦同步延迟或单据编号冲突,财务对账就会出现几百万的差额。这个策略只解决一件事:把 MySQL 中的生产入库单,按增量方式稳定地写入金蝶云星空,组织编码、日期、单据号三类映射规则集中维护,降低后续维护成本。

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

源系统 MySQL 通过 SQL 拉取视图,目标系统金蝶云星空通过 batchSave 接口写入。关键字段对照如下:

FPrdOrgId 与 FStockOrgId 使用了轻易云常见的「编码映射集中管理」模式——通过 _function 表达式,把源端 T01.01 映射到目标端 T01.06,T04 映射到 T04,新增组织只需改这一处。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这个策略被建模为一条 A→B 的同步任务:

• 源端元数据:类型 SQL,api 为 select,主参数 main_params 包含 limit/offset,主查询语句按 :created_at 占位,平台自动替换为调度时间窗。autoFillResponse=true,字段标签即响应字段。
• 目标端元数据:类型 EXECUTE,方法 POST,api 为 batchSave,idCheck=true 表示按 FBillNo 判重,避免重跑产生脏数据。
• 调度:源端 crontab */3 * * * *,目标端 crontab */4 * * * *,源比目标快一拍,保证上游数据先就位。
• 运行期参数:通过 sys_config 表里的 config_id=351 维护增量起点日期,不用改 SQL 就能重新触发历史数据。

实施步骤(分阶段调度)

1. 环境与编码映射初始化:在轻易云的「编码映射」模块维护 delivery_org → FPrdOrgId/FStockOrgId 的对照表,所有依赖该映射的策略共用一份,避免散落在多个 SQL 里。
2. 增量起点设置:首次上线把 config_id=351 的 config_key 设为上线日,config_value 置空,平台会按 update_time > 上线日 抓取;上线当天把 config_value 设为上线日,SQL 里那段 CASE WHEN 会自动回填日期,防止漏单。
3. 全量触发:把 limit/offset 拉大到一次性覆盖全表,跑一次历史补数;跑完后立刻把 config_id 还原成增量模式。这里踩过一次坑——全量没分段,大表直接 OOM,后改成每批 5000 条分页。
4. 调度频率上线:源端每 3 分钟抓一次,目标端每 4 分钟写一次;轻易云的「表头表体分阶段」模式下,先写表头拿到单据内码,再回填单据体明细。
5. 监控与对账:把「源端记录数 vs 目标写入数 vs 失败重试数」三组指标接入轻易云的看板,差异超过阈值自动告警。

踩坑复盘

1. 组织编码写在 SQL 里,改一次要发版:典型的反模式。后来把所有组织映射提到轻易云的编码映射中心,新增组织 5 分钟上线。
2. 单据号源端拼前缀,目标又拼一遍,撞号:源端 CONCAT('RKD', id) 后,目标端 FBillNo 直接传值,千万不要再让金蝶云星空的编码规则覆盖,否则同号会触发 idCheck 失败。
3. 增量起点写死成 2025-01-01:上线时没注意,跑了半年才发现旧数据被反复拉取。稳妥的做法是用 sys_config 表 + 平台变量,所有策略共用一张「水位线表」。
4. batchSave 失败整批回滚:金蝶云星空的特性是单据体一条不过、整批全废。我们加了轻易云的「逐条降级」模式——失败行写入错误队列,后续人工或自动重提,不会阻塞其他行。
5. 日期字段类型不一致:源端 DATE,目标端 STRING,中间不做 DATE_FORMAT 会带时分秒进去,导致金蝶云星空报「日期格式错误」。所有日期字段统一在 SQL 侧转成 YYYY-MM-DD,别把类型转换交给目标端。

适用场景与不适用场景

适用:多组织、多工厂的离散制造企业,生产入库单需要从 MES/WMS 实时推 ERP,组织编码需要集中维护。不适用:需要复杂审批流、需要按工序拆分多条单据体、或者金蝶云星空端要求强校验(比如成本中心必填)的场景——这类需要前置清洗,而不是简单同步。