很多人第一次看销售佣金模块，注意力都放在“提成比例填多少”。但企业真正会卡住的，往往是更基础的问题：方案周期怎么切、每段目标怎么补、目标曲线怎么算、报表又怎么查得动。
这篇文章主要参考了以下企业版源码入口：
enterprise/sale_commission/model/commission_plan.pyenterprise/sale_commission/model/commission_achievement.py
一、这篇功能真正解决什么问题
sale_commission 真正解决的是佣金方案从“制度描述”变成“可计算对象”。如果系统里只有总目标和总提成，企业就很难按月复盘、按季度归档，也没法解释目标完成率落在不同区间时对应多少奖金。
二、核心链路怎么走
1. 方案先被切成 period target
commission_plan._compute_targets() 会根据 periodicity 把 date_from/date_to 切成月、季或年区间，并自动补齐缺失的 target 记录。也就是说，方案录入时写的是一个大区间，执行时系统需要的是很多个有边界的小区间。
2. 提成曲线不是死值，而是可插值的目标表
target_commission_ids 上既有 target_rate 也有 amount。如果管理员没有刚好在 100% 目标处填出标准佣金，_inverse_target_commission_ids() 还会尝试按现有曲线插值/外推，推回 commission_amount。这个设计很企业化：制度可以按档位描述，但系统必须能给出连续计算结果。
3. 性能问题在模型初始化时就被正视
init() 里直接为 sale_order、account_move 等表建立面向佣金报表的索引，分别覆盖团队、开票人、日期等条件。官方显然知道，佣金不是算完就结束，后面还会反复查、按团队汇总、按期间复盘。
三、新手最容易踩的坑
- 以为佣金方案就是一张比例配置表，没有 period target 概念。
- 以为提成曲线必须每个点都手填。其实系统支持按已有档位推回标准佣金额。
- 以为报表慢是数据库正常现象。官方连索引都预建好了，说明这个场景天然就是高频分析场景。
四、实战落地时最该盯的点
- 周期一旦确定，最好别中途频繁改，否则目标切段和历史归档解释都会变麻烦。
- 设计提成档位时至少给出关键折点，尤其是 0%、50%、100% 一类门槛，方便系统推导连续曲线。
- 若佣金报表仍然慢，先确认企业自定义有没有绕开官方索引字段，而不是直接怀疑模块本身。
五、结论
销售佣金方案真正难的，不是填一个奖金数字，而是把期间、目标、曲线和报表性能放进同一套引擎。sale_commission 的价值，恰恰就在这套“从制度到计算”的转译能力上。
DISCUSSION
评论区