Column totals in a Fiori Elements List Report with RAP: more than @Aggregation.default

"How do I show the sum of a column in my Fiori List Report?" comes up again and again in ABAP forums, and the usual first answer is "add @Aggregation.default: #SUM".

That's only half of the answer. In SAP Fiori elements for OData V4 the total row belongs to one table type, the analytical table. That table needs a service that supports data aggregation, and on ABAP that has its own RAP feature, its own annotation and its own release requirements.

This post walks through the RAP and CDS side, the Fiori elements side, and a checklist for when the total doesn't appear. Every behaviour described here is taken from SAP's RAP documentation on the SAP Help Portal and the SAP Fiori elements documentation in the SAPUI5 SDK, linked in each section. The code samples are illustrative and haven't been run on a real system, so adapt names and types to your own data model.

TL;DR

• In Fiori elements for OData V4, totals come from the analytical table. Responsive and grid tables don't calculate sums.
• On the RAP side, add @OData.applySupportedForAggregation: #FULL to the projection view header and @Aggregation.default: #SUM to each measure in the same projection view.
• SAP documents RAP analytical tables for read-only business objects on a list report page, and on recent releases only (SAP BTP ABAP environment and S/4HANA Cloud from 2511).
• Annotate amounts and quantities with @Semantics.amount.currencyCode or @Semantics.quantity.unitOfMeasure. Mixed currencies are totalled per currency in a popup.
• If the sum is missing, check $metadata for Aggregation.ApplySupported, the table type in manifest.json, the total list in your presentation variant, and the $apply in the network request.

Why the sum doesn't show in a normal List Report

The SAPUI5 documentation for SAP Fiori elements for OData V4 lists four table types: responsive table, grid table, analytical table and tree table. Responsive and analytical tables can group rows, but only the analytical table is described with data aggregation ("automatically calculate sums, averages, and other aggregate functions"), and the Table Groupings page says it directly: "For analytical tables, you can also define totals."

So switching a List Report to GridTable does not give you a totals row. You need an analytical table, and the analytical table needs an analytical service. According to Annotating a Service as an Analytical Service, that means the entity set supports @Aggregation.ApplySupported and, for ABAP-based services, all of these transformations: filter, identity, orderby, skip, top, groupby, concat and aggregate.

In RAP you don't write Aggregation.ApplySupported yourself. One CDS annotation generates it.

Check your release first

SAP calls this feature RAP analytical tables. The RAP documentation describes them as available "in read-only scenarios and on a list report page", modelled on a projection view annotated with @OData.applySupportedForAggregation: #FULL.

SAP's ABAP CodeJam material for the feature lists the availability as:

• SAP BTP, ABAP environment as of 2511
• SAP S/4HANA Cloud as of 2511
• SAP S/4HANA and SAP S/4HANA Cloud, private edition as of 2027

If the annotation isn't accepted in your system, the release is the first thing to check. An SAP Community thread on exactly this problem was resolved by moving from 2508 to a newer release.

Step 1: the interface view

Model the measures in the interface (or base) view and give every amount its currency and every quantity its unit. Fiori elements needs that reference to total each currency or unit separately.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales order items (illustrative)'
define root view entity ZI_SalesItemTotals
  as select from zsales_item
{
  key item_uuid     as ItemUUID,
      sales_order   as SalesOrder,
      customer      as Customer,
      material      as Material,
      @Semantics.amount.currencyCode: 'Currency'
      net_amount    as NetAmount,
      currency      as Currency,
      @Semantics.quantity.unitOfMeasure: 'OrderUnit'
      order_qty     as OrderQuantity,
      order_unit    as OrderUnit
}

If you need two different aggregations of the same field, for example a minimum and a maximum, the documentation's reference scenario selects the field twice under different aliases. Only one aggregate function can be used per element.

Step 2: the projection view exposed by the service

This is where the aggregation is switched on. Both annotations go on the projection view that the service definition exposes:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales item totals (illustrative)'
@Metadata.allowExtensions: true
@OData.applySupportedForAggregation: #FULL
define root view entity ZC_SalesItemTotals
  provider contract transactional_query
  as projection on ZI_SalesItemTotals
{
  key ItemUUID,
      SalesOrder,
      Customer,
      Material,
      @Aggregation.default: #SUM
      NetAmount,
      Currency,
      @Aggregation.default: #SUM
      OrderQuantity,
      OrderUnit
}

Then expose it in an OData V4 UI service:

