SAP PCE 系统的月度自动计量跑顺之后，账面上的 FUE 数字由三件事决定：规则集给用户做的自动分类、少量被允许的手动分类、以及 RPA 机器人这类特殊账号的建号方式。自动分类是主轨，前情在《SAP PCE 月度自动计量解读，从数据链路到读数陷阱》里写过。手动分类这条辅轨限制很多，采信条件、适用场景与失效方式都有明确边界，特殊用户的处理更是直接决定要不要为机器人买许可。这两件事值得单独摊开。
手动分类默认不推荐，例外只有四类
官方口径开宗明义：默认不推荐手动分类，自动分类基于授权对象判定，比人手维护可靠。被推荐的例外一共四类：Mixed 系统里的纯引擎用户，手动分到 GF 或 IF；SAP 支持与 CAS 用户，手动分到 GE 或 IE，这一类免费；开发系统的 admin-only 用户，手动分到 GB 或 IB；SAC 的 BI 用户，手动分到 GF。
这四类例外用的类型代号来自价目表的用户阶梯，顺带把阶梯摆清楚：Advanced 覆盖全部方案能力，Core 对应软件使用权利定义的能力，Self-Service 是更窄的子集，Development 是 ABAP 开发工具访问，Support Access 是 SAP 供合规验证用的管理用户，不计数；Tech. Engine Use 只用引擎功能，免费；Technical Use 供技术连接，不可购买也不分配到人。手动分类选的类型就从这个阶梯里来。
采信条件比例外清单更严格。只有按 06、07 价目表做的手动分类会被计量采纳，按其他价目表分类的用户会被自动重分类：Core 系统按授权对象重判，Engine 系统归 Tech Engine，开发系统归 Developer-Test。非对话用户如果没做手动分类，计量时完全忽略；手动分了 PCE 之外的类型，同样被重分类。生产 client 上手动标 91 Test 会被强制重分类，生产环境里本来也不该出现测试标记。还有一条总闸：PCE 没有特殊用户类型，手动分类只能选当前价目表里既有的类型，不存在额外的特殊类型可设。
特殊用户不占 FUE 的三条路
RPA 机器人是最近两年最常踩的坑。首选做法是给机器人建 Service User，这类账号不计 FUE；如果机器人用的是对话用户，就会按对话用户的类型计费，落到 68 或 69 的口径里。Firefighter 应急账号同理，优先 Service User，实在不行手动分 GE 或 IE。Digital Access 场景的间接使用完全不计 FUE，另走数字访问的按单据计费模式，单据类型与权重此前在《SAP 数字访问九类单据计费解读》里拆过。
系统分类本身在 SAP for Me 的 System Measurement 页维护，四类各有计量效果：Core 默认纯 ERP 系统，全自动分类；Mixed 是 Core 与引擎功能共存，纯引擎用户必须手动分 GF 或 IF；Engine 纯引擎独立系统，全员自动归 Tech. Engine Use；SolMan 排除计量，但清单上没识别出来的 SolMan 要客户手动归类，形态是开发系统、分类又改不了的时候，可以把用户手动分到免费类型，把人从 FUE 账里摘出去。
系统类型（Test、Prod、Dev）的纠错是另一件事，客户自己在界面上改不了，要联系 SAP 的客户经理处理。这类纠错影响计量范围本身：QA 系统不计量，开发系统计全部 client，Core 生产系统只计生产 client，范围标错，后面所有数字都歪。开发系统里还有个细节：传输条目本身与 client 无关，每个开发 client 都会出现，判定看用户实际活跃的 client。
旧的手动分类会挡住自动分类
准备期的官方六步里，第二步专门处理这件事：删除旧的手动用户与角色分类，旧 USMM 时代的 license_attributes 与新版的 Role-based Classification 都算。残留的手动分类会阻止自动分类接管，等于把主轨堵死在辅轨上。同一步还连着账号清理的纪律：锁定用户照样被计量，要让账号出账，得把有效期改到过去。这两条在《SAP 审计 USMM 测量前的自查清单》的清单里也是必查项。
自动分类也有失手的时候
辅轨有边界，主轨也会出错，而且错法都留了案底。Note 3568419 修正的那次教训值得记住：自动分类的规则集失效后系统回落到默认分类，FUE 账面直接偏高，计量组件的补丁纪律与账面数字挂钩。分类位置也有口径讲究：Developer Access 用户只在开发系统被分类，部分 Advanced 用户也可能落在开发系统，所以 FUE 核验必须生产系统与开发系统都跑，只看一边就会漏账。UCM 组件另有三项已知缺陷，2026 年 11 月版起修复：手动分类被有效期日期错误拦截、传输请求状态过滤缺失、传输 client 判定缺失。
从项目里的观察补一句，最常见的三类错配：机器人用对话用户跑流程、旧的手动分类残留挡住自动分类、Firefighter 图省事直接拿主管账号顶。三类都不是技术难题，但每一类都直接多花许可的钱，而且都会在对账报告里留下痕迹。
对账有官方工具。Note 3795409 提供 ABAP 报告源码，客户按手册自建程序 ZR_FUE_VERIFY，SE38 建程序贴源码再走传输，跑出来每个用户两列判定：一列是按最新规则集本应分到的类型，一列是月度计量实际采用的结果。两列对不上，就是分类争议点。与 STAR 报表核对时还要多留一层：STAR 的 FUE 计算不考虑手动分类，rule、role、reference-user 三种方式在它眼里都算手动，这一条差异天然会造成两边的数对不齐。建议每月计量出数后跑一遍，生产系统必跑，开发系统也建议跑，在数字变成账单之前把分歧找出来。数字对不上的完整排查路径，见《SAP 许可审计中的计量分类与 FUE 对账》。
本文首发于 sapzx.com，版权归 河_南.赛-锐-信-息.科•技-有_限.公•司 所有，未经授权请勿转载。
看数的位置与两个过滤器
计量结果在 SAP for Me 的 Consumption 看板看，可以按 installation、system、client 三层下钻到 Metering Details，查看权限还是那套 LICAUD_PCL。跑分类辅助程序时注意过滤器差异：User Validation 只看活跃用户，Role 与 Profile Validation 连非活跃用户一起算，两边数字不一致先看是不是过滤器口径不同。Core 与开发系统里还有一个 Use local PCE rule-set 复选框，QA 系统不计量，这个框也不会出现。
把分类当成一次角色治理的机会
分类的本质是按授权对象给用户的实际能力定档，开发权限那一档最贵，口径见《最贵的 FUE 档藏在开发权限里》。所以规则集跑出来的分类结果，本身就是一次角色与授权概念的体检报告：哪些普通用户挂着开发级授权、哪些角色组合把人顶到了高档位，逐条清理的角色治理，才是 FUE 优化的主战场。分类数据在手，清理优先级一目了然，这比等审计函到了再临时降档从容得多。
SAP 许可模式从 ECC 到 S/4HANA 再到 RISE with SAP 的演变，不仅是技术的迭代升级，更是一场涉及企业运营模式和成本结构的深刻变革。对首批走进续约窗口的 PCE 客户而言，续约报价的构成如同一个黑匣子，但黑匣子是可以被打开的。赛锐信息深耕 SAP License 审计与合规治理领域，长期服务于 SAP ECC、S/4HANA 及 RISE with SAP 客户，在 SAP 官方审计流程、FUE 许可优化策略及账号资产精细化管理方面积累了丰富的咨询与实施经验。依托自主研发的 SAP License / FUE 资产优化软件产品（AMS-V），我们帮助企业在满足 SAP 合规要求的前提下，提升 FUE 许可利用率、降低订阅成本、控制审计风险。欢迎随时联系我们，获取 SAP FUE 许可优化咨询服务，并申请产品试用与方案演示。
