Für SAP-Architekten
Wir stärken das Integritätsmodell von SAP. Wir umgehen es nie.
Die Fragen, die Sie im ersten Gespräch stellen werden, jedes Mal gleich beantwortet. Wenn etwas für Ihre Landschaft nicht präzise genug ist, fragen Sie – wir melden uns lieber zurück, als zu improvisieren.
Wie ein Datensatz in SAP ankommt Geschrieben wird von SAP
Ihre Quellen
SAP ECCJD EdwardsDynamics / NAVAltsysteme & Dateien
vise DMW
ValidateProfileMapLoad SimApprove
Geschäftsregeln zusätzlich zu den SAP-Prüfungen; Probelauf gegen Ihr Customizing; namentlich benannter Freigeber. Ihr SAP
BAPIIDocOData / RAPMigration Cockpit
CVI, Customizing, BAdIs, Nummernkreise, Änderungsbelege – alles aktiv. Direkte Schreibzugriffe auf KNA1, LFA1, BUT000 oder eine andere SAP-Tabelle – nie.
01
Sechs Dinge, die immer gelten.
01 Nur über SAP-eigene APIs Jeder Ladevorgang läuft über eine SAP-API: BAPI, IDoc, OData/RAP, einen RFC-Funktionsbaustein, der die SAP-eigene Pflege-API aufruft – oder über das SAP Migration Cockpit, wenn Sie es behalten möchten. vise DMW schreibt nie direkt in KNA1, LFA1, BUT000 oder eine andere Tabelle.
02 Die SAP-Integrität bleibt aktiv CVI-Synchronisation, Customizing-Prüfungen, BAdI-/Exit-Validierung, Nummernkreise, Berechtigungen, Änderungsbelege (CDHDR/CDPOS) – all das läuft genau so wie bei jedem von SAP freigegebenen Werkzeug, weil SAP selbst schreibt.
03 Eine zweite Validierungsebene, kein Ersatz SAP prüft, ob es den Datensatz akzeptiert. vise DMW prüft, ob Ihr Geschäft damit arbeiten kann: objektübergreifende Konsistenz, regulatorische Formate, Financial Governance, Geschäftsrichtlinien, Workflow-Voraussetzungen, Kohärenz der Stammdaten.
04 Simulation vor jedem Ladevorgang Der Ladevorgang läuft probeweise gegen Ihr Zielsystem mit Ihrem Customizing. Das Ziel validiert jeden Datensatz wie beim echten Laden, sodass Sie dieselben Fehler sehen – je Datensatz, bevor irgendetwas festgeschrieben wird.
05 Die KI entwirft, Menschen geben frei Feld-Mappings, Transformationsregeln und Validierungsregeln können von der KI entworfen werden. Jeder Vorschlag wird versioniert, in einer Sandbox getestet und von einer namentlich benannten Person eingeschaltet. Nichts, was die KI schreibt, berührt Ihr Ziel ohne Freigabe.
06 Prüfbereit ab dem ersten Tag Jede Transformation, Werteänderung und Zusammenführungsentscheidung wird mit Benutzer, Zeitpunkt und angewendeter Regel festgehalten. Querverweistabellen (Alt-KUNNR / -LIFNR → Ziel-PARTNER) entstehen nativ.
02
Die Lade-Engine ist Ihre Entscheidung.
DMW ist beim Lademechanismus neutral. Der integrierte Loader ist der Standard; jeder andere Weg bekommt dieselben vorvalidierten Daten.
| Weg | Wann | Was DMW liefert |
|---|---|---|
| Integrierter DMW-LoaderStandard | Standard. Ein Klick aus DMW; BAPI, IDoc oder OData je Objekt und Konfiguration gewählt. | Durchgängig in einem Werkzeug, Lade-Audit verknüpft mit Validierungs- und Transformations-Audit, Echtzeit-Monitoring und Fehlerbehandlung in der DMW-Oberfläche. |
| SAP Migration Cockpit (LTMC / LTMOM) | Sie betreiben es bereits, Ihr Integrator standardisiert darauf, oder ein vordefiniertes Migrationsobjekt passt genau zum Umfang. | Dateien im Vorlagenformat des Cockpits, vorvalidiert, damit der Upload keine Überraschungen bringt, gemappt auf die Struktur des Migrationsobjekts. |
| BAPI | Standard für viele Objekte; kundeneigene Objekte ohne Cockpit-Vorlage. | Payloads je BAPI-Struktur, Pflichtfelder je Objekt, ein Testlauf vor dem Commit, Commits in Paketen, Wiederholungslogik. |
| IDoc | Stammdatenverteilung über eine Landschaft; ALE-Infrastruktur vorhanden; DEBMAS / CREMAS, wobei CVI den BP erzeugt. | Segmentgenaue IDoc-Payloads, vorvalidiert, damit WE02 / SM58 sauber bleiben, Statusüberwachung und Wiederherstellung. |
| OData / RAP | S/4HANA Cloud und Public Cloud, kontinuierliche Datenflüsse nach dem Go-live, Integrationen über den API Business Hub. | API_BUSINESS_PARTNER und RAP-Services, Token-Handling, Batching und Fehlerbehandlung. |
| RFC-Funktionsbaustein | Geschäftspartner mit Kunden- und Lieferantenrolle; Ihre eigenen Z-Funktionsbausteine oder Z-Programme als Ladeziel. | Ein Aufruf je Geschäftspartner an einen kleinen RFC-fähigen Funktionsbaustein, der in Ihrem System installiert ist. Er ruft die Geschäftspartner-Pflege-API von SAP auf (CL_MD_BP_MAINTAIN), läuft zuerst als Test und schreibt nur ein fehlerfreies Ergebnis fest. |
| Ihr eigener Loader oder BODS | Sie haben einen eigenen Loader, eine ETL-Pipeline oder BODS und möchten dabei bleiben. | Bereinigte, vorvalidierte Datensätze in Ihrem Format (CSV, XML, JSON, Staging-Tabellen), Transformationshistorie und die dokumentierten Mapping-Regeln. |
Was DMW nie tut: direkte Datenbankschreibzugriffe auf SAP-Tabellen, Umgehung der Validierung auf Modulebene oder Pseudo-RFC-Tricks in interne Tabellen.
03
SAP fragt, ob es den Datensatz akzeptiert. Wir fragen, ob Ihr Geschäft damit arbeiten kann.
Feldformate, Pflichtfelder, Customizing- und BAdI-Prüfungen sind die Ebene von SAP – Migration Cockpit, LSMW und BODS validieren dagegen. Ein Datensatz kann all das bestehen und trotzdem unbrauchbar sein: ein Lieferant, der einer Einkaufsorganisation außerhalb der Werkshierarchie zugeordnet ist, eine USt-IdNr. mit richtiger Länge und falscher Prüfziffer, Zahlungsbedingungen außerhalb der Einkaufsrichtlinie, ein strategischer Kunde ohne Key Account Manager. Das sind stille Fehler; sie tauchen Monate nach dem Go-live auf, in der Buchhaltung oder in einer blockierten Freigabe. In der Regelbibliothek von DMW definiert Ihr Geschäft sie einmal, und jeder Datensatz wird vor dem Laden geprüft.
Objektübergreifende KonsistenzLieferant ↔ Einkaufsorganisation ↔ Werk; Kostenstelle ↔ Profit-Center ↔ Buchungskreis; Vertriebsbereich ↔ Werk.
Regulatorische FormateNIP, USt-IdNr, GB VAT, EIN – mit Prüfziffern; Branchenkennungen; DSGVO-Aufbewahrungskennzeichen.
Financial GovernanceBankland vs. Sitz, Daten zum wirtschaftlich Berechtigten, Kreditlimits vs. Freigabe, Sanktionsrisiko.
GeschäftsrichtlinienZahlungsbedingungen je Lieferantenkategorie, Rabattobergrenzen je Segment, Preise vs. Markenregeln.
Workflow-VoraussetzungenKey Account Manager je strategischem Kunden, Kostenstellenverantwortlicher, Disponent je Material.
Kohärenz der StammdatenPreiskonditionen je Vertriebsbereich, Infosätze je Einkaufsorganisation, Equipment ↔ Technischer Platz.
04 · Customer Vendor Integration
CVI ist hier Routinearbeit, kein Risikopunkt.
DMW bereitet vor; SAP führt aus. Der Datensatz, der CVI erreicht, ist bereits konsistent.
- 01Zusammenführung Kunde + Lieferant
- Deterministischer und unscharfer Abgleich nach Name, USt-IdNr., Adresse und Bankverbindung; ein BP-Kandidat mit FLCU01 + FLVN01; Abweichungen zur fachlichen Entscheidung markiert; Querverweistabelle für Audit und Abstimmung.
- 02BP-Gruppierung und Nummernkreise
- Alte Kontengruppen auf Ihre BP-Gruppierungen aus dem Customizing gemappt; Pflichtfelder je Gruppierung vor dem Laden validiert.
- 03BP-Kategorie
- Person / Organisation / Gruppe aus den Altdaten abgeleitet und gegen die Rollen jedes Datensatzes geprüft.
- 04Adressen, Steuernummern, Bankdaten
- Haupt- und Zusatzadressen nach BUT020/BUT021; STCD1–3 / STCEG auf S/4-Steuernummerntypen gemappt und je Land validiert; IBAN und Bankschlüssel gegen BNKA geprüft.
05
Wo es läuft.
- Hosting
- EU · AWS oder OVHcloud (Deutschland), nach Ihrer Wahl – oder Ihre eigene Infrastruktur, Aufwand auf Anfrage
- Konnektivität
- Site-to-Site-IPsec-Tunnel, beschränkt auf das vereinbarte Subnetz – oder eine Extrakt-Übergabe
- Zugriff
- Rollenbasiert (CAS), je Programm / Projekt / Standort
- Verschlüsselung
- TLS bei der Übertragung; Backups und gespeicherte Zugangsdaten verschlüsselt
- Zertifizierungen
- ISO/IEC 27001, ISO 9001
- KI
- Keine personenbezogenen Daten in KI-Prompts; nur Vorschläge, von Menschen freigegeben
Technische Fragen und Antworten.
- 01Braucht DMW das Migration Cockpit, um zu funktionieren?
- Nein. vise DMW hat eine eigene Lade-Engine, die Standard-SAP-Schnittstellen nutzt. Das Cockpit ist eine Option, keine Voraussetzung: Wenn Sie es behalten, liefert DMW den vorvalidierten Datensatz für den Upload.
- 02Kann ein kundeneigener Funktionsbaustein oder ein Z-Programm das Ladeziel sein?
- Ja, über RFC. Geschäftspartner laden wir bereits so: ein Aufruf je Partner an einen kleinen RFC-fähigen Funktionsbaustein, der in Ihrem System installiert ist und die SAP-eigene Geschäftspartner-Pflege-API aufruft. Geschrieben wird weiterhin von SAP – Customizing, CVI, Nummernkreise und Änderungsbelege bleiben aktiv, und nichts greift direkt auf eine Tabelle zu.
- 03S/4HANA Public Cloud, wo es keinen direkten DB- oder klassischen BAPI-Zugriff gibt?
- OData-/RAP-APIs (API_BUSINESS_PARTNER und verwandte) – der native SAP-Weg für die Public Cloud. Direkter Datenbankzugriff ist weder möglich noch nötig.
- 04Wie sieht die Performance bei 5 Mio.+ Datensätzen aus?
- Der Ladedurchsatz hängt vom Ziel, der Schnittstelle und Ihren BAdIs ab. DMW bündelt je Schnittstelle (parallele BAPI-Verarbeitung, IDoc-Paketierung). Wir nennen keine Zahlen ohne Benchmark auf Ihren Daten – dafür ist der PoC da.
- 05Kundeneigene BP-Rollen oder -Gruppierungen?
- Validierungsregeln sind Konfiguration, kein Code, den wir ausliefern müssen. Eigene Rollen mit ihren Pflichtfeldern und eigene Gruppierungen werden je Kunde ergänzt.
- 06Was passiert, wenn ein Datensatz während des Ladens an der CVI-Synchronisation scheitert?
- Wiederholung auf Datensatzebene, Isolation im Paket und eine Fehler-Queue. Der fehlerhafte Datensatz geht in die Korrektur, der Rest des Ladevorgangs läuft weiter, der Datensatz wird nach der Korrektur erneut verarbeitet.
- 07BP-Beziehungen (BUT050)?
- Eine eigene Objektklasse im Mapping. Zuerst die primären BPs, dann die Beziehungen (Ansprechpartner → Organisation), in der Reihenfolge, die CVI erwartet.
- 08Wie wird die Reihenfolge abhängiger Ladevorgänge festgelegt, und können Ladevorgänge parallel laufen?
- Abhängigkeiten bestimmen die Ladereihenfolge: Partner vor Beziehungen oder Verträgen, Kopfdaten vor Positionen. Jeder Datensatz wird zuerst simuliert und erst nach einer fehlerfreien Simulation festgeschrieben, nie nach einer blockierenden SAP-Meldung. Parallele Sitzungen laufen je Zielsystem mit Isolation auf Datensatzebene; der Grad der Parallelität wird je Installation eingestellt.
- 09Greenfield-S/4 mit einer Nicht-SAP-Quelle?
- Ja. Jede Quelle: Alt-ERP, Excel, Staging-Tabellen, Dateien. Carve-outs und M&A-Integrationen sind typisch.
- 10Welche Quellen kann vise DMW lesen?
- SAP ECC und S/4HANA direkt oder aus einem Extrakt, andere Datenbanken wie Microsoft SQL Server und PostgreSQL, Dateien, Azure Blob Storage einschließlich Parquet, eine Staging-Datenbank und APIs wie die von Microsoft Dynamics 365 Business Central. Zugriff auf ein Produktivsystem ist nicht nötig: Ein Extrakt oder ein Replikat genügt.
- 11IS-U und die Migrations-Workbench (EMIGALL)?
- Wir haben noch keine produktive IS-U-Referenz und sagen das lieber offen. Vertragskonten, Anlagen und Geräte werden wie jedes andere Objekt aufgenommen: Vorlagen, Mappings und Validierungsregeln, geprüft in einem PoC an Ihren Objekten. EMIGALL ist heute nicht integriert; die beiden Wege sind eine Importdatei in der Struktur, die Ihre Migrationsobjekte erwarten, oder RFC-Aufrufe an die Workbench – den Umfang legen wir mit Ihnen im PoC fest.
- 12Korrekturen nach dem Go-live?
- Das ist vise Data Run: dieselbe Validierungsbibliothek, optimiert für wiederkehrende Massenänderungen statt für eine einmalige Migration.
- 13SAP-Partnerschaft oder -Zertifizierung?
- Visehub ist bewusst kein SAP-Partner. vise DMW arbeitet über die freigegebenen Schnittstellen von SAP (BAPI, IDoc, OData/RAP, Migration Cockpit) unter Ihrer eigenen SAP-Lizenz, sodass nichts davon von einem Partnerprogramm abhängt – und in unserem Preis steckt keine Partnermarge.
Bringen Sie Ihr Landschaftsdiagramm mit. Wir bringen die Antworten.
Eine 60-minütige technische Session mit den Leuten, die die Lade-Engine gebaut haben – kein Vertriebsgespräch.