很多团队理解“只按已审批工时计费”时，只想到发票金额会变。可企业版 sale_timesheet_enterprise 做得更彻底：当 sale.invoiced_timesheet=approved 时，不只是销售交付量要收紧，项目共享页面、portal 可见工时、任务进度口径都得一起收紧，否则前后端看到的就不是同一套真相。
主要参考：
enterprise/sale_timesheet_enterprise/models/sale_order_line.pyenterprise/sale_timesheet_enterprise/models/project_task.pyenterprise/sale_timesheet_enterprise/views/*
一、计费口径先从 delivered quantity 收紧
_timesheet_compute_delivered_quantity_domain() 会在参数为 approved 时，把 domain 再叠一层 validated = True。这意味着销售行上的已交付工时，不再看所有工时，而只看经过审批的工时。
这一点非常关键。否则企业嘴上说“按审批后工时计费”，系统底层却还在用草稿工时算交付量，销售和财务迟早对不上账。
二、项目共享页面也必须跟着收紧，不然客户看到的会比账单更多
_compute_project_sharing_timesheets() 会根据配置决定统计哪些工时；read() 在 portal 或 project sharing 场景下，如果是 approved 模式，还会把 timesheet_ids 过滤成仅 validated 记录；_get_portal_total_hours_dict() 也会只统计 validated 工时。
这说明企业版并没有把“审批口径”只停留在销售结算层，而是一路贯彻到客户可见页面。因为如果门户页展示 100 小时、账单只认 80 小时，客户体验和内部解释都会很糟糕。
三、进度条和共享视图，其实也是计费口径的一部分
项目共享字段里的 portal_effective_hours、portal_total_hours_spent、portal_progress 都会基于同一套工时统计逻辑。也就是说，客户或协作方看到的进度百分比，其实隐含着“哪些工时被视为有效”的管理选择。
这是很多团队最容易忽略的点：工时审批不只影响账单，还会影响客户对项目进度的理解。
四、为什么企业版要把这几层一起收口
因为企业里“可见即承诺”。只要门户上能看到、项目共享里能看到、销售交付量能算出来，外部就会把它当成同一个事实。如果这些层口径不一致，最后承担解释成本的通常是项目经理和财务，而不是系统。
sale_timesheet_enterprise 的价值，恰恰在于它避免了这类“各看各的数”。
五、新手误区
- 以为 approved-only 只影响 invoicing，不影响 portal。
- 以为项目共享进度只是展示层。实际上它也是业务承诺的一部分。
- 以为审批晚一点无所谓。审批节奏会直接影响客户看到的交付进度。
六、落地建议
- 开启 approved-only 前，先和项目团队说清楚：客户看到的工时与内部草稿工时会暂时不同，这是设计使然。
- 审批频率要跟客户沟通节奏匹配，否则门户进度会长期落后于实际执行。
- 若客户经常用项目共享页面看进度，建议把审批作为项目运营节奏的一部分，而不只是月底财务动作。
七、结论
sale_timesheet_enterprise 的成熟之处，在于它把“只认已审批工时”贯彻到交付量、portal 明细、项目共享进度三个层面。这样企业对内对外看到的，才会尽量是同一套可解释的工时事实。
DISCUSSION
评论区