Was kann Nexus aus SAP extrahieren?

dab Nexus ist eine flexible Plattform zur SAP-Datenextraktion, die verschiedene SAP-Quelltypen unterstützt – von physischen Datenbanktabellen bis hin zu semantischen Datenmodellen und SAP-Berichten. Der genaue Extraktionsumfang richtet sich nach der SAP System-Architektur, den verfügbaren Schnittstellen, Berechtigungen und kundenspezifischen Implementierungen.

SAP DDIC-Datenbanktabellen

Überblick

SAP speichert Anwendungsdaten mithilfe von Objekten, die im ABAP Dictionary (DDIC) definiert sind. Je nach SAP-Release und Datenbankplattform können Daten in unterschiedlichen Tabellentypen abgelegt werden. Aus der Perspektive von Nexus können Daten aus SAP-Tabellen und -Sichten extrahiert werden, sofern diese über das ABAP Dictionary freigegeben sind und über die für die Extraktion genutzte SAP-Schnittstelle zugänglich sind.

Die wichtigsten DDIC-Datenbankobjekttypen sind:

DDIC-Objekttyp	Beschreibung	Typische Verwendung
Transparente Tabelle	1:1-Abbildung zwischen DDIC-Definition und physischer Datenbanktabelle	Geschäftsanwendungsdaten
Pooled Table	Mehrere logische Tabellen im gemeinsamen Tabellenpool	SAP System/Steuerungsdaten (Legacy)
Cluster Table	Mehrere logische Tabellen im gemeinsamen Datencluster	SAP-Anwendungsdaten (Legacy)
View	Virtuelles Objekt basierend auf einer oder mehreren Tabellen	Reporting und Datenzugriff

Hinweis Auch wenn SAP S/4HANA heute Pooled und Cluster Tables weitgehend durch transparente Tabellen ersetzt hat, kann Nexus weiterhin auf Pooled und Cluster Tables zugreifen, wo diese verfügbar sind – etwa in älteren SAP ECC-Systemen.

---

Transparente Tabellen

Überblick

Eine transparente Tabelle hat eine 1:1-Beziehung zur zugrundeliegenden Datenbanktabelle. Der Tabellenname, die Feldnamen und die Struktur im ABAP Dictionary entsprechen direkt der physischen Tabelle in der Datenbank.

Transparente Tabellen sind der meistgenutzte Tabellentyp in SAP und enthalten den Großteil der Geschäftsanwendungsdaten.

Haupteigenschaften

• Direkte Zuordnung: Eine SAP-Tabelle = Eine Datenbanktabelle
• Gleiche Struktur im DDIC und der Datenbank
• Unterstützung von Primär- und Sekundärindizes
• Zugriff via Open SQL und Native SQL
• Enthält Transaktions-, Stamm- und Organisationsdaten
• Voll unterstützt in SAP ECC und SAP S/4HANA

Typische Beispiele

Kategorie	Tabelle	Beschreibung
Finance	BKPF	Buchungsbeleg-Kopf
	BSEG	Buchungsbeleg-Positionen
	ACDOCA	Universal Journal
Sales & Distribution	VBAK	Verkaufsauftrag Kopf
	VBAP	Verkaufsauftrag Positionen
Materials Management	EKKO	Bestellkopf
	EKPO	Bestellpositionen
Master Data	MARA	Material-Stamm
	KNA1	Kunden-Stamm
	LFA1	Lieferanten-Stamm

Pooled Tables

Überblick

Pooled Tables sind logische DDIC-Tabellen, die physisch in einem gemeinsamen Tabellenpool gespeichert werden. Mehrere Pooled Tables nutzen dabei dieselbe zugrundeliegende Datenbanktabelle. In älteren SAP-Releases wurden diese Tabellen vorrangig zur Reduzierung von Datenbankressourcen eingesetzt.

Haupteigenschaften

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

Typische Beispiele

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

Cluster Tables

Überblick

Cluster Tables sind logische DDIC-Tabellen, deren Datensätze gemeinsam als komprimierter Datencluster in einer einzigen physischen Datenbanktabelle gespeichert werden.

Mehrere Cluster Tables können dabei denselben Speicherbereich nutzen.

Haupteigenschaften

• Mehrere logische Tabellen im gemeinsamen Datenbank-Cluster gespeichert
• Daten in komprimiertem Format abgelegt
• Ursprünglich zur Performance-Optimierung eingesetzt
• Zugriff typischerweise über ABAP Open SQL
• Legacy-Konzept, ersetzt durch transparente Tabellen in SAP S/4HANA

