Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工

先说结论

Odoo 里“去客户现场维修”最合适的主线，不是单独靠 Repair，而是以 Helpdesk + Field Service 为主，按需接 Inventory / Repair / Sales / Invoicing。

原因很简单：

• Helpdesk 负责接住客户报修和售后上下文；
• Field Service 负责把“要上门”变成可派工、可执行、可签字的现场任务；
• Inventory 负责配件、退料、补料和仓位流转；
• Repair 负责把“这件东西怎么修、拆什么、换什么、修完后产品身份如何延续”讲清楚；
• Sales / Invoicing 负责把上门费、工时费、配件费结掉。

所以“上门维修”本质上不是单一维修单，而是一条售后工单 → 现场派工 → 维修执行 → 物料流转 → 收费闭环的服务链。

---

一、为什么不能把“上门维修”直接等同于 Repair

很多团队第一反应是：

客户设备坏了，就开一张 repair order 不就完了吗？

这个理解只覆盖了“修”这件事，却没覆盖“去客户那里处理”这件事。

现场维修通常至少包含这些阶段：

1. 客户报修；
2. 客服判断是否保修、是否收费、是否需要上门；
3. 派技术员、约时间、带配件；
4. 到场处理、记录工时、拍照、签字；
5. 现场修好 / 缺件待二次上门 / 需要返厂 / 无法修复；
6. 收上门费、工时费、配件费；
7. 留下维修历史与后续回访依据。

repair.order 解决的是维修对象、零件增减、库位与完工后追溯；它不是天然的派工中心，也不是售后入口。

从源码结构看，这个边界非常清楚：

• enterprise/helpdesk_fsm 负责把 Helpdesk ticket 转成现场服务任务；
• enterprise/helpdesk_repair 负责把 Helpdesk ticket 与 repair order 串起来；
• enterprise/industry_fsm_stock 负责现场任务完成时的物料与交付闭环；
• addons/repair 才真正负责 repair order 的状态机、零件流转与维修语义。

也就是说，Repair 是维修语义，Field Service 是上门执行语义，Helpdesk 是售后入口语义。

---

二、Odoo 标准模块各自该管什么

1. Helpdesk：让报修先有“总入口”

上门维修最怕一开始就没有统一入口。

客户可能通过电话、邮件、微信、销售转述、现场人员反馈等各种方式报修。如果没有 ticket 作为总入口，后面就会出现这些问题：

• 技术员知道现场情况，但客服看不到；
• 客服答应了客户时效，但派工端不知道；
• 维修、退货、返厂、收费各有各的单，却没有一条主事实链。

helpdesk_fsm 里有一个很关键的动作：action_generate_fsm_task()。官方按钮名称就很直白：Plan Intervention。

这说明 Odoo 的默认思路不是“报修 = 直接维修”，而是：

先把客户问题收敛在 ticket 里，再决定是否生成一次现场干预任务。

如果你的业务有客服、售后主管、技术员三种角色，这个入口几乎是必须的。

---

2. Field Service：把“要上门”变成可执行任务

Helpdesk 解决的是“接单”，Field Service 解决的是“执行”。

进入现场服务以后，系统真正要承接的是：

• 客户地址；
• 上门时间；
• 指派技术员；
• 现场服务项目；
• 工时记录；
• 客户签字或服务报告；
• 是否完成、是否需要再次上门。

这一层的核心不是维修动作本身，而是服务调度和交付留痕。

所以 Field Service 更像你现实里的“派工单 / 上门服务单”，而不是“维修工艺单”。

如果只用 Repair，不用 Field Service，通常会缺少：

• 谁去；
• 什么时候去；
• 到场后记录了什么；
• 客户是否签收；
• 这次上门是否真正完成。

这就是很多团队把 Repair 用成“万能售后单”后，最后一定会补一层自定义派工逻辑的原因。

---

3. Inventory：现场换件不能只记结果，必须记流转

只要现场维修涉及配件，库存就不能缺席。

现实里常见的几种动作有：

• 技术员出发前从仓库领件；
• 到客户现场更换配件；
• 多带的料退回；
• 换下来的旧件回收；
• 缺件后再补发；
• 二次上门补装。

