Jakie dane może wyodrębniać Nexus z SAP?

dab Nexus to elastyczna platforma do ekstrakcji danych z SAP, obsługująca różne typy źródeł SAP – od fizycznych tabel bazodanowych, przez semantyczne modele danych, aż po raporty SAP. Zakres możliwej ekstrakcji zależy od architektury SAP System, dostępnych interfejsów, uprawnień oraz wdrożeń specyficznych dla konkretnego klienta.

Tabele baz danych SAP DDIC

Przegląd

SAP przechowuje dane aplikacyjne za pomocą obiektów zdefiniowanych w Słowniku ABAP (DDIC). W zależności od wdania SAP oraz wykorzystywanej bazy danych, informacje mogą być zapisywane w różnych typach tabel. Z punktu widzenia Nexus dane mogą być pobierane z tabel i widoków SAP udostępnionych poprzez Słownik ABAP i dostępnych przez wybrany interfejs SAP wykorzystywany podczas ekstrakcji.

Główne typy obiektów bazodanowych DDIC to:

Typ obiektu DDIC	Opis	Typowe zastosowanie
Transparent Table	Odwzorowanie 1:1 pomiędzy definicją DDIC a fizyczną tabelą w bazie danych	Dane aplikacji biznesowych
Pooled Table	Wiele logicznych tabel przechowywanych wspólnie w jednej fizycznej tabeli pool	SAP System/dane konfiguracyjne (starsze wdania)
Cluster Table	Kilka logicznych tabel przechowywanych razem w klastrze danych	Dane aplikacji SAP (starsze wdania)
View	Wirtualny obiekt oparty na jednej lub wielu tabelach	Raportowanie oraz dostęp do danych

Uwaga Pomimo, że SAP S/4HANA w dużym stopniu zastąpił pooled oraz cluster tables przez transparent tables, Nexus nadal umożliwia ekstrakcję pooled oraz cluster tables tam, gdzie są one dostępne, m.in. w starszych systemach SAP ECC.

---

Transparent Tables

Przegląd

Transparent Table to tabela bazodanowa mająca bezpośrednie odwzorowanie 1:1 z fizyczną tabelą bazy danych. Nazwa tabeli, nazwy jej pól oraz struktura określone w Słowniku ABAP odpowiadają dokładnie tabeli fizycznej zapisanej w bazie.

Transparent tables są najczęściej spotykanym typem tabel SAP i przechowują większość danych aplikacyjnych.

Główne cechy

• Bezpośrednie odwzorowanie: jedna tabela SAP = jedna tabela w bazie danych
• Jednakowa struktura w DDIC oraz bazie
• Obsługa indeksów podstawowych i pomocniczych
• Dostęp przez Open SQL oraz Native SQL
• Służy do przechowywania danych transakcyjnych, referencyjnych oraz organizacyjnych
• Pełne wsparcie w SAP ECC oraz SAP S/4HANA

Typowe przykłady

Kategoria	Tabela	Opis
Finanse	BKPF	Nagłówek dokumentu księgowego
	BSEG	Pozycje dokumentu księgowego
	ACDOCA	Uniwersalny dziennik
Sprzedaż i dystrybucja	VBAK	Nagłówek zamówienia sprzedaży
	VBAP	Pozycje zamówienia sprzedaży
Gospodarka materiałowa	EKKO	Nagłówek zamówienia zakupu
	EKPO	Pozycje zamówienia zakupu
Dane podstawowe	MARA	Dane referencyjne materiału
	KNA1	Dane referencyjne klienta
	LFA1	Dane referencyjne dostawcy

Pooled Tables

Przegląd

Pooled tables to logiczne tabele DDIC przechowywane fizycznie we wspólnej tabeli pool. Wiele pooled tables korzysta z tej samej fizycznej tabeli bazy danych. Tego typu tabele służyły przede wszystkim do oszczędzania zasobów bazodanowych w starszych wersjach SAP.

Główne cechy

• Wiele tabel SAP korzysta z jednej fizycznej tabeli w bazie
• Stosowane głównie do przechowywania konfiguracji systemowej oraz danych sterujących
• Dostęp przez Słownik ABAP
• Rozwiązanie historyczne (legacy)
• Nie stosowane w SAP S/4HANA

Przykładowe tabele

Tabela	Opis
A003	Warunki cenowe (starsze systemy ECC)
Różne tabele SAP System	Dane konfiguracyjne i sterujące