Typische Beispiele

Tabelle	Beschreibung
BSEG	Buchungsbeleg-Positionen (ECC)
KONV	Konditionen (ECC)

Hinweis In SAP ECC waren bekannte Tabellen wie BSEG als Cluster Tables implementiert. In SAP S/4HANA wurden diese Strukturen neu gestaltet und als transparente Tabellen abgelegt.

Views

Überblick

Eine View ist ein virtuelles DDIC-Objekt, das auf einer oder mehreren zugrunde liegenden Tabellen basiert. Views speichern nicht zwangsläufig Daten selbst, sondern bieten eine logische Sicht auf die Daten.

Views werden häufig für Reporting, Analysen und vereinfachten Datenzugriff verwendet.

Haupteigenschaften

• Basis auf einer oder mehreren Tabellen
• Keine doppelte Datenspeicherung
• Unterstützung von Joins und Filterungen
• Häufig genutzt für Reporting und Integrationen
• Gängig in ECC und S/4HANA-Umgebungen

Typische Beispiele

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

CDS Views

Überblick

Core Data Services (CDS) Views sind die strategische SAP-Technologie zur Definition semantischer Datenmodelle auf Datenbankebene. CDS Views ermöglichen Entwicklern und Anwendern Zugriff auf Geschäftsdaten über wiederverwendbare, performanceoptimierte und semantisch angereicherte Views. Sie sind ein fundamentaler Bestandteil des Virtual Data Model (VDM) in SAP S/4HANA und können von SAP Fiori-Anwendungen, Analyse-Tools, OData-Services, externen Integrationen und Reporting-Werkzeugen genutzt werden. Für Nexus bieten CDS Views eine geschäftsorientierte Alternative zur Tabellenextraktion und erlauben die Datenaufnahme über von SAP bereitgestellte oder kundenspezifische semantische Modelle.

Haupteigenschaften

• Semantische Datenmodellierung – Geschäftsfeld-orientierte Darstellung der zugrunde liegenden Datenbanktabellen.
• Database Pushdown – Die Verarbeitung erfolgt direkt in SAP HANA, was die Performance verbessert.
• Wiederverwendbare Logik – Geschäftslogik, Joins, Berechnungen und Filter werden einmal definiert und mehrfach genutzt.
• Annotationen – Metadaten-Annotationen ermöglichen Analytics, OData-Expose, UI-Generierung und Berechtigungen.
• Integration von Sicherheit – Unterstützung rollenbasierter Zugriffskontrolle mittels DCL (Data Control Language).
• Virtual Data Models (VDM) – Fundament der modernen SAP-Datenzugriffsarchitektur.

CDS Views in SAP ECC

Die CDS-Technologie steht in neueren SAP ECC-Releases auf SAP HANA zur Verfügung. Typische Einsatzbereiche sind:

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

CDS Views in SAP S/4HANA

In SAP S/4HANA sind CDS Views ein Kernbestandteil der Anwendungsarchitektur. 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
Sales	I_SalesOrder	I_SalesOrder
	I_SalesOrderItem	I_SalesOrderItem
	I_Customer	I_Customer
Procurement	I_PurchaseOrderAPI01	I_PurchaseOrderAPI01
	I_Supplier	I_Supplier
Material & Inventory	I_Product	I_Product
	I_MaterialStock	I_MaterialStock

Diese Views bieten standardisierten Zugang zu Geschäftsdaten bei gleichzeitiger Abstraktion der zugehörigen Tabellenstrukturen.

CDS DDIC-basierte Views vs. CDS View Entities

SAP stellt zwei CDS-View-Implementierungen bereit: CDS DDIC-basierte Views und CDS View Entities. Beide greifen über Core Data Services (CDS) auf Daten zu, SAP empfiehlt aber CDS View Entities für Neuentwicklungen, da sie technisch verbessert und einfacher aufgebaut sind.

Ermittlung des ABAP CDS View-Namens

Möglichkeit 1: CDS View in SE11 prüfen

1. Öffnen Sie 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 ist der ABAP SQL View Name des CDS View.

Hinweis: Neuere CDS View Entities haben ggf. keinen generierten SQL View Name. In diesem Fall nutzen Sie Option 2, um den technischen Namen mithilfe des Operational Data Provisioning (ODP) zu bestimmen.

Möglichkeit 2: Tabelle RSODPABAPCDSVIEW in SE16 prüfen

SAP pflegt eine Zuordnung zwischen CDS Views und den im ODP verwendeten technischen Namen in der Tabelle RSODPABAPCDSVIEW.

