---
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 | — |