Cluster Tables

Przegląd

Cluster tables to logiczne tabele DDIC, których rekordy zapisywane są wspólnie w skompresowanym klastrze danych (jednej fizycznej tabeli w bazie).

Kilka tabel klastrowanych może dzielić tę samą przestrzeń w bazie.

Główne cechy

• Wiele logicznych tabel przechowywanych w jednym klastrze bazy danych
• Dane zapisywane w formacie skompresowanym
• Historycznie stosowane w celu optymalizacji wydajności
• Dostęp typowo przez ABAP Open SQL
• Rozwiązanie legacy; zastąpione przez transparent tables w SAP S/4HANA

Przykładowe tabele

Tabela	Opis
BSEG	Pozycje dokumentu księgowego (ECC)
KONV	Warunki cenowe (ECC)

Uwaga W SAP ECC niektóre znane tabele, takie jak BSEG, były realizowane jako cluster tables. W SAP S/4HANA konstrukcje te zostały przebudowane i obecnie figurują jako transparent tables.

Widoki

Przegląd

Widok (View) to wirtualny obiekt DDIC, oparty na jednej lub wielu tabelach. Widoki same w sobie nie przechowują danych – zapewniają natomiast logiczną reprezentację zapisów.

Widoki są szeroko wykorzystywane do raportowania, analityki oraz ułatwienia dostępu do informacji.

Główne cechy

• Bazują na jednej lub wielu tabelach
• Brak fizycznego powielania danych
• Możliwość stosowania relacji (joinów) oraz filtrów
• Częste zastosowanie w raportach oraz integracjach
• Popularne w środowiskach ECC oraz S/4HANA

Typowe przykłady

Typ widoku	Opis
Database View	Połączenie kilku tabel bazodanowych
Projection View	Podzbiór pól z jednej tabeli
Maintenance View	Umożliwia utrzymanie (modyfikację) zawartości tabel
CDS View	Nowoczesny, semantyczny model danych w S/4HANA

CDS Views

Przegląd

Core Data Services (CDS) Views to strategiczna technologia SAP do definiowania semantycznych modeli danych na warstwie bazy danych. CDS Views umożliwiają deweloperom oraz użytkownikom odbiór danych biznesowych poprzez wielokrotnie wykorzystywalne, zoptymalizowane wydajnościowo i bogate semantycznie widoki. CDS Views stanowią fundament Virtual Data Model (VDM) w SAP S/4HANA; mogą być wykorzystywane przez aplikacje SAP Fiori, narzędzia analityczne, serwisy OData, integracje zewnętrzne oraz rozwiązania do raportowania. W przypadku Nexus, CDS Views stanowią alternatywę dla bezpośredniej ekstrakcji z tabel, umożliwiając korzystanie z firmowych lub niestandardowych modeli semantycznych.

Główne cechy

• Semantyczne modelowanie danych – biznesowa reprezentacja tabel bazodanowych.
• Database pushdown – przetwarzanie realizowane bezpośrednio na SAP HANA, co poprawia wydajność.
• Wielokrotne wykorzystanie logiki – logika biznesowa, łączenia, obliczenia i filtry definiowane tylko raz i stosowane dalej.
• Adnotacje – adnotacje metadanych wspierają analizę, publikację OData, generowanie UI oraz mechanizmy autoryzacyjne.
• Integracja z bezpieczeństwem – obsługa kontroli dostępu na podstawie ról z użyciem DCL (Data Control Language).
• Virtual Data Models (VDM) – trzon nowoczesnej architektury dostępu do danych SAP.

CDS Views w SAP ECC

Technologia CDS dostępna jest w nowszych wydaniach SAP ECC z SAP HANA. Typowe zastosowania obejmują:

• raportowanie i analitykę,
• generowanie serwisów OData,
• aplikacje SAP Fiori,
• upraszczanie złożonych połączeń SQL (joinów),
• ekstrakcję danych do systemów zewnętrznych. Jednak adaptacja CDS w ECC jest na ogół bardziej ograniczona niż w SAP S/4HANA.

CDS Views w SAP S/4HANA

W SAP S/4HANA, widoki CDS stanowią kluczowy element architektury aplikacyjnej. SAP udostępnia tysiące standardowych CDS Views z zakresu takich obszarów biznesowych jak:

