联营订单自动拆分：平台主单与商家子单怎样对应｜云上订货系统

云上订货 · 更新于 2026-10-08

联营订单拆分后，客户的原平台订单与商家交付订单分别保留。核对时从原主单出发，按联营商家、商品规格、单位数量和原金额找到每个子单，再分开看出库、收货与款项。以下系统画面为历史记录，用于辨认原字段，不能代当前拆分和交付结果。

1 从平台原主单确认客户与商家分组

平台原订货单保留订货客户、原销售明细与平台销售金额；商家子单则在对应商家企业中承接其联营商品。商家子单里的客户可能显示平台内部客户，不是终端订货客户改了身份。应同时记录平台企业、原客户、原主单号、联营商家与商家子单号，不能用同名客户或相似单号直接判断是同一笔业务。平台原订单包含普通商品和联营商品时，也不能把每一行都算成商家需要交付的子单内容。

拆分按原明细的联营商家分组，只有一个商家的联营明细也会形成对应子单，并非必须混合多个商家才拆。不同商家分别承接自己的原规格，同一商家组里的多项规格要一并核；不要只查商品种类数或看到第一个子单就认为原明细全部齐。平台主单承担客户订单追溯，子单承担商家业务流转，二者不能合并成一张金额和状态完全相同的订单。

图1：原订货客户、平台主单、各商家子单及每项规格映射分别核，创建与交付款项分层。

2 在审核到出库的原阶段查拆分结果

自动拆分出现在订单审核后、准备出库的相应处理阶段，不能把客户草稿保存、看到提交时间或刚提交订单视为已经生成所有商家子单。原业务要求先付款但付款未满足时，还需先核其原反馈和财务状态；不同企业的提交、确认、审核设置也会影响实际进度。查看原订单流程节点及首个提示，再判断该笔是否已经到了需要拆分的阶段，不用历史全亮流程条推断当前设置。

平台原订货单的“联营订单”区域按商家显示合作方式、商品规格、数量单位、已出库、联营单号及子单状态。历史主单的联营行是两件、已出库零、子单待出库；这证明当时已有该行映射，并不证明其他商家组齐全或全部交付完成。子单编号按合作资料前缀关联原主单编号，仍须用实际保存的编号查询，不能仅凭拼接规律猜一张并不存在的子单。若该区无对应行，先核原规格是否真为联营、审核阶段、所选商家和原查询结果。

图2：历史原行两件、已出库零及子单待出库；原主单编号、商品规格和合作方式仍回同一原订单核对。

3 逐项对原规格单位数量不要凭名称换算

拆分使用原销售明细保存的商家商品与商家规格对应关系，不能把平台商品编号当成商家原商品编号。两边同名也可能有不同规格或编号，应核原平台规格和映射后的商家规格，再对数量、单位和换算比例。平台原单位与商家单位属于各自企业的档案，子单需要找到商家有效单位中与原单位名称对应的单位，平台有某个单位编号不代表商家也能直接使用它。

原数量及原明细换算比例随拆分承接，不应再凭单位文字任意乘除一次。遇到“单位信息异常，请联系管理员”一类反馈，保留原规格、原单位名称及失败时间，由资料维护岗位核双方单位和原映射；不要改为另一单位、放宽精度或重新建同名规格来凑出看似相等的数量。历史两件对应两件只是这一笔的单位示例，不能推所有包装、基本单位和跨商家比例都相同。部分出库、退货与收货后还要对相应原业务数量，不能仅以子单订货数作为客户实际收货数。

图3：两方商品规格及单位档案分别核，承接原数量比例，不额外任意换算或改单位绕异常。

4 平台销售价与子单供货金额是两种口径

商家子单的成交单价取原平台明细中保存的供货成本价，原平台销售单价另作原价参考，不是将当前商品供货价重新覆盖所有历史订单。核对时把原主单销售金额与原子单供货单价、数量、小计并排看，不能要求主单与每个子单总额相等。供货价后来修改，也不能只看新的价格设置就断言这笔已生成子单必须回改，原规格与原保存价需要单独回读。

历史主单待收一百二十，商家子单商品两件、单价五十、小计一百，这笔差额来自两方原价格口径，不能直接当成结算净利润。子单是否另外取配送费还取决于适用应用、设置和原配送费资料，商品小计并不总是子单总金额；优惠、退货及双方收付也各回原记录。历史图只显示原子单件、数量、成本价、单价及小计，主单金额及规格编号还须回同一主子单明细核对，不能只凭子单小计认定双方金额及身份一致。

图4：历史子单件、数量二、成本价五十、单价五十及小计一百；不是平台销售金额或当前结算结果。

