Odoo 企业版 Approvals 为什么不是“建个审批类型”就完了：分类字段模板、经理必审与顺序审批 guardrails 讲透

很多团队第一次上 Approvals，会把“分类”理解成一个筛选标签。但 approval.category 真正做的，是把请求长成什么样、默认找谁审批、最少要过几个人、编号如何生成，全部在模型层一次性定下来。

这篇主要参考：

• enterprise/approvals/models/approval_category.py
• enterprise/approvals/models/approval_request.py
• enterprise/approvals/tests/test_approvals.py

一、它先定义“请求 schema”，再定义“谁来批”

分类上那组 has_date / has_period / has_amount / has_product / requirer_document / approval_properties_definition，本质不是 UI 开关，而是请求单据的数据骨架。业务上想做差旅、借用品、费用、付款，不是靠同一个表单硬填，而是靠分类决定哪些字段必须出现、哪些只是可选。

这也是为什么 Approvals 比“邮件走流程”更稳：入口还没发生审批动作，数据边界已经先收紧了。

二、最低审批人数不是独立参数，要和默认审批人、经理审批一起算

_compute_invalid_minimum() 和 _constrains_approval_minimum() 把两件事分开做：

• 先算“你设的 minimum 是否超过默认可审批人数 + 经理审批补位”；
• 再校验“minimum 不能低于 required approver 的数量”。

所以 minimum 不是随手填的 KPI，而是一个必须和 approver roster 对齐的约束值。很多人以为 minimum=2 就够了，但如果默认审批人里已有 2 个 required，再加经理 required，流程根本起不来。

三、经理审批不是附加通知，而是会改写 approver 列表顺序

manager_approval 既能把直属经理当普通 approver，也能强制成 required approver。更关键的是，_compute_approver_ids() 会把经理插到序列更靠前的位置，默认 sequence 设成比普通人更小，让“经理先批”变成模型层事实，而不是前台展示习惯。

这解释了一个常见误区：团队以为只是“经理也收到通知”，实际上经理可能已经被强行写进审批链，而且在顺序审批里是第一棒。

四、自动编号和顺序审批各自解决不同问题

automated_sequence + sequence_code 只负责把请求名变成可追踪编号；approver_sequence 才负责把审批状态拆成 new / pending / waiting。两者经常一起启用，但不要混为一谈：

• 编号解决的是“这张单是谁”；
• 顺序审批解决的是“现在轮到谁”。

五、落地建议

• 先按业务类型设计分类字段，不要先建一堆空分类。
• required approver、minimum、manager approval 三者一起验算。
• 需要严格责任顺序时才开 approver_sequence，否则并行审批更顺手。
• 想做审计追踪时，优先开自动编号，不要指望人工命名稳定。

六、结论

Approvals 的分类不是“标签层”，而是审批请求的数据模型与责任模型。把分类建对了，后面的最低人数、经理必审、顺序审批才不会彼此打架。