Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 活动报名为什么不是“填个名单就完了”：slot、ticket、参会人资料同步与席位校验链路讲透
很多人以为 Odoo 活动报名只是收集姓名和邮箱，但 event.registration 实际把场次、票种、联系人同步、条码签到和席位校验串成了一条完整业务链。看懂这条链，活动运营才不会在报名扩容和现场签到时翻车。
Odoo 企业版 ESG 为什么不是“填几个碳排数字”：CSRD 指标采集、证据工作流与冻结控制讲透
基于 esg 源码与测试，讲清排放因子、分配规则、报表审计入口与冻结式治理为什么共同决定了 ESG 数据能不能用于 CSRD 级披露。
Odoo 活动售票为什么不能只看“有人下单了”：销售订单、参会人状态与 UTM 归因联动讲透
很多人以为 Odoo Event 接上 Sales 之后，只是多了一个卖票入口。但从 event_sale 模块里的 sale.order、sale.order.line 和 event.registration 代码看，真正关键的是“订单状态如何驱动参会人状态、票种与场次如何回写报名、UTM 如何继承到参会记录”。这条链看懂了，活动营收和报名运营才不会各算各的。
Odoo 问卷为什么把“页面”和“问题”放进同一模型：随机抽题、触发显示与答题次数边界讲透
Odoo Survey 最容易让人看不懂的，不是题型本身，而是为什么页面和问题都叫 survey.question，以及一次答卷为什么还要额外建 survey.user_input。沿着这两层模型看，才能真正理解随机抽题、显示逻辑与答题次数限制。
Odoo 企业版营销自动化短信为什么不是“流程里加一个 SMS 节点”：trace 状态、失败回写与 trigger 重排讲透
基于 marketing_automation_sms 源码，讲清 SMS 节点为什么要和 marketing trace、bounce 事件与未点击重排逻辑一起理解。
Odoo 企业版 Social Push 为什么不是“给网站访客群发通知”：timezone 分批、Firebase fallback 与 token 清理讲透
基于 social_push_notifications 源码，讲清网页推送如何按访客时区过滤、走 Firebase/IAP fallback，并在发送后清理失效 token。