物流已发出但订单仍待发：出库审核、发货动作与回写排查｜云上订货系统
云上订货 · 更新于 2026-10-08
先锁定原订单原出库与实际交运凭证
物流说已经发出而客户订单仍待发，先把实际交运和系统履约分开查。由业务人员从PC管理端订货单按原订单号查客户、商品规格、数量与单位，再从出库情况或发货记录查关联出库单。仓库提供该批实际交运时间、承运单位、物流单号和清单；不能只拿一个物流号就认定客户原订单全部已发，也不能以金额相同或客户同名认定关联正确。
订单号定位整单，出库单号定位某次仓库交付，物流单号定位承运记录。一个订单可以分批出库，一张出库单也可能合并多个订单；要逐张核出库清单的原订单归属和规格单位。跨仓发货保留原仓名称，不把另一仓已发记录移用到本仓未发数量。无承运轨迹时问清是否自提、企业配送或尚未提供运单资料，不直接判定没有交货。
历史PC行中出库单CK-20260913-0002关联订货单DH-20260912-0003，物流单状态为无。这一局部能帮助识别原编号关系，却没有本批商品数量、发货完成时间和客户实收结果；不能替它补造快递轨迹或用它证明整单已送达。当前查发货记录还要核时间范围，列表默认月度条件可能排除较早原单；先保存条件再扩大到实际交运日期。
找不到原关联时，把客户提供的原编号与PC查询条件交给有权限的岗位回查。列表无记录可能涉及客户范围、仓库、日期、关键字或权限，不能据此删除原订单重新下单。先区分查错对象、原出库未生成、原出库未确认以及发货已确认但客户展示不同，后面每一步都继续使用这一组原编号。
图1：历史PC发货行保留原CK与DH关联及无物流状态，不能证明本批数量、承运轨迹或本次发货成功。
出库审核发货确认和编辑物流逐步核
在原出库单详情核仓库、关联订单、商品行及单据阶段。待提交、待审核、待发货和待收货是不同处理位置；审核完成意味着该笔出库进入下一节点，并不代表承运已取货，也不代表发货确认已经保存。现场已交运但单据还待审核时，由负责岗位先核实际清单和审核遗漏，不能越过库存与原订单关联直接把客户状态改成已发。
原出库单处于待发货且当前岗位有权限时，PC详情有发货入口。普通发货弹窗核发货时间、物流公司、物流单号、备注及附件，发货时间是明确必填项；物流资料为空与业务发货未确认不是同一个问题。使用已有实际交运时间和单号，不为赶状态填一个新单号。提交后查看原单实际返回和发货记录，再回原订货单核累计已发数量，成功提示只是这一轮核验的起点。
已经发货后的修改物流用于维护原运输资料，它与发货确认是两个入口。把物流号补进已发记录，不等于重新增加一批发货数量；看到修改成功也不能跳过原订单数量核对。普通物流资料维护、电子面单生成、纸面打印和实际交运各自留证，打印次数不能替代发货结果，生成了运单号也不能证明所有规格均已交运。
企业流程可能去掉单独出库节点，由订货单的发货动作连带生成并确认出库。遇状态差异先核本企业原流程和既有出库记录，不套用另一企业的步骤，也不重推一张出库单试试看。分支转单、联营或特殊跟踪商品还有相应限制，出现拦截保存原提示与原清单，由业务负责人核范围，不能把普通订单的一次成功当所有类型都允许。
图2：审核、发货确认与编辑物流各自回原单，业务数量回写与运输资料维护分开核。
逐行核分批数量与整单状态先后
原订单状态要同时看有效订单数量、已出库数量、已发货数量和已收货数量。系统先判断还有没有未完成出库，再判断是否发完；因此已经交运一个批次而整单仍处于部分出库，并不一定是发货回写失败。必须回原规格行看剩余数量，不能只看最先发出的那张单。箱、瓶、公斤等不同单位按原行核换算，不把混合单位总数当整单重量比较。
以同一规格十二公斤、没有退款退货或数量修改的教学例子说明：原单只出四公斤且四公斤已经发出，仍有八公斤未出库，订单可以继续处在部分出库。原单十二公斤已经全部出库，但只发四公斤，余八公斤待发，属于部分发货。一张首批物流号有轨迹，两种情形都可能在客户商城待发分类中看到整单，不能因此再次确认首批发货。
全部十二公斤均有对应发货结果后，再核原订单是否进入待收货及每批实收。客户签收首批四公斤也不能把未发八公斤解释成已收；收货确认针对实际到货，不用于修饰主状态。原订单存在退款、退货、取消、改量或强制完成时，应保留有效原记录重新算履约口径，不继续机械套用十二减四，也不将商品金额退回当货物已经回仓。
同规格在原订单里有多个商品行或不同单位，核出库明细是否关联正确原行，是否有一批被错误归到另一张原单。出库数量、发货数量和原行关联不同步时，交接具体行和前后数值，不能只报总数少了几件。回写排查应从第一笔无法对应的原出库记录查起，不能直接在汇总数上加减来把状态凑到已发。
图3：十二公斤教学例子按出库四或十二、发货四或十二区分整单阶段，实际退款与调整另核。
客户手机商城分类回到原单详情比较
客户在下单时的供应商手机商城进入我的订单，先从全部找原订单，核当前客户、订单号和下单时间，再进入详情和发货记录。历史手机我的订单局部保留待付款、待发货、待收货与退货单入口，它只说明分类入口，不显示目标订单及本次状态变化；不能用它给当前客户答复已经发出。客户商城侧的核对优先使用手机入口，管理端继续从PC原业务查结果。
商城待发货分类涵盖待出库、部分出库、待发货及部分发货等管理阶段，客户详情的进度也会把尚未完成整单发货的情况显示为待发。管理端看到某一批已经发货，客户仍在待发分类找到整单，先核剩余规格数量；这可能是分类粒度差异，不必先要求重发或修改订单。待付款又属于款项维度，货物已发也不能推断付款确认已经完成。
客户打开原单的发货记录核批次出库号、本批清单和物流资料，管理人员用同一编号回查。页面可见发货入口或有记录，不代表全部商品均已发完；没有轨迹也不直接等于未发。确认收货前核覆盖哪几条实际待收记录，不把点击查看物流或关闭窗口当收货保存完成，更不能为让待发标签消失而提前点收货。
客户与管理端比较时保留各自查询时间，退出旧详情后重新打开原单或刷新列表，再看加载后的结果。不要把浏览器缓存的旧页面与刚保存的管理端结果直接判为异常。刷新后同一原单仍有矛盾，应交接手机分类、详情状态、可见发货记录及PC原数量，分清客户端展示差异与原业务回写遗漏，不能只凭一张标签截图定性。
图4：历史手机商城我的订单分类局部，不包含当前目标订单或发货完成结果。
失败和未知结果先回原单再处理
发货保存提示数据已被修改时，先刷新同一原出库单，核最新阶段、修改时间及是否由其他人员处理。原页面上的旧数据不能继续提交；若原单已经待收货，先查本次发货结果，不把重新点确定当刷新。提示当前单据不允许操作时，核原出库和关联订单是否已完成、已作废或不在允许阶段，记录原错误再由负责岗位判断。
点击后一直加载、网络中断或没有明确返回，要把结果标作待查，而不是立即当失败。回原出库看发货时间、对应清单和当前阶段，回订单看已发数量及操作日志，再与现场交运比对。防重复提交限制也不能替代原结果核验；未知结果下反复发货、重建出库或改物流号，可能把一次交运变成多次业务记录，后续更加难以定位。
电子面单方式把业务发货与面单资料生成分阶段处理，日志和消息出现时间也可能不同。提示面单相关错误时，分别查原出库发货、原物流关联与生成原错误，不以暂时没有通知判定完全没发货，也不承诺只要生成运单就自动修好订单。外部系统状态回传与本地订单数量是不同链路，需要各自保留调用时间和原结果，不能用外部承运轨迹替代本地原业务。
确认确有遗漏后，只补负责岗位认可的缺失步骤，并保留操作前后同一原单证据。实际已经交运但原单状态不允许补确认时，先移交具体编号、原清单、交运凭证和提示，不通过作废、重复出入库或盘点绕过。未确认原因前，不重复执行原出入库或上车操作；当前失败是否解决，须沿同一原单和实际结果核对。
图5：数据变更、阶段拦截、未知返回及面单错误分别回原结果，不能统一重发。
按原对象保存回验结论与下一责任岗位
完成核对后，应能逐项回答原订单还有哪些规格未出库、哪些已出库未发，哪张出库已经系统确认发货，以及哪批实际交给承运。已发数量增加后回同一原商品行看前后值，物流号与原批次绑定后再核实际交运凭证。只看到整单标签变化还不够，也不能把有物流号当全部数量闭合；每一项结论都要指向原单或具体批次。
原订单和原出库的时间字段各自保留。某批发货时间不一定等于整单首笔发货时间，补录旧交运时间也不等于今天实际出车；物流单查询条件要覆盖实际时间。期间新增了第二批发货、原数量调整或退款处理，保存前后时刻和有效记录，不要求后一次查询继续等于旧截图中的累计值，先解释期间变化再判断是否回写遗漏。
交接材料包含原订单号、全部相关出库号、原仓、规格单位、订单及出库已发未发数、物流单号与交运时间、当前两端状态、最后有效操作及原提示。业务员核客户答复与剩余交付，仓库核审核和本批清单，负责发货岗位核原保存结果；接口或展示差异由相关维护人员结合本次时间追查。资料脱敏后保存，不附账号密码或完整联系方式。
对客户应给出具体进展，例如首批四公斤已交运、余八公斤尚未出库，由原仓继续处理；不要笼统承诺刷新后一定变已发。只有原单数量、原批次发货与客户可见结果都核到，才说明这一业务问题已有结论。历史画面和规则示意不能证明当前发货已恢复；尚未确认的数量回写、权限和承运结果继续待核，结论沿同一原订单及每张出库记录给出。
图6：原订单、每张出库、实际物流及客户展示四层回验，交接首个不一致点和剩余数量。
下一步学习
继续核订单状态查询、仓库任务配送与电子面单原关联，围绕同一原订单接续。