Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
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 活动入口为什么不只是一张报名页：ICS 下载、外部描述与 registration desk kiosk 讲透
很多人把 Odoo Event 的公开入口理解成“活动详情页 + 报名按钮”，但 event_event.py 和 event/controllers/main.py 实际还提供了两种很不同的入口：一种把活动包装成 ICS 日历文件带出站外，一种把现场接待切到 registration desk kiosk。理解这两条入口链，才知道活动系统并不只服务报名页面。
Odoo 问卷后台统计为什么会“每题长得不一样”：矩阵题、量表题与汇总管线讲透
很多人以为 Odoo Survey 的结果页只是把答案数量数一遍再画图，但从 survey_question.py 与 survey_user_input.py 看，后台其实按题型走了多条统计管线：choice、matrix、scale、numerical 各有不同表格和图表结构，scored 问题还会额外计算正确率、partial 与常见答案。理解这层，你才知道为什么“每道题的统计长得不一样”并不是前端花活，而是模型设计本身。
Odoo 企业版 Documents + Fleet 为什么不是“车辆上挂附件”而已：集中 folder、owner 策略与访问传播边界讲透
基于 documents_fleet 源码与测试，讲清车辆文档为什么集中进公司级 folder、默认 owner 为当前用户、访问链接默认关闭，以及 company 设置关闭后为何不再自动建文档。