Was kann Nexus aus SAP extrahieren?

dab Nexus ist eine flexible SAP-Datenextraktionsplattform, die verschiedene SAP-Quelltypen unterstützt – von physischen Datenbanktabellen über semantische Datenmodelle bis hin zu SAP-Berichten. Der genaue Extraktionsumfang hängt von der SAP System-Architektur, den verfügbaren Schnittstellen, Berechtigungen und kundenspezifischen Implementierungen ab.

SAP DDIC-Datenbanktabellen

Überblick

SAP speichert Anwendungsdaten mit Objekten, die im ABAP Dictionary (DDIC) definiert sind. Je nach SAP-Release und Datenbankplattform können Daten in unterschiedlichen Tabelletypen gespeichert werden. Aus Sicht von Nexus können Daten aus SAP-Tabellen und -Views extrahiert werden, sofern sie im ABAP Dictionary verfügbar sind und über die zur Extraktion genutzte SAP-Schnittstelle zugänglich gemacht werden.

Die wichtigsten DDIC-Datenbankobjekttypen sind:

DDIC Objekttyp	Beschreibung	Typische Verwendung
Transparent Table	1:1-Abbildung zwischen DDIC-Definition und physischer Datenbanktabelle	Geschäftsanwendungsdaten
Pooled Table	Mehrere logische Tabellen werden in einem gemeinsamen Tabellpool gespeichert	SAP System/Steuerungsdaten (Legacy)
Cluster Table	Mehrere logische Tabellen werden gemeinsam in einem Datencluster gespeichert	SAP-Anwendungsdaten (Legacy)
View	Virtuelles Objekt, basierend auf einer oder mehreren Tabellen	Reporting und Datenzugriff

Hinweis Obwohl SAP S/4HANA die Verwendung von Pooled und Cluster Tables weitgehend durch Transparent Tables ersetzt hat, kann Nexus weiterhin Pooled und Cluster Tables extrahieren, sofern diese noch verfügbar sind – unter anderem auch in älteren SAP ECC-Systemen.

---

Transparent Tables

Überblick

Eine Transparent Table ist eine Datenbanktabelle, die eine 1:1-Beziehung mit der zugrundeliegenden Datenbanktabelle hat. Tabellenname, Feldnamen und Struktur im ABAP Dictionary entsprechen direkt der physischen Tabelle in der Datenbank.

Transparent Tables sind der am häufigsten genutzte SAP-Tabellentyp und enthalten den Großteil der Geschäftsanwendungsdaten.

Wichtige Eigenschaften

• Direkte Zuordnung: Eine SAP-Tabelle = eine Datenbanktabelle
• Identische Struktur im DDIC und in der Datenbank
• Unterstützt Primär- und Sekundärindizes
• Zugriff via Open SQL und Native SQL möglich
• Enthält Transaktions-, Stamm- und Organisationsdaten
• Vollständig unterstützt in SAP ECC und SAP S/4HANA

Häufige Beispiele

Kategorie	Tabelle	Beschreibung
Finance	BKPF	Buchungsbelegkopf
	BSEG	Buchungsbelegpositionen
	ACDOCA	Universal Journal
Vertrieb & Distribution	VBAK	Auftragskopf
	VBAP	Auftragspositionen
Materialwirtschaft	EKKO	Bestellkopf
	EKPO	Bestellpositionen
Stammdaten	MARA	Materialstamm
	KNA1	Kundenstamm
	LFA1	Lieferantenstamm

Pooled Tables

Überblick

Pooled Tables sind logische DDIC-Tabellen, die physisch innerhalb eines gemeinsamen Tabellpools gespeichert werden. Mehrere Pooled Tables teilen sich eine zugrundeliegende Datenbanktabelle. Diese Tabellen wurden vor allem genutzt, um Datenbankressourcen in älteren SAP-Releases zu sparen.

Wichtige Eigenschaften

