Español
English
Català
Français
Português
Italiano
Nederlands
Polski
Es lohnt sich, die Middleware zu entfernen, wenn diese Schicht einen Zustand hält, den Odoo besitzen sollte: den veröffentlichten Bestand, den tatsächlichen Status jeder Bestellung, das Tracking, das an den Kanal zurückgeht. Es lohnt sich nicht, wenn sie nur transportiert: Sie empfängt eine Datei und legt sie woanders ab, ohne etwas zu entscheiden. Das ist die ganze Regel. Im Folgenden: wann die ehrliche Antwort «nicht wechseln» lautet und wie der Wechsel ohne Unterbrechung der Auftragsabwicklung gelingt, erzählt anhand unserer eigenen Migration auf Konnektoren, die innerhalb von Odoo laufen, im Produktivbetrieb.
Kerngedanke: Die Middleware kostet Sie nicht die Gebühr. Sie kostet Sie, dass die Wahrheit Ihres Betriebs an zwei Orten liegt. Jeder Status, der in der Zwischenschicht und auch in Odoo existiert, ist ein Abgleich, den jemand von Hand macht oder den niemand macht.
Was die Middleware im Arbeitsalltag kostet, nicht in Geld
Das Argument, eine Schicht zu entfernen, haben wir bei der elektronischen Rechnung bereits in SERES aus Odoo gemacht, und der grundsätzliche Vergleich steht in Odoo 19 im Vergleich zu Konnektoren mit Middleware. Bei Marktplätzen und Zustellern gilt dasselbe, multipliziert mit den Bestellungen des Tages: vier Aufgaben, die niemand einplant.
| Aufgabe | Mit Middleware | Mit nativer Anbindung |
|---|---|---|
| Produktstamm | Zwei: Odoo und das Mapping der Middleware | Einer. Das Mapping zum Kanal ist ein Feld am Produkt |
| Bestellstatus | Drei Wahrheiten: Marktplatz, Middleware und Odoo | Zwei: der Kanal und Odoo, mit dem Remote-Status direkt bei der Bestellung |
| Nachverfolgbarkeit einer Sendung | Bestellung in Odoo, Tracking in der Middleware, Bestätigung im Marktplatz | Bestellung, Lieferschein, Tracking und Bestätigung im selben Datensatz |
| Wer das Log liest | Das Dashboard des Anbieters, mit eigenem Benutzer und eigener Aufbewahrungsfrist | Ein Odoo-Modell mit Anfrage und Antwort, filterbar und mit Bereinigung |
Die Zeile zum Log verdient eine Warnung: «Wir haben es in Odoo» heißt nicht, dass es geschrieben wird. Beim Audit unseres Mirakl-Konnektors fragte die Funktion, die jeden Aufruf protokollierte, if not log_model ab, und der Helfer lieferte ein leeres Recordset zurück, wenn alles gut lief; in Odoo ist ein leeres Recordset falsch, also war das Protokollieren vom ersten Tag an wirkungslos. Der Beweis lag in der Produktion: Die Sequenz dieser Tabelle stand nach Monaten von Cron-Läufen noch auf NULL. Heute lautet die Prüfung if log_model is False.
Wann Sie nicht wechseln sollten: die drei klaren Fälle
- Mehrere ERP-Systeme. Wenn Odoo eine Gesellschaft führt und ein anderes System eine weitere und beide über dieselben Kanäle verkaufen, ist die Middleware der einzige Ort, an dem der veröffentlichte Bestand die Summe beider ist.
- Orchestrierung zwischen Dritten. Wenn der Ablauf Marktplatz → externer Logistikdienstleister → Zusteller lautet und Odoo erst am Ende davon erfährt, steuert die Schicht Systeme, die nicht Ihnen gehören.
- Niemand, der Odoo pflegt. Ein nativer Konnektor ist Code in Ihrem ERP. Wenn niemand, weder intern noch ein Odoo-Partner, diese Arbeit übernimmt, ist die Middleware mit ihrer Gebühr die günstige Option.
Der Migrationsplan ohne Betriebsunterbrechung
Vier Schritte und ein Prinzip: Die native Anbindung startet lesend und schreibt erst nach außen, wenn sie tagelang dasselbe liest wie die Middleware. Wir haben das im Juni 2026 angewendet, als wir in unserer eigenen Produktion auf Odoo.sh ein altes Amazon-Modul durch den Konnektor ersetzten, der SP-API aus Odoo aufruft.
1. Inventar der Abläufe, mit Richtung
Eine Zeile pro Ablauf: eingehende Bestellungen, ausgehende Bestände und Preise, ausgehendes Tracking, eingehende Stornierungen und Retouren, hochgeladene Rechnungen. Für jede Zeile Richtung, Häufigkeit und Auslöser (Cron, Webhook oder Person). Ein Mirakl-Marktplatz ergibt acht bis zwölf Zeilen; ein Zusteller drei oder vier; eine Signaturplattform zwei.
2. Reihenfolge: Lesen vor Schreiben
Der native Konnektor wird mit abgeschalteten Schreibzugriffen auf den Dritten installiert: bei uns ein globaler Schalter plus eine Markierung pro Konto für jede ausgehende Aktion. Er liest nur Bestellungen, Status und Bestand; die Middleware schreibt weiter, und niemand hört auf zu liefern. Hier trat der erste Fehler der Umstellung auf: Der neue Importer prüfte, ob eine Bestellung existiert, indem er in seine eigene, frisch angelegte und leere Tabelle schaute und nicht in die Verkaufsaufträge, die das Altsystem bereits erstellt hatte. Ergebnis: siebzehn doppelte, bestätigte Verkaufsaufträge, die jeweils erneut Bestand reservierten. Die Lösung war, die Marktplatz-Referenz in sale.order zu suchen, bevor irgendetwas angelegt wird. Die Regel: Dedupliziert wird gegen das Ziel, nie gegen die Zwischentabelle des Konnektors selbst.
3. Parallelbetrieb mit täglichem Vergleich
Ein bis zwei Wochen, in denen beide Systeme denselben Kanal lesen und jeden Morgen eine kurze Liste entsteht: Bestellungen, die das eine importiert hat und das andere nicht, abweichende Status, nicht zugeordnete SKUs. Zwei Tage in Folge null Abweichungen, und dann der erste Schreibzugriff.
4. Umstellung pro Kanal, Schreibzugriffe nur nach vorn
Es wird ein Kanal umgestellt, nicht alle. Und beim Einschalten der Schreibzugriffe nur die, die ein Übergang auslöst: Die Versandbestätigung beim Validieren eines Lieferscheins ist sicher, weil sie einmal pro Bestellung erfolgt, die wirklich rausgeht. Unsicher ist ein Cron, der bestehende Datensätze durchläuft und erneut sendet. Bei unserer Umstellung gab es 534 historische Lieferscheine, die vom alten Modul erledigt und als «pendiente de sincronizar» markiert worden waren; der Wiederholungs-Cron fand sie und schickte in vier Minuten 28 Versandbestätigungen an Amazon, bevor wir ihn abschalteten. Die Lehre: Bevor Sie einen Cron zum Durchlaufen einschalten, bringen Sie den verbliebenen Altbestand in den Zustand, nach dem dieser Cron sucht.
Die historischen Daten: was migriert wird und was nur lesbar bleibt
Migriert wird, was sich noch ändern kann: offene Bestellungen, das Mapping SKU ↔ Kanalreferenz, Sendungen, deren Tracking noch nicht an den Marktplatz zurückgegangen ist, und laufende Retouren. Nicht migriert werden die Aufrufhistorie und abgeschlossene Bestellungen: Sie lassen sich für die Dauer der Reklamationsfrist einen Lesezugriff auf dessen Dashboard geben. Bei unserer Umstellung blieben die Geschäftsdaten unberührt: 1.838 Verkaufsaufträge und 13.236 Produkte blieben, wo sie waren.
Wie Sie vor der Umstellung prüfen, dass die native Anbindung funktioniert
Mit einem echten Odoo-Build und der Sandbox des Dritten, nicht mit Mocks. Mit Zahlen haben wir das in die Tests waren grün und der Konnektor funktionierte nicht erzählt: Ein Konnektor mit 236 von 236 grünen Tests in Odoo 19, 18 und 17 hatte darunter 32 echte Fehler, und ein anderer mit 163 von 163 hatte nie eine Logzeile geschrieben. Die drei Prüfungen, auf die es ankommt:
- Das Synchronisationsfenster fragt nach dem, was sich geändert hat, nicht nach dem, was erstellt wurde. Den Fehler haben wir zweimal gemacht: Der Mirakl-Konnektor sendete
start_date(Erstellung) stattstart_update_date, und der AliExpress-Konnektor filterte nach dem Erstellungsdatum seit dem letzten Lauf. In beiden Fällen kam eine morgens erstellte und nachmittags versendete Bestellung nicht mehr ins Fenster, und ihr Status in Odoo blieb eingefroren. - Das Log hat Zeilen. Zählen Sie nach dem ersten Import die Datensätze des Log-Modells. Null bedeutet, dass nicht geschrieben wird, nicht dass es keine Fehler gibt.
- Die Spur liegt im Datensatz. Von einer importierten Bestellung aus müssen Sie zum Verkaufsauftrag, zum Lieferschein und zum Tracking gelangen, ohne Odoo zu verlassen.
Was danach bleibt: wer den Konnektor in der nächsten Odoo-Version pflegt
Das ist der Teil, den Ihnen die Middleware abgenommen hat und der jetzt Ihnen gehört. Jede Odoo-Version ändert etwas, das ein Konnektor berührt: In 19 ist read_group im ORM selbst als veraltet markiert; in 18 wechselten die Listenansichten von <tree> zu <list>; in 17 läuft ein ir.cron ohne numbercall einmal und schaltet sich von selbst ab. Keines der drei Dinge löst bei der Installation einen Fehler aus. Unsere Konnektoren erscheinen gleichzeitig für 19, 18 und 17 und werden auf echten Builds jeder Serie getestet. Entscheiden Sie vor dem Wechsel, wer diese Arbeit übernimmt: Ihr Team, ein Odoo-Partner oder der Autor des Konnektors, wenn er ihn für mehrere Versionen veröffentlicht und migriert, sobald die neue erscheint.
Wenn der Konnektor für Ihre eigene Software gedacht ist, erklären wir in Odoo-Konnektor für Ihre Software, wie wir das mit Technologiepartnern machen; in unserem Katalog finden Sie die Konnektoren, die bereits mit Amazon, Mirakl, ManoMano, AliExpress und den Zustellern sprechen. Bei mehreren Kanälen hängt die Reihenfolge der Umstellung davon ab, welcher Kanal den Bestand veröffentlicht: Das behandeln wir in auf mehreren Marktplätzen aus einem einzigen Odoo verkaufen und Echtzeitbestand für Marktplätze.
Entscheidungs-Checkliste
- Hält die Middleware Bestand, Bestellstatus oder Tracking, die Odoo nicht hat? Wenn sie nur Dateien transportiert, wechseln Sie nicht.
- Ein einziges ERP oder mehrere, die über dieselben Kanäle verkaufen? Erfährt Odoo am Anfang oder am Ende des Ablaufs von der Bestellung?
- Wer bringt den Konnektor auf die nächste Odoo-Version, und wann?
- Wissen Sie, wie viele historische Datensätze in dem Zustand liegen, nach dem ein Wiederholungs-Cron sucht?
Wenn Sie möchten, dass jemand Ihren Fall mit diesen Kriterien prüft, finden Sie unter Services und Lösungen, wie wir arbeiten.
Häufig gestellte Fragen
Wie lange müssen beide Systeme parallel laufen?
Bis der tägliche Vergleich an zwei Tagen in Folge null Abweichungen ergibt, und nie kürzer als eine Woche.
Kann ich einen Kanal umstellen und die anderen in der Middleware lassen?
Ja, und das ist empfehlenswert. Sie müssen nur festlegen, wer ab der Umstellung den Bestand an diesen Kanal veröffentlicht, und es darf nur einer sein.
Gilt für EDI und elektronische Signatur dasselbe wie für Marktplätze?
Die Regel gilt: Wenn die Schicht den Dokumentstatus hält (akzeptiert, abgelehnt, signiert), lohnt sich der Wechsel. Es gibt zwei oder drei Abläufe statt zehn, und der Parallelbetrieb erfolgt, indem dasselbe Dokument auf beiden Wegen an die Testumgebung des Dritten gesendet wird.
Nützliche Links bei FlexigoTech
Was wir dazu tun
Zahlen Sie für eine Middleware und wissen nicht, ob Sie sie noch brauchen?
Sagen Sie uns, welche Kanäle Sie haben, welche Odoo-Version und wer sie pflegt. Wir sagen Ihnen, ob sich der Wechsel lohnt, in welcher Reihenfolge und was in der Middleware bleiben sollte. Schreiben Sie an comercial@flexigobe.com oder rufen Sie an unter +34 616 809 504.