Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版租赁为什么不是“开始日期 + 结束日期 = 一个价格”而已：pricing rule、overnight period 与 late
企业版 sale_renting 真正困难的地方不是租出去，而是如何把时长、夜间计费、延迟归还、部分取还货和价格更新规则统一成一套可解释的租赁语义。
Odoo 企业版可排班服务销售为什么不是“确认订单后生成几个班次”而已：role 匹配、hours_to_plan 与 unassign deadline
sale_planning 处理的是服务销售和排班系统之间的契约：什么产品能计划、按什么 role 找人、已售工时如何拆成 slot、何时还能取消或回收未分配班次。
Odoo 企业版销售提成为什么不是“按订单金额乘系数”而已：plan 区间、target 保留与多币种 achievement 边界讲透
企业版 sale_commission 处理的不是一个简单公式，而是一整套计划管理：计划周期拉长或缩短时 target 怎么保留、不同销售或经理视角下
Odoo 企业版餐饮后厨屏为什么不是“出单即显示”那么简单：merge/unmerge、course 与通知回流链路讲透
餐饮场景里的 preparation display 远不只是把 POS 订单贴到电视上。企业版 pos_restaurant_preparation_display
Odoo 企业版库存条码入口为什么不是“扫到什么就开哪个页面”：product/package/lot fallback 与主菜单路由边界讲透
stock_barcode 的主菜单扫描链路真正难点，不在识别出一个条码，而在 GS1、别名规则、库位权限与 picking/product/package/lot 多路路由之间如何稳定落到正确动作。
Odoo 企业版 Account Follow-up 为什么不是“逾期就催”而已：next action date、no followup 与负责人选派边界讲透
很多人把 Odoo 企业版催款理解成“发封提醒邮件”。真正看 account_followup 源码会发现，官方做的是一套客户级催收状态机：先按逾期与 level 算出 followup_line，再结合 next_action_date、no_followup、责任人分配和 activity 创建，决定今天到底该不该催、催到哪一级、由谁跟。