• Mehrere SAP-Tabellen teilen sich eine einzige physische Datenbanktabelle
• Hauptsächlich für Systemkonfiguration und Steuerungsdaten genutzt
• Zugriff über das ABAP Dictionary
• Als Legacy-Konzept betrachtet
• In SAP S/4HANA nicht mehr verwendet

Typische Beispiele

Tabelle	Beschreibung
A003	Konditionen (ältere ECC-Systeme)
Verschiedene SAP System-Tabellen	Konfigurations- und Steuerungsdaten

Cluster Tables

Überblick

Cluster Tables sind logische DDIC-Tabellen, deren Datensätze gemeinsam komprimiert in einem einzelnen physischen Datenbankcluster gespeichert werden.

Mehrere Cluster Tables können denselben Speicherbereich nutzen.

Wichtige Eigenschaften

• Mehrere logische Tabellen im selben Datenbankcluster gespeichert
• Daten liegen im komprimierten Format vor
• Historisch zur Performance-Optimierung verwendet
• Zugriff typischerweise über ABAP Open SQL
• Legacy-Konzept; durch Transparent Tables in SAP S/4HANA ersetzt

Typische Beispiele

Tabelle	Beschreibung
BSEG	Buchungsbelegpositionen (ECC)
KONV	Konditionen (ECC)

Hinweis In SAP ECC wurden bekannte Tabellen wie BSEG als Cluster Tables umgesetzt. In SAP S/4HANA wurden diese Strukturen redesigniert und als Transparent Tables gespeichert.

Views

Überblick

Eine View ist ein virtuelles DDIC-Objekt, das auf einer oder mehreren zugrundeliegenden Tabellen basiert. Views speichern Daten in der Regel nicht selbst, sondern stellen eine logische Abbildung der Daten bereit.

Views werden typischerweise für Reporting, Analysen und vereinfachten Datenzugriff verwendet.

Wichtige Eigenschaften

• Basierend auf einer oder mehreren Tabellen
• Keine doppelte Datenspeicherung
• Unterstützt Joins und Filter
• Häufig für Reporting und Integrationen eingesetzt
• Typisch in ECC- und S/4HANA-Umgebungen

Häufige Beispiele

View-Typ	Beschreibung
Database View	Join von Datenbanktabellen
Projection View	Teilausschnitt von Feldern einer Tabelle
Maintenance View	Für Tabellenpflege genutzt
CDS View	Modernes semantisches Datenmodell in S/4HANA

CDS Views

Überblick

Core Data Services (CDS) Views sind SAPs strategische Technologie zur Definition semantischer Datenmodelle auf Datenbankebene. CDS Views ermöglichen Entwicklern und Anwendern den Zugriff auf Geschäftsdaten über wiederverwendbare, performanceoptimierte und semantisch angereicherte Views. CDS Views sind ein zentraler Bestandteil des Virtual Data Model (VDM) in SAP S/4HANA und können sowohl von SAP Fiori-Anwendungen, Analysen, OData-Services, externen Integrationen als auch Reporting-Tools genutzt werden. Für Nexus bieten CDS Views eine geschäftsorientierte Alternative zur direkten Tabellenextraktion und erlauben die Nutzung von von SAP bereitgestellten oder kundenspezifischen semantischen Modellen.

Wichtige Eigenschaften

• Semantische Datenmodellierung – Geschäftsgerechte Abbildung zugrundeliegender Datenbanktabellen.
• Database Pushdown – Verarbeitung erfolgt direkt in SAP HANA, wodurch die Performance steigt.
• Wiederverwendbare Logik – Geschäftslogik, Joins, Berechnungen und Filter werden zentral definiert und mehrfach genutzt.
• Annotationen – Metadaten unterstützen Analysen, OData-Exponierung, UI-Generierung und Berechtigungen.
• Security-Integration – Unterstützt rollenbasierten Zugriff mittels DCL (Data Control Language).
• Virtual Data Model (VDM) – Fundament der modernen Architektur für SAP-Datenzugriff.

