站内已经有一篇车队文档文章，重点讲集中 folder、owner 和访问传播。这一篇刻意不重复那条主链路，而是换一个企业管理视角：车辆文档真正难的不是“集中放哪里”，而是“哪些文件会过期、谁该被追、folder 治理边界到哪”。核心锚点仍然是 enterprise/documents_fleet/models/fleet_vehicle.py，再结合 enterprise/documents_fleet/tests/test_documents.py 里的行为测试去看。
一、车辆文档治理先是 folder policy，再是提醒
fleet_vehicle.py 里 _get_document_folder()、_get_document_owner()、_get_document_tags() 明确把车辆文档的默认落点、所有者和标签都制度化了。这意味着车辆文档不是“附件随便传”，而是先进入一个带治理语义的 Documents 空间。
为什么这件事比到期提醒更重要？因为如果 folder policy 本身不稳，后面再多提醒也只是催着大家去一个混乱仓库里找文件。
二、expiry 的本质不是日期，而是责任人跟进机制
这套桥接模型本身不直接在 fleet_vehicle.py 写出一套复杂 expiry engine，但企业实践里车辆文档几乎都会围绕保险、年检、行驶证、租赁协议等到期对象运转。你看测试文件会发现，Odoo 更重视的是文档如何进入正确 folder、访问如何传播、公司级默认 folder 开关如何影响后续行为。
这背后的产品思路很清楚：先把文档放到对的治理容器里，后面的到期 activity、提醒策略、补件流程才有地方落。没有统一治理容器，expiry 只会沦为 scattered reminders。
三、activity policy 应该建立在 folder 与 access 稳定的前提上
test_documents.py 里专门测了 folder access 传播、多公司 folder 复用/切换、folder 归档后公司配置如何处理。这些测试看似和“到期提醒”无关，实际上是在回答一个更底层的问题：当某份车辆文件需要被追踪续期时，谁应该看得见它，谁应该有权编辑它，它还在不在原来的治理空间里。
对企业来说，activity policy 如果不建立在这些答案上，最后就会出现：系统提醒了，但负责人没权限；或者文档已被挪走，活动点开后找不到对象。
四、公司级 folder 开关就是治理边界开关
已有文章更多从“集中化”角度解释 company folder。这一篇更想强调它的治理含义：公司级 documents_fleet_folder 一旦被禁用、切换或归档，等于组织在重划车辆文档治理边界。测试里就覆盖了新公司复用默认 folder、禁用桥接后不再自动跟随、旧 folder 归档后如何回退等场景。
这意味着 vehicle folder 不是一个目录路径，而是车队文档治理制度的承载体。你改的是配置，实际影响的是未来所有续证、补件、审计追踪。
五、如何避免和已有文章撞题
已有那篇重点是“默认集中到哪、owner 怎么定、访问怎么传播”。这一篇则把重点移到：
- 为什么到期管理离不开稳定 folder policy；
- 为什么 activity policy 需要以权限和归档边界为前提；
- 为什么 company folder 配置变化会改变车辆文档治理制度。
也就是从“存放机制”转到“治理机制”。
六、实战建议
- 先定义哪些车辆文档属于需要 expiry 管控的对象；
- 再统一 folder / tag / owner 规则；
- 最后才上 activity 和提醒，不要倒过来。
七、结论
Odoo 企业版车队文档管理真正难的，不是把文件集中起来，而是让它们在过期、续期、审计和权限变化中始终留在可治理的边界内。到期提醒只是表层，folder policy 与访问治理才是底座。
主要源码锚点：
enterprise/documents_fleet/models/fleet_vehicle.pyenterprise/documents_fleet/tests/test_documents.py
DISCUSSION
评论区