Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版招聘到签署到员工入职，为什么不是“候选人签完合同就结束”
从 applicant、sign request 到 employee/version 的对象迁移，讲清 offer 发起、签署留痕与入职继承为什么要拆层。
Odoo 企业版工单到质检到 IoT 过站，为什么不是“扫码后做个质量检查”
从工单质检、worksheet 到 IoT 设备读数/拍照回写，讲清制造现场为什么要把动作、测量值与过站状态拆成多级接力。
Odoo 企业版排班到考勤到工资工时，为什么不是“班表转成出勤就完了”
从 planning.slot、hr.attendance 到 work entry 与 payslip 的状态接力，讲清排班合同、加班口径与工资取数为什么必须分层。
Odoo 企业版 Mobile Push 为什么不是“开了推送就行”：@mention 分流、4KB payload 与深链回退链路讲透
基于 mail_mobile 源码，讲清 Odoo 企业版移动推送如何先做设备注册，再按 @mention 与普通消息拆分投递，并在 4KB payload、Discuss 会话 subject 重写与 Firebase dynamic link 回退之间维持可点开的移动通知体验。
Odoo 企业版 Knowledge 门户为什么不是“发个邀请链接就能看文档”：invite 注册、member-only 可见性与 share user 跳转边界讲透
很多人以为 Odoo 企业版 Knowledge 对外协作只需要生成一条邀请链接；但标准实现真正处理的是成员邀请注册、share user 的前后台分流、member-only 可见性与 root article 继承。本文从 `article_invite()`、`_redirect_to_portal_view()`、`_compute_user_permission()` 与 `_compute_is_article_visible()` 把这条门户权限链讲透。
Odoo 企业版贷款为什么不是“导个摊销表就完了”：计算向导、Skip Until 与提前关闭边界讲透
基于 account_loans，讲清贷款从计算、导入、跳过历史分录到提前关闭时，Odoo 如何保持余额、期间与自动分录的一致性。