DEV Community: ABAP for Agents

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

ABAP for Agents — Tue, 27 Oct 2026 10:14:45 +0000

"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

Release. Does your system support @OData.applySupportedForAggregation? On BTP ABAP environment and S/4HANA Cloud it's 2511 or later.
Right view. Are both annotations on the projection view that the service definition exposes, not only on the interface view?
Read-only. Is the business object read-only? RAP analytical tables are documented for that scenario.
Numeric measures. Is the summed element numeric, with a type big enough for the total?
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.
$metadata. Is Aggregation.ApplySupported present with all eight transformations?
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.
Presentation variant. Is there a total: [], or a presentation variant without visualizations?
Network. Does the list request contain $apply?
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.

9 ABAP mistakes AI coding assistants keep making (and how to prevent them)

ABAP for Agents — Tue, 27 Oct 2026 10:14:31 +0000

AI coding assistants are great at languages with millions of public examples. ABAP isn't one of them, and it trips them up in two specific ways:

The language changes a lot between releases. Code that activates on S/4HANA 2023 can be a syntax error on an ECC system running SAP_BASIS 7.50.
Most of what you call lives inside SAP systems, not on GitHub. Function modules, BAPIs, CDS views and tables aren't public, so the model can't check whether they exist. It guesses, and the guesses look convincing.

The result is a small set of mistakes that come back again and again, whether you use Cursor, Claude Code or GitHub Copilot. Here are nine of them, with the fix for each.

TL;DR

Tell the assistant your language version, product and SAP_BASIS release first. Most wrong ABAP is valid syntax from a different release.

Guard every FOR ALL ENTRIES with IF itab IS NOT INITIAL.

Plausible names prove nothing. Verify every SAP object the assistant uses.

Table expressions don't set sy-subrc, BAPIs report errors in RETURN, and RAP owns the LUW.

Put these points in a short rules file and keep ATC and ABAP Unit as the real gate.

1. Syntax from the wrong release

