Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版绩效评估为什么不是“定期发个评价表”而已：request flow、goal ratio 与 next appraisal date
hr_appraisal 管的不只是一次打分，而是员工、经理、目标与下次评估周期之间的长期关系：谁能发起请求、目标完成率如何汇总、下一次 appraisal
Odoo 企业版 POS 结清客户欠款为什么不是“前台补收一笔钱”而已：special products、总欠款口径与分客户对账链路讲透
很多团队以为 POS 里的 settle due 只是把客户未结款项再收一次。但企业版 pos_settle_due 真正补的是一条受控结算链：前台先按
Odoo 企业版 Approvals 为什么不是“点同意/拒绝”而已：顺序审批、最低人数、必审人与活动队列边界讲透
很多人把 Odoo 企业版 Approvals 看成一个很轻的审批按钮系统。源码里真正重要的不是按钮，而是“最低审批人数 + 必审人 + 顺序审批 + mail.activity 队列”四层约束如何一起决定请求何时进入 approved、refused 或 waiting。
Odoo 企业版知识库为什么不是“勾上网站发布就完了”：公开子树、发布传播与侧边栏可见性边界讲透
很多人以为企业版 website_knowledge 只是给 Knowledge 多一个前台页面。但从 models、controller 和测试一起看，官方真正做的是一套“公开子树”机制：发布状态会向后代传播、公开访问按根祖先裁剪、侧边栏只展示可达节点，连 summary / OG / Twitter 元信息都按前台阅读场景重新计算。
Odoo 企业版 Documents 分享链接为什么不是“有个 URL 就都能看”：token、文件夹权限与上传边界讲透
很多人把 Odoo Documents 的外链分享理解成“生成一个 access URL”。但从 documents_document.py 和分享模板看，真正决定外部人能看什么、能不能上传、能否继续深入子文件夹的，是 token、user_permission、access_via_link、父文件夹权限和 owner 规则叠加出来的一套边界。本文把这套机制拆开讲清。
Odoo 企业版订阅伙伴关系为什么不是“关单就停权益”：cancel、renew 与 grade/pricelist 回写链讲透
sale_subscription_partnership 在订阅取消、关闭、续费、重开时会联动 commercial partner 的 grade 与 pricelist；权益边界不由 subscription_state 单独决定。