CDS Views in SAP ECC

Die CDS-Technologie ist in neueren SAP ECC-Releases mit SAP HANA verfügbar. Typische Einsatzbereiche sind:

• Reporting und Analysen
• OData-Service-Generierung
• SAP Fiori-Anwendungen
• Vereinfachung komplexer SQL-Joins
• Datenextraktion für externe Systeme Die Einführung von CDS in ECC ist jedoch generell begrenzter als in SAP S/4HANA.

CDS Views in SAP S/4HANA

In SAP S/4HANA sind CDS Views ein zentraler Bestandteil der Architektur. SAP liefert tausende Standard-CDS Views für Geschäftsbereiche wie:

Bereich	CDS View / API Entity	ABAP CDS View Name
Finance	I_GLAccountLineItem	I_GLAccountLineItem
	I_JournalEntry	I_JournalEntry
	I_ProfitCenter	I_ProfitCenter
Vertrieb	I_SalesOrder	I_SalesOrder
	I_SalesOrderItem	I_SalesOrderItem
	I_Customer	I_Customer
Einkauf	I_PurchaseOrderAPI01	I_PurchaseOrderAPI01
	I_Supplier	I_Supplier
Material & Inventar	I_Product	I_Product
	I_MaterialStock	I_MaterialStock

Diese Views ermöglichen einen standardisierten Zugriff auf Geschäftsdaten – unabhängig von den zugrundeliegenden Tabellenstrukturen.

CDS DDIC-basierte Views vs. CDS View Entities

SAP stellt zwei Implementierungen für CDS Views bereit: CDS DDIC-basierte Views und CDS View Entities. Beide bieten Datenzugriff über Core Data Services (CDS), jedoch empfiehlt SAP CDS View Entities für Neuentwicklungen, da diese technisch optimiert und einfacher aufgebaut sind.

Ermittlung des ABAP CDS View Namens

Option 1: CDS View in SE11 prüfen

1. Öffnen Sie die Transaktion SE11.
2. Geben Sie den CDS View Namen ein (z. B. I_GLAccountLineItem).
3. Zeigen Sie die Definition an.
4. Suchen Sie nach der Annotation:

@AbapCatalog.sqlViewName: '...'

Beispiel:

@AbapCatalog.sqlViewName: 'IFIGLACCTLNITM'
define view I_GLAccountLineItem as ...

Der Wert von @AbapCatalog.sqlViewName gibt den ABAP SQL View Namen zur CDS View an.

Hinweis: Neuere CDS View Entities haben möglicherweise keinen generierten SQL View Namen. In diesen Fällen sollten Sie Option 2 verwenden, um den technischen Namen für die Operational Data Provisioning (ODP) zu bestimmen.

Option 2: Tabelle RSODPABAPCDSVIEW in SE16 prüfen

SAP pflegt im Hintergrund eine Zuordnung zwischen CDS Views und den technisch ODP-exponierten Namen in der Tabelle RSODPABAPCDSVIEW.

1. Öffnen Sie die Transaktion SE16 oder SE16N.
2. Geben Sie die Tabelle RSODPABAPCDSVIEW ein.
3. Filtern Sie nach dem CDS View Namen (z.B. I_GLAccountLineItem).
4. Starten Sie die Abfrage.

Das Ergebnis zeigt die zugehörigen CDS View Metadaten und die technischen Namen für ODP-Extraktionsframeworks.

Beispiel

CDS View	Wo der ABAP Name zu finden ist
I_GLAccountLineItem	@AbapCatalog.sqlViewName in SE11 oder Suche in RSODPABAPCDSVIEW
I_JournalEntry	@AbapCatalog.sqlViewName in SE11 oder Suche in RSODPABAPCDSVIEW
I_SalesOrder	@AbapCatalog.sqlViewName in SE11 oder Suche in RSODPABAPCDSVIEW
I_PurchaseOrderAPI01	@AbapCatalog.sqlViewName in SE11 oder Suche in RSODPABAPCDSVIEW

