金蝶销售出库单同步到 MySQL：单策略实战教程

这个策略解决什么问题

零售与电商企业普遍存在"金蝶云星空是财务与供应链主系统、MySQL 仓库承载电商业务数据"的双轨架构。销售出库单一旦在金蝶审核完成，下游电商中台、物流、报表需要尽快拿到一致的分录级数据。这个策略用一条扁平化单表通道，把金蝶 SAL_OUTSTOCK 的每一条分录同步进 MySQL，既能做实时增量，又能承载历史全量。

数据流向与字段映射

数据流向是单向的：金蝶云星空 → 轻易云中间层 → MySQL。中间层负责把金蝶对象字段（FCustomerID.FNumber、FSaleOrgId.FName 等）拍平为目标字段，并以分录 ID 为主键写入目标表 tp_jd_out_stock。

金蝶 executeBillQuery 返回扁平结构，每行就是一条分录，主表字段在每行重复——这是设计的关键前提：目标端无须主从分离，分录行 ID 即可作为唯一去重键。

在轻易云上如何配置

我们在客户现场做这条策略时，习惯按"源端—中间层—目标端"三层拆开。源端选金蝶云星空的 executeBillQuery，FormId 写 SAL_OUTSTOCK，方法 POST，请求体里把 FilterString 写成 FModifyDate>='{{LAST_SYNC_TIME|datetime}}' or FApproveDate>='{{LAST_SYNC_TIME|datetime}}' or FCancelDate>='{{LAST_SYNC_TIME|datetime}}'——三条时间任一命中即拉取，确保单据变更不被漏掉。

中间层是字段映射。把对象字段按 FName / FNumber 双落，是轻易云客户常见的应对模式：编码用于跨表关联、追溯，名称用于报表展示。扩展基础资料如 F_PRSH_Base_re5、F_PRSH_Base_83g 同样走这条规则。无需写脚本，全部用模板变量 {{field}} 透传。

目标端选 MySQL 的 batchexecute，主键 id 勾选 idCheck，写入 SQL 用 REPLACE INTO tp_jd_out_stock (...) VALUES (...)，按 FEntity_FEntryID 去重实现 upsert。批量写入量控制在 200 一批，避免大事务拖垮 MySQL。

实施步骤

第一步：定义增量起点。 在策略元数据里设置 LAST_SYNC_TIME，首次全量时给一个早于业务启用的时间戳，让三条时间字段都能匹配到。

第二步：配置调度，错开窗口。 源端 */7 * * * *，目标端 3-59/7 * * * *——源拉取先于目标写入 3 分钟，确保源端查询到的最新数据已经在中间层落地，目标库写入时不会出现"看似空集"。

第三步：先全量，再增量双轨。 上线当天人工触发一次全量补齐历史数据，确认分录数量级与金蝶一致后再开启定时调度。后续完全靠增量条件滚动。

第四步：上线监控。 在轻易云上观察源端拉取条数、目标端写入条数、REPLACE 影响行数三者比例，异常时第一时间能定位。

踩坑复盘

1. 金蝶对象字段没双落。 早期版本只落了 FName，下游做关联追溯时拿不到编码，不得不二次回填。稳妥的做法是基础资料类字段一律编码与名称双落，建表时就把 _FNumber 与 _FName 写齐。
2. 忘了 FCancelDate。 单据作废时只勾 FApproveDate 不够，金蝶作废是独立动作。建议增量条件同时覆盖修改、审核、作废三条时间，否则作废单会一直留在下游。
3. 分页大小没设。 默认 Limit 过大容易触发金蝶超时，过小又会拉很多轮。在轻易云上把 PAGINATION_PAGE_SIZE 与 PAGINATION_START_ROW 用模板变量接住，便于调优。
4. 写入用 INSERT 引起主键冲突。 增量场景下同一分录会被反复拉到，必须用 REPLACE INTO 或者 INSERT ... ON DUPLICATE KEY UPDATE，否则任务一跑就报错。
5. 目标库事务粒度太粗。 一次写入几千行 REPLACE 会锁表。建议每批 200 条，让 MySQL 能正常并发。

适用场景与不适用场景

适用： 电商中台、零售门店、报表平台需要扁平化分录级销售出库数据，且主系统是金蝶云星空、下游是 MySQL 仓库的项目。 不适用： 需要保留主从结构、做单据级回写、或者下游不是 MySQL 的场景——这类需求应另起一条策略。