Serienerfassung: Was beim Batch-Workflow Zeit spart
Standort und Typ werden einmal gesetzt. Jede Aufnahme landet in einer Queue; Upload, Analyse und Cover laufen weiter, während du das nächste Objekt fotografierst.
Open Inventory
Technische Notizen · MIT-lizenziert
Kurz zusammengefasst
- Gemeinsame Felder werden pro Batch wiederverwendet
- Resource-, Media-, Analyse- und Cover-Schritte laufen getrennt
- Stabile Idempotency-Keys verhindern Duplikate bei definierten Retries
Echte App-Aufnahme
Serienerfassung in der laufenden Web-App
Das eigentliche Problem
Welche Eingaben pro Batch wiederverwendet werden
Bei einer Serie kosten die wiederholten Kontextwechsel mehr Zeit als ein einzelnes Textfeld. Typ und Standort ändern sich innerhalb eines Regals oft nicht. Deshalb setzt du diese Werte einmal und übernimmst sie für die folgenden Aufnahmen.
Für jedes Foto legt der Client einen eigenen Auftrag an. Der Server erstellt zuerst den Inventareintrag, danach die Medien. Analyse und Cover sind optionale, getrennte Schritte. Ein Fehler beim Cover muss also nicht die bereits hochgeladenen Fotos verwerfen.
„In Sekunden statt Stunden“ beschreibt das Ziel für die Aufnahme vor Ort, nicht eine veröffentlichte Benchmark. Die Verarbeitung kann danach weiterlaufen. Gesamtdauer und Durchsatz hängen von Netz, Server, Bildgröße und aktivierten externen Diensten ab.
Der Ablauf
Die Queue in fünf Schritten
- 01
Batch-Kontext setzen
Wähle gemeinsame Werte, zum Beispiel Typ „Werkzeug“ und Standort „Werkstatt · Regal B2“. Cover-Erzeugung und Analyse bleiben optional.
- 02
Aufnahmen lokal vorbereiten
Nimm ein Hauptfoto und bei Bedarf weitere Blickwinkel auf. Modellnummern und Typenschilder gehören auf separate, scharfe Bilder.
- 03
Resource und Medien anlegen
Der Client erstellt den Eintrag und lädt anschließend die Bilder hoch. Beide Stufen haben eigene Status- und Fehlerzustände.
- 04
Queue weiterarbeiten lassen
Du startest die nächste Aufnahme, während frühere Jobs weiterlaufen. Definierte Wiederholungen nutzen stabile Operation-IDs und serverseitige Idempotency-Keys.
- 05
Ergebnisse prüfen
Kontrolliere Name, Tracking-Modus, Standort und Bilder. Seriennummern und benutzerdefinierte Felder werden nicht durch ein brauchbares Foto ersetzt.
Browser und iPhone
Web-Client und iOS-App im Vergleich
Der Web-Client kombiniert Browser-Kamera und vorhandene Dateien. Das passt zu Laptop oder Tablet am Arbeitstisch. Die native SwiftUI-App nutzt AVFoundation direkt und enthält zusätzlich Code-Scanner und RoomPlan-Pfade.
Unter iOS werden Fotos und Stage-Status in einer servergebundenen Outbox unter Application Support persistiert. Nach einem Neustart prüft die App den letzten bestätigten Schritt und setzt dort fort. Das ist keine Offline-Synchronisation des ganzen Datenmodells, sondern eine persistente Upload-Queue.
- Browser-Kamera benötigt HTTPS oder localhost; alternativ lassen sich Fotos hochladen.
- Für die native App muss dein selbst gehosteter Server vom iPhone erreichbar sein. Öffentliche Verbindungen sollten HTTPS verwenden.
- Optionale KI-Schritte verlassen den eigenen Server: Analyse nutzt OpenAI, Cover können über OpenAI oder Google laufen, Fotozählung über Replicate.
- Barcode-Erkennung ersetzt keine inhaltliche Prüfung, wenn mehrere Artikel denselben oder gar keinen Code tragen.
Nach der Aufnahme
Nach der Verarbeitung: Felder und Bilder prüfen
Die Queue liefert zunächst einen bearbeitbaren Datensatz. Danach musst du prüfen, ob Standort, Tracking-Modus, Menge und Bilder zum realen Objekt passen. Für Seriennummern oder sicherheitsrelevante Angaben sollte kein Modellvorschlag ungeprüft übernommen werden.
Der komplette Pfad liegt im MIT-lizenzierten Repository: Web-Client, REST-Routen und die SwiftUI-Outbox sind Open Source. Damit lassen sich Queue-Verhalten und Datenfluss direkt im Code prüfen und bei Bedarf ändern.
Weiterführend