SAP-Dateien hochladen

Lade die SAP-Export-Dateien hoch — als einzelne CSV/TXT oder als ein 7z-Archiv. Speedtest

7z / ZIP Archiv
Ein Archiv mit allen 6 Dateien — Dateinamen werden automatisch zugeordnet
oder einzelne Dateien
E070 (D10)
Aufträge + Typen
E071 (D10)
Auftragsinhalte
Import History T10
Referenzsystem
Import History P10
Grundlage Y10
VRSD T10
Coding-Versionen T10
VRSD P10
Coding-Versionen P10
Import-History Y10
Importreihenfolge Y10 (für Cross-Check nach Re-Import)
VRSD Y10
Objektversionen Y10 — Cross-Check T10 vs Y10
Nur TRs nach diesem Datum berücksichtigen

Hochgeladene Eingabedateien herunterladen

Aktuelle E070, E071, Import-Histories, VRSDs und Konfiguration als einzelne Dateien oder als Archiv (tar.gz schnell, 7z deutlich kleiner).

Datei Beschreibung Größe Geändert Download
Klick „Liste aktualisieren"

Excel anreichern (fehlende Y10-Objekte)

Excel/CSV mit Objekten hochladen, die auf Y10 fehlen. Datei wird unter uploads/_enrich_<name> abgelegt — danach ergänzt der Agent den Typ (PGMID / OBJECT) für SE01-fähigen Import.

Übersicht

—
Gesamt TRs
—
Import-Queue
—
Coding-TRs
—
Customizing-TRs
—
Übersprungen
—
Laufzeit

Noch keine Analyse verfügbar.
Lade Dateien hoch und starte die Analyse.

Resolver-Logik

Regelwerk zur Bestimmung der Import-Queue von T10 nach Y10.

🎯

Ziel

Das Zielsystem Y10 erhält eine Systemkopie von P10. Alle Änderungen die nach dem Stichtag in T10 passiert sind, müssen nach Y10 transportiert werden — in der richtigen Reihenfolge und ohne Downgrades.

🗃

Systemlandschaft

T10 Testsystem Import P10 Produktivsystem Y10 Zielsystem Sys-Copy Delta-Import (diese Queue)
📋

So funktioniert es

  • Stichtag setzen: Datum der letzten Systemkopie P10 → Y10. Alles davor ist schon im Zielsystem.
  • Coding prüfen: Welche Programmier-Objekte haben sich in T10 geändert und sind noch nicht in P10?
  • Customizing prüfen: Welche Konfigurations-Transporte fehlen in P10?
  • Abhängigkeiten auflösen: Wenn ein Transport ältere Versionen enthält, werden automatisch die neueren mitgenommen.
  • Sortieren: Alle Transporte in der gleichen Reihenfolge wie sie in T10 importiert wurden.
</>

Coding: Brauche ich diesen Transport?

Objekt in T10 z.B. Report, Klasse Gleicher Stand wie in P10? Ja Passt schon Nein Neuer Transport noch nicht in P10? Nein Import-Artefakt Ja Importieren! + Abhängigkeiten Abhängigkeiten: Wenn der Transport ältere Versionen mitbringt, werden neuere automatisch dazugenommen (Downgrade-Schutz).
⚙

Customizing: Brauche ich diesen Transport?

Transport in T10 nach Stichtag Schon in P10 importiert? Ja Nicht nötig Nein Importieren! + Abhängigkeiten Abhängigkeiten: Wenn spätere Transporte die gleichen Tabellen ändern, werden sie automatisch mitgenommen.
⚙

Grundregeln

  • Stichtag: Nur TRs die nach dem Stichtag (Sys-Copy) in T10 importiert wurden sind relevant. Alles davor ist durch die Systemkopie abgedeckt.
  • Import-History: Quelle der Wahrheit für Import-Zeitpunkte. Kein TR ohne T10-History-Eintrag ist relevant.
  • E071: Quelle der Wahrheit für Objektzuordnung pro TR. VRSD-Nebenprodukte (DOCU, CUAD, etc.) werden ignoriert.
  • Sortierung: Alle TRs chronologisch nach T10-Import-Zeitstempel (Datum + Uhrzeit), gemischt Coding + Customizing.
⚒

