Odoo 销售里毛利、折扣审批与销售团队到底怎么协作：margin、discount、sales team 的职责边界讲透

先说结论

很多公司希望 Odoo 销售能原生做到这样一条链：

• 报价员看到毛利太低
• 系统自动卡住订单
• 主管审批折扣
• 审批通过后归到正确销售团队
• 团队面板与开票目标自动反映

但如果你直接看官方源码，会发现标准能力其实分成三块，并没有天然拼成完整审批流：

• sale_margin 负责毛利可见性与成本/毛利计算
• sale 负责折扣字段、全局折扣向导、订单上的 team_id
• sales_team 负责团队成员、归属规则、团队统计和 dashboard

也就是说，标准 Odoo 更像是在提供：

看得见毛利、能打折、能归团队、能做分析

而不是直接提供：

低毛利自动审批工作流

这恰恰是实施里最容易误判的地方。

这篇文章主要参考哪些源码

核心参考文件包括：

• /home/ubuntu/odoo-temp/addons/sale_margin/models/sale_order_line.py
• /home/ubuntu/odoo-temp/addons/sale/wizard/res_config_settings.py
• /home/ubuntu/odoo-temp/addons/sale/wizard/sale_order_discount.py
• /home/ubuntu/odoo-temp/addons/sale/models/sale_order.py
• /home/ubuntu/odoo-temp/addons/sales_team/models/crm_team.py
• /home/ubuntu/odoo-temp/addons/sale/models/crm_team.py

最关键的源码信号有：

• sale_margin 给订单行增加 purchase_price、margin、margin_percent
• 折扣能力由 group_discount_per_so_line 控制，并且会联动 pricelist 功能
• sale.order.discount 向导支持行折扣、全局折扣、固定金额折扣
• sale.order.team_id 是标准字段，订单确认与报表会沿用团队归属
• crm.team 负责成员归属、默认团队选择、团队销售与开票指标

第一层：毛利在标准 Odoo 里首先是“可计算、可见”，不是“自动审批”

sale_margin 的核心非常直接：

• 计算 purchase_price
• 计算 margin
• 计算 margin_percent

它的算法也很清楚：

• 基于产品成本 standard_price
• 做 UoM 与币种换算
• 再与销售小计比较得到 margin

这说明标准模块首先回答的是：

• 这条销售行现在利润是多少
• 利润率大概是多少

但它并没有直接回答：

• 低于多少必须审批
• 审批由谁来做
• 审批前是否禁止确认

所以如果团队把 sale_margin 当成“毛利审批模块”，就会高估标准能力。

第二层：折扣在标准里是能力开关，不是审批引擎

sale/wizard/res_config_settings.py 里，group_discount_per_so_line 是折扣能力的入口。

这意味着标准 Odoo 先做的事情是：

• 决定用户是否能看到并使用订单行折扣

同时它还会触发：

• 开启折扣时联动 group_product_pricelist

这很合理，因为很多折扣展示都与 pricelist 规则、折扣显示方式紧密相关。

但你要注意，这里仍然只是：

• 有无折扣能力
• 折扣怎样显示与计算

并不是：

• 折扣超过 15% 自动发审批单
• 审批通过前锁死确认按钮

标准源码没有把这些审批动作直接接上。

第三层：全局折扣向导的本质，是生成折扣行，不是做审批状态机

sale.order.discount 向导支持三种折扣方式：

• 对所有订单行打折
• 全局折扣
• 固定金额折扣

尤其是全局折扣和固定金额折扣，它会：

• 找到或创建 discount product
• 根据税组合准备折扣基础行
• 在订单上生成新的折扣行

这条链的设计重点是：

• 如何让折扣在税、会计、订单金额上表现一致

而不是：

• 谁批准了这次折扣
• 审批何时通过
• 被驳回后怎么回到报价员

所以标准 Discount Wizard 更像“折扣落账工具”，不是“折扣审批工作台”。

第四层：销售团队负责归属、成员与指标，不负责审批责任流

crm.team 和 sales_team 的源码提供的是另一组能力：

• 默认团队选择 _get_default_team_id()
• team leader 与成员关系
• 单团队 / 多团队成员模式
• 团队订单数、已开票金额、月目标等 dashboard 指标

sale 还在 crm.team 上补了：

• sale_order_count
• invoiced
• invoiced_target

这说明销售团队在标准里主要承担的是：

• 订单归属
• 成员管理
• 绩效分析
• dashboard 展示

而不是一个审批节点引擎。

也就是说，团队是“责任与统计维度”，不天然等于“审批路径”。

第五层：为什么很多企业会把“团队负责人”误当成“折扣审批人”

因为从组织直觉看，这很顺：

• 订单挂在某个 team
• team leader 应该审批超标折扣

但标准源码里，user_id / team_id 的重点在于：

• 谁是销售员
• 订单归哪个 team
• 报表怎么算

并没有直接定义：

• 低毛利时自动找 leader 审批
• leader 不批就无法确认

这层逻辑如果要落地，通常需要额外实现：

• 审批条件
• 审批记录
• 按钮权限
• 状态切换
• 审批后才能 confirm 的控制

所以“有 sales team”并不等于“有审批流程”。

第六层：标准能力真正适合怎样的协作方式

如果你不强行把标准系统理解成审批引擎，其实它已经能很好支持一种“轻审批协作”：

1. 毛利先可视化

报价员先在订单行看到：

• 成本
• 毛利额
• 毛利率

2. 折扣统一落在标准字段或折扣向导

这样金额、税、报表口径不会乱。

3. 订单明确归属 team 与 salesperson

后续 dashboard、开票统计、目标完成率都还能追。

4. 真正的审批通过 chatter / activity / 自定义状态补上

也就是说，标准模块负责“算、显、记、归属”。 审批流负责“批、不批、谁批、何时批”。

这两层分开理解，实施反而更稳。

新手最容易误解的 6 件事

1. 装了 sale_margin 就有毛利审批

没有。它先给你的是毛利计算与可见性。

2. 开启 Discounts 就等于折扣审批上线

不是。那只是开放折扣能力。

3. Global Discount Wizard 就是审批单

不是，它主要是把折扣正确落到订单金额结构里。

4. 销售团队天然就是审批链

不是，标准 team 更偏归属与统计。

5. team leader 一定会被系统自动卷入低毛利订单

标准源码没有这条自动链。

6. 想做审批，只要在视图里隐藏 Confirm 按钮就够了

不够。真正稳妥的控制还需要模型层和状态层设计。

实战里我建议这样设计

如果你只是想让团队“先看见风险”

标准就很够：

• 开启 sale_margin
• 开启折扣能力
• 明确 sales team 归属
• 用报表和 dashboard 做跟踪

如果你想做“超过阈值必须审批”

请单独设计：

• 低毛利阈值
• 高折扣阈值
• 审批角色
• 审批状态
• Confirm / Unlock / Discount 按钮的模型层约束

如果你想让团队协作更顺

优先把三件事先定义清楚：

• 谁负责报价
• 谁对利润负责
• 谁对团队目标负责

这三种责任，在标准 Odoo 里不必然是同一个字段自动表达的。

最后一句话

Odoo 标准销售对毛利、折扣和团队协作的设计，本质上是：

把利润看清、把折扣记准、把订单归队。

至于“是否审批、谁审批、审批后才能不能确认”，那通常是下一层业务治理设计，而不是标准模块自动送给你的完整答案。