Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
Odoo 企业版网站 Helpdesk 售后补偿为什么不是“客服发一封优惠券邮件”：ticket 发券、share link 与 loyalty card 回链讲透
很多团队把售后补偿理解成“客服在工单里发张券给客户”；但企业版 Helpdesk + Loyalty 真正做的是工单发券、邮件发送、网站分享链接、coupon/gift card 分流以及 loyalty card 与 ticket 的双向留痕。本文从 `action_coupon_generate_send()`、`action_coupon_generate_share()`、`generate_giftcard()` 与 `open_coupons()` 把这条链路讲透。
Odoo 企业版通知栈为什么不是“浏览器一弹就行”：permission、worker、VAPID 心智与 opt-out 状态机讲透
这篇从企业协同通知栈角度，结合 web service worker、浏览器通知权限与移动/消息补链，讲清 Web Push 为什么本质上是一套状态机。
Odoo 企业版网站订阅为什么不是“电商也能卖 recurring product”而已：plan 选择、one-time mixing 与地址税务边界讲透
website_sale_subscription 真正处理的是电商购物车边界：订阅计划怎样进入 combination info，同一购物车里
Odoo 企业版绩效评估为什么不是“定期发个评价表”而已：request flow、goal ratio 与 next appraisal date
hr_appraisal 管的不只是一次打分，而是员工、经理、目标与下次评估周期之间的长期关系：谁能发起请求、目标完成率如何汇总、下一次 appraisal
Odoo 企业版 Website Appointment 为什么不是“放个预约页”而已：发布态、操作员选择与 visitor fallback 边界讲透
很多人把 Odoo 企业版网站预约理解成“把 appointment.type 暴露到前台”。真正看 website_appointment 源码会发现，官方处理的是一整套网站语义：预约类型既是 appointment 对象，又是 website 发布内容；前台有操作员/资源选择分流；公开访客没有账号时，还会用 website visitor 兜底时区、国家与客户识别。