industry_fsm_stock 的逻辑重点就在这里。它不是只给任务表单多放几个材料字段，而是在 action_fsm_validate() 和 _prepare_materials_delivery() 周围，把：

• 物料交付；
• 已交付数量；
• 出库校验；
• 销售订单锁定；

这些事情一起收口。

这说明 Odoo 官方并不把现场材料当作“备注一下就行”的轻字段，而是把它看成销售、库存、任务三边要对齐的正式业务对象。

如果你的上门维修会收配件费，Inventory 基本不是可选项。

---

4. Repair：它负责“怎么修”，而不是“怎么派工”

addons/repair/models/repair.py 里对 repair order 的定义非常完整：

• 产品要从哪里来；
• 修完后去哪里；
• 新增件去哪里；
• 拆下件去哪里；
• 回收件去哪里；
• 当前处于 draft / confirmed / under_repair / done / cancel 哪个状态。

这类设计说明 Repair 关注的是：

维修对象的库存语义、产品身份延续、零件增减和完工追溯。

它特别适合这些场景：

• 现场没有修好，需要返厂正式维修；
• 需要精确记录换了哪些件、拆了哪些件；
• 要区分 added / removed / recycled parts；
• 要处理 lot/serial、保修、维修后产品继续存在的语义。

所以更合理的理解不是“上门维修靠 Repair 完成”，而是：

• 上门这件事，靠 Helpdesk + Field Service；
• 维修这件事，必要时再由 Repair 承接。

---

三、最稳的业务蓝图：一条单线，两个分叉

如果让我给实施团队画一条最实用的标准流程，我会这样设计。

第一步：客户报修，先生成 Helpdesk Ticket

ticket 至少要承接这些字段：

• 客户；
• 联系人；
• 服务地址；
• 产品/设备；
• 序列号或 lot；
• 故障现象；
• 是否保修内；
• 紧急程度；
• 希望上门时间。

这一步的目标不是马上派工，而是先把客户事实和售后上下文统一下来。

第二步：客服判断，是否需要上门

客服或售后主管要先判断三件事：

1. 电话指导能否解决；
2. 是否需要现场干预；
3. 预计是收费、保修还是待判定。

如果需要上门，就从 ticket 生成 FSM task。

这正好对应 helpdesk_fsm 的设计思路：ticket 先存在，再 Plan Intervention。

第三步：生成 Field Service Task，正式派工

FSM task 负责承接：

• 技术员；
• 预约时间；
• 上门地址；
• 现场说明；
• 预计工时；
• 关联客户与原工单。

此时业务含义已经从“客户说有问题”变成“公司决定派人去处理”。

第四步：现场执行，记录工时、材料与结果

技术员到场后，至少要记录：

• 到场 / 离场时间；
• 实际工时；
• 现场诊断；
• 用掉的配件；
• 拍照或备注；
• 客户签字；
• 本次结果。

结果建议标准化成四种：

1. 当场修复；
2. 缺件待二次上门；
3. 需要返厂维修；
4. 无法维修，建议更换。

这一步最关键的是：不要只记录“修好了没有”，而要记录“这次上门产生了什么业务后果”。

第五步：根据现场结果走两个分叉

分叉 A：现场修好

如果已经在客户现场解决：

• FSM task 完成；
• 工时、材料、签字留痕；
• 上门费 / 工时费 / 配件费进入可结算对象。

这一类场景甚至不一定需要 Repair。

分叉 B：现场没修好，转正式维修

如果现场只是确认故障、拆机、收件、等待备件，后续还要进一步维修：

• ticket 仍然保留为总入口；
• FSM task 记录“本次上门做了什么”；
• 再建立 repair order，或走返厂/退货链路。

这就是 helpdesk_repair 真正有价值的地方：不是“能开 repair 单”，而是让客服视角和维修视角仍然挂在同一个 ticket 之下。

---

四、什么场景只用 Field Service 就够了，什么场景一定要接 Repair

这个边界如果分不清，实施时最容易过度设计。

只用 Field Service 就够的情况

• 现场主要是检修、校准、保养；
• 更换的是少量标准配件；
• 没有复杂拆解和正式维修工艺；
• 你更看重派工、工时、签字和收费闭环。

例如：

• 空调上门加冷媒；
• 设备巡检保养；
• 门锁调试；
• 简单零件替换。