TR-Typen

  • WORKBENCH Entwicklungsobjekte (TRFUNCTION K/S/R/O/E)
  • CUSTOMIZING Tabelleneinträge (TRFUNCTION W/Q/C)
  • ToC Transport of Copies (TRFUNCTION T) — wird anhand der enthaltenen Objekte Coding und/oder Customizing zugeordnet
  • AUTH Reine Berechtigungstransporte (nur ACGR + zugehörige Customizing-Daten)
  • LANG Sprachtransporte (TRFUNCTION L) — wie ToC dual-getrackt
  • PIECE Piece-Listen (TRFUNCTION G) — wie ToC dual-getrackt
</>

Coding-Resolver (Workbench)

VRSD Objekt T10 vs P10 TR T10 = TR P10? Ja Nicht importieren Nein Objekt in E071? Nein VRSD-Nebenprodukt (DOCU, CUAD, etc.) Ja T10-TR in P10 importiert? Ja Import-Artefakt Nicht importieren Nein IMPORTIEREN TR selektieren Transitiver Downgrade-Schutz (kaskadierend) Selektierter TR Prüfe Objekte in E071 Neueste T10- Version = anderer TR? Nein OK — kein Downgrade Ja Anderen TR auch selektieren Kaskadiert
⚙

Customizing-Resolver

TR in T10-History (nach Stichtag) TR in P10-History? Ja Bereits in P10 Nicht importieren Nein IMPORTIEREN Delta-TR selektieren Transitiver Downgrade-Schutz (kaskadierend) Selektierter TR Prüfe Tabellen in E071 Neuerer TR für gleiche Tabelle? Nein OK — kein Downgrade Ja Neueren TR auch selektieren Kaskadiert

Vollständige Pipeline von Datei-Parsing bis Repair-Liste — 17 Blöcke in 4 Phasen. Implementiert in server.js /api/analyze.

Phase A

Parsing & Klassifikation

1
E070 parsen
TR-Header lesen, TR-Typ klassifizieren: WORKBENCH (K/S/R/O/E), CUSTOMIZING (W/Q/C), T (ToC), LANG (L), PIECE (G), FACILITY (F). ToCs/LANG/PIECE werden wie Workbench+Customizing dual-getrackt — E071 entscheidet später anhand des Inhalts. Beschreibung und Owner extrahieren.
in: e070.csv out: e070{tr→{type, description, owner}}
lib/csv-parser.js · parseE070 + normaliseType
2
E071 + Histories + VRSD parallel streamen
Großdateien (~5 GB) mit Streaming parsen. E071: Object-Maps (TR↔Object), Tables, mixed/AUTH-only-Klassifikation. ToCs werden anhand ihrer Inhalte (Objekte vs. Tabellen) WB/CUST zugeordnet.
in: e071, history_t10/p10, vrsd_t10/p10 out: trToObjects, objectToTRs, trToTables, vrsdT10/P10, mixedTRs, acgrOnlyTRs
parseE071Maps · parseImportHistory · parseVRSD
3
Cutoff-Filter (Stichtag)
Manueller Stichtag aus Request oder Auto-Detect aus frühestem Y10-Import-Datum. TRs vor Stichtag sind durch Systemkopie abgedeckt — aus History & t10ValidTRs entfernen, in y10ImportedQueue aufnehmen.
in: histT10, histY10, cutoffDate? out: t10ValidTRs (gefiltert), y10ImportedQueue
server.js · sapDateToSortable + Auto-Cutoff
Phase B

Resolver & Queue-Aufbau

4
Old Queue (Baseline ohne CLAS-Expansion)
Erst Coding-Resolver + Non-VRSD-Fallback OHNE CLAS-Sub-Object-Expansion. Dient als Vergleich/Baseline und als Fallback wenn keine Y10-History vorhanden ist.
out: oldFullQueue (Set)
resolveCodingTRs + findNonVrsdTRs
5
Master → Sub-Object Expansion erweitert
Für jedes Master-Objekt aus VRSD T10 alle zugehörigen Sub-Objekte zuordnen — nicht nur CLAS:
  • R3TR CLAS → METH, CINC, CLSD, CPRI, CPRO, CPUB
  • R3TR INTF → METH, CINC, INTD
  • R3TR MSAG → MESS
  • R3TR DOMA → DOMD
  • R3TR DTEL → DTED
  • R3TR TABL → TABD, CHDO
  • R3TR PROG → REPS, REPT, DYNP, CUAD, VARX, AVAS
  • R3TR FUGR → FUNC, REPS, DYNP, CUAD, DTEL (FUNC via E071-Co-Occurrence, da Names nicht namens-konventionell)