5 两端入口用原编号对应并核查询范围

平台联营订单列表的“单号”对应商家子单，点击进入联营订单详情；“订单号”对应平台原主单，点击回原订货单。列表还可核订货客户、联营商、合作模式、订单金额、结算金额、单据状态和结算状态。商家从“商家联营”进入当前合作平台的订单列表，核子单单号、订单金额、已收金额、财务状态及提交时间，不把另一个合作平台的同名订单作为本次子单。

查询时核商家、合作模式、单据状态、关键词和分页；时间条件可选择提交、完成、交货或作废时间，所取的是子单相应时间，不能用平台主单提交时刻代子单时间范围。有效合作关系、原客户和相关档案的当前状态也会影响平台列表是否显示，不仅是子单是否存在。查不到先清楚核适用筛选和原反馈，再回原主单逐商家组查映射。历史同一行左区保主子单号和客户，右区显示子单一百、结算零、已完成和待结算；已完成不解除结算待办。

图5：历史平台列表原子单、主单、原订货客户和商家，对照同一行原身份。

图5补：同一历史行子单金额一百、结算零、提交时间、已完成及待结算，与原主子单编号一同核对。

6 合作方式出库发货与客户收货分开跟踪

原合作方式决定商家自行发货或平台代发等交付方向。子单保原关系中的合作方式及相关仓库资料，平台原明细也承接相应标识；核订单时先看保存的原方式和原映射，不能仅按后来改过的合作设置推旧单该由谁发货。平台代发还要核原接收仓库与地址条件，商家发货则核原客户收货地址；地址或资料异常回原反馈处理。拆单链不允许以“上门自提”替代这项联营交付。

平台处理出库发货遇到商家发货的联营商品时，需回对应联营商订单核交付，不把总部普通商品出库当成所有商家已发。历史原联营行从已出库零到两件、子单待收货，说明出库量与收货状态不是同一字段；客户商城历史发货记录的一种两件、已完成及物流号又属于对应发货记录层。客户画面没有主子单编号映射，不能独靠物流号相似认全订单收货。部分交付和退货时逐原规格对累计数量，并回原主单、子单和实际发货记录，不以流程节点亮起代全部明细完成。

图6：历史原行已出库两件、子单待收货，与已确认收货分开。

图6补：客户手机商城原发货记录编号、已完成、一种两件、发货时间及物流号；不包含主子单映射。

7 创建中与补偿异常先停后续并回原结果

拆分失败或暂时没有反馈时，先保原主单号、商家分组、原规格数量及首个提示，逐组核是否已有子单、原关系和全部明细。部分临时创建冲突可进入有限重试，创建失败还会留下独立补偿处理记录；这不是任意资料错误都会无限自动恢复。后台创建补偿与子单后续流转是两项处理，原子单保存和关系生成之后，仍有另行处理子单的过程，不能把创建补偿已完成等同子单已审核、发货或收货。

仍提示子订单创建中或已转人工处理时，先停止平台出库发货，由负责岗位核原资料及当前允许入口。已有一条有效主子关系也不能代所有商家组与规格齐全，回查清单应逐项比原明细。若出现子单已推出但补偿任务状态回写失败的反馈，即使已看到子单也不可直接继续出库发货，应同时核任务状态和原业务结果。处理前后都不删除原关系、重建商品或再次整单订货来掩盖差异；无响应先查原编号，未经核对重复操作会使多张原单更难对应。

图7：创建失败、有限重试、人工接续及任务回写分别核，已有子单不代全部映射或后续流转完成。

8 最后核款货状态与双方原记录不要只看完成

商家子单显示已完成，仍可能处于待收款或待结算；平台对订货客户的销售收款与商家对平台内部客户的收款、联营结算也不是同一金额。历史商家手机管理画面原金额一百、运费零、优惠零及待收一百，完整顶部同时为已完成，客户为平台内部客户。这是商家管理端，不是终端客户商城余额页，不能用它证明客户已付或银行已到账。主单一百二十、子单一百的原例也不等于自动分账完成。

验收这一笔时，先确认每个商家子单和原规格都能回主单，再核原订货量、已出已发已收及退货量；随后分查平台客户收款、商家原收款与结算记录。结算额零和未收金额要保留原状态追溯，不把订单完成或客户物流记录完成当作资金结清。结果不明时提供脱敏主子单号、企业角色、商家组、失败时间和首个反馈，说明差异在映射、数量、交付还是资金。历史画面只能帮助识别字段，当前实际范围和结果仍须由相应岗位沿原业务核对。