Odoo 企业版工时审批为什么不只是锁住 timesheet：销售行归属、门户可见工时与计费口径讲透

工时审批真正影响的是交付、开票和客户可见性；validated 不是 UI 标签，而是贯穿项目、销售和门户的状态位。

主要参考：

- `enterprise/timesheet_grid/models/account_analytic_line.py`

• enterprise/sale_timesheet_enterprise/models/account_analytic_line.py

• enterprise/timesheet_grid/tests/test_timesheet_grid.py

  ---

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

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

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

  1. approver 验证工时时，系统先按员工/项目/上级关系筛出可审批行，再统一停掉相关 timer。
  2. 写入 validated=True 后，会回写员工的 last_validated_timesheet_date，并中断早于该日期的仍在运行计时器。
  3. sale_timesheet_enterprise 再利用 validated 状态限制 so_line 更新、portal timesheet domain，以及已开票工时的反审批边界。

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

  三、最容易踩错的边界

  • 未通过 approver 权限校验的用户只能得到 danger notification 或 AccessError。
  • validated 的工时默认不可编辑、不可继续计时；已关联发票的工时更不允许随便反审批。
  • 当配置 sale.invoiced_timesheet = approved 时，门户只能看到已审批工时。

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

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

  1. 如果客户门户与内部已做工时总是对不上，先核对 approved-only 配置。
  2. 审批流程别只看 HR 侧体验，要把销售、项目经理和客户可见性一起验收。
  3. 计时器异常不断线时，重点看 last_validated_timesheet_date 的更新。

  五、结论

  validated 不只是锁字段，它会改变销售行计算、门户可见范围和计时器行为。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。