arthur
7496aafe64
- Bloquants: mermaid 03-picking/_index reconstitue (archive 11-05), 13 liens vers pages squelette retires, 2 liens recibles (anoxie, application-dictionary) - Conventions: 910 em dashes -> tirets simples, 145 checklists -> puces question, 13 questions resolues barrees - Liens: 9 ancres reparees (slugs GitHub) - Delta: 12 standard_ref remappes, blocs Standard EasyWMS + sections References ajoutes, front matter complete - Glossaire: 15 termes standard deplaces en section rappel avec renvoi - Rapport: limagrain/_lint_report.md (Phase 1 + Phase 2 + re-scan final) - Inclut les pages des sessions precedentes non commitees + CLAUDE.md et consume.log en l'etat
13 KiB
title, tags, status, standard_ref, jira_refs, confluence_refs, sources, last_updated, author
| title | tags | status | standard_ref | jira_refs | confluence_refs | sources | last_updated | author | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Séquençage shipping par STOP - Quai assigné |
|
review | concepts/shipping.md |
|
|
|
2026-07-17 | Arthur |
Séquençage shipping par STOP - Quai assigné
Résumé : quand un quai est déjà assigné à une tournée (RUT), les palettes doivent sortir de l'ASRS vers l'image de quai dans l'ordre inverse des STOP. Un custom override le WF de tri du stacker crane pour analyser la séquence STOP sur tous les TK (vision globale de la tournée) au lieu d'un seul TK.
Standard EasyWMS : → voir Shipping, Defragmentation Ce qui suit documente les spécificités Limagrain par rapport au standard.
Contexte projet
Ce custom est le cas complémentaire de la défragmentation client par tournée (LIM-87) qui traite le cas « quai non assigné ».
Ici, le quai est déjà assigné au RUT quand la tournée est libérée (ou assigné avant la fin du picking, ou après). L'assignation de l'image de quai peut être manuelle ou automatique via le job LIM-94 (voir Assignation automatique de l'image de quai). Dans ce cas, LIM-87 (défrag custom) ne s'applique pas : c'est le flux shipping standard qui prend le relais pour envoyer les palettes vers l'image de quai. Il faut néanmoins respecter la règle métier d'ordonnancement par n° de STOP (ordre inverse : STOP max → STOP 1) pour que les palettes soient posées sur l'image de quai dans le bon ordre de chargement camion.
Le picking peut encore être en cours sur certaines lignes. On ne veut pas :
- Qu'une palette complète du STOP 1 parte vers l'image de quai alors que des palettes des STOP supérieurs ne sont pas encore prêtes
- Qu'une palette fille (PF) sortant du PK aille en cross-dock direct vers l'image de quai si son STOP n'est pas encore « éligible »
Approche initiale abandonnée
Custom imaginé au départ : bloquer la génération des tâches de shipping tant que tout le picking n'est pas terminé.
Trop restrictif - on ne profiterait pas du temps pendant lequel les palettes complètes pourraient déjà être pré-positionnées sur l'image de quai dans l'ordre. Par ailleurs, bloquer la génération de tâche est complexe car de nombreux process la déclenchent (pas uniquement des jobs).
Solution retenue
Comportement attendu
1. Génération des tâches shipping (standard)
Dès que le quai est assigné, toutes les palettes prêtes (complètes dans l'ASRS + palettes filles revenues de picking) ont leur tâche de shipping générée par le standard. Une palette non encore pickée n'a pas de tâche - sa tâche sera créée au moment où elle rentrera dans un TK après picking.
2. Ordonnancement d'exécution (custom stacker crane)
Le WF de tri des tâches du stacker crane applique la règle STOP max → STOP 1 avec blocage si un STOP supérieur a des palettes manquantes :
- Si toutes les palettes du STOP N+1 (et au-delà) sont déjà sorties de l'ASRS → les palettes du STOP N deviennent éligibles
- Si un STOP supérieur a encore des palettes non prêtes (picking en cours) → les STOP inférieurs sont bloqués en attente
- Dès qu'une palette manquante devient prête (PF rangée dans un TK) → sa tâche de shipping est créée et le stacker crane reprend le déroulé dans l'ordre
3. Retour palette fille du PK (standard attendu)
La PF doit retourner dans l'ASRS et ne pas cross-docker vers l'image de quai. Ce comportement repose sur le WF standard qui génère la tâche shipping depuis la TP du PK : s'il y a un quai assigné mais pas de route disponible vers l'image de quai, il crée une tâche de rangement (start rangement support client). Crossdock OFF pour que la palette rentre bien dans l'ASRS.
⚠️ À confirmer en recette : vérifier que le standard crée bien une tâche de rangement quand pas de route vers l'image de quai. Sinon → prévoir un custom de secours.
Ce qui est custom
- Le tri du stacker crane doit considérer les palettes sur tous les TK (pas uniquement celles dans un TK unique comme en standard). Pattern déjà réalisé sur le projet Bardinet - à reprendre.
Ce qui reste standard
- Génération des tâches de shipping
- Mécanique de routage TP PK → ASRS (pas de crossdock)
- Gestion du stock reassign après déclaration problème au picking : si pas de stock trouvé → palettes suivantes du STOP envoyées ; si nouveau stock trouvé → récupère le séquençage
Implémentation définitive (revue de code validée 2026-06-02)
Statut : En cours de test client (pré-production). Revue de code et tests validés. Deux revues successives : le tri multi-TK (Maxime Halgand) puis un garde-fou complémentaire sur la génération des tâches de chargement (Vincent Charvet).
Le custom se limite à une query clonée et deux workflows overridés. Aucune génération de tâche custom : le standard crée les tâches shipping au fil de l'eau, le custom n'intervient qu'au tri et pose un garde-fou sur la génération des tâches de chargement AGV.
Query
| Élément | Rôle |
|---|---|
CST_Tasks_PendingOutboundForStackerCrane |
Cœur du custom. Clone de Tasks_PendingOutboundForStackerCrane. Filtre pour récupérer toutes les tâches shipping, conteneurs picking, conteneurs shipping et conteneurs client d'un numéro de STOP supérieur, et vérifier s'ils sont tous en station image de quai (DockStage) ou non |
Workflows
| Workflow | Modification |
|---|---|
StackerCrane_GetOutboundPendingTasks_PR |
Utilise la query custom au lieu de la standard. Ajoute un log pour conserver les informations de recherche |
Outbound_CreateShippingOrLoadTasksToDockOrStage_PR |
Empêche la création d'une tâche de chargement s'il n'y a pas de stage (image de quai) associé à l'OS. Sans ce garde-fou, les palettes bloquent aux PS car les AGV n'ont pas de destination pour effectuer le mouvement (commit 0aec1c3b). Le stage est posé par LIM-94 |
Règle de filtrage
Le filtre ne bloque que les sorties d'expédition : une palette d'un STOP donné ne sort vers l'image de quai que si tous les STOP supérieurs sont déjà arrivés en station DockStage. En revanche, les sorties de palettes picking restent toujours autorisées pour permettre le prélèvement anticipé : le picking n'est jamais bloqué par le séquençage.
Flux fonctionnel
sequenceDiagram
participant SAP as SAP
participant WMS as EasyWMS
participant TK as Stacker Crane
participant PK as Poste Picking
participant IQ as Image de Quai
SAP->>WMS: RUT avec STOP 1, 2, 3
WMS->>WMS: Libération + assignation stock
Note over WMS: Quai déjà assigné
WMS->>TK: Tâches shipping (PC prêtes)
Note over TK: CUSTOM: tri multi-TK par STOP
TK->>IQ: Palettes STOP 3 (max)
Note over TK: STOP 2 bloqué si PF au PK
PK->>TK: PF revenue ASRS (rangement)
TK->>IQ: Palette PF STOP 2
TK->>IQ: Palettes STOP 2 (reste)
TK->>IQ: Palettes STOP 1
Cas de test
Légende
- PC = palette complète (pas de picking nécessaire)
- PP = palette de picking (palette mère qui part au PK)
- PF = palette fille (sortie du picking, retour ASRS)
Cas nominaux
| CT | Préconditions | Résultat attendu |
|---|---|---|
| CT-01 | RUT mono-STOP, 3 PC dans ASRS, quai assigné | 3 tâches shipping, palettes partent vers image de quai |
| CT-02 | RUT multi-STOP (1, 2, 3), 2 PC chacun, quai assigné | 6 tâches. Stacker crane exécute STOP 3, puis 2, puis 1 |
| CT-03 | RUT multi-STOP, picking terminé avant libération, toutes PF revenues | Identique à CT-02 - PF ou PC, même logique |
Cas limites (cœur du custom)
| CT | Préconditions | Résultat attendu |
|---|---|---|
| CT-04 | STOP 3 = 1 PP au PK. STOP 2 et 1 prêts. Quai assigné | Tâches STOP 1 et 2 générées mais non exécutées. Aucune palette ne part |
| CT-05 | Suite CT-04 : PF STOP 3 revient dans ASRS | Tâche shipping PF créée → STOP 3 part → STOP 2 débloqué → STOP 1 débloqué |
| CT-06 | 5 STOP. STOP 5 et 4 prêts. STOP 3 = 1 PP au PK. STOP 2 et 1 prêts | STOP 5 et 4 partent. STOP 2 et 1 bloqués par STOP 3. Déblocage en cascade après retour PF STOP 3 |
| CT-07 | STOP 3 = 4 palettes dont 1 PP au PK. STOP 2 et 1 prêts | 3 PC du STOP 3 partent. STOP 2 et 1 bloqués tant que la 4e palette du STOP 3 (PF) n'est pas sortie |
Retour PF du PK
| CT | Préconditions | Résultat attendu |
|---|---|---|
| CT-08 | PF arrive à la TP sortie PK, quai assigné | Tâche de rangement ASRS créée. Crossdock OFF. Jamais de cross-dock direct vers image de quai |
Multi-tournées
| CT | Préconditions | Résultat attendu |
|---|---|---|
| CT-09 | 2 RUT en parallèle, quais distincts | Ordonnancement indépendant par RUT. Pas de fuite de tri |
| CT-11 | RUT A avec quai, RUT B sans quai | RUT A traité par ce custom. RUT B relève de LIM-87 (défrag). Vérifier absence d'interférence |
| CT-12 | SOR ajouté à un RUT en cours d'exécution | Nouvelles palettes s'insèrent dans l'ordre STOP. Si picking nécessaire → PF reviendront à l'ASRS |
| CT-13 | Bascule de quai en cours de tournée | Scénario exclu : on ne peut pas changer le quai une fois la RUT libérée (contrainte WMS, note dev revue de code). Une rebascule relève d'une opération manuelle exceptionnelle, hors périmètre custom |
Stock reassign au picking
| CT | Préconditions | Résultat attendu |
|---|---|---|
| CT-14 | Problème déclaré, stock reassign échoue | Palette ignorée par stacker crane, STOP suivants envoyés |
| CT-15 | Problème déclaré, stock reassign trouve nouvelle palette | Nouvelle palette récupère le STOP, séquençage non impacté |
Points d'attention
⚠️ Le custom de tri multi-TK reprend un pattern Bardinet - ne pas réinventer le mécanisme.
⚠️ Le retour systématique des PF vers l'ASRS (pas de crossdock) est le comportement standard attendu mais doit être validé en recette.
⚠️ La bascule de quai en cours de tournée (CT-13) est impossible : le quai ne peut pas être changé une fois la RUT libérée. Une rebascule serait une opération manuelle exceptionnelle, hors périmètre custom.
⚠️ Les tâches de chargement ne doivent jamais être générées sans image
de quai associée à l'OS, sinon les palettes bloquent aux PS (les AGV
n'ont pas de destination). Garde-fou porté par
Outbound_CreateShippingOrLoadTasksToDockOrStage_PR.
Questions ouvertes
- ❓ Retour PF vers ASRS (CT-08) : confirmer que le standard crée bien une tâche de rangement quand pas de route vers l'image de quai. Sinon custom de secours nécessaire. (@Nicolas) → voir Questions ouvertes
Bascule de quai en cours de tournée (CT-13) : définir le comportement attendu pour les palettes déjà à l'ancien quai.→ Résolu (note dev, revue de code) : on ne peut pas changer le quai une fois la RUT libérée. Scénario exclu du custom. → voir Questions ouvertes
Historique des modifications
| Date | Auteur | Modification |
|---|---|---|
| 2026-05-12 | Arthur | Création initiale depuis LIM-88 |
| 2026-07-17 | Arthur | Ajout implémentation définitive (revue de code 02/06 : query CST_Tasks_PendingOutboundForStackerCrane, WF StackerCrane_GetOutboundPendingTasks_PR + Outbound_CreateShippingOrLoadTasksToDockOrStage_PR, règle picking toujours autorisé) ; statut préprod ; résolution CT-13 (quai non modifiable après libération RUT) |
| 2026-07-17 | Arthur | Cross-ref LIM-94 (assignation auto de l'image de quai / stage X_EXP dont dépend le garde-fou de chargement) ; jira_refs +LIM-94 |
Références
| Source | Type | Date |
|---|---|---|
| LIM-88 | Ticket Jira (statut préprod / test client) | 2026 |
| Revue de code LIM-88 (M. Halgand, V. Charvet, N. Chabanis) | Revue de code validée, commit 0aec1c3b |
2026-06-02 |
| Expédition - LIMAGRAIN - DEV | Page Confluence | 2026 |
| Projet Bardinet | Pattern custom stacker crane multi-TK | - |