Odoo 客户现场上门维修应该怎么落地:Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order,但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界,给出一套更稳的落地蓝图。
TOPIC PICKS
很多团队把上门维修理解成一张 repair order,但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界,给出一套更稳的落地蓝图。
可以顺着继续读的相邻方向
真正决定群发系统是否稳定的,不是编辑器,而是发送前如何排除 opt-out、如何避免重复触达、如何用队列推进,以及失败后怎么重试。Odoo 在 mailing.py 里把这些都做成了明确链路。
Odoo 把 mailing.contact 和 mailing.list 之间专门拆出 mailing.subscription,并额外记录 opt_out_reason、opt_out_datetime 和 default_list_ids 上下文同步,这说明它把名单关系当成业务对象,而不是一个普通 many2many。
Mail Plugin 在联系人侧真正复杂的,不是“有没有搜到人”,而是它会不会按邮箱域名复用公司、何时调用 IAP 富化、没权限时返回什么,以及通知邮箱这类特殊地址怎么处理。
很多人把 Odoo Event 的公开入口理解成“活动详情页 + 报名按钮”,但 event_event.py 和 event/controllers/main.py 实际还提供了两种很不同的入口:一种把活动包装成 ICS 日历文件带出站外,一种把现场接待切到 registration desk kiosk。理解这两条入口链,才知道活动系统并不只服务报名页面。
很多人以为 Odoo Survey 的结果页只是把答案数量数一遍再画图,但从 survey_question.py 与 survey_user_input.py 看,后台其实按题型走了多条统计管线:choice、matrix、scale、numerical 各有不同表格和图表结构,scored 问题还会额外计算正确率、partial 与常见答案。理解这层,你才知道为什么“每道题的统计长得不一样”并不是前端花活,而是模型设计本身。
基于 documents_fleet 源码与测试,讲清车辆文档为什么集中进公司级 folder、默认 owner 为当前用户、访问链接默认关闭,以及 company 设置关闭后为何不再自动建文档。