联营订单履约闭环：订单拆分、商家发货或平台代发｜云上订货系统

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

沿平台主单、商家原子单及本批出入库关系，分别核两种履约和原资金结果。

1. 先认平台主单与每个商家子单，客户身份分开

平台员工在PC管理端“联营→联营订单”按原商家、单号、客户和单据状态查找，再分别打开商家子单与平台订货单。列表“单号”承接商家子单，“订单号”承接平台主单，点击目标不同；不要看到相似前缀就认成两张重复客户订单。先保原客户、平台企业、商家和两端原单号，后续出库、收货及结算都从这组关系核。

客户在平台购买多个商家商品，平台主单保留客户侧原商品、成交和收货安排；商家子单按各商家原商品明细接续。同一主单还可能有平台自有商品，不能把整单全部交给一个商家发，也不能在平台实体仓把商家自行发货明细再次出库。主单有几种商品与应有几个商家子单不是同一数量。

商家自己的“商家联营”工作台选原合作平台进入订单清单，查看的是本商家原子单；子单客户可能是平台在商家端的客户资料，并非主单终端客户的同一档案。历史列表保原主子号、商家及一百元子单金额，只定位当时原关系，不能证明本次全部商家子单已创建、客户已付款或原库存已扣。

图1：历史联营列表原子单号、平台订单号、客户、商家和子单100金额，不代主单总额。

图2：平台主单与商家原子单按原商家、规格和仓配关系分开。

2. 核确认、收款和财务审核节点，不由提交推拆单完成

拆单不能只以“客户提交成功”或“已付款”判断。平台订单按企业流程经过提交、订单确认和财务审核，所显示节点会随流程设置变化；联营子单创建在财务审核后的相应分支接续，自动流程可在无需人工财务审核时推进。先核原主单当前状态和实际审核结果，再查看各商家原子单，而不是跳过中间环节凭旧完整流程图认定已完成。

先付客户未完成本单收款时，财务审核有未付拦截；未处于允许审核状态也不能继续。客户付款和财务审核是不同结果，不能为尽快发货改客户结算方式或重复确认收款。已通过财审而子单仍缺时，保原主单及提示定位创建环节，不再提交一张相同平台订单来补缺。

子单生成后，提交、确认和财务审核仍有自己的接续处理，不保证创建一张草稿就立即可发货。原创建失败可能进入后续处理，未完成时平台出库与发货会受保护；“稍后”不保证某个固定秒数内成功。当前自动任务运行和同数据结果另核，以原主子关系、实际状态和允许按钮为准。

图3：提交、收款、财务审核与子单创建分节点，先付和自动流程分别核。

3. 逐项核子单规格、原供货价、单位和收货地址

打开原商家子单，逐项核商家原商品、规格编号、单位、数量和单价，并对照平台主单对应明细。子单使用商家供货基数，不把客户在平台的成交价直接当成商家单价。历史五升规格为件单位、两件、单价五十元、小计一百元，仅是该原规格清单；另一个规格或当前主单优惠后的金额不能套用这个数。

两端单位名称要能按原资料对应，件、箱及换算比例也要一起核；显示同样数量不证明货量相同。原单位无法匹配时有单位信息异常反馈，不应临时删除单位或随意换成数量相同的另一单位。规格对应缺失或失效也须沿原明细处理，不能新建同名商品代替已有订单关联。

收货资料按原仓配方式承接。商家自行发货沿主单终端客户地址，平台代发沿原指定平台仓地址，找不到指定仓时还须核默认仓。需配送而平台仓收货资料不完整时，原拆单有完善仓地址的反馈；联营流程也存在不允许上门自提的分支。原子单地址和交货安排正确，不代表客户已实际收货或运费与主单完全相同。

图4：历史原子单5L件单位、两件、单价50.00、小计100.00，不代客户成交价。

图5：子单原供价、单位和地址按仓配方式承接，不机械复制主单金额。

4. 商家自行发货，平台虚拟仓记录不当实体重复出库

合作方式为“商家发货（不入平台仓）”时，商家在原合作平台的联营订单进入子单详情，按原允许状态核规格、本次数量和出库记录，再完成本批发货。原子单出库用商家的原库存与作业入口，平台不能因主单仍有待发提示，就把相同商家明细从自己的实体仓再发一遍。

商家发货接续平台原主单的关联出库，使用该商家的平台虚拟仓和主单客户收货信息，同时保原商家出库与平台出库对应。虚拟仓记录用于原订单承接，不能解释为货物又进平台实体仓再离开。物流、配送方式、单号和发货时间按本次原出库承接，不拿另一张子单的物流覆盖本批。

混合订单仍须分明细判断：商家自行发货商品由商家处理，平台自有商品按平台自己的允许范围出库；已有原合作模式也不能仅按后来档案改选重新解释全部旧订单。成功提示后核本批两端原出库关系与状态，客户实物收到另核。历史两种仓配选择只是配置画面，不是本次已改变合作方式或原子单归属的证明。

