Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Account Reports 为什么不是“点一下就导 Excel”而已：options 引擎、journal groups 与导出管线边界讲透
很多人把 Odoo 企业版财务报表理解成“前端选条件、后台跑 SQL、最后导 Excel”。真正看 `account_reports` 源码会发现，官方做的是一套更重的报表引擎：先把 date/comparison/journals 等状态收敛成 options，再由 report/handler 组合产线条与导出，journal groups、return periods、多公司、异步 send & print 和流式文件下载都围绕这套 options 语义展开。
Odoo 企业版 Salary Package Offer 为什么不是“发个 Offer 链接”而已：savepoint 模拟、候选人假员工与 countersign 生命周期讲透
很多人以为 Odoo 企业版 Salary Package Offer 只是给候选人发一个可调薪酬包的链接，再点签字完成入职。源码里真正复杂的地方在于：offer 页面其实跑在 savepoint 里的“模拟版本”，候选人阶段会先造一个 inactive 假员工承接配置，签字后再按单签/会签状态切换版本、激活员工并触发 benefit 相关活动与后续签署。
Odoo 企业版 Frontdesk 为什么不是“访客填个表单”而已：kiosk token、预约访客窗口与多通道通知边界讲透
很多人以为 Odoo 企业版 Frontdesk 就是一个访客签到页。翻 `frontdesk` 源码会发现，官方真正设计的是一套“公开 kiosk 入口 + 临时移动二维码 + 预约访客快签 + 负责人/接待人/饮品责任人分层通知”的前台协调机制，还额外处理了 host 不在线、跨公司 public user 访问和来访后勤协作。
Odoo 企业版工单 Worksheet 质检为什么不是“打开表单填完就行”：后台 wizard、成功条件与自动跳转链路讲透
很多人第一次在 Odoo 企业版车间端看到 worksheet 质检，会以为它只是把一张表单嵌进工单界面。但从 `quality_control_worksheet`、`quality_mrp_workorder_worksheet` 与 shop floor 前端补丁来看，官方真正做的是一条“双层状态机”：前台打开 worksheet，后台挂着 quality wizard，再根据成功条件决定 pass/fail，并自动跳到下一道质检或下一步工单。
Odoo 企业版 Helpdesk 课程中心为什么不是“挂几个培训课链接”而已：搜索范围、预览可见性与单/多课程路由讲透
很多人以为 Odoo 企业版把 eLearning 课程接进 Helpdesk，只是给帮助中心加几条“去上课”的链接。但从 website_helpdesk_slides 的 models、controller、模板和测试连起来看，官方真正做的是一条受控的前台学习链路：先按团队限定课程范围，再按访客权限裁切可见性，搜索结果还会根据是否可预览决定跳到具体课件还是课程首页。
Odoo 企业版 CRM 为什么订阅报价不会把商机金额随便改来改去：同币种门槛、只增不减、默认月计划与跟踪可见性讲透
很多人以为 Odoo 企业版里，订阅报价一旦绑定商机，确认报价时系统就会把 expected revenue 和 recurring revenue 直接同步过去。`crm_sale_subscription` 真正做的是一套更保守的桥接：只在同币种前提下按更大值上调收入，必要时补默认月计划，还会按权限隐藏 recurring revenue 的跟踪明细。