Handheld-Batch-Import in Odoo: erst den Import entwerfen, dann den Scanner

Lagerteams kaufen Handhelds aus einem einfachen Grund: Der Bestand ist nicht dort, wo das Netz ist. Regale blockieren WLAN, Kühlräume töten die Abdeckung, und ein Lkw-Hof hat gar kein Signal. Also sammelt das Gerät offline und synchronisiert später — und genau dort entscheidet sich Inventargenauigkeit.

Das Gerät ist nicht der schwierige Teil. Der Import ist es.

Warum Batching eine Designentscheidung ist

Offline-Erfassung ist ein bewusster Tausch, und wer ihn ehrlich benennt, hält das Design vernünftig.

• Offline-Erfassung garantiert, dass die Zählung abgeschlossen wird, zum Preis verspäteter Daten.
• Verspätete Daten bedeuten, dass das ERP weitergezogen ist: Wareneingänge, Verkäufe und Umlagerungen lagen zwischen Zählung und Upload.
• Ein Batch ist keine Momentaufnahme, sondern eine Menge von Beobachtungen über Stunden oder Tage.
• Die Importroutine muss daher Zeit mitführen und ihre Absicht erklären: setzen, addieren, subtrahieren oder bestätigen.
• Systeme, die das ignorieren, erzeugen Zählungen, die im Gang stimmen und im Hauptbuch nicht.

Drei Nutzlastformen, drei Verhaltensweisen

Die meisten Importfehler entstehen, weil man diese drei in eine Datei mischt und hofft, der Importer errät es.

• Eine Zählung ist eine absolute Aussage: Dieser Lagerort hält zu diesem Zeitpunkt diese Menge dieses Artikels.
• Ein Ereignis ist eine Bewegung: eine Einheit ging von A nach B, wurde verbraucht oder empfangen.
• Ein Delta ist eine Korrektur: Diese Menge addieren oder abziehen, weil der vorige Datensatz falsch war.
• Zählungen und Deltas können keine Konfliktregel teilen, denn die eine ersetzt die Wahrheit, das andere behauptet eine Änderung.
• Wählen Sie pro Prozess: Stichprobenzählung passt zu Zählungen, Kommissionierbestätigung zu Ereignissen, Korrekturen zu Deltas.

Alles zuerst in die Staging-Tabelle

Die Staging-Tabelle ist die wertvollste Komponente der Pipeline, und sie wird am häufigsten übersprungen.

• Jeden empfangenen Datensatz mit Roh-Nutzlast, Geräte-ID, Bediener und Gerätezeit in Staging schreiben.
• In Staging validieren, nicht am Eingang: Ein abgelehnter Satz muss zur Diagnose sichtbar bleiben.
• Den Importer nie direkt aus einer vom Nutzer gewählten Datei in den Bestand schreiben lassen; die Datei ist Eingabe, keine Autorität.
• Staging-Zeilen nach der Verarbeitung mit Status behalten, damit ein Streitfall bis zum Originalscan zurückverfolgt werden kann.
• Staging als Posteingang behandeln: unverarbeitet, verarbeitet, abgelehnt und manuell geklärt sind vier verschiedene Zustände.

Idempotenz ist die einzige Verteidigung gegen Wiederholung

Ein Handheld, das nach einer fehlgeschlagenen Synchronisation erneut sendet, schickt denselben Batch zweimal, und das ist normal.

• Jeden Batch mit einem deterministischen Bezeichner aus Gerät, Bediener und Zeitfenster versehen.
• Jeden Datensatz mit einem Schlüssel versehen, der beim erneuten Senden gleich bleibt; eine zufällige UUID pro Versuch zerstört die Idempotenz.
• Den angewandten Schlüssel in der Datenbank speichern und Duplikate mit klarem Status ablehnen, nicht mit einem Fehler.
• Den Wiederholungspfad bewusst testen: Sync abbrechen, erneut senden und prüfen, dass der Bestand unverändert ist.
• Ist die Pipeline nicht idempotent, machen Sie den Import zu einem manuellen Prüfschritt statt zu einer automatischen Buchung.

Verteidigbare Konfliktregeln

Ein Konflikt entsteht, wenn sich das ERP seit der Beobachtung verändert hat, und jede Regel muss ausdrücklich sein.

