3. 数据源解析：ERP系统、采购订单表、审批流日志表、组织架构表的结构与字段
越权采购排查的核心难点在于：权限的“应然”与“实然”之间存在信息孤岛。要打通这个孤岛，必须将分散在四个独立系统中的数据源进行结构化关联。本章将逐一拆解ERP系统、采购订单表、审批流日志表和组织架构表的核心字段与业务含义，为后续的规则引擎设计打下数据基础。
数据源对齐原则： 所有表之间必须通过 员工ID（工号） 和 单据编号 建立外键关联，避免使用姓名或部门名称作为关联键，防止因重名或组织调整导致数据断裂。
3.1 ERP系统（主数据与交易核心）
ERP系统是采购支出的最终记账系统，也是我们判断“是否越权”的最终依据。它主要提供两类数据：物料主数据 和 供应商主数据。
| 数据类别 | 关键字段 | 业务含义 | 越权排查用途 |
|---|---|---|---|
| 物料主数据 | 物料编码、物料组、采购组、物料分类（固定资产/原材料/服务） | 定义采购对象的属性与归属 | 判断采购品类是否超出岗位职责范围 |
| 供应商主数据 | 供应商编码、供应商组、信用等级、合作状态 | 定义供应商的资质与分类 | 判断供应商是否在授权名录内 |
| 采购组织 | 采购组织编码、采购组织名称、所属公司 | 定义采购执行的法律实体 | 判断采购行为是否跨法人实体 |
⚠️ 常见陷阱： ERP中的“采购组”字段常被误认为是“审批权限组”。实际上，采购组仅表示业务归属，不代表审批权限。两者必须通过组织架构表进行映射。
3.2 采购订单表（交易行为记录）
采购订单表是越权排查的核心事实表。每一行记录一次采购下单行为，包含下单人、审批人、金额、品类等关键信息。
-- 采购订单表核心字段示例（SQL）
CREATE TABLE purchase_order (
po_number VARCHAR(20) PRIMARY KEY, -- 订单编号
created_by VARCHAR(10), -- 下单人工号（关键）
created_date DATE, -- 下单日期
supplier_code VARCHAR(10), -- 供应商编码
material_code VARCHAR(15), -- 物料编码
quantity DECIMAL(12,2), -- 数量
unit_price DECIMAL(12,2), -- 单价
total_amount DECIMAL(14,2), -- 总金额（含税）
currency VARCHAR(3), -- 币种
department_code VARCHAR(10), -- 申请部门编码
cost_center VARCHAR(10), -- 成本中心
approval_status VARCHAR(2), -- 审批状态（A=已审批，P=待审，R=驳回）
final_approver VARCHAR(10) -- 最终审批人工号
);
| 字段 | 越权排查关键点 |
|---|---|
| created_by | 判断下单人是否具备该品类/金额的采购权限 |
| total_amount | 与岗位金额阈值对比，判断是否超权限下单 |
| department_code | 判断下单人是否跨部门采购（常见越权场景） |
| final_approver | 与审批流日志表关联，验证审批人是否合规 |
3.3 审批流日志表（权限执行轨迹）
审批流日志表记录了每一笔采购订单的完整审批路径，包括每个节点的审批人、审批时间、审批动作。它是验证“审批权限是否被绕过”的核心证据。
-- 审批流日志表核心字段示例（SQL）
CREATE TABLE approval_flow_log (
log_id INT AUTO_INCREMENT PRIMARY KEY,
po_number VARCHAR(20), -- 关联采购订单
node_sequence INT, -- 节点序号（1=第一级，2=第二级...）
approver_id VARCHAR(10), -- 审批人工号
approval_action VARCHAR(2), -- 审批动作（A=同意，R=驳回，T=转审）
approval_comment TEXT, -- 审批意见
approval_time DATETIME, -- 审批时间
is_delegate BOOLEAN, -- 是否代审
delegate_from VARCHAR(10) -- 原审批人工号（代审时填写）
);
关键字段解读：
- node_sequence： 如果某笔订单的审批节点数少于预设规则（例如应审3级，实际只审2级），则判定为“审批流缺失”。
- is_delegate： 代审场景是越权的高发区。需检查代审人是否具备被代审人的权限等级。
- approval_action： 如果出现“先同意后驳回”的异常序列，需标记为可疑行为。
3.4 组织架构表（权限基准）
组织架构表是越权排查的基准参照系。它定义了每个岗位的汇报关系、职级、职能范围和金额审批权限。没有这张表，所有“越权”判断都无从谈起。
| 字段类别 | 字段示例 | 越权排查用途 |
|---|---|---|
| 员工基本信息 | employee_id, name, grade_level | 确定人员身份与职级基准 |
| 岗位权限定义 | procurement_category, max_amount_per_order, max_monthly_amount | 与采购订单表对比，判断是否超品类/超金额 |
| 汇报关系 | supervisor_id, department_code | 验证审批链是否完整，判断是否跨部门采购 |
| 审批权限矩阵 | approval_category, approval_amount_limit | 与审批流日志表对比，判断审批人是否具备相应权限 |
3.5 四表关联逻辑（数据链路总览）
四张表通过以下关键键值形成完整的越权排查数据链路：
- 采购订单表.created_by → 组织架构表.employee_id：验证下单人权限
- 采购订单表.po_number → 审批流日志表.po_number：获取完整审批路径
- 审批流日志表.approver_id → 组织架构表.employee_id：验证审批人权限
- 采购订单表.material_code → ERP系统.物料主数据：获取品类归属
- 采购订单表.supplier_code → ERP系统.供应商主数据：验证供应商资质
💡 实战建议： 在数据清洗阶段，优先检查 created_by 和 approver_id 是否在组织架构表中存在。如果出现“幽灵员工”（已离职但仍在系统中操作），应直接标记为最高风险等级。