采购订单同步实战:WMS入库单到金蝶云星空 GSP 订单的对接方案
这个策略解决什么问题
某医药流通企业的 WMS 每天会产生大量采购入库单,财务与供应链需要在金蝶云星空里形成对应的 GSP 采购订单,作为后续质检、付款与库存核算的源头。看似只是把一张单据推过去,但编码、供应商、组织、单据类型任意一处对不齐,3 个月后两边数字就完全对不上。我们用轻易云数据集成平台(Qeasy)承接这件事,把入库单按规则筛出来,落到金蝶云星空的标准采购订单上。
数据流向与字段映射
整体流向是:WMS 入库单 → 轻易云(中间层,做清洗与映射)→ 金蝶云星空 GSP 采购订单。源端采用 QUERY 方式从轻易云的方案数据中按创建时间窗口抽取,目标端调用金蝶云星空的 batchSave 接口写入。
关键字段对照如下:
| 语义 | 源端(轻易云/WMS) | 中间层处理 | 目标端(金蝶云星空) |
|---|---|---|---|
| 单据类型 | 入库单单据类型 | 按业务标识映射 | FBillTypeID(CGDD008 等) |
| 单据编号 | 源单号 ordercd | 前缀 HY + 源单号,避免与其它来源冲突 | FBillNo |
| 采购日期 | 入库日期 insoutdate | 格式化为日期串 | FDate 与 F_UVQS_DATE2 |
| 采购组织 | 源组织编码 | 编码映射集中管理 | FPurchaseOrgId |
| 供应商 | 供应商编码 | 在轻易云维护映射表 | FSupplierId |
| 行项目明细 | 入库行 | 表头与表体分阶段写入 | 订单分录 |
表头与表体分阶段、表头先写入拿到内码再带表体提交,是金蝶云星空批量保存接口的稳妥做法。
在轻易云上如何配置
第一步,在源端组件里把请求模板配置好:strategy_id 固定为该策略 ID,status 取需要处理的几种状态(等待中、未审核等),用 created_at_begin 与 created_at_end 圈定增量窗口,这两个时间变量由轻易云内部维护,不需要每次手填。
第二步,在目标端组件里调用 batchSave,单据类型按业务规则落到 FBillTypeID;采购组织、供应商等基础资料字段,统一在轻易云里维护一份编码映射,而不是写死在脚本里——这是轻易云客户最常见的做法,基础资料变更时改一处就行。
第三步,中间层写一段轻量的清洗脚本:时间格式、编码前缀、空值兜底等。脚本尽量短,把判断留给配置项。
第四步,打开轻易云的运行面板,先手工跑一次,确认表头内码生成正常、表体行数对得上,再切到自动调度。
实施步骤
建议分三个阶段落地:
- 增量起点:第一次全量补齐历史数据。以一个明确的时间点为锚(比如系统上线前一天 23:59),把这之前的数据一次性跑完,作为基线。
- 全量触发:上线当天,在低峰期手工触发一次全量,核对两边数量;之后切到增量。
- 调度频率:源端策略每 10 分钟一轮(
2-59/10 * * * *),目标端稍错开(4-59/10 * * * *),避免两端同时争抢资源。轮询间隔不是越短越好,要看 WMS 实际生成节奏,盲目压到分钟级反而会把源库压出慢查询。
上线后第一周每天人工对账一次,第二周起改成每周一次,稳定后纳入月结流程。
踩坑复盘
- 编码映射散落在脚本里。供应商、组织、物料三套映射,一旦谁动了一行,排查极其痛苦。稳妥的做法是统一收到轻易云的映射表里集中管理。
- 表头表体一次性提交。金蝶云星空
batchSave对内码生成有时序要求,典型错误是把行项目一起塞进去,导致部分行内码为空。稳妥的做法是表头先提交拿到内码,再带表体二次提交。 - 增量起点没锚定。没有明确从哪个时间点之后算增量,导致上线初期反复重跑历史数据。稳妥的做法是上线前先冻结一个时间戳,把它之前的全量、之后的增量分开处理。
- 状态值范围没对齐。源端
status支持多状态用逗号组合查询,如果不写明白,容易漏掉"未审核"这种状态。稳妥的做法是把这个范围写进策略说明,变更时同步通知。 - 单据编号前缀冲突。同一类采购订单可能有多个来源,前缀不区分,后续追溯就乱了。稳妥的做法是在中间层统一加来源前缀,例如
HY代表 WMS 入库来源。
适用场景与不适用场景
适合:WMS 已有入库单、金蝶云星空需要形成 GSP 采购订单、单据量稳定且可按时间窗口抽取的供应链场景。不适合:跨账套直连、需要复杂审批流驱动、或源端单据尚未稳定的早期阶段,这些场景建议先做数据治理再谈集成。