Obszar	CDS View / encja API	Nazwa widoku ABAP CDS
Finanse	I_GLAccountLineItem	I_GLAccountLineItem
	I_JournalEntry	I_JournalEntry
	I_ProfitCenter	I_ProfitCenter
Sprzedaż	I_SalesOrder	I_SalesOrder
	I_SalesOrderItem	I_SalesOrderItem
	I_Customer	I_Customer
Zakupy	I_PurchaseOrderAPI01	I_PurchaseOrderAPI01
	I_Supplier	I_Supplier
Materiały i stany magazynowe	I_Product	I_Product
	I_MaterialStock	I_MaterialStock

Powyższe widoki zapewniają ustandaryzowany dostęp do danych biznesowych, jednocześnie ukrywając złożone struktury tabel źródłowych.

CDS DDIC-Based Views vs. CDS View Entities

SAP oferuje dwie implementacje widoków CDS: CDS DDIC-based Views oraz CDS View Entities. Choć oba typy udostępniają dane przez Core Data Services (CDS), zaleca się wykorzystanie CDS View Entities w nowych wdrożeniach ze względu na uproszczoną architekturę i usprawnienia techniczne.

Jak znaleźć nazwę widoku ABAP CDS

Opcja 1: Sprawdzenie CDS View w SE11

1. Otworzyć transakcję SE11.
2. Wpisać nazwę CDS View (na przykład I_GLAccountLineItem).
3. Wyświetlić definicję.
4. Poszukać adnotacji:

@AbapCatalog.sqlViewName: '...'

Przykład:

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

Wartość @AbapCatalog.sqlViewName to techniczna nazwa SQL View ABAP skojarzona z CDS View.

Uwaga: Nowe CDS View Entities mogą nie mieć wygenerowanej nazwy SQL View. W takim przypadku należy skorzystać z opcji 2, aby ustalić techniczną nazwę udostępnianą przez Operational Data Provisioning (ODP).

Opcja 2: Sprawdzenie tabeli RSODPABAPCDSVIEW w SE16

SAP utrzymuje mapowanie między CDS Views a ich nazwami technicznymi udostępnionymi przez ODP w tabeli RSODPABAPCDSVIEW.

1. Otworzyć transakcję SE16 albo SE16N.
2. Wprowadzić nazwę tabeli RSODPABAPCDSVIEW.
3. Przefiltrować po nazwie CDS View (np. I_GLAccountLineItem).
4. Wykonać zapytanie.

Wyniki pokażą odpowiadające im metadane CDS View oraz nazwy techniczne wykorzystywane przez framework ODP do ekstrakcji danych.

Przykład

CDS View	Lokalizacja nazwy ABAP
I_GLAccountLineItem	@AbapCatalog.sqlViewName w SE11 lub odczyt w RSODPABAPCDSVIEW
I_JournalEntry	@AbapCatalog.sqlViewName w SE11 lub odczyt w RSODPABAPCDSVIEW
I_SalesOrder	@AbapCatalog.sqlViewName w SE11 lub odczyt w RSODPABAPCDSVIEW
I_PurchaseOrderAPI01	@AbapCatalog.sqlViewName w SE11 lub odczyt w RSODPABAPCDSVIEW

Rekomendacja: W przypadku systemów SAP S/4HANA, zwłaszcza nowszych wersji, sprawdzanie RSODPABAPCDSVIEW jest najpewniejszą metodą identyfikacji technicznej nazwy CDS udostępnianej do ekstrakcji.

Podsumowanie

Funkcja	CDS DDIC-Based View	CDS View Entity
Definiowany przez	DEFINE VIEW	DEFINE VIEW ENTITY
Obiekt słownika ABAP	Tworzony dodatkowy DDIC View zarządzany przez CDS	Brak dodatkowego DDIC View
Architektura	Jednostka CDS + DDIC View	Tylko jednostka CDS
Wydajność aktywacji	Wolniejsza z powodu dodatkowego generowanego obiektu DDIC	Szybsza aktywacja
Rekomendacja SAP	Przestarzały dla nowych wdrożeń	Zalecany do nowych wdrożeń
Dostępność	Obsługiwany dla zgodności i istniejących systemów	Preferowany w nowoczesnym rozwoju ABAP

CDS DDIC-Based Views

CDS DDIC-based view to rozwiązanie technicznie bazujące na CDS-managed DDIC view w Słowniku ABAP, definiowane przez instrukcję DEFINE VIEW. Podczas aktywacji SAP generuje:

