Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版电子表格修订为什么不是“存一份最新 JSON 就好”：revision UUID 链、唯一约束与清理边界讲透
spreadsheet_revision 的设计重点不是存内容，而是用 revision UUID、父子链和唯一约束保护协作顺序，再配合清理策略控制历史膨胀。
Odoo 企业版 Studio 为什么不是“前台改改界面就行”而已：xmlid、view cache 与按钮审批 guardrails 讲透
Studio 真正难的地方不是拖拽，而是拖拽之后这些改动如何变成可持久化、可导出、可缓存、可审计的系统配置。企业版 web_studio 在 xmlid、视图缓存、模型元数据和审批按钮上都做了不少防呆。
Odoo 企业版 AI 建线索为什么不是“让模型随便写一条 CRM lead”而已：available params、public/portal 权限与
ai_crm 并不是给大模型一个 create lead 的任意写权限。它先暴露可用参数，再走受控工具创建流程，并且在 portal 场景明确禁止把已有值随便覆盖，确保
Odoo 企业版 Documents + Accounting 为什么不是“把发票扔进文件夹再点建账单”：Journal Folder Sync、XML 内嵌 PDF 与附件回写边界讲透
很多人把 Odoo 企业版 Documents + Accounting 理解成“在文档里存附件，然后手动生成一张 Vendor Bill”。但从 `documents_account` 源码看，官方真正设计的是一套会计文档编排层：按 Journal 自动建同步文件夹与标签、把可用动作嵌进 Finance 树、从附件创建单据后再持续回写文档位置与业务伙伴，并对 XML 发票里的内嵌 PDF 做预览兼容。
Odoo 企业版 POS 顾客取餐屏为什么不是“厨房看板镜像”而已：stage 同步、消息推送与 open customer display 边界讲透
很多人把顾客取餐屏理解成 preparation display 的只读副本。但 pos_order_tracking_display 实际上重建了一条“可对外展示”的订单状态流：从
Odoo 企业版 POS 预约为什么不是“收银台代客人约个时间”而已：waiting list、电话透传与 booking 视图链路讲透
企业版 pos_appointment 并不是简单把 appointment 放进 POS 菜单里。它把预约资源、waiting list 容量、客户电话与后台