Odoo 19 vs. Konnektoren mit middleware: Wann sich die Integration direkt in Odoo lohnt

Ein nativer Konnektor in Odoo 19 lohnt sich, wenn Odoo die Hoheit über Bestand, Aufträge, Versand und Rechnungen hat: Jeder Status existiert nur einmal, und zwar in dem Datensatz, in dem das Team arbeitet. Eine middleware lohnt sich, wenn lediglich Daten transportiert werden müssen, ohne operative Entscheidungen zu treffen, oder wenn niemand Code in Odoo pflegen wird. Eine API einmal anzubinden war nie das Problem: Das Problem ist, Aufträge, Bestand, Fehler und Nachverfolgbarkeit im Griff zu behalten, wenn der Betrieb wächst.

Der eigentliche Unterschied liegt nicht in der API

Die API von Amazon, von Mirakl oder eines Zustellers ist dieselbe, egal wer sie aufruft. Was sich ändert, ist, wer das Ergebnis speichert und wo die Person, die den Auftrag vorbereitet, es sieht: Darin liegt der Unterschied, nicht in der API.

Wenn Odoo Bestand reservieren, Aufträge vorbereiten, Lieferscheine erzeugen, Etiketten erstellen und die Sendungsverfolgungsnummer an den Kanal zurückmelden soll, hält die native Integration die Nachverfolgbarkeit dort, wo das Team arbeitet. Mit einer Zwischenschicht existiert jeder Schritt doppelt, und beide Kopien stimmen nur überein, wenn jemand es prüft.

Wann ein nativer Konnektor in Odoo die richtige Wahl ist

Das ist sinnvoll, wenn Odoo das führende System für Produkt, Bestand, Aufträge, Logistik und Rechnungsstellung ist. Ebenso, wenn Sie eigene Regeln brauchen: mehrere Lagerhäuser, Prüfungen vor dem Versand, Wiederholversuche, ein Aufrufprotokoll pro Auftrag und Fehler, die der Benutzer auf seinem eigenen Bildschirm sieht.

In unseren Marktplatz-Konnektoren ist das Protokoll jedes Aufrufs ein Odoo-Modell mit Methode, Endpoint, Parametern, gesendetem Body, Code und Body der Antwort, Versuch und Dauer in Millisekunden, mit konfigurierbarer Bereinigung. Es lässt sich wie jede Odoo-Liste filtern, ohne von einem externen Panel abzuhängen.

Wann eine middleware taugen kann

Wenn Sie nur einfache Daten zwischen zwei Systemen bewegen, ohne komplexe operative Entscheidungen, kann eine middleware den Start beschleunigen. Auch dann, wenn mehrere ERP-Systeme über dieselben Kanäle verkaufen und der veröffentlichte Bestand die Summe sein muss. Und vor allem, wenn niemand, weder intern noch ein Odoo-Partner, Code im ERP pflegen wird.

Das Risiko entsteht, wenn das Team drei Panels prüft, um zu wissen, ob ein Auftrag verkauft, reserviert, versendet oder fehlgeschlagen ist: An diesem Tag hat die middleware aufgehört zu transportieren und angefangen, Status zu speichern.

Was eine middleware im Arbeitsalltag kostet

Entscheidend ist nicht die monatliche Gebühr, sondern sind die Aufgaben, die mit einer Zwischenschicht auftauchen und die niemand einplant. Es sind vier.

1. Der doppelte Master. Das Produkt wird in Odoo angelegt und zusätzlich in der middleware gemappt: SKU, Kanalkategorie, Pflichtattribute. Jede Neuanlage, jede EAN-Änderung und jede neue Variante bedeutet zwei Bearbeitungen. Bei einem nativen Konnektor ist das Mapping zum Kanal ein weiteres Feld am Produkt in Odoo.
2. Der Abgleich der Status. Ein Marktplatzauftrag hat drei Wahrheiten: die des Kanals, die der middleware und die von Odoo. Wenn sie nicht übereinstimmen (ein im Kanal stornierter Auftrag, der in Odoo weiterhin Bestand reserviert), findet es jemand von Hand heraus. Mit dem Konnektor in Odoo bleiben zwei, und der Remote-Status wird genau so, wie die API ihn liefert, beim Verkaufsauftrag gespeichert, mit der Uhrzeit der letzten Synchronisierung.
3. Wer das Log liest. Der Fehler eines Aufrufs liegt im Panel des Anbieters, mit eigenem Benutzer und eigener Aufbewahrung. Wer den festhängenden Auftrag in Odoo sieht, hat auf dieses Panel meist keinen Zugriff. Ist das Log ein Odoo-Modell, sieht es derjenige, der das Problem hat, auf demselben Bildschirm.
4. Das Versionsupdate. Wenn Odoo von 18 auf 19 wechselt, verspricht die middleware, dass sich ihre Seite nicht ändert. Die Seite von Odoo ändert sich sehr wohl: das Brückenmodul des Anbieters, die Felder, die es liest, und die Webhooks, die es erwartet. Diese Migration machen Sie trotzdem, im Takt des Anbieters und nicht in Ihrem; wir veröffentlichen gleichzeitig für 19, 18 und 17, wie in ein Modul in drei Versionen pflegen beschrieben.

Wenn Sie bereits für eine Zwischenschicht zahlen und vermuten, dass Sie sie nicht brauchen, steht der Umstellungsplan pro Kanal in von der middleware zur nativen Anbindung in Odoo, erzählt anhand unserer eigenen Amazon-Migration im Produktivbetrieb.

