金蝶生产订单查询同步到 MySQL：基于轻易云的实战配置
这个策略解决什么问题
生产订单从 ERP（金蝶云星空）同步到中间库（MySQL）看似简单，但在我们接触的某制造企业里，这个链路一旦跑起来就成了 MES、排产、看板的数据底座——错一条单据，下游车间当天就停摆。常见的痛点是：金蝶端生产订单状态多变（创建、审核、开工、完工、关闭），表头表体字段极多，自定义字段穿插其中，稍有遗漏就会出现"金蝶里改了状态，MySQL 里没跟上"。本策略的目标，就是用轻易云数据集成平台（Qeasy）把生产订单按增量稳定落到 MySQL，供下游系统消费。
数据流向与字段映射
数据流向很直接：金蝶云星空（源，B 端）→ Qeasy 中间层 → MySQL（目标，A 端），方向是 B_TO_A，类型为 QUERY_ONLY + SQL EXECUTE。
源端是金蝶的 executeBillQuery 查询接口（POST），单据编号字段为 FBillNo，表体用 FTreeEntity_FEntryId 作为行主键。我们整理了一组关键字段对照表（节选）：
| 业务含义 | 源端字段 | 目标 MySQL 字段 | 说明 |
|---|---|---|---|
| 单据主键 | FID | FID | 主键，幂等依据 |
| 单据编号 | FBillNo | FBillNo | 业务编号 |
| 车间名称 | FWorkShopID0.FName | FWorkShopID0_FName | 关联基础资料 |
| 创建人/审核人 | FCREATORID.FName / FApproverId.FName | FCREATORID_FName / FApproverId_FName | 姓名 |
| 创建/审核日期 | FCreateDate / FApproveDate | FCreateDate / FApproveDate | 时间字段 |
| 物料编码/名称 | FMaterialId.FNumber / FName | FMaterialId_FNumber / FMaterialId_FName | 表体 |
| 数量 | FQty | FQty | 表体 |
| 计划开工/完工 | FPlanStartDate / FPlanFinishDate | FPlanStartDate / FPlanFinishDate | 表体 |
| 销售订单号 | FSaleOrderNo | FSaleOrderNo | 跨单关联 |
| 实际开工/完工 | FStartDate / FFinishDate | FStartDate / FFinishDate | 状态判断 |
| 状态 | FStatus | FStatus | 业务状态 |
| 表体行主键 | FTreeEntity_FEntryId | FTreeEntity_FEntryId | 配合 FID 联合主键 |
| 批号/单位 | FLot / FUnitId | FLot / FUnitId | 表体 |
目标端是 MySQL 的 REPLACE INTO，写入表 order_production。我们用 REPLACE 而不是 INSERT，是因为生产订单会"重写"（状态变更时金蝶会重新推送），需要按主键覆盖。limit 设为 800，是单批写入的常规上限，配合源端分页基本够用。
在轻易云上如何配置
进入 Qeasy 控制台，按以下要点配置这条策略：
- 源平台：选
Kingdee.Cloud，账号配置好租户与授权（这里用泛化的「金蝶云星空」实例描述，不出现具体账套号）。 - 目标平台：选
MySQL，配置好连接信息和目标库。 - 源动作：API 选
executeBillQuery，method=POST，effect=QUERY。 - 目标动作：type=SQL，effect=EXECUTE，主语句使用
REPLACE INTO，limit=800。 - 字段映射：在 Qeasy 的字段映射区，把源端 request 里的字段一一映射到目标 SQL 参数。注意关联字段（如
FWorkShopID0.FName）要按金蝶的查询语法写在value里，而不是 label 里——这是金蝶查询接口的常见坑，label 只是显示用。 - 编码映射：车间、物料、单位等基础资料类的编码，集中放到 Qeasy 的映射表里统一维护，避免散落在每条策略中。
- idCheck：目标端开启
idCheck=true，依赖 FID + FTreeEntity_FEntryId 联合判重。 - 调度：源端 crontab 设为
*/15 7-22 * * *，目标端为*/16 7-22 * * *。两端错开 1 分钟，是为了"先查后写"，避免写入快于读取造成空跑。
实施步骤
我们在客户现场通常分四步走：
第一步：增量起点对齐。 第一次跑全量前，先在 MySQL 端建好 order_production 表结构（含所有字段、合适索引），并和源端对一次最近 30 天的单据量。轻易云支持配置"起始时间变量"，从某个时间点开始增量拉取，避免一次拉历史几年。
第二步：全量触发。 在 Qeasy 里手动触发一次全量同步，观察返回体量与耗时。这一步重点是看金蝶接口是否分页正常、自定义字段（F_QOQG_*）有没有缺失。
第三步：分阶段调度（表头 / 表体）。 生产订单是表头+表体结构。我们建议先跑表头相关字段（车间、创建人、状态、备注），再跑表体（物料、数量、日期）。Qeasy 的策略依赖图里可以用 depends_on 显式声明依赖，避免表体比表头先落库。
第四步：日常增量 + 异常监控。 调度按 */15 分钟一次运行，Qeasy 会自动记录每批的拉取条数、写入条数、失败原因。建议在控制台配一个"连续 2 批写入为 0"的告警，防止上游静默断流。
踩坑复盘
- 关联字段写在 label 里。 这是最常见的翻车点：
FWorkShopID0.FName必须写在value，金蝶查询接口才认，写在 label 只是 UI 显示。 REPLACE INTO与INSERT选错。 生产订单状态会反复变（开工 → 暂停 → 复工 → 完工），必须用REPLACE或INSERT ... ON DUPLICATE KEY UPDATE，否则会产生重复行。- 自定义字段未配齐。 金蝶里
F_QOQG_*是用户扩展字段，常被忽略。下游 MES 经常要这些字段做工序分类，少配一个就要回头补。 - 调度频率过高导致金蝶限流。 金蝶云星空的
executeBillQuery有调用频次上限，*/15分钟是经验值；频率再高就容易被租户级限流。 - 表头表体顺序错乱。 没配
depends_on时，Qeasy 并行跑，表体可能先到。此时下游按表头状态做判断就会错——稳妥的做法是显式声明依赖，或在 MySQL 端用视图做"表头+表体 JOIN"的最终一致性校验。
适用场景与不适用场景
适用：金蝶云星空 → MySQL 的生产订单单向同步，下游有 MES/排产/BI 消费 MySQL 数据；需要保留自定义字段、批号、跨单关联（销售订单号）的场景。
不适用：需要双向回写（MySQL 改状态推回金蝶）的场景；金蝶端单据量极大（>10 万/天）且要求分钟级实时——此时建议直接走金蝶的开放平台消息推送，而非轮询。