客户购买联营商品：混合选购、分组运费与提交结果｜云上订货系统

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

从同客户的商品规格和实际选中购物车核本次订单，再区分配送运费、原主单与商家子单、提交返回和付款交付结果。

1. 先核同客户的联营商品规格与单位价格

客户购买联营商品仍从当前店铺的商品详情和购物车进入，但先确认自己登录的客户、店铺与商品编号。平台联营商品和商家自有商品可能同名，不能拿商家自有销售价当这个客户的商城价格。历史手机详情显示清禾餐饮调和油六十元、已选五升规格及平台对应编号；这是原画面的报价和规格，并非当前所有客户的固定成交价。

逐项核规格、订货单位、数量和本客户价格，尤其一件、一箱和基本单位的换算。多单位情况下起订数量和限订数量按所选单位确认，不把基本单位二十四瓶直接当二十四箱。购物车中规格的实际价格还可能涉及客户价和促销；改变单位数量后看本次小计，再进入确认页，商品行展示价不足以代每项规格金额。

商品和规格在加入购物车后可能改变，提交时仍需核实际返回。普通创建会回读规格与客户价，并区分无效规格、预售商品不适用普通下单、下架或过期等反馈。库存限制、客户范围及起限量也须按本商品实际条件确认，不凭历史可加入购物车就承诺当前可提交。历史画面用于辨认步骤，当前客户能否看见、选购及提交仍须按同一原规格的实际返回核对。

图1：历史手机商品详情局部：60元、已选5L与平台商品编号；加入购物车的实际结果须回当前同一规格核对。

2. 购物车混合选择先分清当前商城模式

将需要的可订商品加入购物车后，只选择本次要提交的明细，逐项看规格、单位、数量与小计。历史购物车显示五升商品六十元每件、数量二，该历史选择的合计为一百二十元。这个合计是该原商品选择结果，未证明加入另一家商品后最终含运费金额仍一样，也不把未选中的商品计入本次订单。

普通联营购买中的平台自营商品与联营商品可在同一选购流程核明细，但不是所有商城模式都允许跨任意组同时提交。集团或店铺购物车分组模式，选择另一组会取消原组选中，组全选也只选择该组上架商品。遇到选中项变化，先核当前商城模式和本次实际选中组，不把分组互斥误认成商品删除或库存突然减少。

购物车展示分组与运费按商家分组是两件事。前者决定本次选哪些商品，后者决定当前选中明细怎样计费；不能因为列表排在一起就推免运共用，也不能因有两家商家就断定两张客户订单。修改数量、删除明细或切换组后重新检查所选商品和合计，先按实际选中范围继续，不通过重复加车绕过起订量或限定量提示。

图2：历史手机购物车局部：5L、60元每件与2件；当前合计须回同一购物车选中明细核对。

3. 确认实际收货地址配送方式和订单费用

确认页先检查本张订单实际使用的收货人、联系电话、地区和详细地址，核是不是本次收货门店。档案保存过地址不等于这张订单选择的地址正确；切换门店或配送方式后等待页面重新计算，再核商品数量、商品金额、运费和最终总额。手机号仅用于业务资料核对，不应复制到对外沟通或截图说明中。

历史确认页显示一种商品共二件、配送为快递、商品金额一百二十元、收货运费零，该历史确认页的订单金额为一百二十元。这里的零是该历史订单确认结果，不代表所有联营商品都免运费。商品总价说明不含运费时，不把它当最终应付；如果选了额外服务、发票或其他允许项目，核实际确认页相应费用与保存结果，不自行把所有费用分摊到每个商家。

联营业务有不能选择上门自提的处理限制。限制出现在商家子单接续节点，不能承诺每个手机确认控件都会提前隐藏自提。看到自提选项也不能为了免运费随意选择，先按这笔联营商品支持的配送安排核原结果。非自提时收货信息不完整或地区数据异常会失败，先补对应原地址；平台代发的仓库地址问题由平台核，不要求客户将真实收货门店改成仓库。

图3：历史确认页局部：一种商品共2件、快递、商品120与运费0；地址另核不展示联系方式。

4. 分组运费与满额起订条件分别核对

分组运费只有在相应运费应用、商家入驻和配送规则启用按商家分别计算时接续；未启用这些条件，沿店铺普通运费规则核。本次商品会按商家归属及平台商品组计算，再将各组运费汇总。平台自营组和每个商家组分别核金额、数量、重量、体积与地区，不能将整车金额自动用于每一组的满额免运门槛。

满额免运取当前计费组所传的商品金额，指定客户类型免运和指定商家免运又是不同条件。比如一组达到门槛并不证明另一组也达到，指定商家免运也不代表平台商品组一起免费。重量和体积会结合所选单位换算系数与数量计算，数量合计则应注意订货单位；不要用两件不同包装商品推成两公斤或同体积。实际费用仍核本次配送规则和保存原结果。

规格起订量、区域起订重量、满额免运和最低运费不能互代。数量不够按该规格允许单位修改；地区起订重量提示按实际重量和地区核；最低运费涉及低于相应金额条件，而不是再生成一笔商品金额。前端与服务端分组条件及计算入口各有范围，不能承诺所有组的起订规则和页面明细完全一致。确认页零运费先看是否启用、是否匹配免运与实际规则，再核订单保存的总运费。

