Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
Odoo 活动提醒为什么不会对所有报名人同时轰炸：event.mail、cron 分批与 slot 定时链路讲透
很多人以为 Odoo 的活动邮件就是“设个模板，到点群发”。但 event.mail、event.mail.registration、event.mail.slot 和 event_mail_scheduler 实际拼出了一条会分模式、分场次、分批次、可续跑的调度链。看懂它，活动提醒才不会发早、发漏或一次打爆系统。
Odoo 活动问卷为什么不是把答案贴在报名表上：event.question、registration.answer 与 once_per_order 边界讲透
很多人以为 Odoo 活动问卷只是给报名表多加几个字段。实际上，event.question、event.question.answer、event.registration.answer 和事件上的 general / specific questions 共同组成了一套独立的数据模型。看懂它，才能理解为什么有些问题按订单问一次，有些问题却要对每个参会人分别作答。
Odoo 地址自动定位到底做了什么：base_geolocalize 的经纬度补全、服务调用与失败回退讲透
结合 base_geolocalize 源码，讲清 Odoo 如何把联系人地址组装成查询字符串、如何选择 OpenStreetMap 或 Google、为什么地址一改就清空旧坐标，以及失败时为什么只发提醒不强写坐标。
Odoo 企业版通知栈为什么不是“浏览器一弹就行”：permission、worker、VAPID 心智与 opt-out 状态机讲透
这篇从企业协同通知栈角度，结合 web service worker、浏览器通知权限与移动/消息补链，讲清 Web Push 为什么本质上是一套状态机。
Odoo 展位销售为什么不是“卖一个 Booth 产品”就完事：预留、确认、抢占冲突与付款落定链路讲透
Odoo 的 Event Booth Sale 看起来像是在销售订单里卖一个服务产品，但源码实际上把“想要某个展位”“确认拿到某个展位”“付款后正式落定”拆成了多层状态。本文沿着 sale.order.line、event.booth.registration、sale.order 和 account.move 把这条链路拆开讲清。