> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/coverage-and-quality-insights/multi-app-coverage-report/multi-app-coverage-report-sap-report-structure.md).
# Multi-App Coverage Report: SAP Report Structure
When SAP applications are included in a Multi-App Coverage Report, the report adapts its structure, hierarchy, and terminology to match SAP concepts. This page explains what the report shows, how the data is organized, and what is different compared to non-SAP coverage reports.
For information on how the report is automatically created and linked to a test cycle, see [Multi-App Coverage Report for Test Cycle](/knowledgebase/test-optimization/test-optimization-for-sap/test-recommendations-for-manual-testing/multi-app-coverage-report-for-test-cycle.md).
***
### Business Value & Key Use Cases
* **Release managers and QA leads** get a clear, transport-scoped view of which SAP business processes were covered by testing and which were not, enabling confident go/no-go decisions before moving a transport to production.
* **Test managers planning regression cycles** can identify which App Areas and Executions carry the highest untested change risk, and prioritize testing effort accordingly.
* **SAP teams running manual testing** can validate that the tests executed in a cycle actually covered the code objects changed by their transports, closing the loop between what was recommended and what was tested.
* **Program managers and stakeholders** get a business-language view of coverage, organized by functional area (Finance, HR, Sales) and process (Order-to-Cash, Procure-to-Pay), rather than raw code metrics.
***
### Data Hierarchy
The report organizes SAP coverage data across four levels of drill-down:
Level
Label
Example
1
App Area
Finance, Sales, HR
2
Execution
Order-to-Cash, Procure-to-Pay
3
Object
The modified SAP code object
4
Non-Code Object
Table/Settings modifications nested under a using object
Drilling into an App Area reveals its Executions. Drilling into a Execution reveals the specific Objects changed in the transport scope. Non-Code Objects appear nested under their using object.
A single Object can appear under more than one Execution when it is shared across processes. In that case, coverage data for the object is shown in each relevant context. Coverage percentages for Executions and App Areas are calculated based on the objects associated with them.
### Terminology
The SAP report uses **"Change Coverage"** in place of "Code Changes Coverage" across all headers, charts, and table columns. Change Coverage in SAP is weighted by execution presence: an object that appears under more Executions contributes more to the coverage calculation than one that appears under fewer. For example, if one changed object spans 10 Executions and another spans 5, and only the first is covered by a test, coverage is 67%, not 50%, because the covered object has greater business reach.
### Object Display
For each Object (Level 3) and Non-Code Object (Level 4), the object type is shown in square brackets next to the name (for example, `[TABC] Z_SALES_REPORT`) instead of a line number reference, which is not applicable in the SAP context.
Each Level 3 Object also has an info icon. Hovering over it shows the full technical path of the SAP object in a tooltip.
### Non-Code Objects and Coverage Calculations
Non-Code Objects are shown in the report to reflect their presence in the transport scope, but they are **not counted toward coverage calculations**. Only SAP code objects contribute to Change Coverage percentages.
### Overall Coverage
Overall application-level coverage is not applicable for SAP in the current version. The report reflects this as follows:
* The summary cards at the top of the report display **NA**.
* The Overall Coverage tab is present but shows no coverage data.
This is expected behavior, not an error.
### Report Metadata
In a standard non-SAP report, the metadata bar below the report title shows the number of applications included, which is clickable and opens a details popup. For SAP reports, this is replaced by two static fields, **App Name** and **Test Environment**, displayed as plain text with no link or popup.
### Search
The search box in the report searches by Execution and Object, not by App Area or other fields.
### Constraints
* SAP and non-SAP applications cannot be mixed in the same Multi-App Coverage Report.
* The TGA (Test Gap Analysis) report is not available for SAP applications.
***
### FAQ
Why does the report show "NA" for Overall Coverage instead of a percentage?
Overall application coverage is not supported for SAP in this version. Change Coverage, measured against the specific objects modified in the transport scope, is the applicable metric for SAP. This is a deliberate design decision, not a data issue.
Why does the same object appear under multiple Executions?
SAP objects are often shared across processes. When a changed object is associated with more than one Execution, it appears in each. Coverage data is shown per context, so the object's coverage status is visible wherever it is relevant.
Are Non-Code Objects tested or tracked for coverage?
Non-Code Objects are shown in the report to give visibility into the full scope of a transport's changes, but they do not contribute to coverage calculations. Only SAP code objects are counted.
Can I change the branch or build scope in a cycle-linked report?
No. The scope is derived from the cycle configuration and cannot be changed within the report.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sealights.io/knowledgebase/coverage-and-quality-insights/multi-app-coverage-report/multi-app-coverage-report-sap-report-structure.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.