Warehouses → zones → racks → positions
Une topologie à quatre niveaux pour qu’une palette ait une vraie adresse, et pas « Bâtiment C, quelque part ».
« Où est la palette » est une question à laquelle trop de warehouses ITAD répondent en marchant jusqu’à la trouver. La plateforme transforme la réponse en row dans une base de données.
La hiérarchie
Warehouse : un site physique — Amsterdam, Rotterdam, Bruxelles, ou là où vous opérez. Chaque warehouse a une adresse, des coordonnées de contact et une capacité en palettes, et la liste des warehouses montre quelle part de cette capacité est occupée, en pourcentage. Zone : une région à l’intérieur du warehouse, avec un type. Sept types sont livrés d’origine — receiving, processing, storage, staging, shipping, quarantine et recycling — et votre organisation peut ajouter ses propres types de zone quand le bâtiment a une pièce que les defaults n’avaient pas prévue. Rack : un code, un nom et une grille de rangées par colonnes à l’intérieur d’une zone. Position : un emplacement dans cette grille, avec sa rangée, sa colonne, un code-barres, un poids maximum et un flag « bloqué » pour l’emplacement situé sous le toit qui fuit.
Les positions portent des étiquettes code-barres Code128, imprimables depuis la page de détail du rack ; scanner une étiquette de position dit à la plateforme exactement où se tient l’opérateur et ce qui devrait se trouver devant lui.
Où le plan est géré
Créer des warehouses, les modifier, ajouter des zones et façonner le plan de racks : tout se passe sous Paramètres > Core > Emplacements. Les cartes warehouse et la page de détail y renvoient directement. La suppression d’une zone y reste aussi, parce que c’est là que vivent les contrôles de dépendance — la plateforme ne laissera pas disparaître une zone qui contient des palettes sous prétexte que le plan était plus joli sans elle.
La grille du rack
/core/storage-racks/[id] est une grille interactive du rack. Votre équipe peut glisser une palette d’un emplacement vers un autre, affecter à un emplacement une palette existante non placée, créer une nouvelle palette et la poser dans un emplacement, retirer une palette, bloquer ou débloquer une position vide, et ouvrir l’inventory filtré sur ce rack. Les changements sont mis en attente dans un buffer local et enregistrés d’un seul coup — ou jetés d’un seul coup. Essayez de quitter avec des changements en attente et la page vous prévient. C’est une de ces petites clémences qui empêchent un entrepôt de devenir un puzzle accompagné de factures.
Le journal des transferts
L’onglet Transferts d’un warehouse — également disponible comme page à part, pour être mis en favori — est l’historique des mouvements d’assets et de palettes : depuis quel rack, quelle zone ou quel warehouse vers quel autre, quand, et par qui. C’est un journal, pas un workflow : il n’y a pas de transfert à approuver, à expédier ou à réconcilier, seulement le record de ce qui a bougé. La recherche porte sur tout l’historique du warehouse avant que la page ne soit tronquée, avec le total et les sauts de page sous la liste. Quand un client demande où sa palette a passé le mois de mars, la réponse est un filtre, pas un souvenir.
Pourquoi quatre niveaux
Parce que « storage » n’est pas une adresse. Une receiving zone qui sature, une quarantine zone qui doit rester séparée, une position bloquée que tout le monde connaît sauf le nouvel opérateur — la plateforme ne peut faire respecter ces choses que si elle sait où elles sont, au niveau que comprend un chariot élévateur. Une row dans une base de données, ce n’est pas glamour. Arpenter les allées à 17h40 à la recherche d’une palette partie mardi non plus.