Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 问卷为什么不只是“答题交卷”：评分、证书、限次与 Live Session 边界讲透
很多人把 Odoo Survey 当成普通表单，但源码里的 survey.user_input 把答题记录、计分、证书发放、尝试次数和直播答题一起收进了一条统一主链。看懂这些边界，做考试、认证和活动互动时才不会把规则配乱。
Odoo 活动展位为什么不只是“租个摊位”：展位状态、赞助商生成与参展商资料同步链路讲透
很多人以为 Odoo 的 booth 只是活动现场的一块位置，但源码显示它其实把展位可售状态、租户联系人、赞助商档案和活动消息流连在一起。看懂这条链，活动招商、官网展示与现场执行才不会各做各的。
Odoo 午餐为什么不只是“下个外卖单”：合单、钱包余额、加料约束与订餐截止时间链路讲透
Odoo Lunch 看起来轻量，但源码里其实塞进了不少运营细节：同款订单自动合并、余额不足不让继续加、供应商截止时间控制、配料数量校验，全都在守一件事——让公司内部订餐既顺手又不失控。
Odoo 设备维护为什么不只是“提个工单”：MTBF、MTTR、下一次故障预测与设备责任边界讲透
很多人把 Odoo Maintenance 当成简化版 Helpdesk，但源码显示它真正盯的是“设备全生命周期可维护性”。看懂 maintenance.mixin 之后，你会知道维护请求、设备台账、技师归属和 MTBF/MTTR 预测为什么会被放在同一套模型里。
Odoo 活动报名为什么不是“填个名单就完了”：slot、ticket、参会人资料同步与席位校验链路讲透
很多人以为 Odoo 活动报名只是收集姓名和邮箱，但 event.registration 实际把场次、票种、联系人同步、条码签到和席位校验串成了一条完整业务链。看懂这条链，活动运营才不会在报名扩容和现场签到时翻车。
Odoo 企业版 ESG 为什么不是“填几个碳排数字”：CSRD 指标采集、证据工作流与冻结控制讲透
基于 esg 源码与测试，讲清排放因子、分配规则、报表审计入口与冻结式治理为什么共同决定了 ESG 数据能不能用于 CSRD 级披露。