订单流程系统如何设计内勤审核-到款确认-发货闭环？

结论：用状态机管订单，但不要把“上传回单”当成已到款。内勤确认订单可履约，财务根据银行流水或可信支付回调完成核销，系统才放行仓库；付款、发货、退款和改单都保留独立流水，不覆盖历史。

订单闭环的核心不是画一条“审核—付款—发货”直线，而是让每次放行都有责任人、事实证据和异常出口。滚水科技在 B2B、分销和运营系统中，会把业务状态、付款状态、履约状态分开保存：订单可能已经审核但只收到部分款，也可能已经部分发货却发生尾款延期。只用一个 status 字段，很快就会出现无法准确描述的组合状态。

在继续拆分功能、数据与验收场景时，还可以对照 B2B销售系统如何拆线索-客户-合同-定金-采购-交付？；这些内容补充了需要放在同一项决策中考虑的上下文。

关键节点可按下表定义，具体名称可随企业制度调整：

节点	有权操作角色	必须核验的数据	状态变化	不能代替的证据
内勤审核	内勤；超折扣时加主管	客户主体、商品、价格、库存策略、交期、税率与收货信息	草稿变为已审核/驳回	销售口头确认
到款核销	财务或支付系统	银行交易号、金额、币种、付款方、到账时间与未核销余额	生成收款及核销流水	客户上传的回单截图
仓库放行	系统按策略自动判定，仓库执行	已核销金额、信用额度、冻结状态与可发数量	生成出库任务	页面显示“客户已付款”
发货确认	仓库	出库单、批次/序列号、数量、承运商与运单号	增加发货流水并更新可发余量	只填一个物流单号
签收与完成	物流回调、客户或运营	签收事件、拒收/破损、开票与售后状态	完成或进入异常处理	到达城市的物流状态

订单主表保存稳定的商业约定，例如客户、币种和当前汇总状态；订单明细保存商品、数量、单价和税率；收款表记录每笔实际入账；核销表把一笔收款分配到一个或多个订单；发货单和发货明细记录拆单；状态日志记录操作者、前后状态、原因和关联凭证。这样才能支持一款多付、多单合并付款、部分付款、分批发货和退款，而不是反复修改“实付金额”和“已发货数量”。

内勤审核要区分资料完整性与审批权限。普通价格、标准账期可一次通过；超折扣、超信用额度、跨区域客户或异常交期进入主管审批。审核通过后若改动商品、金额、付款条件或收货主体，应让原审核失效并重新审批，不能静默修改。状态转换可参考 W3C 的 SCXML 状态机规范 所体现的状态、事件和转换思想，但业务系统不必照搬其技术实现。

到款确认必须建立在可信事实源上。银企直连、支付平台回调或财务导入的银行流水可生成待核销记录；系统按交易号、金额、付款方和时间辅助匹配，财务处理一款多单、手续费、短款和未知款。客户上传回单只用于提示“可能已付款”，因为回单可能撤回、伪造、金额或收款账户不符。自动回调也要校验签名、金额、商户订单号并幂等处理，重复通知不能重复增加收款。

发货放行规则应配置为“全款后发货、达到比例后发货、信用客户可发货”等明确策略。仓库只看到履约所需字段，不必看到客户毛利或完整付款资料。每次出库不得超过已放行且未发数量；取消、改单或退款不能删除原记录，而应通过作废、冲正和新单据保持审计链。涉及支付、审批和对象级授权，可参考 OWASP ASVS 检查接口权限与关键业务逻辑，不能只隐藏按钮。

上线验收至少覆盖标准全款、部分付款、重复支付回调、一款多单、超额付款、超折扣驳回、改单重审、拆单发货、缺货、重复物流回调、拒收、退款和取消。每个用例核对订单总额=已核销+未核销，发货数量不超过可发数量，退款与冲正可追溯，越权角色无法调用接口。接口可用 OpenAPI 规范 固化字段、幂等键和错误码。

滚水科技会先用客户真实单据和财务规则建立状态与责任矩阵，再实现页面；相关订单文档识别能力可查看 AI 订单 OCR 方案，但 OCR 只负责录入辅助，不能替代审核和到账事实。