图6：历史商家发货与平台代发选择，当前模式及旧单履约关系仍回原合作资料和订单核对。

图7：商家发货关联平台虚拟仓出库，不代平台实体重复发货。

5. 平台代发先核仓收货与联营入库，再核客户出库

合作方式为“平台代发（入平台仓代发）”时，商家先按原子单把本批货送到平台收货仓，平台再按主单向终端客户履约。这有商家到平台仓、平台仓到客户两段交付，不把仓收货人当终端客户，也不把商家已经发出当平台已经向客户发出。仓库、地址、联系人、原规格和本批数量必须对应原子单。

商家发货可推出平台联营入库记录并提交，当前原入库仍可能是待审核。先核该记录与商家原出库的关联、实物到仓和审核结果；不能只看一条“生成入库”说明就认定系统库存和成本都已完成。关联收货等接续可能推动待审核入库，但仍应以原入库实际状态为准，不代现场验货。

平台对客户出库时核原可用库存、允许状态和主单客户地址；尚未完成仓入库、数量不齐或规格对应不同，就先处理缺失段。原联营入库与普通采购到货也不是同一原单，不能为补联营关联另录一张同货量的采购入库。仓批次已经完成不代原客户订单已经发货、收货、退货或结算完成。

图8：平台代发先生成并提交原联营入库，待审核与客户出库另核。

6. 分批保本次数量、物流和原关联，发货收货分开

每次发货保准确原出库单和本次明细，不把整单订货量反复写成每批发货量。示意订货十件，第一批发四件，未发六件继续保留；第二批再按当时剩余与允许数量处理。实际可发还要核已出、在出、退款与退货等原数量，不能只用十减四忽略其它占用或原状态变化。

本次物流和配送信息属于该批原出库，商家出库与平台出库或入库有自己的对应关系。历史原作业记录显示一条、五升规格件单位、本次出库两件、系统库存九十八，仅定位原批次字段；它没有证明今天库存仍九十八，更不证明这两件已经送达。反馈未知时先核原记录是否已发，不重复新建另一条两件出库。

发货和收货是不同节点，客户收货、平台仓收货也分别核。相关原记录处于待收货或待审核等允许状态时，收货可沿已有关系接续另一端；不应对无关联记录强制写完成。少货、破损或错规格先保本批事实与原订单明细，后续退货退款另按原售后入口处理，不能用整单强制完成掩盖未交付数量。

图9：历史原出库批次两件、系统库存98，只定位原字段，不代当前发货或收货。

图10：每批原数量、物流、出入库关系和收货分开，不用整单量反复发。

7. 主单金额、商家子单和结算资金分别核对

金额先分平台主单客户成交、商家子单供货和联营结算。平台收到客户的一笔钱不等每个商家已经收到相同金额；商家子单一百元也不代整张主单总额。运费可能按原商家和平台分别计算再承接，优惠、原收款与退款另有口径，不能把所有列相加当一次客户付款。

联营结算按所选原子单商品数量与供价、原销售统计、返款扣点及已分账等基数分别核。结算待审核、待打款和已结算与订单已完成不是同一状态；原列表曾同时显示子单已完成和待结算，说明需要继续核结算环节。待审结算通过后仍有付款接续，不把审核通过等同银行已经转账。

原关联付款完成可写系统实际付款和结算完成，实际银行或支付渠道到账还需对应凭据。历史结算页只有零汇总和栏目、没有结算行，不能证明当前原商家已结清，也不能据此判断少款。发生退货或原单价差时，沿同一主子单与结算明细定位，不删原关联、随意调金额或承诺系统完成必然等银行到账。

图11：历史结算页零汇总与金额栏目，空页不证明当前已结清。

图12：主单客户款、子单供货、结算审核付款与真实到账分别核。

8. 缺子单或状态不同，沿原失败与售后边界接续

查不到子单时，先核原平台主单是否已经到正确财审节点、相关明细是否为联营商品，再核原商家、单位对应、仓配方式和仓地址。筛选状态、原合作平台和岗位可见范围可能影响列表，空清单不必然等后台没有原子单。创建未完成的提示出现时，停止本张原单继续出库发货，沿原关系与允许处理入口接续，而不是重新向客户生成一整张重复订单。

已经有子单却未发、只发部分或两端状态不同，按原批次查商家出库、平台关联出入库及各端收货。发货中原版本或单据状态变化可能有刷新提示，不能把所有旧页面请求一律说成相同拒绝规则。保原单号、商家、规格、本次数量、操作时间和脱敏反馈，先确认已有结果再决定缺哪一段。

售后区分未出库退款与已发货退货，原已发、已退和待处理量影响继续处理范围；订单、原出入库与结算状态各保留追溯。原商品上架、平台主单完成、商家子单完成、结算完成都不能代全部货款闭环。操作时分别核岗位权限、自动处理结果、同条件跨端库存和真实资金；历史画面或规则说明不能证明当前各环节已经完成。