Analytical List Page (ALP)

An analytical list page fits when users must see a pattern before they know which items to act on. The chart answers "where is the problem?", and the table underneath answers "which documents?".

• If users already know their selection and only need rows, a list report is simpler.
• If users need a chart, filters and the items on one page, use an analytical list page.
• If a role needs a summary of several topics, an overview page fits better.
• If the goal is to watch one governed KPI from the launchpad, an SAP Smart Business KPI app is the closer match.

Example: a purchasing manager at Alder Manufacturing selects the Bright Freight bar in a chart of order value by supplier and opens the late items in the narrowed table. SAP's Monitor Purchase Order Items app (F2358) follows this pattern. An analytical list page is the right choice when analysis and action belong in the same task.

An analytical list page is built from four regions, top to bottom:

1. Header: the page title, page variants and, optionally, KPI tags: short clickable labels with a KPI value that open a KPI card.
2. Visual filter bar: small charts, one per filter field, each showing a measure by dimension value. Choosing a bar or point sets the filter. A compact filter bar of classic fields is the alternative mode, kept in sync.
3. Main chart: an interactive chart of the filtered data. Selecting a chart segment narrows the table.
4. Table: the underlying items, with actions and navigation to an object page or another app.

The content area shows the chart, the table or both (the hybrid view). The defining feature of an analytical list page is that chart and table share one filter state, so every selection refines both.

In OData V2, the analytical list page has its own template and works only with analytical services; defaultContentView and defaultFilterMode set the starting view and filter mode. In OData V4, a list report gets a views setting with a primary path for the chart, a secondary path for the table and a defaultPath. If a configured path does not exist, the V4 app fails to load. An analytical list page is therefore only as good as the analytical model behind it.

A visual filter is a filter field drawn as a chart, built on the field's value help:

1. The field's ValueList annotation references a presentation variant.
2. The visual filter uses only the first measure and dimension of its first chart.
3. The chart type decides what is shown: a bar chart shows the top or bottom three values; a line chart shows the first or last six data points and needs a date or time dimension; OData V2 also offers a donut chart.
4. The user's selection becomes a filter value, which also appears in the compact filter bar.

The value help behind the visual filter must return the same records as that of the regular filter field, or selections stop synchronizing. SAP documents visual filters in OData V4 as supported with restrictions; for example, only bar and line charts are rendered, and only the first measure and dimension of the chart annotation are used. Visual filters make an analytical list page fast to explore, at the cost of extra modeling for every filter field.

Yes, depending on the OData version and the app owner:

• OData V2, your own app: the analytical list page has its own app extensions: custom actions on the table and the chart, custom filters for the compact filter bar and KPI tags, and a refresh API.
• OData V4, your own app: the analytical list page is a list report flavor, so start from the list report extension options and check in the SAPUI5 SDK which of them the ALP flavor supports.
• An SAP-delivered app: adaptation projects or key user adaptation, without modifying SAP's code; in SAP S/4HANA Cloud Public Edition, use only the extensibility options SAP documents for that edition.

Two built-in behaviors matter. In the flexible column layout, the analytical list page supports only the two-column layout with the first column expanded. When My Home is enabled, users can turn the chart into an Insights card, unless developers hide that option. Extensions of an analytical list page should stay at the edges, because the chart-table interplay is the part users value.

1. Building on a non-aggregating service. Charts need an entity set that supports aggregation; a purely transactional service cannot feed them.
2. Mistyped annotation paths. In OData V4, a wrong primary or secondary path stops the app from loading.
3. Mismatched value helps. When the visual filter and the regular filter read different records, selections drift apart.
4. Line-chart visual filters on non-date dimensions. They are not rendered; use a bar chart.
5. KPI tags that contradict KPI tiles. Different queries behind one KPI name produce different numbers.

When the main chart is empty, check in order: aggregation support on the entity set, the chart path in manifest.json, a default UI.Chart without qualifier, then the user's filters and authorizations. Most analytical list page defects are data model and annotation defects that surface in the chart.