Odoo 企业版项目预测为什么不是“销售卖了工时就自动排满”：报价工时、forecast slot 与工时回写讲透

project_timesheet_forecast_sale 的核心不是复制 planning slot，而是让销售工时、预测排班和已验证工时持续互相校正。

主要参考：

- `enterprise/project_timesheet_forecast_sale/models/planning_slot.py`

• enterprise/project_timesheet_forecast_sale/models/sale_order_line.py
• enterprise/project_timesheet_forecast_sale/models/analytic_account_line.py

• enterprise/project_timesheet_forecast_sale/tests/test_planning.py

  ---

  一、这不是单模块按钮，而是一条跨模块链路

  很多人把这个功能理解成某个界面上的一个按钮、一个 smart button，或者一次自动创建。但从源码看，真正重要的是：上游对象先保留业务上下文，中间层做状态/域/权限判断，下游对象再接住这个上下文继续工作。只看最后一个界面动作，很容易把问题看窄。

  二、核心跨链路是怎么跑通的

  1. 复制 planning slot 时，系统先计算项目剩余可排工时 allocated_hours - total_forecast_time，不是无脑复制整段 slot。
  2. 如果 sold product 没开 planning_enabled，slot 结束时间会被缩短到剩余可排时数，超出的部分根本不会落库。
  3. timesheet 一旦改 validated 或 unit_amount，会触发 _post_process_planning_sale_line()，把 sale line 的已排/已做口径重新平衡。

  这就是为什么我把它归类为“跨模块链路”题：这里至少同时牵涉了业务对象、会计/项目/销售对象，以及状态或权限判断，而不是单个模型内部的小机制。

  三、最容易踩错的边界

  • 没有 allocated hours 的项目允许复制 slot，但不会做剩余工时限制。
  • 对 planning-enabled 产品，排班统计会基于最近一次 validated timesheet 之后的 slot 重新计算，避免历史重复统计。
  • material resource 不计入这条排班链，系统会在 domain 里排除。

  这些边界决定了数据是否还能回到正确的模块继续流动。如果边界被自定义绕开，后面最常见的结果就是：报表看起来还能出， drill-down 却已经解释不通。

  四、落地时最值得先验的三件事

  1. 项目交付要讨论三套数：已售、已排、已做，不要只盯一种。
  2. 售前承诺经常失真时，先看 allocated_hours 是否正确写回项目。
  3. 若项目预测总是虚高，检查 validated timesheet 与 planning slot 的截断点。

  五、结论

  销售卖出的工时不会自动变成可执行排班，系统会不断用预测和已做工时去回正。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。