define service ZUI_SALES_ITEM_TOTALS
  provider contracts odata_v4_ui {
  expose ZC_SalesItemTotals as SalesItem;
}

What SAP's Annotating Aggregate Functions in CDS page says about these annotations:

• The supported functions are #SUM, #MIN, #MAX, #AVG and #COUNT_DISTINCT. #MIN and #MAX also work on dates.
• Only measures can carry an aggregation annotation, and only elements with numerical data types (plus dates for min and max).
• For #SUM, use a numeric type large enough for the total.
• #COUNT_DISTINCT needs @Aggregation.referenceElement: ['...']. SAP recommends a dedicated element for it, because a single row always counts as 1.

Elements without @Aggregation.default become groupable automatically in a service with @OData.applySupportedForAggregation: #FULL, as the SAPUI5 page Defining Groupable Properties notes. You don't annotate dimensions separately.

The base view in this example has no behavior definition, so the business object is read-only, which is the scenario SAP documents. SAP's Developing Read-Only RAP Analytical Tables follows the same pattern with the /DMO/C_TRAVEL_ANA reference objects from the ABAP Flight Reference Scenario. The same page notes that CDS entities annotated for RAP analytical tables aren't enabled for extensibility.

Step 3: grouping and the totals list

By default, Fiori elements groups the records by the columns the user sees, because those are the elements in $select. If you want every row to stay at item level, SAP's documentation suggests requesting the technical key in the presentation variant:

