企业官网建设流程全解析

同一件商品，普通经销商和区域经销商看到的价格不同；同一笔订单，提交时符合起订要求，审核时活动却已经结束；财务查到款项到账，订单页面仍然显示待付款。

这些问题出现在订货规则、订单状态和系统之间的数据传递过程中。把商品列表和下单按钮做出来，只完成了订货系统的一部分。

本文从渠道订货场景出发，讨论需求评审中应当明确的数据关系与异常处理。字段、数字和流程均为设计示例，需要按实际业务调整。

一、把“谁能买、怎么买、买多少”分别建模

假设一个订货平台面向多个经销商，需求中出现了“不同客户采用不同政策”。

继续拆解后，这句话可能包含：

这些约束不宜全部塞进一个客户等级字段。客户等级可以作为规则条件，但规则还可能受区域、合同、商品和时间影响。

例如，某商品的起订量为 8 件，订货步长为 4 件。若约定步长从起订量开始计算，则可接受 8、12、16 件，10 件不符合规则。

这里必须明确“按整箱倍数订货”与“达到起订量后按步长增加”是否相同。两种描述可能产生不同的合法数量集合。

二、价格规则要有明确的命中结果

可以先设计一个简单、可解释的匹配顺序：

客户专属价格 → 客户所属价格组 → 默认订货价格

这只是示例。实际采用何种优先级，应当在需求评审中确定。

更重要的是处理冲突：同一客户、同一商品、同一时间，如果匹配到两条同优先级规则，系统应拒绝冲突配置，或采用事先明确的选择规则。不能依赖数据库恰好先返回哪条记录。

订货确认页面可以显示当前单价和适用条件；后台则保存更完整的计算依据：

• 命中的规则标识与版本；
• 计算时间；
• 商品数量与计价单位；
• 原单价、折扣及成交单价；
• 人工调整原因与审核记录。

这样，后来修改价目表时，历史订单仍然可以解释。

提交价和审核价是否一致，需要提前约定

一种方案是在提交时固定价格，审核只检查是否允许成交。另一种方案是在审核时重新计价，金额变化后要求客户再次确认。

两种方案都涉及不同的业务承诺。验收时，应测试订单提交后活动到期、客户等级变化和商品调价三种情况，观察实际行为是否符合约定。

三、订单不要用一个状态表达所有进度

“已处理”很难回答订单到底完成了哪一步。

可以分别记录：

例如，一笔订购 12 件商品的订单，先发出 8 件，剩余 4 件等待补货。此时它可能同时处于“审核通过、足额收款、部分发货”。

页面可以组合展示这些状态，底层仍应保留独立事实。

状态拆开后，还需要约束合法操作。例如，订单能否取消，要根据已收款、已发货以及正在执行的仓储任务判断；已发货部分不能通过把订单改回“未发货”来消除。

四、重复提交与重复回传要分别验证

经销商点击提交后页面没有反应，再点一次，是常见操作。

可以为一次下单请求分配请求标识。相同客户携带同一标识重试时，返回原处理结果，避免生成第二张订单；若同一标识对应的商品或数量已经改变，则应提示冲突。

仓储回传也有类似问题。一张发货单已经同步成功，但确认响应丢失，仓储系统再次发送同一事件。

接收端需要识别同一事件是否处理过。业务变化和去重记录应可靠关联；仅在处理前查询一次“有没有收到”，仍可能在并发下重复执行。

验收时至少模拟：

1. 同一个下单请求连续提交两次；
2. 同一发货事件重复回传；
3. 发货回传超时后再次发送；
4. 同一订单的第二批发货正常到达。

第四项用于检查去重是否过度：两次合法分批发货，不能因为订单编号相同就只接收一次。

五、对账要保留单据之间的关联

一笔收款可能对应多张订单，一张订单也可能分多次收款。如果只在订单表中保存一个到账金额，后续解释差异会很困难。

可以分别保留收款记录与分配记录：

收款记录：外部流水、付款客户、币种、金额、到账时间 分配记录：收款记录标识、订单标识、本次分配金额

在这一示例中，应校验一笔收款的累计分配金额不超过可分配余额。同币种金额才能直接相加；涉及币种转换时需要另行定义汇率和差额处理。

退款、撤销分配和人工更正应产生可追溯记录，不宜直接覆盖原值。业务页面也应区分客户提交的付款凭证与实际确认到账结果。

六、订货数据不能直接代表终端消费

订货系统可以统计客户订了多少、发了多少、收了多少款。

但经销商采购了 100 件商品，不代表消费者已经买走 100 件。没有终端销售数据时，报表不应据此计算消费者客单价或复购率。

可以先建立边界清楚的指标：

每个指标还需明确取消、退货和跨期调整的处理方式。

实施前，可以准备一张包含差异价格、部分收款、分批发货和取消剩余数量的测试订单。让前台、仓储和财务分别处理，再检查各方记录能否对应。通过这条具体链路，比逐项确认“支持下单、支付、发货”更容易发现设计缺口。