金蝶销售出库单发货消息回写业务系统：单一策略实战教程
这个策略解决什么问题
某零售企业的业务系统开销售单、推到金蝶云星空生成销售订单，仓库发货后金蝶里产生销售出库单，物流公司、运单号都录在金蝶。但门店和客服要看到发货状态，必须回到业务系统才能查。物流信息只留在金蝶，前端用户看不见，订单状态永远卡在「待发货」。
这条策略就是做「金蝶 → 业务系统」的回写：按审核时间增量拉取出库单，把出库单号、物流公司、物流单号、产品明细回写到业务系统的销售订单上。一次性把发货状态、出库明细、物流轨迹全部对齐，省掉人工二次录入。
数据流向与字段映射
数据流向：金蝶云星空（SAL_OUTSTOCK） → 轻易云数据集成平台（分组、映射）→ 云水聚（业务系统，/Kingdee/UpdateSaleOrderLogistics）
源端是金蝶的 executeBillQuery，按 FApproveDate>='{{LAST_SYNC_TIME}}' and FDocumentStatus='C' 过滤，只拉已审核且落在增量窗口内的出库单。返回的是扁平行结构，每一行同时带主表字段和明细字段。平台按 FBillNo（出库单号）分组，每组生成一条目标端请求。
主表关键字段对照：
| 源字段（金蝶） | 目标字段（业务系统） | 映射类型 | 说明 |
|---|---|---|---|
| FSoorDerno | orderNum | DIRECT | 销售订单号，建立金蝶与业务系统订单关联 |
| FBillNo | kingdeeCKCode | DIRECT | 出库单号 |
| FDate | wareHouseDate | DIRECT | 出库日期 |
| FStockID_FNumber | wareHouseName | DIRECT | 仓库编码 |
| F_WDZN__YSJ_Logcompany | expressName | DIRECT | 物流公司，扩展字段 |
| F_WDZN__YSJ_Logbillno | expressCode | DIRECT | 物流单号，扩展字段 |
| （明细行集合） | productItems | COLLECTION | value 配 items，按 FBillNo 分组后传入 |
明细行映射：每个 productItems 元素由 items.* 引用源端明细字段，包含 FMaterialID_FNumber、FMaterialID_FName、FRealQty、FSerialNo、FCarryBillNo。
在轻易云上如何配置
我们在客户现场做这个策略时，主要配置 4 处：
-
源端元数据：选金蝶云星空平台、QUERY 效果，
executeBillQuery接口，number/id都填FBillNo，idCheck=true。请求字段清单把FBillNo、FDate、FSoorDerno、FStockID_FNumber、F_WDZN__YSJ_Logcompany、F_WDZN__YSJ_Logbillno以及明细字段FMaterialID_FNumber、FMaterialID_FName、FRealQty、FSerialNo全部勾上。 -
目标端元数据：选业务系统平台、EXECUTE 效果，
/Kingdee/UpdateSaleOrderLogistics，POST。请求字段按上表配 value，物流公司、物流单号直接用{{...}}透传，productItems的 value 写items。 -
映射关系：用轻易云的「编码映射集中管理」，把
F_WDZN__YSJ_Logcompany的物流公司名称与业务系统字典对齐；物料编码通过「物料对接业务系统」策略先同步，保证两边 SKU 一致。 -
调度：源端 cron
*/10 7-22 * * *（每 10 分钟、白天营业时段），目标端*/10 * * * *（全天）。这一步是「增量与全量双轨」的典型写法。
实施步骤
我们在项目里通常分三个阶段：
- 阶段一·增量起点：先用
FApproveDate >= '2025-01-01 00:00:00'跑一次历史全量，确认订单关联、物料映射、物流字段都能正确回写。轻易云支持表头表体分阶段，先把头跑通，再开明细。 - 阶段二·增量切换：把过滤条件改成
FApproveDate>='{{LAST_SYNC_TIME|dateTime}}'，开启 cron。先观察 24 小时，确认无重复、无漏单。 - 阶段三·常态化监控：源端 10 分钟一次、目标端 10 分钟一次，轻易云控制台看每次拉取条数、写入条数、失败重试。物流字段缺失时单独告警。
踩坑复盘
- 订单关联断了：FSoorDerno 对不上业务系统订单号，物流写不进去。这里容易翻车，因为「销售订单」必须先用「业务系统销售开单对接到金蝶」策略同步过来，出库单才有
FSoorDerno。稳妥的做法是把这条策略的 sequence 排在 B 之后，做depends_on校验。 - 物流字段选错：金蝶标准字段
FLogisticsNos、FLogComId与扩展字段F_WDZN__YSJ_*并存，业务系统只认扩展字段。典型错误是直接照搬标准字段名，结果回写全空。 - 空 productItems 报错：某些出库单无明细行时，
items是空数组，业务系统 API 可能拒绝。稳妥的做法是在目标端加一层前置校验，或与业务确认 API 是否接受空数组。 - 扁平行未分组：executeBillQuery 返回扁平行，没按 FBillNo 分组就会一行一条请求，目标端接口被刷爆。必须依赖平台默认的 FBillNo 分组逻辑，不要自己写循环。
- 发货人字段漏配：
outWareHousePerson目标端 value 为 null。业务真要用时，建议从金蝶扩展字段或FLogComId关联查询补齐，不要留空就跑生产。
适用场景与不适用场景
适用：业务系统开单、金蝶做后端仓储与财务的中大型零售/分销企业，需要把发货状态、物流轨迹实时同步回前端业务系统供门店和客服查询。 不适用：纯财务记账场景（无需回写业务系统）、物流信息录在业务系统而非金蝶的场景，以及未先做「销售订单→金蝶」前置同步的项目。