The assistant doesn't know which system you're on, so it writes the newest syntax it has seen. Some availability dates worth knowing (from SAP's ABAP Keyword Documentation release notes):

Feature	Available from
Inline declarations `DATA(...)`, `NEW`, `VALUE`, table expressions	7.40 SP02
ABAP SQL `@` host variables, comma-separated lists (strict mode)	7.40 SP05
Inline target `INTO TABLE @DATA(...)` in ABAP SQL	7.40 SP08
`xsdbool( )`, `REDUCE`, `FILTER`	7.40 SP08
`RAISE EXCEPTION NEW`	7.52
Calculation assignments `+=`, `-=`	7.54
CDS view entities `define view entity`	7.55

ECC 6.0 runs on SAP_BASIS 7.50 at most (EHP8), so x += 1. won't compile there, and neither will a view entity. On 7.40 SP05 to SP07, this is a syntax error:

SELECT vbeln, erdat FROM vbak
  WHERE erdat >= @date_from
  INTO TABLE @DATA(orders).   " needs 7.40 SP08

The SP05-safe version declares the target first:

TYPES: BEGIN OF ty_order,
         vbeln TYPE vbak-vbeln,
         erdat TYPE vbak-erdat,
       END OF ty_order.
DATA orders TYPE STANDARD TABLE OF ty_order WITH EMPTY KEY.

SELECT vbeln, erdat FROM vbak
  INTO TABLE @orders
  WHERE erdat >= @date_from.

Prevention: give the assistant three facts before it writes a line: language version (ABAP for Cloud Development or Standard ABAP), product (S/4HANA or ECC) and release. If you can't, tell it to assume the lowest plausible release and never mix syntax from different releases in one answer.

2. FOR ALL ENTRIES on an empty table

This one activates fine and passes a quick test, which is why it's dangerous. If the internal table after FOR ALL ENTRIES IN is empty, the whole WHERE clause is ignored and every row of the database table is read.

IF keys IS NOT INITIAL.
  SELECT vbeln, erdat FROM vbak
    FOR ALL ENTRIES IN @keys
    WHERE vbeln = @keys-vbeln
    INTO TABLE @DATA(orders).
ENDIF.

FOR ALL ENTRIES also removes duplicate result rows, so select all key fields or you lose data silently. There's a full walkthrough in FOR ALL ENTRIES with an empty table.

3. Invented function modules, BAPIs and CDS views

Z_GET_ORDER_STATUS, I_SomethingView, BAPI_WHATEVER: invented names follow SAP's naming conventions, so they read as real. A model will also invent parameter names for function modules that do exist.

Prevention: require the assistant to name every SAP object it relies on and to flag the ones it isn't sure about. Then check them yourself: "Open ABAP Development Object" in ADT, SE37/SE24/SE11 in SAP GUI, or SAP's Cloudification Repository for the release state. In ABAP Cloud only released objects are allowed, and an I_ prefix is not proof of either existence or release.

4. Checking sy-subrc after a table expression

Models trained on classic READ TABLE code write this:

DATA(item) = items[ id = key ].
IF sy-subrc <> 0.       " never reached on a miss
  ...
ENDIF.

A table expression doesn't set sy-subrc. If the line isn't found it raises CX_SY_ITAB_LINE_NOT_FOUND, and without a TRY block the program dumps. Use one of these instead:

IF line_exists( items[ id = key ] ).
  ...
ENDIF.

" 7.40 SP08+: initial value instead of an exception
item = VALUE #( items[ id = key ] OPTIONAL ).

(The exception: ASSIGN items[ id = key ] TO <item>. does set sy-subrc and raises nothing.)

5. Java, C# and JavaScript habits

ABAP looks enough like other languages for the model to slip:

IF a != b.          " wrong: ABAP uses <>
i++.                " wrong: no ++ operator
s = "text".         " wrong: " starts a comment

The correct forms are IF a <> b., i = i + 1. (or i += 1. from 7.54) and s = `text`. with backquotes or single quotes. There is no null either: use IS INITIAL or IS NOT BOUND. And RETURN value. only exists in functional methods from 7.58 (ABAP Cloud 2211); below that, assign the returning parameter and then RETURN.

6. boolc( ) instead of xsdbool( )

boolc( ) returns a string, not abap_bool, which can surprise you in comparisons. xsdbool( ) returns type c length 1 and works with abap_true / abap_false:

DATA(is_late) = xsdbool( due_date < today ).
IF is_late = abap_true.
  ...
ENDIF.

7. Classic ABAP inside ABAP Cloud

In ABAP for Cloud Development, sy-datum, WRITE, SUBMIT, CALL TRANSACTION, direct reads of SAP tables like VBAK and non-released function modules are not allowed. Assistants reach for them first because that's what most public ABAP looks like. For the date, use the released class:

DATA(today) = cl_abap_context_info=>get_system_date( ).   " UTC

That returns the system date in UTC. For the user's local date, SAP points to the XCO library with the user time zone.

8. COMMIT WORK inside a RAP handler

In the ABAP RESTful Application Programming Model (RAP), the framework owns the logical unit of work. COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES and ROLLBACK ENTITIES don't belong in behavior handler or saver methods. Errors go back through the failed and reported structures, not through MESSAGE or exceptions. Many classic BAPIs commit internally, so they must not be called in the interaction phase either.

9. Ignoring the BAPI RETURN table

BAPIs don't raise exceptions or set sy-subrc for business errors. They fill a RETURN table, so read it:

DATA return TYPE STANDARD TABLE OF bapiret2 WITH EMPTY KEY.
" ... call the BAPI, passing return ...
IF line_exists( return[ type = 'E' ] ) OR line_exists( return[ type = 'A' ] ).
  " handle the error, do not commit
ENDIF.

Commit separately with BAPI_TRANSACTION_COMMIT, and not once per record inside a loop.

How to stop repeating these corrections

You can paste these reminders into every prompt, but it's easier to put them in the file your tool reads automatically:

Cursor: project rules in .cursor/rules/*.mdc (setup guide)
Claude Code, Codex and other agents: AGENTS.md, imported from CLAUDE.md (guide)
GitHub Copilot: .github/copilot-instructions.md plus path-specific instructions (guide)

Keep these files short. Every always-on line costs context, and long instruction files are followed less reliably. A good rules file states the target release, forbids invented objects, lists the traps above and ends with a self-check the assistant runs before answering.

Rules are guidance, not enforcement. The assistant can still ignore them, so keep the syntax check, ATC and ABAP Unit as your gate, and run them on everything AI-generated before it reaches a transport.

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