企业官网建设流程全解析

做了这么多年 SAP 实施，我经常在项目上遇到一类特别典型的问题：上线第一天，整个采购组坐在一起培训，大家打开同一个 Fiori 应用，屏幕上的列表却完全不一样。A 同事只看到待审批的单子，B 同事的列顺序被调得乱七八糟，C 同事压根不知道右上角还能保存视图。项目经理跑过来问我，能不能让全组默认打开一套统一的界面？我说能，靠的就是 SAP Fiori 里的 Public View（公共视图）。

这篇文章我想把这件事讲透。很多人以为 Public View 就是“把个人视图分享给团队”，操作上点一下就行，但实际项目里真正难的是三件事：一是搞清楚视图背后到底存了什么，二是管住“谁都能发、发了就乱”的失控局面，三是用 SM30 之类的后台手段去维护和清理这些视图。我会把这几块全部展开，配合采购付款对账的实战案例，给出一套可以直接抄作业的方法论。

1. 个人视图满天飞的团队，差一个 Public View

1.1 采购团队里每天都在发生的“数字对不上”

我先描述一个场景，你大概率见过。某个采购团队每周三开应付账款对账会，会上要逐条核对“本周到期未付的采购订单”。按理说大家打开同一个 Fiori 应用，看到的应该是同一份数据。但实际上，每个人打开的界面都不一样：组长默认按“供应商”分组，老张只筛选了“付款条件=30天净额”，小李的表格里干脆少了好几列，数据口径七零八落。

会上最经典的一幕就是两个人吵起来：“我这显示 28 条待付款，你怎么显示 21 条？”最后查下来，谁都没错，只是各自的筛选条件和列布局不一样。问题是，这种争吵和返工本身就是在烧时间、烧信任。

个人视图（Private View / My View）本身没有错，它是 Fiori 里很基础也很重要的个性化能力。错的是一旦团队协作成为刚需，还放任每个人各存各的，没有一套统一的方法把“个人最佳实践”沉淀成“团队公共资产”。Public View 就是干这个的：把你的筛选条件、列布局、排序方式打包成一个可复用的视图，发布给指定范围的团队成员。

1.2 Private View 与 Public View 的本质区别

很多刚接触 Fiori 的人会把这两个概念搞混，先给一张我项目上常用的对比表：

这里要特别强调一点：在 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 创建前置检查：确认应用类型和用户权限

我习惯让用户在做任何保存操作之前，先走一遍三连确认：

1. 当前应用是标准 Fiori Elements 列表报表，而不是某个自开发的 Freestyle 页面。
2. 右上角或者筛选条区域能看到“保存视图”或类似图标的入口。
3. 登录账号已具备创建公共视图的权限；拿不准的话，先让管理员在测试环境开个测试号试一发。

不要小看这几步，在大型项目里，有一半“我保存不了公共视图”的工单，查到最后都是权限没配或者压根不是 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 在公共视图生命周期里确实有用武之地，主要在三类场景：

1. 维护自定义配置表：项目里很多自定义的视图可见范围映射、默认视图配置，我们一般会做成 Z 开头的配置表，里面的数据靠 SM30 维护。比如我们团队把“Fiori 应用 ID -> 默认公共视图 ID”映射放到 ZFIV_DEFAULT_VIEW 里，每次配新应用直接 SM30 往表里插行。
2. 传统 ABAP 变式：如果这个 Fiori 应用底层用的是 ABAP 报表（比如某些 SM30 生成的 Fiori app 或者传统 ALV 应用），那么变式很可能就存在 VARID、VARIT 里，管理员通过 SM30 能查到变式条目、能查到创建人、能清理废弃变式。
3. 排障与巡检：当公共视图出现“看不到、删不掉、有明显脏数据”时，先通过 SM30 找到对应的存储表，定位创建人和创建时间，再决定是前端口径清理还是后台补数据。直接删之前务必备份，这一点放在最后一部分踩坑里细说。

我给项目写操作手册时，一般会给管理员两条技术路径：业务界面上能管的事优先用 Fiori 界面和标准工具，比如 Key User 或应用级配置；只有标准工具覆盖不到的场景，才启用到 SM30/SE16N 这类后台维护手段，并走变更流程。

4.3 清理过期视图：怎么找、怎么删、怎么预防

公共视图发布很容易，清理却很麻烦。我不止一次在项目里看到公共视图下拉列表里躺着几十条僵尸视图，点进去一看，创建人早离职了。

清理的完整链路大概是这样：

1. 导出清单：从管理工具或后台表里导出所有公共视图清单，包含视图名、创建人、创建日期、最近使用时间（如果能拿到）。
2. 业务确认：把超过 6 个月没人用的视图清单发给对应业务部门，让他们确认哪些可以删。这一步不能省，因为你不知道哪条视图是不是某些人每周手动切换着用。
3. 删除前备份：把要删的视图完整记录导出留档，防止删除后又后悔。
4. 执行删除与验证：通过标准管理功能删除；如果是用后台手段删表，删完一定要让用户重新登录 Fiori 验证应用还能正常打开、其他公共视图不受影响。

但与其事后清理，我更推荐事前预防。预防机制有两个：一是收紧发布权限，只有核心用户能发；二是建立命名规范和申请流程，每条公共视图都有一个 Owner，Owner 离职前必须交接，否则门禁直接拒绝释放权限。这套流程配合起来，僵尸视图的数量能控制在一个很低的范围内。

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 View

6.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 和 Backup，Owner 离职必须先交接。
• 每月巡检公共视图清单，超过 6 个月未使用的进入清理流程，删前备份。
• 设置团队默认视图，统一新用户打开应用后的第一视角。
• 不用 SM30 直改前端管理的公共视图存储，优先走标准工具；必须改时做好备份和验证。
• 每季度抽出 15 分钟给核心用户做一次公共视图管理的短训，保证大家会用、敢管。

公共视图这套东西，越早纳入治理，后面越省心。我见过太多项目一开始放任自由，半年后花大力气清理僵尸视图。真要等那时候再动手，成本已经是前置管控的几十倍了。