Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 采购预算为什么“收货了还占预算”：account_budget_purchase 里 committed / achieved 与未开票余额链路讲透
很多人在 Odoo 企业版里启用采购预算后，会以为收货一完成，预算占用就该立刻减少。可 `account_budget_purchase` 的真实设计并不是“按收货释放预算”，而是把确认采购单、已过账账单、未开票余额拆成三层口径。本文从 `budget.line`、`budget.report`、`purchase.order.line` 源码出发，把 committed / achieved 的切换时机讲透。
Odoo 企业版 Knowledge 为什么不是“父文章一改权限全树跟着变”而已：desync 脱同步、成员继承与最后一名 writer 约束讲透
很多人把 Odoo 企业版 Knowledge 的权限理解成“根文章设 read/write/none，子文章原样继承”。但 `knowledge` 源码真正做的是一套可局部脱同步的权限树：子节点可以在降权时复制父级成员后切断继承，根/子节点还始终要满足至少一名 writer，移动到 private/shared 时也会重建权限边界。
Odoo 企业版 POS 卖订阅为什么不是“收完钱就结束”：qty_invoiced 回写与 next_invoice_date 推进讲透
很多人以为把订阅产品放进 POS，无非就是门店也能卖一笔 recurring product。但从企业版 pos_sale_subscription 源码看，官方真正补的是两条缺一不可的桥：一条把 POS 成交数量并回 subscription 的 qty_invoiced 口径，另一条在订单真正 paid 后推进 sale.order 的 next_invoice_date。少了任意一条，订阅既会“卖了像没卖”，也会“账期像没走”。
Odoo 企业版项目里的 Assets 按钮为什么不是“项目挂了固定资产”那么简单：analytic distribution、统计按钮与折旧归集链路讲透
很多人第一次看到 Odoo 企业版项目表单上的 Assets 统计按钮，会以为项目模型自己挂了一套固定资产关系。可 `project_account_asset` 源码恰好说明，官方根本没做“项目资产子表”，而是借 `analytic_distribution` 把资产、折旧与项目分析账户轻量桥接起来。本文把计数、打开动作、默认分摊与会计权限边界一次讲清。
Odoo 企业版批量付款为什么会出现“总额没变、未结清变少、状态还在 sent”：`account_batch_payment` 金额与状态链路讲透
很多人第一次用 Odoo 企业版批量付款，会困惑同一批 payment 明明总额没变，batch 的 residual 却会下降，甚至状态会从 draft 变 sent、再变 reconciled。源码里这不是显示问题，而是 `amount`、`amount_residual(_currency)` 与 `state` 分别回答三件不同的事：批次规模、剩余未核销金额，以及是否已发送并完成匹配。
Odoo 网站 Helpdesk Livechat 为什么不是“聊完自动建单”这么简单：chatbot 建单步骤、访客补全与会话落单边界讲透
很多人以为 Odoo 网站在线客服里的“自动建单”只是 chatbot 最后加一个 create ticket 步骤。但企业版 website_helpdesk_livechat 源码真正做的是三层约束：脚本顺序先收邮箱、步骤上强制绑定 helpdesk team、建单时再把访客资料与整段会话历史一起写进 ticket，并把来源追到 livechat channel 与 chatbot source。