An ALV report can look correct while its totals are wrong. A common cause is joining document headers to multiple items and then adding the repeated header amount. The reporting error starts in the data model; changing the ALV layout cannot repair it.
This SAP ABAP practice project turns that problem into a business specification, a small dataset and clear acceptance checks. It complements SAP ABAP training in Vizag by connecting Open SQL, internal tables, report presentation and debugging with a result you can explain.
Start with a report requirement
Imagine a procurement team wants a read-only purchase-order report showing each order’s supplier, currency and total item value. The detail view should show individual items; the summary should show one row per order and currency. For the exercise, all item values are net amounts before tax and use the same valuation basis.
Write those definitions before choosing tables or coding the layout. Real purchase-order pricing, tax, delivery costs and currency handling can be more complex. This exercise uses a fictional, simplified dataset to isolate header-item cardinality.
Define selection criteria such as an order-date range and supplier. Decide what empty results should look like, which fields users may see and whether export is permitted. These are report requirements, not details to improvise after the screen is built.
A small dataset exposes the bug
| Order | Item | Supplier | Item value | Derived order total |
|---|---|---|---|---|
| PO-A | 10 | Supplier X | ₹600 | ₹1,000 |
| PO-A | 20 | Supplier X | ₹400 | ₹1,000 |
| PO-B | 10 | Supplier Y | ₹900 | ₹900 |
The correct total item value is ₹600 + ₹400 + ₹900 = ₹1,900. The order totals are ₹1,000 for PO-A and ₹900 for PO-B. The “derived order total” column is repeated in the joined detail view to demonstrate the issue; it is not an assertion that every SAP purchase-order header stores that exact field.
If the program sums that repeated column, it obtains ₹1,000 + ₹1,000 + ₹900 = ₹2,900. PO-A has been counted twice because it has two items. Adding another valid item can make the error larger without causing an obvious SQL failure.
Choose the grain of each output
The detail report has one row per order item. The summary has one row per order and currency. Those outputs need different aggregation logic.
- Item view: display the item amount once at item grain and calculate totals from eligible item amounts.
- Order view: aggregate the eligible item amounts to order and currency, then display the derived total once.
- Supplier view: aggregate those values to supplier and currency using the same selections and eligibility rules.
Do not solve the mismatch by deleting duplicate-looking rows indiscriminately. Two legitimate items can have identical amounts and descriptions. Their item keys distinguish valid business records. Similarly, a distinct operation on an amount alone can discard legitimate repeated values.
Build the report in clear stages
- Confirm the data source. For the exercise, define header and item structures with explicit keys. In an SAP system, choose the appropriate tables, views or released APIs for its edition and development model.
- Select only required fields. Apply approved selection criteria at the appropriate layer. Avoid retrieving a large population that the report will immediately discard.
- Verify the join relationship. A header-to-item relationship is normally one-to-many. Additional supplier texts or lookup data can multiply records further if language, validity or other key conditions are incomplete.
- Create separate detail and summary structures. Give each a defined key and a named amount with currency context. Make the aggregation rule explicit.
- Validate the result before displaying it. Check the three item rows, two summary rows and ₹1,900 total in the fictional baseline.
- Add ALV presentation. Use meaningful column labels and selection context. Configure amount/currency relationships and aggregations appropriately for the chosen ALV technology.
- Retest filters and exceptions. Check a single order, a supplier selection, no matches and a second currency.
For the database-access design, use the existing ABAP Open SQL performance guide. The goal is efficient retrieval of the correct business result, not merely a short query.
Make the acceptance checks reviewable
| Test case | Expected result | What it checks |
|---|---|---|
| All baseline items | 3 detail rows; 2 order summary rows; INR total ₹1,900 | Correct grain and aggregation |
| PO-A only | 2 detail rows; 1 summary row; INR total ₹1,000 | Multi-item order is not counted twice |
| Supplier Y only | 1 detail row; INR total ₹900 | Supplier filter reaches the data selection |
| No matching order | Clear empty-result message; no previous result displayed | Empty-result handling |
| Add an order in USD | USD and INR remain separately identified unless an explicit conversion is applied | Currency semantics |
| Add two identical-value items with different item keys | Both valid items remain in the result | No accidental deduplication of business records |
These are expected results for a proposed training project, not claims that code was run in an SAP system. Build and test the implementation in your own authorised learning environment, using its supported ABAP syntax and tools.
Internal tables and tests
Select an internal-table type based on access patterns and the intended key. For example, an order-and-item lookup has different uniqueness requirements from an order-summary lookup. Declaring an unsuitable unique key may reject or collapse rows the business needs.
Separate calculation logic from report display where practical. That makes it easier to check aggregation with small inputs. Read the ABAP internal tables guide and ABAP Unit tutorial when designing those checks.
Authorisation should be part of the report design. Access to a development object or database table does not by itself establish permission to display every business record. Preserve the access rules required for the application and test the intended user context.
What to show in your ABAP portfolio
Keep the business requirement, fictional input data, expected-output tables, model diagram or notes, implementation and test evidence together. Explain the original ₹2,900 error and why the corrected total is ₹1,900. Include a filter example and a case that protects valid repeated-value items.
A clear interview explanation is: “The first report repeated an order-level measure at item grain. I separated the detail and summary definitions, aggregated eligible item values by order and currency, and checked the output against a small dataset.” That describes the cause, correction and verification.
Practise ABAP reporting with guidance
Softenant’s SAP ABAP course in Visakhapatnam covers Open SQL, internal tables, ALV reports, debugging and project-style exercises. Review the syllabus and ask about the current training system and practice arrangements before enrolling.