Empfehlung: Für SAP S/4HANA-Systeme (insbesondere neuere Releases) ist das Prüfen auf RSODPABAPCDSVIEW meist die zuverlässigste Methode, um den für Extraktion verfügbaren technischen CDS-Namen zu ermitteln

Überblick

Merkmal	CDS DDIC-basierte View	CDS View Entity
Definition Statement	DEFINE VIEW	DEFINE VIEW ENTITY
ABAP Dictionary Objekt	Zusätzliche CDS-gesteuerte DDIC View wird angelegt	Keine zusätzliche DDIC View
Architektur	CDS Entity + DDIC View	Nur CDS Entity
Aktivierungsperformance	Langsamer wegen zusätzlicher DDIC-Objektgenerierung	Verbesserte Aktivierungsperformance
SAP-Empfehlung	Nicht für Neuentwicklungen empfohlen	Empfohlen bei Neuentwicklungen
Verfügbarkeit	Unterstützt für Kompatibilität und Bestandssysteme	Bevorzugte Option in moderner ABAP-Entwicklung

CDS DDIC-basierte Views

Eine CDS DDIC-basierte View basiert technisch auf einer CDS-gesteuerten DDIC View im ABAP Dictionary und wird mit dem DEFINE VIEW-Statement definiert. Bei der Aktivierung erzeugt SAP:

• Die CDS Entity
• Eine zugehörige CDS-gesteuerte DDIC View

Dieses zusätzliche Dictionary-Objekt erhöht Komplexität und Aktivierungsaufwand.

Beispiel:

define view Z_SalesOrder
  as select from vbak
{
    key vbeln,
        erdat
}

CDS View Entities

CDS View Entities sind der Nachfolger der CDS DDIC-basierten Views. Sie werden mit dem DEFINE VIEW ENTITY-Statement definiert und generieren keine zusätzliche DDIC View. Das führt zu einer schlankeren Architektur und verbesserter Aktivierungsperformance. SAP empfiehlt CDS View Entities für Neubau.

Beispiel:

define view entity ZI_SalesOrder
  as select from vbak
{
    key vbeln,
        erdat
}

Bestehende SAP-Systeme nutzen weiterhin vor allem CDS DDIC-basierte Views, die von Nexus extrahiert werden können.

Virtual Data Model (VDM)

Das Virtual Data Model (VDM) ist eine strukturierte Sammlung von SAP CDS (Core Data Services) Views, die eine semantisch angereicherte und wiederverwendbare Datenschicht oberhalb der Datenbanktabellen bereitstellt. Das VDM organisiert CDS Views in verschiedene Schichten, um Datenzugriff, Geschäftslogik und Nutzungsszenarien zu trennen.

Das VDM besteht aus:

• Basic Views – Direkter Zugriff auf Datenbanktabellen und Bereitstellung geschäftsfreundlicher Datenmodelle.
• Composite Views – Kombinieren mehrere Basic Views und fügen Geschäftssemantik hinzu.
• Consumption Views – Anwendungsspezifische Modelle für Analysen, Reporting, APIs und SAP Fiori-Anwendungen.

Stabilitätsverträge

SAP klassifiziert viele CDS Views anhand von Stabilitätsverträgen, die das zugesicherte Kompatibilitätsniveau zwischen SAP-Releases kennzeichnen. Stabilitätsverträge helfen Kunden und Partnern dabei, zu entscheiden, ob eine CDS View für eigene Entwicklungen und Integrationen sicher verwendet werden kann. Der wichtigste Vertrag für die externe Verwendung ist:

Vertrag	Beschreibung
C1	Veröffentlicht für Kunden- und Partnernutzung. SAP garantiert eine stabile öffentliche Schnittstelle und rückwärtskompatible Änderungen innerhalb des Vertragsumfangs.

