采购价目表从金蝶云星空到MySQL的增量拉取实战：基于轻易云的策略配置教程

这个策略解决什么问题

某制造业集团的供应链系统里，采购价目表长期躺在金蝶云星空里——价格对象、含税单价、生效/失效日期、审核状态都由业务在 ERP 端维护。下游利润报表、成本核算、营销返利计算却跑在 MySQL 数据仓库上，业务每天要核对两边口径。

看似简单的「按编号拉一次」其实有三个隐藏的坑：价目表行项按修改时间持续变化、币别和组织是引用字段要二次解析、审核与禁用要分别处理否则把已作废价格也算进成本。

我们用轻易云数据集成平台承接这条链路：源端在金蝶云星空做查询，目标端落到 MySQL 集成库（kingdee_inter_oganization_price_new 表），策略每 10 分钟跑一次，增量条件按最后修改时间推进。

数据流向与字段映射

整体是「金蝶云星空 → 轻易云中间层 → MySQL」。金蝶云星空端通过 executeBillQuery 查询采购价目表单据头+分录，结果落到轻易云运行时；中间层做字段重命名、空值归一化、引用字段解析；最终通过 INSERT ... ON DUPLICATE KEY UPDATE 写入 MySQL。

关键字段对照（精简展示，实际字段远多于此）：

设计上让 FItem ID 直接进中间表，外键关联由下游报表库解析——这是轻易云客户常见的「外键下沉、维度上移」模式，避免频繁宽表重算。

在轻易云上如何配置

进入轻易云数据集成平台策略编排，源端选金蝶云星空、目标端选 MySQL，策略类型选「查询+写入」。

源端配置要点：API 选 executeBillQuery，方法 POST，作用 QUERY。勾选 autoFillResponse: true，让平台把响应字段自动展开，省去手写映射表。number 绑 FBillNo，id 绑 FMaterialId，作为唯一性回写键。idCheck 这里置 false——价目表分录主键 FEntity_FEntryID 在增量同步中允许重复触发，由目标端 upsert 去重。

目标端配置要点：API 选 WebAPI execute，方法 POST。主参数 main_params 走轻易云占位符机制，main_sql 用命名参数 SQL：INSERT INTO ... ON DUPLICATE KEY UPDATE ...。命名参数与源字段一一对应，平台在执行前做参数绑定。

轻易云这边走的是「编码映射集中管理」：所有组织、币别、供应商的 FNumber → MySQL 字典项映射统一放在平台映射表里，价目表引用字段解析时一次取齐，避免在每条策略里重复维护。

实施步骤

我们通常按三个阶段推进：

第一阶段，全量基线。先把金蝶云星空里所有生效+已审核且未禁用的价目表行项全量拉一遍，建立 MySQL 表初始数据。全量用一次性手动触发，跑完后做对账：按 FBillno 统计行数、抽样核对 FTaxPrice 与 FEntryEffectiveDate，确认是否一致。

第二阶段，增量起点。全量完成后，把增量条件切到 FModifyDate > last_sync_time。初次增量起点 = 全量跑完时刻；之后每次成功后更新游标。这个时点必须在轻易云策略里用平台变量保存，不写死在 SQL 里。

第三阶段，调度频率。源策略 crontab 设为 */10 * * * *（每 10 分钟），目标端写库策略 crontab 设为 */3 * * * *——这是轻易云客户常见的「增量与全量双轨」思路：源端高频率拉取增量，目标端高频短周期接收，确保不漏单。

上线观察一周，重点盯三件事：单据头与分录条数比例是否符合预期（价目表通常 1:N）、ON DUPLICATE KEY UPDATE 触发的更新条数、禁用/失效字段的状态切换是否及时。

踩坑复盘

第一条：增量起点游标千万别用 FCreateDate。我们见过客户把增量条件写成 FCreateDate > now，结果首日之后再也拉不到任何记录——价目表绝大多数更新是修改价格、改有效期，不是新建。稳妥做法是用 FModifyDate 并用平台变量保存上次成功时间。

第二条：禁用与未审核要分开处理。FForbidStatus=1 的行项必须过滤掉，否则成本核算会把已作废价格算进去。FDocumentStatus 只代表创建/审核态，和禁用态正交——两个字段都要判。

第三条：行级 FEntryID 在增量同步里会重复触发。价目表分录修改后 FEntryID 不变但 FTaxPrice 变了，目标端必须用 ON DUPLICATE KEY UPDATE 而不是先删后插，否则下游会被空窗期闪一下。

第四条：币别 FCurrencyID 是引用字段。金蝶云星空返回的 FCurrencyID.fnumber 不是直接的币别代码，需要二次解析或在中间层做映射，否则下游报表里会出现一堆看不懂的 FItem ID。

第五条：生效/失效日期用字符串传输要做格式校验。金蝶云星空端 FEntryEffectiveDate 是日期类型，但中间层序列化可能退化成字符串，目标 MySQL 是 DATE/DATETIME，写入前要确认格式 yyyy-MM-dd 还是带时分秒，否则会写入失败或截断。

适用场景与不适用场景

适用：供应链主数据（金蝶云星空 → MySQL 数据仓库/BI 库）单向同步、单据+分录结构、需要按修改时间增量、引用字段能在中间层解析。不适用：需要反向回写金蝶云星空、需要实时秒级延迟、跨组织跨账套且编码体系不一致、或者价目表本身在 MySQL 端维护的场景。