Schnittstellen testen: Shop, Bank, Kasse und Buchhaltung vor dem Start
Kurz gesagt
Testen Sie jede Anbindung vor dem Go-live mit vier Testarten: gültiger Fall, Fehlerfall, Tagesspitzenvolumen und doppelte Sendung. Je Schnittstelle: ein gültiger und ein fehlerhafter Datensatz, das Spitzenvolumen eines Tages, eine Kopie für die zweite Lieferung. Bestanden ist sie erst, wenn jeder Fall sein vorher festgelegtes Soll-Ergebnis erreicht: der gültige Satz kommt vollständig an, der Fehlersatz wird ganz abgewiesen, das Tagesvolumen läuft durch, die zweite Sendung erzeugt keinen zweiten Satz. Das gilt für Deutschland, Österreich und die Schweiz.
Das Wichtigste
- Je Anbindung vier Fälle: gültig, fehlerhaft, Tagesspitze, Dublette.
- Das Tagesspitzenvolumen ist der Maßstab für den Mengentest, nicht ein Durchschnittswert.
- Ein Fehlerfall gilt als bestanden, wenn der ganze Satz abgewiesen und der Fehler gemeldet wird.
- ISO/IEC/IEEE 29119-2:2021 beschreibt Testprozesse; verpflichtend wird sie nur über Vertrag oder Werkvereinbarung.
- Nach RFC 9110, Abschnitt 9.2.2, sind PUT, DELETE und die lesenden Methoden idempotent; eine andere Methode dürfen Sie nur automatisch wiederholen, wenn ihre Semantik nachweislich idempotent ist oder die ursprüngliche Anfrage nachweislich nicht angewendet wurde.
Eine Anbindung ist die Verbindung zwischen Ihrem ERP und einem Nachbarsystem; ihre Schnittstelle beschreibt Felder, Formate und Fehlercodes. Ob die Anbindung trägt, zeigt sich im Tagesgeschäft unter vier Belastungen: einem gültigen Fall, einem falschen Fall, dem Spitzenvolumen und einer doppelten Lieferung.
Was Sie vorab brauchen
- eine Liste der Anbindungen mit Richtung (liest, schreibt, beides), Takt (sofort, stündlich, nächtlich) und zuständiger Person
- die Schnittstellenbeschreibung jedes Nachbarsystems: Feldnamen, Pflichtfelder, Formate, erlaubte Werte, Fehlercodes
- eine Testumgebung auf beiden Seiten, die keine echten Belege, Zahlungen oder Buchungen erzeugt
- Testzugangsdaten je Anbindung, getrennt ausstellbar und widerrufbar
- vier Testdatensätze je Anbindung: gültiger Fall, Fehlerfall, Tagesspitzenvolumen, Dublette
- ein Protokollblatt mit einer Zeile je Testfall: Datum, Erwartung, Ist-Wert, Ergebnis
Als Gliederung dient die Norm ISO/IEC/IEEE 29119-2:2021 (Active Standard, veröffentlicht am 28. Oktober 2021). Nach der Beschreibung ihrer Herausgeberin umfasst sie die Prozesse, in denen eine Organisation ihre Tests steuert und ausführt, und gilt für jedes Vorgehensmodell. Verpflichtend wird eine Norm nicht durch Gesetz, sondern nur dort, wo ein Vertrag, eine Werkvereinbarung oder ein Prüfauftrag sie festschreibt; dasselbe gilt für die hier genannten RFCs. Der Normentext ist kostenpflichtig; die Gliederung dieses Artikels ist eine eigene.
Schritt für Schritt: vier Testarten je Anbindung
Schritt 1: Anbindung mit Richtung, Takt und Schlüsselfeld erfassen
Notieren Sie je Anbindung, wer schreibt und wer liest, wie oft ausgetauscht wird und welches Feld den Satz eindeutig macht (Auftragsnummer, Belegnummer, Verwendungszweck). Ohne dieses Feld bleibt der Wiederholungstest aus Schritt 6 unauswertbar. Ende: eine Zeile je Anbindung mit Richtung, Takt und Schlüsselfeld.
Schritt 2: Testumgebung und vier Testdatensätze bereitstellen
Legen Sie auf beiden Seiten einen Testzugang an, der keine echten Belege, Zahlungen oder Buchungen erzeugt, und klären Sie schriftlich, ob er eine eigene Datenbasis hat. Bereiten Sie je Anbindung vier Fälle vor: gültigen Satz, Fehlersatz, Tagesspitzenvolumen und eine Kopie des ersten Satzes. Ende: alle vier Fälle liegen bereit.
Schritt 3: Positivtest fahren
Senden Sie den gültigen Satz und verfolgen Sie ihn über beide Systeme. Dass etwas ankommt, genügt nicht: Prüfen Sie jedes Feld, das Ihr Prozess danach braucht, etwa Menge, Preis, Steuerschlüssel und Konto. Beim Shop steht der Testauftrag vollständig im ERP, bei der Kasse stimmen die Summen mit dem Kassenbericht überein. Ende: jedes geprüfte Feld stimmt.
Schritt 4: Fehlertest fahren
Senden Sie einen Satz mit einem Fehler und beobachten Sie die Reaktion. Der gewünschte Zustand: Der ganze Satz wird abgewiesen und der Grund gemeldet. Entsteht ein halber Datensatz, ist der Fehlerfall nicht bestanden. Prüfen Sie fehlende Pflichtangabe, unbekannten Schlüssel und falsches Format. Ende: Fehlercode statt halber Buchung.
Schritt 5: Mengentest fahren
Senden Sie das Spitzenvolumen eines Tages, nicht den Durchschnitt: die Bestellungen des stärksten Verkaufstags, alle Positionen eines Monatsauszugs. Beobachten Sie Laufzeit und Satzzahl. Ein Aufruflimit darf mit dem Status 429 angezeigt werden, optional wie das Feld Retry-After für die Wartezeit (RFC 6585, Abschnitt 4; RFC 9110, Abschnitt 10.2.3). Ende: alle Sätze verarbeitet, Grenze und Laufzeit notiert.
Schritt 6: Wiederholungstest fahren
Senden Sie denselben Satz ein zweites Mal und zählen Sie die Sätze auf beiden Seiten. Nach RFC 9110, Abschnitt 9.2.2, sind PUT, DELETE und die lesenden Methoden idempotent; sie dürfen nach einem Verbindungsabbruch automatisch wiederholt werden. Eine andere Methode dürfen Sie nur dann automatisch wiederholen, wenn ihre Semantik für diese Ressource nachweislich idempotent ist oder wenn Sie nachweislich feststellen können, dass die ursprüngliche Anfrage nicht angewendet wurde — dass die erste Sendung nicht angekommen ist, genügt dafür nicht. Kommt der Satz zweimal an, hilft nur eine Dublettenprüfung über das Schlüsselfeld. Ende: kein zweiter Satz.
Die Testmatrix je Anbindung
Die Matrix hält vier Testarten je Anbindung fest; tragen Sie je Zelle Erwartungswert und Ist-Wert mit Datum ein.
| Anbindung | Positivtest | Fehlertest | Mengentest | Wiederholungstest |
|---|---|---|---|---|
| Shop → ERP: Bestellung | Bestellung steht vollständig im ERP | fehlende Zahlungsart wird abgewiesen | alle Bestellungen des stärksten Verkaufstags in einem Lauf | dieselbe Bestellung zweimal ergibt einen Auftrag |
| ERP → Shop: Bestand und Status | Bestandsänderung und Statuswechsel kommen im Shop an | unbekannte Artikelnummer wird zurückgewiesen und gemeldet | Bestandsabgleich über den ganzen Katalog | ein zweiter Statuswechsel zählt nicht doppelt |
| ERP ↔ Bank: Zahlung und Auszug | Zahlungsauftrag angenommen, Auszug gelesen und zugeordnet | falsche Kennung ergibt eine definierte Ablehnung | Auszug eines Monats mit allen Positionen in einem Lauf | derselbe Auftrag wird nicht zweimal ausgeführt |
| Kasse → ERP: Tagesabschluss | Abschluss gebucht, Summen wie im Kassenbericht | unbekannter Steuersatz wird abgewiesen und protokolliert | Abschluss eines starken Tages | zweimal importiert entsteht keine zweite Buchung |
| ERP → Buchhaltung: Stapel | alle Sätze vorhanden, Salden stimmen mit dem ERP | fehlendes Sachkonto erzeugt einen Fehlersatz | Monatsstapel mit dem vollen Buchungsvolumen | derselbe Stapel erzeugt keine doppelten Buchungen |
Für die Bank liefert die Deutsche Kreditwirtschaft die Formatliste: EBICS ist der im DFÜ-Abkommen festgelegte Kommunikationsstandard für Zahlungen, Auszüge und Cash-Management; verbindlich wird er über die Vereinbarung mit der Bank, nicht durch Gesetz. Die Datenformate stehen in der Anlage 3 des DFÜ-Abkommens, in der ab 15. November 2026 gültigen Version 26.11. Für die Schweiz beschreiben die SIX Swiss Payment Standards den Kunden-Bank-Austausch als Marktempfehlung: Zahlungsauftrag (pain.001) und Kontoauszug (camt.053) in der Fassung 2.3 mit Inkrafttreten am 14. November 2026, Statusmeldung (pain.002) in der Fassung 2.2. Fragen Sie die Formatbezeichnung ab, die im Testsystem gilt.
Welche Daten Sie je Anbindung vorbereiten
| Anbindung | Testdaten | Vorher schriftlich klären |
|---|---|---|
| Shop | Testartikel mit Variante, Testkunde, bezahlte und stornierte Bestellung | welche Statuswerte der Shop zurückschreibt und welcher Status den Auftrag freigibt |
| Bank | Testkonto im Testsystem, zwei Zahlungsaufträge (einer mit 50 Positionen, Beispielzahl), ein Auszug mit Rückbuchung | Berechtigung und Unterschriftsregel im Testsystem, Formatbezeichnung von Auftrag und Auszug |
| Kasse | Testbeleg mit zwei Steuersätzen, Abschluss eines Testtags, Bericht aus der Kasse | welches Konto je Zahlungsart gilt und welche Summen der Kassenbericht führt |
| Buchhaltung | Teststapel mit Beispielkonten, ein Satz mit fehlendem Konto, ein voller Monatsstapel | Spaltenreihenfolge, Datumsformat, Dezimalzeichen, Zeichenkodierung |
Beispielfestlegung für eine CSV-Datei: Zeichenkodierung UTF-8, Feldtrenner Semikolon, Dezimalzeichen Komma, Datum als Jahr-Monat-Tag. Das in RFC 4180 beschriebene CSV-Format (Informational, Oktober 2005) behandelt Feldtrenner, Anführungszeichen und Zeilenende, legt aber keinen Zeichensatz fest; der Parameter charset des Medientyps text/csv ist optional (Abschnitt 3). Anführungszeichen grenzen dort nur Felder ab (Abschnitt 2) und legen keinen Datentyp fest: ein Importeur kann einen in Anführungszeichen gelieferten Wert wie 00123 trotzdem als Zahl lesen. Auf Textinterpretation können Sie sich nur verlassen, wenn die Importspezifikation des Gegenübers sie ausdrücklich zusichert. Die Kodierung gehört deshalb in die Schnittstellenbeschreibung und in den Test.
Abweichungen, die im Test auffallen
Die Sammlung ist eine redaktionelle Zusammenstellung möglicher Befunde, kein Messergebnis.
| Befund | Was dahintersteckt | Erster Schritt |
|---|---|---|
| Rundungsdifferenz von einem Cent je Steuersatz | Summen werden je Position gerundet und dann addiert | Rundungsregel festhalten und mit einer Beispielrechnung prüfen |
| Umlaute und ß falsch übertragen | Zeichenkodierung von Datei und Importeur weichen ab | Kodierung festlegen, einen Satz mit Umlauten in die Testdaten aufnehmen |
| Führende Nullen verschwinden bei Artikelnummern | Der Importeur liest die Spalte als Zahl | Schlüsselspalten in der Schnittstellenbeschreibung als Text festlegen und im Test prüfen, wie der Importeur die Spalte liest |
| Tag und Monat vertauscht | Datum in unterschiedlicher Reihenfolge geschrieben | Datumsformat fixieren, einen Tag nach dem zwölften Monatstag testen |
| Doppelter Satz nach der zweiten Sendung | wiederholt, ohne zu prüfen, ob der erste Aufruf angewendet wurde | Nachweis der Nicht-Anwendung verlangen, Zählung auf beiden Seiten und Dublettenprüfung einrichten |
So prüfen Sie das Ergebnis
- Jede Zeile der Matrix hat einen vorher festgelegten Erwartungswert und einen Ist-Wert mit Datum, der ihn bestätigt.
- Beide Seiten zählen dieselbe Zahl von Sätzen; die Differenz ist null oder erklärt.
- Jeder Fehlerfall endet abgewiesen und gemeldet, nicht halb gebucht; die zweite Sendung erzeugt keinen zweiten Satz.
- Der Mengentest ist mit Laufzeit und beobachteter Grenze dokumentiert.
- Offene Punkte nennen eine Person und eine Frist.
Bestanden heißt: jeder Fall erreicht sein vorher festgelegtes Soll-Ergebnis. Ein protokollierter Fehler ist kein bestandener Test.
Wenn etwas nicht klappt
| Symptom | Mögliche Ursache | Umgang |
|---|---|---|
| Der Testauftrag aus dem Shop fehlt im ERP | Zugangsdaten, Freigabe oder Filter der Anbindung stimmen nicht | Empfangsprotokoll lesen, Schlüssel und Freigabe prüfen |
| Der Mengentest bricht nach wenigen Sätzen ab | Zeitüberschreitung oder Aufruflimit des Gegenübers | Volumen in Blöcke teilen, Limit schriftlich erfragen |
| Der Fehlerfall legt einen halben Datensatz an | Geprüft wird erst nach dem Schreiben | Reihenfolge von Prüfung und Schreiben mit dem Anbieter klären |
| Nach dem zweiten Senden steht der Auftrag doppelt im System | Wiederholung ohne Dublettenprüfung | Dublettenprüfung im Import einschalten, Test wiederholen |
Wann Sie Hilfe holen sollten
Holen Sie den Anbieter eines Nachbarsystems hinzu, wenn ein Feld in keiner Beschreibung steht oder ein Fehlercode nicht erklärt ist. Die Freigabe der Bank-Zugangsdaten und Unterschriften gehört in die Hände der Person, die das Konto zeichnet. Die Anbindung ist Teil des Abnahmetests; Kriterien und Protokoll stehen im Artikel Abnahmetest im ERP-Projekt. Ob Sie starten können, entscheidet die Go/No-Go-Checkliste; für Fehler nach dem Start gilt Schnittstellenfehler überwachen und wiederholen.