跨订单部分提货：把灵活的提货方式做成一个流程

Impact

The challenge：客户原来怎么做

客户是一位做社区团购/自提的批发商贸企业，用订货系统管理订单。

但他们的提货方式非常灵活：

• 同一个客户可能有多张订单
• 每张订单有多个商品
• 提货时可能只提"某几单里的某几个商品"
• 而且每个商品可能只提一部分数量——车装不下，剩下的下次再提

标准的订货系统不支持这种操作。 系统里的出库/发货接口都是订单维度的：要出库，必须指定订单号，按订单整单出。

于是客户只能这么干：

1. 在系统里查这个客户有哪些待出库商品
2. 人工判断哪些已经到货、能提多少
3. 到系统里一张张订单去做出库
4. 打印小票给提货人

问题在于：第 2 步全靠人判断，第 3 步要来回切换订单。 一个客户提一次货，可能要操作 3–5 张订单，每张都要选商品、填数量。提货高峰期根本忙不过来，而且容易出错。

The solution：我们做了什么

我们做了一个跨订单拣货台，把整个流程压成一个连续动作：

① 输入提货人手机号
      ↓
② 跨订单列出该客户所有"待出库"商品
   （自动聚合多张订单，标明每行来自哪张订单）
      ↓
③ 勾选已到货的商品行 + 填本次实际提货量
      ↓
④ 本地生成出库单 → 打印小票（此时不碰订货系统）
      ↓
⑤ 客户确认无误、离开后 → 点【确认发货】一次性回传

对操作员和提货人来说，这就是"一次提货、一张单子"。

底层实际发生的是：订货系统侧针对涉及的每张订单，各产生一张"部分出库单"——但这个细节客户看不见，也不需要知道。

两阶段设计：先打印，后回传

为什么这样设计：

提货现场变数很多——客户临时改主意、车装不下、临时加单。如果一开始就回传，任何调整都要走退货流程，极其麻烦。

先打印后回传，所有调整都发生在本地，对订货系统零副作用。改到满意了，客户走了，再一次性回传。

关键设计决策

决策一：不改动系统本体，走官方开放接口

为什么：改本体的话，官方升级一次就可能全部推倒，而且没有技术支持。

不这样选会怎样：系统升级后插件失效，客户业务停摆，责任在我们。

决策二：出库接口用 addConsignmentByNum，不用 addConsignment

这是整个项目最关键的技术决策。

原因：客户环境里的商品全部是手工创建的（不是从 ERP 同步过来的），没有真正的 ERP 外码。系统里那个 guid 字段只是内部 ID 的回退值。

实测数据：待出库数据 2930 行，options_goods_num 100% 非空。手工商品、ERP 商品、单规格、多规格全部通过。

不这样选会怎样：如果用直觉选的 addConsignment，在客户环境下会 100% 失败，而且错误信息是误导性的——它说"未查询到待出库商品信息"，看起来像是没有数据，实际是参数定位方式错了。这种坑不踩过一次是想不到的。

决策三：跨订单在插件侧聚合，不追求系统内合并

问题：客户想要"一次提货、一张单子"。但订货系统的出库/发货接口全是订单维度，做不到跨订单物理合并成一张出库单。

我们的选择：插件侧把多张订单的部分出库归入同一张本地出库单。

效果：对操作员和提货人而言就是"一次提货、一张单子"。你不说，客户看不出底层是几张。

不这样选会怎样：要么放弃"一张单子"的体验（客户不满意），要么尝试在系统里重建订单（会改动业务数据，风险极高）。

决策四：本地只记"操作事实"，不记"派生状态"

原则：

• 记：每次提货实际提了多少（哪张订单、哪个商品、提了多少）——这是我方事实，不会与系统冲突
• 不记：剩余待出库数量——这是系统状态，本地存一份历史，一旦不一致就成了脏数据

要查"还剩多少"，一律实时从订货系统拉取。

为什么：本地存派生状态，必然会出现"本地以为还剩 10 个，系统里其实只剩 8 个"的情况。这种不一致极难排查，而且会导致超卖。

能力清单

这个项目体现了四项能力：

交付时间线

边界：我们没做什么

这一节比上面所有内容都重要。

关于"中单位/大单位"：客户的商品有些是多单位的（小单位/中单位/大单位）。实测把中单位数据拿去回传，系统直接返回错误。规则没搞清楚之前，宁可不做，也不做错——这一条我们写进了交付文档，明确告诉客户"当前不支持，等确认规则后再开放"。

这个案例说明了什么

一、标准功能不支持的情况，能不能做？

能。 但要看是不是真的需要"改系统本体"——这个案例里我们没有改动系统本身，而是通过官方开放接口做扩展。

二、技术路径选错会怎样？

这个项目里，如果按直觉选错接口，在客户环境下会 100% 失败，而且错误信息是误导性的。

这种坑不踩过一次是想不到的。 我们在接口调研阶段花了整整两天，测了各种参数组合，才确认哪条路是通的。

三、交付物是什么样子？

不是一个"能跑的 demo"，是一个 32.1MB 的 Windows 可部署包：

客户现场装上就能用，不需要装任何开发环境。

如果你有类似需求

这个案例的典型特征：标准系统功能不支持某种灵活的业务操作，但业务又必须这么做。

如果你遇到类似情况，先问三个问题：

1. 这个操作是"偶尔特殊"还是"每天都要做"？（偶尔特殊的，人工扛过去可能更划算）
2. 系统的开放接口能不能覆盖？（能覆盖就别改本体）
3. 能不能用"两阶段"设计把不可逆操作的风险降下来？（能降就别一步到位）

答完这三个问题，再考虑要不要做。不确定的话，约一次免费诊断，我们帮你判断。