Español
English
Català
Français
Português
Italiano
Nederlands
Polski
Fast alle Unternehmen, die Amazon Seller Central mit Odoo verbinden, erleben dasselbe: Im ersten Monat funktioniert in den Tests alles gut, und nach wenigen Wochen mit realem Volumen treten die immer gleichen Symptome auf. Der Bestand stimmt nicht, Aufträge werden doppelt angelegt, die Sendungsnummer kommt zu spät, die API liefert plötzlich Fehler 429, oder ein Token funktioniert an einem Montagmorgen ohne Vorwarnung nicht mehr.
Kernaussage: Fast keiner dieser Fehler ist ein Problem von Amazon oder von Odoo für sich genommen. Sie treten in der Synchronisationsschicht auf, wenn der Konnektor das asynchrone Modell der SP-API (Benachrichtigungen in Echtzeit, Anfragelimits pro Endpunkt, OAuth-Tokens mit kurzer Laufzeit) nicht beachtet und stattdessen alle X Minuten einfach abfragt und darauf vertraut, dass alles rechtzeitig ankommt.
Warum die Integration von Amazon und Odoo scheitert (und nicht immer offensichtlich)
Die SP-API von Amazon ist keine einfache REST-API mit Anfrage und Antwort. Sie kombiniert synchrone Aufrufe mit einem asynchronen Benachrichtigungssystem (Notifications API, zugestellt über SQS oder EventBridge), einem Berichtsmodell, bei dem Reports im Hintergrund erzeugt werden und abgefragt werden müssen, bis sie bereit sind, und einem Limit für Anfragen pro Sekunde, das für jede Operation anders ist, nicht ein globales für das ganze Konto. Die Authentifizierung läuft über Login With Amazon (LWA): Das Access-Token läuft stündlich ab und muss mit dem refresh_token erneuert werden, bevor es verfällt.
Viele Integrationen (vor allem solche, die mit generischen Automatisierungen wie Zapier, Make oder einem iPaaS ohne spezifische Amazon-Logik aufgebaut sind) vereinfachen all das zu einem Cron-Job, der alle X Minuten Aufträge abfragt und davon ausgeht, dass das genügt. Diese Vereinfachung ist die direkte Ursache der meisten Fehler in der folgenden Tabelle.
Tabelle: Symptom, wahrscheinliche Ursache und wie man es vermeidet
Acht reale Symptome, die wir bei Betrieben sehen, die über Odoo auf Amazon verkaufen, jeweils mit der wahrscheinlichsten technischen Ursache und der Lösung, die ein Konnektor anwendet, der für den echten Betrieb gebaut ist und nicht nur für eine Demo.
| Symptom | Wahrscheinliche Ursache | So vermeiden Sie es |
|---|---|---|
| Bestand stimmt nicht / Überverkauf auf Amazon | Synchronisation per Abfrage alle 30-60 Minuten; die Inventar-Notifications-API wird nicht in Echtzeit genutzt | Abonnement der Inventar-Benachrichtigungen mit sofortiger Übertragung nach jeder Bestandsbewegung in Odoo, dazu ein konfigurierbarer Sicherheitspuffer |
| Doppelte Aufträge in Odoo | Wiederholungsversuche des Konnektors ohne Idempotenz; die AmazonOrderId wird nicht als eindeutiger Schlüssel verwendet | Idempotenter Upsert, indiziert nach AmazonOrderId, mit Eindeutigkeitsbeschränkung auf Datenbankebene |
| Sendungsnummer kommt zu spät bei Amazon an (die Late Shipment Rate steigt) | Die Sendungsnummer wird in einem nächtlichen Cron-Batch übermittelt statt bei der Validierung des Lieferscheins | Automatische Aktion, die die Shipping API in dem Moment aufruft, in dem die Lieferung in Odoo validiert wird |
| Fehler 429 / "Request throttled" | Das spezifische Rate Limit jeder SP-API-Operation wird nicht beachtet (jeder Endpunkt hat seinen eigenen Bucket) | Job-Warteschlange mit exponentiellem Backoff und einem eigenen Rate Limiter pro Endpunkt, nicht einem globalen |
| Abgelaufenes OAuth-Token oder ungültiger refresh_token | Keine automatische Erneuerung des LWA-Access-Tokens, oder die Zustimmung wurde in Seller Central widerrufen, ohne dass es jemand bemerkt | Automatische Erneuerung mit Sicherheitsabstand, dazu ein Alarm, wenn die Erneuerung fehlschlägt (nicht erst, wenn ein echter Auftrag fehlschlägt) |
| Unterschiedliche Preise zwischen Amazon und den übrigen Kanälen | Es gibt keine einheitliche Datenquelle; der Preis wird von Hand in Seller Central geändert | Odoo als maßgebliche Quelle für Preise, mit expliziten Konfliktregeln, wenn eine manuelle Änderung bei Amazon erkannt wird |
| Rückerstattungen und Retouren stimmen in der Buchhaltung nicht | Es werden nur die Aufträge verarbeitet; die Returns/Refunds-Berichte von Amazon werden nicht importiert | Automatischer Import der Returns Reports in Gutschriftsbuchungen, nicht nur in den Bestand |
| Funktioniert im Test, scheitert aber mit mehreren Konten oder Marktplätzen | Zugangsdaten und Synchronisationsstatus sind fest für ein einziges Verkäuferkonto codiert | Zugangsdaten pro Unternehmen/Marktplatz direkt im Datenmodell, nicht als nachträglicher Flicken |
Checkliste: Was ein gut gebauter Amazon-Odoo-Konnektor haben muss
Bevor Sie einen Amazon-Odoo-Konnektor für gut befinden (Ihren eigenen oder einen, den Sie zum Kauf prüfen), gehen Sie diese Liste durch. Das ist keine Theorie: Es sind genau die Stellen, an denen wir reale Integrationen scheitern gesehen haben.
- Nutzt die Notifications API von Amazon (SQS/EventBridge), statt sich nur auf periodische Abfragen zu verlassen
- Importiert Aufträge idempotent mit der AmazonOrderId als eindeutigem Schlüssel
- Sendet die Sendungsnummer an Amazon im Moment der Validierung des Lieferscheins, nicht gebündelt in einem nächtlichen Cron
- Wendet pro Endpunkt einen Rate Limiter und exponentielles Backoff an, nicht ein ungefähres globales Limit
- Erneuert das OAuth-Token (LWA) automatisch, mit frühzeitigem Alarm, falls die Erneuerung fehlschlägt
- Protokolliert jeden API-Aufruf mit Antwortcode und Payload, nicht nur ein generisches "sync OK"
- Unterstützt mehrere Konten und Marktplätze direkt im Datenmodell, nicht als spätere Ergänzung
Was wir bei FlexigoTech tun: unser Amazon-Konnektor für Odoo
Unser Amazon-Konnektor für Odoo ist mit FBA und FBM im realen Produktivbetrieb über die SP-API gebaut, gerade um keinen der acht Punkte der obigen Tabelle zu treffen: idempotenter Import nach AmazonOrderId, Versand der Sendungsnummer bei der Validierung des Lieferscheins und automatische Token-Erneuerung, unter anderem. Es ist keine generische Automatisierungsschicht über der API, sondern ein natives Odoo-Modul, gedacht für den Betrieb mit realem Volumen und nicht nur zum Bestehen einer Demo.
Wenn Sie bereits Odoo einsetzen, der aktuelle Konnektor (eigener oder von Dritten) Ihnen aber eines dieser Symptome beschert, liegt das Problem oft nicht darin, den Konnektor zu wechseln, sondern darin, wie er in Ihrer Instanz eingerichtet ist. Das lässt sich meist im Rahmen eines gut gemachten Projekts zur Einführung von Odoo 19 lösen, mit der Marktplatz-Synchronisation von Anfang an im Projektumfang und nicht als nachträglicher Flicken.
Nützliche Links bei FlexigoTech
Häufige Fragen
Warum läuft der Bestand zwischen Amazon und Odoo auseinander, obwohl ich einen Konnektor installiert habe?
Fast immer, weil der Konnektor in festen Abständen per Abfrage (Polling) synchronisiert, statt auf die Inventar-Benachrichtigungen von Amazon in Echtzeit zu reagieren. Zwischen zwei Durchläufen gibt es ein Zeitfenster, in dem Amazon und Odoo nicht übereinstimmen, und bei Katalogen mit hohem Umschlag genügt das, um etwas zu verkaufen, das Sie nicht mehr haben.
Wie vermeide ich doppelte Aufträge, wenn Amazon dieselbe Benachrichtigung erneut sendet?
Amazon kann dieselbe Auftragsbenachrichtigung mehr als einmal erneut senden; das gehört zu seinem normalen Zustellmodell. Die Lösung ist nicht, Wiederholungen von Hand zu filtern, sondern dass der Konnektor die AmazonOrderId als eindeutigen Schlüssel verwendet und einen idempotenten Upsert ausführt: Existiert der Auftrag bereits, wird er aktualisiert, andernfalls wird er angelegt. Er wird nie doppelt eingefügt.
Was ist ein Fehler 429 der Amazon SP-API und wie behebt man ihn von Odoo aus?
Es ist ein Throttling-Fehler: Sie haben das Limit für Anfragen pro Sekunde dieses konkreten Endpunkts überschritten (jede Operation der SP-API hat ihr eigenes Limit, nicht ein globales). Behoben wird er mit einer Job-Warteschlange, die das Rate Limit jedes Endpunkts beachtet und mit exponentiellem Backoff erneut versucht, statt nach wenigen Sekunden wieder anzufragen.
Was passiert, wenn mein Amazon-OAuth-Token im Produktivbetrieb abläuft?
Amazon nutzt Login With Amazon (LWA): Das Access-Token läuft stündlich ab und muss mit dem refresh_token erneuert werden, bevor es verfällt. Automatisiert der Konnektor diese Erneuerung nicht, oder hat der Verkäufer die Zustimmung in Seller Central widerrufen, ohne jemanden zu informieren, schlagen die Aufrufe mit Autorisierungsfehlern fehl, bis das Konto von Hand neu verbunden wird.
Wirkt sich eine verspätete Sendungsnummer bei Amazon wirklich auf mein Konto aus?
Ja. Amazon misst die Late Shipment Rate, und wenn sie über den Schwellenwert steigt, kann das die Kontogesundheit und die Sichtbarkeit Ihrer Listings beeinträchtigen, zusätzlich zur direkten Wirkung auf das Käufererlebnis. Wird die Sendungsnummer in einem nächtlichen Cron statt bei der Validierung des Lieferscheins in Odoo übermittelt, liegt diese Verzögerung beim Konnektor, nicht bei Amazon.
Was wir dazu tun
Möchten Sie, dass wir Ihre Amazon-Integration prüfen?
Schildern Sie uns, welches Symptom Sie haben (Bestand, doppelte Aufträge, Sendungsnummer oder Tokens), und im ersten Gespräch sagen wir Ihnen, ob es sich um eine punktuelle Anpassung handelt oder der Konnektor grundlegend überarbeitet werden muss. Schreiben Sie uns an comercial@flexigobe.com oder rufen Sie an unter +34 616 809 504.