• Die Gerätezeit mit der letzten Bestandsbewegung für Produkt und Lagerort vergleichen.
• Änderte sich das ERP vor der Beobachtung, die Zählung akzeptieren, denn sie wurde später gemessen.
• Änderte sich das ERP nach der Beobachtung, markieren; die Zählung kann bereits Stunden alt sein.
• Nie stillschweigend den größeren oder kleineren Wert wählen; eine Regel der Vorsicht verbirgt echte Verluste.
• Jeden markierten Konflikt in eine kurze Prüfliste mit beiden Werten und den auslösenden Bewegungen geben.

Zeit ist das Feld, das alle vergessen

Geräteuhren driften, Zeitzonen unterscheiden sich, und eine Zählung ohne Zeitstempel lässt sich nicht abstimmen.

• Zwei Zeitstempel speichern: wann das Gerät das Etikett beobachtet hat und wann der Server es empfangen hat.
• Die Gerätezeit zu Beginn jeder Sitzung synchronisieren und Datensätze mit unplausiblen Zeiten ablehnen.
• Die Geräteuhr in UTC halten und nur zur Anzeige umrechnen; Ortszeit erzeugt zweimal im Jahr Fehler.
• In der Konfliktlogik die Beobachtungszeit verwenden, die Empfangszeit nur zur Prüfung.
• Eine eine Woche verspätete Zählung ist noch Daten, darf aber keine Woche Bewegungen überschreiben.

Vor dem Schreiben validieren

Die billigste Korrektur geschieht, bevor die Bestandsbuchung entsteht.

• Prüfen, dass Produkt, Lagerort und Charge existieren, und unbekannte Barcodes ablehnen statt Artikel anzulegen.
• Einheitenumrechnungen ausdrücklich prüfen; eine Karton-statt-Stück-Verwechslung ist ein stiller hundertfacher Fehler.
• Prüfen, ob der Bediener für diesen Lagerort berechtigt ist, besonders in Mehrfirmen-Setups.
• Mengenplausibilität gegen ein konfiguriertes Band prüfen und Ausreißer zur Prüfung leiten statt zu blockieren.
• Das Validierungsergebnis pro Datensatz festhalten, damit der Ablehnungsgrund beim Bediener ankommt.

Dem Handheld sagen, was passiert ist

Ein Import, der nur eine Summe meldet, ist ein Import, den das Feldteam aufgibt.

• Bei der nächsten Synchronisation den Status pro Datensatz über den Datensatzschlüssel zurückgeben.
• Akzeptiert, akzeptiert mit Korrektur und abgelehnt unterscheiden, jeweils mit einer Zeile Begründung.
• Den Bediener abgelehnte Sätze am Gerät korrigieren lassen, statt sie im Büro neu zu tippen.
• Eine Sitzungszusammenfassung zeigen, die der Vorgesetzte ohne Tabellenkalkulation lesen kann.
• Die Verteilung der Ablehnungsgründe beobachten; steigendes Lagerort unbekannt deutet fast immer auf ein Mappingproblem.

Ein Abstimmbericht, den die Buchhaltung akzeptiert

Die Zählung muss erklärbar sein, nicht nur richtig.

• Pro Zeile die Menge vorher, die beobachtete Menge und die erzeugte Korrektur berichten.
• Jede Korrektur einem Gerät, Bediener, einer Sitzung und einem Zeitfenster zuordnen.
• Korrekturen aus Zählfehlern von jenen aus nicht erfassten Bewegungen trennen.
• Den Wert der Korrekturen mit dem Inventarwert der Periode vergleichen, damit Drift sichtbar wird.
• Den Bericht unveränderlich speichern, weil ein Prüfer ihn Monate später anfordert.

Rollout-Reihenfolge und was zuerst zu testen ist

Die Reihenfolge ist so gewählt, dass Fehler dort passieren, wo sie billig sind.

• Mit einer Lagerortklasse und einem Gerätemodell im Schattenmodus starten: in Staging importieren, vergleichen, nicht schreiben.
• Dann Schreibvorgänge für eine Kategorie mit niedrigem Wert und hoher Bewegung freigeben.
• Dann auf eine vollständige Stichprobenzählung ausweiten und die manuelle Nachzählung als Schiedsrichter behalten.
• Die hässlichen Fälle früh testen: kein Signal, Akku leer mitten in der Sitzung, doppelte Synchronisation, falsche Zeitzone.
• Eine einseitige Bedieneranweisung veröffentlichen, denn die meisten Systemfehler sind Reihenfolgefehler.