商家发货模式：接单、出库、物流与平台状态同步｜云上订货系统

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

沿商家原子单、本批出库与平台关联，分别核库存、物流、收货和资金结果。

1. 进入原合作平台订单，先认商家子单与客户地址

商家在PC管理端进入“商家联营”，选择原合作平台后打开订单列表，再通过原单号进入订货单详情。这里是商家自己的子订单，不是平台员工查看整张客户主单的同一入口。先核原企业、合作平台、商家子单号和对应平台订单，避免在错误平台把相似规格的另一张订单拿来出库。

“商家发货”表示货物由商家直接向主单客户交付，不要求这批实物先进入平台实体仓。子单的客户资料可能是平台在商家端的客户档案，实际收货地址却沿平台主单的终端客户安排；核收货信息时以原子单承接的地址为准，不能仅凭客户名称推收货地点。原规格、单位、数量和交付安排也要与主单对应明细相符。

手机管理端可以从原订单进入“出库情况”，客户商城则从客户自己的订单进入“发货情况”，三种身份不能互相替代。历史手机列表同时显示子单已完成、一种商品两件、金额一百元和待收款一百元，只定位当时原字段。订单状态完成不保证该子单货款已结清，更不保证整张平台主单的所有商家商品已经收到。

图1：历史手机管理原子单已完成与待收款100同时显示，两种结果分开。

图2：商家原工作台、平台主子单关系和终端客户地址分别认。

2. 按原状态接续确认审核，创建子单不等已可发货

进入详情先看原单当前状态及企业流程设置。子单创建后可能由后续处理继续提交、确认和财务审核，但不能把“已经出现一张子单”当成已经通过所有审核。待提交、待确认、待审核、待出库等各有自己的允许处理范围；界面所显示的步骤和按钮可能随原企业设置变化，不承诺所有商家都有一个相同的独立“接单”按钮。

本次出库应从待出库或部分出库的原单及其允许明细开始。仍在确认或审核环节时，先核需要完成哪一段；订单已作废或已完成后不能继续用旧页面发相同一批货。原子单存在自动审核的接续，也须回看本批结果，须回读本次审核结果，不能仅凭一次点击认定全部审核已完成。

商家联营子单与平台主单保留原关联，商家页面对直接作废、强制完成有平台处理提示，不能用这些动作绕过剩余数量和原主单履约。列表为空时先核合作平台、单号与状态筛选；查不到本商家原子单不等平台订单不存在。当前岗位实际可见范围、自动处理运行和同数据状态仍须在原企业分别确认。

图3：创建子单、确认审核、出库发货和收货按允许原状态接续。

3. 核仓库、原单位和本次数量，剩余与在出分开

在“出库情况”核原仓库和待出商品清单，再看规格、单位、待出、已出、在出及本次出库数量。历史PC画面主仓库的五升规格用件单位，待出两件、已出零、在出零、本次两件，系统库存一百件；它说明原页面如何对照，不表示当前仍有一百件或该订单所有规格都可出库。

数量先认原单位及其换算比例，件、箱不可仅凭相同数字替换。示意原订十件，已出四件、在出两件、未出退款影响一件，剩余参考三件；这仍需与当时原允许量、仓库存和其它业务条件一起核。已发货退货沿原售后记录处理，不能把所有退货量随手加回本次待出。分批作业只填本批，避免把正在处理的两件再次发出。

仓库、有效明细或正数数量缺失有对应出库反馈，超过允许量也可能被拦。批次商品还要核本次分配量，序列号商品按实际号码接续，不能用一个汇总数量替代指定资料。付款条件也可能限制出库量或金额，先付未满足时不应为赶发货改结算方式。页面可用量只是核对入口，提交时仍要以原状态和最终业务校验为准。

图4：历史主仓5L件规格待出2、已出0、在出0、本次2与库存100。

图5：原单位、已出、在出和未出退款共同影响剩余参考，本次另核库存。

4. 查看本批出库审核与库存结果，再进入发货

确认本次数量后，出库先保存并提交，审核和发货继续按原流程接续。商家联营子单有自动审核出库的处理分支，仍应查看本批出库单及其实际状态；保存成功不代审核一定成功，审核完成也不代快递已经发出。普通页面可能仍显示“发货”按钮，说明后续配送资料与发货动作要另处理。

库存核原仓、规格和单位比例对应的数量。原出库审核有企业库存设置与库存不足条件检查，批次、规格库存和库存流水分别接续；不保证所有企业都禁止负库存，也不承诺每个流程都有同样的人工审核步骤。历史画面本次出库两件后系统库存九十八件，只是当时从一百到九十八的原结果，不能当成今天库存或当前批次成本。

同一原出库单可在PC明细和手机管理记录中查找，原号码须从实际显示号码的记录核。历史PC“出库记录一条”局部没有出库单号，手机“出库情况”才显示对应原出库单号；不能用未显示的字段证明同一单。审核失败或响应未知时先查是否已有本批记录与库存变化，再处理缺失段，不重新出整张订单的全部数量。

图6：历史出库记录本次2、系统库存98，局部未显示出库单号。

