在现代ERP系统中，调价功能是连接销售、库存、采购、财务等模块的关键能力。企业在不同渠道、不同区域，甚至细化到商品或SKU级别时，价格策略可能完全不同。因此，一个健壮、灵活、可扩展的调价系统，不仅需要满足复杂业务场景，还需具备良好的扩展性与性能表现。
本文将从以下几个方面详细探讨调价功能的系统设计：
功能目标与核心需求
数据模型设计
调价策略匹配机制
调价生效与冲突处理
变更管理与审计
架构与扩展性建议
一、功能目标与核心需求
ERP中的调价功能，核心目标如下：
多维度价格区分：支持按渠道（Channel）、区域（Region）、商品（SPU）或SKU设定价格；
价格优先级控制：支持价格冲突时按优先级匹配；
调价计划管理：支持生效时间、失效时间、预设价格变更；
价格查询效率高：支持大批量商品、实时读取；
操作审计留痕：支持价格历史查询、审批流程记录。
典型业务场景：
渠道区域商品层级示例说明B2B电商华东SKU某SKU在华东的B2B电商渠道价格为100元门店西南商品商品SPU在所有SKU统一定价120元分销全国SKU针对分销客户设置特殊促销价
二、数据模型设计
采用多维价格模型，每条价格记录带有完整的限定维度和有效期信息。
1. 基础表结构设计
CREATE TABLE price_policy (
id BIGINT PRIMARY KEY,
channel_code VARCHAR(64),
region_code VARCHAR(64),
product_id BIGINT, -- 商品ID
sku_id BIGINT, -- SKU ID（为空则表示为SPU级）
price DECIMAL(10,2),
currency VARCHAR(10),
priority INT DEFAULT 0, -- 优先级（值越大越优先）
effective_from DATETIME,
effective_to DATETIME,
status VARCHAR(20), -- draft/published/expired
created_by BIGINT,
created_at DATETIME,
updated_at DATETIME
);
说明：
channel_code：代表渠道，例如“B2B”、“门店”、“分销”；
region_code：代表销售区域，可按行政区划设计；
product_id 与 sku_id：支持 SPU 或 SKU 定价；
priority：解决多个规则重叠冲突的问题；
effective_from/to：支持调价的定时发布。
2. SKU继承机制
若 SKU 没有单独设置价格，可继承其所属商品的价格。通过逻辑层处理继承关系，数据库不冗余记录。
三、调价策略匹配机制
查询价格时需考虑维度优先级，例如：
精准匹配顺序：
SKU + 渠道 + 区域
→ SKU + 渠道
→ SKU + 区域
→ SKU
→ SPU + 渠道 + 区域
→ SPU + 渠道
→ SPU + 区域
→ SPU
实现方式：
构造优先级评分模型；
查询时动态生成价格匹配候选；
基于优先级排序后返回最优价。
四、调价生效与冲突处理
1. 时间范围冲突检测
当用户创建新的价格策略时，应校验是否存在时间范围冲突。例如：
SELECT * FROM price_policy
WHERE sku_id = ? AND channel_code = ? AND region_code = ?
AND effective_to >= ? AND effective_from <= ?;
若存在冲突，应提示用户修改时间或合并策略。
2. 支持预设调价计划
可实现“调价任务”模块，供业务人员提前配置价格计划，到时间自动生效：
CREATE TABLE price_plan (
id BIGINT PRIMARY KEY,
plan_name VARCHAR(128),
apply_time DATETIME,
status VARCHAR(20), -- pending/applied/failed
created_by BIGINT,
...
);
调价任务可由调度服务自动执行并写入 price_policy。
五、变更管理与审计机制
调价涉及核心利益，必须有完整的审计与审批流程：
版本控制：每次变动保留旧版本，支持回滚；
审批流程：草稿状态下提交审批，通过后变更生效；
审计日志：记录创建人、审批人、操作时间等信息。
可扩展 price_policy_log 表追踪历史：
CREATE TABLE price_policy_log (
id BIGINT,
policy_id BIGINT,
action VARCHAR(20), -- create/update/delete
snapshot JSON, -- 变更快照
operator_id BIGINT,
operated_at DATETIME
);
六、架构与扩展性建议
1. 读写分离策略
写操作频率较低，可放入主库；
价格查询频繁，应将价格策略预处理为价格快照表，供销售系统快速查询。
2. 分布式缓存（如 Redis）
可用 SKU + 渠道 + 区域作为 key；
将当前有效期内的最终价格缓存，加快访问速度；
支持定时刷新或价格变动触发缓存更新。
3. 多租户支持
若为SaaS ERP，价格策略应具备租户隔离字段 tenant_id，防止数据混乱。
4. API 分层
后台价格管理接口；
前台价格获取接口（支持批量获取 + 缓存）；
价格模拟接口（用于模拟特定场景的价格生成，如促销引擎接入）。
总结
调价系统的设计是ERP中典型的多维规则匹配与高性能读写场景。合理的建模、清晰的继承逻辑、灵活的调价策略以及审计机制共同构成了一个强健的调价子系统。
未来，调价系统还可进一步接入AI定价引擎、历史销售数据分析、动态市场响应等模块，增强智能化与自适应能力。