CDS view performance issues in project accounting analytics

ERP SAP S/4HANA
, , , , , , , ,
1

We’re experiencing severe performance degradation with our custom CDS views built for project accounting analytics in S/4HANA 2020. The views are used to aggregate project costs, revenues, and profitability metrics across multiple dimensions.

The main issue is query execution time - what used to take 8-12 seconds now takes 45-60 seconds for the same data volume. We’re pulling from standard tables like PRPS, COEP, and BSEG with around 2.3M records. I’ve noticed the delta extraction annotations might not be properly configured, and I’m wondering if switching to HANA calculation views would help.

The CDS views have multiple joins and aggregations, but I’m not sure if we’re following optimization best practices. Has anyone dealt with similar performance issues in project accounting reporting? Should we be looking at view redesign or infrastructure changes?

system 2

Based on the symptoms you’re describing, here’s a comprehensive optimization approach that addresses all three key areas:

CDS View Optimization Strategy:

First, restructure your view hierarchy to minimize layers. For project accounting, you should have: 1) Basic interface views on PRPS/COEP/BSEG, 2) Composite views for calculations, 3) A single consumption view. Each additional layer adds 15-25% overhead.

Delta Extraction Configuration:

This is likely your biggest issue. Add these annotations to your consumption view:


@Analytics.dataExtraction.enabled: true
@Analytics.dataExtraction.delta.byElement: {
  lastChangedAt: 'LastChangedDateTime',
  changeDataCapture: { automatic: true }
}

Ensure your underlying tables have timestamp fields. For COEP and BSEG, use CPUDT/CPUTM or AEDAT/AEZET. Without delta extraction, you’re doing full extracts every query - with 2.3M records, that’s your 45-60 second problem.

HANA Calculation View Consideration:

Don’t switch to HANA calc views yet. While they can handle complex multi-source scenarios better, they have downsides: harder maintenance, no automatic Fiori integration, and manual security implementation. However, if after optimization you still have issues, calc views excel at: complex currency conversions, multi-level aggregations, and scenarios requiring SQL script logic.

Immediate Actions:

  1. Add @Analytics.query: true to enable query-specific optimizations
  2. Use @ObjectModel.usageType.dataClass: #MIXED for transactional-analytical hybrid
  3. Push filters down using WHERE clauses in lower view layers
  4. For project accounting, always filter on BUKRS (company code) and GJAHR (fiscal year) as early as possible
  5. Use @EndUserText.quickInfo for calculated fields to help the optimizer
  6. Check association cardinality - use [0..1] or [1] instead of [0..*] where possible

Performance Validation:

After implementing delta extraction, run a test query. First execution will still be slow (initial load), but subsequent queries should drop to 3-8 seconds. Use transaction RSRT or HANA Studio SQL console to verify execution plans. Look for “COLUMN SEARCH” instead of “COLUMN TABLE” in the plan - that indicates proper index usage.

Long-term Monitoring:

Set up HANA view analysis using transaction SUSG or /IWFND/ERROR_LOG to track query performance over time. For project accounting with growing data volumes, plan for view optimization every 6-8 months as data patterns change.

The combination of proper delta extraction, view layer reduction, and early filtering should bring your query times down to under 10 seconds for most scenarios. If specific reports still lag, those are candidates for HANA calc views or even BW extraction for historical analysis.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact scenario. The problem usually isn’t whether to use CDS vs HANA calc views - it’s about proper optimization. For project accounting, you need to check several things: 1) Are your joins using the right cardinality specifications? 2) Are you filtering early in the view stack rather than at the top level? 3) Do you have proper indexes on custom fields if you added any? HANA calculation views can perform better for very complex aggregations with multiple input sources, but they’re harder to maintain and don’t integrate as cleanly with Fiori. Before switching, I’d optimize your existing CDS views first. The delta extraction point mentioned earlier is critical - that alone could cut your execution time by 70-80%.

joshua_user 4

Tested this on S/4HANA 2021 with PRPS-based CDS views and restructuring to three-tier hierarchy cut our project accounting query runtime from 4 minutes to 40 seconds.

5

What’s your view hierarchy like? Are you stacking multiple CDS views on top of each other? I’ve found that project accounting analytics often suffer from over-layering. Sometimes consolidating 4-5 view layers into 2-3 makes a huge difference.

6

Check your HANA execution plan through HANA Studio. Navigate to the SQL console and run your view query with the execution plan enabled. Look for table scans where you should have index access, and check if your join operations are happening in the optimal order. Project accounting queries hitting COEP and BSEG are notorious for performance issues if the fiscal year and company code filters aren’t pushed down early. Also, are you using @Analytics.query: true on your consumption view? That enables additional query optimizations. And verify your session variables - sometimes SY-DATUM or SY-UNAME in WHERE clauses prevent proper optimization.

7

One thing that’s often overlooked - make sure you’re using @AccessControl.authorizationCheck: #CHECK with proper DCL (Data Control Language) definitions. Security checks can add significant overhead if not implemented correctly. Also, for project accounting specifically, consider whether you need real-time data or if a persisted view would work better for your reporting needs.