Mecalux/mcp-wms-wiki

Fork 0

Files

T

Arthur Ria 23eb3f3c84 màj wiki avec retour MES lot-5 AD

2026-05-20 09:41:27 +02:00

9.4 KiB

Raw Blame History

title, tags, status, standard_ref, jira_refs, confluence_refs, sources, last_updated, author

title

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). 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

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

Historique des modifications

Date	Auteur	Modification
2026-05-12	Arthur	Création initiale depuis LIM-88

Références

Source	Type	Date
LIM-88	Ticket Jira	2026
Expédition - LIMAGRAIN - DEV	Page Confluence	2026
Projet Bardinet	Pattern custom stacker crane multi-TK	—

9.4 KiB Raw Blame History