財(cái)務(wù)同事在 SAP GUI 里打開一張 ALV 報(bào)表，選中金額列，點(diǎn)一下求和，再按照公司代碼、幣種或者憑證類型生成小計(jì)，這套操作已經(jīng)用了很多年。真正把同一類報(bào)表遷移到 RAP 和 Fiori Elements 時(shí)，很容易出現(xiàn)一個(gè)錯(cuò)覺，以為 List Report 只是把 ALV 換了一層 Web UI，原來的求和、分組、小計(jì)自然也應(yīng)該跟著過來。真正動(dòng)手之后會(huì)發(fā)現(xiàn)，兩者的實(shí)現(xiàn)思路并不相同。經(jīng)典 ALV 更像一個(gè)擁有強(qiáng)大客戶端數(shù)據(jù)處理能力的表格控件。RAP List Report 則建立在 CDS、OData V4、SAP Fiori Elements 和 SAPUI5 的元數(shù)據(jù)驅(qū)動(dòng)體系之上。特別是涉及 aggregation 時(shí)，問題已經(jīng)不再只是某個(gè)金額列能不能點(diǎn)一下 Σ，而是 CDS 中哪些字段屬于 measure，哪些字段屬于 dimension，OData 服務(wù)是否聲明支持 aggregation，前端表格采用什么 table type，以及這個(gè)實(shí)體到底還是不是一個(gè)可以修改的事務(wù)實(shí)體。也正因?yàn)槿绱?，?ALV 遷移到 List Report 時(shí)，求和能力反而是一個(gè)很適合觀察兩套技術(shù)體系差異的切入口。經(jīng)典 ALV 的體驗(yàn)大家都很熟悉。假設(shè)報(bào)表中有人員、憑證號(hào)、幣種、金額或者數(shù)量等字段。ALV 加載數(shù)據(jù)之后，對(duì)于金額、數(shù)量、整數(shù)這類數(shù)值字段，可以直接啟用求和。多個(gè)明細(xì)行會(huì)在表格底部形成一個(gè)總計(jì)。文本字段則沒有這種數(shù)學(xué)意義，所以姓名、憑證描述、物料描述這一類字段自然不會(huì)提供 SUM。這一點(diǎn)到了 CDS 世界仍然成立，只是概念從 UI 控件能力變成了數(shù)據(jù)模型語義。SAP 對(duì) aggregation 的建模把字段大體分成兩類，一類叫 measure，