Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 附件搜索为什么不是只看文件名：attachment_indexation 的文本提取、缓存与回退链路讲透
基于 attachment_indexation 源码，讲清 Odoo 如何从 docx、pptx、xlsx、OpenDocument 与 PDF 中抽取文本，为什么会按 checksum 做缓存，以及提取失败时系统如何优雅回退。
Odoo 问卷邀请为什么不是“群发一个链接”而已：收件人识别、重复邀请与 token 链路讲透
Odoo 的 Survey Invite 向导看起来只是填几个邮箱然后发送，但源码里实际处理了 access mode、partner 识别、外部参与资格、重复邀请复用、answer token 生成、模板渲染和语言上下文。本文把 survey.invite 到 survey.user_input 的主链路一次讲清。
Odoo Mass Mailing 为什么不能只看“开信率”：A/B 抽样、trace 状态机与 24 小时统计邮件讲透
Odoo 的群发分析不是只看一个 opened ratio，它还涉及 A/B 抽样、winner mailing 选择、mailing.trace 状态流转，以及 24 小时后给负责人补发统计邮件。真正的分析链比看报表复杂得多。
Odoo 企业版维护 Worksheet 为什么不是“给维修单挂个表单”而已：template access、worksheet count 与自定义报告链路讲透
maintenance_worksheet 不是简单加一个富文本附件。它把维护请求和 worksheet template、安全组、打印报告串起来，让每一张维修单都能基于模板采集可审计的作业信息。
Odoo 企业版 Marketing Automation 为什么不是“定时群发”而已：participants、traces 与触发图边界讲透
很多人把 Odoo 企业版 Marketing Automation 想成邮件自动化器。真正看 marketing_automation 源码会发现，官方做的是一张“参与者 + 轨迹”执行图：campaign 决定目标模型与唯一键，participant 代表被纳入流程的记录，trace 代表某个活动在某个参与者上的待执行节点，活动修改后还要重新 sync 才会重排计划。
Odoo 维修申请为什么不是“收封邮件建个单”：团队别名、邮件入口与请求路由链路讲透
很多人把 Odoo Maintenance 的邮箱入口理解成“来一封邮件就生成一条维修单”，但 maintenance_team 的 alias、maintenance.request 的团队默认值，以及 hr_maintenance 对 message_new 的员工识别，实际上把“邮件入口”做成了一条带团队归属与人员语义的路由链。