金蝶调拨申请单同步到MySQL：单表扁平化增量集成实战

这个策略解决什么问题

某零售连锁在多仓库之间做调拨,金蝶云星空的调拨申请单(STK_TRANSFERAPPLY)要推到 MySQL 的业务中台做调度分析。问题是源端是主从结构、目标端要做单表扁平化分析查询,字段又混着基础资料对象(FNumber/FName)。我们用轻易云数据集成平台(Qeasy)承接,采用「源端扁平拉取 + 目标单表 REPLACE INTO」的模式,搞定编码一致与增量稳定性。

数据流向与字段映射

数据流向:金蝶云星空(executeBillQuery,FormId=STK_TRANSFERAPPLY)→ 轻易云中间层 → MySQL 单表 tp_jd_transpferapply。

源端 executeBillQuery 返回的是扁平化结果,每条记录即一个申请分录行,主表字段在每行重复。目标端用单表扁平存储,不做主从分离,以 FEntity_FEntryID(目标端 FEntryID)为去重主键。

核心字段对照(节选,完整映射以源端元数据为准):

源字段	目标字段	类型	说明
FEntity_FEntryID	FEntryID	DIRECT	分录行ID,upsert 主键
FBillNo	FBillNo	DIRECT	单据编号
FTransferDirect	FTransferDirect	DIRECT	调拨方向
FAPPORGID.FNumber	FAPPORG_FNumber	TRANSFORM	申请组织编码
FAPPORGID.FName	FAPPORG_FName	TRANSFORM	申请组织名称
FMATERIALID.FNumber	FMATERIALID	TRANSFORM	物料编码
FUNITID.FName	FUNITID	TRANSFORM	计量单位名称
FQty	FQty	DIRECT	申请数量
F_PBLH_Base_WDTOUT.FNumber	F_PBLH_Base_WDTOUT_FNumber	TRANSFORM	旺店通调出仓库编码
F_PBLH_Base_WDTIN.FNumber	F_PBLH_Base_WDTIN_FNumber	TRANSFORM	旺店通调入仓库编码
FModifyDate	FModifyDate	DIRECT	增量游标

对象字段一律按 对象.FNumber 取编码、对象.FName 取显示名,编码映射集中管理是轻易云客户最常见的应对模式之一。

在轻易云上如何配置

在 Qeasy 上新建策略「金蝶调拨申请单 → MySQL」,要点如下:

源端连接:金蝶云星空 WebAPI,接口选 executeBillQuery,FormId=STK_TRANSFERAPPLY,请求方法 POST,分页参数 Limit=100 / StartRow=0。
拉取过滤:FilterString 写 FModifyDate>='{{LAST_SYNC_TIME|datetime}}',按最后修改时间增量。
字段映射:在轻易云映射面板里,把对象字段按 {{FMATERIALID.FNumber}} 这种语法取编码或名称;标量字段直接 {{FBillNo}} 透传。
目标端连接:MySQL,API 选 batchexecute,方法 SQL;目标表 tp_jd_transpferapply,主键 id,启用 idCheck。
写入方式:REPLACE INTO,按 FEntity_FEntryID 去重实现 upsert;单条队列写入量 limit=200。
调度:源端 */8 * * * *,目标端 3-59/8 * * * *,写入错开 3 分钟,避免读写出队列撞车。

整个策略无需额外脚本,源端扁平返回 + 目标端字段透传即可。

实施步骤

分三阶段上量,稳妥推进:

阶段一:增量起点。首次跑策略前,先在金蝶侧确认初始 LAST_SYNC_TIME,建议回溯到业务上线日;Qeasy 第一次拉取按 FModifyDate>='初始时间' 拿全量。
阶段二:全量触发。手动触发一次全量回灌,核对目标表 tp_jd_transpferapply 的行数与金蝶侧 STK_TRANSFERAPPLY 明细行数是否一致;再抽样 3-5 个 FBillNo,比对单据头字段与分录行字段。
阶段三:调度频率。确认无误后,启用 */8 的增量节奏。轻易云客户常用「增量与全量双轨」:日常按 FModifyDate 8 分钟增量,每周/每月做一次全量兜底,防止极端丢数。

踩坑复盘

对象字段没取对层级。典型错误是直接写 {{FMATERIALID}},得到的是 JSON 对象而不是编码。这里容易翻车,一定要写 {{FMATERIALID.FNumber}},目标端只存编码字符串,不要把整对象塞进去。
FNumber / FName 没分两列存。报表侧要做名称筛选,但编码才是关联键。稳妥的做法是同时存 FXXX_FNumber 和 FXXX_FName 两列,避免回查金蝶。
调度撞车。源端 */8 与目标端 */8 同时触发,中间队列会瞬间积压。建议目标端 3-59/8,与源端错开 3 分钟,稳稳消化。
REPLACE INTO 的副作用。REPLACE INTO 在 MySQL 上是先删后插,会触发自增 ID 变化与外键重写。表头表体分阶段的项目里,如果目标表有外键引用,优先用 INSERT ... ON DUPLICATE KEY UPDATE;只有确认无外键时才用 REPLACE INTO。
扩展字段命名混用。F_PRSH_Base_83g1、F_PRSH_Base_qtr 这种扩展字段在不同租户可能语义不同,部署前一定先在金蝶侧确认字段含义,不要凭名字猜。

适用场景与不适用场景

适用:调拨申请单需做跨仓调度分析、推下游 BI 或电商中间台、源端主从结构但目标端要做扁平查询的场景。

不适用:目标表已有外键引用且对自增 ID 敏感,或源端单据需保留主从结构做严格反查的场景,建议换「主表 + 明细表」双表建模而非单表扁平。