企业官网建设流程全解析

我最近在项目里做 Dispute Case 分析时，把标准接口视图 I_CaseAttributes 翻了个底朝天，最后用一张 CDS Dimension 把案件的关键信息整理成了分析报表能直接引用的维度。今天把这条路径完整写下来。如果你也正被财务经理追着要“按案件类型、处理状态、责任人拆解纠纷案件”的报表，或者刚接触 SAP 案件管理这个领域，这篇应该能帮你省不少时间。

我先说结论：事情没有想象中复杂，但也没法靠一个普通 SQL 视图糊弄过去。标准系统里案件数据分布在很多底层表，直接 join 拼报表容易翻车，而 I_CaseAttributes 这个接口视图把案件属性的采集窗口打开了。我们要做的，是在它之上建立一张分析友好的维度视图，让上层报表工具一眼就能看懂案件的关键信息该从哪个字段取。

1. 一张有争议的发票，怎么变成分析报表里的维度

先还原一下我客户那边的场景。财务部的信用管理团队每天在 Fiori 里处理大量纠纷案件，客户会对某张发票发起争议：金额不对、重复开票、票没收到、扣款理由不认，各种情况都有。业务主管想在月底看一组全局指标：这个月开了多少案件，其中多少还在处理、多少已关闭；案件类型分布如何；责任人处理量差距大不大；争议金额集中在哪些区间。

这些指标听起来并不复杂，但真正落地时会发现，SAP 的案件管理在设计上就不是一张大宽表。一个 Dispute Case 从创建到关闭，分布在多张表里：案件头、案件方、案件状态历史、关联的发票和金额明细、处理任务和工作流记录。直接让报表组去 join 这些底层表，风险非常大：字段名不统一、状态代码需要翻译、历史状态和当前状态混在一起，而且很容易因为一对多表关系导致金额重复计算。

所以这里的关键不是“会写 SQL 就完事”，而是先找到一个稳定的业务入口。标准接口视图 I_CaseAttributes 就是这样一个入口：它把案件本身最关键的一批属性暴露出来，业务人员看到的案件编号、类型、状态、创建日期、责任人，都可以在这里找到。当我们决定要做一个多维分析报表时，合适的做法是把这些属性收敛成一张维度视图，让上层的报表查询按照统一结构去引用。

1.1 需求从“看孤案”升级为“看全局”

一开始业务提的需求是“帮我查一下 00234 号案件现在是什么状态”，这属于单案查询，用 Fiori 界面很方便。但没过多久，需求就变成了“我要看所有客户的争议处理效率”，这时候单案视角完全不够用了。分析需求的最大特点是需要多个切面同时聚合：按状态、按类型、按责任人、按客户、按金额区间，组合同一个事实进行下钻。

这正好是维度建模的用武之地。分析报表通常由两部分组成：一个可计数、可汇总的事实区，和一组用于分组的维度区。案件数量可以被计数，争议金额可以被汇总，而案件类型、处理状态、责任人、客户这些就是维度。I_CaseAttributes 本身专注描述“案件是什么样”，天然适合作为维度的一部分，而不适合直接当成事实表来用。如果你硬要在它里面找金额字段，往往只能找到案件头的一个汇总值，真正明细级的金额还在事实表里。

1.2 一张标准的案件属性视图，代替一堆零散底层表

我在项目里翻过底层表之后，最大的感受是：能标准化查询的地方，尽量不要自己拼表。原因有三个。第一，底层表结构受版本升级影响，字段在多个 Release 之间有增删，而你发布的报表不可能跟着每个版本重写。第二，接口视图经过了 SAP 语义层处理，字段命名接近业务语言，比如 CaseID、CaseType、LifeCycleStatus，而不是一堆难以理解的内部字段。第三，接口视图通常已经处理了权限和数据隔离，直接使用可以避免把授权逻辑重新实现一遍。

所以从 I_CaseAttributes 出发建立自定义维度，本质上是“站在标准语义层之上再建模”。这一步做对了，后面的报表才能稳定。很多项目一开始图省事，直接在 CDS 里引用底层表，结果上线后每次升级都要重新测试一遍数据正确性，维护成本极高。站在标准视图上，至少数据来源的稳定性是有保证的。

2. I_CaseAttributes 里到底有哪些关键字段

要基于一张视图做维度，第一步不是急着写代码，而是把这张视图的字段结构读明白。I_CaseAttributes 不是一个特别大的视图，但它的字段分为几组，每一组对应一类分析切片。

2.1 案件的生命周期回头看

我先讲一个 Dispute Case 是怎么走完整个生命周期的。假设客户对发票 8100001234 提出争议，信用专员在 Fiori 里创建一个纠纷案件，系统生成一个 CaseID，案件状态通常是“新建”或“待处理”，案件类型会被指定为“有争议的发票”或“扣款争议”等。接下来案件进入处理流程，可能指派给某个责任员工，中间状态会变成“处理中”，内部会记录负责人、联系方式、处理的业务对象。案件解决后，状态变为“已关闭”。这个生命周期中的每一个关键节点，几乎都对应了 I_CaseAttributes 里的字段。

第一次看这个视图的时候，可以按“身份标识、分类信息、状态信息、组织归属、时间戳”五个分组去梳理。这样做的价值在于，你不会被字段列表淹没，而是能快速判断：哪些字段可以做分析分组，哪些字段只是技术辅助字段。我习惯把所有字段复制到 Excel 里，一列写字段名，一列写业务含义，再标上“是否可分组”“是否可筛选”“是否建议隐藏”。这份清单到后面写报表查询时非常有用。

下面这张表是我整理时常用的模板，字段名以你实际系统的 I_CaseAttributes 为准：

2.2 哪些字段适合放进分析维度

不是所有字段都要原样搬进维度。我的选择标准很简单：这张字段是否会被业务用户用来筛选、分组或作为报表的行列标题。CaseID 适合作为维度键，但通常不适合作为分组维度，因为案件数量太多，每个值都不同，下钻意义不大。CaseType 和 LifeCycleStatus 非常适合，因为它们直接回答了“案件是什么”“流程走到哪一步”。ResponsibleEmployee、CompanyCode 也是高价值维度，可以形成组织维度和公司维度。

反过来说，像 CreatedBy 这样记录了“是谁创建”的字段，在某些场景有分析价值，但在大多数纠纷案件分析需求里，业务更关心“现在谁在处理”，而不是“当初谁录入的”。所以这类字段可以保留在维度里，但在消费视图中标记为隐藏，避免字段列表过于臃肿。我一般会在维度定义里用@Consumption.hidden: true把这类字段隐藏起来，上层报表工具就不会把它们暴露给业务用户。

2.3 怎么在 ADT 里快速查看标准视图字段

打开 ADT，在 Project Explorer 里找到你的 ABAP 项目，展开 Core Data Services 节点，用搜索框输入 I_CaseAttributes，回车后双击打开 DDL source。这时能看到整个视图的定义，字段部分在define view的花括号里。如果只想看字段清单而不看注解，也可以用 Data Preview 的前台展示；或者右键视图，选择 Go To