很多团队把制造维护理解成“报修单提交后，在日历上占一个停机时段”。但企业版的 mrp_maintenance 其实在做更强的事情：维护请求一旦改动，停机 leaves 要跟着重建，活动提醒也要同步更新，必要时还要直接挡住冲突排程。
先看生命周期。create() 创建请求后立刻调用 _recreate_leaves()；write() 只要改了 workcenter_id、schedule_date、schedule_end、重复周期、block_workcenter 等核心字段，也会重新建 leaves；unlink() 则会先删掉 leave_ids 再删请求。也就是说，leave 不是维护请求的附件，而是随请求状态不断重算的资源事实。
_recreate_leaves() 里的防线非常明确：请求必须是 maintenance_for = workcenter、必须有 schedule_date、必须有 workcenter_id、必须勾选 block_workcenter，阶段不能 done 且该阶段必须允许 create_leaves。只要缺任何一个条件，系统都不会贸然占用工作中心容量。
真正硬核的是冲突判断。源码会用 _get_first_flexible_available_slot() 计算理想时段是否已经被工单占用；如果期望开始时间不是第一个可用槽，而且 raise_on_schedule_date_already_planned 为真，就直接抛出“Manufacturing Orders are already scheduled for this time slot.”。测试 test_maintenance_block_workcenter() 也专门验证了：维护可以跨非工作时间，但不能无视已排工单。
维护不是只有资源占用，还有协同沟通。_need_new_activity() 只要看到 workcenter_id 就会要求生成新活动，_get_activity_note() 还会把工作中心 HTML link 放进提醒内容。这样做很朴素，但很重要——因为维护调整往往不是技术问题，而是要让计划员和维修员都及时知道“这台工位被谁改了”。
新手最容易犯的错，是把 leave 当成一次性结果：创建时有就行，后面时间改了再手工补。企业版显然不接受这种做法，它宁可每次重建，也不愿留下一个和当前请求状态不一致的旧停机位。
所以制造维护真正的价值，不在“生成一条停机记录”，而在于持续把维护请求、资源 leaves、活动提醒和排程冲突保持一致。
DISCUSSION
评论区