Odoo 客户现场上门维修应该怎么落地：Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order，但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界，给出一套更稳的落地蓝图。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版销售：订阅续费时，关闭旧周期、生成新发票与门户自助续订如何保持同一条状态线
sale_subscription 的续费不是只生成一张 renewal quotation；旧合同的 next_invoice_date、child renewal、portal 交易、token 绑定和付款成功后的 reopen / in-progress 状态，都必须落在同一条合同语义线上。
Odoo 企业版预约 WhatsApp 提醒为什么不能只靠群发：Appointment、Calendar 与 WhatsApp attendee 上下文讲透
基于 whatsapp_calendar、appointment 与 whatsapp 源码，讲清预约提醒、改期后通知与 attendee 责任人选择怎样共享日程上下文。
Odoo 企业版 POS：并桌、拆单和补推备餐时，准备屏与顾客号牌为什么还能维持同一笔订单连续性
pos_restaurant_preparation_display 通过 prep_order、line uuid 和 notify_pdis 维持内部备餐对象；而顾客侧仍靠 tracking/order 投影读进度，所以 merge/unmerge 后看起来是“一单还在走”，其实背后对象已经重绑。
Odoo 企业版文档发起签署为什么不是“上传 PDF 点发送”：Documents、Sign 与完成文件权限链路讲透
基于 documents_sign、sign.template 与 sign.request 源码，讲清 Documents 中的 PDF 如何变成签署模板、回写 folder/tag，并在完成后补权限。
Odoo 企业版 POS：赊账补款时，旧应收、当前付款和关班分录如何重新对齐
pos_settle_due 的重点从来不是做一笔“补收订单”，而是把 partner 总欠款、发票未结清金额、当班 pay_later 分录与 session closing 的核销重新归到同一口径。
Odoo 企业版预约短信为什么不是“发个提醒”而已：预约、短信与日历跟进链路讲透
基于 appointment_sms、appointment 与 calendar_sms 源码，讲清预约 slot 确认、手机号采集与短信提醒如何沿着日历事件上下文闭环。