Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Knowledge 为什么不用文章 Chatter 直接评论：行内 Thread、锚点快照、点名通知与关闭边界讲透
很多人以为 Knowledge 评论无非是给文章挂个 chatter。但从 `knowledge.article.thread` 的模型、控制器与测试看，Odoo 企业版做的是另一套机制：评论 thread 绑定的是文章里的某段内容，不是整篇文章；锚点文本会被净化成快照；portal 用户虽然可参与，但发送字段、通知收件人、附件 token、关闭权限都被严格收口。
Odoo 企业版采购 Intrastat 为什么不是“供应商发票自动带上采购来源”而已：invoice 准备值、国家字段与申报边界讲透
purchase_intrastat 看起来只是一个 bridge，但它决定了采购单进入供应商发票时，Intrastat 相关国家与申报字段如何被保留下来，避免后续统计时只剩会计单据而丢失采购来源语义。
Odoo 企业版为什么不让外部人直接编辑在线 Spreadsheet：冻结副本、token 只读与修订隔离边界讲透
很多人以为 Documents 里的在线 spreadsheet 只要分享链接就能像普通云表格一样协同外部编辑。但从 `documents_spreadsheet` 源码和测试看，Odoo 企业版刻意把“内部协作态”和“外部分发态”拆开：在线表格禁止 portal / 链接编辑，真正对外共享走的是 freeze-and-copy 只读副本，连 revision、Excel 下载和 live data 展示都单独设了边界。
Odoo 企业版采购关账为什么不是“看未开票采购单”而已：prepaid expense、bill to receive 与 accrual 搜索口径讲透
purchase_accountant 不是给采购单多几个筛选器这么简单。它重写的是关账观察角度：哪些采购行其实是 prepaid expense，哪些还属于
Odoo 企业版采购审批为什么不是“批完自动建采购单”而已：warehouse、picking type 与 vendor 分单链路讲透
approvals_purchase_stock 把审批、采购、库存三条线绑在一起：审批商品行要先知道落哪个仓、走哪个收货类型，再按供应商构造采购单，最后把这些选择安全地回写到审批流里。
Odoo 企业版订阅按工时计费为什么不是“timesheet 填了就能开票”而已：postpaid line、delivered qty 与发票回链讲透
sale_subscription_timesheet 解决的是订阅、项目工时和开票三者之间的精确衔接：哪些订阅行算 postpaid、哪些 timesheet