Dla architektów SAP
Wzmacniamy model integralności SAP. Nigdy go nie omijamy.
Pytania, które padną w pierwszej rozmowie, za każdym razem z tą samą odpowiedzią. Jeśli coś nie jest wystarczająco precyzyjne dla Państwa krajobrazu, warto zapytać — wolimy wrócić z odpowiedzią niż improwizować.
Jak rekord trafia do SAP Zapisu dokonuje SAP
Państwa źródła
SAP ECCJD EdwardsDynamics / NAVLegacy i pliki
vise DMW
ValidateProfileMapLoad SimApprove
Reguły biznesowe ponad kontrolami SAP; przebieg próbny względem Państwa customizingu; imiennie wskazana osoba zatwierdzająca. Państwa SAP
BAPIIDocOData / RAPMigration Cockpit
CVI, customizing, BAdI, zakresy numerów, dokumenty zmian — wszystko włączone. Bezpośrednie zapisy do KNA1, LFA1, BUT000 ani żadnej tabeli SAP — nigdy.
01
Sześć rzeczy, które są zawsze prawdziwe.
01 Wyłącznie przez własne API SAP Każde ładowanie idzie przez API SAP: BAPI, IDoc, OData/RAP, moduł funkcyjny RFC wywołujący własne API SAP do obsługi danych — albo przez SAP Migration Cockpit, jeśli chcą Państwo go zachować. Narzędzie vise DMW nigdy nie zapisuje bezpośrednio do KNA1, LFA1, BUT000 ani do żadnej innej tabeli.
02 Integralność SAP pozostaje włączona Synchronizacja CVI, kontrole customizingu, walidacja BAdI/exitów, zakresy numerów, uprawnienia, dokumenty zmian (CDHDR/CDPOS) — wszystko działa dokładnie tak jak w każdym narzędziu zatwierdzonym przez SAP, bo zapisu dokonuje SAP.
03 Druga warstwa walidacji, a nie zastępstwo SAP sprawdza, czy przyjmie rekord. vise DMW sprawdza, czy Państwa biznes może z nim pracować: spójność między obiektami, formaty regulacyjne, nadzór finansowy, polityki biznesowe, warunki wstępne workflow, spójność danych podstawowych.
04 Symulacja przed każdym ładowaniem Ładowanie przechodzi próbnie względem Państwa systemu docelowego z Państwa customizingiem. System docelowy waliduje każdy rekord tak jak przy prawdziwym ładowaniu, więc widzą Państwo te same błędy — dla każdego rekordu, zanim cokolwiek zostanie zapisane.
05 AI przygotowuje, ludzie zatwierdzają Mapowania pól, reguły transformacji i reguły walidacji mogą być przygotowane przez AI. Każda propozycja jest wersjonowana, testowana w sandboksie i włączana przez imiennie wskazaną osobę. Nic, co napisze AI, nie dotyka systemu docelowego bez zatwierdzenia.
06 Gotowe do audytu od pierwszego dnia Każda transformacja, zmiana wartości i decyzja o scaleniu jest zapisywana z użytkownikiem, czasem i zastosowaną regułą. Tabele powiązań (stary KUNNR / LIFNR → docelowy PARTNER) powstają natywnie.
02
Silnik ładowania to Państwa decyzja.
DMW nie narzuca mechanizmu ładowania. Wbudowany loader jest domyślny; każda inna ścieżka dostaje te same wstępnie zwalidowane dane.
| Ścieżka | Kiedy | Co dostarcza DMW |
|---|---|---|
| Wbudowany loader DMWDomyślnie | Domyślnie. Jedno kliknięcie w DMW; BAPI, IDoc lub OData wybierane dla obiektu i konfiguracji. | Od początku do końca w jednym narzędziu, audyt ładowania połączony z audytem walidacji i transformacji, monitoring w czasie rzeczywistym i obsługa błędów w interfejsie DMW. |
| SAP Migration Cockpit (LTMC / LTMOM) | Już go Państwo używają, integrator na nim standaryzuje albo predefiniowany obiekt migracyjny dokładnie pasuje do zakresu. | Pliki w formacie szablonu Cockpit, wstępnie zwalidowane, żeby upload nie przyniósł niespodzianek, zmapowane na strukturę obiektu migracyjnego. |
| BAPI | Domyślnie dla wielu obiektów; obiekty własne bez szablonu Cockpit. | Payloady według struktury BAPI, pola obowiązkowe dla obiektu, przebieg testowy przed commitem, commity w partiach, logika ponowień. |
| IDoc | Dystrybucja danych podstawowych w całym krajobrazie; działająca infrastruktura ALE; DEBMAS / CREMAS z CVI generującym BP. | Payloady IDoc poprawne na poziomie segmentów, wstępnie zwalidowane, żeby WE02 / SM58 pozostały czyste, monitoring statusów i odtwarzanie. |
| OData / RAP | S/4HANA Cloud i Public Cloud, ciągłe przepływy danych po go-live, integracje przez API Business Hub. | API_BUSINESS_PARTNER i serwisy RAP, obsługa tokenów, partie i obsługa błędów. |
| Moduł funkcyjny RFC | Business Partner z rolami klienta i dostawcy; Państwa własne moduły funkcyjne lub programy Z jako cel ładowania. | Jedno wywołanie małego modułu funkcyjnego z obsługą RFC, zainstalowanego w Państwa systemie, na każdy rekord Business Partner. Moduł wywołuje API SAP do obsługi obiektu Business Partner (CL_MD_BP_MAINTAIN), najpierw działa w trybie testowym i wykonuje commit tylko przy czystym wyniku. |
| Własny loader albo BODS | Mają Państwo własny loader, pipeline ETL albo BODS i chcą go zachować. | Czyste, wstępnie zwalidowane zbiory danych w Państwa formacie (CSV, XML, JSON, tabele stagingowe), historia transformacji i udokumentowane reguły mapowania. |
Czego DMW nigdy nie robi: bezpośrednich zapisów do tabel SAP, omijania walidacji na poziomie modułów ani sztuczek z pseudo-RFC do tabel wewnętrznych.
03
SAP pyta, czy przyjmie rekord. My pytamy, czy Państwa biznes będzie mógł z nim pracować.
Formaty pól, pola obowiązkowe, kontrole customizingu i BAdI to warstwa SAP — Migration Cockpit, LSMW i BODS walidują względem niej. Rekord może przejść to wszystko i nadal być bezużyteczny: dostawca przypisany do organizacji zakupowej spoza hierarchii zakładu, numer VAT o właściwej długości i złej sumie kontrolnej, warunki płatności poza polityką zakupową, kluczowy klient bez key account managera. To ciche błędy; wychodzą miesiące po go-live, w księgowości albo w zablokowanym zatwierdzeniu. Biblioteka reguł DMW to miejsce, w którym Państwa biznes definiuje je raz, a każdy rekord jest sprawdzany przed ładowaniem.
Spójność między obiektamiDostawca ↔ organizacja zakupowa ↔ zakład; centrum kosztów ↔ centrum zysku ↔ jednostka gospodarcza; obszar sprzedaży ↔ zakład.
Formaty regulacyjneNIP, USt-IdNr, GB VAT, EIN — z sumami kontrolnymi; identyfikatory branżowe; znaczniki retencji RODO.
Nadzór finansowyKraj banku a siedziba, dane beneficjenta rzeczywistego, limity kredytowe a zatwierdzenia, ekspozycja na sankcje.
Polityki biznesoweWarunki płatności dla kategorii dostawców, limity rabatów dla segmentów, ceny a reguły marki.
Warunki wstępne workflowKey account manager dla każdego kluczowego klienta, właściciel centrum kosztów, planista dla każdego materiału.
Spójność danych podstawowychWarunki cenowe dla obszaru sprzedaży, rekordy info dla organizacji zakupowej, urządzenie ↔ miejsce funkcjonowania.
04 · Customer Vendor Integration
CVI to tu rutyna, a nie pozycja ryzyka.
DMW przygotowuje; SAP wykonuje. Rekord, który trafia do CVI, jest już spójny.
- 01Scalenie klienta i dostawcy
- Dopasowanie deterministyczne i rozmyte po nazwie, numerze VAT, adresie i rachunku bankowym; jeden kandydat na BP z FLCU01 + FLVN01; rozbieżności oznaczone do decyzji biznesowej; tabela powiązań do audytu i uzgodnień.
- 02Grupowanie BP i zakresy numerów
- Stare grupy kont zmapowane na Państwa grupowania BP z customizingu; pola obowiązkowe walidowane dla każdego grupowania przed ładowaniem.
- 03Kategoria BP
- Osoba / organizacja / grupa wyprowadzone z danych legacy i sprawdzone względem ról, które ma każdy rekord.
- 04Adresy, numery podatkowe, dane bankowe
- Adresy główne i dodatkowe do BUT020/BUT021; STCD1–3 / STCEG zmapowane na typy numerów podatkowych S/4 i walidowane dla każdego kraju; IBAN i klucz banku sprawdzane względem BNKA.
05
Gdzie to działa.
- Hosting
- UE · AWS albo OVHcloud (Niemcy), do wyboru — albo Państwa własna infrastruktura, wycena na życzenie
- Łączność
- Tunel IPsec site-to-site ograniczony do uzgodnionej podsieci — albo przekazanie ekstraktu
- Dostęp
- Oparty na rolach (CAS), dla programu / projektu / lokalizacji
- Szyfrowanie
- TLS w transmisji; kopie zapasowe i przechowywane dane uwierzytelniające szyfrowane
- Certyfikaty
- ISO/IEC 27001, ISO 9001
- AI
- Żadnych danych osobowych w promptach AI; tylko propozycje, zatwierdzane przez ludzi
Pytania techniczne.
- 01Czy DMW do działania potrzebuje Migration Cockpit?
- Nie. vise DMW ma własny silnik ładowania korzystający ze standardowych interfejsów SAP. Cockpit to opcja, a nie wymóg: jeśli go Państwo zachowają, DMW dostarcza wstępnie zwalidowany zbiór danych do uploadu.
- 02Czy celem ładowania może być własny moduł funkcyjny albo program Z?
- Tak, przez RFC. W ten sposób działają już ładowania obiektu Business Partner: na każdego partnera przypada jedno wywołanie małego modułu funkcyjnego z obsługą RFC, zainstalowanego w Państwa systemie; moduł ten wywołuje własne API SAP do obsługi tego obiektu. Zapisu nadal dokonuje SAP — customizing, CVI, zakresy numerów i dokumenty zmian pozostają aktywne, a do żadnej tabeli nic nie jest zapisywane bezpośrednio.
- 03S/4HANA Public Cloud, gdzie nie ma bezpośredniego dostępu do bazy ani klasycznych BAPI?
- API OData / RAP (API_BUSINESS_PARTNER i pokrewne) — natywna ścieżka SAP dla Public Cloud. Bezpośredni dostęp do bazy danych nie jest ani możliwy, ani potrzebny.
- 04A wydajność przy 5 mln+ rekordów?
- Przepustowość ładowania zależy od systemu docelowego, interfejsu i Państwa BAdI. DMW dzieli ładowanie na partie dla każdego interfejsu (równoległe przetwarzanie BAPI, pakietowanie IDoc). Nie podajemy liczb bez benchmarku na Państwa danych — do tego służy PoC.
- 05Własne role lub grupowania BP?
- Reguły walidacji to konfiguracja, a nie kod, który musimy wydać. Własne role z ich polami obowiązkowymi i własne grupowania dodajemy dla każdego klienta.
- 06Co się dzieje, gdy jeden rekord nie przejdzie synchronizacji CVI w trakcie ładowania?
- Ponowienie na poziomie rekordu, izolacja partii i kolejka błędów. Błędny rekord trafia do korekty, reszta ładowania idzie dalej, a rekord jest przetwarzany ponownie po poprawce.
- 07Relacje BP (BUT050)?
- Osobna klasa obiektów w mapowaniu. Najpierw główne BP, potem relacje (osoba kontaktowa → organizacja), w kolejności, której oczekuje CVI.
- 08Jak ustalana jest kolejność zależnych ładowań i czy ładowania mogą przebiegać równolegle?
- Zależności wyznaczają kolejność ładowania: partnerzy przed relacjami lub umowami, nagłówki przed pozycjami. Każdy rekord jest najpierw symulowany, a commit następuje dopiero po czystej symulacji, nigdy po blokującym komunikacie SAP. Sesje równoległe działają osobno dla każdego systemu docelowego, z izolacją na poziomie rekordu; stopień równoległości ustawia się osobno dla każdej instalacji.
- 09Greenfield S/4 ze źródłem spoza SAP?
- Tak. Dowolne źródło: ERP legacy, Excel, tabele stagingowe, pliki. Typowe są carve-outy i integracje po fuzjach i przejęciach.
- 10Z jakich źródeł może czytać narzędzie vise DMW?
- SAP ECC i S/4HANA bezpośrednio lub z ekstraktu, inne bazy danych, takie jak Microsoft SQL Server i PostgreSQL, pliki, Azure Blob Storage, w tym pliki parquet, baza stagingowa oraz API, na przykład systemu Microsoft Dynamics 365 Business Central. Dostęp do systemu produkcyjnego nie jest wymagany: wystarczy ekstrakt albo replika.
- 11IS-U i Migration Workbench (EMIGALL)?
- Nie mamy jeszcze produkcyjnej referencji IS-U i wolimy powiedzieć to wprost. Konta umów, instalacje i urządzenia wdraża się tak jak każdy inny obiekt: szablony, mapowania i reguły walidacji, sprawdzone w PoC na Państwa obiektach. EMIGALL nie jest dziś zintegrowany; możliwe są dwie drogi: plik importu w strukturze, której oczekują Państwa obiekty migracyjne, albo wywołania RFC narzędzia Migration Workbench — zakres ustalamy z Państwem w PoC.
- 12Korekty po go-live?
- To vise Data Run: ta sama biblioteka walidacji, zoptymalizowana pod cykliczne zmiany masowe zamiast jednorazowej migracji.
- 13Partnerstwo lub certyfikacja SAP?
- Visehub świadomie nie jest partnerem SAP. vise DMW działa przez udostępnione interfejsy SAP (BAPI, IDoc, OData/RAP, Migration Cockpit) w ramach Państwa własnej licencji SAP, więc nic w nim nie zależy od programu partnerskiego — a w naszej cenie nie ma marży partnerskiej.
Wystarczy przynieść diagram krajobrazu. My przyniesiemy odpowiedzi.
60-minutowa sesja techniczna z ludźmi, którzy zbudowali silnik ładowania — a nie rozmowa sprzedażowa.