有赞电子面单接口的能力边界并不止于“取一个号”。在ERP/OMS系统的实际履约场景中，取号只是起点，真正的难点在于当一个订单需要拆分为多个包裹时，如何将每个包裹的物流单号正确地关联到对应的子订单，并完成发货回传。有赞的拆单发货机制以子订单ID（oids）为核心锚点，开发者必须围绕这一参数设计完整的映射与回传逻辑，否则将面临“号取了但发不了货”的困境。

一、整单与拆单的接口分界

有赞的发货回传通过youzan.logistics.online.confirm接口完成。整单发货时，只需传入订单号tid和物流信息即可；但当订单需要拆分为多个包裹时，必须在调用发货接口时额外指定oids参数，oids为订单交易明细编号（即子订单ID），多个子订单ID用半角逗号分隔。这里有一个硬性规则：如果订单下已有部分商品发货，再次调用发货接口时必须指定oids，否则接口会拒绝请求。这意味着系统不能用一个“整单发货”的简单调用覆盖所有场景，而必须在发货逻辑中根据订单的发货进度动态判断是否需要携带oids。

二、子订单与包裹的映射必须由系统自行维护

有赞电子面单接口本身并不负责“包裹—子订单”的映射关系。取号接口返回的是面单号，发货接口接收的是oids列表和物流单号，二者之间的关联完全由ERP/OMS系统在本地维护。正确的设计是：在拆单取号时，为每一个包裹生成一个本地唯一的包裹标识，记录该包裹对应的oids列表和面单号；在调用发货回传时，根据包裹标识取出oids和物流单号，组装发货请求。如果系统缺少这一层映射，仅凭面单号无法反推其对应的子订单，拆单发货将无法正确执行。

三、按数量拆分发货的限制

有赞的拆单发货支持按子订单维度拆分，但不支持按数量拆分。具体而言，如果一个子订单中某商品的数量为20，系统不能将该子订单拆成20个独立包裹分别发货——该商品必须作为一个整体出现在某一个包裹中。这一约束对ERP系统的拆单策略设计有直接影响：当商家因库存分布或物流限制需要将一个“20件同SKU”的子订单分配到多个包裹时，有赞的拆单发货接口无法支持这种粒度的拆分。系统必须在业务层面对这类场景做出前置判断，例如引导商家合并发货，或在订单进入系统时就通过其他方式规避按数量拆分的需求。

四、发货回传与取号的状态一致性

拆单场景下的另一个风险是“取了号但未回传”或“回传了但号未取”。系统需要确保取号操作和发货回传操作在同一个状态机中推进：包裹状态从“待取号”流转到“已取号”，再流转到“已回传”。只有在“已取号”状态下才允许调用发货接口，且发货成功后包裹状态锁定为“已回传”，禁止重复回传同一物流单号。对于取号成功但发货回传失败的包裹，系统应保留面单号和oids的映射，在重试时直接复用，而非重新取号——重新取号可能产生新的面单号，导致已打印的面单作废。这一状态机的严格性，是拆单发货场景下避免物流信息错乱的基本保障。