Eine Schnittstelle kann technisch funktionieren und trotzdem im Alltag Probleme machen. Das passiert zum Beispiel, wenn niemand festgelegt hat, welches System bei widersprüchlichen Daten führt oder wie ein abgebrochener Lauf wiederholt werden darf.
Vor der Entwicklung sollten deshalb nicht nur Endpunkte und Dateiformate feststehen. Ebenso wichtig sind fachliche Regeln, Fehlerfälle und die spätere Betreuung. Die folgende Checkliste hilft, diese Punkte für eine Sage 100 Schnittstelle zu ordnen.
1. Den fachlichen Ablauf beschreiben
Beginnen Sie mit einem echten Geschäftsvorgang. Ein Beispiel: Ein Auftrag geht im Shop ein, wird in Sage 100 angelegt, ans WMS übergeben und nach dem Packen als Lieferschein oder Rechnung fortgeführt. So wird sichtbar, welche Schritte automatisch laufen und an welchen Stellen ein Mitarbeiter entscheiden muss.
Für jeden Ablauf sollten diese Fragen beantwortet sein:
- Was löst die Übertragung aus?
- Woher kommen die Daten?
- In welchem System werden sie weiterverarbeitet?
- Welche fachliche Rückmeldung wird erwartet?
- Welche Sonderfälle dürfen nicht automatisch weiterlaufen?
2. Führende Systeme und Datenfelder festlegen
Bei Stammdaten und Statuswerten muss klar sein, welches System die maßgebliche Information hält. Sonst überschreibt eine Rückmeldung möglicherweise eine bewusst vorgenommene Änderung.
Eine Feldliste sollte neben Quelle und Ziel auch Pflichtangaben, Formate und Zuordnungen enthalten. Bei Artikeln sind zum Beispiel Artikelnummer, Einheit und Lager relevant. Bei Aufträgen kommen Kunde, Lieferadresse, Zahlungsart, Versandart und Belegpositionen hinzu.
Besonders wichtig sind stabile Schlüssel. Namen oder frei editierbare Texte eignen sich selten als alleinige Zuordnung. Besser sind eindeutige IDs, deren Herkunft und Lebensdauer dokumentiert sind.
3. Übertragungsweg und Takt bestimmen
Nicht jedes System benötigt eine REST-API. Kleine oder zeitlich gebündelte Datenmengen lassen sich manchmal verlässlicher über Dateien austauschen. In anderen Projekten sind API-Aufrufe oder Datenbanktabellen der passende Weg.
Die Technik folgt dem Prozess:
- Wie schnell müssen Änderungen im Zielsystem ankommen?
- Werden einzelne Vorgänge oder Sammelläufe übertragen?
- Kann das Quellsystem eine Rückmeldung verarbeiten?
- Was passiert, wenn eines der Systeme vorübergehend nicht erreichbar ist?
4. Wiederholungen und Fehlerfälle planen
Ein abgebrochener Lauf darf nicht automatisch zu doppelten Kunden, Buchungen oder Belegen führen. Deshalb braucht jeder Vorgang eine nachvollziehbare Kennung und eine klare Regel für Wiederholungen.
Fehler sollten mindestens den betroffenen Vorgang, den Verarbeitungsschritt und die Ursache erkennen lassen. Eine reine Meldung wie „Übertragung fehlgeschlagen“ reicht für die spätere Bearbeitung nicht aus.
Außerdem muss feststehen, wer einen Fehler prüft. Technische Probleme gehören zum Entwickler oder Betreiber der Schnittstelle. Fachliche Rückfragen, etwa zu einer unbekannten Versandart, brauchen einen Ansprechpartner im Unternehmen.
5. Mit repräsentativen Fällen testen
Ein erfolgreicher Standardauftrag ist nur der Anfang. Für die Abnahme sollten auch die Fälle berücksichtigt werden, die im Tagesgeschäft seltener vorkommen und größere Auswirkungen haben.
- Teilmenge, Storno und Retoure
- fehlende oder ungültige Pflichtangabe
- bereits übertragener Vorgang
- nicht erreichbares Zielsystem
- abweichende Versand-, Zahlungs- oder Kundenregel
- erneuter Start nach einem Fehler
Bei einer WMS-Anbindung gehören Packrückmeldungen und Folgebelege in diese Tests. Für eine PlentyONE-Anbindung sind zusätzlich Status, Bestände, Retouren und Stornos relevant.
6. Betrieb und Übergabe mitplanen
Vor dem Produktivstart sollte geklärt sein, wo Protokolle liegen, wie fehlgeschlagene Vorgänge erneut verarbeitet werden und wer Änderungen an Zugangsdaten oder Endpunkten übernimmt.
Zur technischen Übergabe gehören mindestens eine Beschreibung der Datenflüsse, die Feldzuordnungen, Konfigurationshinweise und die wichtigsten Testfälle. Diese Unterlagen helfen nicht nur einem späteren Entwickler. Sie verkürzen auch die Fehlersuche im eigenen Team.
Kompakte Checkliste für die Anfrage
Für eine erste technische Einordnung reichen meist folgende Angaben:
- eingesetzte Sage-100-Version
- Name und Version des Fremdsystems
- wichtigster Datenfluss in einem Satz
- ungefähre Anzahl der Vorgänge
- verfügbare API-, Datei- oder Datenbankzugänge
- bekannte Sonderfälle und aktueller Handlungsdruck
Senden Sie uns diese Eckdaten für eine erste Einordnung Ihrer Schnittstelle.