平台代发模式：商家补货、平台入库、出库与客户收货｜云上订货系统

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

沿原平台客户单和商家子单核两段交付：商家送至平台、关联入库审核，再由平台向客户出库发货并核每笔收货。

1. 先核平台代发方式和原发货仓库

平台代发是商家先把对应货物送到平台仓库，再由平台承接客户配送。开始前在联营商资料核仓配方式和默认送货仓库，分清“商家发货（不入平台仓）”与“平台代发（入平台仓代发）”。历史画面打开了这两个选项，但当前选中的是商家发货，该历史合作资料的默认送货仓库为空，不能拿这一张图证明已经保存代发设置或已经配置好收货仓。

对准备接续的原订单，核联营商身份、平台企业、合作方式和实际发货仓库。商家子单承接时会把当时的仓配方式与发货仓库记到原主子关联中；之后修改合作资料，不应凭当前下拉值就判定旧单已经换成另一条路径。旧单继续沿自己的关联资料处理，新单也要核实际保存结果，不假设关闭代发会自动作废旧入库。

代发分单会使用对应仓库作为商家送货地址，地址资料不完整会限制接续。检查的是原仓库资料及原错误反馈，不让商家随便填写客户地址来冒充平台仓，也不把客户自提承诺为此代发路径可以直接使用。历史画面用于辨认流程位置，实际办理还应核当前岗位、企业授权及同一主子单的出入库原结果。

图1：历史仓配方式局部：商家发货和平台代发两个选项；当前选中商家发货，默认送货仓库还应回原合作资料核对。

2. 沿平台原单确认商家子单及补货范围

在平台的联营订单记录中先找到这张客户原订单对应的商家子单，逐项核两个编号、客户、联营商和原商品规格。历史列表的商家子单编号带商家前缀，另有对应的平台订货单编号；这提供原单关联的查看线索，没有展示该单已经采用代发，也没有证明所有同号商品来自同一家商家。

商家收到的是自己的供货履约子单，平台保留客户原单。子单明细会对应商家原商品规格，单位按两端资料匹配；相同商品名不能代商品编号和规格编号，件、箱、瓶不同也不能直接相加。对子单中每项待备货数量，核对应原平台明细和之前已处理数量，不能用客户主单所有商品合计让这一家商家重复补货。

该项的送到平台承接沿商家原销售出库发货关联生成平台入库，并非任意新增调拨单都会自动接入客户原单。另有独立调拨业务时按原调拨单关联处理，不因实际货物去了同一个仓库就把它和联营子单视为同一笔。找不到商家单或商品对应关系时先查原平台单状态、原单位资料和分单反馈，不能另建同名商品补一条虚假的关联。

图2：历史平台联营订单局部：商家子单与平台订货单编号、客户和联营商；不证明该单采用平台代发。

3. 商家本次出库与送到平台的发货分开

商家在自己的子单核本次出库清单，先对规格、单位、数量、所在仓库和实际货物，再核原出库审核与发货状态。历史出库局部显示五升规格、单位件、系统库存九十八件、本次出库二；该历史原出库的发货和收货节点尚未完成，当前作业仍须回原出库状态核对。系统库存是该画面的库存值，本次二件才是这一笔发货范围，两者不能互当。

有原销售订单关联的出库审核后还要接续发货，发货记录要保发货时间、物流信息和原出库编号。前端发货时间为空会提示，返回成功才更新详情；服务端也会核原出库状态及传入版本。按钮出现、打印发货单或保存物流草稿，都不足以证明本次已经发出，更不能代平台实际签收和审核入库。

本次发货明细决定之后对应的平台代发入库数量，不应直接拿整张商家子单原订货量当本次入库量。分多笔发货时各笔核原出库和关联入库，重复编号先查原关系，不承诺系统在所有入口都替你防止重复补货。缺批次、库存不足或状态错误等提示按原商品条件和原出库记录处理，不以修改另一家商家的库存绕过本笔限制。

图3：历史商家出库局部：5L规格、件、系统库存98件与本次出库2；当前发货入口及进度须回原出库记录核对。

4. 平台关联入库生成后先核待审核结果

商家发货接续成功后，平台沿同一张原主单和商家出库查对应联营入库单。核入库类型、单号、原关联订单、入库仓库、商品规格、数量和单位。代发路径会取原主子关系的仓库，并按商家本次出库清单匹配平台原规格；匹配不到原商品关系会限制处理，不能用平台商品名相同推定匹配成功。

平台代发生成入库会保存并提交，实际接续先到待审核。这里“已生成”“已提交”和“库存已经入库”是不同结果，不能把商家已经发货或平台出现一张入库单当库存增加。入库详情的提交和审核按钮对应不同状态；查看当前状态和审核完成时间，再核真实库存日志，不凭一条自动处理文字跳过收货验货。

商家自发给客户走另一条关联出库处理，不能将其自动接续的出库发货结果套到平台代发。代发平台收到货物后应继续核这张待审核入库，尚在运输中的货物不当已经在平台仓可配送。出现新旧页面不同、关联入库为空或提交反馈不明时，保原商家出库编号和本次返回，按原关系找结果，不立即新建一张无关联其他入库来遮盖原进度。

