Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Social 为什么不是“统一发社媒内容”而已：UTM、live post 与多公司访问边界讲透
Social 模块处理的不是一个群发器，而是一套跨账号、跨公司、跨媒介的内容与归因体系：发帖时要生成 UTM，发出后要拉 live statistics，多公司下还要保证谁能看、谁能发、谁能接账号。
Odoo 企业版活动为什么不是“多几个图表”而已：cohort、gantt 与 registration 分析边界讲透
event_enterprise 虽然代码不多，但它给活动管理补的是分析视角：报名记录怎样进入 cohort 观察、活动怎样在 gantt 上看排期，以及这些分析为何必须建立在
Odoo 企业版 Studio 建模型为什么不是“点几下就有个 x_ 模型”：字段种子、权限初始化与自动视图链路讲透
web_studio 的 studio_model_create 真正做的是一条后端建模流水线：x_name 种子字段、可选能力扩展、access rights 初始化和 automatic views 全都自动衔接。
Odoo 企业版 AI 字段为什么不是“给字段加个模型提示词”而已：property definition、cron fill 与 write/create
ai_fields 把 AI 结果做成字段，不只是多一个 compute。它要在模型元数据里反射参数、校验 property definition、决定哪些记录可批量补值，并且在
Odoo 企业版 Sign 为什么不是“发个签署链接”而已：共享签署、过期校验、拒签复制与日志完整性链路讲透
很多人把 Odoo 企业版 Sign 理解成“给签署人发一个 URL”。但从 `sign` 源码看，官方真正处理的是共享请求与实名请求的分流、邮件链接的过期签名、拒签时为何复制 shared 请求、签署人改派后的 token 轮换，以及签署日志如何串成不可篡改的证据链。
Odoo 企业版 Approvals + Documents 为什么不是“审批单挂个附件”：documents_approvals 的默认文件夹、标签、可见性与回退路径讲透
很多人把 Odoo 企业版审批附件理解成“approval.request 上多了个附件列表”。但 `documents_approvals` 真正做的是把审批材料接进 Documents 的治理体系：默认审批目录、公司级标签、文档 mixin 自动建档、按审批参与者收敛访问权，以及关闭开关后的动作回退。