Receiving sessions: la palette de Schrodinger n’est pas une strategie de stockage

Receiving doit rester prévisible dès le premier scan. Un camion arrive, le manifest dit une chose, le chauffeur en dit une autre, et quelqu’un peut scanner le mauvais code-barres pendant la première heure. Le modèle de session garde ce travail traçable : ce qui est arrivé, qui l’a scanné, quels écarts ont été trouvés et quand le handoff est devenu inventory.

Dans ReVend OS, receiving est une session — une vraie entité dans la base de données avec son propre ID (RECEIV-NNNNN), un début, une fin et un handoff signé qui dit "ces assets sont maintenant inventory, arrêtez de demander". Ce n'est pas une impression. C'est une row.

Ce qu'une session contient

Chaque session est liée à un inbound order, à l'operator de service, au dock ou station où il travaille, et au moment d'ouverture. Chaque asset scanné pendant la session est lié à cette session row, pour pouvoir répondre plus tard à "qu'est-ce qui est arrivé mardi après-midi à AMS-Dock-2?" sans fouiller dans les e-mails. Le composant QuickGrid intake est conçu pour une utilisation keyboard-only: Tab entre les cellules, Enter pour valider une row, Alt+↓ pour choisir dans les brand suggestions. Le grid a été reconstruit pour tenir sur tablette sans scroll horizontal, afin que le dock n'ait pas besoin d'un écran desktop sur un chariot élévateur.

Bulk receive

Pour les loads où scanner un asset à la fois n'est pas le bon rythme, l'onglet manifest de l'inbound-detail propose maintenant un bulk-receive flow: collez ou chargez une serial list, la plateforme la réconcilie avec le manifest en un passage, et crée les asset rows dans une seule transaction. Les discrepancies apparaissent dans la même view que le scanner par asset — même logique de reconciliation, ergonomie différente. Utile quand 200 Latitudes identiques arrivent sur une pallet et que le scan asset par asset devient un goulot d'étranglement.

Le handoff

Fermer une session est un acte délibéré. L'operator marque le count, les discrepancies et les éventuelles condition exceptions. Le système écrit un handoff record signé — RLS-protected, tamper-évident, append-only — et les assets passent de "received" à "inventory". Un rôle séparé (warehouse manager) peut approuver les discrepancies au-dessus d'un threshold, afin que l'operator ne puisse pas masquer seul une pallet manquante.

Pourquoi l'entité existe

Parce que "l'inbound order est aussi le receiving record" était faux. Un inbound order est une revendication contractuelle sur ce qui doit arriver. Une receiving session est la preuve physique de ce qui est arrivé. Les confondre signifiait qu'on ne pouvait pas rouvrir receiving sans rouvrir l'order — et qu'on ne pouvait pas fermer l'order tant que receiving n'était pas terminé — ce qui créait exactement le type de deadlock de state machine qui finit par quelqu'un qui envoie un CSV par e-mail. Deux entités. Un handoff. Un mercredi prévisible.