API-Integration für Marktplätze, Versand und Buchhaltung

Datenquelle, Übertragungsrichtung und Verantwortung für die Annahme

Das Ziel einer API-Integration besteht nicht nur darin, zwei Anwendungen zu verbinden, sondern festzulegen, welche Information in welchem System als maßgeblich gilt. Der Produktname kann im Katalog, der verfügbare Bestand im ERP-System und der Lieferstatus beim Versanddienstleister verwaltet werden. Diese Quellen aktualisieren dieselben Daten zu unterschiedlichen Zeitpunkten. Wird eine bidirektionale Verbindung eingerichtet, ohne für jedes Feld die maßgebliche Quelle, die Übertragungsrichtung und die akzeptierte Verzögerung zu dokumentieren, können sich Widersprüche verstärken.

Zu Beginn erstellen wir eine Übersicht der Datenflüsse. Eingang, Bestätigung, Versand und Fakturierung einer Bestellung sind voneinander getrennte Ereignisse. Welche Stellen dieser Kette verändern sich bei einer Stornierung oder einer teilweisen Rückgabe? Wie wird eine Korrektur im Quellsystem im Zielsystem verarbeitet? Automatisierung beseitigt nicht die Fälle, in denen eine menschliche Entscheidung erforderlich ist; sie kann diese in eine sichtbare Prüfwarteschlange überführen.

Das operative Team muss fehlgeschlagene Übertragungen erkennen können. Eine erfolgreiche Antwort allein beweist nicht, dass der Datensatz auf der Gegenseite korrekt verarbeitet wurde. Transaktionskennung, Belegnummer im Zielsystem und Abstimmungsergebnisse werden gemeinsam bewertet. Beim Aufbau eines Onlineshops oder bei der Ergänzung einer bestehenden Infrastruktur wird die Datenverantwortung mit derselben Sorgfalt gestaltet.

Katalog- und Bestellzuordnung auf Marktplätzen

Bei einer Marktplatzanbindung werden der Händler-API-Zugang des Vertriebskanals, die Kontoberechtigungen und die aktuellen Nutzungsgrenzen geprüft. Der Name Trendyol, Hepsiburada, N11, Amazon oder Pazarama allein bedeutet nicht, dass sämtliche Daten übertragen werden können. Kategorien und Pflichtmerkmale können je nach Kanal variieren. Beim einmaligen Anlegen eines Produktdatensatzes wird nicht vorausgesetzt, dass dieser in jedem Kanal dieselbe Bedeutung hat.

Katalog- und Bestandszuordnung

Für Artikelnummer, Barcode und Variantenkennung wird eine Zuordnungstabelle erstellt. Werden Verpackungs- oder Farbvarianten eines Produkts falsch zugeordnet, erreicht die Bestandsaktualisierung das falsche Angebot. Gelöschte Produkte, geschlossene Angebote und nicht akzeptierte Kategorieangaben werden als separate Zustände sichtbar. Bei kanalbezogenen Preisregeln bestätigt das Unternehmen die Annahmen zu Provisionen, Steuern und Rundung.

Bestellungen und Kanalstatus

Bestellungen können mehrfach mit derselben externen Kennung eingehen. Der Übertragungsdatensatz bewahrt diese Kennung; ein erneuter Abruf darf keine zweite Bestellung erzeugen. Teillieferung, Stornierungsanfrage und Rückgabe werden nicht auf eine einzige Kennzeichnung als abgeschlossen reduziert. Wenn an den Marktplatz übermittelte Rechnungs- oder Sendungsverfolgungsdaten abgelehnt werden, muss das operative Team erkennen können, in welcher Phase der Vorgang stehen geblieben ist.

Bei Standardkatalogen kann die vorhandene Verwaltungsoberfläche eines Integrationsanbieters ausreichen. Eine individuelle Anbindung wird geprüft, wenn das Unternehmen Entscheidungen in seiner eigenen Software trifft oder unterschiedliche Lager- und Händlerregeln anwendet. Ohne Einsicht in die Dokumentation und den Testzugang des Anbieters wird die Unterstützung eines Kanals nicht verbindlich zugesagt. Der Umfang des Ablaufs wird anhand der zulässigen Vorgänge definiert, nicht allein anhand des Systemnamens.

Versandetikett und Lieferstatus getrennt behandeln

Das Anlegen einer Sendung und die Übergabe des Pakets an den Versanddienstleister sind separate Ereignisse. Die Erstellung eines Etiketts bedeutet nicht, dass die Bestellung zugestellt wurde. Paketanzahl, Gewicht, Volumengewicht, Adresse und Versandart fließen in die Sendungsanfrage ein. Damit bei einer erneuten Verarbeitung derselben Bestellung keine zweite Sendung entsteht, werden die externe Datensatzkennung und das Ergebnis der Erstellung gespeichert.

