Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Lazada 发货为什么不是“打印面单就算出库”：pack、shipping label 与 RTS 状态回跳讲透
sale_lazada 把发货拆成打包、下载面单、设为 Ready to Ship 三段，package_extern_id、label 和平台状态彼此约束，不能一步跳过。
Odoo 企业版 Amazon 履约为什么不是“订单进来、发货出去就完了”：sale line 完成度、承运商合规与 feed 回执链讲透
sale_amazon 会在 stock.picking 进入同步前先校验销售行是否完整发出、承运商与 tracking 是否合规，再把发货交给 Amazon feed；履约不是单一 done 动作。
Odoo 企业版 POS 自助点餐为什么不是“只要开 kiosk 就能刷卡”：kitchen printer 选择、IoT box 能力与 self payment method 校验讲透
pos_self_order_iot 在 kiosk 模式下要同时确认 kitchen printer、IoT box 是否能当 kiosk，以及 payment method 是否具备自助支付能力；少一层都不该放行。
Odoo 企业版 POS IoT 为什么不是“发现设备就能直接收银”：box 关联、device 投影与 session 加载边界讲透
pos_iot 把 IoT 设备拆成 box 归属、device 归属和 session 前台投影三层；设备被发现不等于就进入当前 POS 的可用设备集合。
Odoo 企业版 POS 餐厅预约为什么不是“到店就占桌”：calendar event、table 通知与 resource 释放边界讲透
pos_restaurant_appointment 用 calendar.event 的 create/write/unlink 驱动桌台占用通知；预约对餐桌的影响不是静态读表，而是当天事件流里的增删广播。
Odoo 企业版 POS 餐桌配置为什么不是“删一张桌子就结束”：restaurant table、appointment resource 与 linked cleanup 链路讲透
pos_restaurant_appointment 把餐桌和 appointment.resource 双向绑住；桌台创建、停用、删除都会影响前台预约资源加载，不是纯 UI 配置动作。