1. Öffnen Sie 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.

Die Ergebnisse zeigen die Metadaten zur CDS View sowie die technischen Namen für ODP-Extraktionsframeworks.

Beispiel

CDS View	Wo finde ich den ABAP-Namen
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: Insbesondere bei neuen SAP S/4HANA-Systemen ist die Prüfung von RSODPABAPCDSVIEW meist die zuverlässigste Methode zur Identifizierung des technischen CDS-Namens für die Extraktion.

Überblick

Eigenschaft	CDS DDIC-basierte View	CDS View Entity
Definition Statement	DEFINE VIEW	DEFINE VIEW ENTITY
ABAP Dictionary-Objekt	Erzeugt zusätzlich CDS-managed DDIC View	Kein zusätzliches DDIC-View-Objekt
Architektur	CDS Entity + DDIC View	Nur CDS Entity
Aktivierungsperformance	Langsamer wegen DDIC-Objekt	Verbesserte Performance
SAP-Empfehlung	Für Neuentwicklung obsolet	Für Neuentwicklung empfohlen
Verfügbarkeit	Für Kompatibilität und bestehende Systeme unterstützt	In moderner ABAP-Entwicklung bevorzugt

CDS DDIC-basierte Views

Technisch basieren CDS DDIC-basierte Views auf einer CDS-managed DDIC View im ABAP Dictionary und werden mit dem DEFINE VIEW-Statement definiert. Bei Aktivierung erzeugt SAP:

• Die CDS Entity
• Ein zugehöriges CDS-managed DDIC View

Dieses zusätzliche Dictionary-Objekt erhöht die Komplexität und den 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. Die Definition erfolgt mit dem DEFINE VIEW ENTITY-Statement und es wird kein zusätzliches DDIC View generiert. Das führt zu einer schlanken Architektur und besserer Performance bei der Aktivierung. Für Neuentwicklungen empfiehlt SAP CDS View Entities.

Beispiel:

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

Für bestehende SAP-Systeme sind CDS DDIC-basierte Views weiterhin weit verbreitet und können durch Nexus extrahiert werden.

Virtual Data Model (VDM)

Das Virtual Data Model (VDM) ist eine strukturierte Sammlung von SAP CDS Views, die eine semantisch angereicherte und wiederverwendbare Datenschicht über Datenbanktabellen bietet. Das VDM gliedert CDS Views in verschiedene Layer, um Datenzugriff, Geschäftslogik und Nutzungsszenarien zu trennen.

Das VDM besteht aus:

• Basis Views – Direkter Zugriff auf Datenbanktabellen, angereicherte geschäftsfreundliche Datenmodelle.
• Composite Views – Kombinieren mehrere Basis Views und erweitern sie um Business-Semantik.
• Consumption Views – Anwendungsbezogene Modelle für Analysen, Reporting, APIs und SAP Fiori-Anwendungen.

Stability Contracts

SAP klassifiziert viele CDS Views anhand von Stability Contracts, die die garantierte Kompatibilitätsstufe für künftige Releases beschreiben. Stability Contracts helfen Kunden und Partnern, CDS Views sicher in eigenen Entwicklungen und Integrationen wiederzuverwenden. Der wichtigste Vertrag für externe Nutzung ist:

Vertrag	Beschreibung
C1	Freigegeben für Kunden und Partner. SAP garantiert ein stabiles Interface und rückwärtskompatible Weiterentwicklung im Vertragsumfang.

Laut SAP sind nur CDS Views mit C1 Stability Contract offiziell für die Wiederverwendung freigegeben. Diese Views sind für langfristige Nutzungsszenarien vorgesehen 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 Stability Contract.

Offizielle SAP-Referenzen

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

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

• VDM Layer und View-Typen (SAP Help Portal)

Basis Views (Interface Views)

Basis Views werden direkt auf Datenbanktabellen aufgebaut und sind die einzigen CDS Views mit direktem Datenbankzugriff. Sie bieten geschäftsfreundliche Feldnamen und bereichern das Datenmodell durch Metadaten und Beziehungen.

Beispiele

Datenbanktabelle	Basis CDS View	Geschäftsobjekt
KNA1	I_Customer	Kunden-Stamm
MARA	I_Product	Material-/Produkt-Stamm
VBAK	I_SalesOrder	Verkaufsauftrag Kopf
VBAP	I_SalesOrderItem	Verkaufsauftrag Position
BKPF	I_JournalEntry	Buchungsbeleg-Kopf
BSEG	I_OperationalAcctgDocItem	Buchungsbeleg-Position

