Odoo Community gilt oft als ungeeignet für RFID, weil die Enterprise-IoT-Box und die Barcode-App fehlen. Tatsächlich ist die IoT Box eine Bequemlichkeit, keine Fähigkeit: Sie verpackt eine Reihe von Gerätetreibern in einen bezahlten Container. Ein Gateway, das bereits MQTT oder HTTP spricht, braucht sie nicht.

Was Community wirklich verlangt, ist Disziplin. Die Versuchung ist, das Lagermodul direkt zu patchen, und genau diese Versuchung ist der Grund, warum viele Odoo-Projekte nicht mehr aktualisiert werden können. Ein separates Modul mit ein paar hundert Zeilen überlebt drei Migrationen; ein Fork überlebt keine.

Warum die Community-Edition ausreicht

Die Lücken sind schmaler, als sie aussehen, und jede hat einen sauberen Umweg.

Die Kernstärke ist bereits da: stock.quant, stock.move und das Inventuranpassungsmodell sind in der freien Edition enthalten.
Die öffentliche API und das ORM von Odoo geben vollen Modellzugriff, also kann ein eigenes Modul den Bestand genauso schreiben wie die Enterprise-App.
Controller erlauben einen kleinen eingehenden Endpunkt ohne Zusatzinstallation.
Der Cron-Scheduler ist enthalten, und mehr braucht ein Stapelschreiber nicht.
Was man aufgibt, sind fertige Gerätetreiber und deren Supportvertrag; beides ersetzt das eigene Gateway.

Modulgerüst: was wohin gehört

Eine vorhersagbare Struktur ist mehr wert als kluger Code, weil der nächste Entwickler sie zuerst liest.

Das Modulverzeichnis enthält das Manifest, das Abhängigkeiten zu stock und, falls genutzt, zur Job-Queue deklariert.
models enthält drei Dateien: das Leserregister, das Rohleseereignis und die Abbildung von EPC zu Produkt.
views enthält Listen-, Formular- und Suchansichten plus die Menüdefinitionen, sonst nichts.
security enthält die Gruppendefinitionen, die Access-Rights-CSV und die Record Rules.
controllers enthält den eingehenden Endpunkt; data die Cron-Definition; tests die Transaktionstests.

Datenmodelle: Leser, Ereignis, Abbildung

Drei Modelle genügen für eine erste Version, und ein viertes sollte eine Begründung verlangen.

Leser: Kennung, Standort, Zone, Protokoll, Status, letzter Heartbeat und Antennenkonfiguration.
Leseereignis: Leser, Antenne, EPC, Signalstärke, Gerätezeit, Empfangszeit, Sequenz und Status.
Abbildung: EPC-Muster, Produkt, Los, Menge und die zur Auflösung verwendete Regelversion.
Der Status des Ereignisses ist ein kleines Enum — empfangen, aufgelöst, angewendet, verworfen — und das Rückgrat der Prüfspur.
Halten Sie das Rohereignis nach Erreichen eines Endstatus unveränderlich; Korrekturen gehören in ein neues Ereignis, nicht in eine Bearbeitung.

Views und Menüs ohne Kernänderung

Vererbung dient dem Hinzufügen, nicht dem Umschreiben, und diese Unterscheidung entscheidet, ob Upgrades weh tun.

Hängen Sie ein Menü unter Inventar, keine neue Top-Level-App, es sei denn, das Modul dient wirklich mehreren Modulen.
Nutzen Sie geerbte Views, um einen Smart Button im Produktformular hinzuzufügen, der die Etikettenhistorie öffnet.
Geben Sie der Ereignisliste einen Standardfilter für heute und eine Gruppierung nach Zone, denn so schauen Bediener tatsächlich hin.
Zeigen Sie die Regelversion im Ereignisformular; bei einer Abweichung ist das das erste Feld, das jemand prüft.
Überschreiben Sie niemals die Architektur einer Kernansicht komplett; fügen Sie den konkreten Knoten per xpath hinzu.

Sicherheit: ACLs, Record Rules und der API-Benutzer

Sicherheit ist der Teil, der im Prototyp übersprungen und in der Produktion geprüft wird.

Zwei Gruppen sind meist richtig: ein Bediener, der Ereignisse liest und Abbildungen bestätigt, und ein Manager, der Leser und Regeln ändert.
Gewähren Sie keine Schreibrechte auf den Bestandsmodellen über das hinaus, was die Standard-Inventargruppen ohnehin haben.
Nutzen Sie einen dedizierten Integrationsbenutzer mit engem Rechteumfang und geben Sie dem Gateway einen eigenen API-Schlüssel statt eines menschlichen Logins.
Fügen Sie eine Record Rule hinzu, damit ein Benutzer einer Firma nicht Leser und Ereignisse einer anderen sieht.
Protokollieren Sie, wer eine Abbildungsregel geändert hat, denn eine falsche Regel verfälscht stillschweigend Wochen von Bestand.

stock.quant integrieren, ohne stock zu forken

Der Schreibpfad ist der einzige wirklich gefährliche Teil des Moduls.

Rufen Sie den vorhandenen ORM-Helfer auf, der die verfügbare Menge atomar aktualisiert, und weisen Sie das Mengenfeld niemals direkt zu.
Kapseln Sie die Anwendung in eine Transaktion pro Lagerort, damit ein Fehler eine zusammenhängende Einheit zurückrollt statt einen halben Gang.
Vermerken Sie den Anpassungsgrund und die Ursprungs-Ereignis-ID im Referenzfeld, damit die Prüfspur bis zum Funk zurückreicht.
Erzeugen Sie keine Stock Moves für eine Zählkorrektur; nutzen Sie das Inventuranpassungsmodell, das genau dafür existiert.
Halten Sie Deduplizierung und Aggregation außerhalb von Odoo; das Modul soll Deltas empfangen, keinen Strom von Rohlesungen.

Der eingehende Endpunkt: Controller, Cron und Stapel

Der Endpunkt sollte langweilig sein: authentifizieren, validieren, einreihen, zurückgeben.

Akzeptieren Sie einen JSON-Body mit einem Stapel Deltas und einem Idempotenzschlüssel und lehnen Sie alles ab, was die Schemavalidierung verfehlt, mit einem konkreten Fehler.
Schreiben Sie das Delta in die Ereignistabelle und kehren Sie sofort zurück; führen Sie die Odoo-Anwendung niemals im HTTP-Request aus.
Lassen Sie den Cron die Warteschlange jede Minute leeren, oder alle paar Sekunden in der Job-Queue, mit einem einzigen Schreiber.
Machen Sie die Anwendung idempotent auf den Idempotenzschlüssel, damit ein Netzwerk-Retry die Menge nicht verdoppelt.
Begrenzen Sie Stapelgröße und Body-Größe, denn ein unbegrenzter Endpunkt ist eine Einladung.

Tests und Upgrade-Disziplin

Das Modul wird aktualisiert, und die Tests machen daraus Routine statt Projekt.

Schreiben Sie Transaktionstests, die einen Leser anlegen, ein Ereignis einspielen, es anwenden, den Quant prüfen und zurückrollen.
Testen Sie den Duplikatfall explizit: denselben Idempotenzschlüssel zweimal senden und genau eine Anwendung erwarten.
Testen Sie den Ablehnungspfad: Ein unbekannter EPC muss in Quarantäne landen, nicht in einem Traceback.
Halten Sie pro Version ein Migrationsskript für Datenänderungen bereit und testen Sie es gegen eine Produktionskopie.
Fixieren Sie die Abhängigkeiten und vermeiden Sie private API-Aufrufe, denn genau die brechen in der nächsten Hauptversion.