订单下发 WMS 与状态回传

哪个订单状态适合下发仓库？

先确认企业的履约规则：订单提交后就下发，还是付款、授信审核或人工审核完成后才下发。不同触发点会影响取消、欠款和库存安排。接口设计必须服从已批准的业务条件，不能因为下发接口可调用，就让所有订单自动进入仓库。

下发前还应检查配送地址、规格对应、数量单位和仓库归属。若商品为虚拟服务、预售或其他不走仓库的业务，应明确排除。订单中的显示标题不宜作为物料匹配依据；应使用稳定的规格与物料关系。资料缺失时，订单应停留在可识别的待处理状态，而不是发送一份不完整请求后等待仓库猜测。

订单核心具有购物车、报价、提交、取消推进与恢复入口；消费者支付控制器单独提供支付结果读取与支付尝试。

源码提供商城订单用例基础，外部WMS的受理、分仓和履约契约需要按客户系统核对。报价和订单提交存在，不证明已经接入某个仓库厂商。实施清单应将已有业务入口、需要新增的适配层和仓库侧配合内容分开登记。

WMS返回成功究竟代表什么？

HTTP请求完成、请求结构通过校验、仓库生成任务、拣货完成和出库完成，是不同层次的结果。商城应知道自己当前收到的是哪一层确认。若把“已受理”直接显示为“已发货”，消费者会看到尚未发生的履约结果，也会影响售后判断。

约定受理回执时，需要返回能够查询该次任务的业务编号。接口超时后，商城可以凭原操作编号查询，不必重新造一个订单再次发送。仓库拒绝也应带可解释的业务原因，例如物料未对应、地址范围不适用或订单状态已变化；这些原因应进入指定岗位的处理清单。

状态表要考虑终止和中间状态。终止状态如取消完成，不应随意被一个晚到的受理通知覆盖；中间状态如正在拣货，则可能影响是否仍允许取消。把这些语义写在双边契约里，能够避免只有技术人员理解的内部状态码进入消费者界面。

一张订单拆成多个包裹后怎么关联？

订单编号、仓库任务编号、包裹编号和物流单号是不同对象。商城可以按业务需要展示多个包裹，但要说明每个包裹包含哪些订单行及数量。只保存一个“最后物流单号”，会丢失先发出的部分，也无法准确处理分批签收和部分退货。

若仓库将多个商城订单合并打包，回传中同样需要保留订单行归属。数量单位转换必须明确，比如库存物料单位和商城销售单位不同，应按确认规则转换并验证。不能由收货页面上的显示数量推算拆分关系，再据此调整订单状态。

拆分变化也需要修订信息。仓库重新包装、作废面单或改承运商时，商城应能区分“新增包裹”和“原包裹修订”，保留对消费者和客服有意义的当前结果。旧物流单号可能仍有事件到达，不能让它重新成为活动包裹。

取消与出库同时发生怎么办？

取消申请不等于取消成功。若仓库已出库，原取消可能需要转成售后流程；若正在拣货，仓库是否允许撤销也取决于实际业务规则。商城应先提出明确请求，再根据外部结果更新状态，不能在发送取消消息时就把所有库存和款项一并释放。

对竞态场景，准备“取消请求先到、出库通知后到”和相反顺序的联调用例。观察双方最终状态能否解释，是否有人负责处理冲突。外部系统若没有撤销能力，应提前告诉业务团队，不能在切换后通过手工改数据库假装撤销完成。

回调重复或晚到时，应结合任务编号、事件编号和修订判断。重复通知不能导致重复发货展示或重复触发财务动作。某个事件已经进入终止状态后，新通知是否可以改变它，应由状态转换规则决定，不能只按时间字符串比较。

哪些字段与状态应先形成工程证据？

这张表用于双方填写契约与验证位置，状态名称需映射实际接口，不是固定WMS通用字段。

协作阶段	商城要发出或保留什么	仓库要确认什么	验收中的异常场景
下发前准备	订单行、规格映射、配送资料、触发状态	仓库及物料可识别、请求范围有效	未对应规格、错误仓库、缺失资料
接收与受理	原业务编号、操作版本、查询依据	受理或拒绝、外部任务编号	重复请求、受理后回执丢失
履约推进	每个包裹与订单行的关联	拣货、出库及分批数量的真实含义	部分发货、面单作废、事件乱序
撤销与变更	申请原因、影响范围、原任务引用	允许撤销或明确不可撤销	出库与取消竞争、晚到受理通知
退货协作	售后编号、退货商品及数量	收货、质检和入库结果分别确认	退款完成但商品尚未入库

正式验收应让业务人员能够按一张脱敏订单追踪这些对象，不只查看接口监控上的成功率。报告中保留发送、外部查询、回调处理和商城展示的证据，并标注各自时间。若某个阶段只在模拟器中完成，需要明确记录，不能当成真实仓库执行。

退货与退款怎样避免互相替代？

退货入库与财务退款可能分属不同系统。消费者收到退款，并不证明仓库已经收到商品；仓库确认收货，也不证明支付渠道已退回资金。工程方案需要分别维护这两个结果，再按业务规则决定售后完成状态。

退货数量可能小于原包裹数量，且退回商品未必全部允许再次销售。质检或报损应由负责该业务的系统确认，商城不能根据退款金额反推可售库存。售后单应保留原订单行、包裹或出库引用，避免关联到同名但不同批次的商品。

仓库账和商城账怎样对齐？

按商城、外部任务、订单行与履约状态分组，分别列出待受理、受理未出库、已出库及已撤销的集合。用相同截止点查询两侧，避免将仓库刚完成的出库与商城较早快照直接比较。出现差异时先保留原回执和当前业务状态，再决定补查、补传还是人工修正。自动补齐也需要排除已经撤销的任务，不能因为商城查不到结果就再次安排发货。

联调后怎样把责任交给运营团队？

交接时列出未受理任务、长时间未推进任务和回调冲突的查询方式，明确谁可以重发、谁可以批准撤销、谁处理消费者展示差异。运行岗位不应为了恢复速度随意创建新的外部订单；原操作编号与证据链是后续对账的重要依据。

继续阅读系统集成专题，使用ERP与WMS需求模板补齐状态契约，并通过WMS对接服务确认双方实施与验收范围。已有物流账号设置可在物流工程文档查看，配置入口与履约联调分别核验。