@UI.presentationVariant: [{ requestAtLeast: [ 'ItemUUID' ],
                            visualizations: [{ type: #AS_LINEITEM }] }]
annotate entity ZC_SalesItemTotals with
{
  @UI.lineItem: [{ position: 10 }]  SalesOrder;
  @UI.lineItem: [{ position: 20 }]  Customer;
  @UI.lineItem: [{ position: 30 }]  NetAmount;
  @UI.lineItem: [{ position: 40 }]  OrderQuantity;
}

The presentation variant also decides which columns get a total. From Table Groupings:

• Without a presentation variant, every column with an aggregatable property gets a total.
• With a presentation variant, only the properties in its total list get a total. If total is missing, all aggregatable columns get one. If total is defined but empty, none do.
• The presentation variant must have a visualizations entry, or it is ignored.

So a presentation variant copied from another app with total: [] silently removes your sums. You can also set default groups and totals explicitly, for example groupBy: [ 'Customer' ], total: [ 'NetAmount' ].

Currencies and units

Totals across currencies don't make sense, and Fiori elements doesn't add them up. The same Table Groupings page explains that if a group contains several units or currencies, the table shows a Show Details link that opens a popup with the total or subtotal per unit or currency.

On the model side, the OData V4 data aggregation documentation describes how each aggregatable property can carry its unit or currency, which returns a single value when there's only one, and null in a "multi-unit situation". In RAP that reference comes from @Semantics.amount.currencyCode and @Semantics.quantity.unitOfMeasure. Without it, the framework can't tell 100 EUR from 100 USD.

If users need one grand total in a single currency, the totals have to be converted in the back end first. SAP Fiori elements also documents analytical parameters for converting to a target currency at runtime, which is beyond the scope of this post.

The table type in manifest.json

With an analytical service, you usually don't need to configure anything. Determining the Default Table Type says the List Report defaults to the analytical table when the entity set has Aggregation.ApplySupported with all the transformations listed above, and to a responsive table otherwise.

If the app was generated earlier with an explicit table type, it may still say ResponsiveTable or GridTable. Set it as described in Setting the Table Type:

"targets": {
  "SalesItemList": {
    "type": "Component",
    "name": "sap.fe.templates.ListReport",
    "options": {
      "settings": {
        "controlConfiguration": {
          "@com.sap.vocabularies.UI.v1.LineItem": {
            "tableSettings": { "type": "AnalyticalTable" }
          }
        }
      }
    }
  }
}

The documented catch: if you set AnalyticalTable and the entity set has no analytical capabilities, the result is an empty table. So a List Report that shows no rows right after a table-type change usually means the service side isn't done yet.

A few documented restrictions of analytical tables that are worth knowing before you promise them to users:

• The table only displays properties that are groupable or aggregatable. Anything else isn't requested and stays empty.
• Navigation properties aren't supported. A LineItem column pointing to one stays empty.
• Micro charts, multi-line content such as FieldGroup columns, and multi-input fields aren't supported.
• With aggregationOnLeafLevel: true, navigation and bound actions are only enabled when all key properties are visible in the table (Aggregation Based on Visible Properties).

Draft and transactional apps

This is the most common disappointment. RAP's documentation scopes RAP analytical tables to read-only business objects. The SAPUI5 SDK does describe analytical tables with a draft-enabled service: only active entities are shown, the Editing Status filter is hidden, and the combination isn't available in the flexible column layout. Those are general Fiori elements rules, though, and they don't change what RAP supports for your ABAP service.

In practice, if your users need both an editable List Report and totals, plan for a separate read-only projection and service for the analytical list, and keep the transactional app as it is. Check the ABAP platform roadmap and the release notes for your system before you design around anything newer.

Check the service before you blame the UI

Two checks take a few minutes and settle most cases.

1. The $metadata document. Open the service URL with /$metadata (from the service binding in ADT, or from the browser's network tab). On the entity set or entity type, look for the Aggregation.ApplySupported annotation and its Transformations collection. It should contain all of filter, identity, orderby, skip, top, groupby, concat and aggregate. If it's missing, @OData.applySupportedForAggregation: #FULL isn't on the projection view that is actually exposed, or the release doesn't support it. The SAPUI5 SDK's Defining Aggregatable Properties shows how an aggregatable property looks in metadata, with Aggregation.CustomAggregate qualified by the property name.

2. The data request. Open the browser's developer tools, go to the Network tab, filter for $batch, and look at the GET request for your entity set inside the batch. An analytical table doesn't send a plain $select. The OData V4 model derives a $apply system query option from the grouping and aggregation, so you should see $apply with groupby and aggregate. If you see a normal $select ... $top request with no $apply, the app isn't using the analytical table.

OData V2

Most new RAP development uses OData V4 UI services, and the RAP analytical table described above is documented for OData V4. If you maintain a Fiori elements app for OData V2, the logic for the table type is different. According to the V2 page Setting the Table Type:

• Without a configured type, an aggregate-based service gets an analytical table, and any other service gets a responsive table.
• For an analytical table on the List Report, the entity type must have sap:semantics="aggregate". That is a back-end setting.
• If you configure AnalyticalTable and the entity set has no analytical capabilities, the V2 template falls back to a grid table instead of showing an empty table.

The RAP documentation has a separate topic on the OData V2 interpretation of aggregation annotations. Check it for your release rather than assuming the V4 behaviour.

Troubleshooting checklist

1. Release. Does your system support @OData.applySupportedForAggregation? On BTP ABAP environment and S/4HANA Cloud it's 2511 or later.
2. Right view. Are both annotations on the projection view that the service definition exposes, not only on the interface view?
3. Read-only. Is the business object read-only? RAP analytical tables are documented for that scenario.
4. Numeric measures. Is the summed element numeric, with a type big enough for the total?
5. Currency and unit. Do amounts and quantities have @Semantics.amount.currencyCode or @Semantics.quantity.unitOfMeasure? Mixed currencies show "Show Details" instead of one total, which is the expected behaviour.
6. $metadata. Is Aggregation.ApplySupported present with all eight transformations?
7. Table type. Is manifest.json forcing ResponsiveTable or GridTable? Remove the setting or set AnalyticalTable. An empty table after this change points back to the service.
8. Presentation variant. Is there a total: [], or a presentation variant without visualizations?
9. Network. Does the list request contain $apply?
10. Columns. Are the columns groupable or aggregatable properties, not navigation properties?

Why AI assistants get this wrong

Ask a general-purpose AI assistant how to sum a column in a Fiori List Report and you'll often get @Aggregation.default: #SUM on its own, @DefaultAggregation from older analytical CDS views, or advice to switch to a grid table. None of these produces a totals row in an OData V4 RAP app by itself. The feature is new, depends on the release, and is spread across the RAP documentation and the SAPUI5 SDK, so it's thin in the code that models learn from.

The fix is the same as for other ABAP topics: tell the assistant your release and your OData version, and keep the rule where it reads it on every request, for example "Totals in a Fiori elements V4 List Report need a read-only RAP analytical table: @OData.applySupportedForAggregation: #FULL on the exposed projection view, plus @Aggregation.default on the measures." For more patterns like this one, see ABAP mistakes AI coding assistants make.

---

Free MIT-licensed ABAP rules for Cursor, Claude Code and Copilot are on GitHub, and there are more guides at abapforagents.com/guides.