Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Marketing Automation 为什么不是“定时群发”而已：participants、traces 与触发图边界讲透
很多人把 Odoo 企业版 Marketing Automation 想成邮件自动化器。真正看 marketing_automation 源码会发现，官方做的是一张“参与者 + 轨迹”执行图：campaign 决定目标模型与唯一键，participant 代表被纳入流程的记录，trace 代表某个活动在某个参与者上的待执行节点，活动修改后还要重新 sync 才会重排计划。
Odoo 企业版 Approvals 为什么不是“点同意/拒绝”而已：顺序审批、最低人数、必审人与活动队列边界讲透
很多人把 Odoo 企业版 Approvals 看成一个很轻的审批按钮系统。源码里真正重要的不是按钮，而是“最低审批人数 + 必审人 + 顺序审批 + mail.activity 队列”四层约束如何一起决定请求何时进入 approved、refused 或 waiting。
Odoo 企业版知识库为什么不是“勾上网站发布就完了”：公开子树、发布传播与侧边栏可见性边界讲透
很多人以为企业版 website_knowledge 只是给 Knowledge 多一个前台页面。但从 models、controller 和测试一起看，官方真正做的是一套“公开子树”机制：发布状态会向后代传播、公开访问按根祖先裁剪、侧边栏只展示可达节点，连 summary / OG / Twitter 元信息都按前台阅读场景重新计算。
Odoo 企业版现场服务为什么不是“签个字就算交付留痕”：worksheet 可用条件、portal 签署与报告附件回写讲透
基于 industry_fsm 源码，讲清现场服务报告何时可生成、为什么没工时时不能直接签署、portal 客户签字后又如何把 PDF 回帖到任务消息流。
Odoo 企业版现场服务为什么不是“领料后就不能回头”：补料、退料限制、批次回写与 delivered quantity 重算讲透
基于 industry_fsm_stock 源码，讲清现场服务任务里材料数量为何不能随手回改、为什么必须走库存退货、以及 lot/serial 与 delivered quantity 如何一起被重建。
Odoo 企业版 360 反馈为什么不是“多找几个人打分”而已：周期、匿名性与参与人扩展链路讲透
基于 hr_appraisal 源码，讲清 Odoo 企业版 360 反馈如何把 appraisal 周期、员工/经理视图、反馈可见性与参与人扩展串成一条真正可落地的评估链。