• jednostkę CDS,
• powiązany CDS-managed DDIC view.

Dodatkowy obiekt w słowniku zwiększa złożoność oraz wydłuża proces aktywacji.

Przykład:

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

CDS View Entities

CDS View Entities to nowoczesna wersja CDS DDIC-based views. Definiowane są przy użyciu DEFINE VIEW ENTITY i nie generują dodatkowego DDIC view, dzięki czemu architektura jest uproszczona, a aktywacja szybsza. Do nowych wdrożeń SAP zaleca wykorzystywanie CDS View Entities.

Przykład:

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

Dla istniejących systemów SAP CDS DDIC-based views są nadal szeroko stosowane i mogą być wyodrębniane przy użyciu Nexus.

Virtual Data Model (VDM)

Virtual Data Model (VDM) to uporządkowany zbiór widoków SAP CDS (Core Data Services), zapewniający semantyczną, wielokrotnie wykorzystywalną warstwę danych nad tabelami bazy. Model VDM organizuje CDS Views w różne warstwy, oddzielając mechanizmy dostępu do danych, logikę biznesową oraz scenariusze konsumpcji.

VDM składa się z:

• Basic Views – zapewniają bezpośredni dostęp do tabel bazy danych i udostępniają przyjazne biznesowo modele danych.
• Composite Views – łączą wiele Basic Views i wzbogacają je o logikę biznesową.
• Consumption Views – tworzą modele dla określonych zastosowań: analityki, raportowania, API i aplikacji SAP Fiori.

Stability Contracts

SAP klasyfikuje wiele widoków CDS przez tzw. Stability Contracts, które wskazują zakres gwarancji zgodności oferowanej na przyszłe wersje. Umowy stabilności pomagają klientom oraz partnerom SAP ocenić, czy wybrany widok CDS można bezpiecznie wykorzystać w niestandardowych rozwiązaniach czy integracjach. Najistotniejszą umową dla użytku zewnętrznego jest:

Umowa	Opis
C1	Widok udostępniony do wykorzystania przez klientów i partnerów. SAP gwarantuje stabilny interfejs oraz zgodność wsteczną zmian objętych kontraktem.

SAP oficjalnie zaleca do ponownego wykorzystania wyłącznie określone CDS Views zgodne z kontraktem stabilności C1. Widoki te są przeznaczone do trwałych rozwiązań integracyjnych, raportowych i aplikacyjnych. Nexus pozwala wyodrębniać dane z widoków SAP CDS niezależnie od warstwy VDM ani przypisania kontraktu stabilności.

Oficjalne źródła SAP

Więcej informacji na temat architektury Virtual Data Model (VDM) oraz CDS Views w oficjalnych materiałach SAP:

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

• VDM Layers and View Types (SAP Help Portal)

Basic Views (Interface Views)

Basic views bazują bezpośrednio na tabelach bazy danych i są jedynymi widokami CDS zapewniającymi bezpośredni dostęp do tabel. Dostarczają przyjaznych biznesowo nazw pól i rozszerzają model danych o metadane i powiązania.

Przykłady

Tabela bazy danych	Basic CDS View	Obiekt biznesowy
KNA1	I_Customer	Customer Master
MARA	I_Product	Material/Product Master
VBAK	I_SalesOrder	Sales Order Header
VBAP	I_SalesOrderItem	Sales Order Item
BKPF	I_JournalEntry	Accounting Document Header
BSEG	I_OperationalAcctgDocItem	Accounting Document Item

Przykładowe powiązanie

KNA1
  ↓
I_Customer

Adnotacje:

@VDM.viewType: #BASIC

Composite Views (Interface Views)

Composite Views bazują na basic views i/lub innych composite views. Łączą dane z wielu źródeł, dodając logikę biznesową bez bezpośredniego dostępu do tabel bazy.

Przykłady

Composite CDS View	Opis
I_SalesOrderCube	Zamówienia sprzedaży wraz z pozycjami oraz informacją o kliencie
I_BillingDocumentCube	Nagłówki i pozycje dokumentów sprzedaży
I_InventoryCube	Dane produktów i stanów magazynowych
I_ProfitCenterPlanActualCube	Rzeczywiste i planowane dane finansowe

Przykładowe powiązanie

I_SalesOrder
       +
I_SalesOrderItem
       +
I_Customer
       ↓
I_SalesOrderCube

Adnotacje:

@VDM.viewType: #COMPOSITE

Consumption Views

