Receiving sessions : la palette de Schrödinger n’est pas une stratégie de stockage

Le 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é, quelles lignes de manifest sont encore ouvertes, et quand le travail s’est arrêté.

Dans ReVend OS, le receiving est une session — une vraie entité en base de données avec son propre numéro (RECEIV-2026-00042, attribué par tenant et par année par le même compteur qui numérote vos orders), un début, une fin et un statut. Ce n’est pas une impression. C’est une row.

Ce que contient une session

Chaque session appartient à un inbound order et enregistre qui l’a ouverte, quand elle a été ouverte, quand elle a été fermée, son statut — open, paused ou closed —, ses notes, et la collection dont elle provient lorsqu’il y en a une. Chaque asset que vos opérateurs créent pendant la session est lié à cette session row, ce qui permet de répondre plus tard à « qu’est-ce qui est arrivé mardi après-midi ? » sans fouiller dans les e-mails. Tant que la session n’est pas fermée, elle peut être liée à une palette, pour que les assets scannés dans ce passage atterrissent sur la palette où ils se trouvent physiquement.

Les assets sont créés comme assets, immédiatement. Il n’y a pas de purgatoire « received item » que quelqu’un devrait promouvoir en inventory plus tard ; dès qu’une row est validée dans la session, elle existe dans le registre d’assets vivant, avec sa session et son inbound order attachés.

Scan, grid, bulk

Le 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. Il tient sur une tablette sans scroll horizontal, pour que le dock n’ait pas besoin d’un écran desktop sur un chariot élévateur. Les écrans de receiving mobile affichent qui est connecté et pour quelle organisation, avec la déconnexion à un tap — un scanner partagé ne vaut jamais mieux que le compte qui le tient.

Pour les loads où scanner un asset à la fois n’est pas le bon rythme, l’onglet manifest de l’inbound order propose le bulk receive : sélectionnez les lignes de manifest en attente, donnez-leur une condition commune, et la plateforme crée les assets reçus pour ces lignes en une seule fois. Les listes de serials entrent par l’import de manifest Excel ou CSV ; le bulk receive transforme ensuite la claim en stock. Utile quand 200 Latitudes identiques arrivent sur une même palette.

Pas d’order ? Commencez quand même

Un camion qui se présente sans inbound order préparé reste un camion. Le standalone receiving ouvre une session et crée un inbound order coquille auquel l’accrocher, pour que les assets aient un parent dès le premier scan et que la paperasse rattrape les palettes.

Pause, fermeture, et le cas bloqué

Les sessions peuvent être mises en pause puis reprises — le poste se termine, la session n’est pas obligée de faire pareil. Fermer est un changement de statut vers closed, écrit dans Activity avec l’auteur ; plusieurs sessions peuvent se fermer contre un même inbound order quand un shipment arrive en deux camions. Les assets d’une session peuvent partir en testing directement depuis la page de session. Une session coincée dans un état qui ne correspond plus à la réalité dispose d’un chemin de force-finalize — pour quand la vérité opérationnelle est claire et que c’est le statut qu’il faut corriger.

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 le record physique de ce qui s’est présenté. La vue Receiving et le Pipeline appliquent une seule règle partagée pour définir ce qui compte comme travail de receiving ouvert — un order pas entièrement reçu, ou une session encore open ou paused — donc un order entièrement reçu sans session active disparaît des deux écrans en même temps. Deux entités. Une règle. Un mercredi prévisible.