Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo Karma 变化为什么不能只改一个数字：old/new、来源追踪与月度 consolidation 讲透
Karma 看上去只是用户身上的一个整数，但 Odoo 额外维护了 old_value、new_value、gain、origin_ref 与 consolidation 逻辑，说明它更在意“这分数怎么来的”而不是“现在是多少”。
Odoo Gamification Challenge 为什么不是“建个排行榜就结束”：周期起止、目标生成、进度播报与奖励发放讲透
很多人把 Challenge 看成一个排行榜界面，但从周期计算、目标批量生成、进度播报到结束后发奖的源码链路看，它更像一台反复运转的目标分发机。
Odoo Digest 为什么不能只给用户一个“退订”按钮：one-click、slowdown 与偏好入口链路讲透
很多人以为 Digest 只要能发出去和能退订就够了，但源码其实把 one-click 退订、低活跃用户自动降频和偏好入口一起设计成了同一条“反骚扰”链路。
Odoo 企业版 Documents + Fleet 为什么不是“车辆上挂附件”而已：集中 folder、owner 策略与访问传播边界讲透
基于 documents_fleet 源码与测试，讲清车辆文档为什么集中进公司级 folder、默认 owner 为当前用户、访问链接默认关闭，以及 company 设置关闭后为何不再自动建文档。
Odoo 企业版 Survey + Spreadsheet 为什么不是“导出问卷结果”而已：列展开、评论拆列与日期格式管线讲透
基于 documents_spreadsheet_survey 源码与测试，讲清问卷结果进入电子表格时为什么要按题型展开列、把 comments 单独拆列，并把 datetime/date 转成 spreadsheet number 与 locale format。
Odoo 企业版 Social 为什么不是“统一发社媒内容”而已：UTM、live post 与多公司访问边界讲透
Social 模块处理的不是一个群发器，而是一套跨账号、跨公司、跨媒介的内容与归因体系：发帖时要生成 UTM，发出后要拉 live statistics，多公司下还要保证谁能看、谁能发、谁能接账号。