供应商直送撤销发货：客户收货前回退与重新交付｜云上订货系统
云上订货 · 更新于 2026-10-08
直送发货资料错误且客户尚未收货时，先核原供方分单及销售履约，再按允许条件撤销和重新交付。配送记录回退不代实物追回，收货与资金各核原结果。
1 供方从原直送采购单核待收货入口
这项操作由供应商在手机工作台对自己的直送采购单发起。先核登录供方、企业、采购编号、客户和原销售关联，再核履约方式为供应商直送客户，当前为待客户收货。普通采购的本次出货与总部入库流程不适用此撤销入口，不能只看到同一商品就沿另一条采购单操作。
打开原订单详情，在待客户收货状态查看撤销发货按钮。尚未接单或待发货的分单没有一笔已发记录需要撤销；客户已经收货则不能用这条路径回退。历史供方页面用于辨认采购编号、状态和直送方式，实际操作还须核当前原单的客户、商品及撤销入口，不以旧画面代替当前登录和权限确认。
总部应同步核原销售的发货情况及具体供方分单，确认撤销的是哪次错误配送资料。一个销售单可能有多个供方分单，只处理本采购对应的交付；其它供方已经送齐的商品不能一起回退。按钮可见但原状态、身份或明细变化仍可能拒绝，先重查后操作，不凭口头未收货替代原记录。
图1：历史供方采购编号、待客户收货与直送方式；撤销入口须在当前同一原单核对。
2 以当前状态明细核撤销条件与版本差别
撤销要求本采购仍是待客户收货，全部有效直送采购明细有完整销售关联，而且已发数量等于本行数量、已收数量为零。对应销售明细的已出和已发数量也必须足以扣回本次直送数量。存在已收、原明细变化或销售履约量不足时，原返回会拒绝，不能只检查采购单头还写着待收货。
多人同时处理时先刷新采购与销售原记录，再核每一行，不以先前截图的十斤代现在可回退的数量。手机撤销按原单当前状态、明细数量和实际变更条件检查；不能仅凭页面较旧就判断请求一定被拒绝，操作前应刷新同一原采购及销售记录。客户显式确认最终实收另有页面版本校验，两项动作的版本规则不能混用。
不要为了满足撤销条件手改已收数量、删除销售关系或临时关闭业务保护。若客户已经确认、总部已改原订单，先由对应岗位核发生的真实业务，选择允许的退货或差异处理方式。重新发货也会再核原销售可发量，撤销界面可打开并不保证后续整单重发必定通过。
图2：当前状态、数量条件与客户收货版本差别，不能据此判定全部旧版本都拒绝撤销。
3 填写原因并先协调实际货物安排
点击撤销发货后填写撤销原因，采购单和原因不能为空。说明本次错误，例如配送单号登记有误、核对后重新发货，并写清原配送的实际状态。历史原因弹窗示例只说明曾填写内容和确认入口，不能凭弹窗认定原单已经回到待发货；取消弹窗也不代表已提交撤销。
货物已经在路上时，供方先与总部和客户协调是否继续送达、是否需要追回或换资料。系统撤销的是发货登记，不会自动通知司机停驶，也不能证明实物已从门店取回。客户应知道正确验收安排，避免实际已经收到却按旧待收提示再次确认，或者系统回待发货后误认为这次供货已取消。
确认后看本次返回，成功才刷新原单核状态、明细和原因日志。拒绝或网络反馈不明时保首个消息及原编号，不连续点击确认来抵消错误。原因不是授权凭证，也不能代实际状态校验；不能写一个理由就让已收货单撤回，或通过新建同内容采购单覆盖旧交付。
图3：历史原因填写和确认按钮，弹窗不证明已撤销。
4 回查清除配送字段与原履约数量
允许撤销并成功后，直送分单回待发货，原发货时间、收货时间、配送方式、单号、附件、说明和本次发送接收身份等配送字段会清除。原客户收货地址和供方身份关系仍要保留核，不等于删除采购主单或取消商品需求。原发送请求记录也清除，后续重发沿这个原采购身份重新登记。
采购明细本次已发数量回零，对应销售明细扣回这张直送采购的已出、已发数量，再刷新销售原数量及履约状态。不会无条件把整张销售订单全部发货量清零，其它供方或其它履约仍按原结果保留。用原明细逐行比前后，单头状态改变与数量一致应同时成立；只看到一个待发货文字不足以确认所有关联都已正确回退。
该撤销路径没有直接把采购商品数量改为零、重算成交价或进行收付款退款。金额保持原值不是撤销失败，金额忽然变化也不能代回退验证。实际资金、发票和退货如已有记录，由各自原业务核对，不把配送回退当银行退款到账或整笔交易解除；系统记录与实物去向分别保依据。
图4：本路径配送字段和履约数量回退，与主单身份实物资金分开。
5 双方刷新同一分单确认待发货显示
供方刷新同一原采购编号，核状态从待客户收货回待发货，原配送信息不再继续显示为这次有效发货，整单发货入口按当前状态出现。历史撤销后画面显示同一采购编号及待发货；实际整单发货入口仍应在当前同一原单刷新后核对。加载失败时先重新加载，不能把空白详情当采购单被删除。
客户在手机商城刷新自己的原销售订单及供方分单，原分单可仍存在并显示待供应商发货，而不是承诺该记录从列表彻底消失。已撤销后不应继续按旧待确认收货按钮验收；当前配送单号、时间和说明清除后，旧页面残留要以重新查询结果为准。其它供方记录不跟着本分单消失。
总部同时回查原销售的对应已出已发数量与剩余履约状态，确认回退范围正好是本次直送。记录原采购、销售身份及本次原因，有异常时交负责岗位核，不能让客户通过重新登录另一个账号来消除原业务。供方、客户、总部各自读到一致的本单状态后，再决定是否已具备重新交付条件。
图5：历史同原采购编号返回待发货，重新整单发货的入口应在当前原单核对。
6 按正确资料重新整单发货核原结果
重发沿原采购单使用整单发货，核仍已接单且待发货、全部有效商品未收货，采购与销售明细关系正确且原销售可发数量足够。先核客户地址与实际配送安排、商品规格单位数量、配送方式、物流单号及说明；不能用普通采购本次出货或新建第二张采购单来补救这笔已撤销的直送。
配送方式与单号各最多一百个字符，说明最多五百个字符，附件最多四张且每张有有效地址。图片还在上传时先等原上传完成，重发弹窗没有自动把旧附件当新凭证的保证。确认后保返回，再查同原单待客户收货、新配送记录和关联销售已发数量，通知客户按这次资料验收，实际送货不因系统成功而当然已完成。
已发或已完成时，同一已保存的发货请求可回已有结果，另一请求可能报已发货。手机每次发货会形成新的请求标识，不能承诺任意失败后再点都会自动识别成同一次。撤销后旧请求记录已清，先查当前状态才重发；反馈超时先核原单有没有新配送，不重复登记两次来证明送货成功。
图6：历史供方整单发货配送资料，未证明这次已重发。
图6补：原单撤销重发和重复发货请求各看真实原结果。
7 客户确认实收后停止撤销重发路径
客户按新的交付记录进入原订单详情，逐供方分单核商品、单位和实际数量，允许调整时再确认最终实收。历史确认窗口十斤到九点六斤及收货后不可再改提示只是确认前画面，不能作为本次新交付已经成功。最终实收变化还涉及原销售与采购资金、票据及退货活动条件，不靠先撤销重发规避这些约束。
客户已经收货的采购分单，不再通过撤销发货修改最终数量。最终量相同的重复收货可回原完成结果，不同数量会拒绝；这与撤销重复提交不是同一保证。需要退货时沿原销售、原供方采购和实际退回商品接续，退款、抵扣、票据各核原记录，不把客户收货状态强行改回待收来恢复按钮。
供方与总部结束本次回退处理时核新发货、客户最终收货、原双单数量和日志，原错误原因与新的配送信息应能够对应。双方商品单价和订单金额各有口径，不要求销售价与采购价相等。重新收货完成仍不代资金收付或银行到账；客服说明交付经过时，须同时核对原单、实际记录和交付过程，不能仅凭最后一条成功结果下结论。
图7：历史客户最终实收确认前提示，不代本次收货成功。
8 失败超时重复提交按首个原结果排查
出现无权操作或登录供方失效，先核实际账号、企业和原供方采购归属；本链只允许自己的有效直送非作废单，不能改商品资料来获得权限。尚未发货、已收货或已被他人撤销时，先读当前状态，重复撤销通常会因不再待客户收货拒绝，不承诺每次重复都返回同一句成功。
存在已收货或明细变化时，逐行核原采购已发、已收和销售可扣回数量；原销售履约变化提示要回对应销售关系，不能只重试采购侧。错误返回不证明所有步骤已经完整回退，查看原状态、配送字段、采购销售数量及操作日志是否一致；不一致时把首个失败与前后结果交总部核，不直接再发或删明细掩盖。
超时没有明确反馈时，用同一原编号查是否已有撤销原因、待发货或新的交付，不从空白页面推断没保存。必要记录包括操作角色、原单、原状态、首次提示、回查时间及实际货物安排，避免携带无关敏感信息。只有原结果明确且适用条件重新满足，才继续下一步；同页面一次点击不代完整交付与资金闭环通过。
图8：首个失败与原状态明细配送资料分别核，不能用新单抵消旧差异。
下一步学习
- 供应商直送指南：分单、供应商交付与客户收货｜云上订货系统
- 供应商直送收货：最终数量调整与订单金额核对｜云上订货系统