Consumption views stanowią najwyższą warstwę VDM. Budowane są na widokach Basic oraz Composite i przeznaczone do konkretnych zastosowań biznesowych: raportów, analityki, API i aplikacji. Do tabel baz danych mają dostęp wyłącznie pośredni – przez warstwę Basic/Composite.

Przykłady wykorzystania:

• aplikacje SAP Fiori,
• serwisy OData,
• pulpity KPI,
• zapytania analityczne.

Przykłady

Consumption CDS View	Przeznaczenie
C_SalesOrderQry	Analiza zamówień sprzedaży
C_BillingDocumentQry	Analiza fakturowania
C_ProfitCenterPlanActualQry	Raportowanie finansowe
C_GLLineItemsQ0001	Raportowanie księgi głównej
C_ProductSalesPerformanceQry	Analiza wyników sprzedaży

Przykładowe powiązanie

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

Adnotacje:

@VDM.viewType: #CONSUMPTION

Raporty SAP

Nexus umożliwia ekstrakcję danych z raportu SAP pod warunkiem, że raport może być uruchamiany automatycznie, a jego wyniki da się wyeksportować z SAP GUI. W praktyce oznacza to, że raport powinien:

• Być zaimplementowany jako program ABAP,
• Udostępniać ekran selekcji parametrów,
• Generować wynik w formie tabelarycznej,
• Pozwalać na eksport tabeli z wynikami do pliku poprzez standardowe funkcje SAP GUI.

Nexus korzysta z analogicznego procesu, jaki wykonałby użytkownik SAP GUI: uruchamia raport, uzupełnia parametry selekcji i eksportuje wynikową tabelę. Nexus nie pobiera samego raportu – wyodrębnia jedynie dane z wyeksportowanej tabeli. W efekcie, jeśli użytkownik ma możliwość uruchomienia raportu, wprowadzenia parametrów, przejrzenia wyników w tabeli i eksportu tej tabeli do pliku, raport z dużym prawdopodobieństwem można wyekstrahować przez Nexus.

ECC vs. SAP S/4HANA – Rozważania dotyczące modelu danych

Przegląd

Podczas ekstrakcji danych z systemów SAP warto mieć świadomość, że SAP S/4HANA wprowadził istotne zmiany w modelu danych względem SAP ECC. Wiele tradycyjnych tabel wydaje się nadal występować w S/4HANA, jednak w rzeczywistości często są realizowane jako Compatibility Views, a nie fizyczne tabele bazodanowe. SAP wprowadził tego typu widoki, aby zapewnić zgodność wsteczną dla istniejących raportów, rozwiązań niestandardowych, ekstraktorów i integracji.

W rezultacie, narzędzia ekstrakcyjne takie jak Nexus często umożliwiają ciągły dostęp do znanych obiektów ECC nawet podczas migracji klientów na S/4HANA.

Compatibility Views

Compatibility Views to widoki CDS udostępniane przez SAP, które mapują stare struktury tabel ECC na nowy model danych S/4HANA. Pełnią one rolę warstwy abstrakcji między dawnymi mechanizmami aplikacyjnymi a nową fizyczną strukturą baz danych.

Na przykład:

ECC Obiekt	S/4HANA Zamiennik
MSEG	MATDOC (poprzez widok kompatybilnosci)
COEP	Universal Journal (ACDOCA) poprzez widok kompatybilnosci
COSP / COSS	Struktury Universal Journal poprzez widoki kompatybilnosci
Rozne tabele FI/CO	Scentralizowane w ACDOCA
Celem SAP jest zapewnienie, by istniejące niestandardowe rozwiązania oraz integracje mogły działać po konwersji systemu przy minimalnych zmianach.

---

Ważne wskazówki dotyczące ekstrakcji

Obsługa widoków kompatybilności

Nexus umożliwia ekstrakcję zarówno z widoków kompatybilności, jak i ze standardowych tabel SAP, ponieważ SAP udostępnia je przez standardowe interfejsy. Pozwala to na dalsze korzystanie z istniejących pakietów ekstrakcyjnych także po wielu migracjach ECC-do-S/4HANA.

Preferowanie natywnych obiektów S/4HANA, gdy to możliwe

Choć widoki kompatybilności są wygodne, SAP zaleca w miarę możliwości stosowanie nowego modelu danych S/4HANA. Widoki te występują głównie w celu zapewnienia zgodności wstecznej i mogą wprowadzać dodatkowe połączenia, unie lub warstwy logiki biznesowej.