Laut SAP sind nur bestimmte CDS Views mit C1 Stabilitätsvertrag offiziell für Kunden und Partner freigegeben. Diese freigegebenen Views sind für langfristige Nutzungsszenarien gedacht und werden für Integrationen, Reporting-Lösungen und kundenspezifische Anwendungen empfohlen. Nexus kann Daten aus SAP CDS Views extrahieren – unabhängig von VDM-Schicht oder Stabilitätsvertrag.

Offizielle SAP-Referenzen

Weitere Informationen zum Virtual Data Model (VDM) und zur CDS View-Architektur finden Sie in der offiziellen SAP-Dokumentation:

• Virtual Data Model and CDS Views (SAP Help Portal)

• VDM Layers and View Types (SAP Help Portal)

Basic Views (Interface Views)

Basic Views basieren direkt auf Datenbanktabellen und sind die einzigen CDS Views mit direktem Datenbankzugriff. Sie bieten geschäftsfreundliche Feldnamen und bereichern das Datenmodell durch Metadaten und Assoziationen.

Beispiele

Datenbanktabelle	Basic CDS View	Business Object
KNA1	I_Customer	Kundenstamm
MARA	I_Product	Material/Produktstamm
VBAK	I_SalesOrder	Auftragskopf
VBAP	I_SalesOrderItem	Auftragsposition
BKPF	I_JournalEntry	Buchungsbelegkopf
BSEG	I_OperationalAcctgDocItem	Buchungsbelegposition

Beispielhafte Beziehung

KNA1
  ↓
I_Customer

Annotiert mit:

@VDM.viewType: #BASIC

Composite Views (Interface Views)

Composite Views basieren auf Basic Views und/oder anderen Composite Views. Sie kombinieren Daten aus mehreren Quellen und fügen Geschäftssemantik und Logik hinzu – ohne direkten Datenbankzugriff.

Beispiele

Composite CDS View	Beschreibung
I_SalesOrderCube	Aufträge inklusive Positionen und Kundeninformationen
I_BillingDocumentCube	Fakturakopf und Fakturapositionen
I_InventoryCube	Produkt- und Lagerbestandsinformationen
I_ProfitCenterPlanActualCube	Finanzielle Ist- und Plan-Daten

Beispielhafte Beziehung

I_SalesOrder
       +
I_SalesOrderItem
       +
I_Customer
       ↓
I_SalesOrderCube

Annotiert mit:

@VDM.viewType: #COMPOSITE

Consumption Views

Consumption Views bilden die oberste Schicht des VDM. Sie basieren auf Reuse Views (Basic und Composite Views) und sind für spezifische Business-Anwendungsfälle wie Reporting, Analysen, APIs und Anwendungen gedacht. Sie greifen indirekt über die Reuse-Schicht auf Datenbanktabellen zu.

Beispiele:

• SAP Fiori-Anwendungen
• OData-Services
• KPI-Dashboards
• Analytische Queries

Beispiele

Consumption CDS View	Verwendung
C_SalesOrderQry	Auftragsanalysen
C_BillingDocumentQry	Faktura-Analysen
C_ProfitCenterPlanActualQry	Finanz-Reporting
C_GLLineItemsQ0001	Hauptbuch-Reporting
C_ProductSalesPerformanceQry	Vertriebsleistungsanalyse

Beispielhafte Beziehung

I_SalesOrderCube
        ↓
C_SalesOrderQry
        ↓
Fiori App / OData Service / KPI Dashboard

Annotiert mit:

@VDM.viewType: #CONSUMPTION

SAP-Berichte

Nexus kann Daten aus einem SAP-Bericht extrahieren, sofern dieser automatisch ausführbar ist und die Ergebnisse über SAP GUI exportiert werden können. In der Praxis bedeutet dies, dass der Bericht:

• Als ABAP-Programm implementiert ist.
• Einen initialen Selektionsbildschirm für Parameter/Filter bietet.
• Die Ergebnisse nach Ausführung in Tabellenform darstellt.
• Ermöglicht, die Tabellenanzeige mit Standard-SAP-GUI-Funktion als Datei zu exportieren.

