财务同事在 SAP GUI 里打开一张 ALV 报表，选中金额列，点一下求和，再按照公司代码、币种或者凭证类型生成小计，这套操作已经用了很多年。真正把同一类报表迁移到 RAP 和 Fiori Elements 时，很容易出现一个错觉，以为 List Report 只是把 ALV 换了一层 Web UI，原来的求和、分组、小计自然也应该跟着过来。真正动手之后会发现，两者的实现思路并不相同。经典 ALV 更像一个拥有强大客户端数据处理能力的表格控件。RAP List Report 则建立在 CDS、OData V4、SAP Fiori Elements 和 SAPUI5 的元数据驱动体系之上。特别是涉及 aggregation 时，问题已经不再只是某个金额列能不能点一下 Σ，而是 CDS 中哪些字段属于 measure，哪些字段属于 dimension，OData 服务是否声明支持 aggregation，前端表格采用什么 table type，以及这个实体到底还是不是一个可以修改的事务实体。也正因为如此，从 ALV 迁移到 List Report 时，求和能力反而是一个很适合观察两套技术体系差异的切入口。经典 ALV 的体验大家都很熟悉。假设报表中有人员、凭证号、币种、金额或者数量等字段。ALV 加载数据之后，对于金额、数量、整数这类数值字段，可以直接启用求和。多个明细行会在表格底部形成一个总计。文本字段则没有这种数学意义，所以姓名、凭证描述、物料描述这一类字段自然不会提供 SUM。这一点到了 CDS 世界仍然成立，只是概念从 UI 控件能力变成了数据模型语义。SAP 对 aggregation 的建模把字段大体分成两类，一类叫 measure， 从经典 ALV 到 RAP List Report，聚合、合计与分组能力如何迁移到 Fiori Elements
财务同事在 SAP GUI 里打开一张 ALV 报表，选中金额列，点一下求和，再按照公司代码、币种或者凭证类型生成小计，这套操作已经用了很多年。真正把同一类报表迁移到 RAP 和 Fiori Elements 时，很容易出现一个错觉，以为 List Report 只是把 ALV 换了一层 Web UI，原来的求和、分组、小计自然也应该跟着过来。真正动手之后会发现，两者的实现思路并不相同。经典 ALV 更像一个拥有强大客户端数据处理能力的表格控件。RAP List Report 则建立在 CDS、OData V4、SAP Fiori Elements 和 SAPUI5 的元数据驱动体系之上。特别是涉及 aggregation 时，问题已经不再只是某个金额列能不能点一下 Σ，而是 CDS 中哪些字段属于 measure，哪些字段属于 dimension，OData 服务是否声明支持 aggregation，前端表格采用什么 table type，以及这个实体到底还是不是一个可以修改的事务实体。也正因为如此，从 ALV 迁移到 List Report 时，求和能力反而是一个很适合观察两套技术体系差异的切入口。经典 ALV 的体验大家都很熟悉。假设报表中有人员、凭证号、币种、金额或者数量等字段。ALV 加载数据之后，对于金额、数量、整数这类数值字段，可以直接启用求和。多个明细行会在表格底部形成一个总计。文本字段则没有这种数学意义，所以姓名、凭证描述、物料描述这一类字段自然不会提供 SUM。这一点到了 CDS 世界仍然成立，只是概念从 UI 控件能力变成了数据模型语义。SAP 对 aggregation 的建模把字段大体分成两类，一类叫 measure，