Arthur Ria
221 lines
9.4 KiB
Plaintext
221 lines
9.4 KiB
Plaintext
---
|
|
title: "Séquençage shipping par STOP — Quai assigné"
|
|
tags: [outbound, expédition, shipping, tournée, STOP, stacker-crane, custom, AGV]
|
|
status: draft
|
|
standard_ref: concepts/shipping.md
|
|
jira_refs: [LIM-88]
|
|
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"]
|
|
last_updated: 2026-05-12
|
|
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). 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
|
|
|
|
## 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 | **À définir en recette.** Tâches restantes regénérées vers nouveau quai. Palettes déjà à l'ancien quai → traitement manuel |
|
|
|
|
### 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) n'est pas couverte
|
|
par le custom — les palettes déjà à l'image de quai de l'ancien quai
|
|
sont à traiter manuellement.
|
|
|
|
## 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)
|
|
- [ ] Bascule de quai en cours de tournée (CT-13) : définir le
|
|
comportement attendu pour les palettes déjà à l'ancien quai.
|
|
(@Justine)
|
|
→ voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
|
|
|
|
## Historique des modifications
|
|
|
|
| Date | Auteur | Modification |
|
|
|------|--------|--------------|
|
|
| 2026-05-12 | Arthur | Création initiale depuis LIM-88 |
|
|
|
|
## Références
|
|
|
|
| Source | Type | Date |
|
|
|--------|------|------|
|
|
| [LIM-88](https://easywmsfrance.atlassian.net/browse/LIM-88) | Ticket Jira | 2026 |
|
|
| Expédition - LIMAGRAIN - DEV | Page Confluence | 2026 |
|
|
| Projet Bardinet | Pattern custom stacker crane multi-TK | — |
|