批发定价的两个硬需求
鲜花批发和零售的差别，首先体现在价格上：
- 同一种花材，买 1 扎和买 100 扎不是一个价。阶梯价是 B 端采购的基本预期；
- 平台不能替供应商定价。平台的收入来自加价与佣金，供应商自己的底价必须保持独立、可核对。
这两条同时成立，意味着数据库里必须存在两套价格：供应商原价（结算基数）与买家成交价（收款依据），并且两者之间的差额要能逐单追溯。
阶梯价：挂在 SKU 上，按数量区间
阶梯价不挂在商品（SPU）上，而是挂在 SKU 上——同一种玫瑰，A 级与 B 级、20cm 与 40cm 的成本完全不同，档位必须逐 SKU 设置。
每个档位是一条记录：SKU + 数量下限 + 数量上限 + 单价。下单时按采购数量匹配命中的区间，命中失败则回落到 SKU 基础价。命中结果会以业务号形式快照到订单明细上，便于事后核对"当时为什么是这个价"。
关键口径：阶梯价只影响供应商原价，不影响加价。加价是在原价之上叠加的平台行为。
加价规则：三层优先级，命中即止
平台加价不写在商品上，而是独立成规则表，支持三种维度：
| 优先级 | 维度 | 典型用法 |
|---|---|---|
| 1 | 指定商品 | 爆款单品做定向加价 |
| 2 | 商品分类 | 玫瑰类统一加 2 元/扎 |
| 3 | 价格区间 | 低客单价多加点、高客单价少加点 |
匹配顺序是"商品 > 分类 > 价格区间"，命中第一条即停止，不再叠加。这个设计避免了"规则叠加导致价格失控"——运营改一条规则，不会连带影响其它维度。
加价额按件/扎计算，与阶梯价的数量区间正交：买 100 扎时，阶梯价降了，加价仍是每扎固定值，平台收益可预测。
订单明细要存四个价格字段
这是整套定价设计里最容易被简化、也最容易出事故的地方。订单明细必须同时落下：
origin_price：供应商原价（命中阶梯价后的价格），供应商应付结算的基数；markup_amount：本单命中的加价额/件；price：买家成交单价 = 原价 + 加价；tier_biz_no/markup_rule_biz_no：命中的档位与规则业务号（未命中则为空）。
只存成交价是不够的：一旦供应商调价或运营改加价规则，没有快照就无法解释历史订单的金额构成，结算对账会直接卡死。
同理，应付结算单的金额必须由原价与加价分别推导，而不是拿成交价倒算。结算公式在系统里是固定的：结算金额 = 商品原价合计 + 运费 − 平台佣金 − 退款冲减。
为什么不做"平台统一售价"
有一种更简单的做法：平台把所有商品改成自己定价，供应商只供货。我们没这么做，原因有三：
- 供应商参与定价才有动力维护价格与库存，平台不需要几千个 SKU 逐个盯；
- 阶梯价与市场行情强相关，供应商比平台更清楚当天的花价；
- 一旦平台定价，价格调整的责任就转移到平台，运营成本会失控。
平台的收益应该来自规则（加价与佣金），而不是来自定价权。把这两件事分开，系统才能同时服务几百家供应商。
落地时踩过的三个坑
- 档位区间必须连续且不重叠。两个档位同时命中会导致价格不确定，保存时就要校验；
- 加价规则要能停用而不是删除。历史订单引用了规则业务号，物理删除会让快照变成孤儿；
- 价格变更不影响在途订单。下单那一刻快照即锁定，后续调价只对新的订单生效。
定价是 B2B2C 平台最容易引起纠纷的环节。把"谁定价、谁加价、谁结算"三件事在数据层分清楚，后面的争议就只剩沟通问题。