Beispiel-Beziehung

KNA1
  ↓
I_Customer

Annotiert mit:

@VDM.viewType: #BASIC

Composite Views (Interface Views)

Composite Views basieren auf Basis Views und/oder anderen Composite Views. Sie verbinden Daten aus mehreren Quellen und ergänzen diese um Geschäftslogik und Semantik, ohne direkt auf Datenbanktabellen zuzugreifen.

Beispiele

Composite CDS View	Beschreibung
I_SalesOrderCube	Verkaufsaufträge mit Positionen und Kundendaten
I_BillingDocumentCube	Fakturahaupt- und -positionsdaten
I_InventoryCube	Produkt- und Lagerdaten
I_ProfitCenterPlanActualCube	Finanz Ist- und Plan-Daten

Beispiel-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 (Basis und Composite Views) und sind für spezifische Anwendungsfälle wie Reporting, Analytics, APIs und Applikationen konzipiert. Direkten Zugriff auf Datenbanktabellen haben sie nur über die Reuse-Schicht.

Beispiele:

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

Beispiele

Consumption CDS View	Verwendung
C_SalesOrderQry	Analysen zu Verkaufsaufträgen
C_BillingDocumentQry	Faktura-Analysen
C_ProfitCenterPlanActualQry	Finanz-Reporting
C_GLLineItemsQ0001	Hauptbuch-Reporting
C_ProductSalesPerformanceQry	Verkaufsleistungsanalyse

Beispiel-Beziehung

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

Annotiert mit:

@VDM.viewType: #CONSUMPTION

SAP-Berichte

Nexus kann SAP-Berichtsdaten extrahieren, sofern der Bericht automatisiert ausführbar ist und das Ergebnis aus der SAP GUI exportiert werden kann. In der Praxis bedeutet dies, dass der Bericht:

• Als ABAP-Programm implementiert sein muss.
• Einen Initial-Auswahlbildschirm für die Eingabe von Parametern und Filtern bietet.
• Die Ergebnisse tabellarisch ausliefert.
• Die tabellarische Ausgabe über die SAP GUI in eine Datei exportiert werden kann.

Nexus folgt dabei denselben Schritten wie ein Nutzer der SAP GUI: Der Bericht wird ausgeführt, die Selektionsparameter gesetzt und das tabellarische Ergebnis exportiert. Nexus extrahiert nicht den Bericht selbst, sondern die exportierten Tabellendaten. Als Faustregel gilt: Wenn ein Nutzer den Bericht ausführen, Selektionsparameter setzen, das Ergebnis als Tabelle anzeigen und diese Tabelle exportieren kann, ist eine Extraktion durch Nexus in der Regel möglich.

ECC vs. SAP S/4HANA Datenmodell-Besonderheiten

Überblick

Bei der Extraktion von SAP-Daten sollte bedacht werden, dass SAP S/4HANA wesentliche Änderungen am Datenmodell gegenüber SAP ECC eingeführt hat. Viele klassische Tabellen erscheinen in S/4HANA weiterhin, tatsächlich sind diese aber häufig als Compatibility Views realisiert und nicht mehr als physische Datenbanktabellen vorhanden. SAP hat diese Views als Kompatibilitätsschicht eingeführt, um die Abwärtskompatibilität für bestehende Berichte, kundeneigene Entwicklungen, Extraktoren und Integrationen zu gewährleisten.

Daher können Extraktionswerkzeuge wie Nexus häufig weiterhin bekannte ECC-Objekte adressieren, während Kunden auf S/4HANA migrieren.

Compatibility Views

Compatibility Views sind von SAP bereitgestellte CDS-basierte Views, die die Legacy-ECC-Tabellenstrukturen auf das neue S/4HANA-Datenmodell abbilden. Sie dienen als Abstraktionsschicht zwischen alter Anwendungsmethodik 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	Konsolidiert in ACDOCA
SAP verfolgt das Ziel, dass bestehender Custom Code und Integrationen nach einer Systemkonvertierung mit minimalen Anpassungen weiter funktionieren.

---

Wichtige Anleitungen zur Extraktion

Kompatibilitätsansichten werden unterstützt

Nexus kann sowohl aus Kompatibilitätsansichten als auch aus regulären SAP-Tabellen extrahieren, da SAP diese über Standardinterfaces bereitstellt. Dies ermöglicht es bestehenden Extraktionspaketen, nach zahlreichen ECC-zu-S/4HANA-Migrationen weiterhin zu funktionieren.

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

