Odoo 客户现场上门维修应该怎么落地:Helpdesk、Field Service、Repair 与 Inventory 的业务分工
很多团队把上门维修理解成一张 repair order,但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界,给出一套更稳的落地蓝图。
TOPIC PICKS
很多团队把上门维修理解成一张 repair order,但客户现场维修真正要承接的是报修受理、派工、现场处理、配件消耗、返厂分流与收费闭环。本文结合 Odoo 标准模块与源码边界,给出一套更稳的落地蓝图。
可以顺着继续读的相邻方向
从网站文档可见性、public/portal 路由到 token 成员校验,讲清文件上传与分享前端为什么必须连着权限模型一起设计。
从帮助中心搜索、知识库建议到 livechat 创建 ticket,讲清网站入口、知识内容与客服工单前端如何串成一体。
从网站结账、销售确认到发票过账重复计算,讲清外部税为什么必须在多个业务节点重放同一份上下文。
从 website visitor、reveal view、IAP enrich 到 CRM 归属规则,讲清访客识别为什么要经过采集、去重、分配三段接力。
从预约 booking、发票/支付到销售行创建 task,讲清网站、支付、销售与项目如何把一次预约变成可执行任务。
很多团队把网站预约理解成“选个时间 + 选个资源”这么简单;但企业版 Appointment 真正解决的是容量组合、linked resource 联动、前台人数上限与提交瞬间 booking line 分摊的一致性。本文从 `_slots_fill_resources_availability()`、`_slot_availability_select_best_resources()` 到 `appointment_form_submit()` 把这条链路讲透。