Die Lesegeräte laufen. Die Etiketten werden zu 98 % gelesen. Und drei Monate nach dem Start sitzt die Finanzabteilung über Inventurdifferenzen, die niemand erklären kann. Fast jeder RFID-Fehlschlag, der kein Physikproblem ist, ist ein Integrationsproblem: Ereignisse kommen in falscher Reihenfolge, dieselbe Palette wird zweimal gezählt, oder die Middleware schreibt eine Menge ins ERP, die das ERP nie prüfen kann.

Dieser Beitrag behandelt die Schicht zwischen Lesegerät und Geschäftssystem — wie sie gestaltet sein muss, damit die Zahlen in Odoo, SAP oder Yonyou zum Monatsabschluss belastbar sind.

Was die Integration übernehmen sollte und was im ERP bleibt

Teilen Sie die Zuständigkeiten ausdrücklich und schreiben Sie die Aufteilung in den Werkvertrag. Unklarheit an dieser Stelle erzeugt zwei Systeme, die jeweils glauben, das andere sei maßgeblich.

Die Randschicht verantwortet Lesegerätanbindung, Antennenkonfiguration, Lesefilterung, Duplikatunterdrückung, Auflösung von Etikett zu SKU, Zeitstempel und Ereignis-ID.
Die Middleware verantwortet Reihenfolge, Wiederholung, Dead-Letter-Behandlung, Kontextanreicherung (Tor, Bediener, Auftrag) und die Abbildung auf ein Geschäftsdokument.
Das ERP verantwortet Bewertung, Zuteilung, Verfügbarkeitsberechnung, Buchung und Prüfpfad.

Die Regel, die die meisten Projekte rettet: Die Middleware schreibt niemals direkt in stock.quant. Sie reicht ein Dokument ein — Zugang, Umbuchung, Zählkorrektur — und überlässt der Geschäftslogik des ERP, was aus dem Bestand wird. Direkte Schreibzugriffe umgehen den Prüfpfad, umgehen die Bewertungsschicht und brechen am Tag des Upgrades.

Welches Muster passt zu Ihrem Volumen: Datei, API oder Event-Stream?

Entscheiden Sie nach gemessenen Zahlen, nicht nach Anbieterpräferenz. Die drei Muster koexistieren problemlos.

Unter 5.000 Ereignissen pro Schicht: stündlicher oder nächtlicher Dateiaustausch genügt und ist mit Abstand am leichtesten abzustimmen. Eine Datei pro Standort, deterministische Namen, Prüfsumme im Manifest.
5.000 bis 50.000 Ereignisse pro Stunde: synchrone REST-Aufrufe in Bündeln von 100 bis 500, jeweils mit Idempotenzschlüssel.
Darüber, oder wenn Latenz über den Geschäftserfolg entscheidet (ein Tor muss in Sekunden bestätigen): ein Event-Stream — MQTT vom Lesegerät zum Rand, Kafka oder RabbitMQ vom Rand zum ERP.

Latenz ist wichtiger als Durchsatz. Eine Wareneingangsbestätigung, die zwanzig Minuten zu spät kommt, ist ein Geschäftsproblem und kein IT-Problem. Messen Sie das p95 am Tor, nicht den Mittelwert im Testlabor.

Odoo: Ereignisse einspielen, ohne stock.quant zu beschädigen

Odoo erlaubt fast jeden Schreibzugriff. Genau deshalb braucht die Integration Disziplin.

Je Prozess ein eigener Vorgangstyp: RFID-Wareneingang, RFID-interne Umbuchung, RFID-Zählung. Berichte und Berechtigungen folgen dem Vorgangstyp.
Für Zählungen den Assistenten zur Bestandskorrektur nutzen: inventory_quantity auf der Quant-Zeile schreiben, dann action_apply_inventory aufrufen. Nie das Feld quantity direkt schreiben; nur der Assistent erzeugt eine prüfbare Bewegung.
Jedem Ereignis eine stabile externe ID in einem benutzerdefinierten Feld mit eindeutigem Index geben, damit eine Wiederholung keine zweite Bewegungszeile erzeugt.
200 bis 500 Bewegungszeilen pro Transaktion bündeln. Größere Bündel halten Zeilensperren auf Produkten und blockieren andere Benutzer ohne Nutzen.
RFID-Felder (rfid_epc, rfid_event_id, rfid_reader) in ein separates Modell oder als nicht gespeicherte berechnete Felder legen. stock.quant wird ständig gelesen; jede Aufblähung kostet überall Performance.

SAP: IDoc, OData und die Middleware-Frage