Kompatibilitätsansichten sind zwar praktisch, SAP empfiehlt jedoch, wo möglich das neue S/4HANA-Datenmodell zu verwenden. Kompatibilitätsansichten dienen in erster Linie der Abwärtskompatibilität und können zusätzliche Joins, Unions oder Schichten von Geschäftslogik enthalten.

Für neue Projekte sollten Sie nach Möglichkeit folgende Objekte bevorzugen:

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

statt sich ausschließlich auf alte ECC-Strukturen zu verlassen.

Hinweise zur Performance

Einige Kompatibilitätsansichten können deutlich komplexer sein als die ursprünglichen ECC-Tabellen, die sie nachbilden. In bestimmten Fällen führen SAP-Kompatibilitätsansichten Joins und Transformationen über mehrere zugrunde liegende Objekte aus. Umfangreiche Extraktionen sollten daher im Rahmen der Implementierung auf Performance geprüft werden.

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

Bereich	SAP ECC	SAP S/4HANA
Finanzbuchhaltung & Controlling	FI- und CO-Daten verteilt auf mehrere Tabellen wie BKPF, BSEG, COEP, COSP und COSS	Finanz- und Controllingdaten in das Universal Journal (ACDOCA) konsolidiert. Alte Tabellen sind häufig als Kompatibilitätsansichten implementiert.
Bestandsführung	Materialbeleg- und Bestandsinformationen in Tabellen wie MKPF und MSEG gespeichert	Bestandsbuchungen werden primär in MATDOC abgelegt. Alte Objekte wie MSEG werden über Kompatibilitätsansichten bereitgestellt.
Kunden- & Lieferantenstammdaten	Separate Stammdatenobjekte für Kunden (KNA1) und Lieferanten (LFA1)	Vereinheitlichtes Business Partner (BP)-Modell ersetzt die getrennten Konzepte für Kunden und Lieferanten.
Datenzugriffsschicht	Direkte Nutzung physischer ECC-Tabellen durch Berichte, Eigenentwicklungen und Integrationen	Viele alte Tabellen sind als Kompatibilitätsansichten realisiert, die alte Strukturen mit dem neuen S/4HANA-Datenmodell abbilden.
Reporting-Model	Daten oftmals verteilt auf mehrere, anwendungsspezifische Tabellen, die abgeglichen werden müssen	Vereinfachtes und harmonisiertes Datenmodell ermöglicht Echtzeit-Analysen und Reporting auf konsolidierten Strukturen

Empfehlung zur Extraktion

Für SAP S/4HANA-Systeme gilt:

• Bestehende ECC-basierte Extraktionsszenarien funktionieren häufig weiterhin über SAP-Kompatibilitätsansichten.
• Bei neuen Implementierungen sollten CDS Views, CDS View Entities, Business Partner Objekte, ACDOCA und MATDOC bevorzugt werden, sofern möglich.
• Prüfen Sie die Performance der Extraktion, wenn Kompatibilitätsansichten zum Einsatz kommen, da einige Ansichten deutlich komplexer sein können als die zugrunde liegenden S/4HANA-Tabellen.

Wie erkennen Sie, ob ein Objekt eine Kompatibilitätsansicht ist?

Im SAP GUI:

1. Öffnen Sie die Transaktion SE16N
2. Geben Sie den Tabellennamen ein
3. Zeigt SAP ein Proxy Object an, wird das Objekt wahrscheinlich von einer Kompatibilitätsansicht unterstützt
4. Navigieren Sie zu SE11, um die zugrunde liegende CDS-Definition und die beteiligten physischen Tabellen zu prüfen

So können Sie feststellen, ob eine Extraktion auf eine physische Tabelle oder eine virtuelle Kompatibilitätsschicht zugreift.

SAP-Referenzen

Für Kunden, die eine SAP ECC-zu-SAP S/4HANA-Migration planen, stellt SAP umfangreiche Dokumentation zu Kompatibilitätsobjekten und Datenmodellenvereinfachungen bereit:

• SAP Note 2595627 – Kompatibilitätsansichten in SAP S/4HANA – Kompatibilitätsansichten in S/4HANA.
• SAP S/4HANA Simplification List (SIMPL_OP2023) – Vollständige Übersicht der Änderungen im S/4HANA-Datenmodell.
• SAP S/4HANA Migration and Conversion Guides – Offizielle Anleitung zu Migration und Konvertierung.

Diese Dokumente enthalten detaillierte Zuordnungen abgekündigter ECC-Tabellen, Ersatzstrukturen und funktionale Änderungen in SAP S/4HANA.