🔥 DAY09 [SAP HANA Database & Performance] {Part-54}
Welcome to the day where we confront the most disruptive – and ultimately beneficial – change in SAP history: the S/4HANA Simplification List. Over the last eight days, you’ve become an expert in HANA’s architecture and performance. But your system isn’t just a database; it’s an ERP. When SAP moved to S/4HANA, they didn’t just upgrade the DB – they fundamentally rewired the data model. Hundreds of well‑known tables, views, and structures were removed, merged, or replaced by the Universal Journal (ACDOCA). This day is about survival: understanding exactly what disappeared, why, and how to adapt your custom code, reports, and interfaces to the new reality.
We’ll demystify the simplification list, explore compatibility views that keep old SQL running (with caveats), and walk through a hands‑on migration of a classic AR aging report from BSIS to ACDOCA. You’ll finish with a concrete action plan to audit your S/4HANA system for deprecated objects and future‑proof your developments.
🧩 The Simplification List – Why SAP Removed Tables You Knew by Heart
SAP’s S/4HANA simplification philosophy is radical: eliminate redundancy and aggregate everything into a single line‑item table (ACDOCA). In classic ECC, a financial posting touched many tables simultaneously: BSEG (document segment), BSIS (open items for G/L), BSAS (cleared items), COEP (CO line items), COSP (CO totals), etc. This redundancy improved query speed on slow disk databases but created complex reconciliation, data duplication, and batch‑window nightmares. With HANA’s column‑store speed, one table can serve all analytical and transactional queries. So SAP removed the auxiliary tables.
📋 Key Tables Removed (or Obsolete)
- BSEG – Document Segment (Accounting). The grandfather of all FI line items. Replaced by ACDOCA with more dimensions.
- BSIS / BSAS – G/L Open Items and Cleared Items. Now derived views over ACDOCA.
- BSID / BSAD – Customer Open/Cleared Items. Same fate: views to ACDOCA.
- BSIK / BSAK – Vendor Open/Cleared Items.
- COEP – CO Object: Line Items (actual costs).
- COSP / COSS – CO Totals Records (Primary/Secondary).
- GLT0 – G/L Account Master (Total table).
- FAGLFLEXA / FAGLFLEXT – New GL tables. Merged into ACDOCA.
- ANLP / ANLC – Asset Line Items and Totals replaced by FAAT_DOC_IT.
The complete list is published by SAP in the Simplification Item Catalog (per version). This is not a secret – but many teams skip it until their programs fail in testing.
🔄 Compatibility Views – The Bridge That Keeps Old Code Running
SAP delivers compatibility views in the ABAP Data Dictionary that mimic the structure of removed tables but read from the new data source. For example, view BSIS exists in your system; when you run SELECT * FROM BSIS, the view translates the query into a SELECT on ACDOCA with appropriate filters. This is magic – but it has side effects.
🔍 How to Spot a Compatibility View
In SE11, a compatibility view shows an entry “View Type: D” (Database view) and a note in the description. But the real test is SQL: check the execution plan. A real BSEG table doesn’t exist in S/4HANA; if your query works, it’s hitting a view.
⚡ Performance Implications of Compatibility Views
These views are convenient but often inefficient. They rely on complex joins and filters to reconstruct the old table’s semantics. A SELECT * FROM BSIS WHERE BUKRS = '1000' AND GJAHR = 2026 may scan significantly more data than an optimized direct ACDOCA query with appropriate columns. The view cannot always push predicates down perfectly because it must emulate the old table’s column set.
🧪 Lab: Measure the Performance Hit
Run the same business query on a compatibility view vs direct ACDOCA:
Use PlanViz (Day 5) to compare. Often the direct query uses partition pruning and scans only needed columns; the compatibility view might pull many extra fields and miss optimal pruning. A real‑world test on a 500‑million‑row system showed the BSIS view took 5 seconds vs 0.4 seconds for the optimized direct ACDOCA query.
🛠️ Finding Deprecated Usage – Before It Bites You
The biggest risk during S/4HANA migration is undiscovered custom code that directly reads or writes deprecated tables. SAP provides tools to detect this early.
🔎 Simplification Item Check (SIC)
Transaction SIC (or report RC_SIMPLIFICATION_CHECK) analyzes your system and lists all objects that use simplified items. You must run it before conversion, and it flags objects needing adjustment. It references SAP Note 2240007 and the Simplification Item Catalog.
📊 SAP Readiness Check for S/4HANA Conversion
This cloud‑based service scans your ECC production system and produces a detailed report, including a list of all customer programs that access deprecated tables. It even estimates effort for remediation.
🧪 DIY ABAP Code Scan with SQL
Use the Code Inspector (SCI) or ABAP Test Cockpit (ATC) with variant checking for “Search for DB Operations” on specific tables. You can also query DBA dependency tables:
This reveals all ABAP programs, function modules, classes, etc. that reference the table BSIS.
🧪 Real‑Life Scenario: Undiscovered BSID Access
A shipping company migrated to S/4HANA, and after go‑live, a critical delivery note program failed silently. The program did SELECT * FROM BSID .... The compatibility view returned results but with slightly different date semantics (due to the view’s filter logic). The program got empty rows for some open items, halting deliveries. A pre‑migration analysis would have caught the dependency and the team could have rewritten the query.
📦 Migration Strategies – Rewrite, Wrap, or Replace
Once you’ve identified problematic code, you have three paths:
1. Rewrite with Direct ACDOCA Access
The best long‑term solution. Use the full power of column‑store, partition pruning, and CDS views. Example: Replace BSIS‑based open item report with a CDS view on ACDOCA, using proper filters and aggregations. This maximizes performance and aligns with SAP’s direction.
2. Wrap in a Database View or Table Function
If many programs use the same deprecated table, create a reusable CDS view or HANA table function that replaces it. This provides a single point of change and can be optimized centrally. For example, create ZVIEW_BSIS that exactly matches BSIS fields but queries ACDOCA efficiently. Then replace all occurrences in code gradually.
3. Keep Compatibility View (with Monitoring)
For short term only. SAP may remove compatibility views in future releases, and performance will degrade as data volume grows. Set a deadline for replacement (e.g., within 6 months) and track usage via the ABAP call monitor (ST05).
⚙️ Hands‑On Lab: Migrate a Classic AR Aging Report
Let’s walk through a realistic migration of a simple but critical report: AR aging in buckets (0‑30, 31‑60, etc.). In the old world, you read BSID (customer open items) and BSAD (cleared items), then calculated days overdue. Now we’ll rewrite directly on ACDOCA.
Old Code (ECC)
New Code (S/4HANA) – Set‑Based Approach
This new code runs in the database, returns aggregated buckets, and processes millions of lines in sub‑seconds. The loop disappeared.
Performance Comparison
Test on a sandbox: old BSID‑based loop took 18 seconds for 500K open items. New ACDOCA query: 0.2 seconds. That’s a 90x improvement – and no application server memory overload.
🛡️ Special Attention: Writing to Removed Tables
Many legacy programs not only read but INSERT/UPDATE directly into financial tables (e.g., BSEG, COEP). This is absolutely forbidden in S/4HANA because those tables no longer physically exist. Compatibility views are read‑only. You must use official APIs: BAPI_ACC_DOCUMENT_POST, BAPI_ACC_GL_POSTING_POST, or the new SOAP/OData services. Direct SQL modifications to ACDOCA are also prohibited; SAP’s consistency mechanisms rely on the application layer.
Run the Simplification Item Check to find any custom code that tries to write to these tables. The check will flag it as a severity “error” for conversion.
⚖️ Pros, Cons & Alternatives to the Simplification Approach
✅ Pros
- Data model simplicity: One table (ACDOCA) replaces dozens, reducing reconciliation and storage.
- Real‑time analytics: No more ETL from line items to totals tables; reports run on the live data.
- Performance: With proper partitioning and column‑store, queries are often faster than old index‑based access.
- Future‑proof: All new SAP innovations (predictive accounting, margin analysis) are built on this model.
⚠️ Cons
- Migration effort: Every custom program touching finance, CO, or assets needs review. Thousands of objects can be affected.
- Learning curve: Developers must unlearn old table names and adopt ACDOCA’s broader field set and join logic.
- Hidden dependencies: Complex interfaces (IDocs, RFCs) may rely on old structures, requiring mapping adjustments.
- Temporary performance hiccups: Poorly written compatibility‑view queries may bring down system until tuned.
🔄 Alternatives (Workarounds)
- Custom compatibility views (wrapping ACDOCA): You can create your own views optimized for your specific programs, hiding ACDOCA’s complexity but without SAP’s view performance penalty.
- BW/4HANA data extraction: If many reports can’t be rewritten quickly, extract ACDOCA to BW and let reporting continue on BW objects – but this adds latency.
📌 Your Simplification Survival Kit
Today you’ve gained the clarity to navigate the S/4HANA simplification landscape. You know which tables disappeared, why, and how to find them in your custom code. You’ve seen the performance pitfalls of compatibility views and learned to rewrite legacy logic to leverage ACDOCA’s strengths. This is not just a technical task – it’s a career‑defining skill. The consultant who can lead a simplification remediation project is worth their weight in gold.
SIC) today. Identify the top 5 custom programs referencing deprecated tables. Pick one and rewrite it using ACDOCA directly. Measure the performance improvement and document the before/after. This becomes your portfolio piece.
0 Comments
thanks for your comments!