JTL-Ameise: Warum Importvorlagen still die falschen Felder befüllen
Der Import meldet Erfolg, die Daten stehen im falschen Feld — und niemand merkt es, bis der Shop es anzeigt.
Der Anruf kam an einem Donnerstag: Im Shop stünden bei mehreren hundert Artikeln plötzlich absurde Gewichtsangaben. Der nächtliche Preisimport laufe aber ohne Fehler durch, das Protokoll sei sauber. Genau diese Kombination — sauberes Protokoll, falsche Daten — ist typisch für einen Fehler, der in der JTL-Ameise strukturell angelegt ist.
Wie die Ameise Spalten zuordnet
Eine Importvorlage in der Ameise merkt sich für jedes Zielfeld, aus welcher Spaltennummer der Wert kommt. Nicht aus welcher Spaltenüberschrift — aus welcher Position. Die Nummerierung beginnt dabei bei null, was beim manuellen Nachrechnen regelmäßig für Verwirrung sorgt.
Solange die Quelldatei exakt gleich aufgebaut bleibt, ist das unproblematisch. Ändert sich die Struktur aber — weil jemand im Exportsystem ein Feld ergänzt, weil ein Lieferant seine Preisliste um eine Spalte erweitert, weil ein Kollege die Datei in Excel öffnet und eine Hilfsspalte einfügt — dann rutscht ab dieser Position alles um eins nach rechts.
Die Ameise merkt davon nichts. Sie liest weiter Spalte 7 und schreibt sie in das Feld, das vor drei Monaten für Spalte 7 hinterlegt wurde. Dass dort jetzt die Lieferzeit statt des Gewichts steht, kann sie nicht wissen.
Das Erkennungsmuster im Protokoll
Zwei Signale im Importprotokoll deuten auf Drift hin:
Aktualisierte Datensätze fallen auf null. Wenn die Schlüsselspalte — meist die Artikelnummer — mitverrutscht ist, findet die Ameise keinen einzigen Treffer mehr. Der Import läuft durch, ändert aber nichts. Ohne Blick ins Protokoll fällt das tagelang nicht auf.
Die Zahl der Formatfehler bleibt konstant. Das ist das verräterischere Signal. Wechselnde Daten erzeugen wechselnde Fehlerzahlen. Steht in jedem Durchlauf exakt dieselbe Zahl, dann scheitert nicht der Inhalt, sondern die Struktur: In ein Zahlenfeld läuft konsequent Text, und zwar in jeder Zeile.
Am gefährlichsten ist der Fall dazwischen: Wenn die verschobene Spalte zufällig ebenfalls Zahlen enthält, gibt es überhaupt keine Meldung. Der Import ist formal korrekt und inhaltlich Unsinn. Genau das war beim Gewichtsfeld passiert.
Drei Maßnahmen, die das Problem beenden
1. Kopfzeile vor dem Import prüfen
Die wirksamste Maßnahme ist auch die simpelste: Bevor die Datei in die Ameise geht, wird ihre Kopfzeile gegen eine erwartete Reihenfolge geprüft. Weicht sie ab, bricht der Vorgang ab, statt Daten zu verbiegen.
$erwartet = 'ArtNr;Name;Preis;Gewicht;Lieferzeit'
$kopf = (Get-Content .\preise.csv -TotalCount 1).Trim()
if ($kopf -ne $erwartet) {
Write-Error "Spaltenstruktur weicht ab. Import abgebrochen.`nErwartet: $erwartet`nGefunden: $kopf"
exit 1
}
Zehn Zeilen, die verhindern, dass eine stille Verschiebung in die Warenwirtschaft läuft. Wer die Ameise per Aufgabenplanung nachts startet, hängt diese Prüfung davor.
2. Die Quelldatei nicht von Hand anfassen
Jeder manuelle Schritt zwischen Export und Import ist eine Gelegenheit für Drift. Excel ist dabei besonders tückisch: Es öffnet CSV-Dateien nicht nur, es interpretiert sie — führende Nullen in Artikelnummern verschwinden, Zahlen mit Punkt werden zu Datumsangaben, das Trennzeichen ändert sich beim Speichern je nach Systemeinstellung. Wenn Zwischenschritte nötig sind, gehören sie in ein Skript, nicht in eine Tabellenkalkulation.
3. Vorlagen versionieren und dokumentieren
Importvorlagen leben oft jahrelang, während die Menschen wechseln, die sie gebaut haben. Legen Sie zu jeder produktiven Vorlage eine kurze Notiz ab: welche Quelldatei, welche Spaltenreihenfolge, welches Trennzeichen, welche Kodierung, welches Zielfeld an welcher Position. Eine einzige Textdatei im Importordner erspart die Rekonstruktion aus dem Gedächtnis.
Was ich zusätzlich empfehle
Erst im Testsystem, dann produktiv. Eine Testinstanz der Wawi mit einer Kopie der Datenbank kostet wenig und fängt genau die Fälle ab, in denen ein Import formal durchläuft, aber falsche Werte schreibt.
Nach dem ersten Lauf stichprobenartig prüfen. Nicht das Protokoll — die Daten. Fünf Artikel aufmachen und schauen, ob in den Feldern steht, was dort stehen soll. Das dauert zwei Minuten und ersetzt jede Vermutung.
Änderungen an Exporten ankündigen lassen. Wenn Lieferanten oder Dienstleister die Struktur ihrer Dateien ändern, ist das für sie eine Kleinigkeit. Für Ihre Importstrecke ist es ein Bruch. Die Bitte, solche Änderungen vorher mitzuteilen, kostet nichts — und wird erstaunlich oft befolgt, wenn man einmal erklärt hat, warum.
Im eingangs geschilderten Fall war die Ursache übrigens harmlos: Der Lieferant hatte seiner Preisliste eine Spalte mit der internen Warengruppennummer vorangestellt. Eine sinnvolle Ergänzung, freundlich gemeint. Sie hat vierhundert Artikeln ein neues Gewicht verpasst.
Häufige Fragen
Warum meldet die Ameise keinen Fehler, wenn Spalten vertauscht sind?
Weil die Zuordnung über die Spaltenposition erfolgt, nicht über den Spaltennamen. Steht in einer Spalte ein Wert, der zum Zielfeld formal passt, ist der Import aus Sicht der Ameise korrekt. Erst wenn ein Text in ein Zahlenfeld läuft, gibt es eine Formatmeldung — inhaltlicher Unsinn im richtigen Format fällt nicht auf.
Woran erkenne ich, dass eine Vorlage gedriftet ist?
Am typischen Muster im Importprotokoll: die Zahl der aktualisierten Datensätze fällt auf null, während die Zahl der Formatfehler über alle Durchläufe konstant gleich bleibt. Eine gleichbleibende Fehlerzahl bei wechselnden Daten deutet fast immer auf eine strukturelle Verschiebung hin, nicht auf einzelne schlechte Zeilen.
Wie mache ich Importvorlagen unempfindlich gegen Änderungen?
Indem die Quelldatei nicht von Hand entsteht, sondern aus einem Export mit fest definierter Spaltenreihenfolge, und indem vor jedem Import die Kopfzeile gegen eine erwartete Liste geprüft wird. Ein zehnzeiliges Prüfskript, das bei Abweichung abbricht, verhindert genau die Fehler, die man sonst tagelang sucht.