Naming-Convention-basiert (1:1, Space-Split, Padding-Split mit =) plus E071-Co-Occurrence-Fallback für FUGR→FUNC. Voraussetzung für korrekte Plausi-Check-Erkennung.
in: vrsdT10, knownMasterNames (8 Typen) out: masterToSubKeys (Map), erweiterte trToObjects
buildMasterToSubKeys + buildFugrFuncCoOccurrence
6
Coding-Resolver (Workbench)
Pro Objekt: TR-Vergleich T10 vs. P10 — bei unterschiedlichem TR den mit neuester T10-Position auswählen, transitiv kaskadierend (Downgrade-Schutz). VRSD-Nebenprodukte (DOCU, CUAD …) werden via E071 ausgefiltert.
out: codingResult { selectedTRs, objectMap, dependencyGraph, warnings }
lib/coding-resolver.js · resolveCodingTRs
7
Customizing-Resolver
Delta T10 \ P10 in History-Reihenfolge. Kaskadierender Tabellen-Schutz: wenn eine spätere TR die gleichen Tabellen ändert, mitnehmen.
out: customizingResult { deltaTRs, dependencyGraph, warnings }
lib/customizing-resolver.js · resolveCustomizingTRs
8
Hybrid-Resolver
Cross-Resolver-Transitiven (Coding-Objekt zieht Customizing-TR mit oder umgekehrt), Non-VRSD-Fallback und AUTH-only-Sonderbehandlung (ACGR-Transporte). Convergence-Loop bis stabil oder max. 20 Iterationen (mit Warnung wenn Limit erreicht). Sortierung mit Tertiär-Sort auf trNumber als Tie-Breaker für vollständigen Determinismus.
in: codingResult, customizingResult, mixedTRs, acgrOnlyTRs out: erweiterte coding-/customizingResult, hybridStats
lib/import-queue.js · resolveHybrid
Phase C

Y10-Korrektur (Repair-Liste)

aktiv bei Y10-Upload
Hinweis: Diese Phase läuft automatisch sobald vrsd_y10.csv bzw. import_history_y10.csv hochgeladen sind. Sie vergleicht VRSD T10 ↔ Y10 und erzeugt eine Repair-Liste für DGPs (Downgrade-Korrekturen). Ohne Y10-Files wird die Phase übersprungen.
9
Y10-Simulation: Last-Touch pro Sub-Objekt
Single-Pass über Y10-Import-History (sortiert): pro Sub-Objekt die letzte berührende TR speichern. R3TR CLAS berührt ALLE Sub-Objekte der Klasse, METH/CINC nur das jeweilige. Vergleich mit VRSD-T10: ist die letzte Y10-TR älter als der T10-Stand → Downgrade!
out: directRepairTRs (CLAS-Downgrades)
server.js · Step D.1
10
Deletion-TRs (OBJFUNC=D)
Löschtransporte (D10/X10) die in T10 importiert sind aber nicht in Y10 — in Repair-Liste aufnehmen, damit gelöschte Objekte sauber bereinigt werden. Sub-Objekte gelöschter Klassen (explizit oder via späteren CLAS-Rebuild) werden bei Last-Touch-Vergleich übersprungen.
out: deletionRepairTRs, deletedClassNames
server.js · Step D.1b · isSubObjectDeleted
11
Coding-Transitive-Cascade
DepGraph aus Coding-Resolver auf Repair-Set anwenden: wenn TR_B Repair ist und TR_A → TR_B im Graph, dann TR_A auch. Fixpunkt-Iteration.
in: codingResult.dependencyGraph, allRepairTRs out: erweiterte allRepairTRs, repairDepGraph
server.js · Step D.2
12
CLAS-Sub-Object-Cascade
Wenn eine Repair-TR ein R3TR CLAS trägt, würde sie ALLE Sub-Objekte überschreiben. Für jedes Sub-Objekt mit neuerer T10-Version: diese TR auch in Repair-Liste, sonst entsteht durch das Repair selbst ein neuer Downgrade. Fixpunkt-Iteration.
out: erneut erweiterte allRepairTRs (clas-cascade)
server.js · Step D.2b
13
Y10 VRSD DGP-Korrektur (Convergence-Loop)
Falls vrsd_y10.csv vorhanden: für ALLE Objekttypen vergleichen T10 vs. Y10 VRSD. Wo Y10 eine ältere TR trägt → DGP-Korrektur. Convergence-Loop: neue DGP-TRs → CLAS-Cascade + Coding-Transitive → weitere DGPs erkennen, bis stabil.
in: vrsdT10, vrsdY10, t10PositionMap out: dgp-correction-TRs in allRepairTRs
server.js · Step D.4
14
Y10 VRSD Post-Filter
Transitive Repair-TRs entfernen, deren Objekte auf Y10 alle bereits korrekt sind — aber nur wenn auch der Parent gefiltert wird (kaskadierend). Wenn Parent bleibt, würde das Re-Import gemeinsame Objekte überschreiben → neuer DGP.
out: bereinigte allRepairTRs
server.js · Step D.4b
15
Y10 VRSD Final-Verification
Garantie-Check: für jedes D10/X10-Objekt mit Downgrade in Y10 prüfen ob es in der Repair-Liste ist. Ergebnis: checked / alreadyCorrect / inRepairList / overwrittenByLater / missing. Ziel: missing = 0.
out: y10Verification (im Frontend angezeigt)
server.js · Step D.5
Phase D

