Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 活动模板为什么不只是“复制一场活动”：邮件计划、问题继承与已报名数据保护链路讲透
很多人以为 Odoo Event Type 只是建活动时的快捷模板，但从 event_event.py 里的 _compute_event_mail_ids、_compute_question_ids 和 ticket 同步逻辑看，它其实承担了“继承默认值，同时保护历史报名数据”的配置中台角色。看懂这一层，活动模板才不会越用越乱。
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 预防性维护为什么不是“到期再建单”：重复计划、团队分派、活动提醒与完工续生链路讲透
很多人以为 Odoo Maintenance 的预防性维护只是定期生成工单，但源码里的 recurring_maintenance、activity_update、team/user 计算与 done 阶段 copy 逻辑说明，它其实是一条会自我续生的维护计划链。看懂这条链，设备维护才能真正跑起来。
Odoo 车队为什么不只是“记谁开哪辆车”：司机历史、服务日志、里程读数与待办信号讲透
很多人把 Odoo Fleet 当成车辆台账，但源码里的 assignation log、service log、odometer 和 service_activity 说明它其实在做“车辆运营状态聚合”。看懂这条链，你才知道车队管理为什么不是简单登记车辆和司机。
Odoo 活动议程为什么不只是“排个演讲表”：议题提案、阶段可见性、收藏提醒与前台议程链路讲透
很多人以为 Odoo 的活动议程只是把演讲排进时间表，但 event.track 实际把议题提案、讲师资料、前台可见阶段、收藏提醒和 agenda 渲染连成了一条完整链路。看懂这条链，活动内容运营才不会在征稿、排期和现场提醒上反复返工。