图7：保存提交、审核库存与本批发货分开核，不只凭成功提示。

5. 物流按原批次填写，发货时间和修改范围分别核

发货时先选本批原出库记录，核发货时间、配送方式、物流公司、单号、备注及允许附件。普通发货页面要求发货时间，而物流公司和单号并非所有字段都设为必填；没有真实单号时不能伪填号码来让步骤变蓝。时间应说明本批原发出安排，不把订单创建或出库审核时间直接代成运输实际时间。

“查看物流”依赖原记录的物流单号，能打开查询入口也不证明货已送达。不同批次的物流和配送说明分别维护，不能把一条物流覆盖整张主单的其它商家或未发批次。历史PC步骤只显示发货推进而收货尚未推进，该局部没有物流号码；历史客户手机画面才显示原号码及查看物流入口，两种画面各证明自己的范围。

需更正资料时看原出库状态和“修改物流”入口。完成或作废后的页面不承诺仍允许修改，旧页面携带的信息与当前记录不同也可能得到刷新提示。修改时空字段可能清除原物流、备注或附件，先核原值再决定应改哪一项。保存后核这批原记录和客户侧相应显示，不由商家一端修改提示推所有平台关联记录都已同步更新。

图8：历史PC步骤发货已推进而收货未推进，此局部没有物流号码。

图9：本批发货时间、物流与修改范围分别核，空值可能清除原值。

6. 平台虚拟仓按原关系承接，不做实体重复出库

商家自行发货时，平台按原主子单关系承接该商家本批原出库，使用商家在平台对应的虚拟仓及主单客户收货资料。原商家规格对应平台主单明细，数量、原单位比例和本次物流沿已有关系处理；不按商品名称相似就把另一规格或另一商家的出库合并进来。

虚拟仓用于记录平台主单这一段履约，不表示这批实物又进入平台实体仓再发一次。原商家出库与平台出库有对应关系，核两端时保各自原号码和关联明细，不能因平台还显示待发就从平台实体仓重复出相同商家商品。混合主单里的平台自有商品另沿自己的明细出库，不能把整个主单一概当商家代发。

平台发货入口对商家自行发货原明细有保护，子单创建尚未完成也可能提示稍后处理；看到拦截应回原关系定位，不复制一张新订单绕过。平台代发是商家先向平台仓交货、平台再向客户发货的另一条链，与本篇虚拟出库不同。当前跨端库存、原批次状态和自动接续结果需同数据核，不承诺一次商家发货就完成主单全部商品履约。

图10：商家原出库承接平台虚拟出库关联，不做实体重复发货。

7. 对齐两端原出库与收货，系统完成不代实收或到账

两端核同一批时，先认原子单、平台主单、关联出库、规格数量和物流，再比较各自时间与状态。历史手机管理“出库情况”显示原出库单已完成、主仓库与完成时间；客户“发货情况”显示相同原出库单号、一种商品两件、发货时间与物流号码。它们定位当时对应画面，完成时间和发货时间不是同一取数节点，不由时间先后推重复单或少发。

客户收到本批实物后，核原规格、数量、包装和异常再按自己的原订单收货入口处理。相关原记录处于允许收货状态时，收货可以接续另一端关联记录；不能对无关联或状态不符的记录强制写完成。少货、错规格或破损先保本批事实，未发剩余量继续沿原单处理，不以整单完成掩盖分批缺货。

企业流程可省略人工收货并自动推进系统状态，因此“已完成”也不总表示客户做过同样的收货点击。系统状态、现场实物与客户确认分别核，原子单已完成还可能有待收款或结算未完成。当前手机管理与客户商城的岗位、原记录对应和同数据显示尚需核验，不用历史完成画面代本次客户实际收到或资金到账。

图11：历史手机管理原出库单CK-20260915-0001已完成，1种2件与主仓。

图12：历史客户发货原CK单、1种2件、发货时间和QH-915-001物流。

图13：两端原记录、系统收货与客户实物分别核，不以完成代到账。

8. 出库或同步失败，沿原数量、资金与售后接续

出库被拦先看原单状态、有效仓库、本次原明细和允许量，再核库存、批次序列号及付款条件；发货被拦先认本批出库是否处于允许发货状态。原信息变化出现刷新提示时，回到原记录重核当前数量和已做结果，不能把所有失败都解释成同一种旧版本拒绝，也不能通过反复整单点击来补未查清的结果。

响应未知或平台状态不同，保原单号、本批数量、操作时间及脱敏反馈，分别查商家原出库、平台关联出库和客户侧原发货。已生成的记录继续沿原记录处理，尚缺的段落按实际允许入口接续。一次成功提示不保证所有关联更新都完成，重复请求保护也不等全部跨端业务永远不会重复，需先核已有结果。

货与款分开收尾：出库、物流发出、客户收货、子单收款和联营结算各有原记录。待收款金额不能当平台客户未收到货，原收货也不代银行已到账。未出退款与已发退货按原单和本批数量追溯，不删主子关系或随意回改库存金额。当前部署完整授权、自动处理、跨端库存资金和真实渠道结果需逐段核，历史画面不代替当前同一原批次的库存、收货及资金结果。