SAP will Materialbelege, nicht Etikettenlesungen. Es gibt drei realistische Wege, jeder mit gutem Anwendungsfall.

IDoc (WMMBID02, MBGMCR, DESADV): ausgereift, batchorientiert und die am wenigsten disruptive Wahl, wenn PI/PO bereits läuft.
OData und REST-APIs auf S/4HANA: besser für nahezu echtes Echtzeitbuchen und deutlich einfacher zu versionieren als eigene IDoc-Erweiterungen.
Eine dedizierte MII- oder EWM-Schicht: nur oberhalb einiger Millionen Tag-Ereignisse pro Tag sinnvoll, oder wenn EWM ohnehin das führende System des Lagers ist.

Der wiederkehrende Fehler ist die Wahl der Bewegungsart nach Bequemlichkeit statt nach buchhalterischer Bedeutung. 261 und 262 für Verbrauch, 101 und 102 für Zugang, 311 und 312 für Umbuchung — jede hat Folgen in der Kalkulation und im Periodenabschluss. Lassen Sie das Controlling die Zuordnungstabelle unterzeichnen, bevor die erste Zeile Integrationscode entsteht.

Yonyou, Kingdee und chinesische ERPs: zuerst OpenAPI

Chinesische ERPs — Yonyou U8+, Yonyou BIP und NC Cloud, Kingdee K/3 und Cloud — stellen REST-OpenAPI und einen Nachrichtenbus bereit. Nutzen Sie beides, und nutzen Sie es asynchron.

Ziehen Sie täglich einen Bestandsauszug und gleichen Sie ihn mit Ihrer eigenen Zählung ab; senden Sie Transaktionen als abgeschlossene Geschäftsdokumente.
Direkte Datenbankschreibzugriffe in U8 sind im lokalen Markt üblich und die teuerste verfügbare Abkürzung. Sie umgehen den Prüfpfad, brechen bei Patch-Upgrades und machen den Monatsabschluss zu einer politischen Verhandlung.
Prüfen Sie Ratelimits und die Feldzuordnung für Lager, Charge und Seriennummer, bevor Sie Echtzeitverhalten versprechen. Viele chinesische Installationen sind faktisch nahezu echtzeitfähig; das Gegenteil zu versprechen kostet in Woche zwei die Glaubwürdigkeit.

Was im Produktivbetrieb bricht und wie man dafür konstruiert

Sechs Fehlermuster erklären die meisten Störungen, und jedes hat eine Designantwort.

Uhrendrift zwischen Lesegeräten: sowohl occurred_at (Gerät) als auch received_at (Server) protokollieren und nie nur nach occurred_at sortieren.
Doppelte EPCs: zwei Etiketten mit derselben Kennung erzeugen widersprüchliche Bewegungen. Am Rand erkennen und zurückweisen, bevor das ERP sie sieht.
Offline-Rückstand: ein Lesegerät, das nach zwei Stunden wieder verbindet, darf nicht 40.000 veraltete Lesungen als aktuelle Ereignisse wiederholen. Begrenzen Sie das Rückstandsfenster und markieren Sie verspätete Ereignisse ausdrücklich.
Lieferung außer Reihenfolge: Ein Artikel kann einen Standort nicht verlassen, bevor er angekommen ist. Zurückweisen oder quarantänisieren, niemals stillschweigend akzeptieren.
Zeitzone: in UTC speichern, lokal anzeigen und vor dem Start eine Sommerzeitgrenze testen.
Stiller Teilausfall: Bei einem Bündel von 500 mit 3 Fehlern muss die Meldung 497 erfolgreich und 3 offen lauten, nicht ein allgemeiner Fehler.

Checkliste vor der Unterzeichnung des Integrations-SOW

Wer erzeugt die Ereignis-ID, und ist sie über Standorte und Jahre hinweg eindeutig?
Welches System hat die Befugnis, aus einer Lesung eine Bewegung zu machen?
Ist jeder Schreibvorgang idempotent und mit einer absichtlich doppelten Nachricht getestet?
Wie hoch ist die p95-Latenz, gemessen am Tor?
Wie werden Ausnahmen sichtbar, und wer schließt sie innerhalb welcher SLA?
Können Sie einen vollen Tag Ereignisse wiederholen, ohne den Bestand zu verdoppeln?
Hat das Finanz- oder Controlling-Team die Zuordnung von Bewegungs- und Vorgangsarten freigegeben?

Ist eine Antwort ein Personenname statt eines Dokuments, ist die Integration noch nicht spezifiziert — und die Kosten dieser Unklarheit werden in Inventurdifferenzen bezahlt.