门禁通常是作为安防产品被采购的，然后靠一张工卡号 CSV 挂到人事系统上。在 Odoo 环境里，同一次集成可以是带审计轨迹、受控的授权流水线，也可以是一张每晚导出的表，让某位承包商在合同结束六周后仍能刷卡进门。差别在设计，不在硬件。
门禁是授权流程，只是终点在一扇门上
锁回答「这张卡此刻是否有效」，而 ERP 回答「这个人到底该不该在这里」。
- 发卡、区域授权与吊销，都是有人负责的主数据流程。
- 人事与门禁之间每多一步手工表格，就是一次无声的权限扩张。
- 出事后安防要证据，值班时运营要速度。
- Odoo 往往是员工、承包商与项目数据唯一交汇的地方。
- 明确每个字段以哪个系统为准，并把它写下来。
沿着延迟这条线划分职责
门的判定等不了一次 Web 请求，工资记录也不该被一扇门改写。
- 控制器负责毫秒级判定、反回传与离线兜底。
- Odoo 负责名册、区域权限矩阵、有效期与审计查询。
- 向外推送授权，不要让 Odoo 实时去开门。
- 设计好缓存策略，让 Odoo 不可达时现场仍然既安全又能用。
- 记录分歧：本地越权只有在事后可见时才是合理的。
人、凭证与区域要分开建模
多数集成把三个对象压成一行，之后就回答不了任何简单问题。
- 一个人——员工、承包商或访客——在不同时期可以持有多张凭证。
- 凭证是有生命周期的实物：已发放、有效、遗失、吊销、已更换。
- 区域是带策略的逻辑范围，门只是挂在它上面的硬件，不是策略本身。
- 授权把人、区域与一个时间段连起来，并附上理由与审批人。
- 绝不要只存一个「可进入」标志；把授权连同起止日期一起存，否则吊销只能靠猜。
什么该放在 Odoo，什么不该
ERP 适合做授权的记录系统，不适合存秘密。
- hr.employee 加上一个承包商模型，就能提供身份、主管与合同结束日。
- 一个小的自定义授权模型就够了：人、区域、生效日、失效日、审批人、状态。
- 维护与项目记录会告诉你谁应当在现场、什么时候到。
- 不要把原始卡号镜像进 Odoo；改存令牌或哈希引用。
- 照片与生物特征模板留在门禁系统里，按它自己的留存规则管理。
向外推授权，向内收事件
两个方向、两份契约，都不该是同步耦合。
- 出向：Odoo 计算每个人的目标状态，把增量推给控制器。
- 入向：控制器把放行、拒绝、门常开与强制开门事件推入队列。
- 两个方向都需要一个在组织调整与重新入职后依然稳定的人员键。
- 出向同步按分钟批量执行；逐次点击的实时推送既不必要也不可靠。
- 对偏移告警，尤其是控制器里有、Odoo 里却没有的授权。
让事件流幂等且可重放
门禁事件就是审计轨迹，必须扛得住重试、重启和倒霉的下午。
- 每个事件由控制器生成唯一标识，入库时去重。
- 原始事件先落暂存表，再投影进 Odoo 模型。
- 原始事件按政策留存，到期按计划删除，而不是靠意外丢失。
- 重放不得重复生成考勤、工时或工单记录。
- 上报滞后：最新事件的时间年龄，比一个绿色看板更能说明系统健康。
带时间、陪同与到期的最小权限
永久权限应当是例外，而每个例外都要有明确责任人。
- 授权默认到期；永久授权需要审批与复核日期。
- 承包商的授权应随合同结束而结束，而不是随某个人的记性。
- 时间窗与陪同规则属于策略，不属于门边的一张便利贴。
- 把「能进」与「能操作」分开：动力房不是办公走廊。
- 每季复核一次区域矩阵；交付物是复核报告，不是那扇门。
真正造成事故的失效模式
多数门禁事故是集成失效，只是看起来像人的失误。
- 已吊销的卡仍能刷，因为控制器缓存了它，而同步早已悄悄停止。
- 控制器与服务器时钟漂移，导致事件顺序无法证明。
- 反回传设得太严，消防疏散后回场时反被锁在门外。
- 尾随被当成软件问题，而它本质上是物理与文化问题。
- 合同已过期的承包商还在名册里，因为没人关闭人事记录。
审计、隐私与你会被问到的问题
事故之后，问题从来不是「门有没有工作」，而是「谁被允许进来」。
- 要能从存储的授权里回答：某日某人是否被授权进入区域 X。
- 遵守目的限制：门禁数据服务于安全与保卫，不做绩效打分。
- 按数据类别定义留存期，并用自动化删除替代口头承诺。
- 对门禁系统的访问本身就是特权，管理员变更要单独记录。
- 若使用生物特征，说明法律依据，并把模板留在门禁系统内。
上线：先影子运行，再开始拦截
把集成排好序，让最初的拒绝发生在代价便宜的地方。
- 先跑影子模式：Odoo 计算授权，控制器仍用自己的名单，每天比对。
- 执行前先清理名册，因为身份数据脏就会产生误拒。
- 一次只启用一个区域，从风险最低的门和最小人群开始。
- 与安全团队一起演练离线与疏散两种场景。
- 发布一页纸的例外流程，否则主管们会各自发明一套。
