Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版把电子表格文档加入 Dashboard 时，真正发生的不是“复制一份”：快照冻结、评论迁移、权限组重挂与归档边界讲透
很多人以为 Odoo 企业版里把 Documents 里的 spreadsheet 加进 Dashboard，只是“把同一份表再显示一次”。但 `spreadsheet_dashboard_documents` 源码和测试说明，官方实现的是一次受控交接：先保存快照，再以 dashboard section 和 access groups 新建仪表板，把单元格评论线程从 document 侧改挂到 dashboard 侧，清空 JSON 里的 comments，并把原文档归档。
Odoo 企业版 CRM/Helpdesk 为什么不是“改个类型”就完了：线索与工单双向转换、消息线程与 UTM 继承边界讲透
很多人以为 Odoo 把 lead 转 ticket、或把 ticket 转 lead，本质只是同一条记录换个业务类型。企业版 crm_helpdesk 的真实做法更谨慎：它会新建目标对象、迁移消息线程与附件、归档原对象，并把客户匹配、团队归属与 UTM 来源按不同规则接过去。
Odoo 项目文档为什么不是“项目下建个文件夹”就完了：documents_project 的自动建档、权限同步与上传边界讲透
很多人以为 Odoo 企业版项目文档只是给 project 加一个 documents 文件夹。可从 `documents_project` 源码看，官方真正做的是一套“项目 -> 文件夹 -> 文档默认归属 -> 对外上传入口”的联动机制。本文把自动建档、重命名、换文件夹、公司约束与分享边界一次讲清。
Odoo 企业版订阅项目为什么不是“挂个项目字段”就完了：递归任务、续约承接与 Profitability 的 Subscriptions 区块讲透
很多人以为订阅单挂上项目后，无非就是项目里能看到一条销售记录。但从企业版 project_sale_subscription 源码看，订阅会同时改写任务生成、递归结束方式、upsell/renew 的项目承接，以及项目 Profitability 里收入归集的口径。真正难点不是“有没有关联项目”，而是“项目协作链”和“经营收入链”要不要跟订阅生命周期一起走。
Odoo 企业版银行对账单 OCR 为什么不是“上传即导入”：post-commit 发送、webhook 回调与覆盖保护讲透
很多人把企业版银行对账单 OCR 理解成“上传 PDF 后系统直接生成流水”。但从 `account_bank_statement_extract` 与 `iap_extract` 源码看，官方真正设计的是一条异步链：先建 statement、事务提交后再扣 OCR credits、由 webhook 回调触发结果拉取，并用 extractable state 防止覆盖已经人工处理的流水。
Odoo 企业版 Shopee 发货为什么不是“拿到单号就结束”：processing pickings、label 状态与 tracking 回填链讲透
sale_shopee 先筛 eligible pickings，再取 tracking，接着请求和轮询 label 状态；平台履约是多段异步链，而不是拿到单号就完。