做了这么多年 SAP 实施我经常在项目上遇到一类特别典型的问题上线第一天整个采购组坐在一起培训大家打开同一个 Fiori 应用屏幕上的列表却完全不一样。A 同事只看到待审批的单子B 同事的列顺序被调得乱七八糟C 同事压根不知道右上角还能保存视图。项目经理跑过来问我能不能让全组默认打开一套统一的界面我说能靠的就是 SAP Fiori 里的 Public View公共视图。这篇文章我想把这件事讲透。很多人以为 Public View 就是“把个人视图分享给团队”操作上点一下就行但实际项目里真正难的是三件事一是搞清楚视图背后到底存了什么二是管住“谁都能发、发了就乱”的失控局面三是用 SM30 之类的后台手段去维护和清理这些视图。我会把这几块全部展开配合采购付款对账的实战案例给出一套可以直接抄作业的方法论。1. 个人视图满天飞的团队差一个 Public View1.1 采购团队里每天都在发生的“数字对不上”我先描述一个场景你大概率见过。某个采购团队每周三开应付账款对账会会上要逐条核对“本周到期未付的采购订单”。按理说大家打开同一个 Fiori 应用看到的应该是同一份数据。但实际上每个人打开的界面都不一样组长默认按“供应商”分组老张只筛选了“付款条件30天净额”小李的表格里干脆少了好几列数据口径七零八落。会上最经典的一幕就是两个人吵起来“我这显示 28 条待付款你怎么显示 21 条”最后查下来谁都没错只是各自的筛选条件和列布局不一样。问题是这种争吵和返工本身就是在烧时间、烧信任。个人视图Private View / My View本身没有错它是 Fiori 里很基础也很重要的个性化能力。错的是一旦团队协作成为刚需还放任每个人各存各的没有一套统一的方法把“个人最佳实践”沉淀成“团队公共资产”。Public View 就是干这个的把你的筛选条件、列布局、排序方式打包成一个可复用的视图发布给指定范围的团队成员。1.2 Private View 与 Public View 的本质区别很多刚接触 Fiori 的人会把这两个概念搞混先给一张我项目上常用的对比表对比维度个人视图Private View公共视图Public View可见范围仅创建者本人创建者指定的用户、角色或全员存储位置用户个性化数据通常绑定当前登录用户服务端公共存储所有可见用户共享修改权限创建者可改可删由创建者设定“可编辑”范围适用场景个人临时关注的筛选组合、个人列偏好团队统一口径、新人入职模板、周期性报表是否会污染他人界面不会如果开放给全员会直接出现在所有人的视图列表里这里要特别强调一点在 Fiori Elements 的标准机制里同一个应用下个人视图和公共视图是可以共存的。用户打开应用时下拉列表里一般会有“我的视图”和“公共视图”两个分组。公共视图发布后团队其他人不需要做任何额外设置就能从“公共视图”分组里加载。1.3 什么样的场景适合分享公共视图并不是所有列表都需要做成公共视图用得不对反而添乱。我自己的判断标准有三条口径统一是刚需比如财务月结、采购对账、销售周报所有参与人必须基于同一份筛选条件和列定义来讨论数据否则“数字对不上”会反复发生。周期性重复使用每周、每月固定要做的查询。如果只是一次性排查问题临时筛一下就行没必要发布成公共视图。新人上手需要模板团队里来了新人直接让他加载标准公共视图比让他从零摸索效率高一截。反过来下面这几种情况我一般不建议用公共视图只跟个人工作习惯相关、对他人毫无参考价值的布局涉及敏感数据需要严格控制可见性的场景以及团队还没有形成统一命名规范的时候就放开发布权限——这点后面会专门讲管理失控比没有公共视图更头疼。2. 先搞懂变式机制Public View 到底存了什么、存到哪2.1 Smart Table、Smart Filter Bar 与变式的前世今生如果你在 Fiori 里点了“保存视图”其实背后动用的是一套沿袭自 SAP GUI 时代的思想变式Variant。在 SAP GUI 里ALV 报表允许你把筛选条件、列布局、排序规则存成一个变式下次执行报表直接选用。Fiori Elements 把这套东西搬到了 UI5 里通过 Smart Table 和 Smart Filter Bar 这两个控件实现。具体来说Smart Filter Bar 负责筛选条件区用户选择的条件组合可以保存Smart Table 负责结果列表列的显示、隐藏、顺序、宽度、排序、过滤都在这层统一管理。你点“保存视图”的时候前端控件会把当前的筛选条件、列布局、排序状态等打包成一个 JSON 结构再通过 OData 服务提交到后端。这里就带出一个重要认知公共视图保存的不是“查询结果”而是“查询条件 展示配置”。所以同一张公共视图不同时间打开、不同权限的用户打开看到的数据行数可能完全不同但大家用的是同一套口径。这是 Public View 能用来做数据对齐的根本原因。2.2 服务端存储为什么别人能看到你的视图在 SAP GUI / ABAP 报表时代变式一般存在 VARID、VARIT 这类表里用 SM30 或者事务代码直接可以查到。到了 Fiori 时代情况要复杂一些。Fiori Elements 列表报表的公共视图通常走的是后端个性化服务Personalization Service数据落库后通过 OData 对外暴露。用户在前端点“保存视图”前端会调用个性化服务接口把“谁创建的、视图名是什么、存了哪些条件、可见范围是谁”这些信息写进服务端存储区。所以公共视图能跨用户可见本质就是因为它的数据存在“大家的服务端”而不是“某个人的浏览器 localStorage”里。顺带提一个容易踩坑的点有些老项目里开发自己写的自由样式Freestyle UI5 应用如果只是把视图存到了 localStorage那它就永远只是“个人视图”换台电脑甚至换个浏览器都没了更不可能发布成 Public View。判断方法很简单——用另一个测试账号登录看看能不能看到你保存的公共视图看不到说明这个应用根本没有走服务端存储机制。2.3 “可以看”不等于“可以改”公共视图的双权限维度Public View 的权限模型我一般从两个维度去理解可见性Visible To和可编辑性Editable By。可见性谁能看到并用这个视图。常见选项包括“所有人”“指定角色”“指定用户”。可见性一旦放开就意味着所有可见用户的下拉列表里都会出现这条视图。可编辑性谁能修改视图的配置内容。一般选项包括“仅创建者”和“可见用户均可编辑”。很多项目在一开始就直接选了“仅创建者”虽然省事但会带来一个问题业务变了筛选条件要加一个字段创建者调休了整个团队就卡住了。所以我的建议是核心公共视图至少要有两个管理层一个 Owner 负责内容维护一个 Backup 防止人员变动后视图失管。这个双权限模型在操作界面里通常是一组下拉选项但在后端权限控制上SAP 具体是通过角色、业务目录Business Catalog以及服务端授权对象共同实现的。在项目落地上我建议不要过度依赖默认权限而是在实施阶段就规划清楚哪些角色能发布公共视图、发布后默认可见范围是什么。2.4 如何判断当前应用支不支持 Public View不是所有 Fiori 应用都能保存公共视图这是我在项目上被问得最多的问题之一。判断方法有三个层次应用类型标准的 Fiori Elements 列表报表List Report应用基于 Smart Filter Bar Smart Table几乎都支持视图保存。自由样式应用不一定需要看开发有没有接变式基础设施。界面入口工具栏或者筛选条上有没有“保存视图”“管理视图”这类按钮。如果连保存视图按钮都没有就不用谈了。权限控制有按钮不代表你有资格创建公共视图。很多企业会在 PFCG 角色里对变式维护权限做限制导致界面上“公共”这个单选按钮是灰色的。遇到这种情况先别急着提工单让管理员检查一下角色授权和 Fiori 目录配置。另外S/4HANA 不同版本、不同 Fiori 应用之间“公共视图”的界面文案可能不一样有的叫 Team Views有的叫 Public Views还有的叫 Shared Views。本质是一回事别被文案绕晕。3. 创建 Public View 的操作全流程与权限细节3.1 创建前置检查确认应用类型和用户权限我习惯让用户在做任何保存操作之前先走一遍三连确认当前应用是标准 Fiori Elements 列表报表而不是某个自开发的 Freestyle 页面。右上角或者筛选条区域能看到“保存视图”或类似图标的入口。登录账号已具备创建公共视图的权限拿不准的话先让管理员在测试环境开个测试号试一发。不要小看这几步在大型项目里有一半“我保存不了公共视图”的工单查到最后都是权限没配或者压根不是 Elements 应用。3.2 一次完整的保存动作筛选、列布局、命名、发布下面以标准 Fiori Elements 列表报表为例把保存公共视图的完整流程拆开讲一遍。第一步设置好筛选条件。在 Smart Filter Bar 里选择业务需要的筛选字段值。比如采购订单列表我筛“公司代码1000 供应商类别国内 审批状态已批准”。注意有些字段是必选筛选字段这类字段在保存视图时会一并作为视图默认条件带去后面的人加载视图时会先看到这些条件自动填好。第二步调整列布局。在列表区域点表格工具栏上的“设置”图标选择要显示的列、调整顺序。列布局是公共视图里最有差异感的部分我见过最典型的案例是同一个列表应用财务想要“过账日期、发票号”采购想要“供应商、订单类型、交货日期”存成不同公共视图后各自加载各自的列组合互不干扰。第三步给视图命名。命名这个动作看着不起眼其实对后续管理的帮助极大。我建议强制使用“模块前缀-业务场景-关键口径”的格式比如“PO-应付对账-7天内到期”“SO-销售周报-本月新增”。不要出现“视图1”“测试”“2121 别动”这种名字。为什么等公共视图积累到几十条时没有一个规范命名整个下拉列表就是灾难。第四步选择发布类型。这一步最关键。在保存视图对话框里把类型从“个人视图/仅限我”切换成“公共视图”。随后通常会出现两个选择项可见范围哪些人能看到和可编辑范围哪些人能改。建议默认可见范围先选“指定角色”不要一上来就“所有人”。可编辑范围则按团队管理需求来。第五步点击保存然后做一件事——刷新页面重新打开视图下拉列表。如果新视图出现在“公共视图”分组下面说明发布成功如果只出现在“我的视图”下面说明你刚才选的可能还是个人视图或者权限被系统拦截了。3.3 发布后的验证模拟一个“其他用户”这一步很多顾问会忽略但它能省下后面无数的解释成本。发布完公共视图后我不是让创建者自己在那里看而是直接找另一个测试账号最好是和最终业务用户同角色的账号把它登进去打开同一个应用看“公共视图”分组里有没有这条新视图、加载后筛选条件和列布局是否正确。为什么非要换账号验证因为有时候创建者自己看到的是对他本人的个性化结果而其他用户加载时可能会因为权限问题丢字段、丢值。比如某个字段只有创建者有权限另一个人没有加载公共视图后这个字段可能显示为空列还在但内容空了。这类问题只有换账号验一遍才看得见。3.4 团队其他人怎么用一键加载与另存个人视图公共视图发布后其他人使用起来是很轻量的打开应用点视图下拉框选择“公共视图”分组里的对应条目系统自动加载筛选条件和列布局。用户不需要重新配置任何东西。更实用的是“另存为个人视图”。比如团队公共视图已经定义了基础口径但某个用户想在这个基础上多看一个“交货日期”列他可以直接加载公共视图再做局部调整然后另存为自己的个人视图。这样既保证了大方向和团队一致又保留了个性化空间是我在项目上最推荐的协作姿势。4. 管理员视角用 SM30 与标准工具把公共视图管起来4.1 收敛发布入口谁有资格创建公共视图公共视图最大的失控风险就是“人人可发、发了就再也删不掉”。所以我在管控方案里第一步永远是收敛发布入口。冻结发布资格在项目上线初期不要让所有业务用户都拥有发布公共视图的权限。常见的做法是建立一个“核心用户Key User”角色组只有这些人能把视图发布为公共视图。普通业务用户只能创建个人视图、加载公共视图。这样做有实实在在的好处公共视图的数量能被有效控制发布出去的质量有基本保障出了问题知道找谁。业务想发新视图需求先汇总到核心用户那里由核心用户统一创建或审核后发布。对应的技术落点在 PFCG 角色配置和 Fiori 业务目录里把应用权限和变式管理权限做区分。不同版本的操作路径不太一样但思路是一致的——普通用户进得去应用但“保存为公共视图”的入口对他不可用。4.2 SM30 在公共视图生命周期里的真实角色既然你在搜 “sap fiori sm30”这块我多说几句。很多人以为 Fiori 公共视图可以直接用 SM30 去维护这个理解一半对一半不对。SM30 是 SAP 里“表维护生成器”产生的维护视图事务码它的本质是维护数据库表的行内容。Fiori 公共视图如果你的实现走的是标准 Fiori Elements 后端存储那层数据通常不推荐直接拿 SM30 去改表因为它的缓存和数据结构是服务端管理的乱改容易搞出不一致。但 SM30 在公共视图生命周期里确实有用武之地主要在三类场景维护自定义配置表项目里很多自定义的视图可见范围映射、默认视图配置我们一般会做成 Z 开头的配置表里面的数据靠 SM30 维护。比如我们团队把“Fiori 应用 ID - 默认公共视图 ID”映射放到 ZFIV_DEFAULT_VIEW 里每次配新应用直接 SM30 往表里插行。传统 ABAP 变式如果这个 Fiori 应用底层用的是 ABAP 报表比如某些 SM30 生成的 Fiori app 或者传统 ALV 应用那么变式很可能就存在 VARID、VARIT 里管理员通过 SM30 能查到变式条目、能查到创建人、能清理废弃变式。排障与巡检当公共视图出现“看不到、删不掉、有明显脏数据”时先通过 SM30 找到对应的存储表定位创建人和创建时间再决定是前端口径清理还是后台补数据。直接删之前务必备份这一点放在最后一部分踩坑里细说。我给项目写操作手册时一般会给管理员两条技术路径业务界面上能管的事优先用 Fiori 界面和标准工具比如 Key User 或应用级配置只有标准工具覆盖不到的场景才启用到 SM30/SE16N 这类后台维护手段并走变更流程。4.3 清理过期视图怎么找、怎么删、怎么预防公共视图发布很容易清理却很麻烦。我不止一次在项目里看到公共视图下拉列表里躺着几十条僵尸视图点进去一看创建人早离职了。清理的完整链路大概是这样导出清单从管理工具或后台表里导出所有公共视图清单包含视图名、创建人、创建日期、最近使用时间如果能拿到。业务确认把超过 6 个月没人用的视图清单发给对应业务部门让他们确认哪些可以删。这一步不能省因为你不知道哪条视图是不是某些人每周手动切换着用。删除前备份把要删的视图完整记录导出留档防止删除后又后悔。执行删除与验证通过标准管理功能删除如果是用后台手段删表删完一定要让用户重新登录 Fiori 验证应用还能正常打开、其他公共视图不受影响。但与其事后清理我更推荐事前预防。预防机制有两个一是收紧发布权限只有核心用户能发二是建立命名规范和申请流程每条公共视图都有一个 OwnerOwner 离职前必须交接否则门禁直接拒绝释放权限。这套流程配合起来僵尸视图的数量能控制在一个很低的范围内。4.4 把公共视图做成团队默认工作台最后讲一个很多人不知道的进阶玩法把某个公共视图设为团队默认视图。设置完成后用户打开应用时会自动加载这个视图而不是系统默认的空布局。这样做的好处是“一键统一工作台”。新员工第一天打开采购订单列表看到的已经是团队沉淀好的口径不需要任何人教。实现路径上有的版本支持用户自己在视图下拉菜单里“设为默认”但这只是对他个人生效要实现全团队统一需要后台配置或者核心用户统一设置。我们项目上的做法是把“应用 ID 默认公共视图 ID”维护进自定义配置表然后通过启动逻辑去加载。具体代码不展开但这套思路在管理侧的价值非常大能让“统一入口”从口号变成实际动作。5. 一个实战案例把采购付款对账列表做成团队公共视图5.1 业务背景与痛点客户是一家制造企业采购团队 12 个人每周三要对账“本周到期未付的采购订单”。改造之前每个采购员在 Fiori 里打开的采购订单列表都不一样有人按供应商分组有人只筛了部分工厂有人的表格里没有“到期日”列。每周三的对账会平均要花 40 分钟去核对“为什么你看到的是 21 条我看到的是 28 条”。数据口径不一致导致会议效率低还经常出现“明明该付的款漏付了”这样的事故。5.2 实施过程我们做了一次非常敏捷的小改进核心就是一套标准公共视图。第一步跟采购团队确认统一口径。大家坐下来定了三个硬条件公司代码固定为 1000审批状态 已批准到期日在未来 7 天内。列布局也做了统一供应商名称、采购订单号、采购订单类型、净价、币种、到期日、超期天数、采购组。第二步由核心用户在 Fiori 里创建公共视图命名为“PO-应付对账-7天内到期”。可见范围选择“采购部门角色”可编辑范围只给两个人采购经理和他指定的 Back up。第三步在项目配置表的默认视图映射里把采购订单应用绑定到这条公共视图。这样部门成员打开应用时默认加载的就是这套统一界面。第四步开了一场 30 分钟的短培训教大家三件事怎么从公共视图列表里切换视图怎么在加载公共视图的基础上微调并另存为个人视图遇到视图加载异常时找谁。5.3 效果与复盘上线之后的第二周周三对账会的时间从 40 分钟降到了 15 分钟以内原因是会上不再有人纠结“数字为什么不一样”所有讨论都聚焦在具体业务决策上。三个月后这套公共视图还成了新员工培训的标准材料新人第一天就能看到团队统一的业务口径。复盘下来有三个要素缺一不可统一的口径定义、收敛的发布权限、明确的 Owner。技术难度其实不高真正的难点在业务流程协调和权限规范设计上。6. 踩过这五个坑你才敢说会用 Public View6.1 坑一以为保存了“结果”实际保存的是“条件”这是我见过频率最高的误解。用户保存公共视图后隔几天打开发现数据已经变了立刻投诉“视图不准了”。实际上公共视图保存的是筛选条件和列布局不是查询结果快照。数据是实时从后端读的视图只是一个“口径模板”。解决方案是培训时说清楚并且不要承诺视图能当报表用。如果业务确实需要数据快照那应该走报表导出或者自定义存储而不是依赖公共视图。6.2 坑二字段没显示不是权限问题是注解没开有次业务让我解决“公共视图加载后少了一列”的问题。我查了半天权限用户权限完全够最后才发现那个字段压根没在当前应用的 Metadata Extension 里释放出来。Fiori Elements 表格能显示哪些列是由 CDS 视图的UI.lineItem注解决定的没放出来的字段用户在视图配置界面里根本找不到自然存不进去。这个坑提醒了两件事公共视图的列能力上限是由开发侧决定的不是用户侧能突破的业务提“缺列”需求要先看是不是开发配置层面要增加字段而不能只盯着视图模板。6.3 坑三值帮助上下文被一起保存这个坑比较隐蔽。某个用户保存公共视图时顺手把筛选字段的值帮助做了切换这些上下文信息可能会一起被保存进去其他用户加载视图时看到的筛选值跟预设的不一样甚至显示空白。我当时是在一个分销项目里遇到的采购订单列表按“物料组”筛选保存的是“物料组 M 类”但另一个用户加载后筛选条件里物料组的值变成了空白。排查后才发现是值帮助上下文字段一起被序列化保存了。解决方案是让创建者重新选择一次字段值帮助确认前先清掉多余上下文再发布一次。6.4 坑四公共视图下拉列表长到失控有个项目上线半年后公共视图列表里有了 200 多条视图其中大量是“测试-1”“测试-2”这样的名字。业务用户每次下拉都要翻半天。造成这个局面的根本原因是当初没有限制发布权限。这个问题的修复成本比预防成本高得多。清理花了两周还要反复跟业务确认到底哪些能删比当初花 10 分钟配置权限痛苦多了。所以我现在做任何 Fiori 项目上线第一天就会把发布权限收敛到核心用户组并强制命名规范。6.5 坑五SM30 直接改表改出了不一致有次为了快速清理一条公共视图管理员直接用 SM30 把底层存储表的记录删了。结果那条视图在前端还能被看到点进去却报错因为前端缓存和后端数据不一致了。后来只能让相关用户清理本地缓存重新加载才恢复。所以能用标准管理功能就走标准功能必须用 SM30 或 SQL 处理时第一要备份第二要选在业务低谷期操作第三完成后要组织验证。不要为了“快”去直改数据公共视图这东西关联了用户界面状态处理不好就是连环问题。6.6 一份可以直接抄的落地清单最后给一套我每次做这类项目都会带去评审的清单照着落地基本不会出大问题明确公共视图统一口径的三要素筛选条件、列布局、可选字段范围。收敛发布权限普通用户只能创建个人视图核心用户才能发布公共视图。命名规范强制化格式统一为“模块-场景-关键口径”。每条公共视图指定 Owner 和 BackupOwner 离职必须先交接。每月巡检公共视图清单超过 6 个月未使用的进入清理流程删前备份。设置团队默认视图统一新用户打开应用后的第一视角。不用 SM30 直改前端管理的公共视图存储优先走标准工具必须改时做好备份和验证。每季度抽出 15 分钟给核心用户做一次公共视图管理的短训保证大家会用、敢管。公共视图这套东西越早纳入治理后面越省心。我见过太多项目一开始放任自由半年后花大力气清理僵尸视图。真要等那时候再动手成本已经是前置管控的几十倍了。