Output

16
Liste 1: Import-Queue (Gesamtliste) aktiv
Coding + Customizing + Hybrid — sortiert nach T10-Import-Zeitstempel (Datum + Uhrzeit, Tertiär-Sort: trNumber für Determinismus), dedupliziert. Mixed-TRs erhalten listType=MIXED, AUTH-only trType=AUTH. CSV-Spalten: Position, TR-ID, Type, List, Import Date, Import Time, T10-Importreihenfolge, T10-Anomalie, Plausi-Downgrade, Plausi-Downgrade-Objekte, Plausi-Downgrade-Objektliste.
out: queue (Array), exportAsCSV/Text
lib/import-queue.js · buildImportQueue
17
Plausi-Check (Queue-Simulation) aktiv
Simulation des Imports in Queue-Reihenfolge: pro VRSD-Objekt den letzten berührenden TR ermitteln. Wenn dieser Last-Touch-TR nicht den neuesten T10-Stand hat (per t10Position) → Plausi-Downgrade. Skip-Regeln: gelöschte Master (OBJFUNC=D), spätere Master-Rebuilds, Sub-Object's Master nicht in Queue. Annotiert jeden TR mit plausiDowngrade=ja, Anzahl + Liste der betroffenen Objekte. Aktuell: 725 Downgrades / 114 TRs (vor Master-Bridges: 1.970/186).
in: queue, vrsdT10, t10PositionMap, masterToSubKeys out: plausiCheck { downgrades, affectedTRs, sample } + queue-Annotation
server.js · Plausi-Check (post-Queue)
18
Liste 2: Repair-Queue aktiv bei Y10-Upload
Alle allRepairTRs mit Begründung (Downgrade / Löschtransport / DGP-Korrektur / clas-cascade), isReImport-Flag wenn schon in Y10, isDgpCorrection-Flag bei VRSD-Lücke. Export via /api/export/repair-csv.
out: repairQueue, repairCsv, repairStats
lib/import-queue.js · buildRepairList · exportRepairAsCSV
Phase E

Audit & Reproduzierbarkeit

19
Run-Meta + SHA-256-Manifest aktiv
Pro /api/analyze-Lauf wird ein eindeutiger runId erzeugt und ein Manifest mit SHA-256 aller Eingabe-Dateien (inkl. 3.7 GB E071, streaming-gehasht) plus toolVersion (git commit oder package version) und Start/Finish-Zeitstempeln gespeichert. So ist 12 Monate später nachvollziehbar, welche Inputs welche Queue erzeugt haben.
out: runMeta { runId, toolVersion, runStartedAt, runFinishedAt, inputManifest{name,sha256,sizeBytes,modified} }
server.js · sha256OfFile (streaming) + crypto.randomBytes
20
Append-Only Audit-Log aktiv
Jeder analyze_start, analyze_finish, analyze_error wird in uploads/_audit.jsonl (JSONL, append-only) protokolliert — mit Timestamp, runId, toolVersion und Stats. Plus: atomic-write für _last_results.json (temp+rename) und Race-Lock (runExclusive) für serielle Analyse-Läufe.
out: uploads/_audit.jsonl (append-only)
server.js · auditLog + runExclusive + atomic save
21
Blacklist mit Audit-Schema aktiv
TRs in uploads/blacklist.json werden niemals importiert. Vor Resolvers: Histories filtern, E071-Maps prunen, VRSD-T10 fix-upen (next-newest non-blacklisted TR pro Objekt aus objectToTRs). Schema unterstützt jetzt Pflichtfelder pro Eintrag: trNumber, addedBy, addedAt, reason, ticketRef.
in: uploads/blacklist.json (8 TRs aktiv) out: blacklistStats { size, list, entries, vrsdReplaced, vrsdOrphaned, ... }
server.js · Blacklist-Block (vor Cutoff-Filter)

