4. 权限矩阵核心概念
在付款审批流的设计中，权限矩阵是把“谁能做什么、对哪些数据做、在什么条件下做”落到可执行规则的关键工具。很多项目在流程图上画得很清楚，但一到系统配置就出现“审批人看不到单据”“越权付款”“同一人既申请又审批”等问题，根源往往不是流程本身，而是权限模型没有拆解清楚。本节围绕七个核心概念展开：角色、权限、数据范围、功能权限、操作权限、权限继承与权限互斥。
一、核心原理：权限矩阵是“主体—客体—动作—条件”的四维映射
权限矩阵的本质不是一张二维表，而是一个四维映射关系：主体（角色或用户）、客体（付款单、供应商、银行账户、预算科目等数据对象）、动作（查看、编辑、审批、驳回、付款、导出等）、条件（金额区间、组织范围、单据状态、时间窗口）。缺少任何一维，权限都会出现漏洞或过度限制。
其中，角色是权限的集合载体，不是具体的人。角色可以按岗位（如财务专员、财务经理、CFO）、按组织（如华东区财务）、按流程节点（如一级审批、二级审批）来定义。一个用户可以有多个角色，最终权限是多个角色权限的并集，但互斥规则会在此基础上做减法。
功能权限决定“能不能进入某个功能模块”，例如能否打开付款审批页面、能否进入供应商管理菜单。操作权限决定“进入后能执行哪些动作”，例如在付款单上能否点击“审批通过”、能否修改金额、能否导出明细。功能权限是粗粒度入口，操作权限是细粒度按钮级控制，两者必须配合使用。
数据范围决定“能看到和操作哪些数据”，常见类型包括：本人、本部门、本部门及下级、指定组织、全部。数据范围通常与组织架构和单据归属字段绑定，例如“付款单的申请部门”或“成本归属中心”。
二、方法流程：从业务规则到权限矩阵的落地步骤
- 梳理审批节点与岗位：列出付款流程中每个节点由谁审批、由谁执行付款、由谁复核。
- 定义角色清单：将岗位抽象为角色，避免直接给个人授权。例如“应付会计”“资金主管”“财务总监”。
- 拆分功能权限与操作权限：先确定每个角色可进入的模块，再确定模块内可执行的动作。
- 绑定数据范围：为每个角色指定数据可见范围，并明确范围字段来源。
- 设置继承与互斥：确定哪些角色可以继承上级角色权限，哪些角色必须互斥。
- 配置并验证：在系统中配置后，用测试账号逐条验证，重点检查越权和漏权。
推荐用“角色—功能—操作—数据范围—条件”五列清单来管理权限矩阵，每一行代表一条最小授权规则。这样在审计和排障时可以快速定位到具体规则。
三、权限继承与互斥：效率与风控的平衡
权限继承是指下级角色自动获得上级角色的部分或全部权限。例如“财务经理”继承“财务专员”的查看权限，但额外拥有审批权限。继承可以减少重复配置，但必须明确继承边界：是继承功能权限，还是同时继承操作权限和数据范围？如果继承范围过大，容易造成权限膨胀。
权限互斥是指两个角色不能同时授予同一用户，典型场景是“制单”与“审批”互斥、“付款执行”与“付款复核”互斥。互斥是内部控制的基本要求，目的是防止同一人完成全流程而缺乏监督。在系统中，互斥通常表现为：当用户已拥有角色A时，分配角色B会被拒绝或触发告警。
常见误区：把“角色继承”当成“人员汇报关系继承”。汇报关系是组织管理概念，权限继承是系统授权概念，两者不能直接等同。否则会出现“上级自动拥有下级所有操作权限”的越权风险。
四、案例与场景：一张付款审批权限矩阵示例
以下表格展示了一个简化但完整的付款审批权限矩阵，覆盖角色、功能权限、操作权限、数据范围和互斥关系。
| 角色 | 功能权限 | 操作权限 | 数据范围 | 互斥/继承 |
|---|---|---|---|---|
| 付款申请人 | 付款申请、单据查询 | 新建、编辑、提交、撤回 | 本人 | 与审批角色互斥 |
| 部门审批人 | 付款审批 | 审批、驳回、查看明细 | 本部门及下级 | 继承申请人查看权限 |
| 财务复核 | 付款审批、供应商管理 | 复核、退回、修改付款条件 | 全部 | 与付款执行互斥 |
| 资金主管 | 付款执行、银行账户管理 | 付款、导出回单、查询流水 | 全部 | 与财务复核互斥 |
| 财务总监 | 全部付款功能 | 终审、特批、查看报表 | 全部 | 继承资金主管查看权限 |
在这个例子中，申请人只能看到自己的单据；部门审批人可以看到本部门及下级；财务复核和资金主管可以看到全部数据，但两者互斥，不能由同一人担任。财务总监继承资金主管的查看权限，但额外拥有终审和特批操作权限。
五、误区与复盘：权限矩阵设计中的高频问题
- 只配功能权限，不配数据范围：导致审批人能看到全公司付款单，造成数据泄露。
- 角色粒度过粗：一个“财务人员”角色包揽制单、审批、付款，无法满足内控要求。
- 忽略互斥校验：系统允许同一人同时拥有制单和审批角色，审计时被认定为重大缺陷。
- 继承关系混乱：下级角色继承上级后，反而获得了上级的审批权限，造成越权。
- 数据范围字段选错：用“创建人”而不是“申请部门”作为范围字段，导致部门经理看不到本部门单据。
复盘时建议做一次“权限穿透测试”：用每个角色的测试账号，分别验证功能入口、按钮可见性、数据列表范围和单据操作结果。任何一项不符合预期，都回到权限矩阵中定位具体规则。
权限矩阵配置片段示例（伪配置）：
role: 部门审批人
functions: [payment_approval]
operations: [approve, reject, view_detail]
data_scope:
type: dept_and_children
field: applicant_dept
inherit: [付款申请人.view]
mutually_exclusive: []
掌握这七个核心概念后，后续章节中的审批流节点配置、金额分级授权和审计日志设计，都可以在此基础上逐层展开。权限矩阵不是一次性文档，而是需要随组织调整、流程变更和内控要求持续维护的活规则。