Odoo 项目更新为什么不是“自动日报”：project.update、状态快照与项目汇报边界讲透
很多人以为 Odoo 项目里的 Update 就是一个会自动刷新的状态面板，但源码真正做的是“带上下文的人工快照”。本文从 project.update、last_update_status、默认描述模板和 milestone 变化跟踪讲清它的设计边界。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 项目更新为什么不是“自动日报”：project.update、状态快照与项目汇报边界讲透
很多人以为 Odoo 项目里的 Update 就是一个会自动刷新的状态面板，但源码真正做的是“带上下文的人工快照”。本文从 project.update、last_update_status、默认描述模板和 milestone 变化跟踪讲清它的设计边界。
Odoo 里的剩余工时为什么有两套：任务 `remaining_hours` 与销售订单行 `remaining_hours_so` 到底各管什么
很多人看到 Odoo 任务上既有剩余工时，又能看到销售订单行剩余工时，会觉得重复。其实这两者分别回答的是“任务预算还剩多少”和“合同还能消耗多少”，是执行视角与商业视角的两套余额系统。
Odoo 任务分析为什么不是“列表上多几个统计字段”：`report.project.task.user` 这张 SQL 视图到底在汇总什么
Odoo 项目分析页看起来只是任务列表加图表，但底层并不是直接查 `project.task`。官方专门做了一张 `report.project.task.user` 视图，把任务、评分、依赖、里程碑超期和销售剩余工时等指标提前揉成分析底座。本文把这张视图讲透。
Odoo 员工价项目为什么不是“不同员工填不同单价”：employee_rate、sale line mapping 与工时默认归属的底层设计
很多公司做顾问项目时，希望高级顾问和初级顾问按不同价格计费。Odoo 并不是在 timesheet 上直接填一个价格，而是通过 project.sale.line.employee.map、默认销售行选择和成本覆写机制来实现。本文把这套设计讲透。
Odoo 服务产品为什么不会“自动长任务”这么简单：从 service_tracking 到销售订单行生成项目/任务的整条链路
很多人以为 Odoo 服务产品确认销售订单后只是“自动建一个项目或任务”。其实真正决定结果的是 service_tracking、service_policy、模板复用、分析账户和销售订单行复用规则的组合。本文把这条生成链完整讲透。
Odoo 工时计费为什么不是“登记了几小时就能开几小时”：delivered quantity、qty_to_invoice 与退款回冲的真实链路
在 Odoo 里，工时型服务的已交付数量和待开票数量并不是简单等于 timesheet 的小时数。源码里还掺着 domain 过滤、退款单回冲、未开票工时筛选和期间重算逻辑。本文把这条链讲透。