采购入库单拍扁同步：从用友U8到旺店通的实战教程

这个策略解决什么问题

某零售企业的供应链链路里，ERP 端的采购入库单和电商 OMS 端的采购订单，长期是两套口径、两套编号。仓库在 U8 里完成入库，财务按 U8 单号记账；但 OMS 那边要驱动后续的入库验收和发货，又需要一套独立的采购订单。靠人工导出再录入，不出三个月两边数字就对不上——这是我们在客户现场最常听到的抱怨。

这条策略的核心价值，是把 U8 的入库单（带表体多行明细）"拍扁"成 OMS 的采购订单主单加明细行，由轻易云数据集成平台（Qeasy）按调度自动拉取并写入，省掉人工环节，把"两边数字对不上"这种慢性病一次性根治。

数据流向与字段映射

整体流向是 U8 → 轻易云中间层 → 旺店通。U8 端通过 pustorein/list 拉取入库单列表，再通过 pustorein/get 拉详情；中间层做"拍扁"和字段重映射；最后调用旺店通奇门 wdt.purchase.order.push 写入。

关键字段对照如下：

字段顺序与命名以你环境里的具体接口为准，轻易云平台支持在可视化映射里直接拖拽。

在轻易云上如何配置

我们用的是轻易云数据集成平台 Qeasy 的策略画布，整条链路分三段配置。

源端配置（U8）：选 WebAPI 适配器，请求方法 POST，接口路径 /apilink/u8api，apiurl 填 pustorein/list 拉列表，apidetail 填 pustorein/get 拉详情。增量字段用 ufts（U8 的时间戳），调度频率设 */30 * * * *，每 30 分钟拉一次。idCheck 打开，避免重复。

中间层拍扁：这一步是关键。U8 的入库单是表头+表体结构，到 OMS 要拍扁成"一单一明细行"。在 Qeasy 的脚本节点里循环表体，每一行产出一条明细记录，同时把表头字段（供应商、仓库、单号、备注等）复制到每条记录上。建议把"拍扁"脚本独立成一个节点，便于后续给退货单复用——这是轻易云客户里常见的"分阶段沉淀资产"做法。

目标端配置（旺店通）：调 wdt.purchase.order.push，outer_no 用 U8 单号 ccode，warehouse_no 用映射后的仓库编码（素材示例里写的是 999999，你环境里按实际改），provider_no 必须先在 OMS 供应商档案里建好，否则推送会失败。

编码映射这一块，建议在 Qeasy 里建一个独立的"编码映射表"节点集中管理供应商和仓库，不在脚本里硬编码——这是轻易云客户里最常见的应对模式之一，后续换编码体系不用改脚本。

实施步骤

我们通常分三个阶段推进：

1. 存量全量：把 crontab 临时改成 1 1 1 1 1（每年 1 月 1 日触发一次，本质是一次性手动跑），先把历史入库单补齐到 OMS，跑完立刻恢复增量调度。
2. 增量起点：取一个明确的时间点作为增量游标的 ufts 起点，建议选全量完成那一刻往前推 30 分钟，留出余量。
3. 稳态调度：调度频率 */30 * * * *，跑 24 小时观察，确认无重复单、无丢单后再交付。

调度频率别贪快——U8 的 ufts 是数据库时间戳，高频轮询既没有意义也会给 U8 增加压力，30 分钟一次在大多数客户现场够用。

踩坑复盘

1. 增量起点选错导致漏单或重单。典型错误是拿"今天零点"做起点，但 U8 时间戳格式跟系统时区相关。稳妥的做法是先跑一次全量，再以全量完成时间为锚点往回拨 30 分钟。
2. 供应商编码未先建档就推送。provider_no 在 OMS 端必须是已存在的档案，否则推送直接失败。建议把"供应商档案预建"作为这条策略的前置依赖，没有档案就别跑。
3. 仓库编码硬编码。素材里 warehouse_no=999999 看着像个占位值，直接抄到生产环境会出问题。稳妥做法是在 Qeasy 里建映射表，按 U8 仓库动态取。
4. 拍扁脚本里漏拷表头字段。每条明细都要带上表头的供应商、仓库、单号、备注等，漏一个 OMS 那边就报错。
5. 没考虑撤销/作废场景。U8 入库单可能后续被作废，但 OMS 那边已经写入。这种情况要靠 OMS 自身的作废流程或反向同步补齐，单纯靠这条策略覆盖不了。

适用场景与不适用场景

适用：U8 为主、OMS 为辅的零售/分销企业，U8 负责财务记账和库存，OMS 负责入库验收和后续发货，需要把入库事实传递到 OMS 形成可执行采购订单。

不适用：U8 本身已经能完成全部业务的企业（多此一举）；对实时性要求秒级的场景（30 分钟一轮不够）；以及 OMS 端已经有自己完整采购订单体系、不希望被 ERP 反向覆盖的场景。