Coding-TRs

Objekte mit neuerer Version in T10 als P10. Pro Objekt wird der TR mit neuester Version gewählt, inklusive transitiver Abhängigkeiten.

Keine Coding-TRs vorhanden.

Customizing-TRs

Delta T10 → P10: Alle fehlenden Customizing-Transporte in Import-Reihenfolge.

Keine Customizing-TRs vorhanden.

Plausi-Check (Final-State-Analyse)

Simulation: vrsdP10 + Queue-Import versus vrsdT10. Drei Delta-Kategorien werden geprüft, um zu zeigen ob nach dem Import noch ein Stand ungleich dem T10-Soll wäre.

Was sind Datenbank-Lücken (P10-pre-existing & Missing)?

  • P10-pre-existing: Das Objekt steht in vrsdP10 mit einem anderen TR als vrsdT10 — obwohl der T10-newest-TR laut import_history_p10 in P10 angekommen ist. Ursache: die VRSD-Tabelle in P10 wurde nicht korrekt aktualisiert (z.B. nach Re-Import oder Mandanten-Migration). Wirkung: nach Queue-Import bleibt das Objekt im falschen Stand. Fix: SAP-Basis-Team via SE03 → Tools → Konsistenzcheck oder RSWBOIDX-Rebuild.
  • Missing: Das Objekt existiert in vrsdT10, der zugehörige TR ist in import_history_p10 — aber das Objekt fehlt komplett in vrsdP10. Ursache: der TR-Import in P10 ist abgebrochen oder die VRSD-Indexierung hat das Objekt nicht aufgezeichnet. Wirkung: Objekt wird nie auf P10 gepflegt. Fix: Re-Import des TRs auf P10 oder gezielter Repair-Transport, danach RSWBOIDX-Rebuild.
  • Wichtig: Beide Kategorien sind P10-Datenbank-Inkonsistenzen, NICHT durch Queue-Import behebbar. Das Tool macht sie sichtbar, das SAP-Basis-Team muss sie beheben.
—
Geprüfte Objekte
—
Queue-überschreibt
—
P10-pre-existing
—
Missing-Imports

Pattern: Last-Touch-TR in der Queue überschreibt das Objekt mit einer älteren Version als die im VRSD T10 als neueste markiert ist. Diese sind im Hauptqueue-CSV in Spalte „Plausi-Downgrade=ja" markiert.

Objekt Last-TR (Queue) T10-Pos last Newest-TR T10-Pos newest

Pattern: P10 trägt schon einen anderen TR für das Objekt als T10. Das ist eine VRSD-Inkonsistenz auf P10-Seite — durch die Queue nicht behebbar (kein TR in der Queue berührt das Objekt).

Objekt P10-TR T10-Pos P10 Newest-TR (T10) T10-Pos newest

Pattern: Newest-TR existiert (in Queue oder P10), aber das Objekt taucht weder in vrsdP10 auf, noch wird es von einem Queue-TR berührt. Echte Daten-Lücke.

Objekt Newest-TR T10-Pos In Queue? In P10-History?

Export

Exportiere die finale Import-Liste.

Liste 1: Korrigierte Import-Queue
Vollständige Import-Liste mit korrekter Reihenfolge inkl. CLAS-Transitiv-Abhängigkeiten.
Liste 2: Repair-Queue
TRs die nachimportiert werden müssen um CLAS-Downgrades in Y10 zu beheben (inkl. transitive Hüllen).

Cross-Check / Agent-Inspektion

Lade eine Datei (z.B. eine Liste von einem Kollegen) hoch — sie wird auf dem Server gespeichert, sodass der Agent sie inspizieren kann. Sag dem Agenten danach im Chat, was er prüfen soll.

Datei für Agent-Prüfung
Beliebiges Format — CSV, TXT, JSON, Excel-as-CSV, ... (max. 50 MB)