One of the biggest technical changes in the move from SAP ECC to S/4HANA is the simplified data model. Tables that ECC developers knew by heart — MKPF, MSEG, BKPF, BSEG, KNA1, LFA1 — were replaced, merged, or turned into compatibility views. If you work with S/4HANA as a developer, functional consultant, or Basis administrator, understanding the simplified tables is non-negotiable. This guide explains the concept and the three most important simplifications: MATDOC, ACDOCA, and the business partner tables.
Why Did SAP Simplify the Tables?
In ECC, the data model grew over decades. Redundant tables stored the same information in different shapes: header and item tables, plus separate index tables for fast access and aggregate tables holding pre-calculated totals. This made sense when databases were slow and disk was expensive.
SAP HANA changed the economics. An in-memory, columnar database can aggregate millions of rows on the fly, so pre-calculated totals and redundant indexes became unnecessary baggage. S/4HANA therefore removed the redundancy: fewer tables, no aggregates, and calculations done at runtime. The result is a smaller database footprint, simpler code, and real-time reporting without batch jobs building totals overnight. For teams planning a conversion, grasping this rationale makes every subsequent table change easier to accept: each simplification removes work the database no longer needs.
MATDOC: The New Material Document Table
In ECC, material documents (goods receipts, goods issues, stock transfers) were stored in two tables: MKPF for the document header and MSEG for the line items. Every goods movement wrote one header row and one row per item.
In S/4HANA, both are replaced by a single table: MATDOC. Header and item data live together in one document table, keyed by fields including the material document number (MBLNR), the fiscal year (MJAHR), and the item number (ZEILE). Custom ABAP code that joined MKPF and MSEG must be adapted to read MATDOC directly — typically a simplification, since one table replaces a join.
What happened to the old tables? SAP provides compatibility views named MKPF and MSEG that redirect reads to MATDOC, so old code does not break immediately. But these views exist for transition: new development should use MATDOC, and remediation projects should convert old reads.
ACDOCA: The Universal Journal
The most far-reaching simplification is in Finance. In ECC, financial documents were split across BKPF (accounting document header) and BSEG (line items), with a constellation of index tables (like BSIS and BSAS for open/cleared items) and total tables (like GLT0 for GL totals) alongside them.
S/4HANA replaces all of this with ACDOCA, the Universal Journal. Every financial line item — general ledger, accounts payable, accounts receivable, asset accounting, controlling — is stored as a row in ACDOCA, keyed by company code (RBUKRS), fiscal year (GJAHR), document number (BELNR), and line item (BUZEI), among other fields. Because HANA aggregates on the fly, the old total and index tables are gone; their content is derived at runtime.
For developers, the practical impact is large: any custom report reading BSIS, BSAS, or GLT0 must be rewritten against ACDOCA. For finance users, the payoff is real-time financial reporting — no more waiting for period-end batch jobs to update totals. If you work with FICO data models, pair this with our Top 40 FICO interview questions to see how the Universal Journal changed day-to-day finance work.
Business Partner Tables: BUT000 and BUT020
In ECC, customers and vendors lived in separate master tables: KNA1 for customers, LFA1 for vendors, with related tables for company-code and sales/purchasing-organization data. This split caused duplication whenever a business partner was both a customer and a vendor.
S/4HANA adopts the Business Partner concept uniformly. Master data now lives in:
- BUT000: the central business partner table, holding general data for every partner (identified by the partner number).
- BUT020: business partner addresses.
Customer-specific and vendor-specific views of this data are provided through the business partner roles, and the old KNA1/LFA1 tables exist as compatibility views redirecting to the business partner model. The mandatory migration step in S/4HANA conversions — Customer-Vendor Integration (CVI) — converts existing customers and vendors into business partners.
What Are Compatibility Views?
Compatibility views are SAP-provided CDS views named like the old tables (MKPF, MSEG, KNA1, LFA1, and others) that map reads to the new simplified tables. They exist so that custom code and standard programs written for ECC continue to function after conversion.
Important rules for developers:
- Compatibility views are for read transition, not for new development. Write new code against MATDOC, ACDOCA, and the business partner tables.
- Some views redirect cleanly; others have limitations documented in the simplification database. Always check what a view actually returns before relying on it.
- ATC (ABAP Test Cockpit) checks flag direct use of simplified-away tables in custom code — run them as part of every conversion project. Our ABAP on HANA interview guide covers the ATC checks interviewers ask about.
How Simplification Affects Custom Code
For ABAP teams, table simplification drives a concrete remediation checklist:
- Find affected code: run ATC simplification-item checks to list every program reading removed or redirected tables.
- Rewrite data access: replace MKPF/MSEG joins with MATDOC reads, BSIS/BSAS/GLT0 reads with ACDOCA selects, and KNA1/LFA1 reads with business partner tables or views.
- Remove aggregate logic: delete custom code that maintained Z-totals tables — HANA computes aggregates at runtime.
- Retest with real volumes: simplified reads behave differently at scale; performance-test with production-like data.
- Document: record which programs were changed and why, for audit and support.
Beyond the Big Three: Other Notable Simplifications
MATDOC, ACDOCA, and the business partner model get the headlines, but simplification touched many more areas:
- Material master: the material number field was extended, and material master views were consolidated. Custom code with hard-coded field lengths for material numbers is a classic conversion finding.
- Pricing and conditions: condition tables were streamlined as part of the data model cleanup.
- Credit management: ECC credit management tables were replaced by the S/4HANA credit management data model.
- Foreign trade: replaced by SAP Global Trade Services integration concepts.
- Revenue recognition: rebuilt on the new event-based model.
The full catalog lives in SAP’s simplification database — a searchable list where every simplification item documents what changed, the business impact, and the required follow-up actions. Functional and technical teams should review the items relevant to their modules before any conversion project begins.
Reading Simplified Tables Efficiently
A common beginner mistake is treating ACDOCA like BSEG — selecting huge row sets into ABAP and aggregating in loops. The HANA-era approach:
- Aggregate in the database: use ABAP SQL GROUP BY or a CDS view with aggregation so only totals travel to the application server.
- Filter on key fields: company code, fiscal year, and document number first — these align with how the table is organized.
- Use CDS views for reuse: define the joins and calculations once in a CDS view, then consume it from reports, OData services, and analytics instead of repeating SQL everywhere.
- Check before you SELECT *: ACDOCA is a wide table; selecting all columns on millions of rows is the fastest way to ruin performance.
Frequently Asked Questions
What is MATDOC in S/4HANA?
Answer: MATDOC is the single material document table in S/4HANA, replacing the ECC header table MKPF and item table MSEG. It stores goods movements with document number, year, and item as key fields.
What is ACDOCA and why is it called the Universal Journal?
Answer: ACDOCA stores all financial line items — GL, AP, AR, assets, controlling — in one table, replacing BKPF/BSEG plus the old index and total tables. Because every posting lands in one journal, reporting is consistent and real-time.
Do the old tables like KNA1 and BSEG still exist in S/4HANA?
Answer: They exist as compatibility views that redirect to the new tables (business partner tables for KNA1, ACDOCA for BSEG content). They are a transition aid, not a permanent data store.
What is CVI in S/4HANA?
Answer: Customer-Vendor Integration (CVI) is the mandatory conversion step that migrates ECC customers and vendors into the business partner data model (BUT000/BUT020) during an S/4HANA conversion.
Should new custom reports read ACDOCA directly?
Answer: Yes. New development should read the simplified tables directly — ACDOCA for finance, MATDOC for inventory movements, business partner tables for master data — and use CDS views on top of them for reusable, annotated data models.
Where do I start learning the S/4HANA data model hands-on?
Answer: Explore table structures in SE11, browse contents with SE16N, and build a CDS view over MATDOC or ACDOCA to see the simplified model in action. Our essential ABAP TCodes list covers the transactions you will use.