Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 车队为什么不只是“记一辆车”：车型默认值、里程回写与维修紧急信号链路讲透
很多人把 Odoo Fleet 当成车辆台账，但源码里的 fleet.vehicle 实际把车型模板、车辆实例、里程日志、维修活动信号和服务统计都收进了同一个运营枢纽。看懂这条链，才能理解为什么 Fleet 的关键不是“存了多少字段”，而是系统如何让车辆记录持续保持可运营。
Odoo IoT 为什么不只是“设备连上就行”：标识、动作路由与远程连接令牌链路讲透
很多人以为 Odoo IoT 的核心只是发现设备并发出动作，但从 iot_base 的 longpolling.js、device_controller.js 与 iot_drivers 的 websocket_client.py、helpers.py 看，真正撑起系统的是 identifier、device_identifier、路由端点和远程令牌管理。看懂这条链，IoT 才不会停留在“偶尔能连上”。
Odoo 维修工单为什么不只是“拖看板”：阶段完成、关闭日期与活动重排闭环讲透
很多人以为 Odoo Maintenance 的核心只是建单和分派，但从 maintenance.py 的 write、activity_update、_get_activity_note 和 archive/reset 逻辑看，工单真正难的是阶段变化后，close_date、kanban_state、待办活动与归档状态如何一起收口。看懂这个闭环，维护看板才不会表面流转、底层混乱。
Odoo IoT 配对为什么不只是“扫个码”：pairing code、session 事件、设备发现与 driver 生命周期讲透
很多人第一次接触 Odoo IoT 只看到配对码界面，但 connection_manager、event_manager、interface 和 driver 源码说明，它真正难的是“盒子如何被数据库接管、设备如何被发现、动作如何防重并回流事件”。看懂这条链，IoT 才不会停留在表面连通性。
Odoo 午餐为什么不只是“内部点餐”：供应商日历、自动发单 Cron、地点可用性与提醒广播讲透
很多人把 Odoo Lunch 看成办公室小福利，但源码里的 supplier、cron、location、alert 和 cashmove 说明它其实是一套“受时间与地点约束的内部订餐系统”。看懂这条链，午餐模块才不会被误用成一个简化商城。
Odoo IoT 为什么不只是“连上打印机”：Longpolling、WebSocket 与设备驱动分发链路讲透
很多人以为 Odoo IoT 就是把打印机或扫码枪接进系统，但源码里的 longpolling、websocket_client 和 interface 说明它其实是一条双向设备控制链。看懂这条链，才能真正理解 Odoo 为什么能把前端动作落到现场硬件上。