Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Intrastat 为什么不是“发票金额汇总”那么简单：国家、交易代码、原产国与报表分组边界讲透
很多人第一次看 Odoo 企业版 Intrastat，会以为它只是把欧盟往来发票按期间加总。可真正决定报表结果的，不只是金额，还有销售看收货国、采购看往来方国家、行上交易代码默认值、产品原产国、补充计量单位，以及一整套分组键与校验规则。源码里它本质上是一条“发票字段 → 行字段 → 报表分组 → return checks”的链路。
Odoo 企业版 AI 文档源为什么不直接吃原附件：checksum 扇出重建、跨 Agent 重索引与访问边界讲透
很多人以为把 Documents 里的文件加进 AI Agent，只是“拿原附件做个向量索引”。但从 `ai_documents_source` 源码看，Odoo 企业版真正关心的是文档源和原文档的生命周期解耦、同内容多 Agent 的 checksum 复用、文档更新后的批量重建、以及访问权限始终回到 Documents 自身。
Odoo 企业版 Documents + Sign 为什么不是“签完生成个 PDF”而已：folder 继承、reference_doc 路由与 no_document 防重复讲透
很多人把企业版 Documents 与 Sign 的集成理解成“从文档里发起签署，签完把 PDF 丢回文件夹”。但从 `documents_sign` 源码看，官方真正解决的是附件所有权迁移、签署请求如何绑定原文档或文件夹、完成件生成与邮件发送为何要区分 `no_document`、以及签署人/发起人如何自动获得受控访问权。
Odoo 企业版排班为什么不会“机械复制”：重复班次变成 Open Shift 的真实逻辑
很多人以为 Odoo Planning 里的重复班次就是把上一班原样复制到未来，但企业版源码做得更谨慎：只要落到非工作日、超出工作时段、叠加后超配，或者碰到合同边界，系统就可能保留班次却取消员工指派，把它变成 open shift。
Odoo 企业版租赁排班为什么不是“改一下 shift 时间”而已：slot 改期、sale order 回写与资源重指派讲透
sale_renting_planning 把 planning.slot 和 rental sale order 做成双向回写：改排班会推回租期，改租期也会推回 slots，并在资源缺失时重新分配。
Odoo 企业版排班打卡为什么不能各算各的：Planning、Attendance 与 Payroll work entry 优先级讲透
基于 hr_work_entry_planning_attendance、planning_attendance 与 hr_payroll_attendance 源码，讲清排班、打卡和工资工时怎样在同一条 work entry 链上消解冲突。