联营合作模式选择：商家发货还是平台代发｜云上订货系统
云上订货 · 更新于 2026-10-08
先按真实货流选方式，再沿原主子订单、仓库记录与结算分别核对。
1. 先确定货从哪里走，分清联营双方的责任
联营合作先定货流和责任，再选择仓配方式。商家发货表示商家从自己的实际仓库向客户交付；平台代发表示商家先把对应货物送到平台约定仓库，平台再负责向客户配送。两种方式都需要明确谁备货、谁处理缺货、谁联系客户、在哪一段核实数量与状态，不能只按哪个选项看起来方便来选。
平台和商家是不同企业，平台面向客户的原订货单与商家承接的子订单有各自商品和金额。平台可跟踪关联单据，不表示商家的实物库存已经变成平台实物库存；仓库存在或库存显示可用，也不证明这一批货已经运到平台。先把商家原仓、平台收货仓、客户地址和对应单据连起来，才能判断由谁继续处理。
本篇以联营商家资料和原订单关系核两种方式，不把它们当成供应商直送采购。供应商直送有采购和客户实收的另一条链，不能用联营模式去替代其入口、权限和金额。历史资料截图只用于定位原字段，当前企业入口、岗位授权、具体订单、仓库库存和实际交付需按同数据核验。
图1：商家发货与平台代发的真实货流及平台记录区别，不把虚拟仓记录当实物入库。
2. 商家发货核原子单与平台虚拟仓承接
商家发货时，在联营商家资料中选“商家发货（不入平台仓）”。原联营商品被分到对应商家的子订单，收货联系人与地址沿客户原订单承接。商家在自己的订单中完成出库与发货，平台客服按原子单、原出库和物流去跟进，不应在平台实物仓再次替商家拣同一批货。
系统建立联营商家时可在平台建立对应虚拟仓，商家子单发货后也可承接平台侧联营出库记录及原物流信息。这些记录用于连接平台主单与商家处理结果，不改变货物实际由商家发给客户的事实。看到平台有出库单，不能反过来把合作判成平台代发，更不能认为货物先进入了平台实物仓。
核本次出货对应的商家规格、原单位、数量与主单关联，再核剩余尚未交付部分。商家发了一部分不等平台整张混合订单都完成；平台记录已发也不等客户已经签收。若平台尝试对商家发货的明细做出库或发货，应根据原反馈回对应联营商订单处理，不通过临时改模式绕过归属。
图2：历史仓配方式下拉：商家发货不入平台仓、平台代发入平台仓代发。
图3：商家子订单发货与平台虚拟仓出库关联；平台记录不代客户签收。
3. 平台代发先核收货仓与联营入库状态
平台代发时，在资料中选“平台代发（入平台仓代发）”，并准备确实用于收货和配送的仓库。商家子单的收货资料取约定的默认送货仓；未指定或查不到时可能承接平台默认仓，所以界面未填不必然等于审核必失败，也不表示随便使用任何仓库都符合原合作。
核实际被取用的仓库名称、收货联系人、地区和地址。原订单涉及配送但收货资料不完整时，会反馈需要完善平台代发仓库地址后再审核。这里应修正原仓库资料并回原单核结果，而不是改成客户地址或切换商家发货，把“货先到平台”的安排悄悄改掉。
商家子单发货可生成并提交对应联营入库单，承接本次出货的原商品、单位和数量。当前提交后的待审核入库不等已完成入库，更不等实物已经到货；仓管先核实物，再按原入库单状态处理。平台还需从实际仓进行原客户订单的出库和配送，两段交付分别确认，不能以商家发到平台就把客户标成已收到。
图4：平台代发先承接待审核联营入库，再核实际入库与平台客户发货。
4. 在商家资料里保存方式与配套合作规则
进入“联营→商家管理”，打开准确商家详情后点击编辑。核公司名称、仓配方式、默认送货仓库、经营分类及品牌、屏蔽客户类型和区域、销售价格比例、联营商代码、商品发布权限，以及返款和结算设置。方式只决定该项货流承接，商品能否发布和某客户能否看到，仍与原商品及合作范围有关。
界面价格比例输入范围为百分之一百至九百九十九，联营商代码用于区分子单编号。历史本例分类为粮油调味、价格比例百分之一百二十、代码为QH、商品需审核后上架，这些是原资料，不承诺每件商品今天都按相同实价成交。默认送货仓库没有统一必填标记；平台代发仍应主动确认最终仓库和收货资料。
保存时缺企业名称、合作方式异常、经营分类未选、价格比例或代码为空，会有相应反馈；当前企业的有效代码被其他商家占用也不能继续保存。返款比例等配套资料按实际提示补齐。成功后回同一商家详情核原方式，失败或反馈未知先查原资料是否改变，不以关闭编辑页或一张预览当成功。
图5：历史合作字段：粮油调味、价格比例120%、代码QH与审核后上架。
图6：仓配、范围、价格、发布及结算设置用途不同，按原反馈补资料。
5. 客户原订单按商家承接，数量单位和价格分别核
客户的一张平台订单可以包含多家商家的商品和平台自有商品。联营拆分按原明细商家身份分组，只把对应联营商品交给相应商家；不是按商品名字、客户或配送地址任意拼成一张采购单。回查平台主单号、带商家代码的子单号和原明细关系，不能只用相似名称认领商品。
平台商品规格要对应商家原商品规格。原平台单位与商家单位按名称承接，找不到对应单位时会出现单位信息异常反馈；不能把“件”和“箱”仅凭数值相同看作同量，也不通过换商品掩盖单位关系。核原数量、原单位及换算关系，不把拆出的子单数量当已经实物发出。
商家子单商品价格采用供货价，并分别保留平台原销售价，两个金额不要求一致。举例原数量二件、平台原价每件六十元、商家供货价每件五十元，对应商品金额分别一百二十元和一百元；这只是口径示意，运费、优惠和实际结算还要核原单。拆分时保存合作方式与原关系，后续不能用当前档案覆盖所有历史含义。
图7：平台主单按原商家承接子单，规格单位与供货价、平台原价分别核。
6. 混合订单与失败反馈按本次明细接续
处理出库或发货前，先看本次选中的明细属于谁。混合订单中的平台自有商品可与商家发货商品有不同作业责任，整张订单能打开不代每项都允许从平台仓发。原操作选到商家发货明细时，应回对应联营商订单；不要把不同责任的商品合在一个平台出库动作里重复发货。
原子订单仍在创建或关联结果未知时，先核原平台单与已经出现的子单，不继续抢着出库，也不反复重新保存整单来试。原子单尚未承接完成或商品属于商家发货时，应按当前原反馈及单据状态处理；不要连续重试或多人重复办理，先确认是否已有相应原记录。
单位异常回原单位关系；平台代发地址不完整回实际取用仓库；关联规格找不到回原商品映射；发货状态不允许回最新原出库单。当前已发不能再当待发处理，数据更新提示后应先核原记录再接续。保原主单、商家子单、入库或出库标识及脱敏反馈，不能为消除提示改变客户交付方式或删原关联。
图8：混合订单按本次明细归属处理，失败回原单位、仓库、关联及状态。
7. 货物完成不代结算到账，供货款与返款分开
仓配方式不等收款方式，商家已经发货或平台已经入库也不等商家结算到账。客户付给平台的销售款、商家供货金额、返款扣点、已分账金额与最终结算应付各有来源。销售价格比例不是返款比例，返款设置也不是给客户退货退款；看清原字段用途后再核原款项。
结算按所选商家子单原供货数量和价格计算商品结算额，承接原平台价格的销售额另列。示例供货五十元乘二件为一百元，返款百分之五为五元，本例已分账为零时应付为九十五元；已有原扣点金额或分账时按实际记录核，不重复扣除，也不把一百二十元平台销售额直接当商家应收。
结算单生成后先待审核，审核通过进入待打款，关联付款完成后系统才承接实付金额和已结算状态。历史详情写订单完成后当天可结算、每天结算、返款百分之五，只说明原规则，不证明已经生成或支付九十五元。周期和可结算间隔不保证立即自动银行到账，财务要另核原结算单、付款记录与商家实际收款凭据。
图9：历史结算规则：完成后当天可结算、每天结算、返款5%，非已到账。
图10：供货100元扣返款5元、示例分账零得应付95；审核和付款仍分开。
8. 回原订单核方式、款货记录与实际结果
保存合作方式后，回同一商家详情确认展示，再选已有授权范围的一笔原业务沿主单、子单和仓库关联核对。商家发货看原商家出库、平台虚拟仓承接及客户原收货；平台代发看商家出货、平台联营待审核入库、实际入库、平台再出库配送与客户实收，不能只看一个状态就认定两段都完成。
已有订单调整合作方式时，先明确这些原单继续由谁处理。当前发货判别优先原明细及主子关系保存的方式，缺少相关历史信息时还可能参考当前商家配置；这不等所有旧单都永久固定，也不等改档案会全部自动迁移。回具体原单核仓库、地址、数量和作业责任，不能只用今天详情代过去的业务关系。
历史商家详情确认的是原企业、商家发货方式、分类、价格比例和代码，库存、客户签收及资金还须回对应原单和实际凭据核对。实际验收把原商品规格、本次数量、未交付部分、两方原金额、结算应付与实付分别核到记录。若仍不同，沿原关联定位缺哪一步；不以旧图或配置说明承诺当前完整权限、库存及款货流程通过。
图11：历史商家详情核原方式、分类、120%和QH；未证明订单或资金当前结果。
图12：原模式、款货关联、客户实收与结算各自确认，不用当前档案代历史全链。
下一步学习
- 联营版业务总览：平台、联营商家与订货客户怎样协同｜云上订货系统
- 设置联营经营范围：分类、品牌、客户类型与销售区域｜云上订货系统
- 商家发货模式：接单、出库、物流与平台状态同步｜云上订货系统
- 平台代发模式：商家补货、平台入库、出库与客户收货｜云上订货系统
- 平台代发联营单无法审核：商家分组与平台收货仓资料核对｜云上订货系统