Odoo 企业版 Helpdesk 的 SLA 为什么不是“加几个小时”而已：工作日历、等待阶段冻结与 deadline 重算链路讲透

很多团队把 Helpdesk SLA 当倒计时器：建单时 +4 小时，到点就算超时。但 Odoo 企业版的 SLA 不是“绝对时间戳”，而是一个受工作日历、排除阶段和阶段迁移影响的动态结果。

主要参考：

• enterprise/helpdesk/models/helpdesk_ticket.py
• enterprise/helpdesk/tests/test_helpdesk_sla.py

一、deadline 不是固定值，而是“当前未完成 SLA 状态里的最早一个”

_compute_sla_deadline() 会遍历 sla_status_ids，只挑未 reached、且仍有 deadline 的状态，取最小值作为 ticket 的当前 SLA deadline。也就是说，一个工单不是只有一条 SLA，而是可能同时挂多条 policy，前台看到的是最紧的那条。

二、等待阶段不是继续计时，而是冻结

测试 test_sla_waiting 很关键：工单进入 waiting stage 时，deadline 会被清空；再次回到进行中阶段时，系统会把等待期间的工作时间补回去，再算新 deadline。这里补的不是自然时间，而是结合资源日历的工作时间。

这正是很多团队觉得“系统算错了”的来源：他们按真实时钟算，Odoo 按工作日历 + 冻结阶段算。

三、下班后建单不会从夜里开始计时

resource_calendar_id.get_work_duration_data() 决定了 SLA 时间在工作时间内推进。测试 test_deadlines_after_work 证明：晚上 20:00 建单、SLA 3 小时，不会算成当天 23:00，而会顺延到下一个工作日 11:00。

四、fail / reached / reached_late 不是一个字段换皮

• sla_reached 看的是是否有按时满足的状态；
• sla_reached_late 直接比 deadline 和 reached_datetime，甚至能识别“还没完成但已过期”；
• sla_fail 综合当前 deadline 和 late 标记，表达的是工单层面的失败状态。

五、落地建议

• 先设计 waiting / on-hold 阶段，再定义 SLA，不要反过来。
• 多时区团队要统一资源日历，不然 SLA 感知会严重偏差。
• 复盘超时时先看 stage 轨迹和 calendar，而不是只看 create_date。

六、结论

Helpdesk SLA 真正管理的不是“钟表时间”，而是服务承诺在工作日历里的可执行时间。只要把等待阶段、工作时段和多条 policy 忽略掉，SLA 看起来就一定像“算错了”。