Nexus folgt dem gleichen Prozess wie der Nutzer in SAP GUI: Der Bericht wird ausgeführt, Selektionsparameter gesetzt und die resultierende Tabelle exportiert. Nexus extrahiert nicht den Bericht selbst – sondern die exportierten Tabellendaten. Als Faustregel gilt: Wenn der Nutzer den Bericht ausführen, Selektionsparameter eingeben, das Ergebnis als Tabelle ansehen und diese exportieren kann, ist die Extraktion durch Nexus im Regelfall möglich.

ECC vs. SAP S/4HANA Datenmodellüberlegungen

Überblick

Beim Extrahieren von Daten aus SAP-Systemen ist es wichtig zu wissen, dass SAP S/4HANA erhebliche Änderungen beim Datenmodell im Vergleich zu SAP ECC eingeführt hat. Viele traditionelle Tabellen sind in S/4HANA scheinbar weiterhin vorhanden, sind aber tatsächlich als Compatibility Views und nicht als physische Datenbanktabellen implementiert. SAP hat diese Views eingeführt, um die Rückwärtskompatibilität für bestehende Berichte, kundenspezifische Entwicklungen, Extraktoren und Integrationen sicherzustellen.

Daher können Extraktionstools wie Nexus oft weiterhin die bekannten ECC-Objekte abfragen, während sich Kunden zum S/4HANA-Modell migrieren.

Compatibility Views

Compatibility Views sind von SAP bereitgestellte CDS-basierte Views, welche die Legacy-ECC-Tabellenstrukturen auf das neue S/4HANA-Datenmodell abbilden. Sie fungieren als Abstraktionsschicht zwischen alter Anwendungslogik und neuen physischen Tabellen.

Zum Beispiel:

ECC Objekt	S/4HANA Ersatz
MSEG	MATDOC (über Kompatibilitätsansicht)
COEP	Universal Journal (ACDOCA) über Kompatibilitätsansicht
COSP / COSS	Universal Journal-Strukturen über Kompatibilitätsansichten
Verschiedene FI/CO-Tabellen	Zusammengeführt in ACDOCA
Das Ziel von SAP ist es, dass bestehender individueller Code und Integrationen nach einer Systemkonvertierung mit minimalen Anpassungen weiterhin funktionieren.

---

Wichtige Hinweise zur Extraktion

Kompatibilitätsansichten werden unterstützt

Nexus kann aus Kompatibilitätsansichten extrahieren, genauso wie aus regulären SAP-Tabellen, da SAP diese über Standard-Schnittstellen bereitstellt. Dadurch können bestehende Extraktionspakete auch nach vielen ECC-zu-S/4HANA Migrationen weiter genutzt werden.

Bevorzugen Sie native S/4HANA-Objekte, wenn möglich

Obwohl Kompatibilitätsansichten praktisch sind, empfiehlt SAP die Nutzung des neuen S/4HANA-Datenmodells, sofern möglich. Kompatibilitätsansichten dienen in erster Linie der Rückwärtskompatibilität und können zusätzliche Joins, Unions oder Geschäftsschichten enthalten.

Für neue Projekte sollten Sie folgende Objekte bevorzugen:

• CDS Views
• CDS View Entities
• Business Partner-Objekte
• Universal Journal (ACDOCA)
• Materialdokument-Tabelle (MATDOC)
• freigegebene SAP APIs und OData Services

statt ausschließlich auf legacy ECC-Strukturen zurückzugreifen.

Leistungsaspekte

Einige Kompatibilitätsansichten können deutlich komplexer sein als die ursprünglichen ECC-Tabellen, die sie abbilden. In bestimmten Fällen führen SAP-Kompatibilitätsansichten Joins und Transformationen über mehrere zugrunde liegende Objekte hinweg durch. Großvolumige Extraktionen sollten daher im Rahmen der Implementierung auf ihre Leistung geprüft werden.

