MySQL → 金蝶云星空：调拨单外部供应商同步策略实战教程
这个策略解决什么问题
在一次实际项目中，某零售企业的 MES/WMS 端用 MySQL 存储入库确认与计划跟踪数据，而 ERP 端用的是金蝶云星空。两边都涉及"外部供应商"这条线：MySQL 里有一张外部供应商调拨单的明细数据，需要在金蝶云星空里建一张对应的调拨单，作为后续入库核销和财务核算的源头。
这个策略要做的事很朴素：从 MySQL 里把符合条件的外部供应商调拨单据查出来，写入金蝶云星空的调拨单。但难的是"外部供应商"这个限定——一旦过滤条件没卡严，很容易把内部供应商或不同业务类型的单据混进去，3 个月后两边账对不齐。
数据流向与字段映射
数据流向是单向的：MySQL → 轻易云数据集成平台 → 金蝶云星空。
源端（MySQL）是用 SQL 直查的方式，把外部供应商、且任务类型/出库类型匹配、且成功标记位满足条件的记录拉出来。目标端（金蝶云星空）走 batchSave，把这些记录批量落成调拨单。
关键字段对照（按素材原文整理，已脱敏）：
| 业务含义 | MySQL 源字段（示例） | 金蝶云星空目标字段 | 备注 |
|---|---|---|---|
| 单据编号 | CONCAT(d.confrim_no,'_',CAST(c.id AS CHAR)) | FBillNo | 源端拼接生成，目标端作为单据号 |
| 日期 | c.create_time 加工 | 业务日期字段 | 源端有按配置表动态计算逻辑 |
| 计划跟踪号 | b.mode_no | 计划跟踪号 | 用于追溯 |
| 物料编号 | b.part_no | 物料编码 | |
| 数量 | c.confirm_numb | 数量 | |
| 采购单号 | b.business_no | 采购单号 | |
| 条码 | b.ser_code | 条码 | |
| 供应商 | b.supplier_uuid | 供应商 | 外部供应商过滤的关键 |
| 来源 ID | c.id | 写入自定义字段 | 用于幂等与回写 |
| 供应组织 | m.delivery_org | 供应组织 | 与目标端组织编码对齐 |
| 单据类型 | 配置项 | FBillTypeID=ZJDB01_SYS | 调拨单类型 |
| 调拨方向 | 配置项 | FTransferDirect=GENERAL | |
| 调拨类型 | 配置项 | FTransferBizType=OverOrgTransfer | 跨组织调拨 |
| 业务类型 | 配置项 | FBizType=NORMAL |
编码映射的集中管理在轻易云里通常以"映射表 + 脚本"形式落地：源端 supplier_uuid、组织编码、料号等都要在中间层做一次映射，否则目标端会报"供应商不存在/组织不存在"。
在轻易云上如何配置
源端配置要点：API 类型选 select/SQL，方法是 SQL 直查，把主查询语句完整贴进 main_sql，主参数 main_params 传 limit/offset 做分页。注意 :created_at 这种占位符要和主参数字段名保持一致，参数化分页是稳妥的做法。
目标端配置要点：API 类型选 batchSave，方法 POST，把金蝶的调拨单标准字段（FBillNo、FBillTypeID、FBizType、FTransferDirect、FTransferBizType、FSaleOrgId 等）一一对应。idCheck=true 表示按单据号做幂等，避免重复建单。
调度上，源端用 */5 * * * *，目标端用 */2 * * * *，这是素材里的默认配置。源端 5 分钟一轮，目标端 2 分钟一轮，形成"读慢写快"的节奏，让目标端尽量在窗口内把积压单据消费完。
实施步骤
第一步，先做增量起点的配置：在 MySQL 端通过 sys_config 里的水位配置（如 config_id 指向的字段）作为起始时间，避免一开始把历史所有外部供应商调拨单都重跑过来。建议第一次同步时间窗口只取最近 N 天的数据，先验证通路。
第二步，全量触发：当通路验证通过后，把窗口放大或清空一次全量，把历史外部供应商单据补齐。注意，全量阶段建议放在业务低峰期。
第三步，调度频率：源端 5 分钟一轮，目标端 2 分钟一轮。在轻易云里两个调度是分开配的，靠数据积压自动衔接。如果目标端积压越来越多，可以把目标端临时调到 1 分钟一轮。
第四步，回写与幂等：目标端落单后，把金蝶的单据号回写到源端对应记录的标记位上，源端 SQL 里的 is_success 类条件就会自动把这张单剔出去，实现"成功一次就不再处理"。
踩坑复盘
坑 1：外部供应商过滤条件漏写 is_inner=1 或类似限定。素材里源 SQL 明确带了 e.is_inner=1，意思是只取外部供应商。如果漏掉这一条，内部供应商的调拨单也会被推到金蝶，目标端组织/供应商校验直接报错，而且这种脏数据一旦落进去很难清理。
坑 2：供应组织不匹配。源端 m.delivery_org='T01.01' 这种硬编码如果改环境没同步过去，金蝶端会因为找不到组织而拒收。建议供应组织用配置表管理，不要硬编码在语句里。
坑 3：成功标记位没回写，导致重复建单。c.is_success5<>'1' and c.is_success4='1' 这种条件组合是天然的幂等开关，但前提是金蝶端成功之后要更新 is_success5。如果回写链路断了，5 分钟一轮的调度会把同一张单反复推，金蝶端要么报错要么重复。
坑 4：分页参数没传。limit :limit offset :offset 必须有主参数配合，否则 SQL 一次拉全表，几十万行直接 OOM。稳妥做法是分页 size 控制在合理范围。
坑 5：单据类型 FBillTypeID 写错。素材里写的是 ZJDB01_SYS，这是金蝶里调拨单的特定单据类型编码。如果错写成采购单或其他类型，整批都会被目标端拒收。
适用场景与不适用场景
适用：MySQL 作为业务前台（MES/WMS/OMS），金蝶云星空作为 ERP 主数据，需要把外部供应商维度的调拨单据按组织、按时间窗口稳定同步，且有明确的回写条件做幂等。
不适用：业务规则复杂、需要人工审批流转的场景（轻易云同步策略更适合系统对系统的数据搬运）；或者源端数据本身就要在 ERP 里手工创建的情况，硬同步反而会增加对账成本。