易仓与金蝶云星空供应链集成方案总览
场景与价值
某零售企业在大促期间反复踩到同一个坑:仓库发货之后,财务侧的库存账面要等两天才能对齐。问题不是 ERP 抄表慢,而是 WMS 出库单据到 ERP 之间缺少自动闭环——销售出库、采购入库、调拨、其他出入库这四类单据每天几十到几百张,靠人工导入既慢又容易漏。
我们接触到的多数项目,易仓作为 WMS 负责实物移动,金蝶云星空作为 ERP 负责账务和供应链计划。两边单据结构、编码体系、组织模型都不一样,只靠点对点接口很容易在促销季爆掉。这套方案的核心目标,就是把"基础资料先行、单据增量同步、异常可观测"三件事工程化,让出入库动作在 20~30 分钟内闭环到 ERP。
集成架构与数据流
整体架构由三方组成:易仓(WMS)、金蝶云星空(ERP)、集成平台(Hub)。Hub 在这里是轻易云数据集成平台,负责策略调度、编码映射、异常重试和数据中转。
数据流按方向分三段:
- 金蝶 → Hub:仓库、客户、物料、分布调出单查询、采购入库单查询。这部分是把 ERP 的主数据镜像到平台,作为下游单据转换的字典。
- 易仓 → Hub:WMS 仓库查询。用于建立 WMS 仓库编码与 ERP 仓库编码的映射。
- 业务单据双向流转:
- 易仓 → 金蝶:调拨入库、销售出库、采购入库、其他入库(换货/退货/组装/异常退货)、其他出库(盘亏/组装拆分/不良品)。
- 金蝶 → 易仓:分布调出单 → 采购订单。这里按供应商是否为空拆成两条策略,空值场景要走"找上游供应商"的兜底逻辑。
接口清单
本方案共 21 条策略,按阶段组织如下表。
| 策略编号 | 数据对象 | 同步方向 | 备注 |
|---|---|---|---|
| 1 | 仓库查询 | 金蝶 → Hub | 每 10 分钟,首次全量 |
| 2 | 客户查询 | 金蝶 → Hub | 每 20 分钟 |
| 3 | 物料查询(含旧编码) | 金蝶 → Hub | 每 10 分钟 |
| 5 | WMS 仓库查询 | 易仓 → Hub | 每日全量 |
| 9 | 分布调出查询 | 金蝶 → Hub | 每 20 分钟 |
| 4,6 | 调拨入库 / 调拨单 → 直接调拨单 | 易仓 → 金蝶 | 每 2~3 小时 |
| 7 | 销售出库单 → 销售出库单 | 易仓 → 金蝶 | 每 20 分钟 |
| 8 | 采购入库单 → 分布式调入单 | 易仓 → 金蝶 | 每 28 分钟 |
| 10,14 | 分布调出单 → 采购订单(供应商空/非空分支) | 金蝶 → 易仓 | 每 20 分钟 |
| 11,15,16,21 | 其他入库(换货/退货/组装/异常退货) | 易仓 → 金蝶 | 每日 |
| 13,17,18,20 | 其他出库(盘亏/组装拆分/不良品) | 易仓 → 金蝶 | 每日 |
| 12 | 查询采购入库单 | 金蝶 → Hub | 每 20 分钟 |
| 19 | 定期清理 90 天前数据 | 平台内部 | 每日 02:00 |
编码映射依赖:仓库、客户、物料、WMS 仓库、分布调出、供应商共 6 张映射表,所有业务单据策略都依赖这些映射,必须先于业务策略完成初始化。
实施要点
分阶段调度。21 条策略拆成两阶段:阶段 1 是基础资料(策略 1/2/3/5/9),阶段 2 是业务单据(策略 4/6/7/8/10/11/13/14/15/16/17/18/20/21)。阶段 1 内可并行,阶段 2 在基础资料就绪后并行启动。策略 9 必须先于策略 8 完成至少一次同步,否则分布式调入单会找不到上游单据。
增量字段选择。增量同步依赖时间戳:易仓侧用 receiving_update_time、update_time 这类字段;金蝶侧用 FApproveDate、FModifyDate。增量键的选择直接决定误传和漏传的概率,第一次上线必须和业务核对"审批后还会改字段吗"。
全量兜底。物料、仓库、客户每周一次全量补偿,业务单据按需触发全量修复。首次部署必须跑一次全量,不能直接上增量,否则历史脏数据会被增量逻辑绕过。
编码映射集中管理。仓库(WMS warehouseId ↔ ERP FNumber)、物料(ERP FNumber/FOldNumber ↔ WMS productSku)、客户(ERP FNumber/FName ↔ WMS platformUserName)、供应商(supplier_code ↔ suppiler_id)四张映射表必须在 Hub 上集中维护,不要散落在各策略脚本里。我们在客户现场见过把映射写死在 Python 脚本里的版本,业务加了新仓库后只能热更新脚本,事故率高。
异常重试。网络超时按指数退避重试 3 次(30s/60s/120s),目标系统 5xx 重试 2 次(间隔 60s),编码映射缺失不重试直接跳过并告警,联查无结果不重试直接记录。死信队列堆积超过 100 条必须人工介入。
数据隐私。所有真实客户名、账套号、组织编码在方案中已泛化为"某零售企业"等占位符,落地时同样要在 Hub 的日志脱敏模块里把 FNumber、供应商编码、手机号打码。
最佳实践与踩坑复盘
-
基础资料先行是铁律。不少项目为了赶促销节点,跳过阶段 1 直接跑业务单据,结果物料编码对不上,整批销售出库单在 ERP 端被驳回。稳妥的做法是阶段 1 全绿之后再开阶段 2,基础资料阶段就开监控告警。
-
供应商空值要双通道。分布调出 → 采购订单这条链路,供应商是否为空决定了是否能直接落单。我们在轻易云里把它拆成策略 10(供应商非空)和策略 14(供应商为空,需找上游)两条,空值场景走单独的兜底分支。
-
表头表体分阶段写入。金蝶云星空的单据接口对表头表体一致性要求很高,常见翻车是先写表体再写表头,中间失败导致脏单。稳妥做法是先建表头拿到单据号,再分批写表体,失败可重试。
-
监控阈值按业务定。基础资料策略连续失败 3 次应暂停依赖策略,业务策略失败率超 10% 立即告警,同步延迟超 30 分钟必须排查。轻易云客户常见配置是把这套阈值直接配到平台的告警通道里,出问题当天就能收到。
-
定期清理要写进方案。90 天前的中间表数据如果不清理,平台侧会越来越慢,而且审计追溯困难。策略 19 就是为这件事准备的,凌晨 2 点跑一次即可。
何时使用轻易云
如果你的场景是 WMS 与 ERP 之间的多单据、多编码、高频同步,轻易云数据集成平台(Qeasy)提供了现成的策略调度、编码映射中心、异常重试与死信队列,可以省去自建 ETL 调度链路的成本;对于易仓与金蝶云星空这类国产 WMS/ERP 组合,平台内已沉淀常见的字段转换模板,落地周期通常从几周压到几天。