订货小程序的客户等级价、起订量和限价规则怎么设计？

订货小程序刚上线时，价格规则通常不复杂：普通客户一个价，经销商一个价，每箱至少订十件，再设一条“不能低于成本”的提醒。等到客户等级多了、同一商品按箱和按件销售、临时促销与合同价同时生效，问题就不再是少配了一条规则，而是系统不知道该听谁的。

最常见的结果是，商品列表显示 100 元，进入购物车变成 92 元；销售给客户报过 88 元，客户下单时却恢复成等级价；后台允许按 12 件起订，仓库实际只能整箱发 24 件。每个数字单独看都能解释，放进同一张订单就对不上。

红数科技在梳理订货小程序时，会先把规则还原成一笔真实交易：谁在买，买哪个 SKU，用什么单位买，买多少，哪一天成交，价格由哪份协议或政策产生，低到什么程度需要拦截或审批。把这几个问题答清，后台字段才有依据。

客户等级价不是给客户贴个标签就结束

客户等级可以叫普通经销商、核心经销商、直营门店、项目客户，也可以沿用企业现有的 A、B、C 级。名称并不重要，重要的是等级由谁认定、何时生效，以及它到底对应哪些商品和价格。

等级名称只是入口。真正能用来算价的规则，还得带上这些条件：

同一个等级内部也可能存在例外。某个客户拿到年度协议价，某批临期商品正在做清仓，某个项目又有一次性报价。与其不断增加“钻石级”“战略级”来容纳例外，不如把等级价作为长期价盘，把指定客户价、临时报价和活动价分别保存，并给每条规则标明来源、有效期和审批记录。

价格优先级必须写成一张业务人员能看懂的表。一个常见但不是唯一的顺序是：已批准的订单报价或合同专价，优先于客户等级价；等级价再优先于基础批发价。活动价是否压过等级价，要看企业原本的销售政策，不能由系统默认取最低价。阶梯价更适合作为某一套价盘里的数量规则，而不是游离在所有价格之外。

这里还有一个容易漏掉的时间问题。客户今天升级，昨天已经提交、尚未审核的订单是否重新计价？通常更稳妥的做法，是在订单提交时保存价格快照；确需重算，由有权限的人主动操作，并留下旧价、新价和原因。否则一个客户等级变化，就可能让已经确认的订单、退款和对账一起发生变化。

起订量要拆开看，不要都叫 MOQ

“这款商品 10 件起订”听起来很清楚，放进系统还差不少信息。10 件是单个 SKU，还是同系列颜色可以混加？达到 10 件以后可以订 11 件，还是必须按 5 件一组增加？商品按箱报价时，这里的“件”指单品还是整箱？

订货业务里常见的数量限制可以拆成四类：

• ‎单品最低起订量：某个 SKU 至少买多少；
• ‎下单倍数：达到起订量以后，每次按多少递增，例如 12 件起订、6 件递增；
• ‎混批门槛：同一品牌或系列允许多个 SKU 合并达到数量或金额；
• ‎整单门槛：订单总数量或总金额达到多少才允许提交。

四类规则可以同时存在，但页面要把客户真正需要完成的条件说清。假设一箱 24 瓶，2 箱起订，整箱发货，后台最好保存“销售单位=箱、换算关系=1 箱 24 瓶、最低数量=2 箱、递增倍数=1 箱”，不要只在商品详情里写“48 瓶起订”。仓库按箱出库，客户按瓶理解，后面出现拆零和运费争议几乎是必然的。

数量校验也不能只做在商品页。快速下单、购物车改数量、Excel 导入、销售代客下单、接口订单和再次购买，都应调用同一套规则。客户已经加购的商品后来调整了起订量，结算时可以提示补足或移除，但不能悄悄替他增加数量。

“限价”先说清限制的是哪一个价格

业务会上听到的“限价”，可能指三件完全不同的事。

第一种是内部成交底价或最高折扣。它用来防止销售报价、人工改价或优惠叠加后低于企业允许的范围。系统可以直接禁止提交，也可以转入审批。底价不一定等于财务成本，企业还可能把税费、配送、平台费用和最低毛利算进去，所以计算口径需要由财务和业务共同确认。

第二种是订单额度限制，例如单个客户每日最多购买多少、账期客户还能占用多少信用额度。这类规则限制的是数量或风险敞口，不应塞进价格表。它需要自己的周期、已占用额度、订单取消后的释放方式和超额审批流程。

