**Règle générale** : on n’envoie aucune palette sur l’image de quai tant que le picking n’est pas terminé (et que les palettes sont revenues à l’ASRS). Elles n’ont pas forcément besoin d’avoir été défragmentées ; si elles ont uniquement été rangées, via de la reloc, le WMS pourra quand même sortir les palettes dans le bon ordre des numéros de stop.
1er custom imaginé : bloquer la génération des tâches de shipping tant que tout le picking n’a pas été fait (et empêcher la defrag si quai assigné)
-> en réalité : pas de defrag si quai assigné, et pas besoin d’empêcher le shipping de cette manière, il suffit d’empêcher d’envoyer une palette qu n’a pas le bon numéro de stop dans la commande.
Exemple du csutom à faire dans cette tâche
J’ai déjà mes 3 premieres palettes de shipping dans l’ordre : le TK envoie les 3 premiers stop et envoie la palette de picking en parallèle au pk, dès qu’elle revient, il l’envoi, pui senvoie le reste de palettes de shipping etc.
Si un quai est déjà associé à l’OS lorsqu’il est lancé, **custom :** la palette de picking au PK ne pas pas aller à l’image de quai et doit rentrer à l’ASRS → standard finalement (à tester) le WF qui génère la tache de shipping depuis la Tp regarde si ya un quai assigné, si oui, cherche une route, si pas de route, créer une tâche de rangement (start rangement support client).
Lors du rangement, le crossdock est OFF donc la palette se range bien (et ne repart pas direct du convoyeur au quai)
# 0. Résumé
La tâche gère le cas où un quai est déjà assigné à une tournée (RUT) et qu'il faut envoyer les palettes vers l'image de quai dans l'ordre inverse des STOP, y compris quand du picking est encore en cours.
Approche retenue : on laisse le standard générer les tâches de shipping au fil de l'eau (pas de blocage custom à la génération, c'est trop intrusif), et on **override partiellement le WF de tri du stacker crane** pour qu'il analyse la séquence STOP au niveau de **tous les TK** de la tournée (vs. un seul TK en standard) — pattern déjà éprouvé sur le projet Bardinet. Conséquence : une palette d'un STOP inférieur ne sort que si tous les STOP supérieurs sont déjà partis ; si une palette d'un STOP supérieur est encore au PK, les STOP inférieurs attendent en cascade.
Côté retour de picking : la palette client revient **systématiquement** dans l'ASRS (jamais de cross-dock direct vers l'image de quai), via une tâche de rangement générée par le standard quand aucune route vers le quai n'est disponible et avec crossdock OFF — à confirmer en recette, sinon custom de secours.
> **Références :**
>
> - Confluence : [Expédition](https://easywmsfrance.atlassian.net/wiki/spaces/LIM/pages/3001432145921/Exp+dition) — §4 Génération des tâches, §7 Cadencement des tâches
>
> - Tâche liéé : [LIM-87: #LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné #ATTENTE_CLIENT (CT-13)Attente déploiement pour test](https://easywmsfrance.atlassian.net/browse/LIM-87) (défrag custom quand quai **non** assigné — cas complémentaire)
>
> - Ressource : projet **Bardinet** — custom d'analyse de séquence multi-TK au niveau stacker crane
>
---
## 1. Contexte
Cas de figure : **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).
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 (cela casse l'ordre de chargement) ;
- 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 ».
### Ce qu'il ne faut pas faire (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. Bloquer la génération de tâche n’est pas non plus simple. Il y a plein de process qui le font, et parfois ce ne sont pas des jobs ; donc si on les bloque ; les tâches se régénèrent jamais.
### Ce qu'on veut faire
Générer toutes les tâches de shipping **pour les palettes déjà prêtes** dès que le quai est assigné. Laisser le stacker crane (via son WF de tri) choisir **dans quel ordre** les exécuter en fonction des STOP et de la disponibilité physique des palettes des STOP supérieurs.
## 2. Objectif du custom
### 2.1 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. 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 (stacker crane)** : le WF de tri des tâches applique la règle STOP max → STOP 1 avec blocage si un STOP supérieur a des palettes manquantes. Règle détaillée :
- 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) → on **bloque** les STOP inférieurs 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 avec quai assigné** : la PF doit **retourner dans l'ASRS** et ne pas cross-docker vers l'image de quai. Ce comportement serait **standard** et repose sur le WF 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 avec les stratégies de rangement de support client. Crossdock OFF pour que la palette rentre bien dans l'ASRS. **À confirmer en recette.**
### 2.2 Ce qui reste standard
- Génération des tâches de shipping.
- Mécanique de routage TP PK → ASRS même si palette demandée sur une image de quai (pas de crossdock).
- Le principe « le stacker crane force la sortie dans l'ordre strict des STOP pour les palettes prêtes ».
- Si pendant le picking l’opérateur déclare un problème sur un stock (statut de stock empêchant la prépa de commande) et que le stock reassign :
- ne trouve pas d’autres palettes, alors les palettes suivantes prêtes du STOP sont envoyées. Si un autre stock est retrouvé plus tard, le séquençage ne sera pas respecté mais le chargement camion devrait faire garde-fou.
- trouve une autre palette dispo, elle récupère le séquençage en cours et tout rentre dans l’ordre
### 2.3 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). Custom déjà réalisé sur le projet Bardinet — à reprendre comme pattern.
## 3. Solution retenue
### 3.1 Mécanisme
- **Override partiel** du WF de tri du stacker crane : insérer un filtre custom à l'endroit du tri, sur le même modèle que Bardinet.
- Le filtre analyse la séquence STOP **au niveau de tous les TK** (vision globale de la tournée) au lieu de se limiter à un seul TK comme le fait le standard.
- Pas de génération custom : on laisse le standard créer les tâches de shipping au fur et à mesure que les palettes deviennent prêtes.
### 3.3 Points à valider en recette
- [ ] Vérifier en POC que le standard crée bien une tâche de rangement quand il n'y a pas de route vers l'image de quai. Sinon → prévoir un custom de secours.
---
## 4. 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)
- **RUT** = tournée, **STOP** = numéro d'arrêt dans la tournée (ordre de livraison)
- **Éligible** = le WF de tri autorise la sortie de la palette du TK vers l'image de quai
- **Non éligible** = la tâche reste en attente, le stacker crane ne la prend pas
### 4.1 Cas nominaux
#### CT-01 — RUT mono-STOP, toutes palettes prêtes
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec 1 SOR, STOP 1, 3 PC assignées dans l'ASRS, quai assigné.|
|**Action**|Libération du RUT.|
|**Résultat attendu**|3 tâches de shipping générées. Les 3 palettes partent vers l'image de quai (pas de contrainte d'ordre inter-STOP).|
#### CT-02 — RUT multi-STOP sans picking, toutes palettes prêtes
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec 3 SOR (STOP 1, 2, 3), chaque SOR a 2 PC dans l'ASRS, quai assigné.|
|**Action**|Libération du RUT.|
|**Résultat attendu**|6 tâches de shipping générées en une fois. Le stacker crane exécute d'abord les 2 palettes du STOP 3, puis les 2 du STOP 2, puis les 2 du STOP 1.|
#### CT-03 — RUT multi-STOP avec picking terminé avant libération
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec 3 SOR, picking réalisé avant la libération, toutes PF revenues à l'ASRS, quai assigné.|
|**Action**|Libération du RUT.|
|**Résultat attendu**|Identique à CT-02. Le fait que certaines palettes soient des PF n'a aucune incidence — elles sont dans l'ASRS, le tri par STOP s'applique.|
### 4.2 Cas limites (coeur du custom)
#### CT-04 — Palette du STOP max encore en picking à la libération
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec 3 SOR. STOP 3 = 1 PP au PK, PF pas revenue. STOP 2 et STOP 1 = toutes palettes dans l'ASRS. Quai assigné.|
|**Action**|Libération du RUT, passage du job stacker crane.|
|**Résultat attendu**|Les tâches de shipping pour les palettes des STOP 1 et 2 sont générées mais **non exécutées**. Pas de tâche pour la PF du STOP 3 (pas encore dans l'ASRS). Aucune palette ne part vers l'image de quai.|
#### CT-05 — PF du STOP max revient à l'ASRS, déblocage progressif
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|Suite du CT-04. La PF du STOP 3 revient du PK, est rangée dans un TK de l'ASRS.|
|**Action**|Passage du job stacker crane.|
|**Résultat attendu**|1. Tâche de shipping générée pour la PF du STOP 3.
2. Elle devient éligible en premier (plus aucun STOP supérieur).
3. Part vers l'image de quai.
4. Puis les palettes du STOP 2 deviennent éligibles et partent.
5. Puis celles du STOP 1.|
#### CT-06 — Palette de STOP intermédiaire en picking, blocage en cascade
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec 5 SOR (STOP 1 à 5). STOP 5 et 4 = toutes palettes ASRS. STOP 3 = 1 PP au PK. STOP 2 et 1 = toutes palettes ASRS. Quai assigné.|
|**Action**|Libération du RUT.|
|**Résultat attendu**|Les palettes du STOP 5 partent. Les palettes du STOP 4 partent. Les palettes du STOP 2 et STOP 1 sont **bloquées** (le STOP 3 n'est pas sorti). La PF du STOP 3 reviendra → rangement ASRS → tâche shipping générée → STOP 3 part → STOP 2 part → STOP 1 part.|
#### CT-07 — Plusieurs palettes sur un même STOP dont certaines en picking
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec STOP 3 contenant 4 palettes : 3 PC dans l'ASRS, 1 PP au PK (PF pas revenue). STOP 2 et 1 prêts. Quai assigné.|
|**Action**|Libération du RUT, passage du job.|
|**Résultat attendu**|Les 3 PC du STOP 3 partent vers l'image de quai. La 4e palette (PF attendue) n'a pas encore de tâche. **Les STOP 2 et 1 restent bloqués** tant que la 4e palette du STOP 3 n'est pas sortie. À son retour PK → ASRS → tâche shipping → sortie → puis STOP 2 débloqué.|
### 4.3 Retour PF du PK vers l'ASRS
#### CT-08 — PF revient du PK : rangement ASRS systématique
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec quai assigné, une PF arrive à la TP de sortie du PK. STOP de la PF quelconque (éligible ou non — sans importance).|
|**Action**|WF de génération de tâche depuis la TP s'exécute.|
|**Résultat attendu**|Tâche de rangement créée. Crossdock OFF. La PF rentre dans l'ASRS et est rangée dans un TK. **Aucun cross-dock direct vers l'image de quai depuis le PK, quel que soit le STOP.**|
### 4.4 Multi-tournées
#### CT-09 — Deux RUT en parallèle, quais distincts
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT A sur quai 1, RUT B sur quai 2. Chacun a plusieurs STOP avec palettes dans l'ASRS.|
|**Action**|Libération simultanée des deux RUT.|
|**Résultat attendu**|Chaque RUT est ordonnancé indépendamment. Pas de fuite de tri entre RUT A et RUT B. Les palettes de A partent vers quai 1 dans l'ordre des STOP de A ; idem pour B vers quai 2.|
#### CT-11 — Deux RUT, un seul quai libre (standard)
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT A avec quai assigné, RUT B en attente (pas de quai libre).|
|**Action**|Passage du job.|
|**Résultat attendu**|RUT A traité normalement par le tri custom. RUT B reste hors périmètre du custom (pas de quai → relève de LIM-87 pour la défrag). **Vérifier** qu'il n'y a pas d'interférence entre les deux mécanismes.|
#### CT-12 — Ajout d'un SOR à une tournée en cours
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT en cours d'exécution, STOP 3 déjà parti, STOP 2 en cours. Un nouveau SOR est ajouté au RUT avec STOP 1 et des lignes picking.|
|**Action**|Passage du job stacker crane après ajout.|
|**Résultat attendu**|Les nouvelles palettes s'insèrent dans l'ordre STOP (ici STOP 1). Elles attendent la fin du STOP 2. Si le nouveau SOR nécessite du picking, les PF reviendront à l'ASRS (CT-08) puis seront éligibles une fois STOP 2 fini.|
#### CT-13 — Bascule de quai en cours de tournée
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec quai 1 assigné, certaines palettes déjà à l'image de quai 1. L'exploitation rebascule le RUT sur quai 2 (cas blocage/incident).|
|**Action**|Passage du job après bascule.|
|**Résultat attendu**|**À définir en recette.** Attendu : les tâches de shipping restantes sont regénérées vers l'image de quai 2. Les palettes déjà à l'image de quai 1 sont à traiter manuellement (hors périmètre custom). Le tri par STOP continue de s'appliquer pour les palettes restantes dans l'ASRS.|
### 4.4 Problème de stock au picking
#### CT-14 — Stock reassign ne trouve rien
| | |
|---|---|
|Élément|Valeur|
|**Préconditions**|RUT avec quai 1 assigné, un SOR avec 3 STOP. STOP 3 déjà sur l’image de quai, une PP STOP 2 au PK. L’opérateur déclare un problème et la PP n’est plus assignée à la commande. Le stock reassign échoue à trouver un autre stock et la tâche de picking disparaît.|
|**Résultat attendu**|La palette est ignorée par stacker_crane et on reprend l’ordre des stops.|
#### CT-15 — Stock reassign trouve une nouvelle palette
| | |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Élément | Valeur |
| **Préconditions** | RUT avec quai 1 assigné, un SOR avec 3 STOP. STOP 3 déjà sur l’image de quai, une PP STOP 2 au PK. L’opérateur déclare un problème et la PP n’est plus assignée à la commande. Le stock reassign trouve une nouvelle palette dans l’ASRS et l’envoie au PK. |
| **Résultat attendu** | La nouvelle palette récupère le stop de la palette remplacée et le séquençage n’est pas impacté. |