图4：联营运费分组：平台商家分组、金额单位门槛与总运费分层。

5. 提交成功与购物车清理付款结果分开

点击确认订单后，以服务返回和原订单记录确认创建结果，不以按钮变灰、加载结束或成功图标单独判断。需要配送时间、配送方式、收货信息或发票信息时，先按当前页面提示补全；没有选中商品不能提交。系统还可能返回欠款未结清限制或具体商品错误，分别沿客户原欠款和同规格处理，不能通过更换商家商品绕过原客户限制。

成功返回后还会接续购物车清理，再按订单金额和状态进入付款、详情或订单列表；清理购物车失败不表示订单没创建。提交成功却仍看到购物车商品时，先查原订单编号、金额与明细，确认有无本次原单，再决定后续动作。拆单模式可能进入合并支付或原列表，与联营商家履约子单不能混成一个概念，也不把跳到付款页说款已到账。

历史手机支付画面显示订单提交成功、应付一百二十元，可选货到付款和线下支付，说明当时开放的付款安排，不能替所有店铺承诺同样方式。货到付款尚需后续真实收款，线下付款记录也要核收款状态；使用预存或线上支付时核原交易与订单收款结果。历史提交页面不能证明当前已经扣款，不将选择付款方式当整项付款完成。

图5：历史手机订单支付局部：提交成功、应付120及货到付款线下支付；不代款项已到账。

6. 沿客户原单核平台与商家子单关联

客户先沿自己在平台的原订单跟踪购买结果，商家子单用于平台向商家承接供货与履约。非子单财务审核后会按商家归属推送相应子单，不应将客户点击提交写成每次立即全部商家子单都生成。没有立刻看到商家单，先核平台原单状态及接续处理，不再购买一遍同样商品制造第二笔客户需求。

主子关系要核平台原单编号、商家子单编号、商家身份和对应原商品规格。商家子单编号承接商家前缀与原单编号，明细转为商家原商品规格，单位按平台与商家单位名称对应。单位资料异常或平台代发仓库地址不完整会限制接续，由平台和商家核对应原资料；不能让客户随意改数量或新增同名商品来补一条关系。

客户成交金额与商家供货金额不同。子单明细使用原供货成本价作商家销售价，并另留平台原销售价，不能要求两端总额完全相同。分组运费启用时还会从原单与对应商家运费关系接续；税、优惠、运费与子单金额的具体结果逐项核原记录，不承诺平台所有售价供价即时同步。一个客户主单关联多个商家处理结果，并不要求客户向每张商家子单重复付款。

图6：客户主单与商家子单：平台原单、商家原规格及供货与成交金额分开。

7. 发货数量物流与原收货结果逐笔核

客户在原订单详情打开发货情况，核记录是否属于这张原单、各项商品数量、发货时间和物流信息。页面可以列出原出库发货记录，也可能有独立直送记录，不能把直送供应商最终数量调整规则套到普通联营出库。主单可能分批或由不同商家接续，先按每笔记录所含商品规格核数量，再与原订购量比较。

历史手机发货局部显示原出库单已完成、一种商品二件及物流单号。它证明原发货记录的展示字段，不代表整张客户订单的所有其他商品都完成，更不代表原款项结清。商品数量中的件要与清单实际单位对应，混合商品不能把总件数当同一规格的基本单位数量；物流编号也不能代客户已签收或实际已验货。

收到货再按原记录实际数量和允许的确认收货入口处理，缺货、多货、损坏或规格不符先保本次收货事实。确认按钮会随原发货状态显示，不能凭已经有物流号就跳过验货；没有确认入口时先核原记录状态与交付方式。已完成发货与订单收款分别看，货到付款尚未收款继续查原单款项，不因为某个完成清单没有这张单就再次订货。

图7：历史手机发货局部：原出库单、已完成、一种2件和物流单号；非整张订单款项结清。

8. 失败或返回不清先查原订单再接续

返回不明确先查同客户订单列表及详情，按本次时间、商品规格、数量、地址和金额找原单。找到了就沿原单继续核付款或交付，没找到也要先保原提示和请求结果再按允许方式接续。旧确认页、购物车还在或清单仍显示旧合计，都不能作为本次创建失败且可以无条件重提的依据。

失败位置要分开。商品异常核原规格与当前状态，地址必填核原收货资料，欠款限制核客户原未结订单，分组运费不符核配送方式和对应组金额，商家子单错误核原单位与合作仓配资料。保存原订单、清理购物车、平台审核拆商家单和付款是不同步骤；部分步骤失败不承诺全流程没有保存，也不将缺少一张商家单当所有客户商品均未提交。

最终核对本张客户原单的商品金额、总运费、实际应付与已收款，逐笔发货收货和商家关联由相应岗位接续。涉及改数量、退款或重新报价时沿原订单允许流程处理，不让客户重复购买替错误更正。实际提交、付款及交付仍须按当前客户权限和同一原订单返回分别核清，尚未确认的记录列待办；历史画面和金额不代替当前业务结果。