A technical walkthrough of a Purchase Order analytics model developed and evaluated in a S/4HANA 2021 environment, using CDS, SADL virtual elements and runtime calculation.
The hardest analytical fields are often the ones that do not exist in the database
A procurement report looks straightforward on paper. Show purchase order information, highlight delivery performance, surface price variance for procurement and finance users.
The implementation gets demanding when those analytical values are not stored fields you can simply select from a table.
That was the challenge behind Z7AB_AC_PurchaseOrder, a custom CDS-based Purchase Order analytics model. The requirement included dynamic fields such as Delivery Delay and Price Variance, drawn from Purchase Order and Supplier Invoice data. Those fields had to fit the CDS model while calculating correctly at runtime.
At that point the task stops being “create a CDS view.” It becomes a coordinated design problem across data modeling, aggregation, runtime calculation and ABAP implementation.
Why SADL virtual elements matter in SAP CDS procurement analytics
SAP virtual elements exist for values that belong to the application model but are not persisted in the database. Their values are calculated at runtime by an ABAP class referenced from the CDS layer. In the SADL model used here, the calculation class implements IF_SADL_EXIT_CALC_ELEMENT_READ and supplies the requested calculated values after the underlying data has been retrieved.
For this scenario the calculation class was ZCL_7AB_PRICE_VARIANCE_CALC, providing the runtime calculation layer for Delivery Delay and Price Variance.
The CDS data model foundation used in this case is shown below.
define view entity Z7AB_AC_PurchaseOrder
as select from I_PurchaseOrder as POHeader
association to I_PurchaseOrderItem as PoItem
on POHeader.PurchaseOrder = PoItem.PurchaseOrder
{
key POHeader.PurchaseOrder,
key PoItem.PurchaseOrderItem,
POHeader.CompanyCode,
POHeader.Supplier,
PoItem.Material,
PoItem.Plant
}
Actual CDS foundation used in the case: Z7AB_AC_PurchaseOrder models Purchase Order header and item data using standard S/4HANA CDS views.
That makes the enhancement a bridge between the CDS model and ABAP runtime behaviour, exactly the kind of task where a technically plausible first draft is not enough. Data sources, associations, aggregation and mapping all have to line up.
The real complexity sits at the boundaries
The original developer feedback identified four areas that made the enhancement non-trivial.
- CDS associations are not Open SQL joins. Their use had to be validated against the actual retrieval logic.
- Aggregation required complete GROUP BY alignment so price-related calculations did not produce inconsistent results.
- FOR ALL ENTRIES logic needed source-data checks to avoid unsafe full-table reads.
- Index-based mapping using sy-tabix introduced fragility when data ordering changed.
These are not cosmetic issues. They sit at the boundaries between CDS semantics, Open SQL behaviour, runtime data mapping and analytical correctness. A program can be syntactically close and still produce unreliable analytics.
What Aceteroid generated first
Aceteroid is an SAP-focused AI development platform designed to accelerate ABAP engineering work, including code generation, modernization and optimization. It can work from existing SAP development artifacts or Functional Specifications to help teams reach a structured technical implementation faster.
Here it produced the first technical structure instead of leaving the developer to assemble every layer manually. The output included:
- A SADL exit-class foundation for the virtual elements
- Suggested standard CDS views such as I_PurchaseOrder and I_PurchaseOrderItem
- SQL aggregation over persisted Purchase Order / Supplier Invoice data using SUM and GROUP BY, while virtual-element calculations remained in the SADL/ABAP runtime layer.
- Modern ABAP declaration patterns
- Reduced procedural handling, shifting aggregation toward database-driven operations
Initial CDS and class generation took roughly 15 to 25 minutes. The value was not a single code snippet. The developer received a connected starting point spanning the CDS model, the runtime calculation class and the data-access direction.
From building the foundation to reviewing four decisions
Once the first structure existed, review could concentrate on what actually determined correctness: association handling, GROUP BY alignment, FOR ALL ENTRIES safety and stable data mapping.
This is where an SAP-specific workflow beats generic code completion. The question is not only whether the syntax is modern. It is whether the model uses the right data sources, whether aggregation preserves business meaning, whether virtual-element inputs map reliably to their outputs, and whether the runtime calculation behaves consistently across real datasets.
Those decisions surfaced earlier in the implementation cycle.
A second path: start from the Functional Specification
Instead of starting with existing CDS or ABAP logic, a developer can provide the Functional Specification. Aceteroid interprets the requirement and generates CDS views, associations and calculation logic aligned to the described scenario.
For teams working through a backlog of analytical enhancements, that changes the starting point. The functional requirement becomes a structured technical baseline faster, and the developer moves directly into validating the data model and analytical behaviour.
Both paths reach the same outcome: a reviewable SAP-specific implementation, sooner.
The numbers: 5-6 hours estimated manually, 2 to 2.5 hours measured
The senior SAP developer estimated the complete manual implementation at approximately 5 to 6 hours for a single developer. That covers CDS design, virtual-element implementation, aggregation, debugging, testing and performance validation.
Measured with Aceteroid in our S/4HANA 2021 environment:
Phase | Time |
Initial CDS and class generation | 15 to 25 minutes |
Review and logical correction | 70 to 75 minutes |
Testing and debugging | 30 to 45 minutes |
Total | Approximately 2 to 2.5 hours |
The developer estimated that approximately 80 to 85 percent of the generated implementation worked as expected on first execution. This is a developer-reported estimate of behaviour on first run, not a measured percentage of lines or objects. The remainder needed refinement around the SAP-specific decisions described above.
Why this matters for S/4HANA engineering teams
Procurement analytics is one example of a broader pattern. Many custom S/4HANA requirements sit between persistent business data and dynamic application logic. A field may need runtime calculation. An aggregation may span several business objects. A CDS model may need to stay clean while exposing application-specific insights.
Those requirements consume experienced ABAP time because they are not solved by syntax alone. They require coordination across SAP data models, CDS behaviour, runtime interfaces and business calculations.
Aceteroid moved that coordination forward quickly: generate the CDS and SADL foundation, suggest the relevant standard-view direction, structure aggregation, and hand the developer a technical baseline to review against the actual requirement.
From CDS definition to procurement intelligence
Building the CDS definition is one layer of the job. The business value appears when the model reliably exposes the analytical fields the user actually needs.
For Z7AB_AC_PurchaseOrder, that meant connecting Purchase Order and Supplier Invoice data to runtime-calculated Delivery Delay and Price Variance fields through a SADL calculation class.
The CDS view is the model. The analytical outcome is the goal.
FAQ
What is a SADL virtual element in SAP CDS?
A SADL virtual element is a field exposed through a CDS model whose value is calculated at runtime rather than stored directly in the database. In this case, virtual elements were used for analytical fields such as Delivery Delay and Price Variance, with the calculation logic handled through an ABAP class implementing IF_SADL_EXIT_CALC_ELEMENT_READ.
How much development effort did this CDS and SADL procurement analytics case require?
In this S/4HANA 2021 case, the developer estimated approximately 5 to 6 hours for manual implementation. With Aceteroid, the end-to-end work was completed in approximately 2 to 2.5 hours, including review, correction, testing, and debugging. Initial CDS and class generation took approximately 15 to 25 minutes.
What did Aceteroid generate in this use case?
Aceteroid generated the initial CDS and SADL development foundation, including standard CDS view suggestions such as I_PurchaseOrder and I_PurchaseOrderItem, the SADL exit-class structure for virtual-element calculation, SQL aggregation logic using SUM and GROUP BY, and modern ABAP declaration patterns.
Can Aceteroid work from both existing code and a Functional Specification?
Yes. In this case, Aceteroid supported two development paths: it could work from existing CDS or ABAP logic and help enhance or convert it, or it could interpret a Functional Specification and generate CDS views, associations, and calculation logic aligned with the requirement.
