Odoo 预防性维护为什么不是“到期再建单”：重复计划、团队分派、活动提醒与完工续生链路讲透

先说结论

Odoo 的预防性维护，不是简单地“给设备设个周期，到点生成一张单”。

从 /home/ubuntu/odoo-temp/addons/maintenance/models/maintenance.py 看，官方把这条链拆成了几层：

• 设备和分类先定义默认责任边界
• 请求单承接排期、技师、团队和活动提醒
• 预防性维护在完工时自动复制出下一张单
• done / close_date / activity 会被同步维护

所以它真正解决的问题不是“有没有定期保养”，而是：

一项周期性维护如何沿着设备、团队、技师、日程和后续续期自动往前滚。

第一层：为什么维护请求不会凭空长出来

maintenance.request 虽然是工单对象，但它的很多关键字段并不是任意填写，而是从设备链路上算出来：

• category_id related 自设备分类
• maintenance_team_id 优先从设备带出
• user_id 优先从设备技师或分类默认技师带出

这说明 Odoo 的思路不是“谁报修谁手动选团队”，而是尽量让维护责任在资产侧预先落好。

这对预防性维护尤其关键。

因为预防性工作通常不是临时协作，而是长期例行任务。如果每次都靠人工重新分派，系统很快就会沦为提醒看板，而不是流程系统。

第二层：为什么 preventive 和 recurring_maintenance 要拆开

源码里：

• maintenance_type 区分 corrective / preventive
• recurring_maintenance 只在 preventive 语义下成立
• repeat_interval / repeat_unit / repeat_type / repeat_until 负责续期规则

_compute_recurring_maintenance() 还会明确把非 preventive 请求的 recurring 标记关掉。

这表示官方在语义上分得很清楚：

• 预防性维护：计划性工作
• 重复维护：计划性工作里的一个特殊子集

不是所有 preventive 都一定循环，也不是所有维护都适合滚动复制。这种边界划分是合理的，因为现实里：

• 有些预防性工作只做一次专项检查
• 有些则是周检、月检、季检

第三层：为什么完工时才复制下一张单

这套模块里最有意思的一段逻辑在 write()。

当请求被写入某个 done 阶段时，如果它满足：

• maintenance_type == 'preventive'
• recurring_maintenance == True

系统就会：

1. 取当前 schedule_date
2. 按 repeat_unit + repeat_interval 推下一次时间
3. 算新的 schedule_end
4. 如果没超过 repeat_until，就 copy() 一张新请求
5. 新单回到默认初始阶段

这说明 Odoo 的策略不是“提前批量生成一年计划单”，而是：

上一轮真的做完了，再生成下一轮。

这非常稳，因为它能避免两个常见问题：

• 计划还没执行，未来工单已经堆满
• 历史周期被人工改动后，未来整串计划全乱掉

第四层：为什么 close_date 和 stage_id.done 要强绑定

创建和写入逻辑里，系统会自动维护：

• done 阶段 → close_date 写今天
• 非 done 阶段 → close_date 清空
• stage 变化时 kanban_state 重置为 normal

这表示官方把“完工事实”绑定在阶段上，而不是允许用户各写各的。

因为在维护场景里，真正容易出错的不是排期，而是“界面显示完工了，但统计和活动还停在处理中”。

把 done 与 close_date 联动，才能让：

• MTTR
• 历史完工统计
• 周期续生
• 活动反馈

保持同一个完成语义。

第五层：为什么活动提醒是维护链的重要一环

activity_update() 会根据 schedule_date 为请求：

• 重排活动 deadline
• 指向 user_id 或 owner_user_id
• 必要时先删旧活动再建新活动

这说明预防性维护并不是“时间到了去列表里看”，而是要主动变成待办活动，贴到负责人身上。

这类设计很关键，因为维护项目最常见的失败，不是没有单，而是单子存在，但没有人被持续提醒。

Odoo 这里的处理方式相当实际：

• 有排期，就一定有活动
• 改了设备、技师或时间，就重算活动
• 完工后会反馈并更新活动状态

第六层：团队为什么不仅是分组字段

maintenance.team 不只是报表维度，它自己还会算：

• 未完成请求数
• 已排期请求数
• 高优先级数量
• blocked 数量
• 未排期数量

这意味着 team 在产品里承担的是“维护驾驶舱”的角色。

也就是说，团队对象不是把请求归个类，而是承接实际运营监控。

对于预防性维护尤其有意义，因为大量周期任务一旦积压，最先需要看的不是单条请求，而是团队侧的总负载和失衡点。

最容易误解的三个点

误区一：预防性维护就是周期生成器

不是。它背后还连着责任路由、活动提醒、完工回写和下一轮续生。

误区二：done 只是一个看板状态

也不是。done 会触发 close_date、活动反馈和下一轮复制。

误区三：团队只是方便筛选

不是。团队对象本身承接了请求监控和负载观察。

实战上怎么落地最稳

建议这样用：

1. 先在设备分类和设备上把默认技师、默认团队配清楚
2. 把预防性工作和纠正性工作严格分开
3. 周期任务尽量通过完工后续生，不要提前造很远的未来单
4. 所有计划维护都给明确 schedule_date
5. 团队面板用来看积压、阻塞和未排期，而不是只看个人列表

最后总结

Odoo 预防性维护最厉害的地方，不是能“自动生成工单”，而是它把 责任归属、排期、提醒、完工和下一轮延续 收成了一条闭环。

这让 Maintenance 不只是设备报修工具，而是一套能持续滚动的维护计划系统。