同一件商品普通经销商和区域经销商看到的价格不同同一笔订单提交时符合起订要求审核时活动却已经结束财务查到款项到账订单页面仍然显示待付款。这些问题出现在订货规则、订单状态和系统之间的数据传递过程中。把商品列表和下单按钮做出来只完成了订货系统的一部分。本文从渠道订货场景出发讨论需求评审中应当明确的数据关系与异常处理。字段、数字和流程均为设计示例需要按实际业务调整。一、把“谁能买、怎么买、买多少”分别建模假设一个订货平台面向多个经销商需求中出现了“不同客户采用不同政策”。继续拆解后这句话可能包含问题对应规则是否允许订某个系列商品可见与可订范围下单采用什么价格客户价、价格组、生效时间最少买多少最小订货量数量如何递增包装倍数或订货步长一次最多买多少配额或单次上限这些约束不宜全部塞进一个客户等级字段。客户等级可以作为规则条件但规则还可能受区域、合同、商品和时间影响。例如某商品的起订量为 8 件订货步长为 4 件。若约定步长从起订量开始计算则可接受 8、12、16 件10 件不符合规则。这里必须明确“按整箱倍数订货”与“达到起订量后按步长增加”是否相同。两种描述可能产生不同的合法数量集合。二、价格规则要有明确的命中结果可以先设计一个简单、可解释的匹配顺序客户专属价格 → 客户所属价格组 → 默认订货价格这只是示例。实际采用何种优先级应当在需求评审中确定。更重要的是处理冲突同一客户、同一商品、同一时间如果匹配到两条同优先级规则系统应拒绝冲突配置或采用事先明确的选择规则。不能依赖数据库恰好先返回哪条记录。订货确认页面可以显示当前单价和适用条件后台则保存更完整的计算依据命中的规则标识与版本计算时间商品数量与计价单位原单价、折扣及成交单价人工调整原因与审核记录。这样后来修改价目表时历史订单仍然可以解释。提交价和审核价是否一致需要提前约定一种方案是在提交时固定价格审核只检查是否允许成交。另一种方案是在审核时重新计价金额变化后要求客户再次确认。两种方案都涉及不同的业务承诺。验收时应测试订单提交后活动到期、客户等级变化和商品调价三种情况观察实际行为是否符合约定。三、订单不要用一个状态表达所有进度“已处理”很难回答订单到底完成了哪一步。可以分别记录状态维度示例审核待审核、通过、驳回收款未收款、部分收款、足额收款履约未发货、部分发货、全部发货售后无售后、处理中、处理完成例如一笔订购 12 件商品的订单先发出 8 件剩余 4 件等待补货。此时它可能同时处于“审核通过、足额收款、部分发货”。页面可以组合展示这些状态底层仍应保留独立事实。状态拆开后还需要约束合法操作。例如订单能否取消要根据已收款、已发货以及正在执行的仓储任务判断已发货部分不能通过把订单改回“未发货”来消除。四、重复提交与重复回传要分别验证经销商点击提交后页面没有反应再点一次是常见操作。可以为一次下单请求分配请求标识。相同客户携带同一标识重试时返回原处理结果避免生成第二张订单若同一标识对应的商品或数量已经改变则应提示冲突。仓储回传也有类似问题。一张发货单已经同步成功但确认响应丢失仓储系统再次发送同一事件。接收端需要识别同一事件是否处理过。业务变化和去重记录应可靠关联仅在处理前查询一次“有没有收到”仍可能在并发下重复执行。验收时至少模拟同一个下单请求连续提交两次同一发货事件重复回传发货回传超时后再次发送同一订单的第二批发货正常到达。第四项用于检查去重是否过度两次合法分批发货不能因为订单编号相同就只接收一次。五、对账要保留单据之间的关联一笔收款可能对应多张订单一张订单也可能分多次收款。如果只在订单表中保存一个到账金额后续解释差异会很困难。可以分别保留收款记录与分配记录收款记录外部流水、付款客户、币种、金额、到账时间 分配记录收款记录标识、订单标识、本次分配金额在这一示例中应校验一笔收款的累计分配金额不超过可分配余额。同币种金额才能直接相加涉及币种转换时需要另行定义汇率和差额处理。退款、撤销分配和人工更正应产生可追溯记录不宜直接覆盖原值。业务页面也应区分客户提交的付款凭证与实际确认到账结果。六、订货数据不能直接代表终端消费订货系统可以统计客户订了多少、发了多少、收了多少款。但经销商采购了 100 件商品不代表消费者已经买走 100 件。没有终端销售数据时报表不应据此计算消费者客单价或复购率。可以先建立边界清楚的指标指标示例定义审核通过订货量指定时间范围内审核通过的订单数量合计待发数量已确认需求中尚未完成发货的数量发货完成情况按约定交付周期比较应发与实发未分配收款已确认收款中尚未关联订单的余额每个指标还需明确取消、退货和跨期调整的处理方式。实施前可以准备一张包含差异价格、部分收款、分批发货和取消剩余数量的测试订单。让前台、仓储和财务分别处理再检查各方记录能否对应。通过这条具体链路比逐项确认“支持下单、支付、发货”更容易发现设计缺口。