图4：平台代发入库节点：商家发货、平台关联入库保存提交与审核分层。

5. 收货审核核原数量换算和库存流水

平台收到商家货物后，按原入库单和实物逐项验收，核仓库、原平台规格、数量单位和原出库对应记录，再由有权限岗位处理审核。入库审核会带原单版本，仓库权限也是核对范围；状态或资料不符时保原提示并刷新原单，不把修改普通入库单的方法承诺为所有联营关联单都可用。

这条关联审核会接续对应商家出库的收货，并处理平台待审核入库库存。不能因为关联流程经过商家收货，就判断平台不需要增加库存。按实际数量和换算核结果：入库数量乘实际换算比例进入对应原仓库的基本单位库存，库存日志保原入库编号、规格和原单位数量，审核完成另有完成时间。二件是否等于二瓶，要看该规格实际单位换算，不凭页面单位字样推断。

审核成功后重新查同仓库同规格的入库状态和原库存流水，再对实际增加量。总库存、可用数量、其它待办及批次串号条件各有自己的对象，不能只看企业总库存有变化就认为这笔已完成。少货、破损或规格错误先留原验收事实，沿原单允许更正与退回流程处理；不承诺随时直接改生成明细，也不把备注写少收当原数量已经改正。

图5：关联入库库存核对：关联审核、商家原收货与平台库存原数量换算。

6. 平台向客户出库发货另查原订单

平台对客户的配送沿客户原订单另核出库和发货，商家送至平台与平台送至客户是两段交付。平台入库已审核，只说明这笔货物接续了平台库存，不表示客户原单自动全部发货，更不代表客户实际收到。先对客户原单各商品未出、已出和待处理数量，确认本次平台出库包含哪些规格及原仓库。

平台本次出库单核原客户订单、仓库、规格单位、数量和审核状态，再接续发货时间、物流公司、运单号及原返回。原出库详情将提交、审核、发货按状态显示，发货后才进入相应收货阶段。不能把商家补货运单直接当客户配送运单，尤其货先送到平台仓再二次配送时，应分别保两段原物流证据。

多商家或多批处理时，不要求一条商家入库覆盖客户主单所有商品。本批能否出库仍看对应库存及原单状态，不因其它规格已到货就承诺整单可出。库存不足、批次资料缺失、版本改变或状态已推进时先看原出库反馈和已保存结果；不要重复生成同样客户出库来补界面未刷新的数量，也不将商家自发的虚拟出库行为套成代发自动出库。

图6：代发两段交付：商家到平台与平台到客户分别核原记录。

7. 客户收货按每笔发货核部分进度

客户按平台原发货记录核本次实际到货，先看原订单与出库编号、商品规格、单位、数量、发货时间和物流，再对实物。收到一批就核这一批，不用商家子单完成状态代客户签收。平台仓已经收货、客户有物流号、某张出库单已完成，分别表示不同节点，不能一个完成图标代整张客户单的全部商品都收到。

本次短少、破损、规格不符或数量不同，保实收数量和原发货清单，由相应岗位核原平台出库、商家出库与入库关联。数量是否允许修改、是否要走退货或其它更正，按原单实际入口和状态处理，不承诺任何完成单都可任意改最终数量，也不把供应商直送实收调整规则套到这条联营代发。

部分商品已收、其它仍在商家待发或平台待审时，逐笔核各自原记录并继续原待办。返回不明确或页面仍是旧状态时，先刷新同一原记录，核是否已经收货或完成，再判断重试；收货路径处理待收货状态，不能从旧按钮推定可重复推进。不同岗位看到空列表，还要核企业、单号、时间和筛选，空结果不等于原订单、原入库或客户货物已不存在。

图7：客户收货差额：按批收货、剩余待办与失败原结果分别核。

8. 履约数量与客户款项商家结算分开

最后分别核货物履约与款项：客户原订单的应收已收、商家子单的供货金额与收款、平台同商家的结算记录，不能三处金额强求相同。历史商家子单清单是单位件、数量二、成本价五十、单价五十、小计一百；该历史原子单已收为零、待收为一百，即使流程栏走到完成也不能说已经收清款项。

商家子单金额承接原供货价，平台客户单使用客户成交依据，可能还有各自运费或费用规则。逐项沿原明细金额和原关联核，不把销售价格比例叫利润，也不把数量入库当自动付款。联营结算的审核、应付和实际打款另查原结算与资金记录，空结算列表或零汇总也不足以证明无欠款或已经到账。

验收这一张代发业务时至少串起平台客户原单、商家子单及本次出库、平台对应入库和客户原出库收货，再单独对实际款项。哪一笔有差额就保哪一笔原编号、规格单位、状态、时间与提示，由原允许流程接续；没有明确结果不重复发货或重复入库。实际库存、岗位权限、资金结算及客户收货应分别回同一原业务核对，未确认的记录继续列待办，历史画面不代当前结果。