【线下】金蝶其他出库单同步至吉客云销售单：单一策略实战教程

这个策略解决什么问题

某零售企业的供应链链路里，金蝶云星空是 ERP 主干，吉客云承载订单与 WMS。线下样品出库、赠品出库、线下渠道出库这类"非标准销售出库"在金蝶里以其他出库单（单据类型 QTCKD06_SYS）记录，但吉客云侧要看到一张可发货、可跟踪物流的销售单。

我们用轻易云数据集成平台（Qeasy）承接这条策略：金蝶 → 吉客云，按审核日期增量拉取，按单据类型与仓库过滤，构造吉客云 tradeOrder 创建请求。它和"销售出库单 → 销售单"互为补充，覆盖所有出库来源；同时与后续的"物流单号回写"形成闭环。

数据流向与字段映射

流向：金蝶云星空（executeBillQuery，QUERY）→ 轻易云中间层（按 FBillNo 分组、buildModel 构造主表 + 明细）→ 吉客云（oms.trade.ordercreate，EXECUTE）。

主表关键字段对照：

源字段（金蝶）	目标字段（吉客云）	映射类型	转换规则	说明
FBillNo	tradeNo	DIRECT	`{{FBillNo}}`	销售单号，作为业务主键
FBillNo	sellerMemo	DIRECT	`{{FBillNo}}`	卖家备注，必填，用于 P4-211 反向定位金蝶 FID
FDate	consignTime / orderTime	DIRECT	`{{FDate}}`	单据日期
FCustId.FNumber	customerCode / shopCode	DIRECT	`{{FCustId.FNumber}}`	客户编码
FSTOCKID.FNumber	warehouseCode	DIRECT	`{{FSTOCKID.FNumber}}`	发货仓库
F_recipient / F_Receiving_phone_number	receiverName / receiverPhone	DIRECT	直接取值	收货人
F_economize / F_market / F_distinguish / F_Shipping_address	receiverProvince / City / District / Address	DIRECT	直接取值；可拼接为完整地址	收货地址四段
FNOTE	remark	DIRECT	`{{FNOTE}}`	单据备注
—	tradeType	CONSTANT	`线下`	订单类型固定标识
—	source	CONSTANT	`OPEN`	接入来源

明细 goodsDetail 关键字段：FMATERIALID.FNumber → goodsNo、FMaterialID.FBARCODE → barcode、FModel → spec、FQty → sellCount（无 FRealQty，以 FQty 为准）、FSTOCKID.FNumber → warehouseCode（行级仓库）。

在轻易云上如何配置

源端拉取：表单 STK_MisDelivery，过滤条件 FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' and FBillTypeID.FNUMBER='QTCKD06_SYS' and FSTOCKID.FNumber='RR-FZ1A'，分页 Limit/StartRow/TopRowCount。
目标端写入：oms.trade.ordercreate，主对象 tradeOrder 需展开 tradeNo / sellerMemo / warehouseCode / receiverName / goodsDetail 等子字段。goodsDetail 的 value 建议填 details_list，接收按 FBillNo 分组后的明细数组。
编码映射集中管理：客户、物料、仓库编码三张对照表统一放在轻易云的映射中心，金蝶编码直接复用为吉客云编码，避免散落在每个策略里——这是轻易云客户最常用的应对模式之一。
调度：源端 3-59/5 7-22 * * *，目标端错开一分钟 4-59/5 7-22 * * *，避免同秒并发。

实施步骤

第一阶段：增量起点。一次性回灌历史数据时，建议先在源端用 FDate 固定起点把全量跑一遍，跑完后切换为 FApproveDate 增量；并把 LAST_SYNC_TIME 落到轻易云的运行记录里。

第二阶段：全量触发。仓库上线初期或新增仓库时，把 FilterString 中的 FSTOCKID.FNumber 临时去掉，跑一次全量；之后再恢复单仓过滤。

第三阶段：稳态调度。每天 7–22 点每 5 分钟一次，夜间停跑减少对源系统压力；早班先于晚班，错峰消化前一天积压。

第四阶段：闭环验证。金蝶审核一张其他出库单 → 吉客云生成销售单 → WMS 发货 → P4-211 把物流单号按 sellerMemo 回写金蝶。任意一环断链都会造成单据悬空，因此每条上线都要做"正向 + 反向"的端到端核对。

踩坑复盘

sellerMemo 没填，导致物流回写找不到金蝶 FID。这是最典型的翻车点。P4-211 通过 sellerMemo 反查源单，所以无论业务上是否需要备注，FBillNo 必须写入。稳妥做法：在轻易云把 sellerMemo 设为必填校验。
buildModel: false，明细数组没分组。金蝶返回扁平数据，主表字段每行重复。如果目标 API 要求"一单一推"，必须启用 buildModel 或脚本按 FBillNo 分组，否则吉客云会建出 N 张主单。
价格字段缺失。其他出库单源端没有 FPrice / FAmount，若吉客云单价/金额必填，要在脚本里补默认值或 0，否则 API 直接报错。
仓库过滤写死 RR-FZ1A，新增仓库后漏单。这种硬编码在客户现场很常见，建议把允许的仓库清单放到轻易云的映射配置里，扩展时改一处即可。
单据类型混淆：QTCKD06_SYS（其他出库）和 XSCKD09_SYS（线下销售出库）是两个策略，FilterString 一定要写清楚，否则会把赠品出库推到销售出库通道，财务对账立刻对不上。

适用场景与不适用场景

适用：金蝶与吉客云之间、需要把"其他出库单"类非标准出库同步为吉客云可发货销售单、且后续要按 sellerMemo 做物流回写闭环的场景。不适用：纯线上电商订单（应由销售出库通道承担）、需要单价/金额严格匹配财务账的场景（其他出库单源端缺价，需另做价格补齐方案）。