Jedes Szenario folgt demselben Ablauf: Eine DELTA-Variante läuft nach Zeitplan, erreicht jedes Zielsystem per RFC und erzeugt eine farbcodierte Zeile plus ein ServiceNow-Incident — offen, solange die Abweichung besteht, automatisch geschlossen, wenn der nächste saubere Lauf eintrifft.
Artikel-Stammdatenteam · tägliche Variante
Article 100020 was extended to sales org
ER01 in System A vor zehn Tagen. Die Replikation hätte MARC- + MVKE-Zeilen verbreiten sollen an System D within hours, but
something stalled. From the source system everything looks fine;
from System D existiert der Artikel für die neue Vertriebsorg noch nicht.
DELTA's daily variant joins MARA + MARC + MVKE across all four
systems on the (Article, Sales Org, Distribution Channel) key.
System D liefert für diesen Schlüssel keine Zeile — DELTA stellt es dar als Missing data.
PMD_05_MARC_05
VariantePMD_05_DAILY
„Artikel 100020 — Schlüsselkombination fehlt in System D für Vertriebsorg ER01. Replikation könnte fehlgeschlagen sein.“
Geschäftspartner-Team · tägliche Variante
Vendor 1004563 hat seine Lieferadresse aktualisiert. Die Änderung wurde direkt auf System B vorgenommen — am üblichen, von System A gesteuerten Fluss vorbei — und das lokale Update gelangte nie zurück ins Quellsystem oder hinaus in Ihre anderen verbundenen Systeme.
DELTAs GP-Adress-Variante vergleicht BUT020 +
ADRC über alle Systeme auf dem (GP-)Schlüssel. Straße und Postleitzahl stimmen in drei Systemen überein und weichen in einem vierten ab.
BP_ADDR_05
VarianteBP_DAILY
„Lieferant 1004563 — Straße und PLZ weichen in System B gegenüber System A/System C/System D ab. Lokales Update in System B noch nicht zurückrepliziert.“
Kontraktverwaltungs-Team · wöchentliche Variante
Contract 4500876123 erhielt in System A eine Verlängerung um einen Monat (KDATB von 2026-08-30 → 2026-09-30). Der Transport mit der Änderung erreichte System B and System C but
failed quietly on System D. From the buyer's view in System A
everything looks fine; the planner on System D
arbeitet noch mit dem alten Ablaufdatum.
CONTRACT_05_EKKO_05
VarianteCONTRACT_WEEKLY
„Kontrakt 4500876123 — KDATB nicht synchron zwischen System D und dem Rest der Landschaft. Wahrscheinlich fehlgeschlagener Transport TR-System A-244183.“
Preise- & Konditionen-Team · tägliche Variante
Condition record 0000812044 for article
200034 has a validity end date of
2026-08-30 in System A / System B / System C, aber
2026-08-15 in System D — ein Unterschied von 15 Tagen am Ende einer Aktionskampagne.
Das Feld ist konfiguriert als Warnung statt Fehler: Das Team will Sichtbarkeit, aber der Unterschied ist nicht zwingend falsch (rechtliche Kalender variieren). Die Ergebniszeile ist gelb, und ein SNOW-Incident niedriger Schwere wird zur Prüfung geöffnet.
PRICE_KONP_05
VariantePRICE_DAILY
„Kondition 0000812044 (Artikel 200034) — Gültigkeitsende weicht in System D um 15 Tage ab. Kalender vor dem Schließen bestätigen.“
Customizing-Verantwortlicher · wöchentliche Variante (DELTA_CUST)
A new plant 9012 wurde letzten Sprint direkt in System B angelegt, um einen temporären Cross-Docking-Standort zu unterstützen. Die Anpassung landete nie in System A oder in den Schwesterregionen — die Tabelle T001W now diverges by one row.
DELTA's customising-tables variant greift dies in ihrem wöchentlichen Lauf auf. Weil der Vergleich auf dem Customizing-Cluster läuft, nicht auf Stammdaten, löst sich das Ergebnis automatisch auf, sobald das Werk entweder überall ausgerollt oder aus System B entfernt wird.
CUST_T001W_05
VarianteCUST_WEEKLY
Sobald Werk 9012 per Standard-Customizing-Transport ausgerollt (oder aus System B entfernt) wurde, fand der nächste wöchentliche Lauf die vier Systeme abgeglichen — DELTA schloss das Incident mit der Standard-Auto-Close-Notiz.
Egal welche Daten — Artikel, Partner, Kontrakte, Preise, Customizing — die Form ist dieselbe. Eine Sicht definieren, eine Variante speichern, den Lauf einplanen. Das Farbraster und der SNOW-Lebenszyklus erledigen den Rest.
Installation → Zurück zur Übersicht