这类业务的核心矛盾不是 repair order，而是任务执行质量。

必须接 Repair 的情况

• 需要精确记录维修对象、部件增减和库位语义；
• 需要 lot / serial 级维修追溯；
• 需要返厂、拆件、回收件管理；
• 需要把保修维修与收费维修严格区分；
• 现场只是初步处理，真正维修发生在仓内或维修中心。

例如：

• 医疗设备返厂维修；
• 工业控制器拆板换件；
• 高价值设备序列号级维修；
• 保内维修与旧件回收并存。

一句话总结：

Field Service 解决“服务任务有没有完成”，Repair 解决“维修对象到底发生了什么”。

---

五、如果要收费，别把收费逻辑塞进维修备注

上门维修一旦收费，最好把费用拆成标准产品，而不是写在备注里手工记。

常见收费项目：

• 上门费；
• 检测费；
• 工时费；
• 配件费；
• 加急费。

在 Odoo 里更稳的做法通常是：

• 上门费、检测费、工时费建成服务产品；
• 配件建成库存产品；
• 最终生成销售订单 / 发票。

这样你后面才能分析：

• 哪类故障最费工时；
• 哪些客户维修频率高；
• 哪些保内服务正在持续亏损；
• 哪些技术员现场解决率更高。

如果所有收费都只写在任务备注里，系统最后只会留下“有人去过”，不会留下“这次服务到底赚没赚钱”。

---

六、标准 Odoo 大概能覆盖到哪，哪些地方大概率要定制

标准版通常能覆盖的部分

• 客户报修入口；
• 派工与上门任务；
• 工时与材料记录；
• repair order 维修主单；
• 工单与维修、任务之间的关联；
• 基础收费闭环。

很多项目后面都会补的定制点

1. 客户设备台账

不是所有行业都只修“销售订单上的商品”。很多场景修的是客户现场已经安装多年的设备。

这时你通常需要：

• 客户资产台账；
• 安装位置；
• 保修起止；
• 历史维修记录；
• 设备序列号映射。

2. 二次上门闭环

标准流程能做多次任务，但业务上常常还要明确：

• 首次上门诊断；
• 待料；
• 预约二访；
• 二访完成。

这类状态最好业务化，不要只靠 chatter 描述。

3. 旧件回收与责任判定

尤其是保修维修、以旧换新、寄回厂家分析这类场景，旧件去向往往要单独追。

4. 自动保修判定

客户说“这还在保修期内”，和系统能自动判定不是一回事。

只要你的收费规则受保修影响，迟早会想把：

• 销售日期；
• 安装日期；
• 合同年限；
• 延保规则；

串到自动判断里。

5. 标准化服务报告

现场照片、故障分类、处理结论、签字报告、PDF 留档，很多团队都会做成统一模板。

---

七、一个最实用的落地建议：先跑通，再做深

如果你们现在只是要把业务先落进 Odoo，不建议第一天就做一整套超复杂定制。

更稳的做法是三阶段推进。

第一阶段：先跑通售后与上门

模块组合：

• Helpdesk
• Field Service
• Inventory
• Sales / Invoicing

先解决：

• 客户报修；
• 派工上门；
• 材料记录；
• 工时收费。

第二阶段：补正式维修闭环

再接入：

• Repair
• ticket ↔ repair 联动
• 返厂维修
• 二次上门
• 旧件回收

第三阶段：做经营分析与自动化

最后再做：

• 保修自动判定；
• 技术员绩效；
• 首次修复率；
• 故障分类统计；
• 区域派工优化；
• 维保计划自动生成。

这个顺序的好处是：不会一开始就把项目做成“字段很多、流程很重、但一线没人愿意用”。

---

八、结论

Odoo 里的客户现场维修，不应该被理解成“开一张维修单”。

更准确的理解应该是：

它是一条以 Helpdesk 为售后入口、以 Field Service 为现场执行、以 Inventory 为物料闭环、按需由 Repair 承接正式维修语义的服务链。

如果你只抓 Repair，会缺派工和现场交付； 如果你只抓 Field Service，会缺维修对象和零件语义； 如果你忽略 Inventory，配件和收费最后都会失真。

所以最稳的设计，不是谁替代谁，而是让这几个模块各管自己最擅长的那一段。