计划 vs 实际最怕一句“填了多少工时就减多少”，因为工时属于哪个 slot、哪个时间窗、哪个项目，远没这么简单。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/project_timesheet_forecast/models/planning_slot.pyenterprise/project_timesheet_forecast/tests/test_timesheet.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
project_timesheet_forecast 解决的是计划与实际的精细对照：同一 planning slot 该吸纳哪些 timesheet，effective hours 怎么算，项目 gantt 上的 progress bar 又如何按时间窗口动态重算。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 project_timesheet_forecast 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. timesheet 先有 domain，再谈对比
_get_timesheet_domain() 与 _compute_timesheet_ids() 说明实际工时不是全项目大杂烩，而是先按 slot 与时间窗口选出归属工时。
2. effective hours 不等于 timesheet hours 简单求和
_compute_effective_hours() 和 weekend 测试说明实际对比口径会考虑时间窗、单位编码甚至周末处理，不是粗暴累加。
3. 进度条是动态聚合结果
_gantt_progress_bar_project_id() / _gantt_progress_bar() 说明项目 gantt 上看到的 progress 不是静态字段，而是按当前时间段实时汇总。
三、最容易被误解的边界
- 把项目工时分析当作一张 planned - spent 表。
- 不控制 timesheet domain，导致任何工时都能落到任意 slot。
- 只看单条 slot，不看项目 gantt 汇总进度。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先核对 slot 的 timesheet domain。
- 再确认 effective hours 是否按正确窗口计算。
- 最后比对 gantt progress bar 与底层 timesheet 聚合是否一致。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
项目工时预测真正难的，不是拿到两组数字，而是确保计划与实际在同一时间、同一项目、同一 slot 语义下比较。
DISCUSSION
评论区