Receiving Sessions: Schrödingers Palette ist keine Lagerstrategie
Warum Receiving eine Session mit Nummer, Anfang und Ende ist — und kein Bauchgefühl.
Receiving muss ab dem ersten Scan vorhersehbar bleiben. Ein Lkw kommt an, das Manifest sagt das eine, der Fahrer etwas anderes, und in der ersten Stunde scannt vielleicht jemand den falschen Barcode. Das Session-Modell hält diese Arbeit beantwortbar: was angekommen ist, wer gescannt hat, welche Manifest-Zeilen noch offen sind und wann die Arbeit endete.
In ReVend OS ist Receiving eine Session — eine echte Entität in der Datenbank, mit eigener Nummer (RECEIV-2026-00042, vergeben pro Tenant und Jahr vom selben Zähler, der auch Ihre Aufträge nummeriert), einem Anfang, einem Ende und einem Status. Das ist kein Bauchgefühl. Das ist eine Zeile.
Was in einer Session steht
Jede Session gehört zu einem Inbound Order und hält fest, wer sie geöffnet hat, wann sie geöffnet und wann sie geschlossen wurde, welchen Status sie hat — offen, pausiert oder geschlossen —, ihre Notizen und die Collection, aus der sie stammt, sofern es eine gibt. Jedes Asset, das Ihre Operators während der Session anlegen, hängt an dieser Session-Zeile, sodass sich später „was kam am Dienstagnachmittag herein“ beantworten lässt, ohne E-Mails zu durchsuchen. Solange die Session nicht geschlossen ist, kann sie mit einer Palette verknüpft werden, damit die in diesem Durchgang gescannten Assets auf der Palette landen, auf der sie physisch stehen.
Assets werden sofort als Assets angelegt. Es gibt keine Wartezone aus „empfangenen Positionen“, die später jemand ins Inventory befördern muss; sobald eine Zeile in der Session gespeichert ist, existiert sie im laufenden Asset-Register, mit ihrer Session und ihrem Inbound Order daran.
Scannen, Grid, Bulk
Die QuickGrid-Erfassung ist für reine Tastaturbedienung gebaut: Tab zwischen den Zellen, Enter speichert eine Zeile, Alt+↓ wählt aus den Marken-Vorschlägen. Sie passt ohne horizontales Scrollen auf ein Tablet, damit am Dock kein Desktop-Monitor auf dem Gabelstapler landet. Die mobilen Receiving-Screens zeigen, wer eingeloggt ist und für welche Organisation, mit Sign-out einen Tipp entfernt — ein geteilter Scanner ist nur so vertrauenswürdig wie der Account, der ihn gerade hält.
Für Ladungen, bei denen ein Asset nach dem anderen das falsche Tempo ist, bietet der Manifest-Tab des Inbound Orders die Massenannahme: offene Manifest-Zeilen auswählen, ihnen einen gemeinsamen Zustand geben, und die Plattform legt die empfangenen Assets für diese Zeilen in einem Zug an. Seriennummernlisten kommen über den Excel- oder CSV-Manifest-Import herein; die Massenannahme macht aus der Ankündigung dann Bestand. Praktisch, wenn 200 identische Latitudes auf einer Palette ankommen.
Keine Order? Trotzdem anfangen
Ein Lkw, der ohne vorbereiteten Inbound Order vorfährt, ist trotzdem ein Lkw. Standalone-Receiving öffnet eine Session und legt einen Hüllen-Inbound-Order an, an dem sie hängt, damit die Assets ab dem ersten Scan einen Elternsatz haben und der Papierkram den Paletten hinterherkommt.
Pausieren, schließen — und der Fall, der feststeckt
Sessions lassen sich pausieren und wieder aufnehmen — die Schicht endet, die Session muss es nicht. Schließen ist eine Statusänderung auf geschlossen, mit Urheber in der Activity festgehalten; mehrere Sessions können gegen denselben Inbound Order schließen, wenn eine Lieferung in zwei Lkw ankommt. Assets einer Session gehen direkt von der Session-Seite ins Testing. Für eine Session, die in einem Status feststeckt, der nicht mehr zur Realität passt, gibt es einen Force-Finalize-Weg — für die Fälle, in denen die operative Wahrheit klar ist und nur noch der Status korrigiert gehört.
Warum es die Entität gibt
Weil „der Inbound Order ist auch der Receiving-Nachweis“ falsch war. Ein Inbound Order ist eine vertragliche Behauptung darüber, was kommt. Eine Receiving Session ist der physische Nachweis dessen, was aufgetaucht ist. Die Receiving-Übersicht und die Pipeline benutzen eine gemeinsame Regel dafür, was als offene Receiving-Arbeit zählt — ein nicht vollständig empfangener Auftrag oder eine noch offene oder pausierte Session —, sodass ein vollständig empfangener Auftrag ohne aktive Session aus beiden Screens gleichzeitig verschwindet. Zwei Entitäten. Eine Regel. Vorhersagbarer Mittwoch.