Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版付费预约为什么不是“客户付完钱就生成日历事件”：booking 暂存、发票支付与最终成会讲透
基于 appointment_account_payment 与 website_appointment_sale，讲清付费预约为何先存 calendar.booking，再在支付成功后转成真正会议或销售确认。
Odoo 企业版制造维护为什么不是“报修后把工位停掉”：工作中心阻塞、弹性排槽与预防性 leaves 讲透
基于 mrp_maintenance，讲清维护请求如何阻塞工作中心、自动避开已排工单，并为预防性维护预留未来多个停机时段。
Odoo 企业版 Peppol 收票为什么不是“进来就建供应商发票”：Documents 接收模式、文件夹路由与标签落位讲透
基于 documents_account_peppol，讲清企业版 Peppol 收票为何可以不直接落账，而先进入 Documents 文件夹并保留标签与追踪信息。
Odoo 企业版现场服务为什么不是“任务点完成就结束”：销售单预确认、工时挂单与材料出库统一放行讲透
基于 industry_fsm_sale 与 industry_fsm_stock，讲清 FSM 任务完成时为何要先补销售单、再挂工时、最后统一校验材料与序列号出库。
Odoo 企业版 WhatsApp 预约提醒为什么不是“模板一发就完事”：提醒窗口、消息模板与 booking 握手讲透
结合 whatsapp 与 appointment 源码，讲清预约提醒如果要走 WhatsApp，真正要处理的是模板变量、提醒窗口、预约记录上下文与回流动作。
Odoo 企业版 Documents + Fleet 为什么不是“车辆上挂附件”而已：集中 folder、owner 策略与访问传播边界讲透
基于 documents_fleet 源码与测试，讲清车辆文档为什么集中进公司级 folder、默认 owner 为当前用户、访问链接默认关闭，以及 company 设置关闭后为何不再自动建文档。