Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Survey + Spreadsheet 为什么不是“导出问卷结果”而已：列展开、评论拆列与日期格式管线讲透
基于 documents_spreadsheet_survey 源码与测试，讲清问卷结果进入电子表格时为什么要按题型展开列、把 comments 单独拆列，并把 datetime/date 转成 spreadsheet number 与 locale format。
Odoo 企业版 Marketing Automation + WhatsApp 为什么不是“流程里多一个消息节点”而已：trigger 取消、trace 继承与点击统计讲透
基于 marketing_automation_whatsapp 源码与测试，讲清 WhatsApp 活动如何把 read/reply/click/bounce 事件映射到 marketing trace，并在父消息发生后主动取消不再成立的子触发。
Odoo 企业版把电子表格文档加入 Dashboard 时，真正发生的不是“复制一份”：快照冻结、评论迁移、权限组重挂与归档边界讲透
很多人以为 Odoo 企业版里把 Documents 里的 spreadsheet 加进 Dashboard，只是“把同一份表再显示一次”。但 `spreadsheet_dashboard_documents` 源码和测试说明，官方实现的是一次受控交接：先保存快照，再以 dashboard section 和 access groups 新建仪表板，把单元格评论线程从 document 侧改挂到 dashboard 侧，清空 JSON 里的 comments，并把原文档归档。
Odoo 营销卡为什么不只是“生成一张图”：UTM、跳转链接与落地页转化闭环讲透
很多人看到 marketing_card，第一反应是“可以批量做社媒海报”。但源码真正有价值的地方，是 campaign 在创建时就绑定 link.tracker、自动挂 UTM 来源、每张 card 都有独立 preview/redirect 路径，还能把 shared 与 visited 汇总回 campaign。它做的是一条从素材到落地页的可追踪链路。
Odoo 午餐提醒为什么不只是“发个通知”：定时任务、收件人圈选与地点定向链路讲透
很多人只注意 Odoo Lunch 的下单逻辑，却忽略了 lunch.alert 才是真正连接运营节奏和员工触达的那层能力。源码里它把时区换算、动态 cron、订餐地点过滤、最近下单人群筛选和消息投递收成了一条精细化提醒链。
Odoo IoT 为什么不只是“设备连上就行”：标识、动作路由与远程连接令牌链路讲透
很多人以为 Odoo IoT 的核心只是发现设备并发出动作，但从 iot_base 的 longpolling.js、device_controller.js 与 iot_drivers 的 websocket_client.py、helpers.py 看，真正撑起系统的是 identifier、device_identifier、路由端点和远程令牌管理。看懂这条链，IoT 才不会停留在“偶尔能连上”。