Wo die Nachverfolgbarkeit verloren geht

Der genaue Punkt ist der Lieferschein. In Odoo erbt der Lieferschein (stock.picking) von mail.thread, und sein Status wird verfolgt, sodass jeder Übergang auf «Erledigt» mit Datum und Benutzer vermerkt wird. Mit dem Liefermodul ist die Sendungsverfolgungsnummer des Zustellers ein Feld des Lieferscheins selbst (carrier_tracking_ref). All das ist serienmäßig vorhanden.

Was Odoo serienmäßig nicht weiß, ist, ob diese Sendungsverfolgungsnummer beim Marktplatz angekommen ist. Mit einer middleware wird die Kette Auftrag → Lieferschein → Sendungsverfolgungsnummer → Bestätigung an den Kanal in zwei Teile zerrissen: die ersten beiden Glieder in Odoo, die letzten beiden im Panel des Anbieters. Der Chatter des Lieferscheins sagt «Erledigt», und der Beweis, dass der Käufer seine Nummer gesehen hat, liegt in einem anderen System.

Ein nativer Konnektor schließt die Kette an derselben Stelle. In unserem Mirakl-Konnektor löst die Validierung des Lieferscheins die Übermittlung der Sendungsverfolgungsnummer aus, wenn die Instanz sie aktiviert hat, und das Ergebnis wird in den Chatter geschrieben: eine Notiz, wenn sie gesendet wurde, eine weitere mit dem Fehler, wenn es fehlschlug, und eine andere, wenn der Lieferschein keine Sendungsverfolgungsnummer hatte und nichts gesendet wurde. Die Aufrufe an Mirakl laufen über das Gateway von FlexigoTech Cloud, das weder speichert noch protokolliert, was sie enthalten, sodass das Ergebnis jeder Übermittlung in Ihrem Odoo bleibt.

Auch nativ ist keine Magie: 32 Fehler trotz grüner Tests

Der unbequeme Teil geht auf unser Konto: «nativ» heißt, dass der Code in Odoo liegt, nicht dass er funktioniert. Wir haben einen eigenen Marktplatz-Konnektor auditiert, bevor wir ihn einem echten Verkäufer vorgesetzt haben. Die Testsuite zeigte 236 von 236 grün, auf echten Odoo.sh-Builds in 19, 18 und 17. Darunter lagen 32 echte Fehler: 20 beim API-Vertrag und 12 bei der Odoo-Version.

Die Vertragsfehler waren Parameter, die die API verlangte und die nicht gesendet wurden, sowie Antwortfelder, die unter dem falschen Namen gelesen wurden und None zurückgeben, ohne etwas auszulösen. Vier zeigten sich erst beim echten Aufruf: Der Paginierungs-Header kam relativ an, und ab Seite eins wurde kein einziger Auftrag mehr importiert; ein 403 wegen Kontingent kam nicht im dokumentierten Format und wurde als fehlende Berechtigung gelesen, wodurch die gesamte Synchronisierung stoppte. Die Versionsfehler lagen bei Odoo selbst: ein Cron, der in 17 einmal läuft und sich von selbst abschaltet, ein Gruppenfeld, das ab 19 anders heißt, eine Listenansicht, die 17 ablehnt. Die Hälfte erzeugte keinen Fehler: Sie erzeugte Stille.

Der vollständige Fall (einschließlich eines zweiten Konnektors mit 163 von 163 grün, der nie eine einzige Logzeile geschrieben hatte) steht in die Tests waren grün und der Konnektor funktionierte nicht. Die Schlussfolgerung für alle, die vergleichen: Verlangen Sie vom nativen Konnektor dasselbe wie von der middleware. Dass er wirklich in Ihrer Version installiert ist, nicht nur kompiliert; dass er gegen die Spezifikation des Anbieters geprüft wurde und nicht gegen die eigenen Mocks; und dass er pro Endpoint-Familie mindestens einen echten Aufruf gemacht hat. Wenn Sie ihn von jemand anderem erben, steht die Liste in einen geerbten Odoo-Konnektor auditieren.

Checkliste für die Entscheidung

• Wo wird der Bestand reserviert, und wie viele Systeme führen eine Kopie des verfügbaren Bestands?
• Wer erstellt den Lieferschein und das Etikett?
• Wo sieht man den Fehler, wenn eine API ausfällt, und sieht ihn dieselbe Person, die den Auftrag sieht?
• Kommt die Sendungsverfolgungsnummer automatisch zum Kanal zurück, und wird im Lieferschein vermerkt, dass sie zurückgekommen ist?
• Können Sie Wiederholversuche machen, ohne Aufträge oder Sendungen zu duplizieren?
• Wer migriert den Konnektor, wenn die nächste Odoo-Version erscheint, und in welcher Frist?
• Wurde er wirklich in Ihrer Version installiert und gegen die Sandbox des Anbieters getestet?

Die Reihenfolge, in der mehrere Kanäle angebunden werden, hängt davon ab, welcher den Bestand veröffentlicht: Das behandeln wir in auf mehreren Marktplätzen aus einem einzigen Odoo verkaufen. Die Konnektoren, die bereits mit Amazon, Mirakl, ManoMano, AliExpress und den Zustellern sprechen, finden Sie im Katalog und unter Odoo-Integrationen und -Automatisierung; wenn es um Ihre eigene Software geht, siehe Odoo-Konnektor für Ihre Software.

Häufig gestellte Fragen

Nützliche Links bei FlexigoTech

Was wir dazu tun