Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版在线银行同步为什么不是“定时拉流水”而已：journal link、transaction dedup 与 reminder cron
account_online_synchronization 真正处理的是银行连接生命周期：怎样把线上账户指派到正确 journal，怎样过滤重复交易，拉取失败或授权将过期时又怎样通过
Odoo 企业版 Grid 为什么不是“把 pivot 做成可编辑表格”：inline cell update、domain/context 与虚拟网格边界讲透
web_grid 的难点不在表格，而在单元格既要代表聚合口径，又要承载可编辑语义；domain、context、分页和虚拟渲染都因此变复杂。
Odoo 企业版预约转线索为什么不是“客户约了会就建一条 lead”而已：partner 识别、opportunity 关联与 multi-company
appointment_crm 真正补的是预约与 CRM 的身份桥：同一个预约人该挂到哪个 partner、什么时候创建新 lead、什么时候绑定已有
Odoo 企业版工资单发文档为什么不是“生成 PDF 后发邮件”这么简单：链接权限、Worker Payroll Folder、声明队列与 Documents 归档边界讲透
很多人以为 Odoo 企业版 payroll 接 Documents，只是工资单出 PDF、发封邮件这么简单。源码真正实现的是一套把工资单和申报声明安全落到 Documents 的机制：已验证/已支付工资单才允许发送、文档默认走“Anyone with the link”但内部不可见、员工有账号时进个人空间、没有账号时落 Worker Payroll Folder，声明文档还会经过 pdf_to_post 队列与 cron 异步投递，避免把 payroll 文档误做成普通内部附件。
Odoo 企业版 CRM 去重为什么不是“重复线索选一条保留”而已：master election、merge method 与历史消息边界讲透
data_merge_crm 的核心不是删掉重复 lead，而是如何选主记录、如何把 source 合并进 destination，以及哪些历史信息该迁、哪些不能乱拼。
Odoo 企业版供应商发票 OCR 为什么不是“识别到单号就自动匹配采购单”而已：regex、supplier+total 与 subset of lines
account_invoice_extract_purchase 解决的是 OCR 与采购单匹配的容错问题：单靠发票号未必准，所以还要看供应商、总额，甚至允许识别到部分采购行形成