为什么是三层
把权限拆成三个独立的维度，好处是每个维度职责单一，组合起来又能覆盖绝大多数场景。
- 组织维度：决定用户属于哪个核算主体、部门、成本中心
- 岗位维度：决定用户可以执行哪些操作（制单、审核、审批、付款、记账）
- 数据范围维度：决定用户可以访问哪些数据（全部、本组织、本人、指定范围）
三者是相乘关系而非相加。一个用户可能是 A 公司的会计（组织），拥有制单与查询权限（岗位），数据范围限定在 A 公司及其下属部门。改变任一维度都不影响其他两个。
按角色包授权，不按人授权
直接给个人配权限是运维灾难的起点。正确的做法是先定义角色——把常见的职责组合固化成角色包，用户通过关联角色获得权限。
| 典型角色 | 操作权限 | 数据范围 |
|---|---|---|
| 费用会计 | 制单、查询、打印 | 本组织及其下属单元 |
| 财务主管 | 审核、退回、调整 | 本组织全部 |
| 出纳 | 付款执行、银行对账 | 本组织付款相关单据 |
| 共享中心作业岗 | 按分配任务处理单据 | 仅被分配到的单据 |
| 集团财务 | 查询、汇总、报表 | 全部组织（只读为主） |
| 系统管理员 | 用户与权限维护 | 不含业务数据访问权限 |
最后一行值得特别注意。系统管理员负责维护用户和权限，但不应该同时拥有业务数据的完全访问权——这是一个典型的职责冲突，审计时会重点检查。实践中常用的解法是让管理员只能配置权限而不能查看数据，或者查看行为全部留痕并定期复核。
共享中心场景的特殊处理
财务共享中心的作业模式是按任务池分配单据，而不是按组织划分范围。这类场景下，数据范围用“本组织”来限定是行不通的——作业人员可能处理来自多个组织的单据。
可行的做法是引入任务维度的授权：作业人员只能看到被分配到自己任务队列中的单据，任务完成后访问权限自动收回。同时禁止按人检索全量数据的能力，避免有人通过搜索绕过任务分配机制。
常见的授权陷阱
需要避免
- 用超级管理员账号处理日常业务——一旦发生问题无法追溯到具体责任人
- 离职人员账号未及时回收——建议与人事系统联动做自动停用
- 临时授权无限期保留——所有临时授权应有到期时间
- 权限变更不记录——授权与收权操作本身也需要留痕
- 同一个人同时拥有制单和审核权限——违反职责分离原则
配置完成后的验证
权限配置完成后，建议做一次越权测试：用各角色的账号分别尝试访问超出范围的数据与功能，确认都被正确拦截。这项工作最好由不参与配置的人来执行，因为配置者容易陷入“应该没问题”的假设。
另外建议建立定期的权限复核机制。人员岗位变动是持续的，权限如果只在入职时配置、离职时回收，中间过程会积累大量与实际职责不符的授权。按季度做一次复核，把权限清单发给各部门负责人确认，是成本较低且效果明确的做法。