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
267 lines
13 KiB
Markdown
267 lines
13 KiB
Markdown
---
|
|
title: "Séquençage shipping par STOP - Quai assigné"
|
|
tags: [outbound, expédition, shipping, tournée, STOP, stacker-crane, custom, AGV]
|
|
status: review
|
|
standard_ref: concepts/shipping.md
|
|
jira_refs: [LIM-88, LIM-94]
|
|
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
|
|
sources: ["LIM-88 LOT2.1 [TOURNÉES] Séquençage des tâches de shipping par STOP - quai assigné.md", "Jira LIM-88 (lecture directe, revue de code)"]
|
|
last_updated: 2026-07-17
|
|
author: 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](../../concepts/shipping.md),
|
|
> [Defragmentation](../../concepts/defragmentation.md)
|
|
> 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](../02-stockage/defragmentation.md)
|
|
(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](assignation-image-quai.md)).
|
|
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](assignation-image-quai.md) |
|
|
|
|
### 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
|
|
|
|
```mermaid
|
|
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](../08-transverse/questions-ouvertes.md)
|
|
- [x] ~~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](../08-transverse/questions-ouvertes.md)
|
|
|
|
## 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](https://easywmsfrance.atlassian.net/browse/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 | - |
|