W ramach nowych projektów warto rozważyć użycie:

• Widoków CDS
• Encji widoków CDS
• Obiektów Business Partner
• Universal Journal (ACDOCA)
• Tabeli dokumentów materiałowych (MATDOC)
• Opublikowanych interfejsów API SAP oraz serwisów OData

zamiast opierania się wyłącznie na starszych strukturach ECC.

Kwestie wydajnościowe

Wybrane widoki kompatybilności mogą być znacznie bardziej złożone od oryginalnych tabel ECC, które emulują. Zdarza się, że SAP realizuje w ramach takich widoków złączenia i transformacje na wielu obiektach źródłowych. Przy dużych ekstrakcjach zaleca się zatem weryfikację wydajnościową już podczas wdrożenia.

Kluczowe zmiany w modelu danych SAP ECC vs. SAP S/4HANA

Obszar	SAP ECC	SAP S/4HANA
Księgowość finansowa i kontroling	Dane FI oraz CO są przechowywane w wielu tabelach, takich jak BKPF, BSEG, COEP, COSP i COSS	Dane finansowe oraz kontrolingowe zostały skonsolidowane w Universal Journal (ACDOCA). Dziedziczone tabele to często widoki kompatybilności.
Gospodarka magazynowa	Informacje o ruchach materiałowych i stanie zapasów zapisane są w tabelach MKPF i MSEG	Transakcje magazynowe zapisywane są głównie w MATDOC. Starsze obiekty, takie jak MSEG, są udostępniane przez widoki kompatybilności.
Dane podstawowe klientów i dostawców	Oddzielne obiekty danych podstawowych dla klientów (KNA1) i dostawców (LFA1)	Scentralizowany model Business Partner (BP) zastępuje rozdzielone dotychczas koncepcje danych klienta i dostawcy.
Warstwa dostępu do danych	Fizyczne tabele ECC używane były bezpośrednio w raportach, rozwiązaniach autorskich i integracjach	Wiele dziedziczonych tabel występuje jako widoki kompatybilności, mapujące starsze struktury na nowy model danych S/4HANA.
Model raportowy	Dane często rozproszone były po wielu tabelach aplikacyjnych, wymagając konsolidacji	Uproszczony i ujednolicony model danych umożliwiający analizy i raportowanie w czasie rzeczywistym bezpośrednio na scentralizowanych strukturach

Rekomendacje dotyczące ekstrakcji

Dla systemów SAP S/4HANA:

• Istniejące scenariusze ekstrakcji oparte o ECC często działają nadal poprzez widoki kompatybilności SAP.
• W nowych wdrożeniach zaleca się preferowanie rozwiązań takich, jak CDS Views, CDS View Entities, Business Partner objects, ACDOCA oraz MATDOC, gdy jest to możliwe.
• Przed wdrożeniem warto zweryfikować wydajność ekstrakcji, ponieważ niektóre widoki są znacznie bardziej złożone niż bazowe tabele S/4HANA.

Jak sprawdzić, czy obiekt stanowi widok kompatybilności

W SAP GUI:

1. Proszę otworzyć transakcję SE16N
2. Proszę wpisać nazwę tabeli
3. Jeśli SAP wyświetli Proxy Object, dany obiekt prawdopodobnie bazuje na widoku kompatybilności
4. Proszę przejść do SE11 i sprawdzić definicję CDS oraz powiązane tabele fizyczne

Pozwala to ustalić, czy ekstrakcja odbywa się z fizycznej tabeli, czy przez warstwę wirtualną – widok kompatybilności.

Materiały SAP

Klienci planujący migracje SAP ECC do SAP S/4HANA mają do dyspozycji szczegółową dokumentację omawiającą obiekty kompatybilności i uproszczenia modeli danych:

• SAP Note 2595627 – Compatibility Views in SAP S/4HANA – Widoki kompatybilności w S/4HANA.
• SAP S/4HANA Simplification List (SIMPL_OP2023) – Kompleksowe omówienie zmian w modelu danych S/4HANA.
• SAP S/4HANA Migration and Conversion Guides – Oficjalne wytyczne dotyczące migracji oraz konwersji.

Wskazana dokumentacja zawiera szczegółowe mapowania wycofanych tabel ECC, nowe struktury oraz opis zmian funkcjonalnych wprowadzonych w SAP S/4HANA.