Bei Versanddienstleistern wie Yurtici Kargo, Aras Kargo, MNG Kargo, PTT Kargo und Surat Kargo hängen die Zugangsbedingungen vom jeweiligen Konto und Vertrag ab. Vor Arbeitsbeginn werden die Schnittstellendokumentation und die Berechtigungen geprüft. Es wird nicht vorausgesetzt, dass alle Unternehmen dieselben Lieferstatus oder Retourenvorgänge anbieten. Die Statusmeldungen des Versanddienstleisters werden den Bestellzuständen des Unternehmens zugeordnet; unbekannte Codes werden nicht stillschweigend als zugestellt gewertet.

• Die Sendungsverfolgungsnummern einer Bestellung mit mehreren Paketen werden gemeinsam gespeichert.
• Etikettenstornierung und erneuter Druck werden getrennt behandelt.
• Die Retourensendung wird mit dem ursprünglichen Versand verknüpft.
• Adressfehler werden zur operativen Prüfung weitergeleitet.

Beim Sammeldruck von Etiketten wird festgelegt, ob ein fehlgeschlagener Datensatz die Verarbeitung der übrigen Bestellungen anhalten soll. Am Tagesende können die angelegten Sendungen mit den vom Versanddienstleister angenommenen Sendungen verglichen werden. Bei der Weitergabe einer Sendungsverfolgungsmitteilung an den Kunden werden Zeitpunkt und Quelle des Status berücksichtigt; eine verspätete Mitteilung darf den aktuellen Status nicht zurücksetzen.

Abstimmung von ERP-Belegen und Kontenstammdaten

Bei einer ERP-Anbindung werden zunächst die offizielle Schnittstelle der Buchhaltungssoftware und die Nutzungsberechtigung geprüft. Versionen und Module der Produkte von Logo, Netsis, Nebim, DIA, AkinSoft oder Uyumsoft können unterschiedliche Zugriffsmöglichkeiten bieten. Dass ein Programmname in der Liste steht, bedeutet nicht, dass jeder geplante Ablauf technisch möglich ist. Bei Systemen auf lokalen Servern kann der Bedarf an einem sicheren zwischengeschalteten Dienst geprüft werden.

Die Zuordnung von Kunden- und Lieferantenkonten, Artikelnummern, Steuerfeldern und Belegarten erfolgt gemeinsam mit den Mitarbeitenden aus Buchhaltung und operativem Geschäft. Gibt es für denselben Kunden mehrere Stammdatensätze, wird festgelegt, welcher verwendet wird. Eine bloße Namensähnlichkeit gilt nicht automatisch als Identitätsnachweis. Regeln für Datum, Währung, Einheitenumrechnung und Rundung werden anhand von Beispielbelegen getestet.

Wenn das ERP-System die Erstellung eines Datensatzes annimmt, wird die Belegkennung gespeichert. Erfordert eine spätere Korrektur einen neuen Beleg, eine Revision oder eine Gegenbuchung? Diese Entscheidung wird unter Berücksichtigung der vom Programm unterstützten Verfahren getroffen. Ein direkter Schreibzugriff auf die Datenbank gilt ohne Zustimmung des Herstellers nicht als zulässige Abkürzung. Während die individuellen Betriebsabläufe in einer unternehmensspezifischen Software ausgeführt werden, kann das maßgebliche System für die offiziellen Aufzeichnungen beibehalten werden.

Bei der Umstellung und im täglichen Betrieb ist ein Abstimmungsbericht wichtig. Im Quellsystem bestätigte, aber vom ERP-System nicht angenommene Bestellungen, Betragsabweichungen und nicht zugeordnete Stammdatensätze bleiben sichtbar. Nach der Fehlerbehebung kann das operative Team eine sichere erneute Verarbeitung ausführen; es erfolgt keine blinde Wiederholung, bei der derselbe Beleg erneut entstehen könnte.

Von der Übermittlung der türkischen e-Fatura bis zur Belegannahme

Die Anbindung der türkischen e-Fatura basiert auf der API und dem Belegablauf, die der beauftragte private Integrationsanbieter unterstützt. Die Abfrage des Steuerpflichtigenstatus, die Belegart, die Steuerfelder und die Empfängerinformationen werden vor der Übermittlung überprüft. Entscheidungen, die eine Freigabe durch die Buchhaltung erfordern, werden von der Software nicht eigenständig getroffen. Aktuelle gesetzliche Pflichten und Belegszenarien sollten mit der Steuerberatung bestätigt werden; die technische Integration ersetzt keine rechtliche Bewertung.

Rechnungsentwurf, Übermittlung an den Integrationsanbieter, Annahme und Weiterleitung an den Empfänger sind separate Zustände. Wird derselbe Beleg erneut gesendet, während die Antwort noch aussteht, kann ein doppelter Vorgang entstehen. Belegkennung und Anbieterergebnis werden miteinander verknüpft; bei unklarem Status erfolgt eine Abfrage. Die Benutzeroberfläche sollte nicht nur Erfolg oder Fehler melden, sondern auch anzeigen, in welcher Phase der Vorgang wartet.

