聚水潭销售出库单到畅捷通T+销货单的一单一单同步实战

这个策略解决什么问题

零售企业常把线上门店开在聚水潭,财务与进销存却在畅捷通 T+。每日已出库的零售订单必须按单落到 T+ 形成销货单,才能进入对账、库存核算与开票环节。我们这次在客户现场,就是把聚水潭指定零售店铺的销售出库单,按出库时间增量取过来,一单一单写入 T+ 销货单,不做多单合并,确保按单可追溯。

数据流向与字段映射

流向:聚水潭·奇门 → 轻易云数据集成平台(Qeasy)→ 畅捷通 T+。

中间层在轻易云数据中枢里承担两件事:一是落地源端明细,二是为 _findCollection 联查提供「店铺名称 → 客户简称」映射,目标端再把映射结果写进 T+ 销货单。

关键字段对照表(表头)

源端在请求阶段就加了两道过滤:status=Confirmed(只取已出库)和 shop_id=16288585(只取零售店铺),减少无效数据进入管道。

在轻易云上如何配置

1. 新建源端 QUERY 节点:接口选 jushuitan.saleout.list.query,请求方式 POST。start_time 用 {{LAST_SYNC_TIME|datetime}},end_time 用 {{CURRENT_TIME|datetime}},date_type=2(按出库时间),shop_id 固定为指定零售店铺编号。
2. 新建目标端 EXECUTE 节点:接口选 T+ 的 /tplus/api/v2/saleDelivery/Create,请求方式 POST,dataKey=dto。
3. 字段映射:按上面的对照表逐项配置;Customer 用 _findCollection,从「聚水潭店铺查询」方案的结果里按 shop_name 查出 short_name。
4. 明细映射:SaleDeliveryDetails 直接取 items,进入明细子层后,按 T+ 明细结构补存货编码、数量、单价等子级映射。
5. 写入策略:勾选「不合并写入」,每条源单对应一条目标单,不做聚合。
6. 依赖与调度:依赖方案「聚水潭店铺查询」必须先执行;源端调度建议每日 03:49,目标端 04:23,留出店铺同步完成的时间窗。

实施步骤

1. 增量起点:首次上线时,把 start_time 回拨到一个明确日期(如上线前一天),用一次全量把存量已出库单铺平;之后切换到 {{LAST_SYNC_TIME}},按天滚窗。
2. 依赖先行:聚水潭店铺查询方案必须早于本策略执行完,否则 _findCollection 会查不到 short_name,导致客户字段落空。
3. 调度频率:每日一次,源端 03:49 拉取、目标端 04:23 写入,与依赖方案串成一条调度链。
4. ExternalCode 去重:用 io_id + "+1" 拼接,既避开 T+ 内部编码,又天然唯一。
5. 监控与重跑:轻易云会按 io_id 做幂等记录,失败的单据可按 ExternalCode 单独重推,不会重复落账。

踩坑复盘

• start_time 与 end_time 间隔不要超 7 天。聚水潭接口有窗口限制,这里容易翻车,稳妥做法是把单次窗口压到 1 天,靠调度每日推进。
• io_date_new 为空时不要硬塞 io_date。先把空值判出来,空值走 io_date 转换,避免落库日期错位。
• +1 是字符串拼接,不是加法。要确认平台把 +1 当文本拼接,而不是数值运算——否则 ExternalCode 会丢字符,T+ 直接拒收。
• 依赖方案顺序写反。店铺查询没跑完就触发销货单,_findCollection 返回空,客户字段落空,整批失败。把依赖关系挂到调度链上,轻易云会按顺序触发。
• status=Confirmed 与 Cancelled 别混淆。Cancelled 的单据也会带 io_id,但走销货单会变成负数或拒收,务必在源端就过滤掉。

适用场景与不适用场景

适用:零售门店一店一客、订单量适中、要求按单可追溯、对账需要 1:1 落 T+ 销货单的场景。不适用:多张出库单合并开票、需要按客户+日聚合、要按仓库拆单或走 T+ 其他单据形态(例如调拨单)的场景,这些场景应另起聚合策略。