Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Microsoft Calendar 预约同步为什么不是“换个连接器就等同 Google”：connector 检测、日历筛选与 setup 提示讲透
基于 appointment_microsoft_calendar 源码，讲清 Microsoft 预约同步如何判断连接器可用、已配置状态与暂停开关。
Odoo 企业版 Google Calendar 预约同步为什么不是“连上账号就不会撞会”：calendar setup、videocall source 与 post-sync 回写讲透
基于 appointment_google_calendar 源码，讲清 Google 连接器、Meet 链接生成、同步前后字段处理，以及用户未同步时的提示边界。
Odoo Mass Mailing 为什么不是“点发送就完了”：黑名单、seen list、队列发送与失败重试讲透
真正决定群发系统是否稳定的，不是编辑器，而是发送前如何排除 opt-out、如何避免重复触达、如何用队列推进，以及失败后怎么重试。Odoo 在 mailing.py 里把这些都做成了明确链路。
Odoo 群发联系人为什么不能只是一张邮箱表：subscription 中间表、opt-out 时间与默认名单同步讲透
Odoo 把 mailing.contact 和 mailing.list 之间专门拆出 mailing.subscription，并额外记录 opt_out_reason、opt_out_datetime 和 default_list_ids 上下文同步，这说明它把名单关系当成业务对象，而不是一个普通 many2many。
Odoo Mail Plugin 联系人为什么不是“搜不到就新建一下”：公司富化、域名缓存与访问边界讲透
Mail Plugin 在联系人侧真正复杂的，不是“有没有搜到人”，而是它会不会按邮箱域名复用公司、何时调用 IAP 富化、没权限时返回什么，以及通知邮箱这类特殊地址怎么处理。
Odoo Mail Plugin 为什么不是“邮箱插件连一下就能用”：授权页、临时 auth code 与 access token 交换链路讲透
Mail Plugin 接入看起来像一个“登录成功”的瞬间，但源码实际上拆成了授权确认页、短时效 auth code、签名校验和 access token 交换四步，核心目的是把浏览器里的人工确认和插件里的长期访问权隔开。