Stornierung, Widerspruch und teilweise Rückgabe werden nach den Regeln der verwendeten Belegart geplant. Der kaufmännische Status einer Bestellung und der rechtliche Status einer Rechnung werden nicht miteinander vermischt. Belegzugriff, Archivierung und die Berechtigung zur Einsicht in die Datei werden im Rahmen der Verantwortlichkeiten des Unternehmens festgelegt. Im Abnahmeszenario werden Betrag, Steuer, Währung und Belegbeziehungen anhand von Beispieldatensätzen verglichen.

Zahlungsergebnisse zuverlässig verifizieren

Bei einer Zahlungsanbindung ist die Rückkehr des Browsers oder der mobilen App zur Erfolgsseite allein kein Zahlungsnachweis. Das Ergebnis wird mit der verifizierten Antwort des Anbieters und der Transaktionsabfrage verknüpft. Transaktionskennung, Betrag, Währung und Bestellbezug werden geprüft. Die Überprüfung signierter Benachrichtigungen und die Sicherstellung, dass wiederholte Benachrichtigungen dasselbe Ergebnis erzeugen, bilden die Grundlage der technischen Konzeption.

Bei einem virtuellen POS einer Bank oder Anbietern wie iyzico und PayTR sind Händlerkonto, Vertrag und Nutzungsberechtigung Voraussetzungen. Die Verfügbarkeit internationaler Optionen wie Stripe und PayPal für das Land und die Kontostruktur des Unternehmens wird gesondert untersucht; es wird nicht behauptet, dass sie jedem Unternehmen in der Türkei offenstehen. Ratenzahlung, Abonnements und Erstattungen werden entsprechend den tatsächlichen Bedingungen des Anbieters in den Leistungsumfang aufgenommen.

Statt Kartendaten zu speichern, werden die vom Anbieter unterstützten gehosteten oder tokenbasierten Zahlungsverfahren geprüft. Der Zusammenhang zwischen dem Ergebnis von 3D Secure und dem endgültigen Abschluss der Bestellung wird erläutert. Bei einer Zeitüberschreitung muss der Status des ersten Versuchs untersucht werden, bevor der Nutzer erneut zur Zahlung aufgefordert wird. Teilweise Erstattungen, mehrere Erstattungen und fehlgeschlagene Erstattungen können in der operativen Verwaltungsoberfläche getrennt dargestellt werden.

Die Abnahme erfolgt nicht ausschließlich anhand erfolgreicher Zahlungen. Abgelehnte Karten, abgebrochene Authentifizierungen, verspätete Benachrichtigungen und falsche Beträge werden in der Testumgebung geprüft. Dabei wird berücksichtigt, dass die Testumgebung des Anbieters das Livesystem möglicherweise nicht vollständig abbildet; eine begrenzte Prüfung im Livebetrieb wird mit einem berechtigten Konto und einem freigegebenen Umfang geplant.

Fehlerbehandlung bei API-, Webhook- und XML-Datenflüssen

REST API, Webhook und Dateiaustausch unterscheiden sich in ihrem Zustellverhalten. Eine API-Antwort liefert Informationen über den Vorgang; ein Webhook kann verzögert oder erneut gesendet werden; eine XML-Datei bildet nur den Stand zum Zeitpunkt ihrer Erstellung ab. Die Wahl des Verfahrens richtet sich nach der Änderungshäufigkeit der Daten und den Möglichkeiten der Gegenseite. Anstelle des Begriffs Echtzeit werden ein messbares Übertragungsintervall und eine akzeptierte Verzögerung definiert.

Wiederholungsversuche werden nicht bei jedem Fehler gleich behandelt. Ein vorübergehendes Verbindungsproblem unterscheidet sich von einer ungültigen Artikelnummer. Wird ein ungültiger Datensatz ohne Korrektur erneut gesendet, erhöht dies lediglich die Last. In der Warteschlange werden Transaktionskennung, Ergebnis des Versuchs und letzter Fehler sichtbar. Die Übertragungsgeschwindigkeit wird angepasst, ohne API-Limits zu überschreiten; ein Ausfall der Gegenseite wird nicht als verlorener Datensatz verschleiert.

Bei der XML-Übertragung werden die Vollständigkeit der Datei, die Zeichenkodierung, das Datumsformat und die Produktzuordnung geprüft. Eine leere oder abgeschnittene Datei gilt nicht automatisch als Nachweis dafür, dass sämtliche Bestände auf null gesetzt werden sollen. Regeln für Datenlöschung und Massenänderungen werden gesondert festgelegt. Bei internen Systemen ohne Dokumentation wird eine individuelle API-Entwicklung geprüft; Zugriffsberechtigung und Datenverantwortung bleiben auch hier Voraussetzungen.