第三种是经销商对外转售价限制。这已经不是小程序里的内部成交保护。现行《中华人民共和国反垄断法》第十八条涉及经营者与交易相对人固定向第三人转售商品的价格、限定最低转售价等情形。企业如果准备通过系统监控或约束经销商对外售价，应先让法务结合具体协议、市场地位和执行方式审查，不能把一条“最低零售价”配置当成普通技术需求。

落到底价这条规则，财务和业务要把四件事说定：按含税价还是未税价比较；返利、赠品和运费是否折算；低于底价是拦截还是审批；谁能查看底价。客户前台通常只需要看到自己的成交条件，不应看到企业成本、底价和审批阈值。

冲突怎么处理，拿一张订单算一遍

可以用一个纯演示的数字检查规则是否讲得通。某 SKU 基础批发价 100 元，B 级客户价 92 元，购买 100 件以上的 B 级阶梯价 88 元；该客户另有一份有效合同专价 86 元，企业内部成交底价为 82 元。

客户订 120 件时，如果规则约定合同专价优先，成交价就是 86 元，而不是把 92 元、88 元和 86 元再叠加一次折扣。若销售改到 81 元，系统应根据既定政策阻止提交或发起审批；即使审批通过，也要在订单中保留改价人、审批人、原规则价、最终价和原因。

这个例子真正要验证的不是 86 元是否合理，而是每一步都有唯一答案。建议把优先级写成类似下面的决策表：

后台需要保存规则，也要保存当时为什么这样算

只保存订单最终单价，过几个月很难解释当时为什么是这个数。订单明细除了 SKU、数量、单位和成交价，最好同时保存命中的价盘、客户等级快照、数量区间、税率口径、规则版本和人工调整记录。退款沿用原订单成交口径，不能拿退款当天的新价格反算。

规则本身也要有草稿、待审核、生效、失效状态。批量改价先预览受影响的客户和商品，再由有权限的人发布；生效后保留旧版本，不直接覆盖历史。小程序、业务后台、ERP 和销售报价工具如果都会算价，还要指定哪一套系统是最终价格源，其他系统通过同一接口取数。

国家市场监督管理总局《明码标价和禁止价格欺诈规定》要求标价真实准确、货签对位，价格发生变化时及时调整；通过网络等方式销售商品，也应以文字、图像等方式明码标价。对订货小程序来说，客户登录后看到的等级价、商品页计价单位、购物车成交价和结算页附加费用应当互相一致。需要另计运费、税费或定制费，就在客户提交前把条件说清，不要等订单生成后再补。

上线前别只测正常订单

正式开放前，可以拿不同等级客户、指定合同客户、未登录客户、刚升级客户各跑一遍；商品则覆盖单品起订、整箱倍数、混批、阶梯价、活动价和人工改价。除了能下单，还要检查这些情况：

• 规则在零点生效或失效时，购物车里的旧商品怎样处理；
• 客户等级被误改后恢复，历史订单是否保持原价；
• 部分退款、退货后重购，是否错误占用起订量或限购额度；
• Excel 导入和接口订单能否绕过前台校验；
• 缓存、断网重试和重复提交会不会拿到不同价格；
• 低价审批被拒绝、撤回或超时后，订单处于什么状态；
• 客服是否能根据订单记录解释价格，而不必回头找当时的聊天记录。

红数科技评审这类需求时，会让业务、财务、仓储和开发围绕同一批代表性订单一起确认。价格规则由业务定，成本与底价口径要经过财务，包装和发货倍数由仓储验证，系统负责把已经确认的边界稳定执行。四边都能用同一张订单说明“为什么是这个价、为什么必须订这么多、超出权限后由谁处理”，这套规则才到了可以开发的程度。

参考依据

以下资料核验于 2026 年 7 月 24 日。产品功能、法规和企业政策会继续变化，实际配置应以企业现行合同、业务制度和正式法律意见为准。

• 中国政府网：《明码标价和禁止价格欺诈规定》，国家市场监督管理总局令第 56 号，自 2022 年 7 月 1 日起施行。
• 国家法律法规数据库：《中华人民共和国反垄断法》（2022 年修正），重点参见第十八条。
• Odoo 19.0 官方文档：Pricelists，作为价目表、客户群组、最小数量和有效期等常见配置维度的实现参照。