多店铺订单合并发货怎么处理？场景、规则与风险
买家在同一个店的两次下单、或者在两个不同店铺各下一单，收货地址完全相同。仓库看到的是一个地址却有两个包裹，白白多付一次运费；买家则需要收两次快递。合并发货看起来是双赢，但操作前需要分清场景，也要看清平台规则。
一、先判断能不能合
合单的前提是同一个买家、同一个收货地址、同一个物流渠道。三个条件之外，还要确认平台是否允许——部分平台对”订单轨迹与包裹对应关系”有明确要求，盲目合单可能导致物流信息无法回传。
| 场景 | 能否合并 | 主要考量 |
|---|---|---|
| 同一店铺同一买家多次下单 | 通常可以 | 需在平台侧仍保留订单独立状态 |
| 同一买家跨店铺下单 | 视平台规则 | 物流单号需要分别回传给各平台 |
| 不同买家同一收货地址 | 不建议 | 涉及隐私与售后责任界定困难 |
二、在ERP里怎么实现合单
合单的技术难点不在打包，而在订单与包裹之间的对应关系。落地时通常需要三步。
- 识别同一买家。以收货人姓名 + 电话 + 地址的组合作为识别依据，或用平台买家ID关联。要注意同一买家可能用不同收件人姓名，单纯靠姓名容易漏判。
- 설정合单规则。常见限制包括：下单时间间隔（如 24 小时内）、地址相似度、是否含预售或定制商品、是否已打印过面单。已进入拣货流程的订单不建议再合。
- 处理包裹与订单的多对一关系。合单后一个包裹对应多个订单，需要在系统中记录这些订单共享同一个物流单号，并按各平台要求分别回传。
소개跨店铺合单：平台通常要求本店铺的订单必须回传本店铺的物流单号。因此跨店铺合单在系统里需要”一个包裹、多个单号”的映射关系，而不是简单地共用一个单号。选型时值得确认系统是否支持这种结构。
三、要留意的三个风险
- 退款分摊。买家申请其中一个订单退货退款时，运费与优惠如何分摊需要提前约定。若两个订单享受了不同的满减，直接按金额比例分摊可能不符合平台规则。
- 平台考核。发货时效按订单维度统计，合单后包裹只发一次，但两个订单的时效都要满足，不能因为等待合并而超出承诺时间。
- 售后责任。包裹只发一件但两个订单都已标记发货，若后续出现少件争议，需要能拿出合单记录作为凭证。这一条常常在选型时被忽略。
四、用固定批次替代”实时合单”
完全实时的合单会带来一个副作用：为了等待可能的第二单而延迟发货。更稳妥的做法是把合单动作放在固定的处理批次里。
- 设定一个短窗口，例如 6 小时内同地址的订单进入同一批次。
- 在批次开始前统一执行合单判断，过窗口的订单不再等待。
- 把”因合单延迟而超时”作为一条监控指标，避免为了省运费牺牲时效。
批次化处理订单的思路，与打单发货的波次化做法一致，可以合并设计。多店铺的整体选型思路，可参考三种店铺组合场景的选择与多店铺管理ERP工具栏目。
结论：多店铺合单的前提是同一买家、同一地址、同一渠道，且不违反平台规则。系统里需要解决的是”一个包裹对应多个订单、多个平台单号”的映射关系，而不是简单共享单号。退款分摊、发货时效考核与售后凭证是三个容易被忽略的风险点，建议用固定批次替代实时合单，兼顾运费与时效。