Wichtige Änderungen im SAP ECC- vs. SAP S/4HANA-Datenmodell

Bereich	SAP ECC	SAP S/4HANA
Finanzbuchhaltung & Controlling	FI- und CO-Daten auf mehrere Tabellen verteilt, beispielsweise BKPF, BSEG, COEP, COSP und COSS	Finanz- und Controllingdaten werden im Universal Journal (ACDOCA) konsolidiert. Legacy-Tabellen werden häufig als Kompatibilitätsansichten umgesetzt.
Bestandsverwaltung	Materialdokument- und Bestandsinformationen verteilt auf Tabellen wie MKPF und MSEG	Bestandsbuchungen werden primär in MATDOC gespeichert. Legacy-Objekte wie MSEG werden durch Kompatibilitätsansichten bereitgestellt.
Kunden- & Lieferantenstammdaten	Separate Stammdatenobjekte für Kunden (KNA1) und Lieferanten (LFA1)	Das einheitliche Business Partner (BP)-Modell ersetzt die getrennten Konzepte für Kunden und Lieferanten.
Datenzugriffsschicht	Physische ECC-Tabellen werden direkt durch Berichte, Eigenentwicklungen und Integrationen genutzt	Viele legacy Tabellen sind als Kompatibilitätsansichten umgesetzt, die alte Strukturen auf das neue S/4HANA-Datenmodell abbilden.
Reporting-Modell	Daten häufig verteilt auf diverse anwendungsspezifische Tabellen, die Abgleiche erfordern	Vereinfachtes und harmonisiertes Datenmodell ermöglicht Echtzeitanalysen und Reporting direkt auf konsolidierten Strukturen

Extraktionsempfehlung

Für SAP S/4HANA-Systeme:

• Bestehende ECC-basierte Extraktionsszenarien funktionieren häufig weiterhin über SAP-Kompatibilitätsansichten.
• Für Neuanwendungen bevorzugen Sie CDS Views, CDS View Entities, Business Partner-Objekte, ACDOCA und MATDOC, sofern möglich.
• Validieren Sie die Extraktionsleistung, wenn Kompatibilitätsansichten verwendet werden, da einige Ansichten deutlich komplexer sein können als die zugrunde liegenden S/4HANA-Tabellen.

Erkennen, ob ein Objekt eine Kompatibilitätsansicht ist

In SAP GUI:

1. Öffnen Sie die Transaktion SE16N
2. Geben Sie den Tabellennamen ein
3. Zeigt SAP ein Proxy Object an, basiert das Objekt vermutlich auf einer Kompatibilitätsansicht
4. Wechseln Sie zu SE11, um die zugrundeliegende CDS-Definition und die involvierten physischen Tabellen einzusehen

Dies unterstützt Sie dabei festzustellen, ob eine Extraktion direkt auf eine physische Tabelle oder auf eine virtuelle Kompatibilitätsschicht zugreift.

SAP Referenzen

Für Kunden, die SAP ECC- zu SAP S/4HANA-Migrationen planen, stellt SAP umfangreiche Dokumentationen zu Kompatibilitätsobjekten und Datenmodellvereinfachungen bereit:

• SAP-Hinweis 2595627 – Kompatibilitätsansichten in SAP S/4HANA – Kompatibilitätsansichten in S/4HANA.
• SAP S/4HANA Vereinfachungsliste (SIMPL_OP2023) – Vollständiger Überblick zu S/4HANA-Datenmodell-Änderungen.
• SAP S/4HANA Migrations- und Konvertierungsleitfäden – Offizielle Leitlinien zur Migration und Konvertierung.

Diese Unterlagen enthalten detaillierte Abbildungen von veralteten ECC-Tabellen, Ersatzstrukturen und funktionellen Änderungen, die in SAP S/4HANA eingeführt wurden.