Mecalux/mcp-wms-wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

màj wiki avec retour MES lot-5 AD

Browse Source
This commit is contained in:
Arthur Ria
2026-05-20 09:41:27 +02:00
commit 23eb3f3c84
4106 changed files with 469381 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/limagrain/.fuse_hidden000000670000002c
+166
View File
@@ -0,0 +1,166 @@
---
title: "Glossaire Limagrain"
tags: [glossaire, limagrain, référence]
status: draft
last_updated: 2026-05-12
author: Arthur
---
# Glossaire Limagrain
> **Résumé** : termes et acronymes spécifiques au projet Limagrain, complémentaires
> au [glossaire standard EasyWMS](../glossary.md).
| Terme | Signification |
|-------|---------------|
| CstAtt | Custom Attribute — handshake dans le picking combinatoire |
| CR V3.0 | Change Request version 3.0 — architecture 4 jobs picking combinatoire |
| SOR | Shipping Order Request — message ERP entrant, crée un ordre d'expédition |
| RUT | Route — message ERP entrant, définit une tournée transporteur |
| SOF | Shipping Order Fulfilled — message ERP sortant, ordre expédié |
| LOF | Load Order Fulfilled — message ERP sortant, chargement camion terminé |
| ASN | Advanced Shipping Notice — pré-avis de réception avec contenu connu |
| PIE | Station de pesée automatique |
| PDL | Picking Dedicated Location — emplacement dédié picking |
| ASRS | Automatic Storage and Retrieval System — stockage automatique |
| TK | Transstockeur (miniload) |
| TMS | Transport Management System (Galileo chez Mecalux) |
| AD | Application Dictionary — framework métadonnées EasyWMS |
| HU | Handling Unit — palette identifiée par un numéro unique (étiquette RFID) |
| ROR | Reception Order Request — message ERP entrant, crée un ordre de réception |
| ROF | Reception Order Fulfilled — message ERP sortant, ordre de réception clôturé |
| REF | Reception Fulfilled — message ERP sortant, réception individuelle finalisée |
| ITM | Item Master — message ERP entrant, synchronisation des articles/lots |
| STV | Stock Variation — message WMS sortant, notification de variation de stock |
| STR | Stock Request — message ERP entrant, demande changement statut/propriétaire/article |
| STC | Stock Confirmation — message WMS sortant, confirmation changement statut |
| PCK | Passage Conteneur Client — message WMS sortant [CUSTOM], info passage en conteneur client |
| LOC | Location — message WMS sortant [CUSTOM], info emplacement de stockage |
| MOV | Movement — message WMS sortant [CUSTOM], info déplacement stock entre palettes |
| CHG | Change — message ERP entrant [CUSTOM], changement article ou propriétaire |
| ERR | Error — message WMS sortant, erreur d'importation de message |
| MAG01 | Magasin automatique Limagrain — 4 allées TK |
| NIMP15 | Type palette vide — US 100×120 conforme ISPM15 |
| FERT | Produit fini (type article SAP) |
| ZSIZ | Semi-fini calibré (type article SAP) — déclenche ajustement poids au PIE |
| NAV | Navette — convoyeur de transfert entre zones |
| TE | Table d'Entrée — station d'entrée vers l'ASRS |
| TS | Table de Sortie — station de sortie depuis l'ASRS |
| ET | Table intermédiaire (Estación de Transferencia) |
| REAC | Poste de reconditionnement |
| TP | Table de Préparation — emplacement sur un îlot de travail |
| PK | Poste de travail (Picking station) |
| L&F | Lost & Found — emplacement virtuel pour conteneurs perdus |
| GNA | Generic Network Adapter — service communication ERP ↔ EasyWMS |
| SCR | Stock Count Request — message ERP entrant, demande image de stock |
| WSC | Warehouse Stock Confirmation — message WMS sortant, confirmation image de stock |
| COR | Count Order Request — message ERP entrant, demande d'inventaire |
| F9 | Statut de stock « Sacs sales » — applicable au retour client |
| B6 | Statut de stock « Non conforme » — applicable au retour client |
| WF02 | Code site Limagrain dans l'interface ERP |
| PROFIL_STANDARD | Profil logistique articles classiques (code produit + propriétaire + description + destination) |
| PROFIL_PALETTE | Profil logistique palettes bois vides |
| ItemCode | Champ EasyWMS contenant le code lot SAP (= clé article WMS) |
| Bag/Pal | Nombre de sacs par palette (= ContainerQty dans ITM) |
| DESADV | Type message SAP pour livraison fournisseur/intersite (utilisé dans ROR) |
| ORDRSP | Type message SAP pour retour client (utilisé dans ROR) |
| vassist | Virtual assistant — outil SmartUI pour configurer les modes de postes de travail |
| WfAction | Workflow Action — bouton custom dans la workstation (ex. réappro palettes vides) |
| ZPL | Zebra Programming Language — format requis pour imprimantes étiquettes RFID |
| QUAI_TEMPORAIRE | Quai fictif par défaut assigné aux OS, accessible par toutes les images de quai |
| QUAI_RECERTIF | Quai virtuel destination des palettes en recertification (route via PK) |
| CstData | Custom Data — données transmises à Galileo (ex: programme filmage, commande impression) |
| STOP | Numéro d'arrêt dans une tournée RUT — ordonnance le chargement (inverse de l'ordre de livraison) |
| isCritical | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| isRequired | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| AllowAssignStockExcess | Flag SOR.Line — autorise l'assignation même si le stock dépasse la demande |
| OnStockAdjust | Workflow WMS qui recalcule l'assignation après ajustement de stock au picking |
| StackerCrane_SortTasks_PR | Workflow de tri des tâches de picking par gerbabilité (stack) |
| COF | Count Order Fulfilled — message WMS sortant, confirmation échantillonnage |
| SSCC | Serial Shipping Container Code — identifiant unique palette (étiquette GS1) |
| GS1 | Organisation de normalisation — fournit les plages SSCC |
| CPI | Canal Point d'Intégration SAP — middleware traitement messages (volumétrie WSC) |
| Z-Bag | Sacs vides (emballage) — stockés en ASRS pour livraison client uniquement |
| SingleReceipt | Paramètre ROR : true = pas de reliquat WMS (une seule réception par ordre) |
| AutoReleaseDate | Date de libération automatique d'un SOR/RUT (PlannedShippingDate - 48h) |
| TransactionalLineList | Flag SOR : true = tout ou rien (refus total si une ligne est en erreur) |
| CompleteSorList | Flag RUT : true = SOR absents de la mise à jour sont supprimés |
| ERPReasonCode | Code motif ERP (ex: ZSC1) transmis dans les messages de variation stock |
| OutboundClassCode | Classification du type de sortie : PRODUCTION, RECERTIFICATION, CLIENT |
| IsSlave | Flag conteneur LOF : true = palette support (pas le stock directement) |
| QUAI_RECERTIFICATION | Quai fictif assigné aux SOR de recertification dans le message ERP |
| PARKING | Emplacement fictif d'attente camion — quai par défaut avant assignation réelle |
| CST_DockStationsWorkloadForView | Entité custom affichant l'occupation des quais (réceptions + tournées + plaques) |
| InboundClassCode | Code de classe de préavis de réception — contrôle de cohérence à la création réception |
| PALETTE_US | Type de support virtuel créé lors de la déclaration image de quai |
| HORS TOLERANCE | Verrou support posé au PIE si écart de poids détecté (hors retour) — palette admise en ASRS |
| ECART RETOUR | Verrou support posé au PIE si écart de poids sur un retour client — palette rejetée |
| FILMAGES | Paramètre WMS contenant la liste des programmes de filmage (`code;libellé|…`) |
| CstAtt02 (support) | Flag Big Bag sur le support (`true`/`false`) — set au poste de travail réception |
| CstAtt03 (support) | Flag anoxie sur le support (`true`) — set au poste de travail réception |
| CstAtt05 (support) | Programme de filmage (`0`, `A`, `B`…) — set au poste de travail réception |
| AI (GS1) | Application Identifier — préfixe numérique dans un QR Code GS1 identifiant le type de donnée |
| MODES_PKxx | Paramètre SmartUI définissant les modes autorisés + priorité pour un PK (`MODE;PRIO\|…`) |
| PK_ADJACENT | Paramètre SmartUI listant les paires de postes adjacents (`PK01;PK02\|…`) |
| PK_BIGBAG | Paramètre définissant quels PK autorisent les big-bags (P5, P6 avec palan) |
| Mega Job | Job unique « chef d'orchestre » des assignations de tâches vers les PK ([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) |
| DESTINATION_PRODUCTION | Paramètre du job LIM-71 — code du buffer d'entrée production pour les tâches AGV |
| CstAtt04 (support) | Type de réception du support : "ASN" = production, sinon = fournisseur/intersite/retour |
| CstAtt06 (support) | Marqueur de traitement du job LIM-71 — contient la destination après traitement |
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots retour client |
| EV_RETURN | Champ réponse API SAP : "X" = lot valide |
| ET_BATCH | Tableau réponse API SAP : lots autorisés avec MATNR, CHARG, BATCH_OFF, EV_DEPLOY |
| EV_DEPLOY | Champ ET_BATCH : "X" = lot autorisé pour la réception retour |
| CstAtt11 (support) | Marqueur de rangement ASRS pour retour client — `true` une fois le support rangé, jamais remis à false |
| CstAtt01 (réception) | Flag clôture retour en cours — `true` = en attente de rangement ASRS complet |
| CstAtt01 (OE) | Flag hors tolérance — `true` = bloque auto-close OE et ROF, affichage rouge |
| AutoCloseReception | Paramètre WMS : `true` = clôture auto de la réception quand conditions custom remplies |
| AutoCloseInboundOrder | Paramètre WMS : `true` = auto-clôture OE à 100 % ou dans tolérance (ROF envoyé) |
| Reception_Close_PR_V2 | Workflow custom de clôture de réception — gère condition retour (A) et tolérance par ligne (B) |
| NON RANGEE | Valeur zone de stockage dans le REF pour supports non encore rangés en ASRS (fournisseur/intersite uniquement) |
| Mini Job | Sous-workflow du Mega Job — exécute l'assignation effective pour un type de tâche |
| LOC.SEND | Transaction custom WMS déclenchée par le job LOC — signal au GNA pour générer le message LOC |
| BOO (script) | Script Boo exécuté par le GNA — contient la logique métier d'agrégation et formatage des messages |
| SAP-CPI | SAP Cloud Platform Integration — middleware cloud SAP réceptionnant les messages WMS via API REST |
| ATHInboundMessage | Endpoint unique SAP-CPI recevant tous les messages WMS (`/http/ATHInboundMessage`) |
| MessageSAP | Code de routage CPI (ATH201=LOC, ATH202=LOF, ATH214=batch, ATH215=REF Supplier, ATH217=REF Return) |
| CstAtt20 (REF) | Type de préavis de réception (Supplier/Return) — set par REF01Observer pour routage CPI |
| CPI_AUTH_URL | Clé config GNA — URL du serveur d'authentification OAuth SAP |
| CPI_ENDPOINT_URL | Clé config GNA — endpoint unique SAP-CPI |
| VBELN | Code livraison sortante SAP — champ LOC pour ACTION=P (= SorCode côté WMS) |
| POSNR | Ligne de livraison sortante SAP — champ LOC pour ACTION=P |
| ASRS1..4 / ASRS34 | Codes zones SAP correspondant aux TK1-4 pour le message LOC |
| PK_TRANSPORTEUR_MESSAGERIE | Paramètre par transporteur — contient le code PK assigné aux commandes Messagerie de ce transporteur |
| MAX_NB_BUFFER_PK | Paramètre de capacité buffer par PK (valeur par défaut : 3) |
| ES_X | Zone d'attente (buffer) devant les postes de sortie — stockage temporaire des palettes en attente de séquençage |
| TaskCreatedEvent | Événement WMS déclenché à la création d'une tâche — utilisé pour le séquençage TK→PS |
| OutboundOrderReleasedEvent | Événement WMS déclenché au (re)lancement d'un OS — utilisé pour le séquençage TK→PS |
| PC | Palette Complète — palette d'expédition sans besoin de picking |
| PP | Palette de Picking — palette mère qui part au PK pour prélèvement |
| PF | Palette Fille — palette sortie du picking, retour ASRS |
| Défrag client custom | Custom LIM-87 : défrag shipping par tournée quand quai non assigné — éligibilité tout-ou-rien au niveau RUT |
| Stacker crane tri multi-TK | Custom LIM-88 : override WF tri stacker crane pour analyser les STOP sur tous les TK (pattern Bardinet) |
| Line.CstAtt | Numéro de séquence (entier) sur chaque tâche de picking — définit l'ordre de sortie ASRS. Ex-aequo possibles |
| OS.CstAtt | Flag booléen sur l'OS : `false` = séquences non calculées (stacker_crane bloqué), `true` = prêt |
| CONTROLE_TRAITEMENT_COMMERCIAL | Paramètre WMS : `false` = pas de séparation par traitement commercial sur les palettes filles (désactivé V1.1) |
| Bag/pal (pro rata) | Méthode de calcul de remplissage palette : chaque sac = 1/Bag_pal de son lot. Additif, gère les multi-lots |
| MAX_PRELOAD_PAR_PK | Nombre max de palettes pré-chargées en buffer ES par PK (défaut : 3) |
| SEUIL_RECENTRAGE_PF | Nombre min de PICKING_DIRECT restants pour déclencher un recentrage AGV de la PF au centre |
| Ping-pong | Optimisation picking : alternance des palettes sources entre TABLE_GAUCHE et TABLE_DROITE quand la PF est au centre |
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale avec glossaire de base |
| 2026-05-05 | Arthur | Ajout DESADV, ORDRSP, vassist, WfAction, ZPL |
| 2026-05-05 | Arthur | Ajout QUAI_TEMPORAIRE, QUAI_RECERTIF, CstData, STOP, isCritical, isRequired, AllowAssignStockExcess, OnStockAdjust, StackerCrane_SortTasks_PR |
| 2026-05-06 | Arthur | Ajout COF, SSCC, GS1, CPI, Z-Bag, SingleReceipt, AutoReleaseDate, TransactionalLineList, CompleteSorList, ERPReasonCode, OutboundClassCode, IsSlave, QUAI_RECERTIFICATION (CR consolidé) |
| 2026-05-06 | Arthur | Ajout PARKING, CST_DockStationsWorkloadForView, InboundClassCode, PALETTE_US (LIM-62/63/64/65) |
| 2026-05-12 | Arthur | Ajout HORS TOLERANCE, ECART RETOUR, FILMAGES, CstAtt02/03/05 support, AI GS1 (LIM-66/67/68) |
| 2026-05-12 | Arthur | Ajout MODES_PKxx, PK_ADJACENT, PK_BIGBAG, Mega Job, DESTINATION_PRODUCTION, CstAtt04/06 support, SAP_LOT_VERIFY_URL, EV_RETURN, ET_BATCH, EV_DEPLOY (LIM-69/70/71/72) |
| 2026-05-12 | Arthur | Ajout CstAtt11 support, CstAtt01 réception/OE, AutoCloseReception, AutoCloseInboundOrder, Reception_Close_PR_V2, NON RANGEE, Mini Job (LIM-73/74) |
| 2026-05-12 | Arthur | Ajout LOC.SEND, BOO, SAP-CPI, ATHInboundMessage, MessageSAP, CstAtt20 REF, CPI_AUTH_URL, CPI_ENDPOINT_URL, VBELN, POSNR, ASRS1..4/ASRS34 (LIM-76/89) |
| 2026-05-12 | Arthur | Ajout PK_TRANSPORTEUR_MESSAGERIE, MAX_NB_BUFFER_PK, ES_X, TaskCreatedEvent, OutboundOrderReleasedEvent (LIM-80/82/84) |
| 2026-05-12 | Arthur | Ajout PC, PP, PF, Défrag client custom, Stacker crane tri multi-TK (LIM-85/87/88) |
| 2026-05-12 | Arthur | Ajout Line.CstAtt, OS.CstAtt, CONTROLE_TRAITEMENT_COMMERCIAL, Bag/pal pro rata, MAX_PRELOAD_PAR_PK, SEUIL_RECENTRAGE_PF, Ping-pong (specs V1.0/V1.1 + réu. 11/05) |
wiki/limagrain/.fuse_hidden000000690000002d
+96
View File
@@ -0,0 +1,96 @@
---
title: "Wiki Limagrain — Table des matières"
tags: [index, limagrain]
status: draft
last_updated: 2026-05-12
---
# Wiki Limagrain — Table des matières
> **Périmètre** : ce wiki documente les spécificités projet Limagrain par rapport
> au standard EasyWMS. Pour les concepts génériques, se référer au
> [wiki standard](../_index.md).
## Sections
### 01 — Inbound
- [Vue d'ensemble](01-inbound/_index.md)
- [Gestion des camions](01-inbound/gestion-camions.md)
- [Réception fournisseur](01-inbound/reception-fournisseur.md)
- [Réception retour](01-inbound/reception-retour.md)
- [Contrôle qualité réception](01-inbound/controle-qualite-reception.md)
- [Étiquette RFID](01-inbound/etiquette-rfid.md)
- [Flux ERP inbound](01-inbound/flux-erp-inbound.md)
### 02 — Stockage
- [Vue d'ensemble](02-stockage/_index.md)
- [ASRS / Miniload](02-stockage/asrs-miniload.md)
- [Configuration Galileo](02-stockage/galileo-config.md)
- [Stratégies de putaway](02-stockage/putaway-strategies.md)
- [Zones de stockage](02-stockage/zones-stockage.md)
- [Défragmentation](02-stockage/defragmentation.md)
- [Processus d'anoxie](02-stockage/processus-anoxie.md)
- [Gestion des palettes vides](02-stockage/palettes-vides.md)
### 03 — Picking
- [Vue d'ensemble](03-picking/_index.md)
- [Picking combinatoire](03-picking/picking-combinatoire.md)
- [Stations de picking](03-picking/stations-picking.md)
- [Job d'assignation PK (Mega Job)](03-picking/job-assignation-pk.md)
- [Séquençage TK → PS](03-picking/sequencage-tk-ps.md)
- [Placement PS → PK (choix de table)](03-picking/placement-ps-pk.md)
- [Waves et groupes](03-picking/waves-groupes.md)
- [Replenishment](03-picking/replenishment.md)
- [Consolidation / Regroupement](03-picking/consolidation-regroupement.md)
- [Échantillonnage](03-picking/echantillonnage.md)
### 04 — Outbound
- [Vue d'ensemble](04-outbound/_index.md)
- [Flux expédition](04-outbound/flux-expedition.md)
- [Shipping Orders](04-outbound/shipping-orders.md)
- [Séquençage shipping par STOP](04-outbound/sequencage-shipping-stop.md)
- [Consolidation et chargement](04-outbound/consolidation-chargement.md)
- [Flux ERP outbound](04-outbound/flux-erp-outbound.md)
### 05 — AGV
- [Vue d'ensemble](05-agv/_index.md)
- [Intégration Still iGo](05-agv/still-igo-integration.md)
- [Stations et routes AGV](05-agv/agv-stations-routes.md)
- [Job réception production → ASRS](05-agv/job-reception-production.md)
- [Job réception fournisseur/retour → PK](05-agv/job-reception-pk.md)
- [Troubleshooting AGV](05-agv/agv-troubleshooting.md)
### 06 — Interface ERP
- [Vue d'ensemble](06-erp-interface/_index.md)
- [Référence messages](06-erp-interface/messages-reference.md)
- [Données principales et stock](06-erp-interface/donnees-principales.md)
- [LOC — Message périodique](06-erp-interface/loc-message-periodique.md)
- [Intégration GNA → SAP-CPI](06-erp-interface/gna-sap-cpi.md)
- [Mapping ERP-WMS](06-erp-interface/mapping-erp-wms.md)
- [Monitoring interface](06-erp-interface/interface-monitoring.md)
### 07 — Administration
- [Vue d'ensemble](07-admin/_index.md)
- [Utilisateurs et groupes](07-admin/utilisateurs-groupes.md)
- [Paramètres projet](07-admin/parametres-projet.md)
- [AD Customs](07-admin/ad-customs.md)
- [Contacts projet](07-admin/contacts-projet.md)
### 08 — Transverse
- [Vue d'ensemble](08-transverse/_index.md)
- [Tickets Jira clés](08-transverse/jira-tickets-cles.md)
- [Décisions architecture](08-transverse/decisions-architecture.md)
- [Questions ouvertes](08-transverse/questions-ouvertes.md)
- [Historique projet](08-transverse/historique-projet.md)
## Ressources
- [Glossaire Limagrain](glossaire-limagrain.md)
wiki/limagrain/01-inbound/.fuse_hidden0000001100000001
+239
View File
@@ -0,0 +1,239 @@
---
title: "Contrôle qualité réception — Vérification poids PIE"
tags: [inbound, PIE, poids, verrou, inventaire, qualité]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-66]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md]
last_updated: 2026-05-12
author: Arthur
---
# Contrôle qualité réception — Vérification poids PIE
> **Résumé** : mécanisme [CUSTOM] de contrôle de poids au passage PIE avec
> calcul de tolérance par type article, application automatique de verrous
> et mise à jour du poids unitaire.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
**tous les processus** (réception production, extérieure, retour, picking,
regroupement, échantillonnage).
## Contrôles au PIE
Le PIE effectue les contrôles suivants :
| Contrôle | Critère de validation |
|----------|----------------------|
| Étiquette RFID | Connue (détectable) |
| Hauteur | ≤ 1900 mm |
| Largeur | ≤ 1100 mm |
| Longueur | ≤ 1300 mm |
| Poids | ≤ 1250 kg |
| État palette bois | Correct (lames TK ne doivent pas toucher le bois, pas de ski manquant) |
> Les erreurs sont configurables par type dans easyS — possibilité
> d'envoyer vers différentes destinations selon le type d'erreur
> (station error type). Exemple : scotch qui dépasse → station de
> reconditionnement, palette vraiment non conforme → rejet complet.
## Formule de calcul du poids
### Étape 1 — Poids des lignes de stock
```
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
```
### Étape 2 — Répartition au prorata entre lignes de stock
Le poids mesuré est réparti au prorata entre les différentes lignes
de stock.
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
(champ « Poids » de la ligne de stock), puis poids conversion ITM
(champ « Poids théorique » de la ligne de stock).
**Formules :**
```
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
Poids réel de la ligne = Poids lignes de stock × Ratio
```
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
Poids mesuré au PIE = 60 kg (hors palette bois).
| Article | Poids théorique | Ratio | Poids réel calculé |
|---------|-----------------|-------|---------------------|
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
| **Total** | 50 kg | 100 % | **60 kg** |
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
unitaire mesuré :
```
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
```
| Donnée | Champ WMS |
|--------|-----------|
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
| Poids réel pesé (total) | Champ standard « poids balance » du support |
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
> précédente), c'est ce poids unitaire qui est utilisé dans les calculs
> de ratio à l'étape 2 — à la place du poids théorique ITM.
> **Mise à jour du stock : OUI** — le poids calculé est stocké dans
> CstAtt01 de la ligne de stock.
> **Mise à jour de l'ITM : NON** — le poids théorique de la fiche
> article reste inchangé. Raison : le poids varie en fonction de la
> production (début/fin de prod), chaque pesée est unique.
> Le poids est quand même appliqué et recalculé, même en cas de
> blocage (verrou).
## Vérification de la tolérance et blocage
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
revue de code.
### [CUSTOM] Palettes mono-référence
**Condition de blocage** : si l'écart de poids correspond à un écart
d'une ligne de stock (article manquant ou en trop → écart ≥ poids
unitaire de l'article) → blocage via verrou sur le **support** (pas sur
le stock) + alerte SmartUI.
### [CUSTOM] Palettes multi-références — seuil d'alerte
Pour les palettes contenant plusieurs articles différents, le système
utilise le **plus petit poids unitaire** comme seuil d'alerte. Si
l'écart total ≥ poids du plus petit article → blocage + alerte.
### Verrous appliqués
Deux verrous possibles selon le flux :
| Verrou | Flux | Comportement post-PIE |
|--------|------|----------------------|
| **HORS TOLERANCE** | Tous sauf retour client | La palette **entre quand même dans l'ASRS** malgré le verrou |
| **ECART RETOUR** | Retour client uniquement | La palette est **refusée et envoyée en rejet** (destination gérée par EasyS) |
### Notification
- Création d'une **notification SmartUI** via le circuit classique de
notifications basé sur un event (pas d'event custom)
- Le verrou est posé sur le **support** (pas sur le stock)
- Notification dédiée au rejet générée dans le cas ECART RETOUR
### Comportement selon le flux (détail)
| Processus | Verrou appliqué | Action |
|-----------|-----------------|--------|
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
Dans tous les cas, le poids est quand même appliqué et recalculé.
### [CUSTOM] Type ZSIZ — Ajustement automatique
Si le type d'article est **ZSIZ** (semi-fini calibré / big-bag), un
message d'ajustement de stock est envoyé vers SAP via **WSC** contenant
le poids réel de la HU, **indépendamment de la tolérance**.
**Gestion du timing avec le REF :**
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
pas encore la palette (REF pas encore envoyé)
- **Solution** : chaque palette présente dans un REF est flaguée dans
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
REF, un event déclenche la transaction
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
à SAP
## Gestion des verrous
### Consultation
Vue « Entrepôt → Verrous conteneur » :
- Verrou appliqué par conteneur
- Date d'application
- Possibilité de débloquer (lever le verrou)
### Impact sur l'expédition
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
avant tout processus suivant (picking, regroupement, échantillonnage).
### [CUSTOM] Dérogation poids
Pour les processus de **regroupement** et **échantillonnage**, si la palette
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
## Post-traitements
- Réception production : **ASO et ASK désactivés**
- Les messages post-PIE ne sont pas générés pour le flux production
## Points d'attention
⚠️ Le contrôle poids s'applique à **chaque** passage PIE — une palette
peut passer le PIE plusieurs fois (réception → picking → restockage).
⚠️ Le poids est porté par le **stock** (CstAtt01 de la ligne), pas par
la fiche article ITM — chaque pesée est unique.
⚠️ Les palettes avec verrou « Réception » sont prioritaires dans
l'assignation de stock pour l'échantillonnage (permet de combiner
recomptage + échantillonnage).
⚠️ Verrou posé sur le **support** (pas sur le stock) — différent du
comportement standard.
⚠️ Pour les palettes multi-références, le seuil d'alerte est le plus
petit poids unitaire parmi toutes les lignes de stock.
## Questions ouvertes
- [ ] Valeurs exactes des tolérances par type article (@Justine)
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : prorata, multi-ref, verrou support, ZSIZ timing |
| 2026-05-12 | Arthur | LIM-66 : verrous HORS TOLERANCE / ECART RETOUR, CstAtt01 poids unitaire, comportement post-PIE |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001300000002
+128
View File
@@ -0,0 +1,128 @@
---
title: "Étiquette support RFID — Format mono-référence"
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-68]
confluence_refs: []
sources: [LIM-68_Etiquette_RFID.md]
last_updated: 2026-05-12
author: Arthur
---
# Étiquette support RFID — Format mono-référence
> **Résumé** : étiquette A5 imprimée lors de la réception
> fournisseur/intersite, contenant les informations du support (code,
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
ses HU (supports) dans le flux de réception fournisseur/intersite.
L'étiquette est imprimée automatiquement à la confirmation de création
du conteneur sur le poste de travail (voir
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
peut aussi être réimprimée depuis le menu principal du poste (action
« Imprimer étiquette »).
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
attente déploiement pour test.
## Format A5 — Contenu de l'étiquette
| N | Champ | Source WMS | Remarque |
|---|-------|-----------|----------|
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
| 2 | Code-barres | Code 128 du code support au format GS1 | |
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
| 5 | Traitement commercial | `ITM.Family.Description` | |
| 6 | Variety print on bag | Tel quel | |
| 7 | — | `ITM.CstAtt03` | |
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
| 10 | Code GTIN | `ITM.CstAtt05` | |
| 11 | Date | — | Vide (date non connue de l'ERP) |
| 12 | QR Code GS1 | Voir section ci-dessous | |
## QR Code GS1
Le QR Code GS1 encode les identifiants suivants :
| AI (Application Identifier) | Contenu | Source |
|------------------------------|---------|--------|
| `00` | Numéro HU (code support) | Code support WMS |
| `01` | Code GTIN | `ITM.CstAtt05` |
| `10` | Lot officiel | Premier Alias de l'article |
| `21` | Lot SAP | `ITM.Code` |
| `37` | Quantité | Quantité déclarée |
> La date de production (AI `11`) a été **supprimée** du QR Code.
## Encodage RFID (ZPL)
L'impression de l'étiquette combine l'impression physique (texte,
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
des commandes **ZPL** (Zebra Programming Language).
### Structure de base
```zpl
^XA
; --- Encodage RFID ---
^RFW,H^FD<données>^FS
; --- Contenu imprimé ---
^FO50,50^ADN,36,20^FD<texte affiché>^FS
^XZ
```
### Commandes ZPL utilisées
| Commande | Rôle |
|----------|------|
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
| `^MMT` | Active le mode RFID sur l'imprimante |
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
### Exemple concret
```zpl
^XA
^MMT
^RS8,,,1
^RFW,A,0,5,3^FDSupport123456789012^FS
^FO30,20^A0N,30,25^FDRapport de support^FS
^XZ
```
## Points d'attention
- L'imprimante doit être **compatible ZPL** avec encodage RFID
(contrainte fournisseur à valider — voir question ouverte dans
[Réception fournisseur](reception-fournisseur.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
4 octets = 20 octets en banque User 3)
- L'étiquette est au format **A5 paysage**
- La date (champ 11) est volontairement vide car non connue de l'ERP
au moment de la réception
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001500000003
+195
View File
@@ -0,0 +1,195 @@
---
title: "Flux ERP inbound — Messages réception"
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Flux ERP inbound — Messages réception
> **Résumé** : catalogue des messages ERP liés aux processus de réception
> chez Limagrain, avec direction, déclencheur et contenu principal.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
Pour les messages d'expédition, voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
## Messages entrants (SAP → EasyWMS)
### ITM — Item Master
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création/modification article dans SAP |
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
> ⚠️ Chez Limagrain, les **lots SAP** sont gérés comme des articles (descendus
> via ITM). L'article Limagrain est un attribut du lot SAP.
### ASN — Advanced Shipping Notice
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création HU avec code SSCC en production |
| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation — permet suppression individuelle en cas d'annulation) |
| Contenu | Numéro HU, article, lot SAP, [CUSTOM] propriétaire Limagrain, statut de stock, quantité (unités de vente) |
| Timing | Envoyé dès création de la HU avec code SSCC |
**Attributs logistiques dans les lignes ASN** :
| Attribut logistique | Champ SAP | Usage |
|---------------------|-----------|-------|
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
| Source | Description produit | Désignation courte SAP |
| Size | Destination (Pays) | Peut changer |
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
statut (champ vide ou absent du JSON).
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
numéro de série.
### ROR — Reception Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
**Types de réception (InboundType)** :
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|-------------|-------|--------------------------|-----------|
| 0 (Fournisseur) | Livraisons DESADV | SupplierCode = "FOURNISSEUR" | Précisée par SAP (override profil) |
| 1 (Retour) | Retours clients ORDRSP | AccountCode = "CLIENT" | Illimitée (ReceiveLessAllowed=true) |
| 3 (Transfert) | Transferts inter-sites | — | 0% (palettes identifiées) |
**Paramètres clés** : SingleReceipt = true (pas de reliquat WMS),
FreeQuantity non nécessaire. Pas de SSCC dans le ROR (récupéré au scan
RFID en réception).
### [CUSTOM] API Lot SAP (retours clients uniquement)
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
| Requête | Lot officiel |
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
## Messages sortants (EasyWMS → SAP)
### REF — Reception Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
| Contrainte | L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF |
| Données | S'appuie sur les données **réelles** (pas théoriques) |
### ROF — Reception Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Validation/clôture de l'ordre d'entrée |
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
| Reliquats | Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat |
| Hors tolérance | ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise) |
### [CUSTOM] LOC — Location
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
| Contenu | Numéro HU, station départ, station arrivée, workzone arrivée, emplacement arrivée |
| Condition | Généré uniquement si stations départ et arrivée sont différentes |
## Diagramme de séquence — Réception production
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant GAL as Galileo/PIE
SAP->>WMS: ITM (article/lot)
Note over SAP,WMS: En amont
SAP->>WMS: ASN (pré-notif HU)
Note over SAP,WMS: À l'expédition source
GAL->>WMS: Event PIE (RFID + poids)
WMS->>WMS: Contrôle poids + rangement
WMS->>GAL: Tâche stockage
GAL->>WMS: End (palette stockée)
WMS->>SAP: LOC (emplacement)
```
## Diagramme de séquence — Réception extérieure
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo/PIE
SAP->>WMS: ROR (ordre réception)
WMS->>PK: Palette sur poste
PK->>WMS: Déclaration contenu
WMS->>GAL: Tâche évacuation → PIE
GAL->>WMS: Event PIE
WMS->>WMS: Contrôle + rangement
GAL->>WMS: End (stockée)
WMS->>SAP: LOC
PK->>WMS: Clôture réception
WMS->>SAP: REF (avec emplacements)
WMS->>SAP: ROF
```
## Points d'attention
⚠️ Le message REF est retardé jusqu'à validation PIE de tous les conteneurs
(peut prendre du temps si file d'attente PIE longue).
⚠️ Le message LOC n'est pas standard — c'est un [CUSTOM] spécifique
Limagrain pour traçabilité emplacement dans SAP.
⚠️ Les modifications dans les master data ne doivent **pas** être faites
directement dans EasyWMS (risque d'écrasement par prochain ITM).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) — depuis CR consolidé ERP |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001700000004
+348
View File
@@ -0,0 +1,348 @@
---
title: "Gestion des camions — Arrivée, quais et déclaration image de quai"
tags: [inbound, camion, quai, TRF, image-de-quai, étiquette, SmartUI]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65]
confluence_refs: []
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
last_updated: 2026-05-06
author: Arthur
---
# Gestion des camions — Arrivée, quais et déclaration image de quai
> **Résumé** : flux complet depuis l'arrivée physique d'un camion jusqu'à la
> déclaration des palettes sur une image de quai (poumon de réception). Couvre
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
> TRF de déclaration et l'impression d'étiquettes support.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Le standard prévoit la création manuelle de réceptions et leur association à
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
> déclaration des palettes sur les images de quai.
## Contexte projet
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
orientés via un affichage extérieur. Après déchargement physique, un cariste
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
qu'après cette déclaration que les AGV viennent récupérer les palettes.
Ce processus est commun à tous les types de réception (production, extérieure,
retour). Les flux spécifiques de chaque type sont documentés dans les pages
dédiées : [Réception fournisseur](reception-fournisseur.md),
[Réception retour](reception-retour.md).
## Flux fonctionnel global
```mermaid
sequenceDiagram
participant CH as Chauffeur
participant AQ as Agent de quai
participant SM as SmartUI
participant AFF as Affichage extérieur
participant CAR as Cariste (TRF)
participant WMS as EasyWMS
participant AGV as AGV
CH->>AQ: Annonce arrivée camion
AQ->>SM: Crée réception + saisie plaque
SM->>SM: Vérifie classes OE identiques
AQ->>SM: Assigne quai (ou PARKING)
SM->>AFF: Mise à jour affichage (WS)
AFF->>CH: Plaque + quai assigné
CH->>CH: Se gare au quai indiqué
CH->>CAR: Déchargement physique
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
CAR->>CAR: TRF > Réceptions > Image de quai
CAR->>WMS: Déclare nb palettes, poumon, position
WMS->>WMS: Crée palettes virtuelles PALETTE_US
WMS-->>CAR: Impression étiquettes (si type Autre)
AGV->>AGV: Récupère palettes sur image de quai
```
## Étape 1 — Annonce du camion (LIM-62)
### Création de la réception
L'agent de quai accède à la vue **Ordre d'entrée > Réceptions** dans SmartUI.
Il crée une nouvelle réception en saisissant :
- **Plaque d'immatriculation** (champ "Camion", ex-"Document") — non
obligatoire à la création, peut être renseignée après coup
- **Destination** : `PARKING` (quai fictif d'attente) par défaut, ou un quai
réel si disponible
- **Ordres d'entrée** : sélection des OE du camion
### Contrôle de classe
> **Règle** : il est interdit de créer une réception mélangeant des OE de
> classes de préavis de réception différentes (`InboundClassCode`).
Si l'utilisateur sélectionne des OE de classes différentes, un message
d'erreur bloque la création :
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
> classes de préavis de réception différentes"*
Ce contrôle est implémenté dans le `VAssistCreateReceptionOE` (steps 2 et 3)
et dans la vue des ordres d'entrées. L'exception compare le `InboundClassCode`
de chaque OE sélectionné au premier de la liste.
## Étape 2 — Assignation du quai (LIM-62)
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
assigne un quai réel.
### Règles d'assignation
- Le quai et l'image de quai sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
libération
- Modification possible a posteriori
### Tableau d'occupation des quais
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
réceptions, tournées et OS associés avec les plaques correspondantes :
| Quai | Réceptions / Camions |
|------|----------------------|
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
| QUAI_01 | |
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
| ... | |
Ce tableau est aussi disponible dans le `VAssistReceptionAssignDock` (step 1
utilise l'entité `CST_DockStationsWorkloadForView` au lieu de `Station`).
## Étape 3 — Affichage chauffeur (LIM-63)
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
sur le parking les quais assignés avec les plaques d'immatriculation.
### Spécifications
- Afficher uniquement les quais avec des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
- Afficher les plaques (champ "Camion" / Document)
> **Référence technique** : dialogue EasyBuilder, cf. [documentation
> Mecalux](https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md)
## Étape 4 — Déclaration image de quai via TRF (LIM-64)
Après déchargement physique, le cariste déclare les palettes via un menu TRF
dédié **Réceptions > Image de quai**.
### Règle de déchargement physique
Le cariste doit décharger en commençant par l'emplacement le **plus éloigné
du quai** en suivant un ordre précis. Cela permet d'identifier les
emplacements occupés pour les AGV.
### Workflow 7 écrans
Le parcours d'écrans dépend du type de réception :
- **Production** : écrans 1, 3, 4, 5, 7
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
#### Écran 1 — Type de réception
Choix parmi :
- Production
- Autres (fournisseur, intersite, retours, etc.)
- Pile de palette
Échap : retour menu.
#### Écran 2 — Sélection de la réception
Uniquement si type = **Autres**. L'opérateur choisit la réception concernée.
Échap : retour écran 1.
#### Écran 3 — Nombre de palettes
Prompt : « Nombre de palettes de la réception »
Validation :
- Nombre entre 1 et 26 inclus
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
Message d'erreur explicatif si invalide. Échap : retour écran 2.
#### Écran 4 — Choix image de quai (poumon)
Le workflow liste tous les poumons liés aux quais (réception + expédition)
puis filtre :
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
tâches de shipping en destination
- Exclure les poumons pleins (supports = capacité)
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
dernier conteneur
> **Double check** : au moment du choix effectif, les vérifications sont
> refaites — entre l'affichage de la liste et la sélection, la réalité a pu
> changer.
Échap : retour écran 3.
#### Écran 5 — Sous-emplacement de départ
Prompt : « Sous-emplacement de la première palette de la réception »
Validation :
- Nombre valide
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
palettes déclaré) doivent être **vides**
Exemple : si des palettes d'une autre réception occupent la position 5, et
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
position 5 est occupée.
Échap : retour écran 4.
#### Écran 6 — Présence de big-bags
Uniquement si type = **Autres**.
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
Boutons OUI / NON. L'information est conservée pour la suite du flux.
Échap : retour écran 4.
#### Écran 7 — Validation et création
Récapitulatif affiché :
- Image de quai
- Type de réception
- Nombre de palettes
- Sous-emplacement de départ
- Présence de big-bags (si applicable)
À la validation :
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
sous-emplacements consécutifs à partir de la position de départ
2. **Séquence spéciale** : 18 caractères commençant par `8`
(ex : `800000000000000001`, `800000000000000002`, etc.)
— cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
par palette déclarée (format LIM-65)
Échap : retour écran 5. Après validation : retour écran 2.
> **Validation de sécurité** : si le poumon ou la position de départ est
> devenu indisponible entre l'écran 5 et la validation, un message d'erreur
> est affiché. Idem si la réception sélectionnée a été supprimée entre-temps.
## Étiquette support image de quai (LIM-65)
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
(pas pour la production).
| Champ | Contenu |
|-------|---------|
| CODE | Code du support (séquence 8xxx) |
| RECEPTION | Code de la réception |
| DATE | Date d'impression |
| EMPL. | Sous-emplacement du poumon |
| QR Code | Code du support |
## Implémentation technique (AD customs)
### Entités
| Entité | Usage |
|--------|-------|
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
### Queries
| Query | Entité cible |
|-------|-------------|
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
### Vues modifiées
| Vue | Modification |
|-----|-------------|
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
### Ressources i18n
| Code | FR | EN |
|------|----|----|
| `CST_Reception_MultiClassError` | Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes | Can't create reception with inbound orders with different inbound order class |
| `CST_Prop_Reception_Document` | Camion | Truck |
| `CST_Prop_Station_Workload` | Assignations / Camions | Assignations / Trucks |
| `CST_Reception_DockWorkload_Panel_Title` | Occupation des quais | Docks workload |
> **Note** : toutes les ressources custom sont préfixées `CST_` (convention
> Mecalux France validée lors de la revue de code).
### Revue de code
- **05/03/2026** — Vincent Charvet : implémentation initiale
([`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166))
- **06/03/2026** — Nicolas Chabanis : revue non valide (préfixes ressources,
commentaire `//Custom end` manquant, Column Span, titre colonne)
- **09/03/2026** — Nicolas Chabanis : **revue validée**
## Points d'attention
- La plaque du camion n'est **pas obligatoire** à la création de la réception
— elle peut être renseignée après coup (confirmé 09/03/2026)
- Le déchargement doit respecter l'ordre : emplacement le plus éloigné
d'abord, sinon les AGV ne peuvent pas identifier correctement les positions
occupées
- La capacité maximale d'un poumon est de **26 emplacements**
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
(elles arrivent déjà étiquetées via ASN)
- Le double-check de disponibilité du poumon au moment du choix est
**critique** pour éviter les collisions entre opérateurs simultanés
- Les séquences de supports virtuels commencent par `8` et font 18 caractères
— ne pas confondre avec les séquences SSCC standard
## Questions ouvertes
- [ ] Gestion TRF si AGV pas prêts au démarrage — lié aussi à la déclaration
image de quai (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à valider
avec le client (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001900000005
+601
View File
@@ -0,0 +1,601 @@
---
title: "Réception fournisseur — Production et extérieures/intersites"
tags: [inbound, réception, production, ASN, ROR, PIE, clôture, REF, ROF]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-67, LIM-73]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
last_updated: 2026-05-12
author: Arthur
---
# Réception fournisseur — Production et extérieures/intersites
> **Résumé** : deux flux de réception distincts chez Limagrain — production
> (directe ASRS via ASN) et extérieures/intersites (passage poste de travail
> via ROR). Le déchargement camion est une étape commune.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
1. **Réception depuis la production** (flux majoritaire)
2. **Réceptions extérieures / transferts intersites**
Le troisième type (retours client) est couvert dans
[Réception retour](reception-retour.md).
## Étape commune — Arrivée et déclaration du camion
> **Page dédiée** : le flux complet d'arrivée camion, d'assignation de quai,
> d'affichage chauffeur et de déclaration image de quai via TRF est documenté
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
> Ce qui suit est un résumé.
### [CUSTOM] Réservation image de quai
1. Camion arrive → agent de quai crée une **réception** dans la vue
« Ordre d'entrée > Réceptions » (SmartUI)
2. Saisie de la **plaque d'immatriculation** et de la **destination** :
« PARKING » par défaut (quai fictif d'attente) ou quai réel si disponible
3. Sélection des OE (ordres d'entrée) concernés — chaque OE est flagué
via un CstAtt
4. Agent consulte la disponibilité des quais via un graphique dans la vue
des réceptions et assigne un quai réel
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
**Contraintes d'assignation image de quai :**
- Quai et image de quai **réservés** dès la sélection — réutilisation possible
si place restante (gestion manuelle)
- Blocage si flux différent (ex : expédition en cours sur ce quai)
- Blocage si l'image de quai a des supports associés à un OS (expédition)
ou inversement
- Si aucun quai disponible → attente de libération
- Il faut empêcher de créer une réception avec des OE de **classes de
préavis différentes** (message d'erreur bloquant)
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
### Déchargement physique
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
- Permet d'identifier précisément les emplacements occupés pour les AGV
### [CUSTOM] Déclaration sur l'image de quai
Menu TRF custom : Réception > Images de quai > Déclaration
**Séquence commune :**
1. Scan de l'image de quai
2. Choix du type de réception (Production / Fournisseur / Retour client /
Palettes vides)
3. Saisie du nombre de palettes + emplacement de départ
4. Association à la réception (auto pour Production via CstAtt « ASN »,
sélection manuelle de l'OE pour les autres)
5. Prompt big-bag (Oui/Non) — sauté pour Production
6. Écran de validation
7. Création des supports dans le WMS
**Pour les réceptions extérieures/retours client :**
- Impression d'une **étiquette par support** à coller sur la palette
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
- Vérification capacité image de quai
### Création tâches de mouvement AGV
- EasyWMS indique **point de prise** et **point de dépose** uniquement
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
- Pour réceptions nécessitant un poste : assignation automatique selon
contraintes déclarées (mode, big-bag, distance la plus courte)
- Assignation manuelle également possible
- Si aucun poste disponible → tâche en attente
### Libérations
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
de palettes dessus (vérification via supports présents)
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
---
## Flux 1 — Réception depuis la production
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Buffer
participant PIE_01
participant ASRS
Cariste->>Quai/Poumon: Déchargement
Note over Quai/Poumon: Supports virtuels créés
AGV->>Buffer: Transport support virtuel
Buffer->>PIE_01: Convoyeur entrée production
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
alt PIE OK
PIE_01->>ASRS: Stockage (stratégie rangement)
else PIE NOK
PIE_01->>Cariste: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
2. Déplacement AGV → entrée production (via supports virtuels)
3. Passage PIE (suppression support virtuel + validation palette ASN)
4. Stockage ou rejet
5. Libération quai / image de quai
### 1) [CUSTOM] Pré-notification ASN
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
depuis l'ancien magasin). Contenu :
- Numéro unique HU
- Article / Lot SAP
- [CUSTOM] Propriétaire Limagrain
- Statut de stock
- Quantité (unités de vente)
Batch possible : jusqu'à **500 conteneurs par message ASN**.
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
> L'étiquette est collée sur la housse.
### 2) [CUSTOM] Supports virtuels et déplacement AGV
**Principe des supports virtuels :**
- Création de supports « virtuels » identiques à de vrais supports mais
avec une **séquence différente (8000)** pour les identifier
- La flotte AGV déplace la palette fictive jusqu'au PIE
- Le tracking s'effectue avec le support virtuel sur le premier convoyeur
**Destination** : entrée production (convoyeur vers ASRS). L'AGV dépose
sur un **buffer d'entrée** (type POUMON MINILOAD AD) — jamais directement
sur le PIE.
**Suppression du support virtuel :**
- Basée sur le fonctionnement standard des routes AGV
- Surveillance des **containerMovedEvent**
- Filtre : type palette ASN + destination type PIE → suppression du
support virtuel (séquence 8000)
### [CUSTOM] Redirection si entrée production saturée
En cas de blocage long terme sur l'entrée production :
- **Solution standard** : système de routes avec distances — route
principale distance 1, routes secondaires distance 2
- On ferme le PIE de production → le WMS redirige automatiquement vers
les autres entrées disponibles
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
proche de l'entrée)
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
> configuration easyS qui téléportent automatiquement les palettes.
### 3) Passage au PIE et création palette ASN
**Séquence au PIE :**
1. Fin d'ordre AGV au PIE → suppression du support virtuel
(via containerMovedEvent)
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
3. Le ratio poids s'effectue au niveau de l'article
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
RFID connue (ASN). Voir
[Contrôle qualité réception](controle-qualite-reception.md) pour le
détail des contrôles PIE et la répartition du poids.
**PIE OK :**
- [CUSTOM] Aucun message ASO généré
- [CUSTOM] Vérification poids — tolérance par type article, verrou
« Réception » sur le **support** si écart > seuil
- Mise à jour CstAtt01 de la ligne de stock (poids unitaire calculé)
- [CUSTOM] Si type article ZSIZ → message ajustement stock vers SAP
via WSC (poids réel HU) — voir
[Contrôle qualité réception](controle-qualite-reception.md) pour
la gestion du timing avec le REF
- Stratégie de rangement appliquée
- Réservation canal optimale selon nb palettes ASN restantes
**PIE NOK :**
- Rejet standard — plus besoin d'étiquette spécifique
- Palette dirigée automatiquement vers un **poumon au sol** (zone de
rejet)
- **Notification SmartUI** envoyée aux opérateurs
- Opérateur se rend physiquement à la zone de rejet pour corriger
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
RENVOI » et crée une tâche vers un poumon dédié
- [CUSTOM] Aucun message ASK généré
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
travail d'origine)
---
## Flux 2 — Réceptions extérieures / transferts intersites
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Poste PK
participant Filmeuse
participant PIE_02/03
participant ASRS
Cariste->>Quai/Poumon: Déchargement
AGV->>Poste PK: Transport vers poste de travail
Poste PK->>Poste PK: Traitement réception
AGV->>Filmeuse: Évacuation (filmage si demandé)
Filmeuse->>PIE_02/03: Table d'entrée
PIE_02/03->>PIE_02/03: Contrôles
alt PIE OK
PIE_02/03->>ASRS: Stockage
else PIE NOK
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai
2. Déplacement AGV → poste de travail
3. Traitement au poste de travail (constitution mono-ref + déclaration)
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
5. Passage PIE
6. Stockage ou rejet
7. Clôture de la réception
8. Libération quai / image de quai
### 1) Notification ROR
Message **ROR** de SAP → EasyWMS :
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
contenir N livraisons)
- Articles / Lots SAP / Quantités (en unités de vente)
- Pas de création de lignes autorisée
- Tolérance quantité : **0 %** pour intersites (palettes déjà
identifiées), paramétrable **par ligne ROR** pour extérieures
(uniquement en dépassement %)
- `IsSingleReceipt = true` — le WMS ne gère pas de reliquats
automatiques. Si réception incomplète, SAP crée une nouvelle
livraison
- `InboundType = 0` (Standard) pour les deux sous-types
| Élément SAP | Correspondance EasyWMS | Remarque |
|-------------|------------------------|----------|
| Commande d'achat | — | Peut être cadencée en plusieurs livraisons |
| Livraison | 1 ROR | Un ROR = une livraison |
| Camion | N livraisons | Un camion peut contenir plusieurs livraisons |
> Les transferts intersites : le site émetteur est considéré comme un
> fournisseur dans EasyWMS.
### 2) [CUSTOM] Gestion des SSCC
- Les numéros SSCC **ne sont pas envoyés** dans le ROR
(`LineList>ContainerCode`)
- Le SSCC est récupéré au moment du **scan RFID** en réception
- Si SSCC présent sur la palette → conservation lors de la réédition
RFID
- Si SSCC absent → création d'un nouveau SSCC et ré-étiquetage
> Raison : éviter la complexification du process si l'étiquette est
> endommagée.
### 3) [CUSTOM] Déplacement vers poste de travail
Assignation automatique du poste selon :
1. Non bloqué
2. En service
3. Mode autorise la réception
4. Capacité compatible avec la déclaration
5. Distance la plus courte
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
### 4) Constitution palettes mono référence
Les palettes à destination ASRS doivent être **mono référence** autant
que possible. Si multi-référence à l'arrivée :
- Opérateur dispose manuellement une palette vide sur une TP
(non géré par le WMS)
- Tri de marchandise pour constituer des conteneurs mono-ref
> Le process de constitution mono-référence est **standard** — pas de
> développement spécifique.
### 5) [CUSTOM] Traitement au poste de travail
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
attente CDP.
Les opérateurs utilisent le mode **Tâches automatiques** sur PC. Le
code de réception est récupéré automatiquement via le `CstAtt08` du
conteneur présent sur le poste.
**Affichage fournisseur** : sur **tous les écrans** du process,
afficher `"Fournisseur: CODE - NOM"`.
#### a) Confirmation de création support (Big Bag)
Si le conteneur scanné est un **conteneur virtuel** de réception, un
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
- Ligne `"BIG BAG : NON"` (état initial)
- Bouton **"BIG BAG ON"** → toggle vers `"BIG BAG : OUI"` / **"BIG BAG
OFF"**
- Valeur `true`/`false` stockée dans **CstAtt02** du support
- Impression automatique d'une **étiquette RFID** dès confirmation —
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
#### b) Menu principal du poste
Écran central avec 5 actions — les informations du support actuel sont
toujours affichées à droite. Après chaque action, retour à ce menu.
| Action | Description |
|--------|-------------|
| **Ajouter stock** | Sélection article, lot, quantité (écrans standard). Afficher quantité attendue + UdM sans pré-remplir le prompt. Statut de stock affiché mais **non modifiable** (boutons masqués). Écrans date fin de statut et commentaire **skippés**. Pour l'anoxie : set **CstAtt03** du support à `true` |
| **Nouveau support** | Scan emplacement, confirmation de création (retour à l'étape a). Le nouveau conteneur devient le support actif |
| **Changer de support** | Scan du code support à sélectionner comme support actif |
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
#### c) Action « Terminer »
**Vérification fermeture réception** : si le conteneur actuel est le
**dernier** de la réception (nombre de conteneurs virtuels avec
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
`CstAtt10 = true`), proposer la fermeture de la réception avec
uniquement l'option confirmer.
**Sélection du programme de filmage** : dialogue avec liste issue du
paramètre **"FILMAGES"** :
```
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
```
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
**CstAtt05** du support et transmise à Galileo en custom data.
Après validation, une **tâche d'évacuation** est générée pour le
transport AGV du poste de travail vers la table d'entrée.
#### Résumé des CstAtt support (poste de travail)
| CstAtt | Contenu | Set par |
|--------|---------|---------|
| CstAtt02 | Flag Big Bag (`true`/`false`) | Écran confirmation support |
| CstAtt03 | Flag anoxie (`true`) | Action « Ajouter stock » |
| CstAtt05 | Programme de filmage (`0`, `A`, `B`…) | Action « Terminer » |
| CstAtt08 | Code de réception | Déclaration image de quai |
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
### 6) Déplacement AGV → table d'entrée et filmage
- L'AGV déplace le conteneur vers la table d'entrée
- **Gestion du filmage** : le programme de filmage est transmis à
Galileo via custom data au moment du passage. Si le PIE dit NOK →
pas de filmage (custom data non transmis). Le filmage ne se fait que
si le PIE valide la palette
### 7) Passage PIE
Identique au flux production (mêmes formules de répartition poids,
mêmes contrôles PIE). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différence en cas de rejet PIE** : la palette est dirigée vers un
**poumon au sol** avec **notification SmartUI** (ancienne approche de
renvoi au poste de travail d'origine abandonnée — risque de blocage
AGV/table/poste). CstAtt du support flagué avec le poste de travail
d'origine.
---
## Clôture des réceptions (extérieures/intersites)
Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) — LOT
1.3.
La clôture concerne uniquement les flux passant par un poste de travail
(extérieures, intersites, retours client). La réception production (ASN)
n'est pas concernée (pas de clôture manuelle).
**Relation réception ↔ OE** : une réception peut servir **plusieurs
OE**, mais un OE est servi par **une seule réception**. Si la réception
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
livraison (donc nouvel OE).
### Paramétrage
- `IsSingleReceipt = true` — une seule réception par OE, pas de
reliquats WMS
- `AutoCloseReception = true` — le WMS clôture automatiquement la
réception quand les conditions custom sont remplies (§ Déclenchement)
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
OE complété à 100 % ou dans la tolérance est auto-clôturé (ROF
envoyé) et auto-archivé (absent de la vue). Les OE en écart hors
tolérance restent ouverts
### Deux niveaux de clôture
| Niveau | Description | Message ERP |
|--------|-------------|-------------|
| Réception | Clôture d'une livraison physique | REF |
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
### Déclenchement de l'auto-close (LIM-73 §1.1)
L'auto-close de la réception se déclenche — et le bouton « Fermer
réception » n'est visible — que si les deux conditions suivantes sont
**simultanément** remplies :
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
n'est présente (plus de palettes à venir de l'image de quai)
2. **ET** :
- **Si Workstation** : au plus **1** palette réelle au PK avec
`CstAtt10 = true` (la dernière en cours)
- **Si Vue Réception** : **aucune** palette réelle au PK avec
`CstAtt10 = true`
Si au moins une ligne est **hors tolérance**, un message d'avertissement
s'affiche : « La réception a été clôturée mais les quantités reçues sont
hors tolérance, voir avec le manager pour réguler les quantités attendues
puis fermer l'ordre d'entrée ».
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
Le workflow standard de clôture est modifié pour deux comportements :
**Partie A — Condition retours** : si la réception est de type retour
client, la clôture et le REF sont différés jusqu'au rangement ASRS
complet. Voir [Réception retour — Clôture](reception-retour.md) pour le
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
**Partie B — Pose CstAtt01 OE hors tolérance** : à la clôture effective,
pour chaque **ligne article hors tolérance** (en plus ou en moins) :
1. Rechercher le **premier OE** (FirstOrDefault) parmi les OE associés
contenant ce combo code article / lot
2. Poser `CstAtt01 = true` sur cet OE
> En pratique un combo code article/lot n'est jamais partagé entre
> plusieurs OE d'une même réception — le FirstOrDefault est
> déterministe.
Les OE flaggés ne se clôturent pas automatiquement (ROF bloqué) et
s'affichent en rouge dans la vue (voir § Clôture des OE ci-dessous).
### Contenu du REF (custom)
Un seul REF est envoyé par réception (pas de REF progressif, car
`IsSingleReceipt = true`). Contenu :
- Numéros de conteneurs réceptionnés
- Lignes de stocks associées
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
du support) :
- Fournisseur / intersite : si un support se trouve hors de l'ASRS
au moment du REF → valeur **"NON RANGEE"**
- Retour client : ce cas ne se produit pas (REF conditionné au
rangement complet — voir [Réception retour](reception-retour.md))
- [CUSTOM] Attributs stock remontés : code produit SAP, code
propriétaire réel, description courte, pays de destination, lot SAP
**LOC** : envoyé sur delta de 5 min (palette créée/déplacée/supprimée).
Le LOC ne prend pas en compte les palettes liées à une réception non
fermée (standard dans le WSC forké — développement dédié
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
| Situation OE | Clôture | ROF | Affichage vue OE |
|--------------|---------|-----|------------------|
| Reçu = attendu | Auto-close | Envoi auto | Auto-archivé → absent |
| Écart dans la tolérance | Auto-close (custom) | Envoi auto | Auto-archivé → absent |
| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** — bouton restreint |
**Visibilité du bouton « Clôturer l'OE »** :
- OE sans écart ou dans la tolérance : accessible à tous (standard),
mais auto-archivé donc invisible
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
**uniquement pour les profils non-opérateurs** (admin, manager, chef
d'équipe). Masqué pour les opérateurs standards
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
clôture manuellement l'OE → ROF envoyé.
### Réception excédentaire (> % autorisé)
Le WMS bloque. Solutions possibles :
| Solution | Description |
|----------|-------------|
| Modifier la commande | Message ROR UPSERT depuis SAP |
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
## Points d'attention
⚠️ En cas de blocage long terme sur l'entrée production, le WMS
redirige automatiquement vers les autres entrées via le système de
routes avec distances (fermeture du PIE de production).
⚠️ Les palettes issues de réceptions extérieures/intersites reçoivent
**automatiquement** le flag « A anoxier ».
⚠️ L'impression étiquettes réception au déchargement n'est possible que
pour les réceptions extérieures et retours clients (pas production).
⚠️ Les rejets PIE sont dirigés vers un **poumon au sol** avec
notification SmartUI (ancienne approche de renvoi au PK abandonnée).
⚠️ Le process de constitution mono-référence est **standard** (pas de
développement spécifique).
⚠️ Filmage : transmis à Galileo via custom data — uniquement si PIE OK.
## Questions ouvertes
- [x] Programme de filmage — interface définie dans LIM-67 : paramètre
FILMAGES avec format `code;libellé|…`, stocké dans CstAtt05
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
ZPL (@Théo)
- [ ] Position étiquette image de quai (devant/côté) — à valider
avec le client (@Justine)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids (@Nicolas)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
les palettes impossibles à réceptionner ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
| 2026-05-12 | Arthur | LIM-67 : workflow complet poste de travail, Big Bag CstAtt02, anoxie CstAtt03, filmage CstAtt05/FILMAGES, fermeture réception |
| 2026-05-12 | Arthur | LIM-73 : réécriture complète section clôture — AutoCloseReception=true, conditions CstAtt08/CstAtt10, Reception_Close_PR_V2 (tolérance par ligne, CstAtt01 OE hors tolérance), REF custom (zone stockage / "NON RANGEE"), clôture OE (tableau 3 cas, bouton restreint non-opérateur), impact LOC (LIM-76) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira | 2026 |
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF) | 2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001b00000006
+400
View File
@@ -0,0 +1,400 @@
---
title: "Réception retour commandes clients"
tags: [inbound, réception, retour, client, API, lot]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
last_updated: 2026-05-12
author: Arthur
---
# Réception retour commandes clients
> **Résumé** : processus spécifique de réception des retours client, avec
> interrogation API SAP pour validation lot, et déclaration enrichie sur
> poste de travail.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les retours client suivent un flux similaire aux réceptions extérieures
(passage poste de travail obligatoire) mais avec des particularités :
- `InboundType = 1` (Return) — vs 0 (Standard) pour les autres flux
- Création de lignes autorisée (article non attendu possible)
- Tolérance illimitée : profil de réception par défaut configuré en
« illimité » sur tous les articles
- `ReceiveLessAllowed = true` — réception partielle toujours autorisée
- Interrogation API SAP pour valider le lot officiel
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
## Process complet de réception retour client
| Étape | Description | Ticket |
|-------|-------------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | — |
| 8 | Libération quai / image de quai | — |
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
du déchargement camion et des déclarations initiales
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
flux fournisseur au PK).
## Notification ROR
Message ROR de SAP (type ORDRSP) avec :
- Numéro de réception
- Articles / Lots / Quantités attendues
- Codes articles **génériques** (codes uniques avec nomenclature
précise, pas réutilisables — assure la traçabilité)
**Différence clé** : cette réception **autorise la création de lignes**.
Limagrain peut recevoir un article non présent dans le ROR initial.
Un article inconnu de la base EasyWMS = ROR refusé. Un article connu
mais non prévu dans le retour = accepté (tolérance illimitée).
## [CUSTOM] Identification lot — Interrogation API SAP
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
### Rappel : structure des articles chez Limagrain
Chez Limagrain, le **code article WMS = lot SAP** (cf.
[Données principales](../06-erp-interface/donnees-principales.md)).
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
complète), et le code produit est un attribut stocké en CstAtt du stock.
Le **lot officiel** est l'alias de l'article dans le WMS.
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
SAP d'envoyer la fiche article complète.
### Logique de vérification
```mermaid
flowchart TD
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
B -- Oui --> C{Vendu par Limagrain ?}
B -- Non --> D[Appel API SAP]
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
E --> F{ITM reçu via API WMS ?}
F -- Oui --> C
F -- Non / Timeout --> G{Tentative < 5 ?}
G -- Oui --> H[Bouton Réessayer]
H --> D
G -- Non --> I[Erreur finale :<br/>contacter responsable]
C -- Oui --> J{Plusieurs articles ?}
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
M --> L
```
### Appel API SAP — Vérification du lot officiel
L'appel API REST est fait **directement depuis le workflow** (pas via
GNA). Il sert à notifier SAP que le WMS a besoin de la fiche article.
**Séquence d'échange :**
```mermaid
sequenceDiagram
participant WF as WMS (workflow)
participant SAP
WF->>SAP: POST /api/v1/lot/verify
Note over WF,SAP: Payload : IV_LGNUM, IV_BATCH_OFF,<br/>IV_RETURN
SAP-->>WF: Réponse JSON (EV_RETURN, ET_BATCH)
alt EV_RETURN = "X" (OK)
SAP->>WF: POST ApplicationService/ITM
Note over SAP,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
WF->>WF: Vérif : product code existe en base ?
alt OK
WF->>WF: Continuer
else Absent
WF->>WF: Proposer réessayer
end
else EV_RETURN ≠ "X" (NOK)
WF->>WF: Erreur immédiate
end
```
**Payload de requête :**
```json
POST /api/v1/lot/verify
{
"IV_LGNUM": "WF02",
"IV_MATNR": "",
"IV_CHARG": "",
"IV_BATCH_OFF": "<lot officiel à vérifier>",
"IV_RETURN": "<code du retour client (OE)>"
}
```
- `IV_LGNUM` : toujours "WF02"
- `IV_BATCH_OFF` : numéro de lot officiel scanné
- `IV_RETURN` : code du retour client (ordre d'entrée)
- Les autres champs restent vides
**Payload de réponse (champs clés) :**
| Champ | Description |
|-------|-------------|
| `EV_RETURN` | "X" = lot valide, sinon invalide |
| `ET_RETURN[]` | Tableau de messages (TYPE, MESSAGE, etc.) |
| `ET_BATCH[]` | Lots autorisés : `MATNR` (code article SAP), `CHARG` (lot SAP), `BATCH_OFF` (lot officiel), `EV_DEPLOY` ("X" = autorisé) |
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
pour l'opérateur.
### Écran d'attente pendant la réception de l'ITM
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
l'ITM. Pendant cette attente :
- **Message** : "Vérification du lot en cours..."
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
un **alias correspondant au lot officiel** existe en base
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
- **Timeout** : 1 minute maximum par tentative
- **Nombre maximum de tentatives** : 5
| Tentative | Comportement en cas de timeout |
|-----------|-------------------------------|
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
### Choix du code lot (multi-résultat)
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
un (filtrage par pays d'origine).
Si un **seul résultat** → sélection automatique, pas de dialogue.
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
physiquement présent sur la palette.
**Gestion dans le REF :** le code générique envoyé dans le ROR est
remplacé par le vrai code lot dans le REF (custom).
## Déclaration au poste de travail (LIM-72)
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
différences :
| # | Étape | Différence vs fournisseur (LIM-67) |
|---|-------|------------------------------------|
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
| 9 | Validation → évacuation AGV | Identique |
### Statut de stock — Modifiable
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
verrouillé (boutons masqués), dans le flux retour client :
- Les **boutons de changement de statut sont visibles** et fonctionnels
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
Non conforme, etc.)
- Les écrans de **date de fin de statut** et **commentaire** suivent
le comportement standard (non skippés contrairement au fournisseur)
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
(non conforme) — assignables uniquement dans ce processus
### Tolérance illimitée
- **Article non prévu** dans le retour → accepté (création de ligne
autorisée)
- **Quantité supérieure** au prévu → acceptée
- **Quantité inférieure** au prévu → acceptée (réception fermée
manuellement)
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
> **abandonné** — remplacé par un message d'avertissement si le poste
> adjacent est déjà ouvert (voir
> [Stations picking](../03-picking/stations-picking.md)).
## Constitution palettes mono référence
Obligation de constituer des palettes **mono référence** avant stockage.
Si la palette retour est multi-ref :
- Opérateur appelle une palette vide sur une TP disponible
- Tri de marchandise
## Calcul poids et passage PIE
Identique aux réceptions extérieures (mêmes formules de répartition
prorata, mêmes contrôles). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différences pour les retours client :**
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
pour les autres flux) — verrou posé sur le **support** (pas sur
le stock)
- Action requise en cas d'écart : **recomptage du nombre de sacs**
- Rejet PIE : dirigé vers **poumon au sol** + notification SmartUI
(ancienne approche de renvoi au PK abandonnée)
## Clôture — Spécificités retour client (LIM-73)
Le mécanisme général de clôture (déclenchement auto-close, tolérance par
ligne, CstAtt01 OE hors tolérance, clôture OE) est documenté dans
[Réception fournisseur — Clôture](reception-fournisseur.md). Cette
section décrit le **delta retour client** : le REF est conditionné au
rangement ASRS complet.
### Contexte métier
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
ne doit être envoyé que lorsque **tous les supports** de la réception
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
notamment PIE).
Pour les autres types de réception (fournisseur / intersite), le REF est
émis à la clôture de la réception, quelle que soit la position des
supports.
### CstAtt11 — Marqueur de rangement ASRS
À chaque fin de tâche de rangement dans l'ASRS :
- Vérifier si le support provient d'une réception de type **retour**
- Si oui → `CstAtt11 = true` sur le support
- Sinon → aucune action
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
condition de clôture reste satisfaisable même si une palette a déjà été
expédiée entre-temps.
### Statut « Clôture en cours »
Dans la vue des réceptions, le statut visuel est piloté par le
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
| CstAtt01 réception | État | Affichage |
|---------------------|------|-----------|
| null / vide | En attente | Standard |
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
Pour les réceptions non-retour, CstAtt01 de la réception n'est pas
utilisé (affichage standard).
### Adaptation Reception_Close_PR_V2 — Partie A (retours)
- **Si non-retour** → clôture immédiate, génération REF (standard)
- **Si retour** :
- Vérifier que **tous les supports** ont `CstAtt11 = true`
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
générer REF
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
« Clôture en cours »). Le WF est rejoué à chaque event
_task finished_ sur un support de la réception
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
> effectuée.
### Zone de stockage dans le REF
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
### Récapitulatif CstAtt clôture retour
| CstAtt | Entité | Rôle |
|--------|--------|------|
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours |
| CstAtt11 | Support (palette réelle) | `true` quand le support retour a fini son rangement ASRS — **introduit par LIM-73** |
| CstAtt01 | Réception (retour uniquement) | `true` = clôture en attente de rangement complet — **introduit par LIM-73** |
| CstAtt01 | OE (ordre d'entrée) | `true` = hors tolérance, bloque auto-close et ROF — **introduit par LIM-73** |
## Points d'attention
⚠️ Le changement de statut de stock (F9, B6) n'est autorisé sur poste de
travail **que** dans le processus retour client.
⚠️ Un commentaire est associé au statut et remonté dans le message
d'interface ERP.
⚠️ Les palettes retour reçoivent automatiquement le flag « A anoxier »
(risque contamination).
⚠️ L'API lot SAP est une interrogation synchrone — timeout 1 min,
refresh 5s, 5 essais max avant erreur finale.
⚠️ Les codes articles génériques du ROR doivent être **uniques** (pas
réutilisables) pour assurer la traçabilité.
## Paramètres spécifiques retour client
Les paramètres existants de LIM-67 sont réutilisés (FILMAGES, etc.).
Paramètres additionnels pour l'API SAP :
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots | _(à définir)_ |
| SAP_LOT_VERIFY_TIMEOUT | Timeout d'un appel API SAP (en secondes) | 60 |
| SAP_LOT_VERIFY_MAX_RETRIES | Nombre maximum de tentatives | 5 |
| SAP_LOT_VERIFY_REFRESH | Intervalle de refresh écran d'attente (en secondes) | 5 |
## Questions ouvertes
- [x] ~~Format exact du message API lot SAP (requête/réponse)~~ — documenté
via LIM-72 (payload POST /api/v1/lot/verify + réponse ET_BATCH)
- [ ] URL exacte de l'endpoint SAP (SAP_LOT_VERIFY_URL) à définir
(@Fabien)
- [ ] Vérification "vendu par Limagrain" : est-ce le champ EV_DEPLOY
dans ET_BATCH ou un autre champ de la réponse ? (@Fabien)
- [ ] Gestion du token SAP : récupération avant chaque appel ou clé
privée ? Mécanisme à préciser (@Fabien)
- [ ] Cas du product code manquant en base après réponse OK :
combien de temps attendre avant de proposer Réessayer ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
| 2026-05-12 | Arthur | Flux complet PK retour (LIM-72) : process 8 étapes, API SAP détaillée (payload, séquence, écran attente, retry), statut stock modifiable, tolérance illimitée, paramètres SAP_LOT_VERIFY_*, choix article multi-résultat |
| 2026-05-12 | Arthur | LIM-73 : clôture retour client — REF conditionné au rangement ASRS complet (CstAtt11), statut « Clôture en cours » (CstAtt01 réception, jaune), Reception_Close_PR_V2 partie A (event replay), CstAtt01 OE hors tolérance, récap CstAtt clôture |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) | Ticket Jira | 2026 |
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (flux fournisseur PK) | 2026 |
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira (étiquette RFID) | 2026 |
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF retours) | 2026 |
wiki/limagrain/01-inbound/.fuse_hidden0000001d00000007
+60
View File
@@ -0,0 +1,60 @@
---
title: "Inbound — Vue d'ensemble"
tags: [inbound, index]
status: draft
last_updated: 2026-05-12
---
# Inbound — Vue d'ensemble
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
> messages ERP inbound.
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
> [Order Inbound](../../concepts/order-inbound.md)
## Pages de cette section
- [Gestion des camions](gestion-camions.md) — arrivée, quais, déclaration image de quai
- [Réception fournisseur](reception-fournisseur.md)
- [Réception retour](reception-retour.md)
- [Contrôle qualité réception](controle-qualite-reception.md)
- [Étiquette RFID](etiquette-rfid.md) — format A5, QR GS1, encodage ZPL
- [Flux ERP inbound](flux-erp-inbound.md)
## Vue synthétique du flux inbound Limagrain
```mermaid
flowchart TD
CAM[Camion arrive] --> PARK[Quai Parking]
PARK --> QUAI[Assignation quai + image]
QUAI --> DECH[Déchargement sur poumon]
DECH --> DECL{Déclaration type}
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
PROD --> PIE1[PIE_01 contrôle]
VIDE --> PIE1
EXT --> PK[Traitement sur poste PK]
PK --> AGV2[AGV → Entrée postes PIE_02/03]
AGV2 --> PIE2[PIE_02/03 contrôle]
PIE1 -->|OK| ASRS[Stockage ASRS]
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
PIE2 -->|OK| ASRS
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
ASRS --> LOC[Message LOC → SAP]
PK --> REF[Clôture → REF + ROF → SAP]
```
## 3 types de réception
| Type | Message ERP | Passage poste | Entrée PIE |
|------|-------------|---------------|------------|
| Production | ASN | Non | PIE_01 (côté quais) |
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
wiki/limagrain/01-inbound/_index.md
+60
View File
@@ -0,0 +1,60 @@
---
title: "Inbound — Vue d'ensemble"
tags: [inbound, index]
status: draft
last_updated: 2026-05-12
---
# Inbound — Vue d'ensemble
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
> messages ERP inbound.
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
> [Order Inbound](../../concepts/order-inbound.md)
## Pages de cette section
- [Gestion des camions](gestion-camions.md) — arrivée, quais, déclaration image de quai
- [Réception fournisseur](reception-fournisseur.md)
- [Réception retour](reception-retour.md)
- [Contrôle qualité réception](controle-qualite-reception.md)
- [Étiquette RFID](etiquette-rfid.md) — format A5, QR GS1, encodage ZPL
- [Flux ERP inbound](flux-erp-inbound.md)
## Vue synthétique du flux inbound Limagrain
```mermaid
flowchart TD
CAM[Camion arrive] --> PARK[Quai Parking]
PARK --> QUAI[Assignation quai + image]
QUAI --> DECH[Déchargement sur poumon]
DECH --> DECL{Déclaration type}
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
PROD --> PIE1[PIE_01 contrôle]
VIDE --> PIE1
EXT --> PK[Traitement sur poste PK]
PK --> AGV2[AGV → Entrée postes PIE_02/03]
AGV2 --> PIE2[PIE_02/03 contrôle]
PIE1 -->|OK| ASRS[Stockage ASRS]
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
PIE2 -->|OK| ASRS
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
ASRS --> LOC[Message LOC → SAP]
PK --> REF[Clôture → REF + ROF → SAP]
```
## 3 types de réception
| Type | Message ERP | Passage poste | Entrée PIE |
|------|-------------|---------------|------------|
| Production | ASN | Non | PIE_01 (côté quais) |
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
wiki/limagrain/01-inbound/controle-qualite-reception.md
+268
View File
@@ -0,0 +1,268 @@
---
title: "Contrôle qualité réception — Vérification poids PIE"
tags: [inbound, PIE, poids, verrou, inventaire, qualité]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-66]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md, wiki-update-poids-PIE-tolerance.md]
last_updated: 2026-05-13
author: Arthur
---
# Contrôle qualité réception — Vérification poids PIE
> **Résumé** : mécanisme [CUSTOM] de contrôle de poids au passage PIE avec
> calcul de tolérance par type article, application automatique de verrous
> et mise à jour du poids unitaire.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
**tous les processus** (réception production, extérieure, retour, picking,
regroupement, échantillonnage).
## Contrôles au PIE
Le PIE effectue les contrôles suivants :
| Contrôle | Critère de validation |
|----------|----------------------|
| Étiquette RFID | Connue (détectable) |
| Hauteur | ≤ 1900 mm |
| Largeur | ≤ 1100 mm |
| Longueur | ≤ 1300 mm |
| Poids | ≤ 1250 kg |
| État palette bois | Correct (lames TK ne doivent pas toucher le bois, pas de ski manquant) |
> Les erreurs sont configurables par type dans easyS — possibilité
> d'envoyer vers différentes destinations selon le type d'erreur
> (station error type). Exemple : scotch qui dépasse → station de
> reconditionnement, palette vraiment non conforme → rejet complet.
## Formule de calcul du poids
### Étape 1 — Poids des lignes de stock
```
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
```
### Étape 2 — Répartition au prorata entre lignes de stock
Le poids mesuré est réparti au prorata entre les différentes lignes
de stock.
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
(champ « Poids » de la ligne de stock), puis poids conversion ITM
(champ « Poids théorique » de la ligne de stock).
**Formules :**
```
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
Poids réel de la ligne = Poids lignes de stock × Ratio
```
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
Poids mesuré au PIE = 60 kg (hors palette bois).
| Article | Poids théorique | Ratio | Poids réel calculé |
|---------|-----------------|-------|---------------------|
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
| **Total** | 50 kg | 100 % | **60 kg** |
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
unitaire mesuré :
```
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
```
| Donnée | Champ WMS |
|--------|-----------|
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
| Poids réel pesé (total) | Champ standard « poids balance » du support |
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
> précédente), c'est ce poids unitaire qui est utilisé comme référence
> pour **tous les calculs du passage PIE** — ratio (étape 2) **et**
> seuil de tolérance (vérification ci-dessous) — à la place du poids
> théorique ITM.
> **Mise à jour du stock : OUI** — le poids calculé est stocké dans
> CstAtt01 de la ligne de stock.
> **Mise à jour de l'ITM : NON** — le poids théorique de la fiche
> article reste inchangé. Raison : le poids varie en fonction de la
> production (début/fin de prod), chaque pesée est unique.
> Le poids est quand même appliqué et recalculé, même en cas de
> blocage (verrou).
## Vérification de la tolérance et blocage
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
revue de code.
### Poids de référence pour le seuil de tolérance
Le "poids unitaire de l'article" utilisé comme seuil de tolérance suit
la même règle de priorité que le ratio :
| Situation | Poids de référence utilisé |
|-----------|---------------------------|
| CstAtt01 renseigné (pesée précédente) | **CstAtt01** (poids unitaire mesuré) |
| CstAtt01 vide (premier passage PIE) | **Poids ITM** (conversion article) |
**Conséquence sur les passages successifs** : après un premier passage
PIE qui recalibre le poids unitaire (ex. ITM = 10 kg, mesuré = 30 kg),
le seuil de tolérance au passage suivant sera basé sur 30 kg (CstAtt01).
Un écart de 20 kg (2 unités au poids ITM d'origine) ne déclenchera pas
de blocage car il reste inférieur à 1 unité au poids recalibré (30 kg).
> Validé par le client (échange Justine BEUTIN / Olivier, mai 2026).
### [CUSTOM] Palettes mono-référence
**Condition de blocage** : si l'écart de poids correspond à un écart
d'une ligne de stock (article manquant ou en trop → écart ≥ poids
unitaire de référence, cf. tableau ci-dessus) → blocage via verrou sur
le **support** (pas sur le stock) + alerte SmartUI.
### [CUSTOM] Palettes multi-références — seuil d'alerte
Pour les palettes contenant plusieurs articles différents, le système
utilise le **plus petit poids unitaire de référence** (CstAtt01 si
renseigné, sinon ITM, par ligne) comme seuil d'alerte. Si l'écart
total ≥ ce plus petit poids → blocage + alerte.
### Verrous appliqués
Deux verrous possibles selon le flux :
| Verrou | Flux | Comportement post-PIE |
|--------|------|----------------------|
| **HORS TOLERANCE** | Tous sauf retour client | La palette **entre quand même dans l'ASRS** malgré le verrou |
| **ECART RETOUR** | Retour client uniquement | La palette est **refusée et envoyée en rejet** (destination gérée par EasyS) |
### Notification
- Création d'une **notification SmartUI** via le circuit classique de
notifications basé sur un event (pas d'event custom)
- Le verrou est posé sur le **support** (pas sur le stock)
- Notification dédiée au rejet générée dans le cas ECART RETOUR
### Comportement selon le flux (détail)
| Processus | Verrou appliqué | Action |
|-----------|-----------------|--------|
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
Dans tous les cas, le poids est quand même appliqué et recalculé.
### [CUSTOM] Type ZSIZ — Ajustement automatique
Si le type d'article est **ZSIZ** (semi-fini calibré / big-bag), un
message d'ajustement de stock est envoyé vers SAP via **WSC** contenant
le poids réel de la HU, **indépendamment de la tolérance**.
**Gestion du timing avec le REF :**
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
pas encore la palette (REF pas encore envoyé)
- **Solution** : chaque palette présente dans un REF est flaguée dans
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
REF, un event déclenche la transaction
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
à SAP
## Gestion des verrous
### Consultation
Vue « Entrepôt → Verrous conteneur » :
- Verrou appliqué par conteneur
- Date d'application
- Possibilité de débloquer (lever le verrou)
### Impact sur l'expédition
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
avant tout processus suivant (picking, regroupement, échantillonnage).
### [CUSTOM] Dérogation poids
Pour les processus de **regroupement** et **échantillonnage**, si la palette
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
## Post-traitements
- Réception production : **ASO et ASK désactivés**
- Les messages post-PIE ne sont pas générés pour le flux production
## Points d'attention
⚠️ Le contrôle poids s'applique à **chaque** passage PIE — une palette
peut passer le PIE plusieurs fois (réception → picking → restockage).
⚠️ Le poids est porté par le **stock** (CstAtt01 de la ligne), pas par
la fiche article ITM — chaque pesée est unique.
⚠️ Les palettes avec verrou « Réception » sont prioritaires dans
l'assignation de stock pour l'échantillonnage (permet de combiner
recomptage + échantillonnage).
⚠️ Verrou posé sur le **support** (pas sur le stock) — différent du
comportement standard.
⚠️ Pour les palettes multi-références, le seuil d'alerte est le plus
petit poids unitaire parmi toutes les lignes de stock.
⚠️ Après un passage PIE qui recalibre fortement le poids (ex. ITM
10 kg → CstAtt01 30 kg), le seuil de tolérance au passage suivant
est proportionnellement plus large. C'est le comportement attendu :
chaque pesée fait foi pour la suivante.
## Questions ouvertes
- [x] Tolérances : le seuil est dynamique (CstAtt01 > ITM), validé par
le client (mai 2026). Pas de valeur fixe par type article.
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : prorata, multi-ref, verrou support, ZSIZ timing |
| 2026-05-12 | Arthur | LIM-66 : verrous HORS TOLERANCE / ECART RETOUR, CstAtt01 poids unitaire, comportement post-PIE |
| 2026-05-13 | Arthur | Clarification tolérance CstAtt01 > ITM pour passages PIE successifs (validation client) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client | mai 2026 |
wiki/limagrain/01-inbound/etiquette-rfid.md
+128
View File
@@ -0,0 +1,128 @@
---
title: "Étiquette support RFID — Format mono-référence"
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-68]
confluence_refs: []
sources: [LIM-68_Etiquette_RFID.md]
last_updated: 2026-05-12
author: Arthur
---
# Étiquette support RFID — Format mono-référence
> **Résumé** : étiquette A5 imprimée lors de la réception
> fournisseur/intersite, contenant les informations du support (code,
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
ses HU (supports) dans le flux de réception fournisseur/intersite.
L'étiquette est imprimée automatiquement à la confirmation de création
du conteneur sur le poste de travail (voir
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
peut aussi être réimprimée depuis le menu principal du poste (action
« Imprimer étiquette »).
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
attente déploiement pour test.
## Format A5 — Contenu de l'étiquette
| N | Champ | Source WMS | Remarque |
|---|-------|-----------|----------|
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
| 2 | Code-barres | Code 128 du code support au format GS1 | |
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
| 5 | Traitement commercial | `ITM.Family.Description` | |
| 6 | Variety print on bag | Tel quel | |
| 7 | — | `ITM.CstAtt03` | |
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
| 10 | Code GTIN | `ITM.CstAtt05` | |
| 11 | Date | — | Vide (date non connue de l'ERP) |
| 12 | QR Code GS1 | Voir section ci-dessous | |
## QR Code GS1
Le QR Code GS1 encode les identifiants suivants :
| AI (Application Identifier) | Contenu | Source |
|------------------------------|---------|--------|
| `00` | Numéro HU (code support) | Code support WMS |
| `01` | Code GTIN | `ITM.CstAtt05` |
| `10` | Lot officiel | Premier Alias de l'article |
| `21` | Lot SAP | `ITM.Code` |
| `37` | Quantité | Quantité déclarée |
> La date de production (AI `11`) a été **supprimée** du QR Code.
## Encodage RFID (ZPL)
L'impression de l'étiquette combine l'impression physique (texte,
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
des commandes **ZPL** (Zebra Programming Language).
### Structure de base
```zpl
^XA
; --- Encodage RFID ---
^RFW,H^FD<données>^FS
; --- Contenu imprimé ---
^FO50,50^ADN,36,20^FD<texte affiché>^FS
^XZ
```
### Commandes ZPL utilisées
| Commande | Rôle |
|----------|------|
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
| `^MMT` | Active le mode RFID sur l'imprimante |
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
### Exemple concret
```zpl
^XA
^MMT
^RS8,,,1
^RFW,A,0,5,3^FDSupport123456789012^FS
^FO30,20^A0N,30,25^FDRapport de support^FS
^XZ
```
## Points d'attention
- L'imprimante doit être **compatible ZPL** avec encodage RFID
(contrainte fournisseur à valider — voir question ouverte dans
[Réception fournisseur](reception-fournisseur.md))
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
4 octets = 20 octets en banque User 3)
- L'étiquette est au format **A5 paysage**
- La date (champ 11) est volontairement vide car non connue de l'ERP
au moment de la réception
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
wiki/limagrain/01-inbound/flux-erp-inbound.md
+195
View File
@@ -0,0 +1,195 @@
---
title: "Flux ERP inbound — Messages réception"
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Flux ERP inbound — Messages réception
> **Résumé** : catalogue des messages ERP liés aux processus de réception
> chez Limagrain, avec direction, déclencheur et contenu principal.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
Pour les messages d'expédition, voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
## Messages entrants (SAP → EasyWMS)
### ITM — Item Master
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création/modification article dans SAP |
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
> ⚠️ Chez Limagrain, les **lots SAP** sont gérés comme des articles (descendus
> via ITM). L'article Limagrain est un attribut du lot SAP.
### ASN — Advanced Shipping Notice
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création HU avec code SSCC en production |
| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation — permet suppression individuelle en cas d'annulation) |
| Contenu | Numéro HU, article, lot SAP, [CUSTOM] propriétaire Limagrain, statut de stock, quantité (unités de vente) |
| Timing | Envoyé dès création de la HU avec code SSCC |
**Attributs logistiques dans les lignes ASN** :
| Attribut logistique | Champ SAP | Usage |
|---------------------|-----------|-------|
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
| Source | Description produit | Désignation courte SAP |
| Size | Destination (Pays) | Peut changer |
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
statut (champ vide ou absent du JSON).
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
numéro de série.
### ROR — Reception Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
**Types de réception (InboundType)** :
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|-------------|-------|--------------------------|-----------|
| 0 (Fournisseur) | Livraisons DESADV | SupplierCode = "FOURNISSEUR" | Précisée par SAP (override profil) |
| 1 (Retour) | Retours clients ORDRSP | AccountCode = "CLIENT" | Illimitée (ReceiveLessAllowed=true) |
| 3 (Transfert) | Transferts inter-sites | — | 0% (palettes identifiées) |
**Paramètres clés** : SingleReceipt = true (pas de reliquat WMS),
FreeQuantity non nécessaire. Pas de SSCC dans le ROR (récupéré au scan
RFID en réception).
### [CUSTOM] API Lot SAP (retours clients uniquement)
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
| Requête | Lot officiel |
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
## Messages sortants (EasyWMS → SAP)
### REF — Reception Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
| Contrainte | L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF |
| Données | S'appuie sur les données **réelles** (pas théoriques) |
### ROF — Reception Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Validation/clôture de l'ordre d'entrée |
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
| Reliquats | Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat |
| Hors tolérance | ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise) |
### [CUSTOM] LOC — Location
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
| Contenu | Numéro HU, station départ, station arrivée, workzone arrivée, emplacement arrivée |
| Condition | Généré uniquement si stations départ et arrivée sont différentes |
## Diagramme de séquence — Réception production
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant GAL as Galileo/PIE
SAP->>WMS: ITM (article/lot)
Note over SAP,WMS: En amont
SAP->>WMS: ASN (pré-notif HU)
Note over SAP,WMS: À l'expédition source
GAL->>WMS: Event PIE (RFID + poids)
WMS->>WMS: Contrôle poids + rangement
WMS->>GAL: Tâche stockage
GAL->>WMS: End (palette stockée)
WMS->>SAP: LOC (emplacement)
```
## Diagramme de séquence — Réception extérieure
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo/PIE
SAP->>WMS: ROR (ordre réception)
WMS->>PK: Palette sur poste
PK->>WMS: Déclaration contenu
WMS->>GAL: Tâche évacuation → PIE
GAL->>WMS: Event PIE
WMS->>WMS: Contrôle + rangement
GAL->>WMS: End (stockée)
WMS->>SAP: LOC
PK->>WMS: Clôture réception
WMS->>SAP: REF (avec emplacements)
WMS->>SAP: ROF
```
## Points d'attention
⚠️ Le message REF est retardé jusqu'à validation PIE de tous les conteneurs
(peut prendre du temps si file d'attente PIE longue).
⚠️ Le message LOC n'est pas standard — c'est un [CUSTOM] spécifique
Limagrain pour traçabilité emplacement dans SAP.
⚠️ Les modifications dans les master data ne doivent **pas** être faites
directement dans EasyWMS (risque d'écrasement par prochain ITM).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) — depuis CR consolidé ERP |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/01-inbound/gestion-camions.md
+348
View File
@@ -0,0 +1,348 @@
---
title: "Gestion des camions — Arrivée, quais et déclaration image de quai"
tags: [inbound, camion, quai, TRF, image-de-quai, étiquette, SmartUI]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65]
confluence_refs: []
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
last_updated: 2026-05-06
author: Arthur
---
# Gestion des camions — Arrivée, quais et déclaration image de quai
> **Résumé** : flux complet depuis l'arrivée physique d'un camion jusqu'à la
> déclaration des palettes sur une image de quai (poumon de réception). Couvre
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
> TRF de déclaration et l'impression d'étiquettes support.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Le standard prévoit la création manuelle de réceptions et leur association à
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
> déclaration des palettes sur les images de quai.
## Contexte projet
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
orientés via un affichage extérieur. Après déchargement physique, un cariste
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
qu'après cette déclaration que les AGV viennent récupérer les palettes.
Ce processus est commun à tous les types de réception (production, extérieure,
retour). Les flux spécifiques de chaque type sont documentés dans les pages
dédiées : [Réception fournisseur](reception-fournisseur.md),
[Réception retour](reception-retour.md).
## Flux fonctionnel global
```mermaid
sequenceDiagram
participant CH as Chauffeur
participant AQ as Agent de quai
participant SM as SmartUI
participant AFF as Affichage extérieur
participant CAR as Cariste (TRF)
participant WMS as EasyWMS
participant AGV as AGV
CH->>AQ: Annonce arrivée camion
AQ->>SM: Crée réception + saisie plaque
SM->>SM: Vérifie classes OE identiques
AQ->>SM: Assigne quai (ou PARKING)
SM->>AFF: Mise à jour affichage (WS)
AFF->>CH: Plaque + quai assigné
CH->>CH: Se gare au quai indiqué
CH->>CAR: Déchargement physique
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
CAR->>CAR: TRF > Réceptions > Image de quai
CAR->>WMS: Déclare nb palettes, poumon, position
WMS->>WMS: Crée palettes virtuelles PALETTE_US
WMS-->>CAR: Impression étiquettes (si type Autre)
AGV->>AGV: Récupère palettes sur image de quai
```
## Étape 1 — Annonce du camion (LIM-62)
### Création de la réception
L'agent de quai accède à la vue **Ordre d'entrée > Réceptions** dans SmartUI.
Il crée une nouvelle réception en saisissant :
- **Plaque d'immatriculation** (champ "Camion", ex-"Document") — non
obligatoire à la création, peut être renseignée après coup
- **Destination** : `PARKING` (quai fictif d'attente) par défaut, ou un quai
réel si disponible
- **Ordres d'entrée** : sélection des OE du camion
### Contrôle de classe
> **Règle** : il est interdit de créer une réception mélangeant des OE de
> classes de préavis de réception différentes (`InboundClassCode`).
Si l'utilisateur sélectionne des OE de classes différentes, un message
d'erreur bloque la création :
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
> classes de préavis de réception différentes"*
Ce contrôle est implémenté dans le `VAssistCreateReceptionOE` (steps 2 et 3)
et dans la vue des ordres d'entrées. L'exception compare le `InboundClassCode`
de chaque OE sélectionné au premier de la liste.
## Étape 2 — Assignation du quai (LIM-62)
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
assigne un quai réel.
### Règles d'assignation
- Le quai et l'image de quai sont réservés dès la sélection
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
place restante)
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
libération
- Modification possible a posteriori
### Tableau d'occupation des quais
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
réceptions, tournées et OS associés avec les plaques correspondantes :
| Quai | Réceptions / Camions |
|------|----------------------|
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
| QUAI_01 | |
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
| ... | |
Ce tableau est aussi disponible dans le `VAssistReceptionAssignDock` (step 1
utilise l'entité `CST_DockStationsWorkloadForView` au lieu de `Station`).
## Étape 3 — Affichage chauffeur (LIM-63)
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
sur le parking les quais assignés avec les plaques d'immatriculation.
### Spécifications
- Afficher uniquement les quais avec des réceptions ou OS associés
- Prévoir l'affichage de **6 quais + le parking** sans scroll
- Afficher les plaques (champ "Camion" / Document)
> **Référence technique** : dialogue EasyBuilder, cf. [documentation
> Mecalux](https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md)
## Étape 4 — Déclaration image de quai via TRF (LIM-64)
Après déchargement physique, le cariste déclare les palettes via un menu TRF
dédié **Réceptions > Image de quai**.
### Règle de déchargement physique
Le cariste doit décharger en commençant par l'emplacement le **plus éloigné
du quai** en suivant un ordre précis. Cela permet d'identifier les
emplacements occupés pour les AGV.
### Workflow 7 écrans
Le parcours d'écrans dépend du type de réception :
- **Production** : écrans 1, 3, 4, 5, 7
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
#### Écran 1 — Type de réception
Choix parmi :
- Production
- Autres (fournisseur, intersite, retours, etc.)
- Pile de palette
Échap : retour menu.
#### Écran 2 — Sélection de la réception
Uniquement si type = **Autres**. L'opérateur choisit la réception concernée.
Échap : retour écran 1.
#### Écran 3 — Nombre de palettes
Prompt : « Nombre de palettes de la réception »
Validation :
- Nombre entre 1 et 26 inclus
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
Message d'erreur explicatif si invalide. Échap : retour écran 2.
#### Écran 4 — Choix image de quai (poumon)
Le workflow liste tous les poumons liés aux quais (réception + expédition)
puis filtre :
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
tâches de shipping en destination
- Exclure les poumons pleins (supports = capacité)
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
dernier conteneur
> **Double check** : au moment du choix effectif, les vérifications sont
> refaites — entre l'affichage de la liste et la sélection, la réalité a pu
> changer.
Échap : retour écran 3.
#### Écran 5 — Sous-emplacement de départ
Prompt : « Sous-emplacement de la première palette de la réception »
Validation :
- Nombre valide
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
palettes déclaré) doivent être **vides**
Exemple : si des palettes d'une autre réception occupent la position 5, et
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
position 5 est occupée.
Échap : retour écran 4.
#### Écran 6 — Présence de big-bags
Uniquement si type = **Autres**.
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
Boutons OUI / NON. L'information est conservée pour la suite du flux.
Échap : retour écran 4.
#### Écran 7 — Validation et création
Récapitulatif affiché :
- Image de quai
- Type de réception
- Nombre de palettes
- Sous-emplacement de départ
- Présence de big-bags (si applicable)
À la validation :
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
sous-emplacements consécutifs à partir de la position de départ
2. **Séquence spéciale** : 18 caractères commençant par `8`
(ex : `800000000000000001`, `800000000000000002`, etc.)
— cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
par palette déclarée (format LIM-65)
Échap : retour écran 5. Après validation : retour écran 2.
> **Validation de sécurité** : si le poumon ou la position de départ est
> devenu indisponible entre l'écran 5 et la validation, un message d'erreur
> est affiché. Idem si la réception sélectionnée a été supprimée entre-temps.
## Étiquette support image de quai (LIM-65)
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
(pas pour la production).
| Champ | Contenu |
|-------|---------|
| CODE | Code du support (séquence 8xxx) |
| RECEPTION | Code de la réception |
| DATE | Date d'impression |
| EMPL. | Sous-emplacement du poumon |
| QR Code | Code du support |
## Implémentation technique (AD customs)
### Entités
| Entité | Usage |
|--------|-------|
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
### Queries
| Query | Entité cible |
|-------|-------------|
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
### Vues modifiées
| Vue | Modification |
|-----|-------------|
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
### Ressources i18n
| Code | FR | EN |
|------|----|----|
| `CST_Reception_MultiClassError` | Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes | Can't create reception with inbound orders with different inbound order class |
| `CST_Prop_Reception_Document` | Camion | Truck |
| `CST_Prop_Station_Workload` | Assignations / Camions | Assignations / Trucks |
| `CST_Reception_DockWorkload_Panel_Title` | Occupation des quais | Docks workload |
> **Note** : toutes les ressources custom sont préfixées `CST_` (convention
> Mecalux France validée lors de la revue de code).
### Revue de code
- **05/03/2026** — Vincent Charvet : implémentation initiale
([`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166))
- **06/03/2026** — Nicolas Chabanis : revue non valide (préfixes ressources,
commentaire `//Custom end` manquant, Column Span, titre colonne)
- **09/03/2026** — Nicolas Chabanis : **revue validée**
## Points d'attention
- La plaque du camion n'est **pas obligatoire** à la création de la réception
— elle peut être renseignée après coup (confirmé 09/03/2026)
- Le déchargement doit respecter l'ordre : emplacement le plus éloigné
d'abord, sinon les AGV ne peuvent pas identifier correctement les positions
occupées
- La capacité maximale d'un poumon est de **26 emplacements**
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
(elles arrivent déjà étiquetées via ASN)
- Le double-check de disponibilité du poumon au moment du choix est
**critique** pour éviter les collisions entre opérateurs simultanés
- Les séquences de supports virtuels commencent par `8` et font 18 caractères
— ne pas confondre avec les séquences SSCC standard
## Questions ouvertes
- [ ] Gestion TRF si AGV pas prêts au démarrage — lié aussi à la déclaration
image de quai (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à valider
avec le client (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
wiki/limagrain/01-inbound/reception-fournisseur.md
+614
View File
@@ -0,0 +1,614 @@
---
title: "Réception fournisseur — Production et extérieures/intersites"
tags: [inbound, réception, production, ASN, ROR, PIE, clôture, REF, ROF]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-67, LIM-73]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
last_updated: 2026-05-12
author: Arthur
---
# Réception fournisseur — Production et extérieures/intersites
> **Résumé** : deux flux de réception distincts chez Limagrain — production
> (directe ASRS via ASN) et extérieures/intersites (passage poste de travail
> via ROR). Le déchargement camion est une étape commune.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
1. **Réception depuis la production** (flux majoritaire)
2. **Réceptions extérieures / transferts intersites**
Le troisième type (retours client) est couvert dans
[Réception retour](reception-retour.md).
## Étape commune — Arrivée et déclaration du camion
> **Page dédiée** : le flux complet d'arrivée camion, d'assignation de quai,
> d'affichage chauffeur et de déclaration image de quai via TRF est documenté
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
> Ce qui suit est un résumé.
### [CUSTOM] Réservation image de quai
1. Camion arrive → agent de quai crée une **réception** dans la vue
« Ordre d'entrée > Réceptions » (SmartUI)
2. Saisie de la **plaque d'immatriculation** et de la **destination** :
« PARKING » par défaut (quai fictif d'attente) ou quai réel si disponible
3. Sélection des OE (ordres d'entrée) concernés — chaque OE est flagué
via un CstAtt
4. Agent consulte la disponibilité des quais via un graphique dans la vue
des réceptions et assigne un quai réel
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
**Contraintes d'assignation image de quai :**
- Quai et image de quai **réservés** dès la sélection — réutilisation possible
si place restante (gestion manuelle)
- Blocage si flux différent (ex : expédition en cours sur ce quai)
- Blocage si l'image de quai a des supports associés à un OS (expédition)
ou inversement
- Si aucun quai disponible → attente de libération
- Il faut empêcher de créer une réception avec des OE de **classes de
préavis différentes** (message d'erreur bloquant)
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
### Déchargement physique
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
- Permet d'identifier précisément les emplacements occupés pour les AGV
### [CUSTOM] Déclaration sur l'image de quai
Menu TRF custom : Réception > Images de quai > Déclaration
**Séquence commune :**
1. Scan de l'image de quai
2. Choix du type de réception (Production / Fournisseur / Retour client /
Palettes vides)
3. Saisie du nombre de palettes + emplacement de départ
4. Association à la réception (auto pour Production via CstAtt « ASN »,
sélection manuelle de l'OE pour les autres)
5. Prompt big-bag (Oui/Non) — sauté pour Production
6. Écran de validation
7. Création des supports dans le WMS
**Pour les réceptions extérieures/retours client :**
- Impression d'une **étiquette par support** à coller sur la palette
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
- Vérification capacité image de quai
### Création tâches de mouvement AGV
- EasyWMS indique **point de prise** et **point de dépose** uniquement
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
- Pour réceptions nécessitant un poste : assignation automatique selon
contraintes déclarées (mode, big-bag, distance la plus courte)
- Assignation manuelle également possible
- Si aucun poste disponible → tâche en attente
### Libérations
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
de palettes dessus (vérification via supports présents)
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
---
## Flux 1 — Réception depuis la production
### Flux physique
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Buffer
participant PIE_01
participant ASRS
Cariste->>Quai/Poumon: Déchargement
Note over Quai/Poumon: Supports virtuels créés
AGV->>Buffer: Transport support virtuel
Buffer->>PIE_01: Convoyeur entrée production
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
alt PIE OK
PIE_01->>ASRS: Stockage (stratégie rangement)
else PIE NOK
PIE_01->>Cariste: Rejet → poumon au sol + notification
end
```
### Résumé du processus
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
2. Déplacement AGV → entrée production (via supports virtuels)
3. Passage PIE (suppression support virtuel + validation palette ASN)
4. Stockage ou rejet
5. Libération quai / image de quai
### 1) [CUSTOM] Pré-notification ASN
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
depuis l'ancien magasin). Contenu :
- Numéro unique HU
- Article / Lot SAP
- [CUSTOM] Propriétaire Limagrain
- Statut de stock
- Quantité (unités de vente)
Batch possible : jusqu'à **500 conteneurs par message ASN**.
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
> L'étiquette est collée sur la housse.
### 2) [CUSTOM] Supports virtuels et déplacement AGV
**Principe des supports virtuels :**
- Création de supports « virtuels » identiques à de vrais supports mais
avec une **séquence différente (8000)** pour les identifier
- La flotte AGV déplace la palette fictive jusqu'au PIE
- Le tracking s'effectue avec le support virtuel sur le premier convoyeur
**Destination** : entrée production (convoyeur vers ASRS). L'AGV dépose
sur un **buffer d'entrée** (type POUMON MINILOAD AD) — jamais directement
sur le PIE.
**Suppression du support virtuel :**
- Basée sur le fonctionnement standard des routes AGV
- Surveillance des **containerMovedEvent**
- Filtre : type palette ASN + destination type PIE → suppression du
support virtuel (séquence 8000)
### [CUSTOM] Redirection si entrée production saturée
En cas de blocage long terme sur l'entrée production :
- **Solution standard** : système de routes avec distances — route
principale distance 1, routes secondaires distance 2
- On ferme le PIE de production → le WMS redirige automatiquement vers
les autres entrées disponibles
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
proche de l'entrée)
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
> configuration easyS qui téléportent automatiquement les palettes.
### 3) Passage au PIE et création palette ASN
**Séquence au PIE :**
1. Fin d'ordre AGV au PIE → suppression du support virtuel
(via containerMovedEvent)
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
3. Le ratio poids s'effectue au niveau de l'article
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
RFID connue (ASN). Voir
[Contrôle qualité réception](controle-qualite-reception.md) pour le
détail des contrôles PIE et la répartition du poids.
**PIE OK :**
- [CUSTOM] Aucun message ASO généré
- [CUSTOM] Vérification poids — tolérance par type article, verrou
« Réception » sur le **support** si écart > seuil
- Mise à jour CstAtt01 de la ligne de stock (poids unitaire calculé)
- [CUSTOM] Si type article ZSIZ → message ajustement stock vers SAP
via WSC (poids réel HU) — voir
[Contrôle qualité réception](controle-qualite-reception.md) pour
la gestion du timing avec le REF
- Stratégie de rangement appliquée
- Réservation canal optimale selon nb palettes ASN restantes
**PIE NOK :**
- Rejet standard — plus besoin d'étiquette spécifique
- Palette dirigée automatiquement vers un **poumon au sol** (zone de
rejet)
- **Notification SmartUI** envoyée aux opérateurs
- Opérateur se rend physiquement à la zone de rejet pour corriger
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
RENVOI » et crée une tâche vers un poumon dédié
- [CUSTOM] Aucun message ASK généré
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
travail d'origine)
---
## Flux 2 — Réceptions extérieures / transferts intersites
### Flux physique (extérieur)
```mermaid
sequenceDiagram
participant Cariste
participant Quai/Poumon
participant AGV
participant Poste PK
participant Filmeuse
participant PIE_02/03
participant ASRS
Cariste->>Quai/Poumon: Déchargement
AGV->>Poste PK: Transport vers poste de travail
Poste PK->>Poste PK: Traitement réception
AGV->>Filmeuse: Évacuation (filmage si demandé)
Filmeuse->>PIE_02/03: Table d'entrée
PIE_02/03->>PIE_02/03: Contrôles
alt PIE OK
PIE_02/03->>ASRS: Stockage
else PIE NOK
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
end
```
### Résumé du processus (extérieur)
1. Déclaration sur l'image de quai
2. Déplacement AGV → poste de travail
3. Traitement au poste de travail (constitution mono-ref + déclaration)
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
5. Passage PIE
6. Stockage ou rejet
7. Clôture de la réception
8. Libération quai / image de quai
### 1) Notification ROR
Message **ROR** de SAP → EasyWMS :
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
contenir N livraisons)
- Articles / Lots SAP / Quantités (en unités de vente)
- Pas de création de lignes autorisée
- Tolérance quantité : **0 %** pour intersites (palettes déjà
identifiées), paramétrable **par ligne ROR** pour extérieures
(uniquement en dépassement %)
- `IsSingleReceipt = true` — le WMS ne gère pas de reliquats
automatiques. Si réception incomplète, SAP crée une nouvelle
livraison
- `InboundType = 0` (Standard) pour les deux sous-types
| Élément SAP | Correspondance EasyWMS | Remarque |
|-------------|------------------------|----------|
| Commande d'achat | — | Peut être cadencée en plusieurs livraisons |
| Livraison | 1 ROR | Un ROR = une livraison |
| Camion | N livraisons | Un camion peut contenir plusieurs livraisons |
> Les transferts intersites : le site émetteur est considéré comme un
> fournisseur dans EasyWMS.
### 2) [CUSTOM] Gestion des SSCC
- Les numéros SSCC **ne sont pas envoyés** dans le ROR
(`LineList>ContainerCode`)
- Le SSCC est récupéré au moment du **scan RFID** en réception
- Si SSCC présent sur la palette → conservation lors de la réédition
RFID
- Si SSCC absent → création d'un nouveau SSCC et ré-étiquetage
> Raison : éviter la complexification du process si l'étiquette est
> endommagée.
### 3) [CUSTOM] Déplacement vers poste de travail
Assignation automatique du poste selon :
1. Non bloqué
2. En service
3. Mode autorise la réception
4. Capacité compatible avec la déclaration
5. Distance la plus courte
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
### 4) Constitution palettes mono référence
Les palettes à destination ASRS doivent être **mono référence** autant
que possible. Si multi-référence à l'arrivée :
- Opérateur dispose manuellement une palette vide sur une TP
(non géré par le WMS)
- Tri de marchandise pour constituer des conteneurs mono-ref
> Le process de constitution mono-référence est **standard** — pas de
> développement spécifique.
### 5) [CUSTOM] Traitement au poste de travail
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
attente CDP.
Les opérateurs utilisent le mode **Tâches automatiques** sur PC. Le
code de réception est récupéré automatiquement via le `CstAtt08` du
conteneur présent sur le poste.
**Affichage fournisseur** : sur **tous les écrans** du process,
afficher `"Fournisseur: CODE - NOM"`.
#### a) Confirmation de création support (Big Bag)
Si le conteneur scanné est un **conteneur virtuel** de réception, un
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
- Ligne `"BIG BAG : NON"` (état initial)
- Bouton **"BIG BAG ON"** → toggle vers `"BIG BAG : OUI"` / **"BIG BAG
OFF"**
- Valeur `true`/`false` stockée dans **CstAtt02** du support
- Impression automatique d'une **étiquette RFID** dès confirmation —
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
#### b) Menu principal du poste
Écran central avec 5 actions — les informations du support actuel sont
toujours affichées à droite. Après chaque action, retour à ce menu.
| Action | Description |
|--------|-------------|
| **Ajouter stock** | Sélection article, lot, quantité (écrans standard). Afficher quantité attendue + UdM sans pré-remplir le prompt. Statut de stock affiché mais **non modifiable** (boutons masqués). Écrans date fin de statut et commentaire **skippés**. Pour l'anoxie : set **CstAtt03** du support à `true` |
| **Nouveau support** | Scan emplacement, confirmation de création (retour à l'étape a). Le nouveau conteneur devient le support actif |
| **Changer de support** | Scan du code support à sélectionner comme support actif |
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
#### c) Action « Terminer »
**Vérification fermeture réception** : si le conteneur actuel est le
**dernier** de la réception (nombre de conteneurs virtuels avec
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
`CstAtt10 = true`), proposer la fermeture de la réception avec
uniquement l'option confirmer.
**Sélection du programme de filmage** : dialogue avec liste issue du
paramètre **"FILMAGES"** :
```
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
```
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
**CstAtt05** du support et transmise à Galileo en custom data.
Après validation, une **tâche d'évacuation** est générée pour le
transport AGV du poste de travail vers la table d'entrée.
#### Résumé des CstAtt support (poste de travail)
| CstAtt | Contenu | Set par |
|--------|---------|---------|
| CstAtt02 | Flag Big Bag (`true`/`false`) | Écran confirmation support |
| CstAtt03 | Flag anoxie (`true`) | Action « Ajouter stock » |
| CstAtt05 | Programme de filmage (`0`, `A`, `B`…) | Action « Terminer » |
| CstAtt08 | Code de réception | Déclaration image de quai |
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
### 6) Déplacement AGV → table d'entrée et filmage
- L'AGV déplace le conteneur vers la table d'entrée
- **Gestion du filmage** : le programme de filmage est transmis à
Galileo via custom data au moment du passage. Si le PIE dit NOK →
pas de filmage (custom data non transmis). Le filmage ne se fait que
si le PIE valide la palette
### 7) Passage PIE
Identique au flux production (mêmes formules de répartition poids,
mêmes contrôles PIE). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différence en cas de rejet PIE** : la palette est dirigée vers un
**poumon au sol** avec **notification SmartUI** (ancienne approche de
renvoi au poste de travail d'origine abandonnée — risque de blocage
AGV/table/poste). CstAtt du support flagué avec le poste de travail
d'origine.
---
## Clôture des réceptions (extérieures/intersites)
Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) — LOT
1.3.
La clôture concerne uniquement les flux passant par un poste de travail
(extérieures, intersites, retours client). La réception production (ASN)
n'est pas concernée (pas de clôture manuelle).
**Relation réception ↔ OE** : une réception peut servir **plusieurs
OE**, mais un OE est servi par **une seule réception**. Si la réception
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
livraison (donc nouvel OE).
### Paramétrage
- `IsSingleReceipt = true` — une seule réception par OE, pas de
reliquats WMS
- `AutoCloseReception = true` — le WMS clôture automatiquement la
réception quand les conditions custom sont remplies (§ Déclenchement)
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
OE complété à 100 % ou dans la tolérance est auto-clôturé (ROF
envoyé) et auto-archivé (absent de la vue). Les OE en écart hors
tolérance restent ouverts
### Deux niveaux de clôture
| Niveau | Description | Message ERP |
|--------|-------------|-------------|
| Réception | Clôture d'une livraison physique | REF |
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
### Déclenchement de l'auto-close (LIM-73 §1.1)
L'auto-close de la réception se déclenche — et le bouton « Fermer
réception » n'est visible — que si les deux conditions suivantes sont
**simultanément** remplies :
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
n'est présente (plus de palettes à venir de l'image de quai)
2. **ET** :
- **Si Workstation** : au plus **1** palette réelle au PK avec
`CstAtt10 = true` (la dernière en cours)
- **Si Vue Réception** : **aucune** palette réelle au PK avec
`CstAtt10 = true`
Si au moins une ligne est **hors tolérance**, un message d'avertissement
s'affiche : « La réception a été clôturée mais les quantités reçues sont
hors tolérance, voir avec le manager pour réguler les quantités attendues
puis fermer l'ordre d'entrée ».
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
Le workflow standard de clôture est modifié pour deux comportements :
**Partie A — Condition retours** : si la réception est de type retour
client, la clôture et le REF sont différés jusqu'au rangement ASRS
complet. Voir [Réception retour — Clôture](reception-retour.md) pour le
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
**Partie B — Pose CstAtt01 OE hors tolérance** : à la clôture effective,
pour chaque **ligne article hors tolérance** (en plus ou en moins) :
1. Rechercher le **premier OE** (FirstOrDefault) parmi les OE associés
contenant ce combo code article / lot
2. Poser `CstAtt01 = true` sur cet OE
> En pratique un combo code article/lot n'est jamais partagé entre
> plusieurs OE d'une même réception — le FirstOrDefault est
> déterministe.
Les OE flaggés ne se clôturent pas automatiquement (ROF bloqué) et
s'affichent en rouge dans la vue (voir § Clôture des OE ci-dessous).
### Contenu du REF (custom)
Un seul REF est envoyé par réception (pas de REF progressif, car
`IsSingleReceipt = true`). Contenu :
- Numéros de conteneurs réceptionnés
- Lignes de stocks associées
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
du support) :
- Fournisseur / intersite : si un support se trouve hors de l'ASRS
au moment du REF → valeur **"NON RANGEE"**
- Retour client : ce cas ne se produit pas (REF conditionné au
rangement complet — voir [Réception retour](reception-retour.md))
- [CUSTOM] Attributs stock remontés : code produit SAP, code
propriétaire réel, description courte, pays de destination, lot SAP
**LOC** : envoyé sur delta de 5 min (palette créée/déplacée/supprimée).
Le LOC ne prend pas en compte les palettes liées à une réception non
fermée (standard dans le WSC forké — développement dédié
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
| Situation OE | Clôture | ROF | Affichage vue OE |
|--------------|---------|-----|------------------|
| Reçu = attendu | Auto-close | Envoi auto | Auto-archivé → absent |
| Écart dans la tolérance | Auto-close (custom) | Envoi auto | Auto-archivé → absent |
| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** — bouton restreint |
**Visibilité du bouton « Clôturer l'OE »** :
- OE sans écart ou dans la tolérance : accessible à tous (standard),
mais auto-archivé donc invisible
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
**uniquement pour les profils non-opérateurs** (admin, manager, chef
d'équipe). Masqué pour les opérateurs standards
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
clôture manuellement l'OE → ROF envoyé.
### Réception excédentaire (> % autorisé)
Le WMS bloque. Solutions possibles :
| Solution | Description |
|----------|-------------|
| Modifier la commande | Message ROR UPSERT depuis SAP |
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
## Points d'attention
⚠️ En cas de blocage long terme sur l'entrée production, le WMS
redirige automatiquement vers les autres entrées via le système de
routes avec distances (fermeture du PIE de production).
⚠️ Les palettes issues de réceptions extérieures/intersites reçoivent
**automatiquement** le flag « A anoxier » (CstAtt03).
⚠️ L'impression étiquettes réception au déchargement n'est possible que
pour les réceptions extérieures et retours clients (pas production).
⚠️ Les rejets PIE sont dirigés vers un **poumon au sol** avec
notification SmartUI (ancienne approche de renvoi au PK abandonnée).
⚠️ Le process de constitution mono-référence est **standard** (pas de
développement spécifique).
⚠️ Filmage : transmis à Galileo via custom data (CstAtt05) — uniquement
si PIE OK. Paramètre SmartUI `FILMAGES` définit la liste des programmes.
⚠️ `AutoCloseReception = true` mais la clôture effective dépend des
CstAtt08/CstAtt10 (tous supports traités). La clôture OE est
automatique si conditions remplies (`AutoCloseInboundOrder`).
⚠️ Le CstAtt01 poids unitaire mesuré (PIE) est **prioritaire** sur le
poids ITM pour tous les calculs suivants.
## Questions ouvertes
- [x] Programme de filmage exact — documenté, 8 programmes A→H,
paramètre SmartUI `FILMAGES` (LIM-67)
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
ZPL (@Théo)
- [ ] Position étiquette image de quai (devant/côté) — à valider
avec le client (@Justine)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids (@Nicolas)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
les palettes impossibles à réceptionner ? (@Justine)
- [ ] Palette refusée PIE mais non supprimée — comment gérer le
support qui reste en base ? (@Nicolas) (LIM-73)
- [ ] WF clôture OE : faut-il modifier le WF existant ou en créer
un nouveau pour la condition CstAtt01 ? (@Fabien) (LIM-73)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
| 2026-05-12 | Arthur | Réécriture section traitement poste travail (LIM-67) : menu 5 actions, CstAtt02/03/05/08/10, filmage FILMAGES |
| 2026-05-12 | Arthur | Réécriture section clôture (LIM-73) : AutoCloseReception=true, Reception_Close_PR_V2, REF custom, clôture OE 3 cas |
| 2026-05-13 | Arthur | Restauration sections tronquées (points d'attention, questions, historique, références) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (postes travail) | 2026 |
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture/REF) | 2026 |
wiki/limagrain/01-inbound/reception-retour.md
+466
View File
@@ -0,0 +1,466 @@
---
title: "Réception retour commandes clients"
tags: [inbound, réception, retour, client, API, lot]
status: draft
standard_ref: concepts/reception.md
jira_refs: [LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "recap_session_LIM-72_13-05-2026.md"]
last_updated: 2026-05-13
author: Arthur
---
# Réception retour commandes clients
> **Résumé** : processus spécifique de réception des retours client, avec
> interrogation API SAP pour validation lot, et déclaration enrichie sur
> poste de travail.
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les retours client suivent un flux similaire aux réceptions extérieures
(passage poste de travail obligatoire) mais avec des particularités :
- `InboundType = 1` (Return) — vs 0 (Standard) pour les autres flux
- Création de lignes autorisée (article non attendu possible)
- Tolérance illimitée : profil de réception par défaut configuré en
« illimité » sur tous les articles
- `ReceiveLessAllowed = true` — réception partielle toujours autorisée
- Interrogation API SAP pour valider le lot officiel
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
## Process complet de réception retour client
| Étape | Description | Ticket |
|-------|-------------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | — |
| 8 | Libération quai / image de quai | — |
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
du déchargement camion et des déclarations initiales
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
flux fournisseur au PK).
## Notification ROR
Message ROR de SAP (type ORDRSP) avec :
- Numéro de réception
- Articles / Lots / Quantités attendues
- Codes articles **génériques** (codes uniques avec nomenclature
précise, pas réutilisables — assure la traçabilité)
**Différence clé** : cette réception **autorise la création de lignes**.
Limagrain peut recevoir un article non présent dans le ROR initial.
Un article inconnu de la base EasyWMS = ROR refusé. Un article connu
mais non prévu dans le retour = accepté (tolérance illimitée).
## [CUSTOM] Identification lot — Interrogation API SAP
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
### Rappel : structure des articles chez Limagrain
Chez Limagrain, le **code article WMS = lot SAP** (cf.
[Données principales](../06-erp-interface/donnees-principales.md)).
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
complète), et le code produit est un attribut stocké en CstAtt du stock.
Le **lot officiel** est l'alias de l'article dans le WMS.
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
SAP d'envoyer la fiche article complète.
### Logique de vérification
```mermaid
flowchart TD
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
B -- Oui --> C{Vendu par Limagrain ?}
B -- Non --> D[Appel API SAP]
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
E --> F{ITM reçu via API WMS ?}
F -- Oui --> C
F -- Non / Timeout --> G{Tentative < 5 ?}
G -- Oui --> H[Bouton Réessayer]
H --> D
G -- Non --> I[Erreur finale :<br/>contacter responsable]
C -- Oui --> J{Plusieurs articles ?}
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
M --> L
```
### Appel API SAP — Vérification du lot officiel (ATH214)
L'appel API REST est fait **directement depuis le workflow** (pas via
GNA). Il sert à notifier SAP que le WMS a besoin de la fiche article.
> **Architecture CPI** : tous les flux WMS → SAP passent par un
> **endpoint unique** SAP CPI, différencié par le champ `MessageType`
> dans l'enveloppe JSON. Le flux retour utilise `MessageType = "ATH214"`.
> Voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
> pour le détail de l'architecture et de l'authentification OAuth 2.0.
**Séquence d'échange :**
```mermaid
sequenceDiagram
participant WF as WMS (workflow)
participant CPI as SAP CPI
participant SAP as SAP ECC
WF->>CPI: GET /http/ATHInboundMessage<br/>MessageType: ATH214
Note over WF,CPI: Auth: OAuth 2.0 Bearer token<br/>Body: { MessageType, data }
CPI->>SAP: Z_IATH214 (check batch)
SAP-->>CPI: Réponse (EV_RETURN, ET_BATCH)
CPI-->>WF: Réponse JSON
alt EV_RETURN = "X" (OK)
SAP->>CPI: ATH002 (push ITM automatique)
CPI->>WF: POST ApplicationService/ITM
Note over CPI,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
WF->>WF: Poll alias en base (5s)
alt Alias trouvé
WF->>WF: Continuer
else Timeout 1 min
WF->>WF: Proposer réessayer
end
else EV_RETURN ≠ "X" (NOK)
WF->>WF: Erreur immédiate
end
```
**Authentification OAuth 2.0 :**
- Grant type : `client_credentials`
- Token endpoint TEST :
`https://vilm-cpi-test-73ltxp48.authentication.eu30.hana.ondemand.com/oauth/token`
- Token endpoint PROD : à définir
- Body : `x-www-form-urlencoded` avec `grant_type`, `client_id`,
`client_secret`
- Le token est envoyé en header `Authorization: Bearer <token>`
- Expiration gérée côté WMS (cache + renouvellement)
**Payload de requête :**
```json
GET /http/ATHInboundMessage
{
"MessageType": "ATH214",
"data": {
"IV_LGNUM": "WF02",
"IV_MATNR": "",
"IV_CHARG": "",
"IV_BATCH_OFF": "<lot officiel scanné>",
"IV_RETURN": "<code OE retour>"
}
}
```
| Champ | Type | Description |
|-------|------|-------------|
| `IV_LGNUM` | CHAR 4 | Toujours `"WF02"` |
| `IV_MATNR` | CHAR 40 | OPTIONNEL - code lot WMS (= product code SAP) |
| `IV_CHARG` | CHAR 10 | OPTIONNEL - code article WMS (= lot SAP) |
| `IV_BATCH_OFF` | CHAR 30 | Lot officiel scanné sur le sac |
| `IV_RETURN` | CHAR 10 | Numéro du document de retour (code OE) |
> ⚠️ **Méthode HTTP** : `GET` avec body JSON — spécifique SAP CPI.
> Header `Connection: keep-alive` requis.
**Payload de réponse :**
```json
{
"EV_RETURN": "X",
"ET_RETURN": [ { "TYPE": "...", "MESSAGE": "..." } ],
"ET_BATCH": [
{
"MATNR": "000000000000020955",
"CHARG": "2023293649",
"BATCH_OFF": "F0964D002488",
"EV_DEPLOY": "X"
}
]
}
```
| Champ | Type | Description |
|-------|------|-------------|
| `EV_RETURN` | CHAR 1 | `"X"` = aucune erreur, vide = erreur |
| `ET_RETURN[]` | Table | Messages d'erreur ou de succès SAP |
| `ET_BATCH[].MATNR` | CHAR 40 | Code lot WMS = product code SAP |
| `ET_BATCH[].CHARG` | CHAR 10 | Code article WMS = lot SAP |
| `ET_BATCH[].BATCH_OFF` | CHAR 30 | Lot officiel |
| `ET_BATCH[].EV_DEPLOY` | CHAR 1 | `"X"` = déployé/vendu, `""` = non |
> ⚠️ **Mapping inversé CHARG / MATNR** : contrairement à la
> nomenclature SAP standard, `MATNR` (Material Number) porte ici le
> **product code** (= code lot WMS), et `CHARG` (Charge/Batch) porte le
> **code article WMS** (= lot SAP). Ce mapping est confirmé par Michael
> Chaudier et Vincent Goyet (avril 2026).
> ⚠️ **À confirmer** : le nom du champ de déploiement est ambigu dans
> les échanges — `EV_DEPLOY` ou `ZDEPLOY` ? En attente de clarification
> (question A2 dans
> [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
pour l'opérateur.
### Écran d'attente pendant la réception de l'ITM
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
l'ITM. Pendant cette attente :
- **Message** : "Vérification du lot en cours..."
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
un **alias correspondant au lot officiel** existe en base
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
- **Timeout** : 1 minute maximum par tentative
- **Nombre maximum de tentatives** : 5
| Tentative | Comportement en cas de timeout |
|-----------|-------------------------------|
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
### Choix du code lot (multi-résultat)
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
un (filtrage par pays d'origine).
Si un **seul résultat** → sélection automatique, pas de dialogue.
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
physiquement présent sur la palette.
**Gestion dans le REF :** le code générique envoyé dans le ROR est
remplacé par le vrai code lot dans le REF (custom).
## Déclaration au poste de travail (LIM-72)
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
différences :
| # | Étape | Différence vs fournisseur (LIM-67) |
|---|-------|------------------------------------|
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
| 9 | Validation → évacuation AGV | Identique |
### Statut de stock — Modifiable
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
verrouillé (boutons masqués), dans le flux retour client :
- Les **boutons de changement de statut sont visibles** et fonctionnels
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
Non conforme, etc.)
- Les écrans de **date de fin de statut** et **commentaire** suivent
le comportement standard (non skippés contrairement au fournisseur)
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
(non conforme) — assignables uniquement dans ce processus
### Tolérance illimitée
- **Article non prévu** dans le retour → accepté (création de ligne
autorisée)
- **Quantité supérieure** au prévu → acceptée
- **Quantité inférieure** au prévu → acceptée (réception fermée
manuellement)
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
> **abandonné** — remplacé par un message d'avertissement si le poste
> adjacent est déjà ouvert (voir
> [Stations picking](../03-picking/stations-picking.md)).
## Constitution palettes mono référence
Obligation de constituer des palettes **mono référence** avant stockage.
Si la palette retour est multi-ref :
- Opérateur appelle une palette vide sur une TP disponible
- Tri de marchandise
## Calcul poids et passage PIE
Identique aux réceptions extérieures (mêmes formules de répartition
prorata, mêmes contrôles). Voir
[Contrôle qualité réception](controle-qualite-reception.md).
**Différences pour les retours client :**
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
pour les autres flux) — verrou posé sur le **support** (pas sur
le stock)
- Action requise en cas d'écart : **recomptage du nombre de sacs**
- Rejet PIE : dirigé vers **poumon au sol** + notification SmartUI
(ancienne approche de renvoi au PK abandonnée)
## Clôture — Spécificités retour client (LIM-73)
Le mécanisme général de clôture (déclenchement auto-close, tolérance par
ligne, CstAtt01 OE hors tolérance, clôture OE) est documenté dans
[Réception fournisseur — Clôture](reception-fournisseur.md). Cette
section décrit le **delta retour client** : le REF est conditionné au
rangement ASRS complet.
### Contexte métier
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
ne doit être envoyé que lorsque **tous les supports** de la réception
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
notamment PIE).
Pour les autres types de réception (fournisseur / intersite), le REF est
émis à la clôture de la réception, quelle que soit la position des
supports.
### CstAtt11 — Marqueur de rangement ASRS
À chaque fin de tâche de rangement dans l'ASRS :
- Vérifier si le support provient d'une réception de type **retour**
- Si oui → `CstAtt11 = true` sur le support
- Sinon → aucune action
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
condition de clôture reste satisfaisable même si une palette a déjà été
expédiée entre-temps.
### Statut « Clôture en cours »
Dans la vue des réceptions, le statut visuel est piloté par le
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
| CstAtt01 réception | État | Affichage |
|---------------------|------|-----------|
| null / vide | En attente | Standard |
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
Pour les réceptions non-retour, CstAtt01 de la réception n'est pas
utilisé (affichage standard).
### Adaptation Reception_Close_PR_V2 — Partie A (retours)
- **Si non-retour** → clôture immédiate, génération REF (standard)
- **Si retour** :
- Vérifier que **tous les supports** ont `CstAtt11 = true`
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
générer REF
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
« Clôture en cours »). Le WF est rejoué à chaque event
_task finished_ sur un support de la réception
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
> effectuée.
### Zone de stockage dans le REF
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
### Récapitulatif CstAtt clôture retour
| CstAtt | Entité | Rôle |
|--------|--------|------|
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours de traitement |
| CstAtt11 | Palette réelle | `true` quand rangée en ASRS — condition de clôture retour |
| CstAtt01 | Réception | `true` = clôture en attente de rangement ASRS (affichage jaune) |
## État du développement LIM-72
### Implémenté (commit 8401f5456d, 28/04/2026)
- Entité `CST_StockStatus` : CstAtt 1 applicable en retour, CstAtt 2 =
ZLOG, CstAtt 3 = ZINCO
- Query `CST_StockStatus_AllowedForReturn` : filtre statuts autorisés
- Workflow `CST_Return_Stock_GetStatus_UI` : sélection statut simplifié
- Workflow `Reception_FilterLinesByProductAndContainer_UI_V1` : retrait
filtre quantité (tolérance illimitée)
- Dialog `CST_GetProductQuantity_Prompt` : option SelectStatus ajoutée
### Reste à développer
- Appel API SAP ATH214 + gestion token OAuth 2.0
- Écran d'attente ITM (polling alias 5s, timeout 1 min, 5 tentatives)
- Dialogue choix multi-lot (quand ET_BATCH contient plusieurs articles)
- Impression étiquette stock retour client (rapport custom à créer)
- Configuration flux de rejet PIE retours (verrou ECART RETOUR,
destination, notification)
## Points d'attention
⚠️ Le paramètre `SAP_LOT_VERIFY_URL` doit pointer vers l'endpoint CPI
unique `/http/ATHInboundMessage`, pas vers `/api/v1/lot/verify`.
⚠️ Le `MessageType` doit être `"ATH214"` dans l'enveloppe JSON.
⚠️ Pour les lots **déjà connus** en base WMS, le flag "déployé" n'est
pas vérifié dans le design actuel — trou fonctionnel identifié (question
A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
## Questions ouvertes
- [ ] Champs manquants ET_BATCH : description article, pays destination,
propriétaire (@Vincent Goyet) — A1
- [ ] Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ?
(@Vincent Goyet) — A2
- [ ] Délai ATH214 → push ITM dimensionnement polling
(@Vincent Goyet) — A3
- [ ] Vérification "déployé" pour lots déjà connus sans ATH214
(@Vincent Goyet) — A4
- [ ] Étiquette stock retour : format, champs, imprimante
(@Leila / @Antoine) — B1
- [ ] Flux rejet PIE retour : destination, notification, actions
(@Leila / @Antoine) — B2
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV réception |
| 2026-05-12 | Arthur | Intégration LIM-72 (process complet 8 étapes, API SAP, CstAtt) |
| 2026-05-12 | Arthur | Intégration LIM-73 (clôture retour, CstAtt11, REF conditionné) |
| 2026-05-13 | Arthur | Correction API : endpoint CPI unique + ATH214, auth OAuth 2.0, mapping CHARG/MATNR, état dev, questions ouvertes |
## Références
| Source | Type | Date |
|--------|------|------|
| Jira LIM-72 | Ticket | 2025 |
| Jira LIM-73 | Ticket | 2025 |
| Jira LIM-14 | Ticket (CstAtt) | 2025 |
| Athenzat SAP-CPI Webservices Documentation v1.0 | PDF | 2026-04-24 |
| Mail Michael Chaudier ↔ Vincent Goyet | Échange | 2026-04-07/10 |
| Mail Justine ↔ Leila ↔ Vincent Goyet ↔ Maxime Tourrette | Échange | 2026-04-24/29 |
| recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |
wiki/limagrain/02-stockage/.fuse_hidden0000001f00000008
+107
View File
@@ -0,0 +1,107 @@
---
title: "ASRS — Entrepôt automatique Limagrain"
tags: [stockage, ASRS, transstockeur, racks, emplacements]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# ASRS — Entrepôt automatique Limagrain
> **Résumé** : description de l'installation automatique Limagrain : 4 allées
> de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
> types de conteneurs et dimensions.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose d'un magasin automatique **MAG01** composé de 4 allées de
transstockeurs gérées par EasyWMS. L'entrepôt stocke essentiellement des
graines (sacs, big-bags) sur palettes US.
## Organisation EasyWMS
| Code | Description |
|------|-------------|
| **LM** | Organisation LIMAGRAIN |
| **MAG01** | Magasin automatique — 4 allées |
## Racks et capacités
| Type rack | X Initial | X Final | Y Initial | Y Final | Hauteur (mm) | Palette |
|-----------|-----------|---------|-----------|---------|--------------|---------|
| RACK01 | 1 | 69 | 1 | 1 | 1150 | US (1000×1200) |
| RACK02 | 1 | 69 | 2 | 8 | 1950 | US (1000×1200) |
| RACK03 | 1 | 69 | 9 | 10 | 2250 | US (1000×1200) |
## Nomenclature des emplacements
Format : **AAAXXXYYYS(D)**
| Code | Nb caractères | Description |
|------|---------------|-------------|
| AAA | 3 | Nom de l'allée (001–004) |
| XXX | 3 | Coordonnée X — travée le long de l'allée |
| YYY | 3 | Coordonnée Y — hauteur dans la travée |
| S | 1 | Côté de l'allée (1 = gauche, 2 = droite) |
| D | 1 | Profondeur (1 = premier, 2 = second, ...) |
**Exemple** : `00100300721` = allée 1, colonne 3, hauteur 7, côté droit,
profondeur 1.
> Un emplacement EasyWMS correspond à un **canal complet** de rangement de
> palettes (multi-profondeur).
## Type de conteneur unique
| Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
|------|--------------|---------------|--------------|----------------|
| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
## Contrôles au PIE
Au passage PIE, Galileo vérifie :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État de la palette bois
- Lecture étiquette RFID (code barre / QR)
Si un critère n'est pas respecté → rejet vers poste de reconditionnement
ou poste de travail d'origine.
## Exceptions de stockage
Le convoyeur de sortie **TS01** dans l'allée TK_01 occupe physiquement des
emplacements rack. Canaux indisponibles :
- X=21, Y=1
- X=21, Y=2
- X=22, Y=1
## Points d'attention
⚠️ Un seul type de conteneur (palette US) simplifie les stratégies mais
les hauteurs variables (800–1900 mm) impactent le choix du rack (RACK01/02/03).
⚠️ La hauteur PLC déterminée au PIE pilote le choix du niveau de stockage
(Y=1 pour ≤1150, Y=2-8 pour ≤1950, Y=9-10 pour ≤2250).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/.fuse_hidden0000002100000009
+234
View File
@@ -0,0 +1,234 @@
---
title: "Défragmentation — Zone client et ordonnancement par tournée"
tags: [stockage, défragmentation, expédition, zone-client, planning, tournée, STOP, custom]
status: draft
standard_ref: concepts/defragmentation.md
jira_refs: [LIM-85, LIM-87]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "LIM-85 LOT2.1 Configuration stratégies defragmentation du stock client par tournée.md", "LIM-87 LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné ATTENTE_CLIENT CT-13.md"]
last_updated: 2026-05-12
author: Arthur
---
# Défragmentation — Zone client et ordonnancement par tournée
> **Résumé** : processus de défragmentation pour préparer les palettes
> d'expédition vers la zone de défragmentation client dans l'ASRS.
> Inclut un **custom majeur** de défragmentation par tournée (RUT) avec
> ordonnancement par numéro de STOP, déclenché uniquement quand toutes
> les palettes sont prêtes et qu'aucun quai n'est assigné.
> **Standard EasyWMS** : → voir [Defragmentation](../../concepts/defragmentation.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
La défragmentation est un processus standard des entrepôts automatisés.
Chez Limagrain, elle sert à préparer les routes (expéditions) en
déplaçant les conteneurs vers la zone de défragmentation client
(TK02-04, rangées 60-69).
La défragmentation shipping standard propose trois modes d'assignation
(Picking Only, Shipping Only, Picking & Shipping) mais **aucun ne
répond au besoin Limagrain** :
| Mode standard | Comportement | Problème |
|---------------|-------------|----------|
| Shipping Only | Défrag uniquement les palettes complètes | Les palettes de picking ne sont pas repositionnées → ordonnancement STOP faux dans le canal |
| Picking & Shipping | Défrag toutes les palettes (y compris celles à picker) | Les palettes sortent pour être défragmentées alors qu'elles doivent d'abord passer au PK → casse l'ordonnancement |
| Picking Only | Non applicable au besoin | — |
**Contrainte métier** : le stock doit être rangé dans le canal
d'expédition ASRS dans l'**ordre inverse des STOP** de la tournée, de
sorte que les palettes sortent du canal dans le bon ordre lors du
chargement camion (STOP max chargé en premier → déchargé en dernier).
Deux cas se présentent selon l'assignation du quai :
| Situation | Custom | Page |
|-----------|--------|------|
| Quai **non assigné** au RUT | Défrag custom décrite ci-dessous | Cette page |
| Quai **déjà assigné** au RUT | Override du WF stacker crane | → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md) |
## Principe général
Les conteneurs assignés à une expédition sont relocalisés dans la zone
de défragmentation client **en avance**, généralement la nuit ou pendant
les périodes de moindre charge. Cela permet une sortie rapide le jour
de l'expédition.
## Caractéristiques
- **Priorité** : basse (s'exécute en arrière-plan)
- **Planification** : horaires configurables par Limagrain
- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
rangées 60-69, profondeurs 2-10)
- **Déclencheur** : stratégie de défragmentation shipping (mode
Shipping, type d'ordre Tournée) avec filtre custom
## Configuration du planning
Limagrain peut modifier les horaires de façon autonome :
1. Menu « Configuration » → « Défragmentation » → « Planning de
défragmentation »
2. Bouton « Ajouter » → paramétrer les horaires/planning souhaités
3. Activer la défragmentation via le bouton « Activer »
## Prérequis
Pour que EasyWMS puisse défragmenter les conteneurs vers la zone client,
il doit exister au moins une **stratégie de défragmentation shipping**
configurée en mode Shipping et type d'ordre Tournée.
## Lien avec l'expédition
La défragmentation est l'étape 4 du flux d'expédition (voir
[Flux expédition](../04-outbound/flux-expedition.md)) :
1. OS reçu et libéré → stock assigné
2. Palettes complètes → défragmentation vers zone client
3. Palettes picking → poste de travail d'abord, puis zone client
4. Depuis zone client → sortie vers poumon le jour J
## Custom défrag client par tournée — quai non assigné (LIM-87)
### Objectif
Déclencher la défragmentation client d'une tournée **uniquement lorsque
toutes ses palettes de tous ses OS sont prêtes à partir vers l'image de
quai**, c'est-à-dire :
- Les palettes complètes (PC) sont dans l'ASRS
- Les palettes ayant nécessité un picking sont revenues dans l'ASRS
après prélèvement (palettes filles PF retournées)
- **Aucun quai n'est encore associé à la tournée** (sinon le flux
shipping standard avec ordonnancement par STOP prend le relais —
voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md))
La condition « toutes les palettes terminées » s'évalue **au niveau de
la tournée** (RUT) : c'est du « tout-ou-rien ».
### Mécanisme
Le custom utilise le **job de défragmentation client standard** avec
une stratégie en mode Shipping et type d'ordre Tournée. Un **filtre
custom au niveau de la sélection des candidats** exclut de l'éligibilité
toute tournée dont au moins une palette (d'au moins un OS) n'est pas
encore prête dans l'ASRS.
### Règle d'éligibilité
```
POUR CHAQUE RUT candidat à la défrag shipping
(standard : exclut les RUT avec quai assigné) :
POUR CHAQUE OS du RUT :
SI l'OS a des lignes picking non terminées → EXCLURE le RUT
SI au moins une palette complète assignée n'est pas dans l'ASRS
→ EXCLURE le RUT
SI aucune exclusion → ÉLIGIBLE
SINON → reste candidat pour le prochain passage du job
```
> **Point clé** : l'éligibilité est « tout-ou-rien » au niveau tournée.
> Tant qu'un seul OS du RUT n'a pas toutes ses palettes prêtes, aucune
> défrag n'est lancée pour le RUT.
### Ordonnancement dans le canal
Les tâches de défrag sont générées avec un tri par **numéro de STOP**
inversé : les palettes du STOP max entrent dans le canal en premier,
celles du STOP 1 en dernier. Ainsi, à la sortie du canal, l'ordre
est respecté (STOP 1 sort en premier).
La décision prise est de ranger **une tournée par canal** (ou plusieurs
canaux si nécessaire) et non un STOP par canal.
### Paramétrage
- **MAX_DEFRAG_ATTEMPT** : nombre max de tentatives par support pour
trouver un emplacement de destination. Le compteur ne s'incrémente
que si le WMS a cherché un emplacement et n'en a pas trouvé. Si le
filtre custom exclut la tournée avant la recherche de destination,
le compteur reste à 0.
> ⚠️ Point ouvert : vérifier si MAX_DEFRAG_ATTEMPT impacte uniquement
> la défrag par rotation ou aussi la défrag client.
### Cas de test
#### Cas nominaux
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-01 | RUT mono-OS, 3 PC dans l'ASRS, aucun quai | Éligible. 3 tâches défrag, tri par séquence STOP |
| CT-02 | RUT mono-OS, 2 PP pickées → 2 PF revenues ASRS, aucun quai | Éligible. 2 tâches défrag pour les PF |
| CT-03 | RUT mono-OS mixte : 2 PC + 1 PF revenue, aucun quai | Éligible. 3 tâches défrag |
| CT-04 | RUT multi-OS (STOP 1, 2, 3), 2 PC chacun, aucun quai | Éligible. 6 tâches, STOP 3 entre en premier dans le canal |
| CT-05 | RUT multi-OS mixte, tous prêts, aucun quai | Éligible en un seul passage |
#### Cas limites
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-06 | RUT 2 OS : SOR1 prêt, SOR2 a 1 PF non revenue | **NON éligible** — un OS bloque tout le RUT |
| CT-07 | RUT multi-OS, 1 PF en transit AGV vers ASRS | **NON éligible** tant que PF pas physiquement stockée dans un emplacement ASRS |
| CT-08 | RUT prêt mais quai déjà assigné | **NON éligible** pour le custom défrag. Flux shipping standard prend le relais |
| CT-09 | RUT 1 SOR, 3 lignes picking : 2 PF revenues, 1 PP au PK | **NON éligible** — on attend la totalité |
#### Cas dégradés
| CT | Préconditions | Résultat attendu |
|----|--------------|------------------|
| CT-11 | AGV HS pendant retour PF → ASRS | **NON éligible** tant que PF pas dans l'ASRS. Redevient éligible après remise en route |
| CT-12 | PP en litige, stock réassigné sur PP' | Éligible quand toutes les palettes (y compris réassignations) sont dans l'ASRS |
| CT-13 | Rupture de stock sur un OS de la tournée | **À trancher** — voir point ouvert ci-dessous |
| CT-14 | Bouton « Problème » au picking, OnStockAdjust recalcule | Si stock suffisant : PF revient, RUT éligible. Si réassignation : attente nouvelle PF' |
| CT-15 | RUT libéré, aucune tâche picking jamais générée | **À trancher** — non éligible par défaut |
| CT-16 | Nouveau SOR ajouté à un RUT déjà éligible | **Redevient NON éligible** jusqu'à ce que le nouveau SOR soit terminé |
## Pause et reprise
Le processus peut être mis en pause et repris ultérieurement en cas de
reprise d'activité (par exemple si l'activité reprend la nuit).
## Points d'attention
⚠️ Les tâches de défragmentation ont une priorité **basse** — elles ne
perturbent pas l'activité normale mais peuvent être longues.
⚠️ MECALUX conseille une présence sur site lors de la défragmentation
en cas de défaut sur les transstockeurs (non obligatoire).
⚠️ L'avancée des tâches est consultable sur la vue des tâches.
⚠️ Le filtre custom n'incrémente pas MAX_DEFRAG_ATTEMPT quand il
exclut un RUT — le compteur ne démarre que lors d'une recherche
effective de destination.
## Questions ouvertes
- [ ] Comportement en cas de **rupture de stock** sur un OS de la
tournée (CT-13) : option A (RUT reste non éligible, attend un
nouveau SOR sans les lignes concernées) ou option B (défrag lancée
sur les palettes disponibles) ? (@Justine — à vérifier avec client)
→ voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
- [ ] **MAX_DEFRAG_ATTEMPT** : impacte-t-il uniquement la défrag par
rotation ou aussi la défrag client ? (@Nicolas)
→ voir [Questions ouvertes](../08-transverse/questions-ouvertes.md)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-12 | Arthur | Ajout custom défrag client par tournée (LIM-85/LIM-87) : mécanisme, éligibilité, cas de test, points ouverts |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira | 2026 |
| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira | 2026 |
wiki/limagrain/02-stockage/.fuse_hidden000000230000000a
+143
View File
@@ -0,0 +1,143 @@
---
title: "Configuration Galileo — Limagrain"
tags: [stockage, galileo, TMS, architecture, IT]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Configuration Galileo — Limagrain
> **Résumé** : architecture logicielle IT de l'installation Limagrain et
> spécificités de la configuration Galileo (TMS).
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [System Architecture](../../architecture/overview.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
EasyWMS gère l'entrepôt automatique Limagrain avec une base Oracle. Le TMS
Galileo contrôle les 4 transstockeurs, les convoyeurs, navettes et stations
PIE. Les AGV sont gérés par un fournisseur tiers (non Galileo).
## Architecture logicielle
```mermaid
graph TD
SAP[SAP EWM] -->|XML / Webservice| GNA[EasyWMS GNA]
GNA --> EWMS[EasyWMS Serveur]
EWMS --> BBDD[(Oracle DB)]
EWMS --> GW[EasyWMS Gateway]
GW -->|TCP 3000| GAL[Galileo TMS]
GAL --> TK[Transstockeurs x4]
GAL --> CONV[Convoyeurs]
GAL --> NAV[Navettes]
GAL --> PIE[Stations PIE x3]
EWMS --> LP[Label Printer Service]
EWMS --> WEB[Application Web EasyWMS]
EWMS --> PC[Application PC EasyWMS]
WEB --> TRF[Terminaux RF]
AGV[AGV - Fournisseur tiers] -.->|Interface séparée| EWMS
```
### Composants serveur EasyWMS
| Composant | Rôle |
|-----------|------|
| Application serveur EasyWMS | Services de logique et gestion |
| Oracle DB | Base de données |
| EasyWMS GNA | Communication ERP (SAP) via XML/Webservice |
| EasyWMS Gateway | Communication Galileo (protocole frames TCP) |
| EasyWMS Label Printer | Impression étiquettes et documents |
### Communication ERP
- **Protocole** : XML + Webservice
- **ERP** : SAP EWM
- **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
## Stations PIE — Configuration spécifique
3 stations PIE installées :
| Station | Côté | Usage principal |
|---------|------|----------------|
| PIE_01 | Quais (production) | Réception production directe |
| PIE_02 | Postes de travail | Réception ext./retours après traitement |
| PIE_03 | Postes de travail | Idem PIE_02 |
### Mode d'insertion PIE
- **Mode normal** (known containers) : rejet si RFID inconnue
- [CUSTOM] Pas de message ASO au passage PIE
- [CUSTOM] Vérification poids avec tolérances par type article
- [CUSTOM] Mise à jour du « Poids de l'unité » du conteneur à chaque passage
### Contrôle au PIE
| Contrôle | Valeur limite |
|----------|---------------|
| Dimensions max | 1300 × 1100 × 1900 mm |
| Poids max | 1250 kg |
| État palette bois | Correct (visuel Galileo) |
| Lecture RFID | Obligatoire — doit être connue (ASN) |
## Flux physiques dans l'entrepôt
Les flux sont majoritairement réalisés par des **AGV** (fournisseur tiers).
EasyWMS communique les points de prise et de dépose ; le sens de prise/dépose
est géré par le fournisseur AGV.
Deux entrées dans l'ASRS :
| Entrée | Côté | Usage |
|--------|------|-------|
| Entrée production | Quais (PIE_01) | Palettes production, palettes vides |
| Entrée postes de travail | Postes (PIE_02/03) | Palettes après traitement en poste |
> En cas de blocage long terme sur une entrée, un bouton permet de
> rediriger les flux vers l'autre entrée.
## Rétention des données
| Entité | Durée standard | Souhait Limagrain |
|--------|----------------|-------------------|
| Transactions | 6 mois | 2 ans |
| Movements | 6 mois | 2 ans |
| Outbound Orders | 1 an | 2 ans |
| Inbound Orders | 1 an | 2 ans |
| Tasks | 1 an | 2 ans |
| Stock adjustments | 1 an | 2 ans |
> ⚠️ Mecalux doit étudier l'impact de la rétention 2 ans sur les prérequis
> serveurs pour éviter saturation DB et lenteurs.
## Points d'attention
⚠️ Les interfaces AGV sont définies dans un document annexe séparé et
peuvent impacter les flux fonctionnels.
⚠️ La banderoleuse (filmeuse) est située avant le PIE côté postes de
travail — un contrôle capacité filmeuse est fait en amont du PIE.
## Questions ouvertes
- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
- [ ] Fournisseur AGV définitif et protocole d'interface (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/.fuse_hidden000000250000000b
+124
View File
@@ -0,0 +1,124 @@
---
title: "Gestion des palettes vides"
tags: [stockage, palettes-vides, réapprovisionnement, expédition]
status: draft
standard_ref: concepts/container-management.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Gestion des palettes vides
> **Résumé** : gestion des piles de palettes vides dans EasyWMS —
> réception, stockage, réapprovisionnement des postes et expédition.
> **Standard EasyWMS** : → voir [Container Management](../../concepts/container-management.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les palettes vides sont intégrées dans le périmètre EasyWMS. Leur gestion
est faite **uniquement en pile** — aucune palette vide n'est traitée de
façon unitaire.
## Typologie
- Dimensions : US (1000 × 1200 mm)
- Type unique : NIMP15
- Stockage : piles de **10 palettes vides**
## Réception
Les piles de palettes vides sont réceptionnées au niveau des quais.
Type de réception : **Réception palettes vides**. L'article est nommé
« PILE DE 10 PALETTES ».
**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé —
contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
de travail. Destination : stockage direct dans l'ASRS.
> **Remarque** : en cas de blocage long terme sur l'entrée quai, un bouton
> permet de rediriger manuellement les palettes vers l'entrée « Postes de
> travail ».
## Stockage
### Dans l'ASRS
- Priorité : allées 2, 3 et 4 (TK02-04)
- Position : au plus proche de l'entrée/sortie pour réapprovisionner
rapidement les postes
- Stratégie de rangement : voir
[Stratégies de rangement](putaway-strategies.md) — type 5
- Consultation : vue des stocks avec filtre sur l'article « palettes vides »
### Au niveau des postes de travail
- **2 piles par îlot de travail** (et non par poste individuel)
- Création d'un **emplacement picking dédié** pour chaque emplacement
physique accueillant les stocks de palettes vides (permet le
réapprovisionnement automatique sur seuil)
## Réapprovisionnement
### Sur poste de travail
- Chaque poste est équipé d'une aide à la manutention (prise palette
sur la pile → dépose sur table de préparation)
- Action **manuelle**, non pilotée par EasyWMS
- En cas de regroupement : l'opérateur peut reposer une palette vide
sur la pile
> ⚠️ La pile doit être parfaitement remontée pour passer le contrôle
> gabarit au PIE.
[CUSTOM] Quand la pile est vide :
- **Bouton WfAction** dans la workstation pour demander le
réapprovisionnement
- L'opérateur choisit la pile à réapprovisionner parmi une liste
(paramètre par PK avec noms des emplacements)
- Quand l'emplacement devient vide (via bouton WfAction) →
réapprovisionnement automatique déclenché
- Bouton inverse pour renvoyer une pile au stockage
### Sur le poumon
- Réapprovisionnement **automatique** des 2 emplacements poumon quand
un emplacement est vidé (tâche depuis ASRS)
## Expédition
Les piles de palettes vides peuvent être expédiées :
1. Création **manuelle** d'un ordre de sortie
2. Renseigner la destination : table de préparation (poste) OU image de quai
3. Une fois expédiées → sorties des stocks EasyWMS
## Points d'attention
⚠️ Gestion uniquement en pile (jamais unitaire) — simplifie le suivi
mais impose des manipulations par lot de 10.
⚠️ Le nombre de piles en stock est visible en filtrant la vue des stocks
sur l'article spécifique des palettes vides.
⚠️ La pile doit être correctement empilée pour ne pas être rejetée
au PIE (contrôle gabarit).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : emplacement picking dédié, 2 piles/îlot, WfAction |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki/limagrain/02-stockage/.fuse_hidden000000270000000c
+154
View File
@@ -0,0 +1,154 @@
---
title: "Processus d'anoxie — TK01"
tags: [stockage, anoxie, TK01, flag, custom, processus]
status: draft
standard_ref: concepts/warehouse-processes.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Processus d'anoxie — TK01
> **Résumé** : processus [CUSTOM] de traitement par anoxie dans l'allée 1,
> incluant le flag « A anoxier », la relocalisation et le blocage d'allée.
> **Standard EasyWMS** : → voir [Warehouse Processes](../../concepts/warehouse-processes.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'anoxie consiste à baisser le niveau d'oxygène dans l'allée 1 (TK01)
pour éliminer d'éventuels nuisibles dans les semences. Ce processus est
spécifique au domaine des semences et n'existe pas dans le standard EasyWMS.
## Caractéristiques
- **Localisation** : allée 1 uniquement (TK01)
- **Durée** : 3 à 4 semaines en moyenne
- **Fréquence** : 2 fois par an
- **Déclenchement** : manuel
- **Impact** : allée et stock bloqués pendant toute la durée
En dehors des périodes d'anoxie, la zone est utilisée pour du stockage
normal en priorisant les palettes à anoxier. Chaque compartiment a un
taux d'oxygène contrôlé.
## [CUSTOM] Flag « A anoxier »
### Attribution automatique
Tous les stocks des palettes issues des processus suivants reçoivent
automatiquement le flag « A anoxier » car elles présentent des risques
de contamination :
- Réceptions extérieures / intersites
- Retours client
Condition : la palette doit passer par un poste de travail.
### Attribution manuelle
Il est également possible d'assigner le flag manuellement sur des stocks
spécifiques depuis la vue des stocks.
### Retrait du flag
- **Automatique** : à la fin du processus d'anoxie (bouton « Fin d'anoxie »)
- **Manuel** : par un utilisateur, qui devra saisir une date de dernière
anoxie
## Cas particuliers
- Des stocks d'une même référence (article-lot) peuvent posséder des dates
de dernière anoxie différentes — ces stocks ne sont pas physiquement
différenciables
- Si une palette contient du stock « mixte » dont certaines lignes ont le
flag et d'autres pas → toutes les lignes sont considérées « A anoxier »
## Processus complet
```mermaid
flowchart TD
START[Décision lancer anoxie] --> SEL1[1. Sélection palettes à évacuer de TK01]
SEL1 --> RELOC1[Relocalisation vers TK02-04]
RELOC1 --> SEL2[2. Sélection palettes à anoxier]
SEL2 --> RELOC2[Relocalisation vers TK01]
RELOC2 --> BLOCK[3. Blocage manuel allée 01]
BLOCK --> WAIT[Anoxie en cours — 3 à 4 semaines]
WAIT --> FIN[4. Bouton « Fin d'anoxie »]
FIN --> UPDATE[MAJ date dernière anoxie + suppression flag]
UPDATE --> DEBLOCK[Déblocage manuel allée 01]
```
### Étape 1 — Évacuation des palettes non concernées
- Sélection manuelle depuis la vue des conteneurs (filtre sur flag
« A anoxier »)
- Relocalisation vers une autre allée (en masse, voir déplacement
de conteneurs)
### Étape 2 — Relocalisation des palettes à anoxier
- Sélection manuelle des palettes avec flag « A anoxier »
- Relocalisation vers TK01 dans la mesure des emplacements disponibles
[CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
automatiquement les tâches de relocalisation.
### Étape 3 — Blocage
- Blocage **manuel** de l'allée 01 sur EasyWMS
- Le stock et l'allée deviennent indisponibles
### Étape 4 — Fin d'anoxie
- [CUSTOM] Bouton « Fin d'anoxie » qui :
- Met à jour la date de dernière anoxie
- Supprime automatiquement le flag « A anoxier » pour chaque ligne
de stock présente dans l'allée
- Déblocage manuel de l'allée 01
## Suivi et rapports
- Extraction de la vue des stocks avec filtres « A anoxier » et
« date de dernière anoxie » pour établir le rapport souhaité
- L'avancée des tâches de relocalisation est consultable sur la vue
des tâches
## Lien avec les stratégies de rangement
Les palettes avec flag « A anoxier » ont une stratégie de rangement
dédiée qui priorise TK01 (voir
[Stratégies de rangement](putaway-strategies.md) — type 1).
## Points d'attention
⚠️ La relocalisation peut prendre un temps significatif selon les
quantités sélectionnées.
⚠️ MECALUX conseille d'avoir une personne sur site lors du lancement
de la défragmentation/relocalisation en cas de défaut sur les
transstockeurs (non obligatoire).
⚠️ Le processus d'anoxie peut être mis en pause et repris ultérieurement
en cas de reprise d'activité.
## Questions ouvertes
- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/.fuse_hidden000000290000000d
+113
View File
@@ -0,0 +1,113 @@
---
title: "Stratégies de rangement Limagrain"
tags: [stockage, putaway, stratégie, rangement, canaux]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Stratégies de rangement Limagrain
> **Résumé** : 5 stratégies de rangement distinctes selon la typologie de la
> palette, avec des règles de sélection de canal et d'allée spécifiques.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le premier filtre appliqué aux palettes détermine la stratégie de rangement.
Limagrain n'utilise pas de classes de rotation ABC — la répartition se fait
sur la nature fonctionnelle de la palette.
## Stratégie 1 — Palettes avec flag « A Anoxier » (mono ou multi lot)
Objectif : stocker en priorité dans TK_01 (zone anoxie).
| Priorité | Règle |
|----------|-------|
| 1 | TK01 — canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
| 2 | TK01 — canal vide |
| 3 | TK01 — canal incomplet avec autre référence |
| 4 | Appliquer la stratégie sans flag « A Anoxier » (stratégie 2 ou 3) |
| 5 | REJET |
## Stratégie 2 — Palettes mono lot sans flag « A Anoxier »
Objectif : optimiser le taux de remplissage et répartir le stock entre allées.
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet même lot SAP + mêmes attributs logistiques |
| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) — taille optimale vs nb palettes ASN restantes |
| 3 | Canal le plus adapté aux nb palettes ASN restantes (toute allée) |
| 4 | REJET |
**Sélection du canal** : canal le plus grand possible qui sera rempli
complètement, ou canal qui laissera le moins de positions vides.
## Stratégie 3 — Palettes multi lot sans flag « A Anoxier »
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet mixte |
| 2 | Canal vide |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Stratégie 4 — Palettes d'expédition (mono ou multi lot)
Objectif : stocker dans la zone défragmentation client, regroupées par route.
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet avec palettes de la même route — zone défragmentation client |
| 2 | Canal vide — zone défragmentation client |
| 3 | PAS DE MOUVEMENT (palette reste en place) |
## Stratégie 5 — Piles de palettes vides
Article type « Palette » (NIMP15).
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet le plus proche de l'entrée avec piles de palettes vides |
| 2 | Canal vide le plus proche de l'entrée (hors TK01) |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Critères transverses
- **Réservation de canal** : le nombre de palettes en ASN non encore reçues
détermine la capacité optimale du canal à réserver (stratégie 2)
- **Équilibrage inter-allées** : pour les palettes mono lot, EasyWMS répartit
le stock entre allées différentes quand un canal plein existe déjà
- **Hauteur** : la hauteur de la première palette au PIE détermine le type
de rack compatible (RACK01 ≤1150, RACK02 ≤1950, RACK03 ≤2250)
## Points d'attention
⚠️ Si aucun emplacement n'est trouvé → palette rejetée vers le poste de
rejet configuré (sauf stratégie 4 où la palette reste sur place).
⚠️ Les palettes d'expédition ne sont déplacées en zone défragmentation
qu'après assignation de stock (post-libération de l'OS).
⚠️ La stratégie 1 (anoxie) utilise un fallback vers les stratégies 2/3
si TK_01 est plein — important en période hors-anoxie.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/.fuse_hidden0000002b0000000e
+85
View File
@@ -0,0 +1,85 @@
---
title: "Zones de stockage Limagrain"
tags: [stockage, zones, anoxie, défragmentation, ASRS]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Zones de stockage Limagrain
> **Résumé** : Limagrain dispose de 3 zones de stockage dans l'ASRS, chacune
> avec un rôle spécifique : anoxie, stockage principal, défragmentation client.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'entrepôt automatique Limagrain comporte **4 allées** (TK_01 à TK_04). Les
zones de stockage ont été définies pour répondre à deux besoins métier :
1. **Anoxie** : traitement insecticide par réduction d'oxygène sur TK_01
2. **Défragmentation client** : pré-positionnement des palettes assignées à
une route avant expédition (optimise les temps de sortie)
## Configuration des zones
| Zone | Transstockeur | X initial | X final | Y initial | Y final |
|------|---------------|-----------|---------|-----------|---------|
| Zone Anoxie | TK_01 | 1 | 69 | 1 | 10 |
| Zone Principale | TK_02, 03 & 04 | 1 | 59 | 1 | 10 |
| Zone Principale (ext.) | TK_02, 03 & 04 | 60 | 69 | 1 | 1 |
| Zone Défragmentation client | TK_02, 03 & 04 | 60 | 69 | 2 | 10 |
> ⚠️ Cette répartition peut être modifiée par un administrateur Limagrain
> selon les besoins opérationnels.
## Comportement par zone
### Zone Anoxie (TK_01)
- Réservée **en priorité** aux palettes avec le flag « A anoxier »
- Hors période d'anoxie, utilisée comme stockage normal (priorité anoxie)
- Durant l'anoxie (3-4 semaines, 2x/an) : allée + stock bloqués
- Voir [Processus d'anoxie](../../limagrain/08-transverse/decisions-architecture.md)
### Zone Principale (TK_02, 03 & 04)
- Stockage général : articles et piles de palettes vides
- Pas de distinction de classe de rotation (pas d'ABC)
- Stratégie de répartition inter-allées pour équilibrer la charge
### Zone Défragmentation client (TK_02, 03 & 04, X=60-69, Y=2-10)
- Palettes assignées à un ordre de sortie (post stock assignment)
- Regroupement par route/stop pour optimiser le séquencement à l'expédition
- Les palettes y sont déplacées automatiquement après libération de l'OS
## Points d'attention
⚠️ Les piles de palettes vides sont stockées en priorité dans les allées
02, 03 & 04, au plus proche des entrées/sorties (canaux bas en X).
⚠️ Le convoyeur de sortie TS01 dans TK_01 crée une **exception de stockage** :
pas de canaux en X=21/Y=1, X=21/Y=2, X=22/Y=1.
⚠️ Taux minimum de 5% d'emplacements libres recommandé par Mecalux pour
la défragmentation et les relocalisations.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/.fuse_hidden0000002d0000000f
+48
View File
@@ -0,0 +1,48 @@
---
title: "Stockage — Vue d'ensemble"
tags: [stockage, asrs, galileo, index]
status: draft
last_updated: 2026-05-05
---
# Stockage — Vue d'ensemble
> **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
> putaway, zones de stockage, défragmentation.
> **Standard EasyWMS** : voir [Storage](../../concepts/storage.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
## Pages de cette section
- [ASRS / Miniload](asrs-miniload.md)
- [Configuration Galileo](galileo-config.md)
- [Stratégies de putaway](putaway-strategies.md)
- [Zones de stockage](zones-stockage.md)
- [Défragmentation](defragmentation.md)
- [Processus d'anoxie](processus-anoxie.md)
- [Gestion des palettes vides](palettes-vides.md)
## Vue synthétique du stockage Limagrain
```mermaid
graph LR
subgraph ASRS MAG01
TK1[TK_01<br/>Zone Anoxie]
TK2[TK_02]
TK3[TK_03]
TK4[TK_04]
end
subgraph Zones
ZA[Zone Anoxie<br/>TK01 X1-69 Y1-10]
ZP[Zone Principale<br/>TK02-04 X1-59 Y1-10<br/>+ X60-69 Y1]
ZD[Zone Défrag. Client<br/>TK02-04 X60-69 Y2-10]
end
TK1 --- ZA
TK2 --- ZP
TK3 --- ZP
TK4 --- ZP
TK2 --- ZD
TK3 --- ZD
TK4 --- ZD
```
wiki/limagrain/02-stockage/_index.md
+48
View File
@@ -0,0 +1,48 @@
---
title: "Stockage — Vue d'ensemble"
tags: [stockage, asrs, galileo, index]
status: draft
last_updated: 2026-05-05
---
# Stockage — Vue d'ensemble
> **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
> putaway, zones de stockage, défragmentation.
> **Standard EasyWMS** : voir [Storage](../../concepts/stock.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
## Pages de cette section
- [ASRS / Miniload](asrs-miniload.md)
- [Configuration Galileo](galileo-config.md)
- [Stratégies de putaway](putaway-strategies.md)
- [Zones de stockage](zones-stockage.md)
- [Défragmentation](defragmentation.md)
- [Processus d'anoxie](processus-anoxie.md)
- [Gestion des palettes vides](palettes-vides.md)
## Vue synthétique du stockage Limagrain
```mermaid
graph LR
subgraph ASRS MAG01
TK1[TK_01<br/>Zone Anoxie]
TK2[TK_02]
TK3[TK_03]
TK4[TK_04]
end
subgraph Zones
ZA[Zone Anoxie<br/>TK01 X1-69 Y1-10]
ZP[Zone Principale<br/>TK02-04 X1-59 Y1-10<br/>+ X60-69 Y1]
ZD[Zone Défrag. Client<br/>TK02-04 X60-69 Y2-10]
end
TK1 --- ZA
TK2 --- ZP
TK3 --- ZP
TK4 --- ZP
TK2 --- ZD
TK3 --- ZD
TK4 --- ZD
```
wiki/limagrain/02-stockage/asrs-miniload.md
+107
View File
@@ -0,0 +1,107 @@
---
title: "ASRS — Entrepôt automatique Limagrain"
tags: [stockage, ASRS, transstockeur, racks, emplacements]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# ASRS — Entrepôt automatique Limagrain
> **Résumé** : description de l'installation automatique Limagrain : 4 allées
> de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
> types de conteneurs et dimensions.
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose d'un magasin automatique **MAG01** composé de 4 allées de
transstockeurs gérées par EasyWMS. L'entrepôt stocke essentiellement des
graines (sacs, big-bags) sur palettes US.
## Organisation EasyWMS
| Code | Description |
|------|-------------|
| **LM** | Organisation LIMAGRAIN |
| **MAG01** | Magasin automatique — 4 allées |
## Racks et capacités
| Type rack | X Initial | X Final | Y Initial | Y Final | Hauteur (mm) | Palette |
|-----------|-----------|---------|-----------|---------|--------------|---------|
| RACK01 | 1 | 69 | 1 | 1 | 1150 | US (1000×1200) |
| RACK02 | 1 | 69 | 2 | 8 | 1950 | US (1000×1200) |
| RACK03 | 1 | 69 | 9 | 10 | 2250 | US (1000×1200) |
## Nomenclature des emplacements
Format : **AAAXXXYYYS(D)**
| Code | Nb caractères | Description |
|------|---------------|-------------|
| AAA | 3 | Nom de l'allée (001–004) |
| XXX | 3 | Coordonnée X — travée le long de l'allée |
| YYY | 3 | Coordonnée Y — hauteur dans la travée |
| S | 1 | Côté de l'allée (1 = gauche, 2 = droite) |
| D | 1 | Profondeur (1 = premier, 2 = second, ...) |
**Exemple** : `00100300721` = allée 1, colonne 3, hauteur 7, côté droit,
profondeur 1.
> Un emplacement EasyWMS correspond à un **canal complet** de rangement de
> palettes (multi-profondeur).
## Type de conteneur unique
| Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
|------|--------------|---------------|--------------|----------------|
| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
## Contrôles au PIE
Au passage PIE, Galileo vérifie :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État de la palette bois
- Lecture étiquette RFID (code barre / QR)
Si un critère n'est pas respecté → rejet vers poste de reconditionnement
ou poste de travail d'origine.
## Exceptions de stockage
Le convoyeur de sortie **TS01** dans l'allée TK_01 occupe physiquement des
emplacements rack. Canaux indisponibles :
- X=21, Y=1
- X=21, Y=2
- X=22, Y=1
## Points d'attention
⚠️ Un seul type de conteneur (palette US) simplifie les stratégies mais
les hauteurs variables (800–1900 mm) impactent le choix du rack (RACK01/02/03).
⚠️ La hauteur PLC déterminée au PIE pilote le choix du niveau de stockage
(Y=1 pour ≤1150, Y=2-8 pour ≤1950, Y=9-10 pour ≤2250).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/defragmentation.md
+231
View File
@@ -0,0 +1,231 @@
---
title: "Défragmentation — Zone client et ordonnancement par tournée"
tags: [stockage, défragmentation, expédition, zone-client, planning, tournée, STOP, custom]
status: draft
standard_ref: concepts/defragmentation.md
jira_refs: [LIM-85, LIM-87]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "LIM-85 LOT2.1 Configuration stratégies defragmentation du stock client par tournée.md", "LIM-87 LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné ATTENTE_CLIENT CT-13.md"]
last_updated: 2026-05-12
author: Arthur
---
# Défragmentation — Zone client et ordonnancement par tournée
> **Résumé** : processus de défragmentation pour préparer les palettes
> d'expédition vers la zone de défragmentation client dans l'ASRS.
> Inclut un **custom majeur** de défragmentation par tournée (RUT) avec
> ordonnancement par numéro de STOP, déclenché uniquement quand toutes
> les palettes sont prêtes et qu'aucun quai n'est assigné.
> **Standard EasyWMS** : → voir [Defragmentation](../../concepts/defragmentation.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
La défragmentation est un processus standard des entrepôts automatisés.
Chez Limagrain, elle sert à préparer les routes (expéditions) en
déplaçant les conteneurs vers la zone de défragmentation client
(TK02-04, rangées 60-69).
La défragmentation shipping standard propose trois modes d'assignation
(Picking Only, Shipping Only, Picking & Shipping) mais **aucun ne
répond au besoin Limagrain** :
| Mode standard | Comportement | Problème |
|---------------|-------------|----------|
| Shipping Only | Défrag uniquement les palettes complètes | Les palettes de picking ne sont pas repositionnées → ordonnancement STOP faux dans le canal |
| Picking & Shipping | Défrag toutes les palettes (y compris celles à picker) | Les palettes sortent pour être défragmentées alors qu'elles doivent d'abord passer au PK → casse l'ordonnancement |
| Picking Only | Non applicable au besoin | — |
**Contrainte métier** : le stock doit être rangé dans le canal
d'expédition ASRS dans l'**ordre inverse des STOP** de la tournée, de
sorte que les palettes sortent du canal dans le bon ordre lors du
chargement camion (STOP max chargé en premier → déchargé en dernier).
Deux cas se présentent selon l'assignation du quai :
| Situation | Custom | Page |
|-----------|--------|------|
| Quai **non assigné** au RUT | Défrag custom décrite ci-dessous | Cette page |
| Quai **déjà assigné** au RUT | Override du WF stacker crane | → voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md) |
## Principe général
Les conteneurs assignés à une expédition sont relocalisés dans la zone
de défragmentation client **en avance**, généralement la nuit ou pendant
les périodes de moindre charge. Cela permet une sortie rapide le jour
de l'expédition.
## Caractéristiques
- **Priorité** : basse (s'exécute en arrière-plan)
- **Planification** : horaires configurables par Limagrain
- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
rangées 60-69, profondeurs 2-10)
- **Déclencheur** : stratégie de défragmentation par rotation (standard)
+ custom défrag client par tournée (ci-dessous)
## Configuration du planning (standard)
Limagrain peut modifier les horaires de façon autonome :
1. Menu « Configuration » → « Défragmentation » → « Planning de
défragmentation »
2. Bouton « Ajouter » → paramétrer les horaires/planning souhaités
3. Activer la défragmentation via le bouton « Activer »
Prérequis : au moins une **stratégie de défragmentation par rotation**.
## Lien avec l'expédition
La défragmentation est l'étape 4 du flux d'expédition (voir
[Flux expédition](../04-outbound/flux-expedition.md)) :
1. OS reçu et libéré → stock assigné
2. Palettes complètes → défragmentation vers zone client
3. Palettes picking → poste de travail d'abord, puis zone client
4. Depuis zone client → sortie vers poumon le jour J
## [CUSTOM] Défrag client par tournée — Quai non assigné (LIM-87)
### Objectif
Déclencher la défragmentation client d'une tournée **uniquement
lorsque toutes ses palettes de tous ses OS sont prêtes à partir vers
l'image de quai** :
- Les palettes complètes sont dans l'ASRS
- Les palettes ayant nécessité un picking sont revenues dans l'ASRS
après prélèvement
- **Aucun quai n'est encore associé à la tournée** (sinon le flux
shipping standard prend le relais →
[Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md))
La condition « toutes les palettes terminées » s'évalue **au niveau
de la tournée** (RUT), pas de l'OS individuel.
### Mécanisme
- Utiliser le **job de défragmentation client standard** avec une
stratégie en mode Shipping et type d'ordre Tournée
- Ajouter un **filtre custom au niveau de la sélection des candidats**
qui exclut de l'éligibilité toute tournée dont au moins une palette
(d'au moins un OS) n'est pas encore prête dans l'ASRS
### Règle d'éligibilité (pseudocode)
```
POUR CHAQUE RUT candidat à la défrag shipping
(en standard, exclut les RUT avec quai assigné) :
POUR CHAQUE OS du RUT :
SI l'OS a des lignes picking non terminées
→ EXCLURE le RUT
SI au moins une palette complète assignée
n'est pas dans l'ASRS
→ EXCLURE le RUT
SI aucune exclusion → ÉLIGIBLE
SINON → reste candidat pour le prochain passage du job
```
> **Point clé** : l'éligibilité est « tout-ou-rien » au niveau
> tournée. Tant qu'un seul OS du RUT n'a pas toutes ses palettes
> prêtes, aucune défrag n'est lancée pour le RUT.
### Ordonnancement dans le canal
Les palettes du **STOP max** entrent dans le canal en premier, celles
du **STOP 1** en dernier. Ainsi les palettes sortent dans le bon ordre
lors du chargement camion (STOP 1 chargé en premier).
Le rangement se fait dans un canal (ou plusieurs canaux) par tournée
— pas un canal par STOP.
### Paramètre MAX_DEFRAG_ATTEMPT
À chaque passage du job, le WMS essaie de trouver un emplacement
valide. Si aucun n'est trouvé, le compteur de tentatives est
incrémenté. Une fois MAX_DEFRAG_ATTEMPT atteint (défaut : 5), le
support est retiré des candidats défrag.
**Important** : le compteur ne s'incrémente que si le WMS a cherché
un emplacement de destination et n'en a pas trouvé. Si le filtre
custom exclut la tournée avant même de chercher une destination,
aucune tentative n'est décomptée.
## Cas de tests (LIM-87)
Légende : PC = palette complète, PP = palette de picking (mère),
PF = palette fille (sortie du picking, retour ASRS).
### Cas nominaux
| CT | Description | Préconditions | Résultat attendu |
|----|-------------|---------------|------------------|
| 01 | RUT mono-OS, uniquement PC | 1 SOR, 3 PC dans ASRS, pas de quai | Éligible. 3 tâches défrag, séquence STOP respectée |
| 02 | RUT mono-OS, uniquement picking terminé | 1 SOR, 2 PP → 2 PF revenues ASRS, pas de quai | Éligible. 2 tâches défrag pour les PF |
| 03 | RUT mono-OS mixte (PC + picking terminé) | 1 SOR : 2 PC + 1 PF revenue ASRS, pas de quai | Éligible. 3 tâches défrag |
| 04 | RUT multi-OS, ordonnancement STOP | 3 SOR (STOP 1,2,3), 2 PC chacun, toutes ASRS | Éligible. 6 tâches, STOP 3 en premier dans le canal |
| 05 | RUT multi-OS, tous prêts simultanément | 3 SOR mixtes, toutes palettes ASRS | Éligible en un seul passage. 5 tâches, séquence STOP |
### Cas limites
| CT | Description | Préconditions | Résultat attendu |
|----|-------------|---------------|------------------|
| 06 | PP partie, PF pas encore revenue | 2 SOR, SOR1 prêt, SOR2 avec PF pas revenue | **NON éligible** (un OS bloque tout le RUT) |
| 07 | PF encore sur AGV (en mouvement) | Multi-OS, 1 PF en transit AGV | **NON éligible** tant que PF pas dans ASRS |
| 08 | Quai déjà assigné à la tournée | Toutes palettes prêtes, quai assigné | **NON éligible** pour custom défrag — flux standard prend le relais |
| 09 | Picking partiel sur un OS | 1 SOR, 3 lignes picking, 2 PF revenues, 1 PP au PK | **NON éligible** (on attend la totalité) |
### Cas dégradés
| CT | Description | Préconditions | Résultat attendu |
|----|-------------|---------------|------------------|
| 11 | AGV HS pendant retour PF | PF bloquée sur PK/buffer | **NON éligible** jusqu'à rangement ASRS |
| 12 | Support sous révision | PP → buffer litige, stock réassigné sur PP' | Éligible quand toutes les palettes (réassignations incluses) dans ASRS |
| 13 | Rupture de stock (ATTENTE CLIENT) | SOR1 prêt, SOR2 avec 1 ligne en rupture | **À trancher** : option A (RUT bloqué) ou option B (défrag partielle) |
| 14 | Modification quantité (bouton Problème) | OnStockAdjust recalcule | Si stock suffisant → PF revient, RUT éligible. Si réassignation → attendre PP'/PF' |
| 15 | RUT libéré, aucune PP partie (figé) | Pas de PK disponible | **NON éligible** (picking pas déclenché ≠ prêt). Pas de MAX_DEFRAG_ATTEMPT |
| 16 | Ajout SOR à un RUT déjà éligible | Nouveau SOR avec lignes picking non traitées | **Redevient NON éligible** jusqu'à fin du nouveau SOR |
## Pause et reprise
Le processus peut être mis en pause et repris ultérieurement (par
exemple si l'activité reprend la nuit).
## Points d'attention
⚠️ Les tâches de défragmentation ont une priorité **basse** — elles ne
perturbent pas l'activité normale mais peuvent être longues.
⚠️ MECALUX conseille une présence sur site lors de la défragmentation
en cas de défaut sur les transstockeurs (non obligatoire).
⚠️ L'avancée des tâches est consultable sur la vue des tâches.
⚠️ L'éligibilité est « tout-ou-rien » au niveau tournée. Un seul OS
non prêt bloque toute la défrag du RUT.
## Questions ouvertes
- [ ] Rupture de stock CT-13 : option A (RUT bloqué tant que rupture
non résolue) ou option B (défrag sur les palettes dispo) ? (@Justine)
- [ ] MAX_DEFRAG_ATTEMPT : scope défrag client seul ou aussi défrag par
rotation ? Impact sur la valeur à configurer (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-12 | Arthur | Refonte : ajout custom défrag client par tournée (LIM-87), mécanisme filtre éligibilité, ordonnancement STOP, 16 cas de tests |
| 2026-05-13 | Arthur | Restauration contenu tronqué (caractéristiques, config, custom, cas de tests, points d'attention) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira (stratégies défrag) | 2026 |
| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira (défrag client quai non assigné) | 2026 |
wiki/limagrain/02-stockage/galileo-config.md
+143
View File
@@ -0,0 +1,143 @@
---
title: "Configuration Galileo — Limagrain"
tags: [stockage, galileo, TMS, architecture, IT]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Configuration Galileo — Limagrain
> **Résumé** : architecture logicielle IT de l'installation Limagrain et
> spécificités de la configuration Galileo (TMS).
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md),
> [System Architecture](../../architecture/overview.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
EasyWMS gère l'entrepôt automatique Limagrain avec une base Oracle. Le TMS
Galileo contrôle les 4 transstockeurs, les convoyeurs, navettes et stations
PIE. Les AGV sont gérés par un fournisseur tiers (non Galileo).
## Architecture logicielle
```mermaid
graph TD
SAP[SAP EWM] -->|XML / Webservice| GNA[EasyWMS GNA]
GNA --> EWMS[EasyWMS Serveur]
EWMS --> BBDD[(Oracle DB)]
EWMS --> GW[EasyWMS Gateway]
GW -->|TCP 3000| GAL[Galileo TMS]
GAL --> TK[Transstockeurs x4]
GAL --> CONV[Convoyeurs]
GAL --> NAV[Navettes]
GAL --> PIE[Stations PIE x3]
EWMS --> LP[Label Printer Service]
EWMS --> WEB[Application Web EasyWMS]
EWMS --> PC[Application PC EasyWMS]
WEB --> TRF[Terminaux RF]
AGV[AGV - Fournisseur tiers] -.->|Interface séparée| EWMS
```
### Composants serveur EasyWMS
| Composant | Rôle |
|-----------|------|
| Application serveur EasyWMS | Services de logique et gestion |
| Oracle DB | Base de données |
| EasyWMS GNA | Communication ERP (SAP) via XML/Webservice |
| EasyWMS Gateway | Communication Galileo (protocole frames TCP) |
| EasyWMS Label Printer | Impression étiquettes et documents |
### Communication ERP
- **Protocole** : XML + Webservice
- **ERP** : SAP EWM
- **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
## Stations PIE — Configuration spécifique
3 stations PIE installées :
| Station | Côté | Usage principal |
|---------|------|----------------|
| PIE_01 | Quais (production) | Réception production directe |
| PIE_02 | Postes de travail | Réception ext./retours après traitement |
| PIE_03 | Postes de travail | Idem PIE_02 |
### Mode d'insertion PIE
- **Mode normal** (known containers) : rejet si RFID inconnue
- [CUSTOM] Pas de message ASO au passage PIE
- [CUSTOM] Vérification poids avec tolérances par type article
- [CUSTOM] Mise à jour du « Poids de l'unité » du conteneur à chaque passage
### Contrôle au PIE
| Contrôle | Valeur limite |
|----------|---------------|
| Dimensions max | 1300 × 1100 × 1900 mm |
| Poids max | 1250 kg |
| État palette bois | Correct (visuel Galileo) |
| Lecture RFID | Obligatoire — doit être connue (ASN) |
## Flux physiques dans l'entrepôt
Les flux sont majoritairement réalisés par des **AGV** (fournisseur tiers).
EasyWMS communique les points de prise et de dépose ; le sens de prise/dépose
est géré par le fournisseur AGV.
Deux entrées dans l'ASRS :
| Entrée | Côté | Usage |
|--------|------|-------|
| Entrée production | Quais (PIE_01) | Palettes production, palettes vides |
| Entrée postes de travail | Postes (PIE_02/03) | Palettes après traitement en poste |
> En cas de blocage long terme sur une entrée, un bouton permet de
> rediriger les flux vers l'autre entrée.
## Rétention des données
| Entité | Durée standard | Souhait Limagrain |
|--------|----------------|-------------------|
| Transactions | 6 mois | 2 ans |
| Movements | 6 mois | 2 ans |
| Outbound Orders | 1 an | 2 ans |
| Inbound Orders | 1 an | 2 ans |
| Tasks | 1 an | 2 ans |
| Stock adjustments | 1 an | 2 ans |
> ⚠️ Mecalux doit étudier l'impact de la rétention 2 ans sur les prérequis
> serveurs pour éviter saturation DB et lenteurs.
## Points d'attention
⚠️ Les interfaces AGV sont définies dans un document annexe séparé et
peuvent impacter les flux fonctionnels.
⚠️ La banderoleuse (filmeuse) est située avant le PIE côté postes de
travail — un contrôle capacité filmeuse est fait en amont du PIE.
## Questions ouvertes
- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
- [ ] Fournisseur AGV définitif et protocole d'interface (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/palettes-vides.md
+124
View File
@@ -0,0 +1,124 @@
---
title: "Gestion des palettes vides"
tags: [stockage, palettes-vides, réapprovisionnement, expédition]
status: draft
standard_ref: concepts/container-management.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Gestion des palettes vides
> **Résumé** : gestion des piles de palettes vides dans EasyWMS —
> réception, stockage, réapprovisionnement des postes et expédition.
> **Standard EasyWMS** : → voir [Container Management](../../concepts/container.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les palettes vides sont intégrées dans le périmètre EasyWMS. Leur gestion
est faite **uniquement en pile** — aucune palette vide n'est traitée de
façon unitaire.
## Typologie
- Dimensions : US (1000 × 1200 mm)
- Type unique : NIMP15
- Stockage : piles de **10 palettes vides**
## Réception
Les piles de palettes vides sont réceptionnées au niveau des quais.
Type de réception : **Réception palettes vides**. L'article est nommé
« PILE DE 10 PALETTES ».
**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé —
contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
de travail. Destination : stockage direct dans l'ASRS.
> **Remarque** : en cas de blocage long terme sur l'entrée quai, un bouton
> permet de rediriger manuellement les palettes vers l'entrée « Postes de
> travail ».
## Stockage
### Dans l'ASRS
- Priorité : allées 2, 3 et 4 (TK02-04)
- Position : au plus proche de l'entrée/sortie pour réapprovisionner
rapidement les postes
- Stratégie de rangement : voir
[Stratégies de rangement](putaway-strategies.md) — type 5
- Consultation : vue des stocks avec filtre sur l'article « palettes vides »
### Au niveau des postes de travail
- **2 piles par îlot de travail** (et non par poste individuel)
- Création d'un **emplacement picking dédié** pour chaque emplacement
physique accueillant les stocks de palettes vides (permet le
réapprovisionnement automatique sur seuil)
## Réapprovisionnement
### Sur poste de travail
- Chaque poste est équipé d'une aide à la manutention (prise palette
sur la pile → dépose sur table de préparation)
- Action **manuelle**, non pilotée par EasyWMS
- En cas de regroupement : l'opérateur peut reposer une palette vide
sur la pile
> ⚠️ La pile doit être parfaitement remontée pour passer le contrôle
> gabarit au PIE.
[CUSTOM] Quand la pile est vide :
- **Bouton WfAction** dans la workstation pour demander le
réapprovisionnement
- L'opérateur choisit la pile à réapprovisionner parmi une liste
(paramètre par PK avec noms des emplacements)
- Quand l'emplacement devient vide (via bouton WfAction) →
réapprovisionnement automatique déclenché
- Bouton inverse pour renvoyer une pile au stockage
### Sur le poumon
- Réapprovisionnement **automatique** des 2 emplacements poumon quand
un emplacement est vidé (tâche depuis ASRS)
## Expédition
Les piles de palettes vides peuvent être expédiées :
1. Création **manuelle** d'un ordre de sortie
2. Renseigner la destination : table de préparation (poste) OU image de quai
3. Une fois expédiées → sorties des stocks EasyWMS
## Points d'attention
⚠️ Gestion uniquement en pile (jamais unitaire) — simplifie le suivi
mais impose des manipulations par lot de 10.
⚠️ Le nombre de piles en stock est visible en filtrant la vue des stocks
sur l'article spécifique des palettes vides.
⚠️ La pile doit être correctement empilée pour ne pas être rejetée
au PIE (contrôle gabarit).
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : emplacement picking dédié, 2 piles/îlot, WfAction |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki/limagrain/02-stockage/processus-anoxie.md
+154
View File
@@ -0,0 +1,154 @@
---
title: "Processus d'anoxie — TK01"
tags: [stockage, anoxie, TK01, flag, custom, processus]
status: draft
standard_ref: concepts/warehouse-processes.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Processus d'anoxie — TK01
> **Résumé** : processus [CUSTOM] de traitement par anoxie dans l'allée 1,
> incluant le flag « A anoxier », la relocalisation et le blocage d'allée.
> **Standard EasyWMS** : → voir [Warehouse Processes](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'anoxie consiste à baisser le niveau d'oxygène dans l'allée 1 (TK01)
pour éliminer d'éventuels nuisibles dans les semences. Ce processus est
spécifique au domaine des semences et n'existe pas dans le standard EasyWMS.
## Caractéristiques
- **Localisation** : allée 1 uniquement (TK01)
- **Durée** : 3 à 4 semaines en moyenne
- **Fréquence** : 2 fois par an
- **Déclenchement** : manuel
- **Impact** : allée et stock bloqués pendant toute la durée
En dehors des périodes d'anoxie, la zone est utilisée pour du stockage
normal en priorisant les palettes à anoxier. Chaque compartiment a un
taux d'oxygène contrôlé.
## [CUSTOM] Flag « A anoxier »
### Attribution automatique
Tous les stocks des palettes issues des processus suivants reçoivent
automatiquement le flag « A anoxier » car elles présentent des risques
de contamination :
- Réceptions extérieures / intersites
- Retours client
Condition : la palette doit passer par un poste de travail.
### Attribution manuelle
Il est également possible d'assigner le flag manuellement sur des stocks
spécifiques depuis la vue des stocks.
### Retrait du flag
- **Automatique** : à la fin du processus d'anoxie (bouton « Fin d'anoxie »)
- **Manuel** : par un utilisateur, qui devra saisir une date de dernière
anoxie
## Cas particuliers
- Des stocks d'une même référence (article-lot) peuvent posséder des dates
de dernière anoxie différentes — ces stocks ne sont pas physiquement
différenciables
- Si une palette contient du stock « mixte » dont certaines lignes ont le
flag et d'autres pas → toutes les lignes sont considérées « A anoxier »
## Processus complet
```mermaid
flowchart TD
START[Décision lancer anoxie] --> SEL1[1. Sélection palettes à évacuer de TK01]
SEL1 --> RELOC1[Relocalisation vers TK02-04]
RELOC1 --> SEL2[2. Sélection palettes à anoxier]
SEL2 --> RELOC2[Relocalisation vers TK01]
RELOC2 --> BLOCK[3. Blocage manuel allée 01]
BLOCK --> WAIT[Anoxie en cours — 3 à 4 semaines]
WAIT --> FIN[4. Bouton « Fin d'anoxie »]
FIN --> UPDATE[MAJ date dernière anoxie + suppression flag]
UPDATE --> DEBLOCK[Déblocage manuel allée 01]
```
### Étape 1 — Évacuation des palettes non concernées
- Sélection manuelle depuis la vue des conteneurs (filtre sur flag
« A anoxier »)
- Relocalisation vers une autre allée (en masse, voir déplacement
de conteneurs)
### Étape 2 — Relocalisation des palettes à anoxier
- Sélection manuelle des palettes avec flag « A anoxier »
- Relocalisation vers TK01 dans la mesure des emplacements disponibles
[CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
automatiquement les tâches de relocalisation.
### Étape 3 — Blocage
- Blocage **manuel** de l'allée 01 sur EasyWMS
- Le stock et l'allée deviennent indisponibles
### Étape 4 — Fin d'anoxie
- [CUSTOM] Bouton « Fin d'anoxie » qui :
- Met à jour la date de dernière anoxie
- Supprime automatiquement le flag « A anoxier » pour chaque ligne
de stock présente dans l'allée
- Déblocage manuel de l'allée 01
## Suivi et rapports
- Extraction de la vue des stocks avec filtres « A anoxier » et
« date de dernière anoxie » pour établir le rapport souhaité
- L'avancée des tâches de relocalisation est consultable sur la vue
des tâches
## Lien avec les stratégies de rangement
Les palettes avec flag « A anoxier » ont une stratégie de rangement
dédiée qui priorise TK01 (voir
[Stratégies de rangement](putaway-strategies.md) — type 1).
## Points d'attention
⚠️ La relocalisation peut prendre un temps significatif selon les
quantités sélectionnées.
⚠️ MECALUX conseille d'avoir une personne sur site lors du lancement
de la défragmentation/relocalisation en cas de défaut sur les
transstockeurs (non obligatoire).
⚠️ Le processus d'anoxie peut être mis en pause et repris ultérieurement
en cas de reprise d'activité.
## Questions ouvertes
- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/putaway-strategies.md
+113
View File
@@ -0,0 +1,113 @@
---
title: "Stratégies de rangement Limagrain"
tags: [stockage, putaway, stratégie, rangement, canaux]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Stratégies de rangement Limagrain
> **Résumé** : 5 stratégies de rangement distinctes selon la typologie de la
> palette, avec des règles de sélection de canal et d'allée spécifiques.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le premier filtre appliqué aux palettes détermine la stratégie de rangement.
Limagrain n'utilise pas de classes de rotation ABC — la répartition se fait
sur la nature fonctionnelle de la palette.
## Stratégie 1 — Palettes avec flag « A Anoxier » (mono ou multi lot)
Objectif : stocker en priorité dans TK_01 (zone anoxie).
| Priorité | Règle |
|----------|-------|
| 1 | TK01 — canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
| 2 | TK01 — canal vide |
| 3 | TK01 — canal incomplet avec autre référence |
| 4 | Appliquer la stratégie sans flag « A Anoxier » (stratégie 2 ou 3) |
| 5 | REJET |
## Stratégie 2 — Palettes mono lot sans flag « A Anoxier »
Objectif : optimiser le taux de remplissage et répartir le stock entre allées.
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet même lot SAP + mêmes attributs logistiques |
| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) — taille optimale vs nb palettes ASN restantes |
| 3 | Canal le plus adapté aux nb palettes ASN restantes (toute allée) |
| 4 | REJET |
**Sélection du canal** : canal le plus grand possible qui sera rempli
complètement, ou canal qui laissera le moins de positions vides.
## Stratégie 3 — Palettes multi lot sans flag « A Anoxier »
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet mixte |
| 2 | Canal vide |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Stratégie 4 — Palettes d'expédition (mono ou multi lot)
Objectif : stocker dans la zone défragmentation client, regroupées par route.
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet avec palettes de la même route — zone défragmentation client |
| 2 | Canal vide — zone défragmentation client |
| 3 | PAS DE MOUVEMENT (palette reste en place) |
## Stratégie 5 — Piles de palettes vides
Article type « Palette » (NIMP15).
| Priorité | Règle |
|----------|-------|
| 1 | Canal incomplet le plus proche de l'entrée avec piles de palettes vides |
| 2 | Canal vide le plus proche de l'entrée (hors TK01) |
| 3 | Canal incomplet (tout) |
| 4 | REJET |
## Critères transverses
- **Réservation de canal** : le nombre de palettes en ASN non encore reçues
détermine la capacité optimale du canal à réserver (stratégie 2)
- **Équilibrage inter-allées** : pour les palettes mono lot, EasyWMS répartit
le stock entre allées différentes quand un canal plein existe déjà
- **Hauteur** : la hauteur de la première palette au PIE détermine le type
de rack compatible (RACK01 ≤1150, RACK02 ≤1950, RACK03 ≤2250)
## Points d'attention
⚠️ Si aucun emplacement n'est trouvé → palette rejetée vers le poste de
rejet configuré (sauf stratégie 4 où la palette reste sur place).
⚠️ Les palettes d'expédition ne sont déplacées en zone défragmentation
qu'après assignation de stock (post-libération de l'OS).
⚠️ La stratégie 1 (anoxie) utilise un fallback vers les stratégies 2/3
si TK_01 est plein — important en période hors-anoxie.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/02-stockage/zones-stockage.md
+85
View File
@@ -0,0 +1,85 @@
---
title: "Zones de stockage Limagrain"
tags: [stockage, zones, anoxie, défragmentation, ASRS]
status: draft
standard_ref: concepts/putaway.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Zones de stockage Limagrain
> **Résumé** : Limagrain dispose de 3 zones de stockage dans l'ASRS, chacune
> avec un rôle spécifique : anoxie, stockage principal, défragmentation client.
> **Standard EasyWMS** : → voir [Putaway](../../concepts/putaway.md),
> [Location](../../concepts/location.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'entrepôt automatique Limagrain comporte **4 allées** (TK_01 à TK_04). Les
zones de stockage ont été définies pour répondre à deux besoins métier :
1. **Anoxie** : traitement insecticide par réduction d'oxygène sur TK_01
2. **Défragmentation client** : pré-positionnement des palettes assignées à
une route avant expédition (optimise les temps de sortie)
## Configuration des zones
| Zone | Transstockeur | X initial | X final | Y initial | Y final |
|------|---------------|-----------|---------|-----------|---------|
| Zone Anoxie | TK_01 | 1 | 69 | 1 | 10 |
| Zone Principale | TK_02, 03 & 04 | 1 | 59 | 1 | 10 |
| Zone Principale (ext.) | TK_02, 03 & 04 | 60 | 69 | 1 | 1 |
| Zone Défragmentation client | TK_02, 03 & 04 | 60 | 69 | 2 | 10 |
> ⚠️ Cette répartition peut être modifiée par un administrateur Limagrain
> selon les besoins opérationnels.
## Comportement par zone
### Zone Anoxie (TK_01)
- Réservée **en priorité** aux palettes avec le flag « A anoxier »
- Hors période d'anoxie, utilisée comme stockage normal (priorité anoxie)
- Durant l'anoxie (3-4 semaines, 2x/an) : allée + stock bloqués
- Voir [Processus d'anoxie](../08-transverse/decisions-architecture.md)
### Zone Principale (TK_02, 03 & 04)
- Stockage général : articles et piles de palettes vides
- Pas de distinction de classe de rotation (pas d'ABC)
- Stratégie de répartition inter-allées pour équilibrer la charge
### Zone Défragmentation client (TK_02, 03 & 04, X=60-69, Y=2-10)
- Palettes assignées à un ordre de sortie (post stock assignment)
- Regroupement par route/stop pour optimiser le séquencement à l'expédition
- Les palettes y sont déplacées automatiquement après libération de l'OS
## Points d'attention
⚠️ Les piles de palettes vides sont stockées en priorité dans les allées
02, 03 & 04, au plus proche des entrées/sorties (canaux bas en X).
⚠️ Le convoyeur de sortie TS01 dans TK_01 crée une **exception de stockage** :
pas de canaux en X=21/Y=1, X=21/Y=2, X=22/Y=1.
⚠️ Taux minimum de 5% d'emplacements libres recommandé par Mecalux pour
la défragmentation et les relocalisations.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/03-picking/.fuse_hidden0000002f00000010
+148
View File
@@ -0,0 +1,148 @@
---
title: "Consolidation (regroupement) — Processus sur poste"
tags: [picking, regroupement, consolidation, MOV, poste, custom]
status: draft
standard_ref: concepts/picking.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Consolidation (regroupement) — Processus sur poste
> **Résumé** : processus [CUSTOM] de consolidation de palettes incomplètes
> partageant les mêmes critères de stock, sur poste de travail.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le regroupement permet de vider des palettes partiellement remplies en
déplaçant leur stock vers d'autres palettes contenant le même stock.
L'objectif est de libérer des emplacements dans l'ASRS.
## Critères de consolidation
Le regroupement est proposé quand deux palettes ou plus partagent :
- Article
- Lot SAP
- Propriétaire
- Statut de stock
- Flag anoxie
## [CUSTOM] Vue de proposition de regroupement
Une vue spécifique est développée pour Limagrain. Elle présente :
- Les palettes candidates au regroupement
- Le gain potentiel en nombre de palettes
**Règle** : le regroupement n'est proposé que s'il permet de gagner au
moins 1 palette. Exemple : Bag/Pal = 75, si palette H1 = 73 et H2 = 5
→ pas de regroupement (73 + 5 = 78 > 75, pas de gain).
L'opérateur sélectionne un ou plusieurs ordres de regroupement depuis
cette vue.
## Processus complet
```mermaid
flowchart TD
VUE[Vue proposition regroupement] --> SELECT[Sélection ordres]
SELECT --> ASSIGN[Assignation poste automatique]
ASSIGN --> TACHE[Création tâches mouvement]
TACHE --> ORD[Ordonnancement palettes au poste]
ORD --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PICK[Déplacement sacs]
RECOUNT --> PICK
PICK --> VIDE{Palette vidée ?}
VIDE -->|Oui| DEGAGE[Dégagement palette vide]
VIDE -->|Non| PICK
DEGAGE --> EVAC[Évacuation palette stock]
EVAC --> FILM[Choix filmage]
FILM --> PIE[Passage PIE]
PIE --> STOCK[Stockage ASRS]
```
## Assignation poste de travail
- Assignation **automatique** quand un ordre est lancé
- [CUSTOM] Si le lot a un Bag/Pal ≤ 2 → considéré « big-bag » →
seul le **poste P6** (équipé d'un palan) est assignable
- Un big-bag ne peut être consolidé que sur un autre big-bag
- Si P6 n'est pas en mode regroupement → tâche en attente
- Si aucun poste disponible → ordre en attente de libération
## [CUSTOM] Ordonnancement des palettes au poste
Une fois l'ordre lancé et le poste assigné, les palettes arrivent dans
cet ordre :
1. **Minimum de mouvements palette** (moins de déplacements physiques)
2. **Minimum de mouvements sac** (moins de manipulations)
3. **Palette complète** (en priorité la palette destinataire)
## Exécution sur poste
1. [CUSTOM] Si verrou « Réception » → recomptage avant regroupement
2. Les sacs de la palette à éliminer sont déplacés vers la palette
destinataire
3. Quand la palette est vidée → dégagement de la table de préparation
4. Évacuation de la palette avec stock restant via bouton EasyWMS
5. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
6. [CUSTOM] Message **MOV** à chaque déplacement de stock :
- Palette d'origine
- Palette de destination
- Nouvelle palette ? (Oui/Non)
- Quantité + caractéristiques (article, lot SAP, ...)
## Passage PIE post-regroupement
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État palette bois correct
- Étiquette RFID connue
[CUSTOM] Calcul poids de référence :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Vérification avec tolérance par type d'article (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ Le message MOV est envoyé à chaque mouvement unitaire — volumétrie
potentiellement élevée pour un regroupement complexe.
⚠️ Les 3 tables de préparation d'un même poste peuvent être occupées
simultanément pendant le regroupement.
⚠️ Un big-bag ne peut être consolidé que sur un autre big-bag (contrainte
physique + système).
## Questions ouvertes
- [ ] Programme de filmage exact pour le regroupement (@Théo)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/03-picking/.fuse_hidden0000003100000011
+145
View File
@@ -0,0 +1,145 @@
---
title: "Échantillonnage — Processus de contrôle qualité"
tags: [picking, échantillonnage, inventaire, qualité, poste, custom]
status: draft
standard_ref: concepts/inventory.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Échantillonnage — Processus de contrôle qualité
> **Résumé** : processus [CUSTOM] d'échantillonnage pour contrôle qualité,
> assimilé à un inventaire dans EasyWMS, avec prélèvement sur poste de travail.
> **Standard EasyWMS** : → voir [Inventory](../../concepts/inventory.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'échantillonnage sert au contrôle qualité sur une partie des lots
produits. Il consiste à prélever environ 200 grammes dans une partie du
stock sélectionné. Le prélèvement est ensuite analysé pour valider la
qualité du produit fini.
Dans EasyWMS, ce processus est assimilé à un **inventaire** (ordre
d'inventaire).
## Création de l'ordre d'échantillonnage
Deux modes de création :
| Mode | Origine | Détail |
|------|---------|--------|
| Interface ERP | Message de l'ERP (COR) | Spécifie un lot à inventorier |
| Manuel | Interface EasyWMS | Choix d'un lot par l'opérateur |
[CUSTOM] Un champ texte est disponible pour donner des **consignes**
rattachées à l'ordre d'inventaire.
## [CUSTOM] Assignation du stock
L'assignation diffère selon le mode de création :
### Création par interface ERP
- Maximum **4 palettes** échantillonnées :
- Si stock global < 4 → toutes les palettes
- Si stock global ≥ 4 → 4 palettes sélectionnées
- [CUSTOM] Les palettes avec un verrou d'écart de poids (« Production »)
sont **prioritaires** pour permettre une vérification simultanée
### Création manuelle
- Nombre de palettes choisi par l'opérateur
## Assignation poste de travail
- Automatique, à condition que le poste soit ouvert et autorise le
mode « échantillonnage »
- Si aucun poste paramétré en mode échantillonnage → tâches en attente
- Une fois le poste assigné → création des tâches de mouvement
## Processus sur poste de travail
```mermaid
flowchart TD
ORDRE[Ordre échantillonnage] --> ASSIGN[Assignation stock]
ASSIGN --> POSTE[Assignation poste auto]
POSTE --> TACHE[Tâches mouvement créées]
TACHE --> ARRIVE[Palette arrive sur TP]
ARRIVE --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PRELEV[Prélèvement ~200g]
RECOUNT --> PRELEV
PRELEV --> ETIQ[Impression étiquette échantillonnage]
ETIQ --> SCOTCH[Scotch sac ouvert]
SCOTCH --> FILM[Choix filmage]
FILM --> EVAC[Évacuation → PIE → stockage]
EVAC --> NEXT{Palette suivante ?}
NEXT -->|Oui| ARRIVE
NEXT -->|Non| FIN[Fin ordre]
```
Les 3 tables de préparation peuvent être occupées simultanément.
Le processus est démarré et effectué sur **une seule palette à la fois**.
### Séquence opérateur
1. [CUSTOM] Si verrou « Réception » → recomptage avant échantillonnage
2. Prendre une pochette d'échantillonnage vide (hors EasyWMS)
3. Effectuer un prélèvement dans un des sacs (~200g, hors EasyWMS)
4. Déposer le prélèvement dans la pochette (hors EasyWMS)
5. Éditer et imprimer une **étiquette d'échantillonnage**
6. Coller l'étiquette sur la pochette (hors EasyWMS)
7. Scotcher le sac ouvert sur la palette (hors EasyWMS)
8. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
9. Évacuer la palette vers le stockage
## Passage PIE post-échantillonnage
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- Étiquette RFID connue
- État palette bois correct
[CUSTOM] Poids de référence recalculé + vérification avec tolérance
(voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
Si PIE NOK → rejet vers poste d'origine. Possibilité de forcer le
passage en cas d'excédent de poids non corrigeable.
## Points d'attention
⚠️ L'échantillonnage est un processus d'**inventaire** dans EasyWMS,
pas un processus de picking — important pour le paramétrage des modes
de poste.
⚠️ Les palettes avec verrou « Production » (écart poids) sont traitées
en priorité pour optimiser le recomptage.
⚠️ La quantité prélevée (~200g) n'est pas déduite du stock dans EasyWMS
(négligeable par rapport au poids total).
## Questions ouvertes
- [ ] Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)
- [ ] Programme de filmage exact (@Théo)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/03-picking/.fuse_hidden0000003300000012
+211
View File
@@ -0,0 +1,211 @@
---
title: "Mega Job — Assignation des tâches aux PK"
tags: [picking, job, assignation, agv, workflow]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-70, LIM-74, LIM-75, LIM-80]
confluence_refs: []
sources: ["LIM-70 LOT1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK.md", "LIM-80 LOT2.1 2 Mini Job Assignation des postes PK aux commandes.md"]
last_updated: 2026-05-12
author: Arthur
---
# Mega Job — Assignation des tâches aux PK
> **Résumé** : job unique « chef d'orchestre » qui analyse les postes de
> travail éligibles et leur assigne des tâches de mouvement selon les
> modes autorisés et leur priorité. Évite la concurrence entre
> mini-jobs indépendants.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md),
> [Stations & Routes](../../concepts/stations.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chez Limagrain, les postes de travail (PK) sont polyvalents : réception,
picking, regroupement, échantillonnage, re certification. Plusieurs
flux différents génèrent des tâches de mouvement vers les PK. Sans
orchestration centralisée, ces flux se feraient concurrence.
Le Mega Job est un **job unique** avec une entête qui analyse l'ensemble
des supports concernés et, selon leur emplacement d'origine et leurs
caractéristiques, délègue à des **sous-workflows** dédiés.
## Éligibilité d'un PK
Pour qu'un poste soit éligible à une nouvelle assignation, **toutes** les
conditions suivantes doivent être remplies :
- **Aucun ordre de sortie** assigné au PK (écran Menu > Contrôle >
Affectation des postes de prélèvements)
- **Aucune tâche de mouvement** ayant pour destination ce PK
- **Aucune palette** présente sur un des sous-emplacements du PK
- **Le poste est ouvert** (mode actif)
- **Le paramètre MODES_PKxx existe et n'est pas vide** — sinon le PK
est ignoré
Si un PK ne remplit pas ces conditions, le job le saute et passe au
suivant.
## Logique principale
```mermaid
flowchart TD
A[Début du job] --> B[Lister les PK ouverts]
B --> C{PK éligible ?}
C -- Non --> D[PK suivant]
C -- Oui --> E[Lire MODES_PKxx]
E --> F{Paramètre existe et non vide ?}
F -- Non --> D
F -- Oui --> G[Trier les modes par priorité]
G --> H[Exécuter sous-WF du mode priorité 1]
H --> I{Tâche assignée ?}
I -- Oui --> D
I -- Non --> J[Exécuter sous-WF du mode priorité 2]
J --> K{Tâche assignée ?}
K -- Oui --> D
K -- Non --> L[... mode suivant ...]
L --> D
D --> M{Autres PK ?}
M -- Oui --> C
M -- Non --> N[Fin du job]
```
Pour chaque PK éligible :
1. Le WMS récupère le paramètre `MODES_PKxx` (x = numéro du poste)
2. Les modes sont triés par priorité croissante
3. Le sous-workflow du mode de priorité la plus haute est exécuté
4. Si le sous-WF a assigné une tâche → passage au PK suivant
5. Sinon → exécution du sous-WF du mode suivant dans l'ordre de priorité
6. Si aucun sous-WF n'a rien assigné → le PK reste en attente
## Gestion des Big-Bags
Le paramètre `PK_BIGBAG` définit quels PK autorisent la présence de
big-bags (physiquement : P5 et P6 avec palan).
- Les ordres contenant des supports big-bag sont **interdits** sur les
PK qui ne les autorisent pas
- Ces ordres sont **prioritaires** (en respectant le séquençage des
process en première priorité) sur les PK qui les autorisent
## Sous-workflows
Le Mega Job délègue la création effective des tâches à des sous-workflows
spécialisés :
| Sous-WF | Ticket | Process | Page wiki |
|---------|--------|---------|-----------|
| Mini Job images de quai → PK | [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Réception fournisseur / intersite / retour client (depuis images de quai) | [Job réception PK](../05-agv/job-reception-pk.md) |
| Mini Job PS → PK | [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | _(tâche à écrire)_ | — |
| Mini Job assignation commandes → PK | [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Assignation des ordres de sortie (commandes) aux PK pour picking | Voir section ci-dessous |
Chaque sous-workflow retourne une information au WF principal indiquant
s'il a assigné quelque chose ou non.
## Mini Job — Assignation commandes aux PK (LIM-80)
Ce sous-workflow est appelé par le Mega Job quand le mode **Picking** est
actif sur un PK. Il assigne un ordre de sortie (commande) au poste.
### Éligibilité du PK pour une commande
Le PK peut recevoir une commande si **toutes** les conditions sont
remplies :
- Le PK **autorise la préparation de commande** (mode Picking actif)
- Le PK **n'a pas de commande déjà assignée**
- Le PK **est vide** (aucune palette présente)
- Le PK **n'a aucune tâche en direction de celui-ci**
### Choix de la commande
```mermaid
flowchart TD
A[PK éligible en mode Picking] --> B{Commande Messagerie\ndisponible ?}
B -- Oui --> C{PK_TRANSPORTEUR_MESSAGERIE\ncontient une valeur ?}
C -- Non --> D[Assigner 1ère Messagerie\net enregistrer PK dans param]
C -- Oui --> E{Valeur = ce PK ?}
E -- Oui --> F[Assigner prochaine Messagerie\ndu même transporteur]
F --> G{Commande trouvée ?}
G -- Non --> H[Vider le paramètre]
E -- Non --> I[Ignorer les Messagerie\nde ce transporteur]
I --> J[Chercher autre commande]
B -- Non --> J
H --> J
J --> K[Assignation standard\npar tournée / numéro d'arrêt]
```
#### Commandes Messagerie (prioritaires)
Les commandes de **classe Messagerie** sont expédiées le jour même et
sont donc **prioritaires** sur les autres commandes.
**Affinité transporteur ↔ PK** : une fois qu'un PK est choisi pour une
commande Messagerie, **toutes les commandes Messagerie du même
transporteur** doivent être assignées au même PK. Le mécanisme repose
sur un paramètre par transporteur :
- `PK_TRANSPORTEUR_MESSAGERIE` : contient le code du PK assigné
- Si le paramètre contient une valeur correspondant au PK analysé →
assigner la prochaine commande Messagerie de ce transporteur
- Si la valeur correspond à un **autre PK** → ignorer toutes les
Messagerie de ce transporteur pour ce PK
- Si le PK a le paramètre mais qu'**aucune commande** Messagerie de ce
transporteur n'est trouvable → **vider le paramètre**
- Si le paramètre contient le nom du PK → le PK ne peut assigner **que**
des Messagerie de ce transporteur (exclusivité tant que le
paramètre est actif)
#### Autres commandes (standard)
Le processus standard est utilisé : assignation d'une commande à une
table de préparation et un PK, en respectant l'ordre de la **tournée**
(numéro d'arrêt croissant — plus petit numéro d'arrêt en premier).
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| MODES_PKxx | Modes autorisés + priorité pour le PK xx (un par PK, renseigné via la vassist — voir [Stations picking](stations-picking.md)) | _(vide)_ |
| PK_BIGBAG | PK autorisant les big-bags | _(à définir — P5, P6)_ |
| PK_TRANSPORTEUR_MESSAGERIE | Code PK assigné au transporteur Messagerie en cours (un paramètre par transporteur) | _(vide)_ |
## Points d'attention
> **À reprendre par @Michael** : l'entête du job doit checker tous les
> PK en attente de tâche, vérifier leurs modes autorisés et la séquence
> de priorité pour entrer dans le sous-WF nécessaire.
- Le job standard `Task_GenerateMovementJob_PR` gère le passage
"en attente" → "créé" ; le Mega Job ne remplace pas ce mécanisme
mais crée les tâches en amont
- Un PK fermé n'est jamais éligible — le job le vérifie dès la première
condition
## Questions ouvertes
- [ ] Fréquence d'exécution du Mega Job à définir (@Michael)
- [ ] Sous-WF pour regroupement, échantillonnage : tickets à créer ?
- [ ] Interaction entre PK_BIGBAG et les modes : si P5 est en mode
regroupement, accepte-t-il quand même les big-bags en réception ?
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-70 |
| 2026-05-12 | Arthur | Ajout sous-WF assignation commandes (LIM-80) |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira | 2026 |
| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira | 2026 |
| [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | Ticket Jira | 2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (modes PK) | 2026 |
| [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation commandes PK) | 2026 |
wiki/limagrain/03-picking/.fuse_hidden0000003500000013
+307
View File
@@ -0,0 +1,307 @@
---
title: "Picking sur poste de travail — Expédition client"
tags: [picking, poste, expédition, ordonnancement, MOV, PCK]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-82]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-82 LOT2.2 [PICKING] Ordonnancement des tâches de picking PS PK.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# Picking sur poste de travail — Expédition client
> **Résumé** : processus [CUSTOM] de picking sur poste de travail pour
> les commandes client, avec ordonnancement par espèce, règles de picking
> négatif et contraintes physiques.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le picking chez Limagrain se fait sur les postes de travail automatisés
(pas de picking mobile en allée). Les palettes source et les palettes
de préparation sont acheminées par AGV sur les tables de préparation (TP).
> **Note** : cette page décrit le picking tel que défini dans l'AF V1.5.
> Le projet a depuis évolué vers un modèle « picking combinatoire »
> (CR V3.0, 4 jobs, CstAtt) qui sera documenté séparément.
## Déclenchement
Le picking est déclenché pour les commandes client (RUT type « Client »)
quand des palettes incomplètes sont nécessaires (la quantité demandée
ne correspond pas à des palettes complètes).
Prérequis : un **poste de travail assigné** (auto ou manuellement).
## [CUSTOM] Ordonnancement des palettes au poste
Une fois le poste assigné, les palettes arrivent dans cet ordre :
### Tri par espèce et gerbabilité
1. **Espèce Maïs** toujours en premier (pas la variété mais l'espèce)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité → **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : le maïs = stack 0 (le plus
lourd/stable, donc en base). [CUSTOM] Gestion en **async sur l'ITM** pour
calculer la gerbabilité automatiquement à la création de l'article. Tri
des tâches de picking dans le workflow `StackerCrane_SortTasks_PR`.
### ~~Séparation par traitement commercial~~ SUPPRIMÉ (réu. 11/05/2026)
~~Pas de mélange entre articles avec traitement et sans traitement
sur une même palette fille.~~
**Décision** : `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt
Limagrain ne fait pas de bio, pas de raison de maintenir cette
contrainte. Paramètre réactivable si besoin futur.
> Voir [Séquençage TK → PS — Arbitrage](sequencage-tk-ps.md#arbitrage-des-contradictions-reu-11052026)
> pour le détail de l'analyse comparative.
## [CUSTOM] Règle du picking négatif
**Deux conditions cumulatives** (réu. 11/05/2026) :
1. La quantité à prélever dépasse le **seuil fiche article** (défaut
55%, paramétrable par article via "Complete quantity percent excess
for negative picking")
2. Le **poids unitaire du sac ≥ 7 kg** (raison : instabilité palette si
gros sacs ramenés sur petits sacs)
Si les deux conditions sont remplies → **picking négatif** : au lieu de
déplacer les sacs à expédier, déplacer les sacs qui **retourneront en
stock** (moins de mouvements physiques).
Si l'une des deux conditions n'est pas remplie → picking direct
classique.
> Le picking négatif est **prioritaire sur Maïs first** et toutes les
> autres règles de tri (confirmé par Olivier, réu. 11/05/2026).
> Voir [Séquençage TK → PS](sequencage-tk-ps.md#critère-1--picking-négatif-en-premier).
## [CUSTOM] Calcul équivalent palette (pro rata Bag/pal)
Pour déterminer si une palette est « pleine », calcul en **pro rata
Bag/pal** (réu. 11/05/2026, remplace la logique DevOps "Bag/pal max") :
```
Équivalent palette d'un sac = 1 ÷ Bag/Pal de son lot
```
Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette :
```
Exemple :
15 sacs lot Bag/pal 20 + 10 sacs lot Bag/pal 75
= 15/20 + 10/75
= 0,75 + 0,133
= 88,3% → il reste ~12% de place
```
Seuil cible : **~95%** de remplissage (marge de sécurité).
Poids max palette : **1 250 kg** (AF fait foi, corrige 1 200 kg du
DevOps).
## [CUSTOM] Verrou « HORS TOLERANCE » — Recomptage
Si la palette source porte le verrou « HORS TOLERANCE » → recomptage
demandé avant le picking (inventaire).
- Si stock restant suffisant après inventaire → assignation maintenue
(workflow `OnStockAdjust` recalcule uniquement si nécessaire — ne casse
pas la tâche en cours)
- Si plus assez de stock → réassignation ailleurs + retrait verrou
## [CUSTOM] Algorithme de répartition des palettes sur les TP
Logique combinatoire complète gérant tous les cas :
- Picking négatif et enchaînement de pickings négatifs
- Ordonnancement par espèce
- Terminer une palette pleine avant d'en entamer une autre
- Cadencement des buffers devant les postes de picking
- Pas de mélange de traitement commercial (via famille d'article)
- **Contrainte** : l'opérateur ne doit **pas déplacer de sacs d'une table
à l'autre** (sacs lourds)
**Table du milieu** : toujours occupée soit par une palette de picking
négatif, soit par une palette vide de dépôt. Quand la palette de
prélèvement est vidée, l'opérateur la remet manuellement sur une pile
de palettes vides à proximité.
> Prévoir un process sans picking négatif pour les cas où c'est rarement
> utilisé (ou monter le seuil, ex : 70% au lieu de 50%).
## Processus de préparation
### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur
un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
### Picking
1. Palette source arrive sur une TP
2. Palette destination (vide ou en cours) sur une autre TP
3. Opérateur prélève les sacs (ou sacs retour si picking négatif)
4. ~~[CUSTOM] Message MOV envoyé à SAP~~ **ANNULÉ** (décision client)
5. Avant évacuation : choix filmage (CstData transmis à Galileo).
Possibilité de choisir « pas de filmage ».
6. Évacuation palette → PIE → contrôle poids → stockage/expédition
## [CUSTOM] Ordonnancement des tâches PS → PK (LIM-82)
Détail du cadencement des palettes depuis les postes de sortie (PS)
vers les postes de picking (PK). Toutes les tâches de picking se font
sur les tables élévatrices des PK.
### Règles de priorité
1. **Picking négatif toujours en premier** — une seule palette à la fois
pour ce process, toujours déposée sur la **table du centre**
2. **Picking classique ensuite** — jusqu'à **2 palettes simultanées** au
PK, déposées sur les **tables latérales**
3. Le WMS peut envoyer **1 palette picking négatif + 1 palette picking
classique** en même temps (pour compléter la palette post-picking
négatif)
4. Le nombre de palettes de prélèvement au PK ne dépasse **jamais 2**
### Picking négatif — Détail
À chaque tâche de picking négatif :
- Un **nouveau code SSCC** est généré pour la palette où l'excédent de
stock est déposé
- Une **étiquette RFID** est imprimée pour cette nouvelle palette
- La palette de picking négatif va toujours au **centre** du PK
### Cadencement des buffers
Les palettes non encore nécessaires au PK sont dirigées vers les
**zones d'attente** (buffers ES_X) s'il y a de la place disponible. Le
WMS **privilégie la sortie des palettes de picking négatif** vers les
buffers.
À chaque palette arrivant au PS, celui-ci vérifie s'il existe d'autres
tâches du même OS avec une **séquence plus faible** :
- Si oui → palette envoyée au **buffer ES_X** (attente)
- Si non → palette envoyée directement au **PK**
### Cas d'exemple — 10 tâches (3 négatif, 7 classique)
1. Le WMS envoie **2 palettes** vers le PK : 1 picking négatif + 1
picking classique
2. Les **8 autres** palettes sont dirigées vers les zones d'attente
(priorité aux palettes de picking négatif)
3. L'opérateur réalise le picking négatif → impression étiquette
SSCC/RFID pour la nouvelle palette
4. L'opérateur réalise le picking classique → stock déposé sur la
palette du milieu
5. Si la palette client n'est pas pleine → le WMS apporte une nouvelle
palette de picking classique
6. L'opérateur déclare la palette client **pleine** → le WMS apporte la
2ᵉ palette de picking négatif
7. Si le picking classique précédent est **en cours** (tâche partielle)
→ pas de nouvelle palette classique. Sinon → 2ᵉ palette classique
envoyée au PK
Voir aussi [Séquençage TK → PS](sequencage-tk-ps.md) pour le
mécanisme amont de tri des tâches entre les transstockeurs et les
postes de sortie, et [Placement PS → PK](placement-ps-pk.md) pour
l'algorithme de choix de table (ping-pong, buffers, évacuation).
## Information passage conteneur client
Le passage en conteneur client est visible dans le **LOC** envoyé
toutes les 5 minutes à SAP (flag « client » = true). Voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md#communication-erp--loc--détails).
## Étiquetage
### Cas standard (non MII ou MII mono lot)
- 1 étiquette RFID pour la palette physique bois
### Cas MII multi lots
- 1 étiquette HU RFID pour la palette physique (HU mère)
- 1 étiquette HU sans RFID par ligne de stock (HU fille / intercalaire)
- Impression auto à chaque nouvelle palette (RFID) et à chaque article
(intercalaire)
- Basé sur la **classe de commande**
## Contraintes opérateur (hors EasyWMS)
Règles non gérées par le système mais à respecter :
1. Palette ne doit pas excéder **1,90 m** (sinon rejet PIE)
2. Palette ne doit pas excéder **1 250 kg** (sinon rejet PIE, AF fait foi)
3. Pas de gerbage de palette
4. Disposition d'intercalaires entre couches
## Calcul poids de référence (post-picking)
Pour les palettes multi-lignes de stock :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Contrôle PIE identique aux autres processus (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ Le picking négatif (seuil 55% ET poids ≥ 7 kg) est une règle métier
custom — les deux conditions sont cumulatives (réu. 11/05/2026).
⚠️ L'ordonnancement espèce → quantité → poids est géré par EasyWMS
(pas un choix opérateur).
⚠️ Le message MOV est **ANNULÉ** (décision réunion client).
⚠️ Le verrou HORS TOLERANCE déclenche un recomptage mais ne casse pas
l'assignation si le stock restant est suffisant.
⚠️ L'algorithme de répartition TP est le « gros morceau » custom du
picking — gestion combinatoire de tous les cas.
## Questions ouvertes
- [x] ~~Programme de filmage exact~~ → 8 programmes documentés (A→H)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
- [x] ~~Process sans picking négatif — seuil à 70% au lieu de 50%~~ →
Tranché : seuil paramétrable par article (défaut 55%) + condition
poids ≥ 7 kg (réu. 11/05/2026)
- [x] ~~Traitement commercial — séparation palette~~ → Supprimé
(`CONTROLE_TRAITEMENT_COMMERCIAL = false`, réu. 11/05/2026)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Gerbabilité/stack, algo répartition TP, verrou HORS TOLERANCE, MOV annulé, arrivée palettes 3 TP, filmage CstData |
| 2026-05-12 | Arthur | Ajout ordonnancement PS→PK (LIM-82) : priorité picking négatif, cadencement buffers, cas d'exemple, lien séquençage TK→PS |
| 2026-05-12 | Arthur | MAJ réunion 11/05 : picking négatif 2 conditions cumulatives (55% + 7 kg), TC supprimé, pro rata Bag/pal, poids max 1 250 kg, questions fermées |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-82](https://easywmsfrance.atlassian.net/browse/LIM-82) | Ticket Jira (ordonnancement PS→PK) | 2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
wiki/limagrain/03-picking/.fuse_hidden0000003700000014
+323
View File
@@ -0,0 +1,323 @@
---
title: "Placement des palettes PS → PK (choix de table)"
tags: [picking, placement, table, buffer, ping-pong, algorithme]
status: draft
standard_ref: concepts/picking.md
jira_refs: []
confluence_refs: []
sources: ["Logique combinatoire picking - PS vers PK - V1.0.md"]
last_updated: 2026-05-12
author: Arthur
---
# Placement des palettes PS → PK (choix de table)
> **Résumé** : algorithme exécuté par le WMS lorsqu'une palette source
> arrive au poste de sortie (PS). Il décide sur quelle table du PK la
> poser, ou la redirige vers un buffer ES. Ce process s'exécute **en
> aval** du [séquençage TK → PS](sequencage-tk-ps.md) : les palettes
> arrivent au PS déjà triées.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence
stricte :
```
TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
✅ adjacentes ✅ adjacentes
TABLE_GAUCHE ←————————————————→ TABLE_DROITE
❌ INTERDIT
```
Règles de mouvement :
- Le stock est **toujours sur une palette**, jamais posé directement sur
la table
- L'opérateur peut déplacer du **stock** (sacs, colis) d'une palette à
une autre **uniquement entre deux tables adjacentes**
- Il est **interdit de déplacer une palette d'une table à une autre** —
seul l'AGV peut déplacer une palette (arrivée, évacuation, recentrage)
- **TABLE_CENTRE** est le pivot : seule table adjacente aux deux autres
## Déclenchement
L'algorithme est appelé **à chaque arrivée physique d'une palette au
PS**. Le PS interroge le WMS qui retourne une réponse parmi :
- **TABLE_GAUCHE**, **TABLE_CENTRE** ou **TABLE_DROITE** → la palette
est envoyée sur cette table
- **Buffer ESx** → aucune table n'est disponible, la palette est
redirigée vers un emplacement buffer
- **Attente** → ni table ni buffer disponible, la palette reste au PS
## Entrées de l'algorithme
| Donnée | Source |
|--------|--------|
| Tâche courante : palette source, article, quantité, type de picking (NÉGATIF / DIRECT), `Line.CstAtt` (séquence) | Tâche associée à la palette |
| État des 3 tables du PK : VIDE, PALETTE_FILLE_ACTIVE, PALETTE_FILLE_EN_ATTENTE, PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE, EN_ATTENTE_EVACUATION | État temps réel du PK |
| Tâches suivantes de l'OS (triées par `Line.CstAtt` croissant) | OS en base |
| Buffers ES disponibles : parmi ES1–ES16, ceux non occupés ni ciblés | État temps réel des buffers |
| Nombre de buffers déjà affectés à ce PK vs `MAX_PRELOAD_PAR_PK` (défaut : 3) | Compteur par PK |
## Décision niveau 1 : table du PK ou buffer ?
```
FONCTION décider_destination(palette, PK) :
table_cible ← choisir_table(palette, PK)
SI table_cible ≠ NULL :
RETOURNER table_cible
// Aucune table disponible → tenter un buffer
SI nb_buffers_affectés(PK) < MAX_PRELOAD_PAR_PK :
buffer ← premier ES libre
SI buffer existe :
RETOURNER buffer
// Ni table ni buffer disponible
RETOURNER ATTENTE
```
## Décision niveau 2 : choix de la table
Le choix dépend du **type de picking** de la tâche associée.
### Cas PICKING_NÉGATIF
En picking négatif, la palette source arrive sur une table, l'opérateur
retire l'excédent sur une palette posée sur une **table adjacente**,
puis échange d'étiquettes. La palette a besoin de **2 tables** : une
pour elle, une adjacente libre pour l'excédent.
```
FONCTION choisir_table_picking_négatif(PK) :
// Priorité 1 : centre + un côté libre
SI TABLE_CENTRE == VIDE ET (TABLE_GAUCHE == VIDE
OU TABLE_DROITE == VIDE) :
RETOURNER TABLE_CENTRE
// Priorité 2 : côté + centre libre
SI (TABLE_GAUCHE == VIDE OU TABLE_DROITE == VIDE)
ET TABLE_CENTRE == VIDE :
RETOURNER côté vide
// Priorité 3 : centre libre + un côté libérable
SI TABLE_CENTRE == VIDE ET un côté est libérable :
évacuer(côté libérable)
RETOURNER TABLE_CENTRE
// Priorité 4 : un côté libre + centre libérable
SI un côté == VIDE ET TABLE_CENTRE est libérable :
évacuer(TABLE_CENTRE)
RETOURNER côté vide
// Dernier recours : évacuation forcée
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_picking_négatif(PK) // rappel
```
### Cas PICKING_DIRECT
La palette source doit être posée sur une table **adjacente à la
palette fille active**. Le choix se fait en fonction de l'emplacement
de la palette fille.
```
FONCTION choisir_table_picking_direct(tâche, PK) :
// Étape 1 : localiser la palette fille compatible
table_fille ← localiser_palette_fille(tâche, PK)
SI table_fille == NULL :
table_fille ← choisir_table_nouvelle_palette_fille(PK)
// Étape 2 : choisir une table adjacente
tables_adj ← tables_adjacentes(table_fille)
// Prio A : palette source déjà sur une adjacente
// (multi-tâches même palette)
POUR chaque t DANS tables_adj :
SI t contient tâche.PALETTE_SOURCE :
RETOURNER t
// Prio B : adjacente VIDE
// Si 2 adjacentes libres (PF au centre) → ping-pong
adjacentes_vides ← [t POUR t DANS tables_adj SI t == VIDE]
SI len(adjacentes_vides) == 2 :
RETOURNER choisir_côté_ping_pong(PK)
SI len(adjacentes_vides) == 1 :
RETOURNER adjacentes_vides[0]
// Prio C : adjacente en cours d'évacuation (AGV en route)
POUR chaque t DANS tables_adj :
SI t == EN_ATTENTE_EVACUATION :
RETOURNER t
// Prio D : forcer l'évacuation d'une adjacente
t_à_libérer ← choisir_table_à_évacuer(tables_adj)
évacuer(t_à_libérer)
RETOURNER t_à_libérer
```
### Localisation de la palette fille compatible
```
FONCTION localiser_palette_fille(tâche, PK) :
// Parmi les PF actives
POUR chaque table :
SI table.état == PALETTE_FILLE_ACTIVE :
RETOURNER table
// Note : CONTROLE_TRAITEMENT_COMMERCIAL = false,
// donc pas de filtre TC
// Puis parmi les PF en attente
POUR chaque table :
SI table.état == PALETTE_FILLE_EN_ATTENTE :
RETOURNER table
RETOURNER NULL
```
### Choix de table pour une nouvelle palette fille
```
FONCTION choisir_table_nouvelle_palette_fille(PK) :
// TABLE_CENTRE = pivot → maximise la flexibilité
SI TABLE_CENTRE == VIDE : RETOURNER TABLE_CENTRE
SI TABLE_GAUCHE == VIDE : RETOURNER TABLE_GAUCHE
SI TABLE_DROITE == VIDE : RETOURNER TABLE_DROITE
// Aucune table vide → forcer une évacuation
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_nouvelle_palette_fille(PK)
```
## Optimisation ping-pong
Le ping-pong est l'optimisation principale pour le débit. Il n'est
possible que lorsque la **palette fille est au centre** : les palettes
sources alternent alors entre TABLE_GAUCHE et TABLE_DROITE, de sorte
que la palette suivante est déjà en place quand l'opérateur termine.
```
FONCTION choisir_côté_ping_pong(PK) :
SI TABLE_GAUCHE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_DROITE
SI TABLE_DROITE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_GAUCHE
// Aucun côté occupé → choix arbitraire
RETOURNER TABLE_GAUCHE
```
**Recentrage** : si la palette fille est sur un côté (issue d'un
picking négatif), le ping-pong est impossible. Si le nombre de
PICKING_DIRECT restants ≥ `SEUIL_RECENTRAGE_PF` (défaut : 3), le WMS
peut déclencher un mouvement AGV pour recentrer la PF sur
TABLE_CENTRE.
## Évacuation des tables — Priorité
Lorsqu'aucune table n'est libre et qu'il faut en libérer une :
```
FONCTION évacuer_table_prioritaire(PK) :
// 1. Palette vide → retrait manuel (pas d'AGV)
// 2. Table déjà en attente d'évacuation → attendre AGV
// 3. Palette source en attente, non réutilisée par
// la prochaine tâche → AGV vers buffer/ASRS
// 4. Palette fille en attente → AGV vers image de quai
// 5. Palette source en attente (même si réutilisée)
// → AGV vers buffer ES
```
## Gestion des buffers ES → PK
Quand une table se libère au PK, le WMS choisit parmi les palettes en
buffer affectées à ce PK :
- Tri par `Line.CstAtt` **croissant** (plus petit = plus prioritaire)
- La première palette compatible avec la table libérée est envoyée
**Règle critique** : l'ordre de sortie des buffers est dicté par
`Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
## Palettes multi-commandes
Une palette source peut être assignée à plusieurs OS.
Après picking de la commande en cours :
- Si la palette a encore des tâches pour d'autres OS → marquée
`MULTI_COMMANDE`, envoyée vers un buffer ES libre
- Elle reste en buffer jusqu'au lancement de l'OS suivant
- Une palette multi-commande au PK ou en mouvement compte comme une
place buffer occupée dans le calcul de `MAX_PRELOAD_PAR_PK`
## Priorité d'accès aux buffers entre PK
Lorsque les buffers ES sont saturés, la priorité est définie par la
séquence du mode "Picking" dans `MODES_PKxx`
(voir [Modes de travail PK](stations-picking.md)) :
- Séquence 1 = priorité la plus haute
- Quand un buffer se libère → affecté en priorité au PK avec la
séquence la plus basse parmi ceux qui ont des palettes en attente
## Paramètres WMS
| Paramètre | Description | Défaut |
|-----------|-------------|--------|
| `MAX_PRELOAD_PAR_PK` | Nombre max de palettes pré-chargées en buffer ES par PK | 3 |
| `SEUIL_RECENTRAGE_PF` | Nombre min de PICKING_DIRECT restants pour recentrer la PF au centre | 3 |
| `CONTROLE_TRAITEMENT_COMMERCIAL` | Séparer ou non les articles par TC sur les palettes filles | `false` (V1.1) |
| `MODES_PKxx` | Modes autorisés + priorité par PK (LIM-69) | — |
| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | — |
## Points d'attention
⚠️ La contrainte d'adjacence est **physique** : l'opérateur ne peut pas
déplacer de sacs entre TABLE_GAUCHE et TABLE_DROITE directement.
⚠️ Le picking négatif nécessite 2 tables (palette source + adjacente
pour l'excédent), ce qui complique la gestion des cas saturés.
⚠️ Le recentrage de la palette fille (AGV) n'est déclenché que si
suffisamment de tâches de picking direct restent (≥ SEUIL_RECENTRAGE_PF).
⚠️ L'ordre de sortie des buffers suit `Line.CstAtt`, pas l'ordre FIFO
d'entrée en buffer.
## Questions ouvertes
(Aucune identifiée — algorithme V1.0 complet)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis spec "Logique combinatoire picking - PS vers PK - V1.0" |
## Références
| Source | Type | Date |
|--------|------|------|
| Logique combinatoire picking - PS vers PK - V1.0 | Spécification technique | 27/04/2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (modes PK) | 2026 |
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
wiki/limagrain/03-picking/.fuse_hidden0000003900000015
+471
View File
@@ -0,0 +1,471 @@
---
title: "Séquençage des tâches de picking TK → PS"
tags: [picking, séquençage, transstockeur, événement, workflow, algorithme]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-84, LIM-61]
confluence_refs: []
sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "Logique combinatoire picking - TK vers PS - V1.1.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# Séquençage des tâches de picking TK → PS
> **Résumé** : algorithme événementiel qui ordonne les tâches de picking
> depuis les transstockeurs (TK) vers les postes de sortie (PS). Il
> écrit les numéros de séquence `Line.CstAtt` sur chaque tâche et
> contrôle le flag `OS.CstAtt` pour autoriser le stacker_crane.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Le séquençage TK → PS est critique pour garantir que les palettes
arrivent aux postes de picking dans le bon ordre. L'algorithme
s'exécute **en amont** de l'algorithme de
[placement PS → PK](placement-ps-pk.md) : les palettes arrivent au PS
**déjà triées**.
Quatre solutions ont été envisagées avant de retenir une approche
événementielle (solution 4).
## Historique des solutions envisagées
### Solution 1 — Process isolé sur finalisation des tâches d'OS
Déclenchement à la finalisation de la création des tâches d'un OS.
Séquençage via `OS.Line.CstAtt`, marquage OS traité via
`OS.CstAtt = true`.
**Problème** : pas assez dynamique en cas de recréation de tâches suite
à des imprévus dans le WMS.
### Solution 2 — Calcul dans le workflow stacker_crane
Intégration du tri directement dans les WF
`Galileo_StackerCraneSearch_PR` / `StackerCrane_SortTasks_PR`, avec
recalcul complet du pool de tâches à chaque exécution. Supprimerait le
besoin de `OS.Line.CstAtt` et `OS.CstAtt`.
**Problème** : complexité élevée (requêtes LINQ imbriquées sur les
tâches multi-OS).
### Solution 3 — Solution 1 transformée en job
Reprise du process de la solution 1 sous forme de job planifié, en
excluant les tâches de picking en cours.
**Problème** : pas assez réactif par rapport à la cadence de recherche
d'ordre des TK.
### Solution 4 — Process événementiel (retenue)
Reprise de la solution 1 déclenchée sur deux événements, avec
mécanisme de verrouillage `OS.CstAtt` pour bloquer le stacker_crane
pendant le séquençage.
**Avantages** : simple à développer, isolée et découplée du reste,
flexible et réactive.
## Changelog V1.1 (11/05/2026)
Modifications issues de la réunion Arthur + Justine (Mecalux) — Olivier
(Limagrain), croisées avec l'AF §6.4.8 et le DevOps #64854 :
- **Hiérarchie des règles** : nouvel ordre de priorité validé.
La complétude palette et l'anti-split de lignes de stock sont des
contraintes amont prioritaires sur les règles de tri
- **Picking négatif** : ajout condition cumulative poids ≥ 7 kg
- **Traitement commercial** : critère de regroupement par TC
**supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`). Pas de bio
sur cet entrepôt
- **Calcul de remplissage** : méthode pro rata Bag/pal validée,
remplace la logique DevOps "Bag/pal max"
- **Poids max palette** : 1 250 kg (l'AF fait foi, corrige les 1 200 kg
du DevOps)
- **Règles confirmées** : mélange d'espèces OK, pas de gerbage,
hauteur max 1,90 m, séparateurs inter-lots hors WMS
> Voir la section [Arbitrage des contradictions](#arbitrage-des-contradictions-reu-11052026)
> pour le détail des décisions.
## Déclenchement
L'algorithme est déclenché sur **deux événements** :
### TaskCreatedEvent
Une nouvelle tâche de picking vient d'être créée (par le MINI JOB
Picking LIM-75, ou suite à une réassignation de stock).
```
SI événement.type == TaskCreatedEvent :
SI tâche.type == PICKING ET tâche.OS.statut == Released :
traiter_séquençage(tâche.OS)
```
### OutboundOrderReleasedEvent
Un OS passe au statut Released (première mise en service ou relance
après un arrêt).
```
SI événement.type == OutboundOrderReleasedEvent :
traiter_séquençage(OS)
```
## Process principal
```
FONCTION traiter_séquençage(OS) :
// ─── Étape 1 : verrouiller l'OS ───
OS.CstAtt ← false
// ─── Étape 2 : récupérer les tâches ───
toutes_tâches ← récupérer_tâches_picking(OS)
// ─── Étape 3 : filtrer ───
tâches_à_séquencer ← [t POUR t DANS toutes_tâches
SI t.statut == EN_ATTENTE]
SI tâches_à_séquencer est vide :
OS.CstAtt ← true
RETOURNER
// ─── Étape 4 : trier ───
tâches_triées ← trier_tâches(tâches_à_séquencer)
// ─── Étape 5 : écrire les séquences ───
écrire_séquences(tâches_triées)
// ─── Étape 6 : libérer l'OS ───
OS.CstAtt ← true
```
```mermaid
sequenceDiagram
participant EVT as Événement (TaskCreated / OS Released)
participant SEQ as Process séquençage
participant SC as Stacker Crane
EVT->>SEQ: Déclenche
SEQ->>SEQ: OS.CstAtt = false
Note over SC: Bloqué — ne prend pas<br/>de tâche de cet OS
SEQ->>SEQ: Récupère tâches en attente
SEQ->>SEQ: Applique tri + écrit séquences
SEQ->>SEQ: OS.CstAtt = true
Note over SC: Débloqué — reprend<br/>les tâches séquencées
```
## Contraintes amont (constitution des palettes filles)
Ces contraintes orientent le regroupement des lignes sur les palettes
filles **avant** le tri. L'algorithme de séquençage doit les respecter :
l'ordre de sortie doit être compatible avec la constitution de palettes
conformes à ces règles.
### C1. Palettes les plus complètes possible
Objectif premier — optimisation transport. Seuil de remplissage ~95%.
**Calcul : pro rata Bag/pal.** Chaque sac consomme `1/Bag_pal` de son
lot. Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette.
```
Exemple :
16 sacs d'un lot Bag/pal 20 + 7 sacs d'un lot Bag/pal 50
= 16/20 + 7/50
= 0,80 + 0,14
= 94%
```
Regrouper les lots de même Bag/pal sur une même palette fille facilite
la complétude.
> Cette méthode remplace la logique DevOps #64854 de "prendre le
> Bag/pal max entre lots". Le pro rata est plus précis et ne nécessite
> pas de Bag/pal de référence unique.
### C2. Ne pas splitter les lignes de stock
Éviter de répartir les sacs d'une même ligne de stock sur plusieurs
palettes. **Prioritaire sur les règles de tri** : si respecter
"Maïs first" implique de splitter une ligne, on regroupe la ligne
complète quitte à décaler le maïs.
### Autres contraintes palette
| Contrainte | Valeur | Source |
|------------|--------|--------|
| Poids max palette | **1 250 kg** | AF (corrige 1 200 kg du DevOps) |
| Hauteur max palette | 1,90 m | AF — rejet au PIE si dépassement |
| Gerbage | Interdit | — |
| Mélange d'espèces | Autorisé sur une même palette fille | — |
| Différenciation de marque | Aucune dans une même expédition | — |
| Séparateurs (intercalaires) | Règle opérateur, hors WMS | — |
## Règles de tri (séquençage des sorties ASRS)
Les tâches de picking d'un même OS sont triées selon les critères
suivants, **par ordre de priorité décroissante** :
### Critère 1 — Picking négatif en premier
Les tâches de type PICKING_NÉGATIF passent **avant** les tâches de type
PICKING_DIRECT. Prioritaire sur toutes les règles suivantes, y compris
Maïs first : si une tâche négatif concerne du tournesol, elle passe
avant une tâche maïs classique.
Condition cumulative pour la détermination NÉGATIF / DIRECT (cf.
[détermination picking négatif](#détermination-picking-négatif)) :
pourcentage quantité > seuil fiche article (défaut 55%) **ET** poids
unitaire sac ≥ 7 kg. En dessous de 7 kg, pas de picking négatif.
```
tri_1(tâche) → 0 si PICKING_NÉGATIF, 1 si PICKING_DIRECT
```
### Critère 2 — Espèce Maïs en premier
Les tâches portant sur l'espèce **Maïs** passent avant les autres
espèces. Le maïs est lourd/stable, il constitue la base de la palette
fille.
```
tri_2(tâche) → 0 si espèce == MAÏS, 1 sinon
```
### ~~Critère 3 (V1.0) — Traitement commercial~~ SUPPRIMÉ V1.1
`CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt ne fait pas de
bio. Paramètre réactivable si besoin futur.
### Critère 3 — Espèce la plus volumineuse
Les tâches sont regroupées par espèce, et l'espèce ayant la **plus
grande quantité totale de sacs** dans l'OS passe en premier. Commencer
par l'espèce la plus volumineuse permet de constituer rapidement la
base de la palette fille.
```
tri_3(tâche) → -quantité_totale_espèce(tâche.espèce, OS)
```
### Critère 4 — Article/lot le plus lourd en base
À espèce égale, les tâches portant sur les articles/lots **les plus
lourds** passent en premier. Corollaire : les semences essais, très
légères, se retrouvent naturellement en haut de palette.
```
tri_4(tâche) → -tâche.article.poids
```
### Critère 5 — Regroupement par palette source
Toutes les tâches portant sur la **même palette source** sont
consécutives. L'opérateur enchaîne toutes les tâches d'une palette
source avant de la libérer.
```
tri_5(tâche) → tâche.PALETTE_SOURCE.identifiant
```
### Récapitulatif du tri multi-critères (V1.1)
```
FONCTION trier_tâches(tâches) :
RETOURNER tâches.trier_par(
(1) type_picking ASC // NÉGATIF (0) avant DIRECT (1)
(2) espèce_maïs ASC // MAÏS (0) avant autres (1)
(3) quantité_espèce DESC // espèce la + volumineuse
(4) poids_article DESC // article le + lourd
(5) palette_source // regroupement par palette
)
```
## Écriture des séquences (Line.CstAtt)
### Règle des ex-aequo
Quand deux tâches consécutives sont **interchangeables** (l'ordre entre
elles n'a aucun impact fonctionnel), elles reçoivent le **même numéro
de séquence**. Cela laisse de la flexibilité au stacker_crane pour
optimiser son débit.
### Critères d'interchangeabilité
Deux tâches A et B sont interchangeables si :
- Elles portent sur la **même palette source**, **OU**
- Elles portent sur des **palettes sources différentes** mais tous les
critères de tri sont identiques : même type de picking, même espèce,
même quantité espèce, même poids article
### Algorithme d'écriture
```
FONCTION écrire_séquences(tâches_triées) :
séquence_actuelle ← max(Line.CstAtt des tâches en cours) + 1
SI aucune tâche en cours :
séquence_actuelle ← 1
POUR i DE 0 À len(tâches_triées) - 1 :
tâche ← tâches_triées[i]
tâche.Line.CstAtt ← séquence_actuelle
SI i < len(tâches_triées) - 1 :
tâche_suivante ← tâches_triées[i + 1]
SI interchangeables(tâche, tâche_suivante) :
CONTINUER
SINON :
séquence_actuelle ← séquence_actuelle + 1
```
### Exemple
```
Commande avec 5 tâches, après tri :
Tâche 1 : Palette A, Maïs, 500kg → séq 1
Tâche 2 : Palette B, Maïs, 500kg → séq 1 (interchangeable)
Tâche 3 : Palette C, Maïs, 500kg → séq 1 (interchangeable)
Tâche 4 : Palette D, Blé, 300kg → séq 2 (espèce différente)
Tâche 5 : Palette E, Blé, 300kg → séq 2 (interchangeable)
Résultat Line.CstAtt : [1, 1, 1, 2, 2]
Le stacker_crane peut sortir A, B, C dans n'importe quel ordre,
puis D ou E dans n'importe quel ordre.
```
## Comportement du stacker_crane après séquençage
Le stacker_crane **ignore** les tâches dont `OS.CstAtt == false`,
consomme celles dont `OS.CstAtt == true` par `Line.CstAtt` croissant,
et entre tâches à séquence égale il optimise librement (proximité ASRS,
charge TK). Il crée les tâches de mouvement TK → PS.
Les palettes arrivent ensuite au PS, où l'algorithme de
[placement PS → PK](placement-ps-pk.md) décide sur quelle table les
poser.
## Détermination picking négatif
Le type de picking (NÉGATIF ou DIRECT) est déterminé **par tâche** au
moment de la création des tâches par le MINI JOB Picking (LIM-75) :
```
SI quantité_à_prélever > seuil_article × quantité_palette_source
ET article unique dans la palette source
ET pas d'attribut logistique à capturer
ET poids_unitaire_sac ≥ 7 kg
ALORS → PICKING_NÉGATIF
SINON → PICKING_DIRECT
```
Le seuil % reste paramétrable par fiche article (champ "Complete
quantity percent excess for negative picking", défaut : 55%).
La détermination se fait **en amont** (MINI JOB Picking, LIM-75), avant
l'algorithme de séquençage. L'algorithme de séquençage lit ce type mais
ne le calcule pas.
## Cas particuliers
### Recalcul suite à une nouvelle tâche (réassignation de stock)
Si une tâche est créée après que l'OS a déjà été séquencé, le
`TaskCreatedEvent` déclenche un recalcul : verrouillage, re-tri des
tâches en attente uniquement (en commençant après le dernier numéro des
tâches en cours), puis libération.
### Relance d'un OS arrêté
Si un OS est arrêté puis relancé (`OutboundOrderReleasedEvent`), le
même process s'applique. Les tâches en cours conservent leur séquence,
les tâches en attente sont re-séquencées.
## Arbitrage des contradictions (réu. 11/05/2026)
Analyse comparative de 3 sources (DevOps #64854, AF §6.4.8, réunion
11/05/2026 Arthur + Justine + Olivier). **Tous les points sont résolus.**
| Sujet | DevOps | AF | Réunion (fait foi) |
|-------|--------|----|--------------------|
| Traitement commercial | À creuser | Séparation stricte | **Supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`) |
| Seuil picking négatif | Pas de seuil explicite | > 50% | **Deux conditions cumulatives** : % seuil fiche article (défaut 55%) ET poids sac ≥ 7 kg |
| Poids max palette | 1 200 kg | 1 250 kg | **1 250 kg** (AF fait foi) |
| Picking négatif vs Maïs first | Pas de hiérarchie | Maïs en tête, négatif séparé | **Picking négatif prioritaire** (confirmé Olivier) |
| Semences essais en haut | Oui (dédié) | Non mentionné | **Couvert par règle du plus lourd en base** (essais = légères → haut) |
| Lots même Bag/pal | Prioriser regroupement | — | **Retenu** (WF palettes complètes) |
| Différenciation marque | Aucune | — | **Confirmé** |
| Calcul Bag/pal multi-lots | "Prendre le Bag/pal max" | Équivalent palette | **Pro rata** (chaque sac = 1/Bag_pal de son lot) |
## Paramètres WMS
| Paramètre | Description | Défaut | Statut V1.1 |
|-----------|-------------|--------|-------------|
| `CONTROLE_TRAITEMENT_COMMERCIAL` | Regroupement par TC dans le tri | ~~true~~ | **false** — désactivé |
| Seuil picking négatif (fiche article) | "Complete quantity percent excess for negative picking" | 55% | Inchangé |
| Poids min picking négatif | Poids unitaire sac minimum pour autoriser le picking négatif | **7 kg** | **Nouveau V1.1** |
| Seuil remplissage palette | Taux cible remplissage palette fille | **~95%** | **Nouveau V1.1** |
| Poids max palette | Poids maximum palette fille | **1 250 kg** | Corrigé (était 1 200 kg) |
| `OS.CstAtt` | Flag verrouillage OS pendant séquençage (true = stacker_crane autorisé) | true | Inchangé |
| `MAX_NB_BUFFER_PK` | Nombre de buffers disponibles par PK | 3 | Inchangé |
## Points d'attention
⚠️ Le custom LIM-61 (vérification capacité buffer) doit être modifié
pour prendre en compte les palettes multi-PK.
⚠️ Le verrouillage `OS.CstAtt` est temporaire (durée du séquençage) —
en cas d'erreur du process, l'OS risque de rester bloqué.
⚠️ Les tâches **en cours** sont exclues du séquençage — seules les
tâches en attente sont réordonnées.
⚠️ La condition poids ≥ 7 kg pour le picking négatif est ajoutée pour
éviter l'instabilité palette (gros sacs ramenés sur petits sacs).
## Points non traités (hors scope)
- Affichage opérateur au PK (combien de sacs ajouter, possibilité de
dévier de la consigne) — à traiter une fois les fondations posées
- Picking négatif < 7 kg en option (avantage opérationnel sans
obligation) — nécessite discussion élargie
- Messagerie carton (moins prioritaire, navette du lendemain, zone
angle Est) — en attente de précisions
- Verrou réception → recomptage avant picking (mentionné dans l'AF
uniquement, non reconfirmé)
## Questions ouvertes
- [ ] Comportement en cas d'erreur du process de séquençage — OS reste
bloqué avec CstAtt = false ? (@Nicolas)
- [ ] Impact sur les performances si beaucoup d'OS sont Released
simultanément — risque de contention sur les événements ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-84 |
| 2026-05-12 | Arthur | Refonte complète : intégration spec V1.1 (algo complet, contraintes amont, 5 critères tri, écriture séquences, ex-aequo, cas particuliers) + arbitrage contradictions réunion 11/05/2026 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira (custom capacité buffer) | 2026 |
| Logique combinatoire picking - TK vers PS - V1.1 | Spécification technique | 11/05/2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
| DevOps #64854 | Note historique | — |
| AF §6.4.8 | Analyse fonctionnelle V1.5 | 28/11/2025 |
wiki/limagrain/03-picking/.fuse_hidden0000003b00000016
+301
View File
@@ -0,0 +1,301 @@
---
title: "Stations et postes de travail Limagrain"
tags: [picking, stations, postes, ilots, buffer]
status: draft
standard_ref: concepts/stations.md
jira_refs: [LIM-69, LIM-70]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-69 - LOT1.3 Modes de travail des PK.md"]
last_updated: 2026-05-12
author: Arthur
---
# Stations et postes de travail Limagrain
> **Résumé** : description des stations de l'entrepôt automatique, des
> postes de travail polyvalents (3 îlots × 2 postes) et des buffers associés.
> **Standard EasyWMS** : → voir [Stations & Routes](../../concepts/stations.md),
> [Mechanical Elements](../../concepts/mechanical-elements.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, les postes de travail sont **polyvalents** et multi-processus.
L'ensemble des opérations (réception, picking, regroupement, échantillonnage,
re-certification) se fait sur les mêmes postes physiques, configurables
dynamiquement.
## Cartographie des stations
### Zone entrée production / sortie expéditions
| Station | Description |
|---------|-------------|
| PIE_01 | Poste d'identification 01 (côté quais) |
| NAV_01 | Navette 01 |
### Zone entrée/sortie postes de travail
| Station | Description |
|---------|-------------|
| PIE_02 | Poste d'identification 02 |
| PIE_03 | Poste d'identification 03 |
| REAC_01 | Poste de reconditionnement 01 |
| NAV_02 | Navette 02 |
| ET_21, ET_22 | Tables intermédiaires |
### Zone stockage côté postes de travail
| Station | Description |
|---------|-------------|
| ET_23 à ET_28 | Tables intermédiaires 23 à 28 |
| TE_01 à TE_04 | Tables d'entrée 01 à 04 |
| TS_01 à TS_04 | Tables de sortie 01 à 04 |
### Zone stockage côté quais
| Station | Description |
|---------|-------------|
| ET_11 à ET_15 | Tables intermédiaires 11 à 15 |
| TE/TS_01 à TE/TS_04 | Tables mixtes entrée/sortie 01 à 04 |
### Zone postes de travail
| Station | Description |
|---------|-------------|
| P1 à P6 | Postes de travail 01 à 06 |
| TP11 à TP63 | Tables de préparation 11 à 63 |
## Postes de travail — Architecture physique
### 3 îlots de 2 postes
Physiquement, il y a **3 îlots**, chacun composé de **6 tables de préparation
(TP)**. Chaque îlot peut être configuré de 2 façons :
1. **Mode scindé** : 2 postes individuels × 3 TP chacun (mode par défaut)
2. ~~**Mode global** : 1 poste × 6 TP (mode « esclave »)~~ **ABANDONNÉ**
> **MISE À JOUR** : le mode esclave (6 TP) est abandonné au profit d'un
> simple **message d'avertissement**. Si le poste adjacent est déjà
> ouvert → « Attention, le poste PVx est déjà ouvert. Voulez-vous quand
> même ouvrir ? ». L'opérateur peut confirmer ou annuler. Pas de blocage
> technique, juste un avertissement.
>
> **Justification** : les opérateurs sont physiquement à ~2 mètres l'un
> de l'autre et peuvent se coordonner verbalement. Les AGV ont des
> capteurs de sécurité et demandent l'autorisation de dépose. Trop de cas
> complexes à gérer avec un mode esclave custom. L'AGV amène toujours la
> palette au centre du PV actif.
>
> **Développement** : message d'avertissement à l'ouverture du poste,
> vérification si le poste conjoint est déjà ouvert (via support présent
> ou poste en mode réception), workflow action sur le end process pour
> fermer le poste.
### Numérotation
```
Îlot 1 : P1 (TP11, TP12, TP13) | P2 (TP21, TP22, TP23)
Îlot 2 : P3 (TP31, TP32, TP33) | P4 (TP41, TP42, TP43)
Îlot 3 : P5 (TP51, TP52, TP53) | P6 (TP61, TP62, TP63)
```
### Spécificités P5 & P6
Les postes **P5 et P6** sont équipés d'un **palan** pour la manipulation
de big-bags. Toute opération impliquant un big-bag (bag/pal ≤ 2) doit
être traitée sur P5 ou P6.
**Picking** : WS PK picking rob en priorité, process RF comme fallback
(plus robuste pour picking négatif, multi-tables). Le process de réception
est déjà plugué au mode Automatic tasks (custom) → même mode pour le
picking et la recertification.
Voir [Flux expédition — Préparation](../04-outbound/flux-expedition.md#6-préparation-au-poste-de-travail)
pour les règles détaillées (arrivée palettes 3 TP, algorithme répartition,
ordonnancement par gerbabilité).
### Modes de travail — Configuration et fonctionnement
Chaque poste est **polyvalent** et peut être utilisé pour différents flux.
Le manager configure les modes autorisés et leur priorité ; l'opérateur
ouvre le poste et le WMS gère automatiquement le process en fonction de
la palette qui arrive.
#### Modes disponibles
| Mode | Correspondance EasyWMS |
|------|------------------------|
| Picking | Picking |
| Réception | Réception |
| Regroupement | Consolidation |
| Échantillonnage | Inventaire |
| Re certification | Picking |
> ~~Mode esclave (3 ou 6 tables)~~ **ABANDONNÉ** — remplacé par un simple
> message d'avertissement poste adjacent (voir section dédiée ci-dessous).
#### Configuration par le manager (vassist SmartUI)
Dans la vue des postes de travail, un **bouton d'action "Choix modes de
travail"** est disponible à la sélection d'un ou plusieurs PK. Ce bouton
ouvre une **vassist** qui permet de :
- **Cocher/décocher les modes autorisés** parmi les 5 modes ci-dessus
- **Définir la priorité** de chaque mode coché via un champ numérique
(séquence)
**Règles de validation** à la soumission :
- Chaque mode coché doit avoir une priorité renseignée
- Un mode non coché ne doit pas avoir de priorité
- Au moins un mode doit être coché (pour bloquer un PK, utiliser le
bouton standard dédié)
**Stockage** : la configuration est enregistrée dans un **paramètre
SmartUI dédié par PK** au format :
```
MODES_PK01 = "RECEPTION;1|PICKING;2|CONSOLIDATION;3"
MODES_PK02 = "RECEPTION;1"
```
Chaque entrée : `MODE;PRIORITÉ` séparés par `|`.
Cette configuration est utilisée par le
[Mega Job d'assignation](job-assignation-pk.md)
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) pour
déterminer si un PK est éligible à recevoir des tâches d'un flux donné
et dans quel ordre de priorité.
#### Ouverture du poste par l'opérateur (SmartUI)
L'opérateur accède à **Poste de travail > Station de picking**.
L'interface affiche un **bouton "Fermer le poste"** toujours visible.
Par défaut, le poste fonctionne en **tâche automatique** : le WMS
choisit le bon process en fonction de la palette qui arrive ou qui est
déjà sur le PK. L'opérateur n'a pas à sélectionner manuellement un mode.
#### Avertissement poste adjacent
À chaque ouverture d'un PK, le WMS vérifie si le **poste adjacent** est
déjà ouvert (en mode actif). Le mapping des paires est défini dans le
paramètre `PK_ADJACENT`.
**Si le poste adjacent est actif** → message d'avertissement (y compris
en mode tâche automatique) :
> "Attention, le poste [CODE_PK_ADJACENT] est déjà ouvert.
> Voulez-vous quand même ouvrir ?"
- Bouton **Confirmer** : le PK s'ouvre normalement
- Bouton **Annuler** : le PK reste inactif
**Pas de blocage technique** — uniquement informatif. Les opérateurs sont
physiquement à ~2 mètres et peuvent se coordonner verbalement. Les AGV
ont des capteurs de sécurité et demandent l'autorisation de dépose.
#### Fermeture du poste
Le bouton **"Fermer le poste"** est toujours visible quel que soit l'état.
Au clic :
- Le PK est remis en mode **inactif** (aucun mode actif)
- Le PK redevient éligible pour une nouvelle assignation par le
[Mega Job](job-assignation-pk.md) (sous réserve qu'il n'ait plus de
tâches actives)
#### Paramètres modes de travail
| Paramètre | Description | Valeur par défaut | Exemple |
|-----------|-------------|-------------------|---------|
| MODES_PKxx | Modes autorisés + priorité pour le PK xx (un par PK, via vassist) | _(vide)_ | `RECEPTION;1\|PICKING;2` |
| PK_ADJACENT | Paires de postes adjacents | _(vide)_ | `PK01;PK02\|PK03;PK04` |
### Équipement par poste
- 1 poste léger EasyWMS dupliqué sur 2 écrans
- 1 imprimante Zebra (étiquettes HU RFID)
- 1 imprimante A4 (étiquettes A4)
- 1 douchette multi-format (RFID, QR Code, code à barres)
## [CUSTOM] Mega Job d'assignation des tâches aux postes
→ Voir page dédiée : **[Job d'assignation PK](job-assignation-pk.md)**
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70))
Job unique « chef d'orchestre » qui vérifie les modes de travail pour
chaque PK et orchestre l'envoi de tâches via des sous-workflows dédiés
(LIM-74, LIM-75). Transverse à tous les flux (réception, picking,
regroupement, échantillonnage, re certification).
## Buffer postes de travail
16 emplacements palettes au sol le long de l'allée TK_01 :
| Nb emplacements | Usage |
|-----------------|-------|
| 14 | Avance pour les processus en cours |
| 2 | Piles de palettes vides |
> ⚠️ 2 emplacements supplémentaires pour palettes rejetées en attente de
> libération d'un poste de travail.
### [CUSTOM] Buffer configurable
Les emplacements du buffer sont **interchangeables** : un champ « type de
fonctionnement » peut être modifié quand l'emplacement est vide.
### [CUSTOM] Bouton d'évacuation
Un bouton spécifique sur l'écran EasyWMS permet d'évacuer automatiquement
une palette du buffer vers le convoyeur d'entrée pour stockage.
## Piles de palettes vides par poste
- **2 piles par îlot de travail** (et non par poste individuel)
- Emplacement picking dédié pour réapprovisionnement automatique sur
seuil
- Aide à la manutention sur chaque poste pour prendre/poser des palettes
- [CUSTOM] Bouton WfAction pour demander ou renvoyer une pile —
l'opérateur choisit la pile à réapprovisionner parmi une liste
Voir [Palettes vides](../02-stockage/palettes-vides.md) pour le détail.
## Points d'attention
⚠️ Un poste fermé ne peut pas être assigné à un processus.
⚠️ L'assignation automatique du poste optimise la distance la plus courte.
⚠️ Si une TP est HS, elle peut être bloquée individuellement sans impacter
le reste du poste.
⚠️ L'entrée côté postes de travail et l'entrée côté quais sont
interchangeables manuellement en cas de blocage long terme (bouton de
redirection).
## Questions ouvertes
- [ ] Détail de la gestion des tables de préparation bloquées (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Mode esclave abandonné, job transverse, vassist modes, 2 piles/îlot |
| 2026-05-05 | Arthur | Cross-ref flux expédition, picking WS vs RF, contrainte Big-Bag |
| 2026-05-12 | Arthur | Détail modes de travail (LIM-69) : vassist manager, paramètres MODES_PKxx/PK_ADJACENT, tâche automatique, avertissement adjacent, fermeture poste. Renvoi job vers page dédiée (LIM-70) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira | 2026 |
wiki/limagrain/03-picking/.fuse_hidden0000003d00000017
+50
View File
@@ -0,0 +1,50 @@
---
title: "Picking — Vue d'ensemble"
tags: [picking, combinatoire, stations, index]
status: draft
last_updated: 2026-05-12
---
# Picking — Vue d'ensemble
> **Périmètre** : picking combinatoire (CR V3.0, 4-job, CstAtt), stations de
> picking, job d'assignation PK, waves et groupes, replenishment.
> **Standard EasyWMS** : voir [Picking](../../concepts/picking.md)
## Pages de cette section
- [Picking combinatoire](picking-combinatoire.md)
- [Stations de picking](stations-picking.md)
- [Job d'assignation PK (Mega Job)](job-assignation-pk.md)
- [Waves et groupes](waves-groupes.md)
- [Replenishment](replenishment.md)
- [Séquençage TK → PS](sequencage-tk-ps.md)
- [Placement PS → PK (choix de table)](placement-ps-pk.md)
- [Consolidation / Regroupement](consolidation-regroupement.md)
- [Échantillonnage](echantillonnage.md)
## Vue synthétique du picking Limagrain
```mermaid
flowchart TD
OS[OS libéré + stock assigné] --> SEQ[Séquençage TK → PS]
SEQ --> TRI["Tri : négatif > maïs > volume > poids"]
TRI --> PS[Palette arrive au PS]
PS --> PLACE[Placement PS → PK]
PLACE --> TABLE{Table ou buffer ?}
TABLE -->|Table libre| PICK[Prélèvement au PK]
TABLE -->|Buffer ES| WAIT[Attente buffer]
WAIT --> PICK
PICK --> NEG{"Picking négatif ?\n(% > 55% ET ≥ 7 kg)"}
NEG -->|Oui| PNEG[Picking négatif]
NEG -->|Non| PPOS[Picking direct]
PNEG --> FILM[Choix filmage]
PPOS --> FILM
FILM --> PIE[Passage PIE]
PIE --> DEFRAG[Zone défrag client]
```
> **Note** : le picking AF V1.5 a depuis évolué vers le modèle
> « picking combinatoire » CR V3.0 (4 jobs, CstAtt). Les pages de cette
> section couvrent les deux versions.
wiki/limagrain/03-picking/_index.md
+58
View File
@@ -0,0 +1,58 @@
---
title: "Picking — Vue d'ensemble"
tags: [picking, combinatoire, stations, index]
status: draft
last_updated: 2026-05-13
---
# Picking — Vue d'ensemble
> **Périmètre** : picking combinatoire (CR V3.0, 4-job, CstAtt), stations de
> picking, job d'assignation PK, waves et groupes, replenishment.
> **Standard EasyWMS** : voir [Picking](../../concepts/picking.md)
## Pages de cette section
- [Picking combinatoire](picking-combinatoire.md)
- [Stations de picking](stations-picking.md)
- [Job d'assignation PK (Mega Job)](job-assignation-pk.md)
- [Waves et groupes](waves-groupes.md)
- [Replenishment](replenishment.md)
- [Séquençage TK → PS](sequencage-tk-ps.md)
- [Séquençage TK → PS — Historique et arbitrage](sequencage-tk-ps-historique.md)
- [Placement PS → PK (choix de table)](placement-ps-pk.md)
- [Consolidation / Regroupement](consolidation-regroupement.md)
- [Échantillonnage](echantillonnage.md)
## Chaîne picking — Ordre des traitements
L'ordre réel de la chaîne picking est le suivant :
1. **LIM-80** — [Assignation PK](job-assignation-pk.md) : quelle commande
sur quel poste → déclenche la génération des tâches de picking
2. **LIM-84** — [Séquençage TK → PS](sequencage-tk-ps.md) : ordonne les
sorties des TK vers les PS
3. **LIM-82** — [Placement PS → PK](placement-ps-pk.md) : la palette
arrivant au PS va sur quelle table du PK
4. Workflow opérateur au PK (picking effectif)
## Vue synthétique du picking Limagrain
```mermaid
flowchart TD
OS[OS libéré + stock assigné] --> ASSIGN["LIM-80 : Assignation PK\n(commande → poste)"]
ASSIGN --> SEQ["LIM-84 : Séquençage TK → PS\n(tri : négatif > maïs > volume > poids)"]
SEQ --> PS[Palette arrive au PS]
PS --> PLACE["LIM-82 : Placement PS → PK\n(choix de table)"]
PLACE --> TABLE{Table ou buffer ?}
TABLE -->|Table libre| PICK[Prélèvement au PK]
TABLE -->|Buffer ES| WAIT[Attente buffer]
WAIT --> PICK
PICK --> NEG{"Picking négatif ?\n(% > 55% ET ≥ 7 kg)"}
NEG -->|Oui| PNEG[Picking négatif]
NEG -->|Non| PPOS[Picking direct]
PNEG --> FILM[Choix filmage]
PPOS --> FILM
FILM --> PIE[Passage PIE]
wiki/limagrain/03-picking/consolidation-regroupement.md
+148
View File
@@ -0,0 +1,148 @@
---
title: "Consolidation (regroupement) — Processus sur poste"
tags: [picking, regroupement, consolidation, MOV, poste, custom]
status: draft
standard_ref: concepts/picking.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Consolidation (regroupement) — Processus sur poste
> **Résumé** : processus [CUSTOM] de consolidation de palettes incomplètes
> partageant les mêmes critères de stock, sur poste de travail.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le regroupement permet de vider des palettes partiellement remplies en
déplaçant leur stock vers d'autres palettes contenant le même stock.
L'objectif est de libérer des emplacements dans l'ASRS.
## Critères de consolidation
Le regroupement est proposé quand deux palettes ou plus partagent :
- Article
- Lot SAP
- Propriétaire
- Statut de stock
- Flag anoxie
## [CUSTOM] Vue de proposition de regroupement
Une vue spécifique est développée pour Limagrain. Elle présente :
- Les palettes candidates au regroupement
- Le gain potentiel en nombre de palettes
**Règle** : le regroupement n'est proposé que s'il permet de gagner au
moins 1 palette. Exemple : Bag/Pal = 75, si palette H1 = 73 et H2 = 5
→ pas de regroupement (73 + 5 = 78 > 75, pas de gain).
L'opérateur sélectionne un ou plusieurs ordres de regroupement depuis
cette vue.
## Processus complet
```mermaid
flowchart TD
VUE[Vue proposition regroupement] --> SELECT[Sélection ordres]
SELECT --> ASSIGN[Assignation poste automatique]
ASSIGN --> TACHE[Création tâches mouvement]
TACHE --> ORD[Ordonnancement palettes au poste]
ORD --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PICK[Déplacement sacs]
RECOUNT --> PICK
PICK --> VIDE{Palette vidée ?}
VIDE -->|Oui| DEGAGE[Dégagement palette vide]
VIDE -->|Non| PICK
DEGAGE --> EVAC[Évacuation palette stock]
EVAC --> FILM[Choix filmage]
FILM --> PIE[Passage PIE]
PIE --> STOCK[Stockage ASRS]
```
## Assignation poste de travail
- Assignation **automatique** quand un ordre est lancé
- [CUSTOM] Si le lot a un Bag/Pal ≤ 2 → considéré « big-bag » →
seul le **poste P6** (équipé d'un palan) est assignable
- Un big-bag ne peut être consolidé que sur un autre big-bag
- Si P6 n'est pas en mode regroupement → tâche en attente
- Si aucun poste disponible → ordre en attente de libération
## [CUSTOM] Ordonnancement des palettes au poste
Une fois l'ordre lancé et le poste assigné, les palettes arrivent dans
cet ordre :
1. **Minimum de mouvements palette** (moins de déplacements physiques)
2. **Minimum de mouvements sac** (moins de manipulations)
3. **Palette complète** (en priorité la palette destinataire)
## Exécution sur poste
1. [CUSTOM] Si verrou « Réception » → recomptage avant regroupement
2. Les sacs de la palette à éliminer sont déplacés vers la palette
destinataire
3. Quand la palette est vidée → dégagement de la table de préparation
4. Évacuation de la palette avec stock restant via bouton EasyWMS
5. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
6. [CUSTOM] Message **MOV** à chaque déplacement de stock :
- Palette d'origine
- Palette de destination
- Nouvelle palette ? (Oui/Non)
- Quantité + caractéristiques (article, lot SAP, ...)
## Passage PIE post-regroupement
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- État palette bois correct
- Étiquette RFID connue
[CUSTOM] Calcul poids de référence :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Vérification avec tolérance par type d'article (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ Le message MOV est envoyé à chaque mouvement unitaire — volumétrie
potentiellement élevée pour un regroupement complexe.
⚠️ Les 3 tables de préparation d'un même poste peuvent être occupées
simultanément pendant le regroupement.
⚠️ Un big-bag ne peut être consolidé que sur un autre big-bag (contrainte
physique + système).
## Questions ouvertes
- [ ] Programme de filmage exact pour le regroupement (@Théo)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/03-picking/echantillonnage.md
+145
View File
@@ -0,0 +1,145 @@
---
title: "Échantillonnage — Processus de contrôle qualité"
tags: [picking, échantillonnage, inventaire, qualité, poste, custom]
status: draft
standard_ref: concepts/inventory.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Échantillonnage — Processus de contrôle qualité
> **Résumé** : processus [CUSTOM] d'échantillonnage pour contrôle qualité,
> assimilé à un inventaire dans EasyWMS, avec prélèvement sur poste de travail.
> **Standard EasyWMS** : → voir [Inventory](../../concepts/count.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'échantillonnage sert au contrôle qualité sur une partie des lots
produits. Il consiste à prélever environ 200 grammes dans une partie du
stock sélectionné. Le prélèvement est ensuite analysé pour valider la
qualité du produit fini.
Dans EasyWMS, ce processus est assimilé à un **inventaire** (ordre
d'inventaire).
## Création de l'ordre d'échantillonnage
Deux modes de création :
| Mode | Origine | Détail |
|------|---------|--------|
| Interface ERP | Message de l'ERP (COR) | Spécifie un lot à inventorier |
| Manuel | Interface EasyWMS | Choix d'un lot par l'opérateur |
[CUSTOM] Un champ texte est disponible pour donner des **consignes**
rattachées à l'ordre d'inventaire.
## [CUSTOM] Assignation du stock
L'assignation diffère selon le mode de création :
### Création par interface ERP
- Maximum **4 palettes** échantillonnées :
- Si stock global < 4 → toutes les palettes
- Si stock global ≥ 4 → 4 palettes sélectionnées
- [CUSTOM] Les palettes avec un verrou d'écart de poids (« Production »)
sont **prioritaires** pour permettre une vérification simultanée
### Création manuelle
- Nombre de palettes choisi par l'opérateur
## Assignation poste de travail
- Automatique, à condition que le poste soit ouvert et autorise le
mode « échantillonnage »
- Si aucun poste paramétré en mode échantillonnage → tâches en attente
- Une fois le poste assigné → création des tâches de mouvement
## Processus sur poste de travail
```mermaid
flowchart TD
ORDRE[Ordre échantillonnage] --> ASSIGN[Assignation stock]
ASSIGN --> POSTE[Assignation poste auto]
POSTE --> TACHE[Tâches mouvement créées]
TACHE --> ARRIVE[Palette arrive sur TP]
ARRIVE --> VERROU{Verrou « Réception » ?}
VERROU -->|Oui| RECOUNT[Recomptage]
VERROU -->|Non| PRELEV[Prélèvement ~200g]
RECOUNT --> PRELEV
PRELEV --> ETIQ[Impression étiquette échantillonnage]
ETIQ --> SCOTCH[Scotch sac ouvert]
SCOTCH --> FILM[Choix filmage]
FILM --> EVAC[Évacuation → PIE → stockage]
EVAC --> NEXT{Palette suivante ?}
NEXT -->|Oui| ARRIVE
NEXT -->|Non| FIN[Fin ordre]
```
Les 3 tables de préparation peuvent être occupées simultanément.
Le processus est démarré et effectué sur **une seule palette à la fois**.
### Séquence opérateur
1. [CUSTOM] Si verrou « Réception » → recomptage avant échantillonnage
2. Prendre une pochette d'échantillonnage vide (hors EasyWMS)
3. Effectuer un prélèvement dans un des sacs (~200g, hors EasyWMS)
4. Déposer le prélèvement dans la pochette (hors EasyWMS)
5. Éditer et imprimer une **étiquette d'échantillonnage**
6. Coller l'étiquette sur la pochette (hors EasyWMS)
7. Scotcher le sac ouvert sur la palette (hors EasyWMS)
8. [CUSTOM] Choix filmage depuis vue spécifique (programme à définir)
9. Évacuer la palette vers le stockage
## Passage PIE post-échantillonnage
Contrôle identique aux autres processus :
- Dimensions max : 1300 × 1100 × 1900 mm
- Poids max : 1250 kg
- Étiquette RFID connue
- État palette bois correct
[CUSTOM] Poids de référence recalculé + vérification avec tolérance
(voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
Si PIE NOK → rejet vers poste d'origine. Possibilité de forcer le
passage en cas d'excédent de poids non corrigeable.
## Points d'attention
⚠️ L'échantillonnage est un processus d'**inventaire** dans EasyWMS,
pas un processus de picking — important pour le paramétrage des modes
de poste.
⚠️ Les palettes avec verrou « Production » (écart poids) sont traitées
en priorité pour optimiser le recomptage.
⚠️ La quantité prélevée (~200g) n'est pas déduite du stock dans EasyWMS
(négligeable par rapport au poids total).
## Questions ouvertes
- [ ] Le prélèvement de 200g est-il déduit du stock ou négligé ? (@Nicolas)
- [ ] Programme de filmage exact (@Théo)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/03-picking/job-assignation-pk.md
+203
View File
@@ -0,0 +1,203 @@
---
title: "Mega Job — Assignation des tâches aux PK"
tags: [picking, job, assignation, agv, workflow]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-70, LIM-74, LIM-75, LIM-80]
confluence_refs: []
sources: ["LIM-70 LOT1.3 [AGV][JOB] MEGA JOB - assignation d'ordre par priorité de process par PK.md", "LIM-80 LOT2.1 2 Mini Job Assignation des postes PK aux commandes.md"]
last_updated: 2026-05-12
author: Arthur
---
# Mega Job — Assignation des tâches aux PK
> **Résumé** : job unique « chef d'orchestre » qui analyse les postes de
> travail éligibles et leur assigne des tâches de mouvement selon les
> modes autorisés et leur priorité. Évite la concurrence entre
> mini-jobs indépendants.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md),
> [Stations & Routes](../../concepts/stations.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chez Limagrain, les postes de travail (PK) sont polyvalents : réception,
picking, regroupement, échantillonnage, re certification. Plusieurs
flux différents génèrent des tâches de mouvement vers les PK. Sans
orchestration centralisée, ces flux se feraient concurrence.
Le Mega Job est un **job unique** avec une entête qui analyse l'ensemble
des supports concernés et, selon leur emplacement d'origine et leurs
caractéristiques, délègue à des **sous-workflows** dédiés.
## Éligibilité d'un PK
Pour qu'un poste soit éligible à une nouvelle assignation, **toutes** les
conditions suivantes doivent être remplies :
- **Aucun ordre de sortie** assigné au PK (écran Menu > Contrôle >
Affectation des postes de prélèvements)
- **Aucune tâche de mouvement** ayant pour destination ce PK
- **Aucune palette** présente sur un des sous-emplacements du PK
- **Le poste est ouvert** (mode actif)
- **Le paramètre MODES_PKxx existe et n'est pas vide** — sinon le PK
est ignoré
Si un PK ne remplit pas ces conditions, le job le saute et passe au
suivant.
## Logique principale
```mermaid
flowchart TD
A[Début du job] --> B[Lister les PK ouverts]
B --> C{PK éligible ?}
C -- Non --> D[PK suivant]
C -- Oui --> E[Lire MODES_PKxx]
E --> F{Paramètre existe et non vide ?}
F -- Non --> D
F -- Oui --> G[Trier les modes par priorité]
G --> H[Exécuter sous-WF du mode priorité 1]
H --> I{Tâche assignée ?}
I -- Oui --> D
I -- Non --> J[Exécuter sous-WF du mode priorité 2]
J --> K{Tâche assignée ?}
K -- Oui --> D
K -- Non --> L[... mode suivant ...]
L --> D
D --> M{Autres PK ?}
M -- Oui --> C
M -- Non --> N[Fin du job]
```
Pour chaque PK éligible :
1. Le WMS récupère le paramètre `MODES_PKxx` (x = numéro du poste)
2. Les modes sont triés par priorité croissante
3. Le sous-workflow du mode de priorité la plus haute est exécuté
4. Si le sous-WF a assigné une tâche → passage au PK suivant
5. Sinon → exécution du sous-WF du mode suivant dans l'ordre de priorité
6. Si aucun sous-WF n'a rien assigné → le PK reste en attente
## Gestion des Big-Bags
Le paramètre `PK_BIGBAG` définit quels PK autorisent la présence de
big-bags (physiquement : P5 et P6 avec palan).
- Les ordres contenant des supports big-bag sont **interdits** sur les
PK qui ne les autorisent pas
- Ces ordres sont **prioritaires** (en respectant le séquençage des
process en première priorité) sur les PK qui les autorisent
## Sous-workflows
Le Mega Job délègue la création effective des tâches à des sous-workflows
spécialisés :
| Sous-WF | Ticket | Process | Page wiki |
|---------|--------|---------|-----------|
| Mini Job images de quai → PK | [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Réception fournisseur / intersite / retour client (depuis images de quai) | [Job réception PK](../05-agv/job-reception-pk.md) |
| Mini Job PS → PK | [LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) | _(tâche à écrire)_ | — |
| Mini Job assignation commandes → PK | [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Assignation des ordres de sortie (commandes) aux PK pour picking | Voir section ci-dessous |
Chaque sous-workflow retourne une information au WF principal indiquant
s'il a assigné quelque chose ou non.
## Mini Job — Assignation commandes aux PK (LIM-80)
Ce sous-workflow est appelé par le Mega Job quand le mode **Picking** est
actif sur un PK. Il assigne un ordre de sortie (commande) au poste.
### Éligibilité du PK pour une commande
Le PK peut recevoir une commande si **toutes** les conditions sont
remplies :
- Le PK **autorise la préparation de commande** (mode Picking actif)
- Le PK **n'a pas de commande déjà assignée**
- Le PK **est vide** (aucune palette présente)
- Le PK **n'a aucune tâche en direction de celui-ci**
### Choix de la commande
```mermaid
flowchart TD
A[PK éligible en mode Picking] --> B{Commande Messagerie\ndisponible ?}
B -- Oui --> C{PK_TRANSPORTEUR_MESSAGERIE\ncontient une valeur ?}
C -- Non --> D[Assigner 1ère Messagerie\net enregistrer PK dans param]
C -- Oui --> E{Valeur = ce PK ?}
E -- Oui --> F[Assigner prochaine Messagerie\ndu même transporteur]
F --> G{Commande trouvée ?}
G -- Non --> H[Vider le paramètre]
E -- Non --> I[Ignorer les Messagerie\nde ce transporteur]
I --> J[Chercher autre commande]
B -- Non --> J
H --> J
J --> K[Assignation standard\npar tournée / numéro d'arrêt]
```
#### Commandes Messagerie (prioritaires)
Les commandes de **classe Messagerie** sont expédiées le jour même et
sont donc **prioritaires** sur les commandes standard.
Une fois un PK choisi pour une commande Messagerie, **toutes les
commandes Messagerie du même transporteur** doivent être assignées au
même PK. Pour cela, un paramètre par transporteur est créé :
`PK_TRANSPORTEUR_MESSAGERIE`.
Règles :
- À l'assignation d'une commande Messagerie au PK, le nom du PK est
enregistré dans le paramètre
- Si le paramètre contient le nom de ce PK → assigner **uniquement**
des commandes Messagerie du même transporteur. Si aucune n'est
trouvée → vider le paramètre
- Si le paramètre contient un autre PK → ignorer toutes les commandes
Messagerie de ce transporteur pour ce PK
#### Commandes standard
Le processus standard est utilisé pour assigner une commande à une
table de préparation et un PK. Les commandes d'une même tournée sont
préparées en respectant le **numéro d'arrêt** (plus petit numéro
d'arrêt en premier).
## Points d'attention
⚠️ Le Mega Job est le chef d'orchestre du picking : il distribue le
travail aux PK en fonction des modes configurés par PK.
⚠️ Les commandes Messagerie sont prioritaires et ont une affinité
transporteur/PK via `PK_TRANSPORTEUR_MESSAGERIE`.
⚠️ L'éligibilité PK vérifie 4 conditions (mode autorisé, pas de
commande, vide, pas de tâche en cours).
## Questions ouvertes
- [ ] Fréquence du Mega Job — toutes les N secondes ou événementiel ?
(@Nicolas)
- [ ] Sous-WF regroupement et échantillonnage — quand les documenter ?
(@Arthur)
- [ ] Interaction PK_BIGBAG et modes de travail — un PK en mode
Big-Bag peut-il aussi traiter du picking normal ? (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-70 (Mega Job) |
| 2026-05-12 | Arthur | Ajout sous-WF assignation commandes (LIM-80) : Messagerie prioritaire, affinité transporteur/PK |
| 2026-05-13 | Arthur | Restauration sections tronquées (Messagerie détail, commandes standard, points d'attention, questions, historique, références) |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
| [LIM-80](https://easywmsfrance.atlassian.net/browse/LIM-80) | Ticket Jira (assignation commandes) | 2026 |
| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira (Mini Job réception PK) | 2026 |
wiki/limagrain/03-picking/picking-combinatoire.md
+287
View File
@@ -0,0 +1,287 @@
---
title: "Picking sur poste de travail — Expédition client"
tags: [picking, poste, expédition, ordonnancement, MOV, PCK]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-82]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-82 LOT2.2 [PICKING] Ordonnancement des tâches de picking PS PK.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-13
author: Arthur
---
# Picking sur poste de travail — Expédition client
> **Résumé** : processus [CUSTOM] de picking sur poste de travail pour
> les commandes client, avec ordonnancement par espèce, règles de picking
> négatif et contraintes physiques.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le picking chez Limagrain se fait sur les postes de travail automatisés
(pas de picking mobile en allée). Les palettes source et les palettes
de préparation sont acheminées par AGV sur les tables de préparation (TP).
> **Note** : cette page décrit le picking tel que défini dans l'AF V1.5.
> Le projet a depuis évolué vers un modèle « picking combinatoire »
> (CR V3.0, 4 jobs, CstAtt) qui sera documenté séparément.
## Déclenchement
Le picking est déclenché pour les commandes client (RUT type « Client »)
quand des palettes incomplètes sont nécessaires (la quantité demandée
ne correspond pas à des palettes complètes).
Prérequis : un **poste de travail assigné** (auto ou manuellement).
## [CUSTOM] Ordonnancement des palettes au poste
Une fois le poste assigné, les palettes arrivent dans cet ordre :
### Tri par espèce et gerbabilité
1. **Espèce Maïs** toujours en premier (pas la variété mais l'espèce)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité → **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : le maïs = stack 0 (le plus
lourd/stable, donc en base). [CUSTOM] Gestion en **async sur l'ITM** pour
calculer la gerbabilité automatiquement à la création de l'article. Tri
des tâches de picking dans le workflow `StackerCrane_SortTasks_PR`.
### ~~Séparation par traitement commercial~~ SUPPRIMÉ (réu. 11/05/2026)
~~Pas de mélange entre articles avec traitement et sans traitement
sur une même palette fille.~~
**Décision** : `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt
Limagrain ne fait pas de bio, pas de raison de maintenir cette
contrainte. Paramètre réactivable si besoin futur.
> Voir [Séquençage TK → PS — Arbitrage](sequencage-tk-ps.md#arbitrage-des-contradictions-reu-11052026)
> pour le détail de l'analyse comparative.
## [CUSTOM] Règle du picking négatif
**Deux conditions cumulatives** (réu. 11/05/2026) :
1. La quantité à prélever dépasse le **seuil fiche article** (défaut
55%, paramétrable par article via "Complete quantity percent excess
for negative picking")
2. Le **poids unitaire du sac ≥ 7 kg** (raison : instabilité palette si
gros sacs ramenés sur petits sacs)
Si les deux conditions sont remplies → **picking négatif** : au lieu de
déplacer les sacs à expédier, déplacer les sacs qui **retourneront en
stock** (moins de mouvements physiques).
Si l'une des deux conditions n'est pas remplie → picking direct
classique.
> Le picking négatif est **prioritaire sur Maïs first** et toutes les
> autres règles de tri (confirmé par Olivier, réu. 11/05/2026).
> Voir [Séquençage TK → PS](sequencage-tk-ps.md#critère-1--picking-négatif-en-premier).
## [CUSTOM] Calcul équivalent palette (pro rata Bag/pal)
Pour déterminer si une palette est « pleine », calcul en **pro rata
Bag/pal** (réu. 11/05/2026, remplace la logique DevOps "Bag/pal max") :
```
Équivalent palette d'un sac = 1 ÷ Bag/Pal de son lot
```
Le calcul est additif et gère nativement des lots avec des Bag/pal
différents sur une même palette :
```
Exemple :
15 sacs lot Bag/pal 20 + 10 sacs lot Bag/pal 75
= 15/20 + 10/75
= 0,75 + 0,133
= 88,3% → il reste ~12% de place
```
Seuil cible : **~95%** de remplissage (marge de sécurité).
Poids max palette : **1 250 kg** (AF fait foi, corrige 1 200 kg du
DevOps).
## [CUSTOM] Verrou « HORS TOLERANCE » — Recomptage
Si la palette source porte le verrou « HORS TOLERANCE » → recomptage
demandé avant le picking (inventaire).
- Si stock restant suffisant après inventaire → assignation maintenue
(workflow `OnStockAdjust` recalcule uniquement si nécessaire — ne casse
pas la tâche en cours)
- Si plus assez de stock → réassignation ailleurs + retrait verrou
## [CUSTOM] Algorithme de répartition des palettes sur les TP
Logique combinatoire complète gérant tous les cas :
- Picking négatif et enchaînement de pickings négatifs
- Ordonnancement par espèce
- Terminer une palette pleine avant d'en entamer une autre
- Cadencement des buffers devant les postes de picking
- Pas de mélange de traitement commercial (via famille d'article)
- **Contrainte** : l'opérateur ne doit **pas déplacer de sacs d'une table
à l'autre** (sacs lourds)
**Table du milieu** : toujours occupée soit par une palette de picking
négatif, soit par une palette vide de dépôt. Quand la palette de
prélèvement est vidée, l'opérateur la remet manuellement sur une pile
de palettes vides à proximité.
> Prévoir un process sans picking négatif pour les cas où c'est rarement
> utilisé (ou monter le seuil, ex : 70% au lieu de 55%).
## Processus de préparation
### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur
un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
### Picking
1. Palette source arrive sur une TP
2. Palette destination (vide ou en cours) sur une autre TP
3. Opérateur prélève les sacs (ou sacs retour si picking négatif)
4. ~~[CUSTOM] Message MOV envoyé à SAP~~ **ANNULÉ** (décision client)
5. Avant évacuation : choix filmage (CstData transmis à Galileo).
Possibilité de choisir « pas de filmage ».
6. Évacuation palette → PIE → contrôle poids → stockage/expédition
## [CUSTOM] Ordonnancement des tâches PS → PK (LIM-82)
Détail du cadencement des palettes depuis les postes de sortie (PS)
vers les postes de picking (PK). Toutes les tâches de picking se font
sur les tables élévatrices des PK.
### Règles de priorité
1. **Picking négatif toujours en premier** — une seule palette à la fois
pour ce process, toujours déposée sur la **table du centre**
2. **Picking classique ensuite** — jusqu'à **2 palettes simultanées** au
PK, déposées sur les **tables latérales**
3. Le WMS peut envoyer **1 palette picking négatif + 1 palette picking
classique** en même temps (pour compléter la palette post-picking
négatif)
4. Le nombre de palettes de prélèvement au PK ne dépasse **jamais 2**
### Picking négatif — Détail
À chaque tâche de picking négatif :
- Un **nouveau code SSCC** est généré pour la palette où l'excédent de
stock est déposé
- Une **étiquette RFID** est imprimée pour cette nouvelle palette
- La palette de picking négatif va toujours au **centre** du PK
### Cadencement des buffers
Les palettes non encore nécessaires au PK sont dirigées vers les
**zones d'attente** (buffers ES_X) situées entre le PS et le PK.
Le nombre max de palettes pré-chargées est contrôlé par
`MAX_PRELOAD_PAR_PK` (défaut : 3). L'ordre de sortie des buffers
suit `Line.CstAtt` (séquence), pas l'ordre FIFO d'entrée physique.
Voir [Placement PS → PK](placement-ps-pk.md) pour l'algorithme
complet de choix de table et de gestion des buffers.
## Information passage conteneur client
Le passage en conteneur client est visible dans le **LOC** envoyé
toutes les 5 minutes à SAP (flag « client » = true). Voir
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
## Étiquetage
### Cas standard (non MII ou MII mono lot)
- 1 étiquette RFID pour la palette physique bois
### Cas MII multi lots
- 1 étiquette HU RFID pour la palette physique (HU mère)
- 1 étiquette HU sans RFID par ligne de stock (HU fille / intercalaire)
- Impression auto à chaque nouvelle palette (RFID) et à chaque article
(intercalaire)
- Basé sur la **classe de commande**
## Contraintes opérateur (hors EasyWMS)
Règles non gérées par le système mais à respecter :
1. Palette ne doit pas excéder **1,90 m** (sinon rejet PIE)
2. Palette ne doit pas excéder **1 250 kg** (sinon rejet PIE)
3. Pas de gerbage de palette
4. Disposition d'intercalaires entre couches
## Calcul poids de référence (post-picking)
Pour les palettes multi-lignes de stock :
```
Poids réf = Σ (Poids_unité_ligne_i × quantité_ligne_i) + poids_palette_bois
```
Contrôle PIE identique aux autres processus (voir
[Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)).
## Points d'attention
⚠️ Le picking négatif (seuil 55% + poids ≥ 7 kg, deux conditions
cumulatives) est une règle métier intégrée dans EasyWMS — c'est un
développement custom.
⚠️ Le traitement commercial est **désactivé**
(`CONTROLE_TRAITEMENT_COMMERCIAL = false`, réu. 11/05/2026).
⚠️ L'ordonnancement espèce → quantité → poids est géré par EasyWMS
(pas un choix opérateur).
⚠️ Le message MOV est **ANNULÉ** (décision réunion client).
⚠️ Le verrou HORS TOLERANCE déclenche un recomptage mais ne casse pas
l'assignation si le stock restant est suffisant.
⚠️ L'algorithme de répartition TP est le « gros morceau » custom du
picking — gestion combinatoire de tous les cas.
## Questions ouvertes
- [x] Programme de filmage exact — documenté, 8 programmes A→H
(voir [Flux expédition](../04-outbound/flux-expedition.md#filmage))
- [x] Process sans picking négatif / seuil — confirmé 55% + poids ≥ 7 kg
(réu. 11/05/2026)
- [x] Traitement commercial — supprimé
(`CONTROLE_TRAITEMENT_COMMERCIAL = false`, réu. 11/05/2026)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Gerbabilité/stack, algo répartition TP, verrou HORS TOLERANCE, MOV annulé, arrivée palettes 3 TP, filmage CstData |
| 2026-05-12 | Arthur | Ajout ordonnancement PS → PK (LIM-82), picking négatif détaillé, cadencement buffers |
| 2026-05-12 | Arthur | TC supprimé, picking négatif 2 conditions cumulatives 55% + 7 kg, pro rata Bag/pal, poids max 1 250 kg (réu. 11/05/2026) |
| 2026-05-13 | Arthur | Restauration sections perdues (étiquetage, contraintes, poids réf, points d'attention), correction seuil 50% → 55% |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| LIM-82 LOT2.2 | Ticket Jira (ordonnancement PS → PK) | 2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion + analyse comparative | 11/05/2026 |
wiki/limagrain/03-picking/placement-ps-pk.md
+325
View File
@@ -0,0 +1,325 @@
---
title: "Placement des palettes PS → PK (choix de table)"
tags: [picking, placement, table, buffer, ping-pong, algorithme]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-82]
confluence_refs: []
sources: ["Logique combinatoire picking - PS vers PK - V1.0.md"]
last_updated: 2026-05-12
author: Arthur
---
# Placement des palettes PS → PK (choix de table)
> **Résumé** : algorithme exécuté par le WMS lorsqu'une palette source
> arrive au poste de sortie (PS). Il décide sur quelle table du PK la
> poser, ou la redirige vers un buffer ES. Ce process s'exécute **en
> aval** du [séquençage TK → PS](sequencage-tk-ps.md) : les palettes
> arrivent au PS déjà triées.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence
stricte :
```
TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
✅ adjacentes ✅ adjacentes
TABLE_GAUCHE ←————————————————→ TABLE_DROITE
❌ INTERDIT
```
Règles de mouvement :
- Le stock est **toujours sur une palette**, jamais posé directement sur
la table
- L'opérateur peut déplacer du **stock** (sacs, colis) d'une palette à
une autre **uniquement entre deux tables adjacentes**
- Il est **interdit de déplacer une palette d'une table à une autre** —
ni par l'opérateur, ni par l'AGV. Une palette arrive sur une table
et ne peut que repartir (évacuation)
- **TABLE_CENTRE** est le pivot : seule table adjacente aux deux autres
## Déclenchement
L'algorithme est appelé **à chaque arrivée physique d'une palette au
PS**. Le PS interroge le WMS qui retourne une réponse parmi :
- **TABLE_GAUCHE**, **TABLE_CENTRE** ou **TABLE_DROITE** → la palette
est envoyée sur cette table
- **Buffer ESx** → aucune table n'est disponible, la palette est
redirigée vers un emplacement buffer
- **Attente** → ni table ni buffer disponible, la palette reste au PS
## Entrées de l'algorithme
| Donnée | Source |
|--------|--------|
| Tâche courante : palette source, article, quantité, type de picking (NÉGATIF / DIRECT), `Line.CstAtt` (séquence) | Tâche associée à la palette |
| État des 3 tables du PK : VIDE, PALETTE_FILLE_ACTIVE, PALETTE_FILLE_EN_ATTENTE, PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE, EN_ATTENTE_EVACUATION | État temps réel du PK |
| Tâches suivantes de l'OS (triées par `Line.CstAtt` croissant) | OS en base |
| Buffers ES disponibles : parmi ES1–ES16, ceux non occupés ni ciblés | État temps réel des buffers |
| Nombre de buffers déjà affectés à ce PK vs `MAX_PRELOAD_PAR_PK` (défaut : 3) | Compteur par PK |
## Décision niveau 1 : table du PK ou buffer ?
```
FONCTION décider_destination(palette, PK) :
table_cible ← choisir_table(palette, PK)
SI table_cible ≠ NULL :
RETOURNER table_cible
// Aucune table disponible → tenter un buffer
SI nb_buffers_affectés(PK) < MAX_PRELOAD_PAR_PK :
buffer ← premier ES libre
SI buffer existe :
RETOURNER buffer
// Ni table ni buffer disponible
RETOURNER ATTENTE
```
## Décision niveau 2 : choix de la table
Le choix dépend du **type de picking** de la tâche associée.
### Cas PICKING_NÉGATIF
En picking négatif, la palette source arrive sur une table, l'opérateur
retire l'excédent sur une palette posée sur une **table adjacente**,
puis échange d'étiquettes. La palette a besoin de **2 tables** : une
pour elle, une adjacente libre pour l'excédent.
```
FONCTION choisir_table_picking_négatif(PK) :
// Priorité 1 : centre + un côté libre
SI TABLE_CENTRE == VIDE ET (TABLE_GAUCHE == VIDE
OU TABLE_DROITE == VIDE) :
RETOURNER TABLE_CENTRE
// Priorité 2 : côté + centre libre
SI (TABLE_GAUCHE == VIDE OU TABLE_DROITE == VIDE)
ET TABLE_CENTRE == VIDE :
RETOURNER côté vide
// Priorité 3 : centre libre + un côté libérable
SI TABLE_CENTRE == VIDE ET un côté est libérable :
évacuer(côté libérable)
RETOURNER TABLE_CENTRE
// Priorité 4 : un côté libre + centre libérable
SI un côté == VIDE ET TABLE_CENTRE est libérable :
évacuer(TABLE_CENTRE)
RETOURNER côté vide
// Dernier recours : évacuation forcée
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_picking_négatif(PK) // rappel
```
### Cas PICKING_DIRECT
La palette source doit être posée sur une table **adjacente à la
palette fille active**. Le choix se fait en fonction de l'emplacement
de la palette fille.
```
FONCTION choisir_table_picking_direct(tâche, PK) :
// Étape 1 : localiser la palette fille compatible
table_fille ← localiser_palette_fille(tâche, PK)
SI table_fille == NULL :
table_fille ← choisir_table_nouvelle_palette_fille(PK)
// Étape 2 : choisir une table adjacente
tables_adj ← tables_adjacentes(table_fille)
// Prio A : palette source déjà sur une adjacente
// (multi-tâches même palette)
POUR chaque t DANS tables_adj :
SI t contient tâche.PALETTE_SOURCE :
RETOURNER t
// Prio B : adjacente VIDE
// Si 2 adjacentes libres (PF au centre) → ping-pong
adjacentes_vides ← [t POUR t DANS tables_adj SI t == VIDE]
SI len(adjacentes_vides) == 2 :
RETOURNER choisir_côté_ping_pong(PK)
SI len(adjacentes_vides) == 1 :
RETOURNER adjacentes_vides[0]
// Prio C : adjacente en cours d'évacuation (AGV en route)
POUR chaque t DANS tables_adj :
SI t == EN_ATTENTE_EVACUATION :
RETOURNER t
// Prio D : forcer l'évacuation d'une adjacente
t_à_libérer ← choisir_table_à_évacuer(tables_adj)
évacuer(t_à_libérer)
RETOURNER t_à_libérer
```
### Localisation de la palette fille compatible
```
FONCTION localiser_palette_fille(tâche, PK) :
// Parmi les PF actives
POUR chaque table :
SI table.état == PALETTE_FILLE_ACTIVE :
RETOURNER table
// Note : CONTROLE_TRAITEMENT_COMMERCIAL = false,
// donc pas de filtre TC
// Puis parmi les PF en attente
POUR chaque table :
SI table.état == PALETTE_FILLE_EN_ATTENTE :
RETOURNER table
RETOURNER NULL
```
### Choix de table pour une nouvelle palette fille
```
FONCTION choisir_table_nouvelle_palette_fille(PK) :
// TABLE_CENTRE = pivot → maximise la flexibilité
SI TABLE_CENTRE == VIDE : RETOURNER TABLE_CENTRE
SI TABLE_GAUCHE == VIDE : RETOURNER TABLE_GAUCHE
SI TABLE_DROITE == VIDE : RETOURNER TABLE_DROITE
// Aucune table vide → forcer une évacuation
évacuer_table_prioritaire(PK)
RETOURNER choisir_table_nouvelle_palette_fille(PK)
```
## Optimisation ping-pong
Le ping-pong est l'optimisation principale pour le débit. Il n'est
possible que lorsque la **palette fille est au centre** : les palettes
sources alternent alors entre TABLE_GAUCHE et TABLE_DROITE, de sorte
que la palette suivante est déjà en place quand l'opérateur termine.
```
FONCTION choisir_côté_ping_pong(PK) :
SI TABLE_GAUCHE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_DROITE
SI TABLE_DROITE.état ∈ {PALETTE_SOURCE_EN_PICKING,
PALETTE_SOURCE_EN_ATTENTE} :
RETOURNER TABLE_GAUCHE
// Aucun côté occupé → choix arbitraire
RETOURNER TABLE_GAUCHE
```
**Recentrage** : si la palette fille est sur un côté (issue d'un
picking négatif), le ping-pong est impossible. Si le nombre de
PICKING_DIRECT restants ≥ `SEUIL_RECENTRAGE_PF` (défaut : 3), le WMS
peut déclencher un mouvement AGV pour recentrer la PF sur
TABLE_CENTRE.
## Évacuation des tables — Priorité
Lorsqu'aucune table n'est libre et qu'il faut en libérer une :
```
FONCTION évacuer_table_prioritaire(PK) :
// 1. Palette vide → retrait manuel (pas d'AGV)
// 2. Table déjà en attente d'évacuation → attendre AGV
// 3. Palette source en attente, non réutilisée par
// la prochaine tâche → AGV vers buffer/ASRS
// 4. Palette fille en attente → AGV vers image de quai
// 5. Palette source en attente (même si réutilisée)
// → AGV vers buffer ES
```
## Gestion des buffers ES → PK
Quand une table se libère au PK, le WMS choisit parmi les palettes en
buffer affectées à ce PK :
- Tri par `Line.CstAtt` **croissant** (plus petit = plus prioritaire)
- La première palette compatible avec la table libérée est envoyée
**Règle critique** : l'ordre de sortie des buffers est dicté par
`Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
## Palettes multi-commandes
Une palette source peut être assignée à plusieurs OS.
Après picking de la commande en cours :
- Si la palette a encore des tâches pour d'autres OS → marquée
`MULTI_COMMANDE`, envoyée vers un buffer ES libre
- Elle reste en buffer jusqu'au lancement de l'OS suivant
- Une palette multi-commande au PK ou en mouvement compte comme une
place buffer occupée dans le calcul de `MAX_PRELOAD_PAR_PK`
## Priorité d'accès aux buffers entre PK
Lorsque les buffers ES sont saturés, la priorité est définie par la
séquence du mode "Picking" dans `MODES_PKxx`
(voir [Modes de travail PK](stations-picking.md)) :
- Séquence 1 = priorité la plus haute
- Quand un buffer se libère → affecté en priorité au PK avec la
séquence la plus basse parmi ceux qui ont des palettes en attente
## Paramètres WMS
| Paramètre | Description | Défaut |
|-----------|-------------|--------|
| `MAX_PRELOAD_PAR_PK` | Nombre max de palettes pré-chargées en buffer ES par PK | 3 |
| `SEUIL_RECENTRAGE_PF` | Nombre min de PICKING_DIRECT restants pour recentrer la PF au centre | 3 |
| `CONTROLE_TRAITEMENT_COMMERCIAL` | Séparer ou non les articles par TC sur les palettes filles | `false` (V1.1) |
| `MODES_PKxx` | Modes autorisés + priorité par PK (LIM-69) | — |
| `PK_BIGBAG` | Autorise ou non les big-bags par PK (LIM-70) | — |
## Points d'attention
⚠️ La contrainte d'adjacence est **physique** : l'opérateur ne peut pas
déplacer de sacs entre TABLE_GAUCHE et TABLE_DROITE directement.
⚠️ Le picking négatif nécessite 2 tables (palette source + adjacente
pour l'excédent), ce qui complique la gestion des cas saturés.
⚠️ Le recentrage de la palette fille (AGV) n'est déclenché que si
suffisamment de tâches de picking direct restent (≥ SEUIL_RECENTRAGE_PF).
⚠️ L'ordre de sortie des buffers suit `Line.CstAtt`, pas l'ordre FIFO
d'entrée en buffer.
## Questions ouvertes
(Aucune identifiée — algorithme V1.0 complet)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis spec "Logique combinatoire picking - PS vers PK - V1.0" |
| 2026-05-13 | Arthur | Correction règle déplacement palette (jamais déplacée, ni AGV ni opérateur), ajout jira_ref LIM-82 |
## Références
| Source | Type | Date |
|--------|------|------|
| Logique combinatoire picking - PS vers PK - V1.0 | Spécification technique | 27/04/2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira (modes PK) | 2026 |
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
wiki/limagrain/03-picking/sequencage-tk-ps-historique.md
+98
View File
@@ -0,0 +1,98 @@
---
title: "Séquençage TK → PS — Historique et arbitrage"
tags: [picking, séquençage, historique, décision]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-84]
confluence_refs: []
sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# Séquençage TK → PS — Historique et arbitrage
> **Résumé** : historique des solutions envisagées pour le séquençage
> TK → PS, et arbitrage des contradictions entre les 3 sources
> (DevOps #64854, AF §6.4.8, réunion 11/05/2026).
> Pour l'algorithme retenu, voir
> [Séquençage TK → PS](sequencage-tk-ps.md).
## Solutions envisagées
### Solution 1 — Process isolé sur finalisation des tâches d'OS
Séquençage via `OS.Line.CstAtt`, marquage OS traité via
`OS.CstAtt = true`.
**Problème** : pas assez dynamique en cas de recréation de tâches.
### Solution 2 — Calcul dans le workflow stacker_crane
Intégration dans `Galileo_StackerCraneSearch_PR` /
`StackerCrane_SortTasks_PR`, recalcul complet à chaque exécution.
**Problème** : complexité élevée (requêtes LINQ imbriquées multi-OS).
### Solution 3 — Solution 1 transformée en job
Job planifié, excluant les tâches en cours.
**Problème** : pas assez réactif par rapport à la cadence des TK.
### Solution 4 — Process événementiel (retenue)
Solution 1 déclenchée sur `TaskCreatedEvent` et
`OutboundOrderReleasedEvent`, avec verrouillage `OS.CstAtt`.
**Avantages** : simple, découplée, réactive.
## Arbitrage des contradictions (réu. 11/05/2026)
Analyse comparative : DevOps #64854 (le plus ancien), AF §6.4.8
(intermédiaire), réunion 11/05/2026 Arthur + Justine + Olivier
(fait foi). **Tous les points sont résolus.**
| Sujet | DevOps | AF | Réunion (fait foi) |
|-------|--------|----|--------------------|
| Traitement commercial | À creuser | Séparation stricte | **Supprimé** (`false`) |
| Seuil picking négatif | Pas de seuil | > 50% | **55% ET poids ≥ 7 kg** |
| Poids max palette | 1 200 kg | 1 250 kg | **1 250 kg** (AF) |
| Négatif vs Maïs first | Pas de hiérarchie | Maïs en tête | **Négatif prioritaire** |
| Semences essais | Dédié en haut | Non mentionné | **Couvert par poids** |
| Lots même Bag/pal | Prioriser | — | **Retenu** |
| Différenciation marque | Aucune | — | **Confirmé** |
| Calcul Bag/pal | "Prendre le max" | Équivalent palette | **Pro rata** |
## Changelog V1.1 (11/05/2026)
- Hiérarchie des règles : complétude palette et anti-split
prioritaires sur le tri
- Picking négatif : condition cumulative poids ≥ 7 kg ajoutée
- TC **supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`)
- Calcul remplissage : pro rata Bag/pal (remplace "Bag/pal max")
- Poids max palette : 1 250 kg (corrige 1 200 kg du DevOps)
- Confirmé : mélange espèces OK, pas de gerbage, 1,90 m max
## Points non traités (hors scope réunion)
- Affichage opérateur au PK (consignes, déviation possible)
- Picking négatif < 7 kg en option
- Messagerie carton (navette du lendemain, zone angle Est)
- Verrou réception → recomptage avant picking (AF uniquement)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création — extraction depuis sequencage-tk-ps.md |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion | 11/05/2026 |
| DevOps #64854 | Note historique | — |
| AF §6.4.8 | Analyse fonctionnelle V1.5 | 28/11/2025 |
wiki/limagrain/03-picking/sequencage-tk-ps.md
+155
View File
@@ -0,0 +1,155 @@
---
title: "Séquençage des tâches de picking TK → PS"
tags: [picking, séquençage, transstockeur, événement, workflow, algorithme]
status: draft
standard_ref: concepts/picking.md
jira_refs: [LIM-84, LIM-61]
confluence_refs: []
sources: ["LIM-84 LOT2.2 [PICKING] Séquençage des tâches de picking TK PS.md", "Logique combinatoire picking - TK vers PS - V1.1.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# Séquençage des tâches de picking TK → PS
> **Résumé** : algorithme événementiel (V1.1) qui ordonne les tâches
> de picking depuis les transstockeurs (TK) vers les postes de sortie
> (PS). Il écrit les numéros de séquence `Line.CstAtt` sur chaque
> tâche et contrôle le flag `OS.CstAtt` pour autoriser le
> stacker_crane.
> **Standard EasyWMS** : → voir [Picking](../../concepts/picking.md)
## Déclenchement
L'algorithme est déclenché sur **deux événements** :
- **TaskCreatedEvent** — nouvelle tâche de picking créée (MINI JOB
LIM-75 ou réassignation). Condition : tâche type PICKING et OS
statut Released
- **OutboundOrderReleasedEvent** — OS passe en Released (lancement
ou relance après arrêt)
## Process principal
1. `OS.CstAtt ← false` (verrouille le stacker_crane)
2. Récupérer toutes les tâches de picking de l'OS
3. Filtrer : tâches **en attente** uniquement (en cours = intouchables)
4. Trier selon les 5 critères ci-dessous
5. Écrire les séquences `Line.CstAtt`
6. `OS.CstAtt ← true` (déverrouille le stacker_crane)
## Contraintes amont (constitution palettes filles)
**C1. Palettes les plus complètes possible** — seuil ~95%. Calcul en
pro rata Bag/pal : chaque sac = `1/Bag_pal` de son lot. Additif,
gère nativement les multi-lots.
**C2. Ne pas splitter les lignes de stock** — prioritaire sur les
règles de tri. Regrouper la ligne complète quitte à décaler le maïs.
| Contrainte | Valeur |
|------------|--------|
| Poids max palette | **1 250 kg** |
| Hauteur max | 1,90 m |
| Gerbage | Interdit |
| Mélange espèces | Autorisé |
| Traitement commercial | **Désactivé** (V1.1) |
## Les 5 critères de tri (V1.1)
```
tâches.trier_par(
(1) type_picking ASC // NÉGATIF (0) avant DIRECT (1)
(2) espèce_maïs ASC // MAÏS (0) avant autres (1)
(3) quantité_espèce DESC // espèce la + volumineuse
(4) poids_article DESC // article le + lourd en base
(5) palette_source // regroupement par palette
)
```
### Critère 1 — Picking négatif en premier
Prioritaire sur tout, y compris Maïs first. Condition cumulative
(V1.1) : % quantité > seuil fiche article (défaut 55%) **ET** poids
unitaire sac ≥ 7 kg.
### Critère 2 — Espèce Maïs en premier
Le maïs est lourd/stable → base de palette fille.
### Critère 3 — Espèce la plus volumineuse
Espèce avec la plus grande quantité totale de sacs dans l'OS.
### Critère 4 — Article le plus lourd en base
Les semences essais (légères) se retrouvent naturellement en haut.
### Critère 5 — Regroupement par palette source
L'opérateur enchaîne toutes les tâches d'une palette avant de la
libérer.
## Écriture des séquences (Line.CstAtt)
Deux tâches **interchangeables** reçoivent le **même numéro** de
séquence (ex-aequo), laissant au stacker_crane la liberté
d'optimiser. Interchangeables si : même palette source, OU tous les
critères de tri identiques.
## Détermination picking négatif (MINI JOB LIM-75)
```
SI quantité_à_prélever > seuil_article × quantité_palette_source
ET article unique dans la palette source
ET pas d'attribut logistique à capturer
ET poids_unitaire_sac ≥ 7 kg
ALORS → PICKING_NÉGATIF
SINON → PICKING_DIRECT
```
## Paramètres WMS
| Paramètre | Défaut | Note V1.1 |
|-----------|--------|-----------|
| `CONTROLE_TRAITEMENT_COMMERCIAL` | **false** | Désactivé |
| Seuil picking négatif (fiche article) | 55% | Inchangé |
| Poids min picking négatif | **7 kg** | Nouveau |
| Seuil remplissage palette | **~95%** | Nouveau |
| Poids max palette | **1 250 kg** | Corrigé |
| `MAX_NB_BUFFER_PK` | 3 | Inchangé |
## Points d'attention
⚠️ Le custom LIM-61 (capacité buffer) doit gérer les palettes
multi-PK.
⚠️ En cas d'erreur du process, l'OS reste bloqué (CstAtt = false).
⚠️ Condition poids ≥ 7 kg : évite l'instabilité palette (gros sacs
ramenés sur petits sacs).
## Liens
- [Placement PS → PK](placement-ps-pk.md) — algorithme aval
- [Picking combinatoire](picking-combinatoire.md) — vue d'ensemble
- [Historique et arbitrage](sequencage-tk-ps-historique.md) —
solutions envisagées + arbitrage contradictions réunion 11/05/2026
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-84 |
| 2026-05-12 | Arthur | Refonte V1.1 : algo complet, 5 critères, contraintes amont, arbitrage réunion 11/05 |
| 2026-05-12 | Arthur | Découpage : historique solutions + arbitrage → page dédiée |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-84](https://easywmsfrance.atlassian.net/browse/LIM-84) | Ticket Jira | 2026 |
| [LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) | Ticket Jira | 2026 |
| Logique combinatoire picking - TK vers PS - V1.1 | Spec technique | 11/05/2026 |
| REU PICKING SEQUENCAGE 11-05-2026 | CR réunion | 11/05/2026 |
wiki/limagrain/03-picking/stations-picking.md
+301
View File
@@ -0,0 +1,301 @@
---
title: "Stations et postes de travail Limagrain"
tags: [picking, stations, postes, ilots, buffer]
status: draft
standard_ref: concepts/stations.md
jira_refs: [LIM-69, LIM-70]
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "LIM-69 - LOT1.3 Modes de travail des PK.md"]
last_updated: 2026-05-12
author: Arthur
---
# Stations et postes de travail Limagrain
> **Résumé** : description des stations de l'entrepôt automatique, des
> postes de travail polyvalents (3 îlots × 2 postes) et des buffers associés.
> **Standard EasyWMS** : → voir [Stations & Routes](../../concepts/stations.md),
> [Mechanical Elements](../../concepts/mechanical-elements.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Chez Limagrain, les postes de travail sont **polyvalents** et multi-processus.
L'ensemble des opérations (réception, picking, regroupement, échantillonnage,
re-certification) se fait sur les mêmes postes physiques, configurables
dynamiquement.
## Cartographie des stations
### Zone entrée production / sortie expéditions
| Station | Description |
|---------|-------------|
| PIE_01 | Poste d'identification 01 (côté quais) |
| NAV_01 | Navette 01 |
### Zone entrée/sortie postes de travail
| Station | Description |
|---------|-------------|
| PIE_02 | Poste d'identification 02 |
| PIE_03 | Poste d'identification 03 |
| REAC_01 | Poste de reconditionnement 01 |
| NAV_02 | Navette 02 |
| ET_21, ET_22 | Tables intermédiaires |
### Zone stockage côté postes de travail
| Station | Description |
|---------|-------------|
| ET_23 à ET_28 | Tables intermédiaires 23 à 28 |
| TE_01 à TE_04 | Tables d'entrée 01 à 04 |
| TS_01 à TS_04 | Tables de sortie 01 à 04 |
### Zone stockage côté quais
| Station | Description |
|---------|-------------|
| ET_11 à ET_15 | Tables intermédiaires 11 à 15 |
| TE/TS_01 à TE/TS_04 | Tables mixtes entrée/sortie 01 à 04 |
### Zone postes de travail
| Station | Description |
|---------|-------------|
| P1 à P6 | Postes de travail 01 à 06 |
| TP11 à TP63 | Tables de préparation 11 à 63 |
## Postes de travail — Architecture physique
### 3 îlots de 2 postes
Physiquement, il y a **3 îlots**, chacun composé de **6 tables de préparation
(TP)**. Chaque îlot peut être configuré de 2 façons :
1. **Mode scindé** : 2 postes individuels × 3 TP chacun (mode par défaut)
2. ~~**Mode global** : 1 poste × 6 TP (mode « esclave »)~~ **ABANDONNÉ**
> **MISE À JOUR** : le mode esclave (6 TP) est abandonné au profit d'un
> simple **message d'avertissement**. Si le poste adjacent est déjà
> ouvert → « Attention, le poste PVx est déjà ouvert. Voulez-vous quand
> même ouvrir ? ». L'opérateur peut confirmer ou annuler. Pas de blocage
> technique, juste un avertissement.
>
> **Justification** : les opérateurs sont physiquement à ~2 mètres l'un
> de l'autre et peuvent se coordonner verbalement. Les AGV ont des
> capteurs de sécurité et demandent l'autorisation de dépose. Trop de cas
> complexes à gérer avec un mode esclave custom. L'AGV amène toujours la
> palette au centre du PV actif.
>
> **Développement** : message d'avertissement à l'ouverture du poste,
> vérification si le poste conjoint est déjà ouvert (via support présent
> ou poste en mode réception), workflow action sur le end process pour
> fermer le poste.
### Numérotation
```
Îlot 1 : P1 (TP11, TP12, TP13) | P2 (TP21, TP22, TP23)
Îlot 2 : P3 (TP31, TP32, TP33) | P4 (TP41, TP42, TP43)
Îlot 3 : P5 (TP51, TP52, TP53) | P6 (TP61, TP62, TP63)
```
### Spécificités P5 & P6
Les postes **P5 et P6** sont équipés d'un **palan** pour la manipulation
de big-bags. Toute opération impliquant un big-bag (bag/pal ≤ 2) doit
être traitée sur P5 ou P6.
**Picking** : WS PK picking rob en priorité, process RF comme fallback
(plus robuste pour picking négatif, multi-tables). Le process de réception
est déjà plugué au mode Automatic tasks (custom) → même mode pour le
picking et la recertification.
Voir [Flux expédition — Préparation](../04-outbound/flux-expedition.md#6-préparation-au-poste-de-travail)
pour les règles détaillées (arrivée palettes 3 TP, algorithme répartition,
ordonnancement par gerbabilité).
### Modes de travail — Configuration et fonctionnement
Chaque poste est **polyvalent** et peut être utilisé pour différents flux.
Le manager configure les modes autorisés et leur priorité ; l'opérateur
ouvre le poste et le WMS gère automatiquement le process en fonction de
la palette qui arrive.
#### Modes disponibles
| Mode | Correspondance EasyWMS |
|------|------------------------|
| Picking | Picking |
| Réception | Réception |
| Regroupement | Consolidation |
| Échantillonnage | Inventaire |
| Re certification | Picking |
> ~~Mode esclave (3 ou 6 tables)~~ **ABANDONNÉ** — remplacé par un simple
> message d'avertissement poste adjacent (voir section dédiée ci-dessous).
#### Configuration par le manager (vassist SmartUI)
Dans la vue des postes de travail, un **bouton d'action "Choix modes de
travail"** est disponible à la sélection d'un ou plusieurs PK. Ce bouton
ouvre une **vassist** qui permet de :
- **Cocher/décocher les modes autorisés** parmi les 5 modes ci-dessus
- **Définir la priorité** de chaque mode coché via un champ numérique
(séquence)
**Règles de validation** à la soumission :
- Chaque mode coché doit avoir une priorité renseignée
- Un mode non coché ne doit pas avoir de priorité
- Au moins un mode doit être coché (pour bloquer un PK, utiliser le
bouton standard dédié)
**Stockage** : la configuration est enregistrée dans un **paramètre
SmartUI dédié par PK** au format :
```
MODES_PK01 = "RECEPTION;1|PICKING;2|CONSOLIDATION;3"
MODES_PK02 = "RECEPTION;1"
```
Chaque entrée : `MODE;PRIORITÉ` séparés par `|`.
Cette configuration est utilisée par le
[Mega Job d'assignation](job-assignation-pk.md)
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) pour
déterminer si un PK est éligible à recevoir des tâches d'un flux donné
et dans quel ordre de priorité.
#### Ouverture du poste par l'opérateur (SmartUI)
L'opérateur accède à **Poste de travail > Station de picking**.
L'interface affiche un **bouton "Fermer le poste"** toujours visible.
Par défaut, le poste fonctionne en **tâche automatique** : le WMS
choisit le bon process en fonction de la palette qui arrive ou qui est
déjà sur le PK. L'opérateur n'a pas à sélectionner manuellement un mode.
#### Avertissement poste adjacent
À chaque ouverture d'un PK, le WMS vérifie si le **poste adjacent** est
déjà ouvert (en mode actif). Le mapping des paires est défini dans le
paramètre `PK_ADJACENT`.
**Si le poste adjacent est actif** → message d'avertissement (y compris
en mode tâche automatique) :
> "Attention, le poste [CODE_PK_ADJACENT] est déjà ouvert.
> Voulez-vous quand même ouvrir ?"
- Bouton **Confirmer** : le PK s'ouvre normalement
- Bouton **Annuler** : le PK reste inactif
**Pas de blocage technique** — uniquement informatif. Les opérateurs sont
physiquement à ~2 mètres et peuvent se coordonner verbalement. Les AGV
ont des capteurs de sécurité et demandent l'autorisation de dépose.
#### Fermeture du poste
Le bouton **"Fermer le poste"** est toujours visible quel que soit l'état.
Au clic :
- Le PK est remis en mode **inactif** (aucun mode actif)
- Le PK redevient éligible pour une nouvelle assignation par le
[Mega Job](job-assignation-pk.md) (sous réserve qu'il n'ait plus de
tâches actives)
#### Paramètres modes de travail
| Paramètre | Description | Valeur par défaut | Exemple |
|-----------|-------------|-------------------|---------|
| MODES_PKxx | Modes autorisés + priorité pour le PK xx (un par PK, via vassist) | _(vide)_ | `RECEPTION;1\|PICKING;2` |
| PK_ADJACENT | Paires de postes adjacents | _(vide)_ | `PK01;PK02\|PK03;PK04` |
### Équipement par poste
- 1 poste léger EasyWMS dupliqué sur 2 écrans
- 1 imprimante Zebra (étiquettes HU RFID)
- 1 imprimante A4 (étiquettes A4)
- 1 douchette multi-format (RFID, QR Code, code à barres)
## [CUSTOM] Mega Job d'assignation des tâches aux postes
→ Voir page dédiée : **[Job d'assignation PK](job-assignation-pk.md)**
([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70))
Job unique « chef d'orchestre » qui vérifie les modes de travail pour
chaque PK et orchestre l'envoi de tâches via des sous-workflows dédiés
(LIM-74, LIM-75). Transverse à tous les flux (réception, picking,
regroupement, échantillonnage, re certification).
## Buffer postes de travail
16 emplacements palettes au sol le long de l'allée TK_01 :
| Nb emplacements | Usage |
|-----------------|-------|
| 14 | Avance pour les processus en cours |
| 2 | Piles de palettes vides |
> ⚠️ 2 emplacements supplémentaires pour palettes rejetées en attente de
> libération d'un poste de travail.
### [CUSTOM] Buffer configurable
Les emplacements du buffer sont **interchangeables** : un champ « type de
fonctionnement » peut être modifié quand l'emplacement est vide.
### [CUSTOM] Bouton d'évacuation
Un bouton spécifique sur l'écran EasyWMS permet d'évacuer automatiquement
une palette du buffer vers le convoyeur d'entrée pour stockage.
## Piles de palettes vides par poste
- **2 piles par îlot de travail** (et non par poste individuel)
- Emplacement picking dédié pour réapprovisionnement automatique sur
seuil
- Aide à la manutention sur chaque poste pour prendre/poser des palettes
- [CUSTOM] Bouton WfAction pour demander ou renvoyer une pile —
l'opérateur choisit la pile à réapprovisionner parmi une liste
Voir [Palettes vides](../02-stockage/palettes-vides.md) pour le détail.
## Points d'attention
⚠️ Un poste fermé ne peut pas être assigné à un processus.
⚠️ L'assignation automatique du poste optimise la distance la plus courte.
⚠️ Si une TP est HS, elle peut être bloquée individuellement sans impacter
le reste du poste.
⚠️ L'entrée côté postes de travail et l'entrée côté quais sont
interchangeables manuellement en cas de blocage long terme (bouton de
redirection).
## Questions ouvertes
- [ ] Détail de la gestion des tables de préparation bloquées (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Mode esclave abandonné, job transverse, vassist modes, 2 piles/îlot |
| 2026-05-05 | Arthur | Cross-ref flux expédition, picking WS vs RF, contrainte Big-Bag |
| 2026-05-12 | Arthur | Détail modes de travail (LIM-69) : vassist manager, paramètres MODES_PKxx/PK_ADJACENT, tâche automatique, avertissement adjacent, fermeture poste. Renvoi job vers page dédiée (LIM-70) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| [LIM-69](https://easywmsfrance.atlassian.net/browse/LIM-69) | Ticket Jira | 2026 |
wiki/limagrain/04-outbound/.fuse_hidden0000003f00000018
+184
View File
@@ -0,0 +1,184 @@
---
title: "Quais, poumons et chargement"
tags: [outbound, quais, poumons, chargement, AGV, étiqueteuse]
status: draft
standard_ref: concepts/shipping.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Quais, poumons et chargement
> **Résumé** : description physique et logique des quais, poumons (images
> de quai) et du processus de chargement/déchargement chez Limagrain.
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose de 6 quais physiques et 11 poumons (images de quai). Les
quais sont utilisés à la fois pour la réception et l'expédition, avec un
paramétrage du mode de fonctionnement.
## Configuration physique
### 6 quais
Modes de fonctionnement configurables par quai :
- Réception uniquement
- Expédition uniquement
- Les deux
### 11 poumons (images de quai)
Chaque poumon est composé de **26 emplacements palettes au sol**, répartis en
2 colonnes de 13 emplacements numérotés.
Toutes les combinaisons quai/poumon sont possibles — aucune restriction.
La cohérence des assignations est de la responsabilité de Limagrain.
### [CUSTOM] Quai fictif « Parking »
À l'arrivée d'un camion, un agent de quai peut lui assigner un quai fictif
**« Parking »** en attendant qu'un quai réel soit affecté. Cela permet
d'identifier les camions en attente.
[CUSTOM] Une fois quai + image de quai sélectionnés, un écran parking affiche
« Plaque d'immatriculation + N° de quai » pour le chauffeur.
## Règles d'assignation
### Réception
- L'assignation quai + image de quai est **manuelle**
- [CUSTOM] Une fois sélectionnés, quai et image de quai sont **réservés**
(indisponibles pour une autre assignation)
- Si l'image de quai est pleine, une autre doit être assignée manuellement
- [CUSTOM] Libération automatique de l'image de quai quand toutes les
tâches AGV sont exécutées
- Libération manuelle du quai quand le véhicule est parti
### Expédition
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai (poumon d'expédition). Il suffit d'assigner un
poumon pour lancer la livraison.
**À la libération de la commande** :
- Le stock va jusqu'à l'image de quai (poumon exp)
- Le vrai quai est précisé ultérieurement (pour affichage chauffeur)
- Association commande ↔ quai pour le chargement camion
- Association camion ↔ quai dans une vue dédiée
**Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
sont générées, **même si aucun quai n'est encore assigné**.
**Libération** :
- Image de quai : **automatique** à la dernière palette chargée
- Quai : **manuel** au départ du camion
## Disposition et sens de déchargement
L'opérateur décharge en commençant par l'emplacement **le plus éloigné du
quai** pour :
- Éviter le manque de place si plus de palettes que prévu
- Identifier précisément les emplacements occupés pour les AGV
Exemple pour 5 palettes :
```
Quai ← [vide][vide][vide][vide][vide][vide][vide][vide][5][4][3][2][1]
```
## Contraintes physiques
⚠️ La disposition des poumons **ne permet pas la circulation AGV entre les
poumons**. Impact sur les processus de chargement/déchargement.
⚠️ Le marquage au sol et le nombre de palettes par poumon doivent être
respectés par les caristes pour les prises/déposes AGV.
## Blocage quai/poumon
| Élément bloqué | Conséquence |
|----------------|-------------|
| Quai bloqué | Plus assignable → assigner un autre quai manuellement |
| Poumon bloqué | Plus assignable → assigner un autre poumon. Palettes déjà présentes traitées normalement, les suivantes réorientées |
### Cas particulier — Messagerie carton
- Pas d'image de quai assignée
- **Emplacement au sol dédié** par transporteur (ex: « Colissimo »,
« Chronopost ») — ne pas utiliser d'image de quai classique pour ne
pas perdre 25 places
- [CUSTOM] À l'import du SOR, vérification combo shipping class code +
transporteur → poumon associé automatiquement
## Points d'attention
⚠️ Le process de messagerie carton n'utilise pas d'image de quai — un
emplacement au sol spécifique est réservé (à définir).
⚠️ Possibilité de modifier quai/image de quai a posteriori manuellement
si les contraintes d'exploitation l'imposent.
## Problème de dépose AGV sur image de quai
Si plusieurs tâches en parallèle pour déposer sur la même image de quai
avec destinations précises (ex : emplacement 26 et 23), et qu'un AGV
dépose en 26 avant 23, celui du 23 est bloqué (pas de recul possible,
emplacements serrés).
**Solutions identifiées** :
1. Demander à déposer sur **l'image de quai** (sans position précise) et
laisser l'AGV (iGO/Still) choisir l'emplacement disponible le plus
proche, puis remonter l'emplacement exact au WMS
2. OU imposer à Still de **respecter l'ordre des STOP** tel que sorti par
le WMS — c'est Still qui est responsable de l'ordonnancement
> ⚠️ À valider avec Still lors d'une réunion technique dédiée.
## Confirmation prise/dépose AGV
Quand l'AGV prend une palette (sortie TK, sortie buffer, sortie PK), il
doit **informer le WMS** que la palette est sur l'AGV (emplacement =
`AGV_00X`), et non plus sur la dernière station ou en Mov.
**Raison** : sans cette confirmation, la capacité de la station reste
incorrecte (occupée informatiquement alors que physiquement vide), ce qui
bloque les flux suivants.
Confirmation de dépose (fin de mission) déjà prévue par Still — il faut
aussi le **début de mission** (prise palette).
Les AGV déposent les palettes sur le poumon en respectant l'**ordre des
arrêts (STOP)** pour la livraison.
## Questions ouvertes
- [ ] Emplacement au sol exact par transporteur pour messagerie carton (@Théo)
- [ ] Validation réunion technique Still pour le problème dépose AGV
sur image de quai (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | QUAI_TEMPORAIRE, messagerie carton, problème dépose AGV, confirmation prise/dépose |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki/limagrain/04-outbound/.fuse_hidden0000004100000019
+226
View File
@@ -0,0 +1,226 @@
---
title: "Flux ERP outbound — Messages expédition"
tags: [outbound, ERP, SOR, RUT, SOF, LOF, PCK, MOV, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Flux ERP outbound — Messages expédition
> **Résumé** : catalogue des messages ERP liés aux processus d'expédition
> chez Limagrain, avec direction, déclencheur et contenu principal.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP expédition utilise XML + Webservice (SAP EWM ↔ GNA).
Pour les messages de réception, voir
[Flux ERP inbound](../01-inbound/flux-erp-inbound.md).
## Messages entrants (SAP → EasyWMS)
### RUT — Route
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification expédition camion |
| Contenu | Image camion (tournée), 1+ ordres de sortie (SOR), date/heure libération, n° stops |
| Types | « Client » (commandes client + messagerie palette), « Messagerie » (messagerie carton) |
### SOR — Shipping Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création commande de sortie dans SAP |
| Contenu | Lignes de stock (article/lot SAP, propriétaire Limagrain, statut de stock, quantité), priorité, date/heure libération |
| Types | « Production » (consommation OF hors recert), « Recert » (consommation OF avec recert) |
## Messages sortants (EasyWMS → SAP)
### SOF — Shipping Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Automatiquement (commande préparée à 100%) ou manuellement (clic opérateur). Envoi multiple possible en cas d'expédition partielle |
| Statut | 🟡 Phase 2 possible. Démarrage possible sans SOF, activation ultérieure. Utile potentiellement pour déclencher la création de HU dans MII |
| Contenu clé | SorCode, Status (Closed/Cancelled), LneContCode (HU), LneItemCode, ShippedQuantity, attributs logistiques |
**Statuts SOF** :
- **Closed** = stock réellement expédié, supprimé du WMS
- **Cancelled** = commande annulée, ShippedQuantity = 0 sur les lignes non
expédiées
### LOF — Load Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Chargement camion terminé |
| Contenu | État des lieux du chargement réel. Ne contient **que les HU effectivement chargées** (pas de ligne à 0 ni d'alerte pour les non chargées). Peut regrouper plusieurs SOR/commandes |
**Articulation LOF / SOF** :
| Message | Contenu | Granularité |
|---------|---------|-------------|
| SOF | Ce qui a été expédié par commande | Par ordre de sortie |
| LOF | HU réellement chargées dans un camion | Par chargement |
**Structure des conteneurs dans le LOF** : arborescence imbriquée :
Palette support (IsSlave=TRUE) → Palette fille (IsSlave=FALSE) → Lignes
de stock avec attributs logistiques. Cas des supports remontés M2I :
Palette US (IsSlave=TRUE) → Séparateur 1 → Séparateur 2.
### [CUSTOM] PCK — Passage Conteneur Client
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Stock préparé — passage en conteneur client EasyWMS |
| Contenu | Information passage conteneur client |
| Envoyé pour | Commande client, consommation OF hors recert, messagerie carton |
### ~~[CUSTOM] MOV — Movement~~ ANNULÉ
> **ANNULÉ** — décision réunion client, jugé inutile.
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | ~~Déplacement de stock entre palettes (picking, regroupement)~~ |
| Contenu | ~~Palette d'origine, palette de destination, nouvelle palette (Oui/Non), quantité + caractéristiques~~ |
## Communication ERP : LOC — Détails
### Principe retenu
Un fichier JSON unique envoyé **toutes les 5 minutes** contenant toutes
les palettes ayant eu un mouvement, les palettes nouvellement créées, et
les palettes supprimées.
### Structure du message
Chaque palette inclut :
- **Flag de type** : Mouvement / Création / Suppression
- **Nouvelle position** (zone de stockage)
- **Quantité** actuelle
- **Code** de la palette
- **Client flag** true / false
Le delta de 5 minutes se base sur le **dernier mouvement** pour détecter
les mouvements (et non une autre date).
> **Usage outbound** : le passage en conteneur client est visible dans le
> LOC (client flag = true), ce qui remplace le besoin d'un message dédié
> à chaque passage.
## Synthèse des communications ERP outbound
| Événement | Mode de communication |
|-----------|----------------------|
| Passage en conteneur client | LOC (toutes les 5 min) |
| ~~Déplacement stock picking~~ | ~~MOV~~ **ANNULÉ** |
| Clôture ordre de sortie | SOF |
| Chargement camion terminé | LOF |
| Réception palette re-certifiée | ASN (depuis MII) |
## Diagramme de séquence — Expédition client complète
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo
participant QUAI as Quai/Poumon
SAP->>WMS: RUT (image camion + SOR)
WMS->>WMS: Libération auto (date atteinte)
WMS->>WMS: Assignation stock
Note over WMS: Palettes complètes → défrag
Note over WMS: Palettes picking → attente poste
WMS->>PK: Assignation poste + palettes picking
PK->>WMS: Picking terminé
Note over WMS: LOC toutes les 5 min (client flag)
WMS->>GAL: Tâches défrag → zone client
WMS->>WMS: Assignation poumon
WMS->>GAL: Tâches sortie + CstData étiqueteuse
GAL->>QUAI: Palettes déposées (ordre STOP)
QUAI->>WMS: Scan étiquette (chargement)
WMS->>SAP: SOF (OS clôturé)
WMS->>SAP: LOF (camion chargé)
```
## Diagramme de séquence — Consommation OF avec recertification
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
SAP->>WMS: SOR (type Recert)
WMS->>WMS: Libération + assignation
WMS->>PK: Palette au poste
PK->>WMS: HU supprimée
WMS->>SAP: SOF
Note over SAP: Nouvelle HU créée hors WMS
SAP->>WMS: ASN (nouvelle palette)
WMS->>WMS: Réception + stockage
```
## Tableau récapitulatif des messages
| Message | Direction | Standard/Custom | Processus | Statut |
|---------|-----------|-----------------|-----------|--------|
| RUT | ERP → WMS | Standard | Expédition client, messagerie | ✅ Actif |
| SOR | ERP → WMS | Standard | Consommation OF, recert | ✅ Actif |
| SOF | WMS → ERP | Standard | Tous (clôture OS) | 🟡 Phase 2 |
| LOF | WMS → ERP | Standard | Chargement terminé | ✅ Actif |
| LOC | WMS → ERP | [CUSTOM] | Toutes les 5 min (mouvements, créations, suppressions) | ✅ Actif |
| PCK | WMS → ERP | [CUSTOM] | Client, OF hors recert, messagerie | ⚠️ **REMPLACÉ** par LOC |
| MOV | WMS → ERP | [CUSTOM] | ~~Picking, regroupement~~ | ⚠️ **ANNULÉ** |
## Points d'attention
⚠️ Le message MOV est **ANNULÉ** (décision réunion client — jugé inutile).
⚠️ Le SOF est automatique quand tous les conteneurs sont chargés.
En cas d'expédition partielle, la clôture (et le SOF) est manuelle.
Les lignes sans quantité expédiée n'apparaissent pas dans le SOF.
⚠️ Pour la recertification, le SOF est envoyé **avant** la réception
de la nouvelle HU (séquence SOF → ASN).
⚠️ Le LOC est envoyé toutes les 5 minutes avec un delta basé sur le
dernier mouvement. Le passage en conteneur client y est visible via
le flag « client ».
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure), synthèse communications |
| 2026-05-06 | Arthur | Enrichissement SOF (phase 2, statuts, contenu), LOF (structure conteneurs, articulation SOF/LOF), PCK remplacé par LOC — depuis CR consolidé |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/04-outbound/.fuse_hidden000000430000001a
+495
View File
@@ -0,0 +1,495 @@
---
title: "Flux expédition — Processus complet"
tags: [outbound, expédition, défragmentation, étiquetage, chargement, recertification, messagerie, litiges, AGV]
status: draft
standard_ref: concepts/shipping.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Flux expédition — Processus complet
> **Résumé** : processus d'expédition de bout en bout en 12 étapes, de la
> réception de l'OS jusqu'à la libération du quai, incluant les flux
> spécifiques (re-certification, messagerie carton, consommation OF, litiges).
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le processus d'expédition est composé de 12 étapes. Les palettes passent
par une zone de défragmentation client dans l'ASRS avant d'être sorties
vers les poumons. Un custom clé gère l'ordonnancement : la défragmentation
ne se déclenche que quand toutes les palettes de picking sont terminées.
## Processus global
```mermaid
flowchart TD
SOR["1. Réception SOR/RUT"] --> LIB["2. Libération auto/manuelle"]
LIB --> ASSIGN["3. Assignation stock"]
ASSIGN --> GEN["4. Génération tâches"]
GEN -->|Picking requis| PK["5. Assignation poste travail"]
GEN -->|Palettes complètes| DEFRAG["CUSTOM: Défrag → zone client"]
PK --> PICK["6. Préparation au poste"]
PICK --> CADENCE["7. Cadencement tâches"]
CADENCE --> POUMON["8. Assignation poumon/quai"]
DEFRAG --> POUMON
POUMON --> SORT["9. Déplacement + étiquetage auto"]
SORT --> AGV["AGV → dépose poumon"]
AGV --> CHARG["10. Chargement camion"]
CHARG --> SOF["11. Clôture → SOF + LOF"]
SOF --> LIBRE["12. Libération quai/poumon"]
```
## Étapes détaillées
### 1. Réception de l'ordre de sortie
L'ERP envoie une commande d'expédition vers EasyWMS : un **SOR** (commande
de sortie) ou un **RUT** (image camion pouvant contenir plusieurs SOR
ordonnancés par n° de STOP). Voir [Ordres de sortie](shipping-orders.md).
### 2. Libération de l'ordre de sortie
| Mode | Description |
|------|-------------|
| Automatique | Date/heure de libération définie dans le SOR/RUT (mode principal). Par défaut `PlannedShippingDate - 48h`. |
| Manuelle | Depuis l'écran des ordres de sortie dans EasyWMS |
### 3. Assignation du stock
Voir [Ordres de sortie — Assignation](shipping-orders.md#assignation-de-stock)
pour les stratégies détaillées (FIFO 24h, économie de mouvement, pas de
FEFO, max palettes complètes).
### 4. Génération des tâches
| Type de palette | Action |
|-----------------|--------|
| Palettes complètes / picking terminées | [CUSTOM] Tâche de défragmentation (reloc) vers zone d'expédition ASRS. Ne se déclenche que si **toutes** les palettes clientes sont « terminées » et qu'aucun quai n'est associé à l'OS. Voir [Défragmentation custom](../02-stockage/defragmentation.md#custom-défrag-client-par-tournée--quai-non-assigné-lim-87). |
| Palettes picking | Aucune tâche tant qu'un poste de travail n'est pas assigné |
> **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) — sauf si le stop précédent est fini.
>
> **Deux customs complémentaires** gèrent l'ordonnancement par STOP :
> quai non assigné → [Défragmentation custom](../02-stockage/defragmentation.md),
> quai assigné → [Séquençage shipping par STOP](sequencage-shipping-stop.md).
> **Note** : l'information du passage en conteneur client est disponible
> dans le LOC envoyé périodiquement à SAP.
### 5. Assignation du poste de travail
Assignation **automatique** depuis EasyWMS. Modes possibles par poste :
Picking, Réception, Regroupement, Échantillonnage, Recertification, Tous.
**Contrainte** : seuls les postes **P5 et P6** (équipés palan) peuvent
être assignés pour les processus comportant au moins une palette Big-Bag.
**Priorité** : WS PK picking rob en priorité, et si trop limité, utiliser
le **process RF** comme fallback (plus robuste pour picking négatif,
multi-tables, etc.). Le process de réception est déjà plugué au mode
Automatic tasks de la WS (custom) → même mode pour le picking.
Voir [Stations picking](../03-picking/stations-picking.md).
### 6. Préparation au poste de travail
#### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
#### Ordonnancement des prélèvements
1. **Espèce Maïs** toujours en premier (pas la variété)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité : **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : maïs = stack 0 (le plus
lourd/stable, en base). [CUSTOM] Gestion en async sur l'ITM pour calculer
la gerbabilité automatiquement à la création de l'article. Tri via
workflow `StackerCrane_SortTasks_PR`.
#### Règles de picking
| Règle | Détail |
|-------|--------|
| Picking négatif | Si quantité à prélever > 50% → déplacer les sacs qui restent |
| Pas de mélange traitement commercial | Articles avec/sans traitement sur palettes filles séparées (via famille d'article) |
| Verrou « HORS TOLERANCE » | Si présent → recomptage avant picking. Si stock restant suffisant après inventaire → assignation maintenue. Sinon → réassignation ailleurs + retrait verrou. |
#### Algorithme de répartition des palettes sur les TP
[CUSTOM] Logique combinatoire complète gérant : picking négatif et
enchaînements, ordonnancement par espèce, terminer une palette pleine
avant d'en entamer une autre, cadencement des buffers, pas de mélange
traitement commercial, contrainte opérateur (pas de déplacement de sacs
d'une table à l'autre — sacs lourds).
**Table du milieu** : toujours occupée soit par une palette de picking
négatif, soit par une palette vide de dépôt. Palette vide remise
manuellement sur pile quand vidée.
#### Étiquetage au picking
**Palettes MII et multi-lots** : 1 étiquette HU RFID pour la palette
physique (HU mère) + 1 étiquette HU sans RFID par ligne de stock
(HU fille / intercalaire). Impression auto à chaque nouvelle palette
(RFID) et à chaque article (intercalaire).
**Autres palettes** : 1 étiquette HU RFID uniquement. Basé sur la
classe de commande.
#### Message MOV
~~À chaque déplacement de stock durant le picking, un message MOV est
envoyé à SAP.~~ **ANNULÉ** — vu en réunion client, jugé inutile.
#### Filmage
Avant chaque évacuation, l'opérateur choisit le programme de filmage
(CstData transmis à Galileo). Possibilité de choisir « pas de filmage ».
**Programmes de filmage disponibles** :
| Code | Espèce | Contenant | Mode |
|------|--------|-----------|------|
| A | Tournesol | Sacs | Complet |
| B | Tournesol | Sacs | Réduit |
| C | Tournesol | Big Bag | Complet |
| D | Tournesol | Big Bag | Réduit |
| E | Maïs & Blé | Sacs | Complet |
| F | Maïs & Blé | Sacs | Réduit |
| G | Maïs & Blé | Big Bag | Complet |
| H | Maïs & Blé | Big Bag | Réduit |
Voir [Picking combinatoire](../03-picking/picking-combinatoire.md) pour
les détails du processus de préparation.
### 7. Cadencement des tâches
Séquence pour une commande « classique » :
1. Lancement de la commande (quelques heures/jours avant la prépa réelle)
2. Les tâches de shipping **ne se déclenchent pas** tant que le poumon/quai
n'est pas assigné
3. Les palettes deviennent « client » → information dans le LOC
4. Si la commande n'a pas de poumon assigné, ou si TK dispo (tâche prio
très basse), l'ASRS déplace les palettes de shipping vers une **zone
tampon** du magasin proche des sorties (via défrag en tâche de fond)
5. Si un PK est dispo, les tâches de picking se génèrent → palettes
vont aux PK
6. À chaque palette pickée et terminée :
- Selon classe de commande → retour TK ou non
- Si retour ASRS : tâche AGV (PK → Entrée TK)
- Si messagerie : tâche vers le poumon d'expédition choisi manuellement
- Si aucun poumon choisi → prompt
7. La palette de picking **re-rentre dans le TK directement au bon
endroit** (zone client) avec si possible canal dédié à la route. Pas
de stockage temporaire puis défrag la nuit.
8. Assignation du poumon → génération des tâches de shipping
### 8. Assignation quai / poumon
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai. Simplement assigner un poumon pour lancer la
livraison.
**À la libération** : le stock va jusqu'à l'image de quai (poumon exp).
Le vrai quai est précisé ultérieurement (affichage chauffeur). Association
commande ↔ quai pour le chargement, camion ↔ quai dans une vue dédiée.
**Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
sont générées, même si aucun quai n'est encore assigné.
Voir [Quais et poumons](consolidation-chargement.md).
### 9. Déplacement et étiquetage automatique
Palettes sortent de la zone défrag → poste de sortie ASRS.
**Étiqueteuse automatique** : deux étiqueteuses au niveau des 2 postes de
sortie TK.
Voir la section [Étiqueteuse automatique](#étiqueteuse-automatique)
ci-dessous pour le fonctionnement détaillé.
Ordonnancement des palettes sur le poumon par **n° STOP** (ordre de
livraison). Les AGV déposent en respectant l'ordre des arrêts.
### 10. Chargement camion
Le chargement camion est créé par le RUT.
1. Vérification que la palette a été étiquetée automatiquement. Si échec :
impression manuelle via imprimante sur les quais.
2. Scan de l'étiquette pour confirmer la prise en charge
3. Dépose de la palette dans le camion
4. Palette suivante jusqu'à fin de chargement
**Fermeture auto** si chargement complet : possibilité de lancer un
CloseCommand sur l'OS pour expédier ce qui est chargé.
### 11. Clôture de l'ordre de sortie
- **Automatique** lorsque tous les conteneurs sont chargés
- Messages **SOF + LOF** envoyés vers SAP
Dans un SOF, les lignes sans quantité expédiée **n'apparaissent pas**
(pas de ligne à 0).
Si un premier chargement est clôturé partiellement → vérifier si un
deuxième chargement est recréé automatiquement pour le reliquat.
> ⚠️ À paramétrer et tester : comportement du reliquat chargement
> camion, notamment avec fichier RUT.
- Le LOF représente l'image exacte du camion (palettes physiquement
chargées)
- Si une commande est expédiée sur 2 camions → 2 LOF distincts
- X SOF par commande si expédition partielle
### 12. Libération quai / image de quai
| Élément | Mode de libération |
|---------|-------------------|
| Image de quai | **Automatique** — dernière palette chargée |
| Quai | **Manuel** — départ du camion |
## Étiqueteuse automatique
### Principe
Deux étiqueteuses au niveau des deux postes de sortie TK, pouvant imprimer
une ou plusieurs étiquettes selon le processus.
### Étiquetage au picking
100% des palettes passant par le picking sont étiquetées (étiquette
d'expédition) directement au PK. Un `CstAtt` est positionné à `true` sur
la palette pour indiquer qu'elle a déjà été étiquetée.
### Comportement à la sortie TK
L'étiqueteuse **n'imprime pas** si :
- `CstAtt` = `true` (palette déjà étiquetée au picking)
- OU hauteur palette trop faible (PLC height type = 1)
L'étiqueteuse **imprime** si :
- `CstAtt` = `false` ET PLC height type ≠ 1
- Si impression réussie → `CstAtt` passe à `true`
- Si impression échouée → `CstAtt` passe à `error`
### Mode dégradé — Chargement camion
Si l'opérateur scanne une palette sans étiquette (`CstAtt` = `false` ou
`error`, PLC height type ≠ 1) au chargement camion → impression
automatique sur une imprimante proche du quai.
### Communication Galileo
On envoie un **custom data** à Galileo (pas de changement de
destination/route). Galileo, en recevant le custom data avec le bon
tracking de palette, arrête les rouleaux et lance l'impression. Un seul
chemin — l'arrêt est piloté par le custom data.
### Multi-étiquettes (2 étiquettes)
2 rapports différents → **2 docs de 1 page** (= 2 demandes d'impression
simultanées). L'étiqueteuse articulée colle à 2 endroits différents sur
la palette (positions à définir avec Théo).
### Gestion des pannes
- Imprimante en échec → erreur envoyée à Galileo → Galileo met en
**défaut la ET (station)** correspondante
- Si une des deux étiqueteuses est HS → Galileo reroute automatiquement
vers l'autre poste de sortie
- [CUSTOM Galileo] Communication HS imprimante → mise en défaut ET à
documenter dans le document TMS
## Flux spécifiques
### Re-certification
La re-certification consiste à ré-étiqueter une palette existante pour
lui donner une nouvelle identité (nouvelle HU) sans déplacer physiquement
le stock. C'est une **sortie administrative** suivie d'une **réception
administrative**.
**Pré-requis** : le PK doit être passé en **mode recertif** (par le
manager), ce qui bloque le PK pour les autres types de tâches.
**Flux détaillé :**
1. L'ERP envoie un SOR de type « Recertification »
2. Le WMS crée une tâche vers QUAI_RECERTIF. La route passe par le PK
(seul chemin possible)
3. L'AGV amène la palette au PK assigné
4. [CUSTOM] **Event à l'arrivée sur le PK** : on stocke le code du PK
(ex: PK02) dans un CstAtt de la palette
5. **Route virtuelle** : la palette est déplacée informatiquement du PK
vers QUAI_RECERTIF
6. [CUSTOM] **Event sur le déplacement vers QUAI_RECERTIF** — 3 actions :
- Récupération du CstAtt (code PK d'origine)
- Fermeture de la commande → expédition du stock → génération du SOF
- Création d'une **palette vide** sur le PK d'origine (pour maintenir
la capacité correcte et empêcher le WMS d'envoyer de nouvelles
palettes sur un PK physiquement occupé)
7. L'ERP reçoit le SOF → mise à jour avec son MII en interne
8. L'opérateur recertifie physiquement la palette, ré-étiquette (hors WMS)
9. L'ERP renvoie un **ASN** avec la nouvelle identité palette
10. [CUSTOM] L'opérateur scanne la palette recertifiée au PK → le WMS
propose de choisir la table (prompt position PK). La palette passe
de ASN au bon emplacement PK. La **palette vide est supprimée**
automatiquement.
11. L'opérateur appuie sur « Ranger support » → AGV vient la chercher →
passage au PIE de réception (standard)
> ⚠️ **Risque** : si l'ASN n'est pas encore arrivé au moment du scan →
> erreur, réessayer plus tard.
> ⚠️ **3 mini-customs identifiés** : event de stockage CstAtt + event
> de fermeture/création palette vide + suppression palette vide au scan ASN.
### Messagerie carton
**Solution recommandée** : **Pick and Pack** (module transporteur). Plus
simple, pas de colisage séparé, impression étiquette directe. **Nécessite
le module transporteur.** Plan B : fusion des lignes comme alternative.
**Sans module transporteur** : custom le picking PK avec un mode
« messagerie carton » :
1. Commandes descendues dans un RUT de type « Messagerie carton » (classe
d'expédition)
2. Tous les OS préparés en simultané sur un seul poste de travail
3. Tri par transporteur (l'opérateur ne peut déposer que sur une seule
palette). Via modèle d'expédition à créer avec le client.
4. Impression étiquette colis à la première tâche de picking
(SOR.Code, SOR.Account, SOR.Delivery, SSCC colis 128)
5. Consolidation sur palette unique
6. Prélèvement dans un carton (support identifié) puis sur palette
7. Indicateur à l'opérateur quand un carton ne recevra plus de stock →
fermer le carton
8. Bouton « Palette pleine » sur la WS :
- Impression SSCC
- Collage par l'opérateur
- Prompt du code
- Remontage des supports « colis » sur la palette
9. Fermeture auto aussi possible si palette n'attend plus de stock
10. AGV récupère la palette vers le quai
**Assignation poumon** : [CUSTOM] à l'import du SOR, vérification combo
shipping class code + transporteur → si OK, poumon associé automatiquement.
L'idée retenue est de **ne pas** utiliser d'image de quai classique (sinon
perte de 25 places) mais un **emplacement au sol par transporteur**
(ex: emplacement « Colissimo », « Chronopost »).
> ⚠️ Custom à prévoir pour que la fermeture fonctionne dans le cas d'un
> support non client possédant des supports clients.
### Consommation OF hors recertification
**Prérequis** :
- `AllowAssignStockExcess` à `true` dans la SOR.Line
- Modèle d'expédition avec une stratégie d'assignation de stock
- [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
(= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
sans picking.
- Stock assigné directement déposé sur l'image de quai
- Pas de passage par un poste de travail
Pour les SOR de classe Production, les ruptures de stock ne bloquent pas
l'expédition. Le client utilise `isCritical` / `isRequired` au niveau
SOR.Line si besoin.
### Gestion des litiges (sac endommagé)
1. La palette arrive au PK
2. Problème constaté par l'opérateur sur un stock à picker :
- Bouton « Problème » → « Modif quantité »
- S'il reste du stock dispo : assignation maintenue (workflow
`OnStockAdjust` recalcule uniquement si nécessaire)
- Si plus assez de stock → réassignation ailleurs
3. Autre problème — le support n'est pas ok (90% du stock a un problème) :
- **Verrou de support** interdisant le picking (bouton « mettre sous
révision » en standard, à configurer)
- Tâche créée pour que l'AGV dépose la palette sur un **emplacement
au sol buffer litige** (à valider avec le client)
4. Retour au flux classique
## Modes opératoires
Tous les process doivent être pensés en **3 modes** :
| Mode | Description |
|------|-------------|
| Full AGV | Fonctionnement nominal |
| Mixte | AGV + caristes (cas probable en montée en charge) |
| Full TRF (caristes) | Mode dégradé sans AGV |
Le module AGV standard permet la finalisation manuelle (simulation AGV).
4 TRF disponibles sur site. Réunion dédiée à planifier pour les modes
dégradés.
## Points d'attention
⚠️ L'ordonnancement des palettes sur le poumon respecte le n° STOP.
⚠️ Le custom de défragmentation est le développement clé : il attend que
toutes les palettes de picking soient terminées avant de lancer les relocs.
⚠️ La clôture est automatique pour les OS complets mais **manuelle** en
cas d'expédition partielle.
⚠️ Le message MOV est **annulé** (décision réunion client).
⚠️ Les 3 modes opératoires (Full AGV / Mixte / Full TRF) doivent être
documentés pour chaque process.
## Questions ouvertes
- [ ] Ordonnancement des palettes dans le canal du poumon d'expé du
magasin automatique — géré par le WMS ou naturellement via l'ordre
de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ?
(@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
— à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie en parallèle sur un poste ? (@Justine)
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
- [ ] Réunion technique avec Still pour valider le problème de dépose
AGV sur image de quai (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Réécriture complète : 12 étapes, étiqueteuse auto détaillée, recertif 11 étapes, messagerie carton, conso OF, litiges, modes opératoires, MOV annulé |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki/limagrain/04-outbound/.fuse_hidden000000450000001b
+220
View File
@@ -0,0 +1,220 @@
---
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 | — |
wiki/limagrain/04-outbound/.fuse_hidden000000470000001c
+244
View File
@@ -0,0 +1,244 @@
---
title: "Ordres de sortie — Types et libération"
tags: [outbound, OS, SOR, RUT, libération, assignation, FIFO, LOC]
status: draft
standard_ref: concepts/order-outbound.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Ordres de sortie — Types et libération
> **Résumé** : 4 types d'ordres de sortie chez Limagrain, avec des
> comportements de libération, d'assignation et de préparation distincts.
> **Standard EasyWMS** : → voir [Order Outbound](../../concepts/order-outbound.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'expédition chez Limagrain couvre des flux variés : commandes clients
(palettes et messagerie), approvisionnement production (OF), et
re-certification. Le message d'entrée diffère selon le type.
## Types d'ordres de sortie
| Type | Message ERP | Passage poste travail | Destination |
|------|-------------|----------------------|-------------|
| Commande client | RUT « Client » | Si picking nécessaire | Image de quai |
| Messagerie palette | RUT « Client » | Si picking nécessaire | Image de quai |
| Conso OF hors recertification | SOR « Production » | Non | Image de quai direct |
| Conso OF avec recertification | SOR « Recertification » | Oui | Route virtuelle → réception ASN |
| Messagerie carton | RUT « Messagerie » | Oui | Emplacement au sol dédié |
## Classification (OutboundClassCode)
| OutboundClassCode | Usage | AccountCode |
|-------------------|-------|-------------|
| PRODUCTION | Flux vers l'ancien magasin / M2I | PRODUCTION |
| RECERTIFICATION | Flux vers postes de travail SRS | PRODUCTION |
| CLIENT | Commandes clients | CLIENT |
## Structure RUT / SOR
- **RUT** = image camion, peut contenir **plusieurs OS** (même camion).
Un seul message contenant : Route → SorList → Lignes (pas de fichiers
RUT + SOR séparés)
- **SOR** = commande de sortie de marchandise (1 ou plusieurs palettes)
- Chaque OS peut avoir plusieurs **lignes** (article + quantité)
- Chaque palette est étiquetée et ordonnancée par **n° STOP**
## Paramètres ERP des SOR/RUT
| Paramètre | Valeur | Commentaire |
|-----------|--------|-------------|
| OutboundType | 0 (Customer) | Même pour production |
| Priorité par défaut | 3 (Basse) | Échelle : 0=Urgente → 4=Très basse |
| AutoReleaseDate | PlannedShippingDate - 48h | Si < 48h → date passée = libération immédiate |
| TransactionalLineList | true | Tout ou rien (refus total si erreur) |
| CompleteSorList (RUT) | true | SOR absents de la RUT = supprimés |
| AllowAssignStockExcess | true | Palettes pleines, jamais de picking partiel |
| Limite d'annulation | Statut "Chargé" | Avant = OK, après = refusé |
| IgnoreNulls (RUT) | false | — |
## Gestion des ruptures SOR Production
SAP ne connaît pas la répartition stock entre ASRS et autres entrepôts.
Beaucoup de lignes seront en rupture (affichage rouge = **normal et attendu**).
Le WMS prépare ce qu'il peut, SAP supprime le résiduel 3-4 jours plus tard
via un DELETE complet du SOR.
Pas de SOF en phase 1 pour la production. Détection des manquants = mode
manuel.
## Quai recertification
Pour les SOR de type recertification :
`AssignedDockStationCode = "QUAI_RECERTIFICATION"` (quai fictif, renseigné
par Limagrain dans le SOR).
## Libération
### Libération automatique (mode principal)
La date/heure de libération est descendue dans l'interface SOR ou RUT.
EasyWMS vérifie périodiquement et libère quand la date est atteinte.
Séquence :
1. Vérification date → date atteinte
2. Statut → « Libéré »
3. Assignation stock par ligne
4. Génération tâches expédition/prélèvement
5. Statut → « En préparation » ou « En rupture de stock »
### Libération manuelle
Depuis l'écran « Ordres de sortie » → sélection → « Libérer ». Possible
uniquement si statut « En attente », « En préparation » ou « En rupture ».
### Priorité
- Priorité définie à la création (dans le SOR/RUT)
- Modifiable dans EasyWMS avant libération (si libération manuelle)
- Par défaut : ordre de réception (FIFO de création)
## Assignation de stock
### Sélection du stock valide
Filtres appliqués :
1. Article (lot SAP) + attributs logistiques (article Limagrain, propriétaire
Limagrain, statut de stock) correspondent à la ligne demandée
2. Stock **et** conteneur sans verrou empêchant l'expédition
3. Stock pas dans une allée bloquée
4. Emplacement sans erreur d'extraction/dépose
5. Stock non déjà assigné à un autre OS
6. Stock sans tâche d'un autre processus
### Stratégie d'assignation
Dans l'ordre de priorité :
1. **Article/lot SAP + attributs logistiques** spécifiés dans le SOR/RUT
2. **Économie de mouvement** (minimum de mouvements) — **prioritaire**
3. **FIFO sur 24h** : standard confirmé. Les palettes reçues le même jour
ont le même FIFO (heures/minutes ignorées), ce qui permet de prendre
la palette la plus accessible dans un canal. Pas de FIFO strict
infra-journalier.
4. **Pas de FEFO** — la proposition initiale de faire du FEFO sur du stock
sans DLC est **abandonnée**. Il n'y a pas de date d'expiration sur les
produits. Le FIFO journalier est retenu.
5. **Maximum palettes complètes** puis palettes incomplètes (avec picking)
> ⚠️ **Attention unités** : certains semi-finis calibrés (ZSIZ) sont gérés
> en kilos, d'autres en big bags. Vérifier que la quantité complète est
> cohérente avec l'unité de réception. À valider avec le client.
## Comportement post-assignation par type
### Commande client / Messagerie palette
- Palettes complètes / picking terminées → [CUSTOM] tâche de
**défragmentation** vers zone de stockage d'expédition dans l'ASRS.
Ne se déclenche que si **toutes** les palettes clientes sont « terminées »
(palettes de picking retournées dans l'ASRS) ET qu'aucun quai n'est
associé à l'OS.
- Palettes picking → **pas de tâche** tant qu'un poste de travail n'est
pas assigné
- Voir [Zones stockage](../02-stockage/zones-stockage.md)
> **Explication du CUSTOM défrag** : en standard, le mode « Expédition
> uniquement » ne reloc pas les palettes de picking (ordonnancement STOP
> faux). Le mode « Picking et expédition » reloc toutes les palettes y
> compris celles à picker, ce qui casse l'ordonnancement quand on les
> ressort. Le custom attend que toutes les palettes de picking soient
> pickées et rangées dans l'ASRS avant de lancer les relocs par STOP.
> **Note** : si un quai est déjà assigné et l'OS libéré, le WMS peut
> sortir les palettes dans le bon ordre des STOP sans défragmentation
> préalable, via de la reloc standard.
### Consommation OF hors recertification
- `AllowAssignStockExcess` à `true` dans la SOR.Line
- [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
(= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
sans picking.
- Stock assigné directement déposé sur l'image de quai — aucun passage
poste de travail
- Ruptures de stock ne bloquent pas l'expédition. Le client utilise
`isCritical` / `isRequired` au niveau SOR.Line si besoin.
- Voir [Flux spécifiques expédition](flux-expedition.md#consommation-of-hors-recertification)
### Consommation OF avec recertification
- Stock assigné mais **aucune tâche** tant que poste de travail non assigné
- Le PK doit être passé en **mode recertif** (par le manager)
- Flux détaillé en 11 étapes — voir
[Re-certification](flux-expedition.md#re-certification)
### Messagerie carton
- Stock assigné mais aucune tâche tant que poste non assigné
- Tous les OS de la RUT préparés **simultanément** sur un seul poste
- Tri par transporteur (l'opérateur ne dépose que sur une seule palette)
- Consolidation sur palette unique avec supports carton identifiés
- Pas d'image de quai — emplacement au sol dédié par transporteur
- [CUSTOM] À l'import du SOR, vérification combo shipping class code +
transporteur → si OK, poumon associé automatiquement
- Voir [Messagerie carton](flux-expedition.md#messagerie-carton)
## Gestion des reliquats
Si stock insuffisant pour une ligne :
- Ligne → statut « rupture de stock » (affichage rouge)
- Reste de la commande peut être expédié (expédition partielle)
- Clôture manuelle de la commande obligatoire
- Si stock redevient disponible avant clôture → peut être préparé
## Création manuelle d'OS
Possible depuis EasyWMS avec choix de destination :
- Table de préparation sur un poste de travail
- Image de quai
## Points d'attention
⚠️ La libération automatique est le mode principal — la date est dans le
message ERP.
⚠️ L'assignation spécifie **toujours** les 4 critères (article, lot SAP,
propriétaire, statut) — pas d'assignation « ouverte ».
⚠️ Le FIFO est à la **journée** (palettes du même jour = même rang FIFO),
avec l'**économie de mouvement** prioritaire sur le FIFO. Pas de FEFO.
⚠️ Les palettes d'expédition sont stockées dans la zone défrag avec si
possible **un canal dédié par route/STOP**.
⚠️ Le custom de défragmentation attend que toutes les palettes de picking
soient terminées et retournées dans l'ASRS avant de lancer les relocs —
c'est le développement clé du flux outbound.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : 5 types OS, FIFO 24h, pas de FEFO, custom défrag, conso OF détaillé, messagerie carton |
| 2026-05-06 | Arthur | Ajout classifications, paramètres ERP, ruptures production, quai recertif (CR consolidé) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/04-outbound/.fuse_hidden000000490000001d
+47
View File
@@ -0,0 +1,47 @@
---
title: "Outbound — Vue d'ensemble"
tags: [outbound, expédition, shipping, index]
status: draft
last_updated: 2026-05-05
---
# Outbound — Vue d'ensemble
> **Périmètre** : flux SOR → RUT → SOF → LOF, consolidation, chargement,
> messages ERP outbound.
> **Standard EasyWMS** : voir [Order Outbound](../../concepts/order-outbound.md),
> [Shipping](../../concepts/shipping.md)
## Pages de cette section
- [Flux expédition](flux-expedition.md)
- [Shipping Orders](shipping-orders.md)
- [Séquençage shipping par STOP](sequencage-shipping-stop.md)
- [Consolidation et chargement](consolidation-chargement.md)
- [Flux ERP outbound](flux-erp-outbound.md)
## Vue synthétique du flux outbound Limagrain
```mermaid
flowchart LR
SAP[SAP: RUT/SOR] --> LIB[Libération]
LIB --> ASS[Assignation stock]
ASS --> COMP[Palettes complètes]
ASS --> PICK[Palettes picking]
COMP --> DEFRAG[Zone défrag client]
PICK --> PK[Poste travail]
PK -->|MOV + PCK| DEFRAG
DEFRAG --> POUMON[Sortie → Poumon]
POUMON --> CHARG[Chargement]
CHARG -->|SOF + LOF| SAP2[SAP]
```
## 4 types d'ordres de sortie
| Type | Interface | Picking | Destination |
|------|-----------|---------|-------------|
| Commande client | RUT « Client » | Oui (partiel) | Poumon → camion |
| Conso OF hors recert | SOR « Production » | Non | Poumon → production |
| Conso OF avec recert | SOR « Recert » | Passage poste | Restockage |
| Messagerie carton | RUT « Messagerie » | Oui | Emplacement sol |
wiki/limagrain/04-outbound/_index.md
+47
View File
@@ -0,0 +1,47 @@
---
title: "Outbound — Vue d'ensemble"
tags: [outbound, expédition, shipping, index]
status: draft
last_updated: 2026-05-05
---
# Outbound — Vue d'ensemble
> **Périmètre** : flux SOR → RUT → SOF → LOF, consolidation, chargement,
> messages ERP outbound.
> **Standard EasyWMS** : voir [Order Outbound](../../concepts/order-outbound.md),
> [Shipping](../../concepts/shipping.md)
## Pages de cette section
- [Flux expédition](flux-expedition.md)
- [Shipping Orders](shipping-orders.md)
- [Séquençage shipping par STOP](sequencage-shipping-stop.md)
- [Consolidation et chargement](consolidation-chargement.md)
- [Flux ERP outbound](flux-erp-outbound.md)
## Vue synthétique du flux outbound Limagrain
```mermaid
flowchart LR
SAP[SAP: RUT/SOR] --> LIB[Libération]
LIB --> ASS[Assignation stock]
ASS --> COMP[Palettes complètes]
ASS --> PICK[Palettes picking]
COMP --> DEFRAG[Zone défrag client]
PICK --> PK[Poste travail]
PK -->|MOV + PCK| DEFRAG
DEFRAG --> POUMON[Sortie → Poumon]
POUMON --> CHARG[Chargement]
CHARG -->|SOF + LOF| SAP2[SAP]
```
## 4 types d'ordres de sortie
| Type | Interface | Picking | Destination |
|------|-----------|---------|-------------|
| Commande client | RUT « Client » | Oui (partiel) | Poumon → camion |
| Conso OF hors recert | SOR « Production » | Non | Poumon → production |
| Conso OF avec recert | SOR « Recert » | Passage poste | Restockage |
| Messagerie carton | RUT « Messagerie » | Oui | Emplacement sol |
wiki/limagrain/04-outbound/consolidation-chargement.md
+184
View File
@@ -0,0 +1,184 @@
---
title: "Quais, poumons et chargement"
tags: [outbound, quais, poumons, chargement, AGV, étiqueteuse]
status: draft
standard_ref: concepts/shipping.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-05
author: Arthur
---
# Quais, poumons et chargement
> **Résumé** : description physique et logique des quais, poumons (images
> de quai) et du processus de chargement/déchargement chez Limagrain.
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Limagrain dispose de 6 quais physiques et 11 poumons (images de quai). Les
quais sont utilisés à la fois pour la réception et l'expédition, avec un
paramétrage du mode de fonctionnement.
## Configuration physique
### 6 quais
Modes de fonctionnement configurables par quai :
- Réception uniquement
- Expédition uniquement
- Les deux
### 11 poumons (images de quai)
Chaque poumon est composé de **26 emplacements palettes au sol**, répartis en
2 colonnes de 13 emplacements numérotés.
Toutes les combinaisons quai/poumon sont possibles — aucune restriction.
La cohérence des assignations est de la responsabilité de Limagrain.
### [CUSTOM] Quai fictif « Parking »
À l'arrivée d'un camion, un agent de quai peut lui assigner un quai fictif
**« Parking »** en attendant qu'un quai réel soit affecté. Cela permet
d'identifier les camions en attente.
[CUSTOM] Une fois quai + image de quai sélectionnés, un écran parking affiche
« Plaque d'immatriculation + N° de quai » pour le chauffeur.
## Règles d'assignation
### Réception
- L'assignation quai + image de quai est **manuelle**
- [CUSTOM] Une fois sélectionnés, quai et image de quai sont **réservés**
(indisponibles pour une autre assignation)
- Si l'image de quai est pleine, une autre doit être assignée manuellement
- [CUSTOM] Libération automatique de l'image de quai quand toutes les
tâches AGV sont exécutées
- Libération manuelle du quai quand le véhicule est parti
### Expédition
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai (poumon d'expédition). Il suffit d'assigner un
poumon pour lancer la livraison.
**À la libération de la commande** :
- Le stock va jusqu'à l'image de quai (poumon exp)
- Le vrai quai est précisé ultérieurement (pour affichage chauffeur)
- Association commande ↔ quai pour le chargement camion
- Association camion ↔ quai dans une vue dédiée
**Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
sont générées, **même si aucun quai n'est encore assigné**.
**Libération** :
- Image de quai : **automatique** à la dernière palette chargée
- Quai : **manuel** au départ du camion
## Disposition et sens de déchargement
L'opérateur décharge en commençant par l'emplacement **le plus éloigné du
quai** pour :
- Éviter le manque de place si plus de palettes que prévu
- Identifier précisément les emplacements occupés pour les AGV
Exemple pour 5 palettes :
```
Quai ← [vide][vide][vide][vide][vide][vide][vide][vide][5][4][3][2][1]
```
## Contraintes physiques
⚠️ La disposition des poumons **ne permet pas la circulation AGV entre les
poumons**. Impact sur les processus de chargement/déchargement.
⚠️ Le marquage au sol et le nombre de palettes par poumon doivent être
respectés par les caristes pour les prises/déposes AGV.
## Blocage quai/poumon
| Élément bloqué | Conséquence |
|----------------|-------------|
| Quai bloqué | Plus assignable → assigner un autre quai manuellement |
| Poumon bloqué | Plus assignable → assigner un autre poumon. Palettes déjà présentes traitées normalement, les suivantes réorientées |
### Cas particulier — Messagerie carton
- Pas d'image de quai assignée
- **Emplacement au sol dédié** par transporteur (ex: « Colissimo »,
« Chronopost ») — ne pas utiliser d'image de quai classique pour ne
pas perdre 25 places
- [CUSTOM] À l'import du SOR, vérification combo shipping class code +
transporteur → poumon associé automatiquement
## Points d'attention
⚠️ Le process de messagerie carton n'utilise pas d'image de quai — un
emplacement au sol spécifique est réservé (à définir).
⚠️ Possibilité de modifier quai/image de quai a posteriori manuellement
si les contraintes d'exploitation l'imposent.
## Problème de dépose AGV sur image de quai
Si plusieurs tâches en parallèle pour déposer sur la même image de quai
avec destinations précises (ex : emplacement 26 et 23), et qu'un AGV
dépose en 26 avant 23, celui du 23 est bloqué (pas de recul possible,
emplacements serrés).
**Solutions identifiées** :
1. Demander à déposer sur **l'image de quai** (sans position précise) et
laisser l'AGV (iGO/Still) choisir l'emplacement disponible le plus
proche, puis remonter l'emplacement exact au WMS
2. OU imposer à Still de **respecter l'ordre des STOP** tel que sorti par
le WMS — c'est Still qui est responsable de l'ordonnancement
> ⚠️ À valider avec Still lors d'une réunion technique dédiée.
## Confirmation prise/dépose AGV
Quand l'AGV prend une palette (sortie TK, sortie buffer, sortie PK), il
doit **informer le WMS** que la palette est sur l'AGV (emplacement =
`AGV_00X`), et non plus sur la dernière station ou en Mov.
**Raison** : sans cette confirmation, la capacité de la station reste
incorrecte (occupée informatiquement alors que physiquement vide), ce qui
bloque les flux suivants.
Confirmation de dépose (fin de mission) déjà prévue par Still — il faut
aussi le **début de mission** (prise palette).
Les AGV déposent les palettes sur le poumon en respectant l'**ordre des
arrêts (STOP)** pour la livraison.
## Questions ouvertes
- [ ] Emplacement au sol exact par transporteur pour messagerie carton (@Théo)
- [ ] Validation réunion technique Still pour le problème dépose AGV
sur image de quai (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | QUAI_TEMPORAIRE, messagerie carton, problème dépose AGV, confirmation prise/dépose |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
wiki/limagrain/04-outbound/flux-erp-outbound.md
+226
View File
@@ -0,0 +1,226 @@
---
title: "Flux ERP outbound — Messages expédition"
tags: [outbound, ERP, SOR, RUT, SOF, LOF, PCK, MOV, interface]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Flux ERP outbound — Messages expédition
> **Résumé** : catalogue des messages ERP liés aux processus d'expédition
> chez Limagrain, avec direction, déclencheur et contenu principal.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication ERP expédition utilise XML + Webservice (SAP EWM ↔ GNA).
Pour les messages de réception, voir
[Flux ERP inbound](../01-inbound/flux-erp-inbound.md).
## Messages entrants (SAP → EasyWMS)
### RUT — Route
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Planification expédition camion |
| Contenu | Image camion (tournée), 1+ ordres de sortie (SOR), date/heure libération, n° stops |
| Types | « Client » (commandes client + messagerie palette), « Messagerie » (messagerie carton) |
### SOR — Shipping Order Request
| Champ | Description |
|-------|-------------|
| Direction | ERP → WMS |
| Déclencheur | Création commande de sortie dans SAP |
| Contenu | Lignes de stock (article/lot SAP, propriétaire Limagrain, statut de stock, quantité), priorité, date/heure libération |
| Types | « Production » (consommation OF hors recert), « Recert » (consommation OF avec recert) |
## Messages sortants (EasyWMS → SAP)
### SOF — Shipping Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Automatiquement (commande préparée à 100%) ou manuellement (clic opérateur). Envoi multiple possible en cas d'expédition partielle |
| Statut | 🟡 Phase 2 possible. Démarrage possible sans SOF, activation ultérieure. Utile potentiellement pour déclencher la création de HU dans MII |
| Contenu clé | SorCode, Status (Closed/Cancelled), LneContCode (HU), LneItemCode, ShippedQuantity, attributs logistiques |
**Statuts SOF** :
- **Closed** = stock réellement expédié, supprimé du WMS
- **Cancelled** = commande annulée, ShippedQuantity = 0 sur les lignes non
expédiées
### LOF — Load Order Fulfilled
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Chargement camion terminé |
| Contenu | État des lieux du chargement réel. Ne contient **que les HU effectivement chargées** (pas de ligne à 0 ni d'alerte pour les non chargées). Peut regrouper plusieurs SOR/commandes |
**Articulation LOF / SOF** :
| Message | Contenu | Granularité |
|---------|---------|-------------|
| SOF | Ce qui a été expédié par commande | Par ordre de sortie |
| LOF | HU réellement chargées dans un camion | Par chargement |
**Structure des conteneurs dans le LOF** : arborescence imbriquée :
Palette support (IsSlave=TRUE) → Palette fille (IsSlave=FALSE) → Lignes
de stock avec attributs logistiques. Cas des supports remontés M2I :
Palette US (IsSlave=TRUE) → Séparateur 1 → Séparateur 2.
### [CUSTOM] PCK — Passage Conteneur Client
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | Stock préparé — passage en conteneur client EasyWMS |
| Contenu | Information passage conteneur client |
| Envoyé pour | Commande client, consommation OF hors recert, messagerie carton |
### ~~[CUSTOM] MOV — Movement~~ ANNULÉ
> **ANNULÉ** — décision réunion client, jugé inutile.
| Champ | Description |
|-------|-------------|
| Direction | WMS → ERP |
| Déclencheur | ~~Déplacement de stock entre palettes (picking, regroupement)~~ |
| Contenu | ~~Palette d'origine, palette de destination, nouvelle palette (Oui/Non), quantité + caractéristiques~~ |
## Communication ERP : LOC — Détails
### Principe retenu
Un fichier JSON unique envoyé **toutes les 5 minutes** contenant toutes
les palettes ayant eu un mouvement, les palettes nouvellement créées, et
les palettes supprimées.
### Structure du message
Chaque palette inclut :
- **Flag de type** : Mouvement / Création / Suppression
- **Nouvelle position** (zone de stockage)
- **Quantité** actuelle
- **Code** de la palette
- **Client flag** true / false
Le delta de 5 minutes se base sur le **dernier mouvement** pour détecter
les mouvements (et non une autre date).
> **Usage outbound** : le passage en conteneur client est visible dans le
> LOC (client flag = true), ce qui remplace le besoin d'un message dédié
> à chaque passage.
## Synthèse des communications ERP outbound
| Événement | Mode de communication |
|-----------|----------------------|
| Passage en conteneur client | LOC (toutes les 5 min) |
| ~~Déplacement stock picking~~ | ~~MOV~~ **ANNULÉ** |
| Clôture ordre de sortie | SOF |
| Chargement camion terminé | LOF |
| Réception palette re-certifiée | ASN (depuis MII) |
## Diagramme de séquence — Expédition client complète
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
participant GAL as Galileo
participant QUAI as Quai/Poumon
SAP->>WMS: RUT (image camion + SOR)
WMS->>WMS: Libération auto (date atteinte)
WMS->>WMS: Assignation stock
Note over WMS: Palettes complètes → défrag
Note over WMS: Palettes picking → attente poste
WMS->>PK: Assignation poste + palettes picking
PK->>WMS: Picking terminé
Note over WMS: LOC toutes les 5 min (client flag)
WMS->>GAL: Tâches défrag → zone client
WMS->>WMS: Assignation poumon
WMS->>GAL: Tâches sortie + CstData étiqueteuse
GAL->>QUAI: Palettes déposées (ordre STOP)
QUAI->>WMS: Scan étiquette (chargement)
WMS->>SAP: SOF (OS clôturé)
WMS->>SAP: LOF (camion chargé)
```
## Diagramme de séquence — Consommation OF avec recertification
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
participant PK as Poste travail
SAP->>WMS: SOR (type Recert)
WMS->>WMS: Libération + assignation
WMS->>PK: Palette au poste
PK->>WMS: HU supprimée
WMS->>SAP: SOF
Note over SAP: Nouvelle HU créée hors WMS
SAP->>WMS: ASN (nouvelle palette)
WMS->>WMS: Réception + stockage
```
## Tableau récapitulatif des messages
| Message | Direction | Standard/Custom | Processus | Statut |
|---------|-----------|-----------------|-----------|--------|
| RUT | ERP → WMS | Standard | Expédition client, messagerie | ✅ Actif |
| SOR | ERP → WMS | Standard | Consommation OF, recert | ✅ Actif |
| SOF | WMS → ERP | Standard | Tous (clôture OS) | 🟡 Phase 2 |
| LOF | WMS → ERP | Standard | Chargement terminé | ✅ Actif |
| LOC | WMS → ERP | [CUSTOM] | Toutes les 5 min (mouvements, créations, suppressions) | ✅ Actif |
| PCK | WMS → ERP | [CUSTOM] | Client, OF hors recert, messagerie | ⚠️ **REMPLACÉ** par LOC |
| MOV | WMS → ERP | [CUSTOM] | ~~Picking, regroupement~~ | ⚠️ **ANNULÉ** |
## Points d'attention
⚠️ Le message MOV est **ANNULÉ** (décision réunion client — jugé inutile).
⚠️ Le SOF est automatique quand tous les conteneurs sont chargés.
En cas d'expédition partielle, la clôture (et le SOF) est manuelle.
Les lignes sans quantité expédiée n'apparaissent pas dans le SOF.
⚠️ Pour la recertification, le SOF est envoyé **avant** la réception
de la nouvelle HU (séquence SOF → ASN).
⚠️ Le LOC est envoyé toutes les 5 minutes avec un delta basé sur le
dernier mouvement. Le passage en conteneur client y est visible via
le flag « client ».
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure), synthèse communications |
| 2026-05-06 | Arthur | Enrichissement SOF (phase 2, statuts, contenu), LOF (structure conteneurs, articulation SOF/LOF), PCK remplacé par LOC — depuis CR consolidé |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/04-outbound/flux-expedition.md
+489
View File
@@ -0,0 +1,489 @@
---
title: "Flux expédition — Processus complet"
tags: [outbound, expédition, défragmentation, étiquetage, chargement, recertification, messagerie, litiges, AGV]
status: draft
standard_ref: concepts/shipping.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
last_updated: 2026-05-13
author: Arthur
---
# Flux expédition — Processus complet
> **Résumé** : processus d'expédition de bout en bout en 12 étapes, de la
> réception de l'OS jusqu'à la libération du quai, incluant les flux
> spécifiques (re-certification, messagerie carton, consommation OF, litiges).
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Le processus d'expédition est composé de 12 étapes. Les palettes passent
par une zone de défragmentation client dans l'ASRS avant d'être sorties
vers les poumons. Un custom clé gère l'ordonnancement : la défragmentation
ne se déclenche que quand toutes les palettes de picking sont terminées.
## Processus global
```mermaid
flowchart TD
SOR["1. Réception SOR/RUT"] --> LIB["2. Libération auto/manuelle"]
LIB --> ASSIGN["3. Assignation stock"]
ASSIGN --> GEN["4. Génération tâches"]
GEN -->|Picking requis| PK["5. Assignation poste travail"]
GEN -->|Palettes complètes| DEFRAG["CUSTOM: Défrag → zone client"]
PK --> PICK["6. Préparation au poste"]
PICK --> CADENCE["7. Cadencement tâches"]
CADENCE --> POUMON["8. Assignation poumon/quai"]
DEFRAG --> POUMON
POUMON --> SORT["9. Déplacement + étiquetage auto"]
SORT --> AGV["AGV → dépose poumon"]
AGV --> CHARG["10. Chargement camion"]
CHARG --> SOF["11. Clôture → SOF + LOF"]
SOF --> LIBRE["12. Libération quai/poumon"]
```
## Étapes détaillées
### 1. Réception de l'ordre de sortie
L'ERP envoie une commande d'expédition vers EasyWMS : un **SOR** (commande
de sortie) ou un **RUT** (image camion pouvant contenir plusieurs SOR
ordonnancés par n° de STOP). Voir [Ordres de sortie](shipping-orders.md).
### 2. Libération de l'ordre de sortie
| Mode | Description |
|------|-------------|
| Automatique | Date/heure de libération définie dans le SOR/RUT (mode principal). Par défaut `PlannedShippingDate - 48h`. |
| Manuelle | Depuis l'écran des ordres de sortie dans EasyWMS |
### 3. Assignation du stock
Voir [Ordres de sortie — Assignation](shipping-orders.md#assignation-de-stock)
pour les stratégies détaillées (FIFO 24h, économie de mouvement, pas de
FEFO, max palettes complètes).
### 4. Génération des tâches
| Type de palette | Action |
|-----------------|--------|
| Palettes complètes / picking terminées | [CUSTOM] Tâche de défragmentation (reloc) vers zone d'expédition ASRS. Ne se déclenche que si **toutes** les palettes clientes sont « terminées » et qu'aucun quai n'est associé à l'OS. Voir [Défragmentation custom](../02-stockage/defragmentation.md#custom-défrag-client-par-tournée--quai-non-assigné-lim-87). |
| Palettes picking | Aucune tâche tant qu'un poste de travail n'est pas assigné |
> **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) — sauf si le stop précédent est fini.
>
> **Deux customs complémentaires** gèrent l'ordonnancement par STOP :
> quai non assigné → [Défragmentation custom](../02-stockage/defragmentation.md),
> quai assigné → [Séquençage shipping par STOP](sequencage-shipping-stop.md).
> **Note** : l'information du passage en conteneur client est disponible
> dans le LOC envoyé périodiquement à SAP.
### 5. Assignation du poste de travail
Assignation **automatique** depuis EasyWMS. Modes possibles par poste :
Picking, Réception, Regroupement, Échantillonnage, Recertification, Tous.
**Contrainte** : seuls les postes **P5 et P6** (équipés palan) peuvent
être assignés pour les processus comportant au moins une palette Big-Bag.
**Priorité** : WS PK picking rob en priorité, et si trop limité, utiliser
le **process RF** comme fallback (plus robuste pour picking négatif,
multi-tables, etc.). Le process de réception est déjà plugué au mode
Automatic tasks de la WS (custom) → même mode pour le picking.
Voir [Stations picking](../03-picking/stations-picking.md).
### 6. Préparation au poste de travail
#### Arrivée des palettes (toujours un poste 3 TP)
- Première palette au **centre** si picking négatif proposé, sinon sur un côté
- Si une palette est sur un côté et qu'on propose du picking négatif →
prévenir l'opérateur de déplacer la palette au centre
- La palette client revient **toujours** au centre
- Pas de prépa sur 6 TP en simultané
#### Ordonnancement des prélèvements
1. **Espèce Maïs** toujours en premier (pas la variété)
2. Puis espèce avec la **plus grande quantité** dans la commande
3. Si égalité : **article/lot le plus lourd** en base de palette
**Mapping Espèce → stack (gerbabilité)** : maïs = stack 0 (le plus
lourd/stable, en base). [CUSTOM] Gestion en async sur l'ITM pour calculer
la gerbabilité automatiquement à la création de l'article. Tri via
workflow `StackerCrane_SortTasks_PR`.
#### Règles de picking
| Règle | Détail |
|-------|--------|
| Picking négatif | **Deux conditions cumulatives** (réu. 11/05/2026) : seuil fiche article (défaut **55%**, pas 50%) ET poids unitaire sac **≥ 7 kg**. Si l'une des deux n'est pas remplie → picking direct classique. Voir [Picking combinatoire](../03-picking/picking-combinatoire.md#custom-règle-du-picking-négatif). |
| ~~Traitement commercial~~ | ~~Articles avec/sans traitement sur palettes filles séparées~~ — **SUPPRIMÉ** (réu. 11/05/2026, `CONTROLE_TRAITEMENT_COMMERCIAL = false`). L'entrepôt ne fait pas de bio. |
| Verrou « HORS TOLERANCE » | Si présent → recomptage avant picking. Si stock restant suffisant après inventaire → assignation maintenue. Sinon → réassignation ailleurs + retrait verrou. |
#### Algorithme de répartition des palettes sur les TP
[CUSTOM] Logique combinatoire complète gérant : picking négatif et
enchaînements, ordonnancement par espèce, terminer une palette pleine
avant d'en entamer une autre, cadencement des buffers, pas de mélange
traitement commercial, contrainte opérateur (pas de déplacement de sacs
d'une table à l'autre — sacs lourds).
**Table du milieu** : toujours occupée soit par une palette de picking
négatif, soit par une palette vide de dépôt. Palette vide remise
manuellement sur pile quand vidée.
#### Étiquetage au picking
**Palettes MII et multi-lots** : 1 étiquette HU RFID pour la palette
physique (HU mère) + 1 étiquette HU sans RFID par ligne de stock
(HU fille / intercalaire). Impression auto à chaque nouvelle palette
(RFID) et à chaque article (intercalaire).
**Autres palettes** : 1 étiquette HU RFID uniquement. Basé sur la
classe de commande.
#### Message MOV
~~À chaque déplacement de stock durant le picking, un message MOV est
envoyé à SAP.~~ **ANNULÉ** — vu en réunion client, jugé inutile.
#### Filmage
Avant chaque évacuation, l'opérateur choisit le programme de filmage
(CstData transmis à Galileo). Possibilité de choisir « pas de filmage ».
**Programmes de filmage disponibles** :
| Code | Espèce | Contenant | Mode |
|------|--------|-----------|------|
| A | Tournesol | Sacs | Complet |
| B | Tournesol | Sacs | Réduit |
| C | Tournesol | Big Bag | Complet |
| D | Tournesol | Big Bag | Réduit |
| E | Maïs & Blé | Sacs | Complet |
| F | Maïs & Blé | Sacs | Réduit |
| G | Maïs & Blé | Big Bag | Complet |
| H | Maïs & Blé | Big Bag | Réduit |
Voir [Picking combinatoire](../03-picking/picking-combinatoire.md) pour
les détails du processus de préparation.
### 7. Cadencement des tâches
Séquence pour une commande « classique » :
1. Lancement de la commande (quelques heures/jours avant la prépa réelle)
2. Les tâches de shipping **ne se déclenchent pas** tant que le poumon/quai
n'est pas assigné
3. Les palettes deviennent « client » → information dans le LOC
4. Si la commande n'a pas de poumon assigné, ou si TK dispo (tâche prio
très basse), l'ASRS déplace les palettes de shipping vers une **zone
tampon** du magasin proche des sorties (via défrag en tâche de fond)
5. Si un PK est dispo, les tâches de picking se génèrent → palettes
vont aux PK
6. À chaque palette pickée et terminée :
- Selon classe de commande → retour TK ou non
- Si retour ASRS : tâche AGV (PK → Entrée TK)
- Si messagerie : tâche vers le poumon d'expédition choisi manuellement
- Si aucun poumon choisi → prompt
7. La palette de picking **re-rentre dans le TK directement au bon
endroit** (zone client) avec si possible canal dédié à la route. Pas
de stockage temporaire puis défrag la nuit.
8. Assignation du poumon → génération des tâches de shipping
### 8. Assignation quai / poumon
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
toutes les images de quai. Simplement assigner un poumon pour lancer la
livraison.
**À la libération** : le stock va jusqu'à l'image de quai (poumon exp).
Le vrai quai est précisé ultérieurement (affichage chauffeur). Association
commande ↔ quai pour le chargement, camion ↔ quai dans une vue dédiée.
**Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
sont générées, même si aucun quai n'est encore assigné.
Voir [Quais et poumons](consolidation-chargement.md).
### 9. Déplacement et étiquetage automatique
Palettes sortent de la zone défrag → poste de sortie ASRS.
**Étiqueteuse automatique** : deux étiqueteuses au niveau des 2 postes de
sortie TK.
Voir la section [Étiqueteuse automatique](#étiqueteuse-automatique)
ci-dessous pour le fonctionnement détaillé.
Ordonnancement des palettes sur le poumon par **n° STOP** (ordre de
livraison). Les AGV déposent en respectant l'ordre des arrêts.
### 10. Chargement camion
Le chargement camion est créé par le RUT.
1. Vérification que la palette a été étiquetée automatiquement. Si échec :
impression manuelle via imprimante sur les quais.
2. Scan de l'étiquette pour confirmer la prise en charge
3. Dépose de la palette dans le camion
4. Palette suivante jusqu'à fin de chargement
**Fermeture auto** si chargement complet : possibilité de lancer un
CloseCommand sur l'OS pour expédier ce qui est chargé.
### 11. Clôture de l'ordre de sortie
- **Automatique** lorsque tous les conteneurs sont chargés
- Messages **SOF + LOF** envoyés vers SAP
Dans un SOF, les lignes sans quantité expédiée **n'apparaissent pas**
(pas de ligne à 0).
Si un premier chargement est clôturé partiellement → vérifier si un
deuxième chargement est recréé automatiquement pour le reliquat.
> ⚠️ À paramétrer et tester : comportement du reliquat chargement
> camion, notamment avec fichier RUT.
- Le LOF représente l'image exacte du camion (palettes physiquement
chargées)
- Si une commande est expédiée sur 2 camions → 2 LOF distincts
- X SOF par commande si expédition partielle
### 12. Libération quai / image de quai
| Élément | Mode de libération |
|---------|-------------------|
| Image de quai | **Automatique** — dernière palette chargée |
| Quai | **Manuel** — départ du camion |
## Étiqueteuse automatique
### Principe
Deux étiqueteuses au niveau des deux postes de sortie TK, pouvant imprimer
une ou plusieurs étiquettes selon le processus.
### Étiquetage au picking (étiqueteuse auto)
100% des palettes passant par le picking sont étiquetées (étiquette
d'expédition) directement au PK. Un `CstAtt` est positionné à `true` sur
la palette pour indiquer qu'elle a déjà été étiquetée.
### Comportement à la sortie TK
L'étiqueteuse **n'imprime pas** si :
- `CstAtt` = `true` (palette déjà étiquetée au picking)
- OU hauteur palette trop faible (PLC height type = 1)
L'étiqueteuse **imprime** si :
- `CstAtt` = `false` ET PLC height type ≠ 1
- Si impression réussie → `CstAtt` passe à `true`
- Si impression échouée → `CstAtt` passe à `error`
### Mode dégradé — Chargement camion
Si l'opérateur scanne une palette sans étiquette (`CstAtt` = `false` ou
`error`, PLC height type ≠ 1) au chargement camion → impression
automatique sur une imprimante proche du quai.
### Communication Galileo
On envoie un **custom data** à Galileo (pas de changement de
destination/route). Galileo, en recevant le custom data avec le bon
tracking de palette, arrête les rouleaux et lance l'impression. Un seul
chemin — l'arrêt est piloté par le custom data.
### Multi-étiquettes (2 étiquettes)
2 rapports différents → **2 docs de 1 page** (= 2 demandes d'impression
simultanées). L'étiqueteuse articulée colle à 2 endroits différents sur
la palette (positions à définir avec Théo).
### Gestion des pannes
- Imprimante en échec → erreur envoyée à Galileo → Galileo met en
**défaut la ET (station)** correspondante
- Si une des deux étiqueteuses est HS → Galileo reroute automatiquement
vers l'autre poste de sortie
- [CUSTOM Galileo] Communication HS imprimante → mise en défaut ET à
documenter dans le document TMS
## Flux spécifiques
### Re-certification
La re-certification consiste à ré-étiqueter une palette existante pour
lui donner une nouvelle identité (nouvelle HU) sans déplacer physiquement
le stock. C'est une **sortie administrative** suivie d'une **réception
administrative**.
**Pré-requis** : le PK doit être passé en **mode recertif** (par le
manager), ce qui bloque le PK pour les autres types de tâches.
**Flux détaillé :**
1. L'ERP envoie un SOR de type « Recertification »
2. Le WMS crée une tâche vers QUAI_RECERTIF. La route passe par le PK
(seul chemin possible)
3. L'AGV amène la palette au PK assigné
4. [CUSTOM] **Event à l'arrivée sur le PK** : on stocke le code du PK
(ex: PK02) dans un CstAtt de la palette
5. **Route virtuelle** : la palette est déplacée informatiquement du PK
vers QUAI_RECERTIF
6. [CUSTOM] **Event sur le déplacement vers QUAI_RECERTIF** — 3 actions :
- Récupération du CstAtt (code PK d'origine)
- Fermeture de la commande → expédition du stock → génération du SOF
- Création d'une **palette vide** sur le PK d'origine (pour maintenir
la capacité correcte et empêcher le WMS d'envoyer de nouvelles
palettes sur un PK physiquement occupé)
7. L'ERP reçoit le SOF → mise à jour avec son MII en interne
8. L'opérateur recertifie physiquement la palette, ré-étiquette (hors WMS)
9. L'ERP renvoie un **ASN** avec la nouvelle identité palette
10. [CUSTOM] L'opérateur scanne la palette recertifiée au PK → le WMS
propose de choisir la table (prompt position PK). La palette passe
de ASN au bon emplacement PK. La **palette vide est supprimée**
automatiquement.
11. L'opérateur appuie sur « Ranger support » → AGV vient la chercher →
passage au PIE de réception (standard)
> ⚠️ **Risque** : si l'ASN n'est pas encore arrivé au moment du scan →
> erreur, réessayer plus tard.
> ⚠️ **3 mini-customs identifiés** : event de stockage CstAtt + event
> de fermeture/création palette vide + suppression palette vide au scan ASN.
### Messagerie carton
**Solution recommandée** : **Pick and Pack** (module transporteur). Plus
simple, pas de colisage séparé, impression étiquette directe. **Nécessite
le module transporteur.** Plan B : fusion des lignes comme alternative.
**Sans module transporteur** : custom le picking PK avec un mode
« messagerie carton » :
1. Commandes descendues dans un RUT de type « Messagerie carton » (classe
d'expédition)
2. Tous les OS préparés en simultané sur un seul poste de travail
3. Tri par transporteur (l'opérateur ne peut déposer que sur une seule
palette). Via modèle d'expédition à créer avec le client.
4. Impression étiquette colis à la première tâche de picking
(SOR.Code, SOR.Account, SOR.Delivery, SSCC colis 128)
5. Consolidation sur palette unique
6. Prélèvement dans un carton (support identifié) puis sur palette
7. Indicateur à l'opérateur quand un carton ne recevra plus de stock →
fermer le carton
8. Bouton « Palette pleine » sur la WS :
- Impression SSCC
- Collage par l'opérateur
- Prompt du code
- Remontage des supports « colis » sur la palette
9. Fermeture auto aussi possible si palette n'attend plus de stock
10. AGV récupère la palette vers le quai
**Assignation poumon** : [CUSTOM] à l'import du SOR, vérification combo
shipping class code + transporteur → si OK, poumon associé automatiquement.
L'idée retenue est de **ne pas** utiliser d'image de quai classique (sinon
perte de 25 places) mais un **emplacement au sol par transporteur**
(ex: emplacement « Colissimo », « Chronopost »).
> ⚠️ Custom à prévoir pour que la fermeture fonctionne dans le cas d'un
> support non client possédant des supports clients.
### Consommation OF hors recertification
**Prérequis** :
- `AllowAssignStockExcess` à `true` dans la SOR.Line
- Modèle d'expédition avec une stratégie d'assignation de stock
- [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
(= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
sans picking.
- Stock assigné directement déposé sur l'image de quai
- Pas de passage par un poste de travail
Pour les SOR de classe Production, les ruptures de stock ne bloquent pas
l'expédition. Le client utilise `isCritical` / `isRequired` au niveau
SOR.Line si besoin.
### Gestion des litiges (sac endommagé)
1. La palette arrive au PK
2. Problème constaté par l'opérateur sur un stock à picker :
- Bouton « Problème » → « Modif quantité »
- S'il reste du stock dispo : assignation maintenue (workflow
`OnStockAdjust` recalcule uniquement si nécessaire)
- Si plus assez de stock → réassignation ailleurs
3. Autre problème — le support n'est pas ok (90% du stock a un problème) :
- **Verrou de support** interdisant le picking (bouton « mettre sous
révision » en standard, à configurer)
- Tâche créée pour que l'AGV dépose la palette sur un **emplacement
au sol buffer litige** (à valider avec le client)
4. Retour au flux classique
## Modes opératoires
Tous les process doivent être pensés en **3 modes** :
| Mode | Description |
|------|-------------|
| Full AGV | Fonctionnement nominal |
| Mixte | AGV + caristes (cas probable en montée en charge) |
| Full TRF (caristes) | Mode dégradé sans AGV |
Le module AGV standard permet la finalisation manuelle (simulation AGV).
4 TRF disponibles sur site. Réunion dédiée à planifier pour les modes
dégradés.
## Points d'attention
⚠️ L'ordonnancement des palettes sur le poumon respecte le n° STOP.
⚠️ Le custom de défragmentation est le développement clé : il attend que
toutes les palettes de picking soient terminées avant de lancer les relocs.
⚠️ La clôture est automatique pour les OS complets mais **manuelle** en
cas d'expédition partielle.
⚠️ Le message MOV est **annulé** (décision réunion client).
⚠️ Les 3 modes opératoires (Full AGV / Mixte / Full TRF) doivent être
documentés pour chaque process.
## Questions ouvertes
- [ ] Ordonnancement des palettes dans le canal du poumon d'expé du
magasin automatique — géré par le WMS ou naturellement via l'ordre
de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ?
(@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
— à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie en parallèle sur un poste ? (@Justine)
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
- [ ] Réunion technique avec Still pour valider le problème de dépose
AGV sur image de quai (@Théo)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Réécriture complète depuis ateliers DEV expédition |
| 2026-05-13 | Arthur | Correction seuil picking négatif 50% → 55% + poids ≥ 7 kg, suppression règle traitement commercial |
wiki/limagrain/04-outbound/sequencage-shipping-stop.md
+220
View File
@@ -0,0 +1,220 @@
---
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 | — |
wiki/limagrain/04-outbound/shipping-orders.md
+244
View File
@@ -0,0 +1,244 @@
---
title: "Ordres de sortie — Types et libération"
tags: [outbound, OS, SOR, RUT, libération, assignation, FIFO, LOC]
status: draft
standard_ref: concepts/order-outbound.md
jira_refs: []
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Ordres de sortie — Types et libération
> **Résumé** : 4 types d'ordres de sortie chez Limagrain, avec des
> comportements de libération, d'assignation et de préparation distincts.
> **Standard EasyWMS** : → voir [Order Outbound](../../concepts/order-outbound.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
L'expédition chez Limagrain couvre des flux variés : commandes clients
(palettes et messagerie), approvisionnement production (OF), et
re-certification. Le message d'entrée diffère selon le type.
## Types d'ordres de sortie
| Type | Message ERP | Passage poste travail | Destination |
|------|-------------|----------------------|-------------|
| Commande client | RUT « Client » | Si picking nécessaire | Image de quai |
| Messagerie palette | RUT « Client » | Si picking nécessaire | Image de quai |
| Conso OF hors recertification | SOR « Production » | Non | Image de quai direct |
| Conso OF avec recertification | SOR « Recertification » | Oui | Route virtuelle → réception ASN |
| Messagerie carton | RUT « Messagerie » | Oui | Emplacement au sol dédié |
## Classification (OutboundClassCode)
| OutboundClassCode | Usage | AccountCode |
|-------------------|-------|-------------|
| PRODUCTION | Flux vers l'ancien magasin / M2I | PRODUCTION |
| RECERTIFICATION | Flux vers postes de travail SRS | PRODUCTION |
| CLIENT | Commandes clients | CLIENT |
## Structure RUT / SOR
- **RUT** = image camion, peut contenir **plusieurs OS** (même camion).
Un seul message contenant : Route → SorList → Lignes (pas de fichiers
RUT + SOR séparés)
- **SOR** = commande de sortie de marchandise (1 ou plusieurs palettes)
- Chaque OS peut avoir plusieurs **lignes** (article + quantité)
- Chaque palette est étiquetée et ordonnancée par **n° STOP**
## Paramètres ERP des SOR/RUT
| Paramètre | Valeur | Commentaire |
|-----------|--------|-------------|
| OutboundType | 0 (Customer) | Même pour production |
| Priorité par défaut | 3 (Basse) | Échelle : 0=Urgente → 4=Très basse |
| AutoReleaseDate | PlannedShippingDate - 48h | Si < 48h → date passée = libération immédiate |
| TransactionalLineList | true | Tout ou rien (refus total si erreur) |
| CompleteSorList (RUT) | true | SOR absents de la RUT = supprimés |
| AllowAssignStockExcess | true | Palettes pleines, jamais de picking partiel |
| Limite d'annulation | Statut "Chargé" | Avant = OK, après = refusé |
| IgnoreNulls (RUT) | false | — |
## Gestion des ruptures SOR Production
SAP ne connaît pas la répartition stock entre ASRS et autres entrepôts.
Beaucoup de lignes seront en rupture (affichage rouge = **normal et attendu**).
Le WMS prépare ce qu'il peut, SAP supprime le résiduel 3-4 jours plus tard
via un DELETE complet du SOR.
Pas de SOF en phase 1 pour la production. Détection des manquants = mode
manuel.
## Quai recertification
Pour les SOR de type recertification :
`AssignedDockStationCode = "QUAI_RECERTIFICATION"` (quai fictif, renseigné
par Limagrain dans le SOR).
## Libération
### Libération automatique (mode principal)
La date/heure de libération est descendue dans l'interface SOR ou RUT.
EasyWMS vérifie périodiquement et libère quand la date est atteinte.
Séquence :
1. Vérification date → date atteinte
2. Statut → « Libéré »
3. Assignation stock par ligne
4. Génération tâches expédition/prélèvement
5. Statut → « En préparation » ou « En rupture de stock »
### Libération manuelle
Depuis l'écran « Ordres de sortie » → sélection → « Libérer ». Possible
uniquement si statut « En attente », « En préparation » ou « En rupture ».
### Priorité
- Priorité définie à la création (dans le SOR/RUT)
- Modifiable dans EasyWMS avant libération (si libération manuelle)
- Par défaut : ordre de réception (FIFO de création)
## Assignation de stock
### Sélection du stock valide
Filtres appliqués :
1. Article (lot SAP) + attributs logistiques (article Limagrain, propriétaire
Limagrain, statut de stock) correspondent à la ligne demandée
2. Stock **et** conteneur sans verrou empêchant l'expédition
3. Stock pas dans une allée bloquée
4. Emplacement sans erreur d'extraction/dépose
5. Stock non déjà assigné à un autre OS
6. Stock sans tâche d'un autre processus
### Stratégie d'assignation
Dans l'ordre de priorité :
1. **Article/lot SAP + attributs logistiques** spécifiés dans le SOR/RUT
2. **Économie de mouvement** (minimum de mouvements) — **prioritaire**
3. **FIFO sur 24h** : standard confirmé. Les palettes reçues le même jour
ont le même FIFO (heures/minutes ignorées), ce qui permet de prendre
la palette la plus accessible dans un canal. Pas de FIFO strict
infra-journalier.
4. **Pas de FEFO** — la proposition initiale de faire du FEFO sur du stock
sans DLC est **abandonnée**. Il n'y a pas de date d'expiration sur les
produits. Le FIFO journalier est retenu.
5. **Maximum palettes complètes** puis palettes incomplètes (avec picking)
> ⚠️ **Attention unités** : certains semi-finis calibrés (ZSIZ) sont gérés
> en kilos, d'autres en big bags. Vérifier que la quantité complète est
> cohérente avec l'unité de réception. À valider avec le client.
## Comportement post-assignation par type
### Commande client / Messagerie palette
- Palettes complètes / picking terminées → [CUSTOM] tâche de
**défragmentation** vers zone de stockage d'expédition dans l'ASRS.
Ne se déclenche que si **toutes** les palettes clientes sont « terminées »
(palettes de picking retournées dans l'ASRS) ET qu'aucun quai n'est
associé à l'OS.
- Palettes picking → **pas de tâche** tant qu'un poste de travail n'est
pas assigné
- Voir [Zones stockage](../02-stockage/zones-stockage.md)
> **Explication du CUSTOM défrag** : en standard, le mode « Expédition
> uniquement » ne reloc pas les palettes de picking (ordonnancement STOP
> faux). Le mode « Picking et expédition » reloc toutes les palettes y
> compris celles à picker, ce qui casse l'ordonnancement quand on les
> ressort. Le custom attend que toutes les palettes de picking soient
> pickées et rangées dans l'ASRS avant de lancer les relocs par STOP.
> **Note** : si un quai est déjà assigné et l'OS libéré, le WMS peut
> sortir les palettes dans le bon ordre des STOP sans défragmentation
> préalable, via de la reloc standard.
### Consommation OF hors recertification
- `AllowAssignStockExcess` à `true` dans la SOR.Line
- [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
(= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
sans picking.
- Stock assigné directement déposé sur l'image de quai — aucun passage
poste de travail
- Ruptures de stock ne bloquent pas l'expédition. Le client utilise
`isCritical` / `isRequired` au niveau SOR.Line si besoin.
- Voir [Flux spécifiques expédition](flux-expedition.md#consommation-of-hors-recertification)
### Consommation OF avec recertification
- Stock assigné mais **aucune tâche** tant que poste de travail non assigné
- Le PK doit être passé en **mode recertif** (par le manager)
- Flux détaillé en 11 étapes — voir
[Re-certification](flux-expedition.md#re-certification)
### Messagerie carton
- Stock assigné mais aucune tâche tant que poste non assigné
- Tous les OS de la RUT préparés **simultanément** sur un seul poste
- Tri par transporteur (l'opérateur ne dépose que sur une seule palette)
- Consolidation sur palette unique avec supports carton identifiés
- Pas d'image de quai — emplacement au sol dédié par transporteur
- [CUSTOM] À l'import du SOR, vérification combo shipping class code +
transporteur → si OK, poumon associé automatiquement
- Voir [Messagerie carton](flux-expedition.md#messagerie-carton)
## Gestion des reliquats
Si stock insuffisant pour une ligne :
- Ligne → statut « rupture de stock » (affichage rouge)
- Reste de la commande peut être expédié (expédition partielle)
- Clôture manuelle de la commande obligatoire
- Si stock redevient disponible avant clôture → peut être préparé
## Création manuelle d'OS
Possible depuis EasyWMS avec choix de destination :
- Table de préparation sur un poste de travail
- Image de quai
## Points d'attention
⚠️ La libération automatique est le mode principal — la date est dans le
message ERP.
⚠️ L'assignation spécifie **toujours** les 4 critères (article, lot SAP,
propriétaire, statut) — pas d'assignation « ouverte ».
⚠️ Le FIFO est à la **journée** (palettes du même jour = même rang FIFO),
avec l'**économie de mouvement** prioritaire sur le FIFO. Pas de FEFO.
⚠️ Les palettes d'expédition sont stockées dans la zone défrag avec si
possible **un canal dédié par route/STOP**.
⚠️ Le custom de défragmentation attend que toutes les palettes de picking
soient terminées et retournées dans l'ASRS avant de lancer les relocs —
c'est le développement clé du flux outbound.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | Enrichissement : 5 types OS, FIFO 24h, pas de FEFO, custom défrag, conso OF détaillé, messagerie carton |
| 2026-05-06 | Arthur | Ajout classifications, paramètres ERP, ruptures production, quai recertif (CR consolidé) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Expédition - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/05-agv/.fuse_hidden0000004b0000001e
+158
View File
@@ -0,0 +1,158 @@
---
title: "Mini Job — Images de quai vers poste de travail (PK)"
tags: [agv, job, réception, pk, mini-job, big-bag]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-74, LIM-70, LIM-60]
confluence_refs: []
sources: ["LIM-74 LOT1.3 [AGV][JOB] MINI JOB - images de quai poste de travail (PK).md"]
last_updated: 2026-05-12
author: Arthur
---
# Mini Job — Images de quai vers poste de travail (PK)
> **Résumé** : sous-workflow du [Mega Job](../03-picking/job-assignation-pk.md)
> qui orchestre l'envoi des palettes depuis les images de quai vers les
> postes de travail (PK) pour les réceptions fournisseur, intersite et
> retour client.
> **Standard EasyWMS** : → voir
> [Galileo Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Dans le flux de réception fournisseur/intersite/retour client, les
palettes sont déchargées par un cariste sur une image de quai puis
déclarées via le TRF
([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)). Ce job
périodique est le mécanisme qui assigne les réceptions aux PK et crée les
tâches de déplacement.
Ce job fait partie du
[Mega Job (LIM-70)](../03-picking/job-assignation-pk.md) qui en est
l'entête. L'éligibilité du PK (4 conditions) est vérifiée dans l'entête,
pas dans ce sous-workflow.
> Ce job ne concerne **pas** les réceptions de type Production. Celles-ci
> sont envoyées directement vers le PIE de l'ASRS via des supports
> virtuels — voir
> [Job réception production](job-reception-production.md) (LIM-71).
### Process complet de réception
| # | Étape | Ticket |
|---|-------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | **Déplacement AGV → poste de travail** | **LIM-74 (cette page)** |
| 3 | Traitement au poste de travail | [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) |
| 8 | Libération quai / image de quai | — |
## Logique principale
```
POUR CHAQUE PK éligible (vérifié par l'entête LIM-70)
├─ 1. RECHERCHE D'UNE RÉCEPTION À ASSIGNER
│ ├─ Filtrer les réceptions ayant des supports fictifs (séquence 8000*)
│ │ sur une image de quai dont CstAtt06 est vide (pas de PK assigné)
│ ├─ Filtre big-bag : si CstAtt01 du support = true (big-bag)
│ │ → le PK doit figurer dans le paramètre PK_BIGBAG
│ ├─ Trier : ordres big-bag prioritaires (si PK l'autorise), puis FIFO
│ │ sur la date de création de la réception
│ └─ Prendre la PREMIÈRE réception éligible
│
├─ 2. ASSIGNATION DU PK
│ └─ Set CstAtt06 = code du PK sur TOUS les supports de cette réception
│
└─ 3. CRÉATION DES TÂCHES
├─ Pour CHAQUE support fictif de la réception :
│ créer 1 tâche : sous-emplacement image de quai → PK (station)
├─ Statut initial : "en attente"
└─ Toutes les palettes d'une réception → même PK, en une seule passe
```
## Détails des étapes
### 1. Recherche d'une réception
Le job cherche parmi toutes les réceptions non-production celles qui ont
des supports fictifs (séquence 8000*) positionnés sur une image de quai,
dont **CstAtt06 est vide** (pas encore assignés à un PK). Les supports
de production n'ont pas de réception associée et sont donc naturellement
exclus.
**Filtre big-bag** : si les supports de la réception ont `CstAtt01 =
true` (big-bag déclaré lors de la déclaration image de quai), le PK doit
figurer dans le paramètre `PK_BIGBAG`. Si aucun PK compatible n'est
libre, la réception attend.
**Ordre de priorité** : ordres contenant des big-bags d'abord (si le
poste l'autorise), puis FIFO sur la date de création de la réception.
### 2. Assignation du PK
Une fois la réception trouvée, le **CstAtt06** de **tous les supports
fictifs** de cette réception est mis à jour avec le code du PK assigné.
Ce CstAtt sert également à identifier le poste d'origine en cas de
notification de rejet au PIE.
### 3. Création des tâches
Pour chaque support fictif de la réception sur l'image de quai :
- **Origine** : sous-emplacement de l'image de quai
- **Destination** : PK (station). Le sous-emplacement (TP) de
destination est choisi automatiquement par le WMS au moment de la
génération du mouvement
([LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60))
- **Statut** : "en attente"
Le WMS gère ensuite le passage "en attente" → "généré" via le standard
`Task_GenerateMovementJob_PR`, selon la capacité en temps réel du PK. Le
module AGV/GNA envoie les tâches à la flotte iGo.
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| PK_BIGBAG | Liste des PK compatibles big-bag (séparés par `;`) | _(vide)_ |
## Points d'attention
⚠️ Un PK compatible big-bag (`PK_BIGBAG`) peut aussi traiter des
réceptions sans big-bag — le filtre ne s'applique que dans le sens
"big-bag vers PK non compatible".
⚠️ Toutes les palettes d'une même réception vont vers le **même PK** en
une seule passe. Pas de répartition entre PK.
⚠️ Le CstAtt06 empêche le re-traitement d'une réception déjà assignée
lors d'exécutions successives du job.
⚠️ Le nombre de tâches créées peut dépasser le nombre de TP du PK
(ex : 10 tâches pour 3 TP). Le WMS gère le flux "en attente" → "créé"
selon la capacité temps réel.
## Questions ouvertes
_(aucune question ouverte identifiée dans cette tâche)_
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-74 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira | 2026 |
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
| [LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60) | Ticket Jira (sous-emplacement auto) | 2026 |
wiki/limagrain/05-agv/.fuse_hidden0000004d0000001f
+160
View File
@@ -0,0 +1,160 @@
---
title: "Job AGV — Réception production vers ASRS"
tags: [agv, job, reception, production, asrs, pie]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-71, LIM-64, LIM-66]
confluence_refs: []
sources: ["LIM-71 LOT1.2 RECEPTION PRODUCTION AGV Job de création des tâches images de quai ASRS.md"]
last_updated: 2026-05-12
author: Arthur
---
# Job AGV — Réception production vers ASRS
> **Résumé** : job périodique (30 s) qui crée les tâches de déplacement
> AGV depuis les images de quai vers le buffer d'entrée production
> (alimentant le PIE de l'ASRS). Concerne uniquement les réceptions
> production (CstAtt04 = "ASN").
> **Standard EasyWMS** : → voir
> [Galileo Integration](../../architecture/galileo-integration.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Dans le flux de réception production, les palettes arrivent de la
production (ou de l'ancien magasin) et vont **directement dans l'ASRS**
sans passer par un poste de travail. Elles sont déchargées par un
cariste sur une image de quai puis déclarées via le TRF en type
"Production"
([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)).
Ce job crée les tâches de déplacement AGV depuis les images de quai
vers le buffer d'entrée production, qui a une route virtuelle vers une
table d'entrée du convoyeur.
> **Périmètre** : uniquement les réceptions de type Production (supports
> avec CstAtt04 = "ASN"). Les réceptions fournisseur / intersite /
> retour client sont gérées par le
> [Mega Job d'assignation PK](../03-picking/job-assignation-pk.md)
> ([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)).
## Process complet de réception production
```mermaid
sequenceDiagram
participant Cariste
participant TRF as TRF (LIM-64)
participant Job as Job AGV (LIM-71)
participant AGV
participant PIE as PIE (LIM-66)
participant ASRS
Cariste->>TRF: Décharge palette sur image de quai
TRF->>TRF: Déclaration type "Production"
Note over TRF: Support fictif séq. 8000*<br/>CstAtt04 = "ASN"
Job->>Job: Détecte support éligible
Job->>Job: Crée tâche "En attente"
Note over Job: Origine = image de quai<br/>Dest = stratégie rangement
Job-->>AGV: Tâche passe "Créé" → GNA → iGo
AGV->>PIE: Transport vers entrée production
PIE->>PIE: Suppression support virtuel<br/>Création palette ASN
PIE->>ASRS: Stockage ou rejet
```
## Configuration du job
- **Type** : job périodique
- **Fréquence** : toutes les **30 secondes**
## Logique d'éligibilité
Le job parcourt tous les supports positionnés sur des images de quai.
Un support est éligible si **toutes** les conditions suivantes sont
réunies :
| Condition | Détail |
|-----------|--------|
| Séquence 8000* | Support fictif créé lors de la déclaration image de quai ([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)) |
| CstAtt04 = "ASN" | Support de type production |
| CstAtt06 vide | Pas encore traité par ce job |
| Aucune tâche active | Statuts actifs = Bloqué, Créé, En attente, En attente d'annulation, En cours. Statuts historiques (ignorés) = Annulé, Terminé |
La double vérification CstAtt06 + absence de tâche active est une
**sécurité anti-doublon**.
## Traitement d'un support éligible
### Marquage
Le job positionne `CstAtt06` = valeur du paramètre
`DESTINATION_PRODUCTION` (ex : "ENTREE_PRODUCTION").
### Création de la tâche
| Champ | Valeur |
|-------|--------|
| Origine | Sous-emplacement de l'image de quai |
| Destination | Déterminée par la **stratégie de rangement** configurée (MU d'entrée Est ou Ouest, Est par défaut) |
| Statut initial | "En attente" |
Le passage "en attente" → "créé" est géré par le WMS standard
(`Task_GenerateMovementJob_PR`). Le module AGV / GNA écoute ce
changement et envoie les tâches à la flotte iGo.
## Redirection si PIE saturé
Gérée en **standard** par le système de routes et distances configuré
dans EasyS :
- Route principale : distance 1
- Routes secondaires : distance 2
On ferme le PIE de production → le WMS redirige automatiquement vers
les autres entrées disponibles. Ce job envoie toujours vers la même
destination ; c'est le WMS qui reroute si nécessaire.
> ⚠️ À vérifier si faisable avec plusieurs poumons, plusieurs PIE et
> si la config EasyS actuelle est prête pour ce mode dégradé.
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| DESTINATION_PRODUCTION | Code du buffer d'entrée production (destination des tâches AGV) | ENTREE_PRODUCTION |
## Points d'attention
- Un support non ASN (fournisseur, intersite, retour) sur une image
de quai est **ignoré** — il est géré par le
[Mega Job](../03-picking/job-assignation-pk.md) (LIM-70)
- Le marquage CstAtt06 a été simplifié en cours de développement
(certains cas de tests marqués "Plus utilisé") — la vérification
par absence de tâche active reste la sécurité principale
- La stratégie de rangement détermine l'entrée Est/Ouest ; le
paramètre DESTINATION_PRODUCTION n'est plus directement utilisé
comme destination de tâche
## Questions ouvertes
- [ ] Redirection multi-poumons / multi-PIE : config EasyS prête ?
(@Nicolas)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification
par tâche active suffit ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-71 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-71](https://easywmsfrance.atlassian.net/browse/LIM-71) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira (déclaration image quai) | 2026 |
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (passage PIE) | 2026 |
wiki/limagrain/05-agv/.fuse_hidden0000004f00000020
+25
View File
@@ -0,0 +1,25 @@
---
title: "AGV — Vue d'ensemble"
tags: [agv, still, igo, index]
status: draft
last_updated: 2026-05-12
---
# AGV — Vue d'ensemble
> **Périmètre** : intégration Still iGo, stations et routes AGV,
> jobs AGV spécifiques, troubleshooting.
> **Standard EasyWMS** : voir [AGV Integration](../../architecture/agv-integration.md)
## Pages de cette section
- [Intégration Still iGo](still-igo-integration.md)
- [Stations et routes AGV](agv-stations-routes.md)
- [Job réception production → ASRS](job-reception-production.md)
- [Job réception fournisseur/retour → PK](job-reception-pk.md)
- [Troubleshooting AGV](agv-troubleshooting.md)
## Vue synthétique des flux AGV Limagrain
<!-- Diagramme Mermaid — à compléter -->
wiki/limagrain/05-agv/_index.md
+59
View File
@@ -0,0 +1,59 @@
---
title: "AGV — Vue d'ensemble"
tags: [agv, still, igo, index]
status: draft
last_updated: 2026-05-12
---
# AGV — Vue d'ensemble
> **Périmètre** : intégration Still iGo, stations et routes AGV,
> jobs AGV spécifiques, troubleshooting.
> **Standard EasyWMS** : voir [AGV Integration](../../modules/agv.md)
## Pages de cette section
- [Intégration Still iGo](still-igo-integration.md)
- [Stations et routes AGV](agv-stations-routes.md)
- [Job réception production → ASRS](job-reception-production.md)
- [Job réception fournisseur/retour → PK](job-reception-pk.md)
- [Troubleshooting AGV](agv-troubleshooting.md)
## Vue synthétique des flux AGV Limagrain
```mermaid
flowchart LR
subgraph Inbound["Réception"]
IQ[Images de quai]
end
subgraph AGV["Flotte AGV Still EXV CB iGo"]
direction TB
iGO["iGO easy<br/>API REST port 7002"]
end
subgraph Auto["ASRS"]
PIE[PIE pesée]
TK[Transstockeurs]
end
subgraph Picking["Picking"]
PK[Postes PK 1-6]
end
subgraph Outbound["Expédition"]
QUAI[Quais chargement]
end
IQ -->|"Job LIM-71<br/>production → ASRS"| PIE
IQ -->|"Mini Job LIM-74<br/>fournisseur/retour → PK"| PK
TK -->|"Picking<br/>TK → PS → PK"| PK
PK -->|"Palettes filles<br/>→ quai/ASRS"| QUAI
PK -->|"Retour PF"| TK
```
> **Communication** : EasyWMS ↔ iGO via **API REST HTTPS** (port 7002,
> TLS 1.2, X-API-Key). Le middleware pool IIS C# traduit les tables
> AGV_* vers/depuis l'API PACS.
> → voir [Intégration Still iGo](still-igo-integration.md)
wiki/limagrain/05-agv/agv-stations-routes.md
+127
View File
@@ -0,0 +1,127 @@
---
title: "Stations et routes AGV — Topologie iGO"
tags: [agv, still, igo, stations, routes, topologie, location, group]
status: draft
standard_ref: concepts/stations.md
jira_refs: []
confluence_refs: []
sources: ["CR technique - iGO STILL - fonctionnement et flux API + correspondance avec le module AGV EasyWMS Opus 4.7 v1.md"]
last_updated: 2026-05-12
author: Arthur
---
# Stations et routes AGV — Topologie iGO
> **Résumé** : correspondance entre les stations/routes EasyWMS et les
> concepts Location/Group/Vehicle d'iGO. Configuration dans MyMA vs
> EasyS, différences de gestion des routes, et mapping topologique.
> **Standard EasyWMS** : → voir [Stations & Routes](../../concepts/stations.md)
> Ce qui suit documente les **spécificités Limagrain** liées à
> l'utilisation d'iGO easy comme fleet manager AGV.
## Contexte projet
Chez Limagrain, les AGV Still (EXV CB iGo) circulent entre les images
de quai, les PIE, les postes de picking (PK) et les zones de stockage.
La topologie physique (positions, trajets) est gérée **entièrement
dans iGO** (MyMA / iGO designer) — EasyWMS ne connaît que les points
de départ et d'arrivée.
## Mapping topologique EasyWMS ↔ iGO
| Concept EasyWMS | Concept iGO | Notes |
|----------------|-------------|-------|
| Station (type 65 — AGV) | **Vehicle** | Le véhicule physique lui-même |
| Location (`IRealLocation`) | **Location** | Point physique avec `possibleActions` |
| Route entre stations | _(pas d'équivalent)_ | iGO gère le routage en interne |
| WorkingZone | **Group** | Ensemble de Locations (décision tardive) |
| AGV equipment group (EasyS) | Flotte dans MyMA | Configuration véhicules |
| `Allow loading` / `Allow unloading` | `Location.isEnabled` + `possibleActions` | Flag binaire côté iGO |
| `LocationLockType` "For AGV" | `Location.isEnabled = false` | iGO n'a pas de typage de lock |
| Manual loading aisle | _(pas d'équivalent)_ | iGO calcule la trajectoire seul |
| Route distance | _(pas d'équivalent)_ | iGO optimise le chemin en interne |
## Configuration côté iGO (MyMA)
Les éléments suivants sont configurés dans MyMA, **pas dans EasyS** :
- **Vehicles** : enregistrement des AGV physiques (id, modèle, capacité)
- **Locations** : déclaration de chaque point physique avec actions
autorisées, types de véhicules et de charges admis, et
`actualLoads` courantes
- **Groups** : regroupement de Locations pour la décision tardive (cas
typique : zone de déchargement avec plusieurs alvéoles)
- **Layout / routes** : géré dans le designer iGO, invisible côté WMS
## Configuration côté EasyS (EasyWMS)
Restent dans EasyS :
- Création du warehouse station lié à l'AGV equipment group
- Déclaration des AGV dans le groupe
- Routes EasyWMS **entre stations WMS** (type "External" pour les
segments AGV — le manager d'exécution est "External")
> ⚠️ Pas d'équivalent aux "Routes between stations" de type Galileo
> pour iGO. Les routes EasyS servent uniquement à valider l'existence
> d'un chemin logique côté WMS avant de créer la tâche AGV — la
> trajectoire physique est résolue par iGO.
## Décision tardive — utilisation des Groups
Cas d'utilisation chez Limagrain :
- **Déchargement vers un quai** : le WMS crée le transport avec
`destinationGroupId = "DOCK_OUT"`. iGO achemine l'AGV au point de
décision du groupe. Le WMS choisit alors l'alvéole exacte via
`POST /transports/{id}/final-destination`.
- **Reproduction du CanPick/CanDrop** : pour forcer iGO à demander
une autorisation avant chargement/déchargement, il faut configurer
un Group même pour une seule Location. Le status `RequestSource` /
`RequestDestination` sert alors de signal d'autorisation.
## Gestion des verrous
| EasyWMS | iGO |
|---------|-----|
| `LocationLockType` avec flag "For AGV" | `Location.isEnabled = false` |
| Lock typé (par erreur extraction, putaway, etc.) | Un seul flag binaire côté iGO |
| Lock posé automatiquement par les workflows | À gérer côté WMS uniquement — iGO ne pose pas de lock |
> ⚠️ iGO n'a pas de granularité dans les types de verrous. La
> traduction entre les codes erreur EasyWMS (1001-2700) et le flag
> `isEnabled` est à la charge du middleware.
## Points d'attention
⚠️ **Pas de routage exposé** : si un AGV ne peut pas atteindre une
location (obstacle, zone interdite), iGO gère le contournement en
interne. Pas d'erreur "Disabled route" renvoyée au WMS.
⚠️ **Pas de notion d'allée** (`LoadAisle` / `UnloadAisle`) côté iGO :
ces champs EasyWMS (obligatoires en FIFO compact) sont portés par la
Location côté iGO, pas par le transport.
⚠️ **Modification des Locations via API** : l'API iGO n'expose que
`GET /api/locations` — pas de `POST`/`PUT`. Toute modification de
topologie passe par MyMA manuellement.
## Questions ouvertes
- [ ] Création/modification de Location via API iGO — actuellement
en lecture seule, à clarifier avec STILL (@Arthur)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-12 | Arthur | Création initiale |
## Références
| Source | Type | Date |
|--------|------|------|
| CR technique iGO STILL v1 | CR technique | 2026-04-28 |
| [Stations & Routes standard](../../concepts/stations.md) | Wiki standard | — |
| [AGV module standard](../../modules/agv.md) | Wiki standard | — |
wiki/limagrain/05-agv/agv-troubleshooting.md
+144
View File
@@ -0,0 +1,144 @@
---
title: "Troubleshooting AGV — Contraintes terrain"
tags: [agv, still, igo, terrain, convoyeurs, troubleshooting]
status: draft
standard_ref: operations/troubleshooting.md
jira_refs: []
confluence_refs: []
sources: ["reu_still_sur_site.pdf"]
last_updated: 2026-05-13
author: Arthur
---
# Troubleshooting AGV - Contraintes terrain
> **Résumé** : problèmes physiques identifiés lors de la visite terrain
> Still/Mecalux du 29/05/2026 sur l'installation convoyeurs. Contraintes
> de positionnement AGV, non-conformités défenses, et actions correctives.
> **Standard EasyWMS** : -> voir [Troubleshooting](../../operations/troubleshooting.md)
> Ce qui suit documente les **problèmes terrain spécifiques Limagrain**
> liés à l'intégration physique des AGV Still EXV CB iGo.
## Contexte projet
Lors de la visite commune Still/Mecalux du 29/05/2026, réalisée à la
demande de Mecalux, plusieurs problèmes physiques ont été identifiés sur
l'installation convoyeurs. Étaient présents : Cyprien Allard (Still),
Sébastien Varenne, Abdennaim Autoghza et Théo Le Paih (Mecalux).
Le CR a été transmis par Théo à Limagrain (Thierry Channeboux,
Jean-Baptiste Rouvet) et en copie à Cérès Solutions, Harington et
Mecalux le 06/05/2026.
## Paramètres physiques AGV
Les caractéristiques AGV suivantes conditionnent toutes les contraintes
identifiées :
| Paramètre | Valeur | Notes |
|-----------|--------|-------|
| Tolérance de positionnement AGV | +/- 20 mm | Centrage théorique, pas par rapport à la palette |
| Limite de déport mât/dosseret | ~75 mm | Distance max entre dosseret de fourche et mât |
| Espace max palette/convoyeur | ~45 mm | Calcul : 75 - 20 - 10 (jeu fonctionnel), à confirmer par Still |
| Capteur présence | Electro-mécanique | Monté sur le dosseret de fourche |
> **Point clé** : l'AGV ne recentre pas par rapport à la palette, il se
> positionne en théorique. Un avaloir à palette est donc **nécessaire**
> sur tous les postes d'entrée pour assurer un centrage palette/convoyeur
> suffisant.
## Problèmes identifiés
### P1 - Zone Ouest : défenses non conformes
Les défenses qui possèdent les avaloirs ont une **barre de renfort
avant de 55 mm d'épaisseur**, ce qui dépasse l'espace max disponible
de ~45 mm.
- **Cause** : épaisseur de la barre de renfort (55 mm) incompatible avec
la tolérance de positionnement AGV
- **Impact** : risque de collision AGV/défense lors de la prise/dépose
- **Action** : Mecalux doit identifier une adaptation des défenses
### P2 - Zone Est : prise/dépose latérale impossible
La prise/dépose latérale prévue côté Est est **impossible en l'état** :
déport d'environ 200 mm (environ 120 mm sans la défense).
- **Cause** : distance mât/bord palette insuffisante pour le déport
latéral requis
- **Impact** : la prise/dépose latérale Est ne peut pas fonctionner
- **Action** : Still doit identifier un moyen d'augmenter la distance
entre mât et bord palette
### P3 - SAS7 : bord de dalle potentiellement trop éloigné
Le bord de la dalle semble trop éloigné du bord de palette (~95 mm)
sur le SAS7. Mesure réelle à confirmer.
- **Cause** : écart de ~95 mm entre bord dalle et bord palette
(supérieur au max ~45 mm)
- **Impact** : potentiel - même problème que Zone Est si confirmé
- **Action** : Mecalux doit confirmer la mesure réelle lors de
l'implantation des éléments (@Abdennaim Autoghza)
### P4 - Poste de rejet Ouest : manoeuvre AGV impossible
Prise par AGV impossible sur le poste de rejet Ouest : pas d'espace
nécessaire pour manoeuvrer.
- **Cause** : espace physique insuffisant autour du poste de rejet
- **Impact** : l'AGV ne peut pas accéder au poste de rejet Ouest
- **Action** : résolution potentielle si Still augmente la distance
mât/bord palette (lié à P2)
## Synthèse des actions
| # | Responsable | Action | Statut |
|---|------------|--------|--------|
| A1 | Mecalux | Adapter les défenses Zone Ouest (barre renfort 55 mm) | En cours |
| A2 | Still | Augmenter distance mât/bord palette (résout P2, P4 et potentiellement P3) | En cours |
| A3 | Mecalux (@Abdennaim) | Confirmer mesure réelle SAS7 lors de l'implantation | En attente |
> ⚠️ L'action A2 de Still est **critique** : si elle aboutit, elle
> pourrait résoudre tout ou partie des problèmes P2, P3 et P4. Le
> résultat conditionne la faisabilité de la topologie AGV prévue.
## Points d'attention
- ⚠️ L'ensemble de ces contraintes impacte la configuration topologique
iGO (Locations, possibleActions) documentée dans
[Stations et routes AGV](agv-stations-routes.md). Toute modification
physique des postes peut nécessiter une reconfiguration dans MyMA.
- ⚠️ Les tolérances AGV (+/- 20 mm) sont à prendre en compte pour
**tous** les postes de prise/dépose, pas uniquement ceux identifiés
dans ce CR.
- ⚠️ Le problème d'avaloir concerne potentiellement tous les postes
d'entrée du site (pas seulement Zone Ouest).
## Questions ouvertes
- [ ] Confirmation par Still de l'espace max palette/convoyeur ~45 mm
(@Théo)
- [ ] Mesure réelle SAS7 à effectuer lors de l'implantation
(@Abdennaim)
- [ ] Solution Still pour augmenter la distance mât/bord palette :
quel impact sur les specs AGV (capacité, hauteur de levée) ?
(@Cyprien Allard / Still)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-13 | Arthur | Création initiale depuis CR visite terrain 29/05 |
## Références
| Source | Type | Date |
|--------|------|------|
| CR visite terrain Still/Mecalux (mail Théo) | CR visite | 2026-05-06 |
| [Stations et routes AGV](agv-stations-routes.md) | Wiki Limagrain | 2026-05-12 |
| [Intégration Still iGo](still-igo-integration.md) | Wiki Limagrain | 2026-05-12 |
| [Troubleshooting standard](../../operations/troubleshooting.md) | Wiki standard | - |
| [AGV module standard](../../modules/agv.md) | Wiki standard | - |
wiki/limagrain/05-agv/job-reception-pk.md
+158
View File
@@ -0,0 +1,158 @@
---
title: "Mini Job — Images de quai vers poste de travail (PK)"
tags: [agv, job, réception, pk, mini-job, big-bag]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-74, LIM-70, LIM-60]
confluence_refs: []
sources: ["LIM-74 LOT1.3 [AGV][JOB] MINI JOB - images de quai poste de travail (PK).md"]
last_updated: 2026-05-12
author: Arthur
---
# Mini Job — Images de quai vers poste de travail (PK)
> **Résumé** : sous-workflow du [Mega Job](../03-picking/job-assignation-pk.md)
> qui orchestre l'envoi des palettes depuis les images de quai vers les
> postes de travail (PK) pour les réceptions fournisseur, intersite et
> retour client.
> **Standard EasyWMS** : → voir
> [Galileo Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Dans le flux de réception fournisseur/intersite/retour client, les
palettes sont déchargées par un cariste sur une image de quai puis
déclarées via le TRF
([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)). Ce job
périodique est le mécanisme qui assigne les réceptions aux PK et crée les
tâches de déplacement.
Ce job fait partie du
[Mega Job (LIM-70)](../03-picking/job-assignation-pk.md) qui en est
l'entête. L'éligibilité du PK (4 conditions) est vérifiée dans l'entête,
pas dans ce sous-workflow.
> Ce job ne concerne **pas** les réceptions de type Production. Celles-ci
> sont envoyées directement vers le PIE de l'ASRS via des supports
> virtuels — voir
> [Job réception production](job-reception-production.md) (LIM-71).
### Process complet de réception
| # | Étape | Ticket |
|---|-------|--------|
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
| 2 | **Déplacement AGV → poste de travail** | **LIM-74 (cette page)** |
| 3 | Traitement au poste de travail | [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
| 4 | Déplacement AGV → table d'entrée (+ filmage) | — |
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
| 6 | Stockage ou rejet | — |
| 7 | Clôture de la réception | [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) |
| 8 | Libération quai / image de quai | — |
## Logique principale
```
POUR CHAQUE PK éligible (vérifié par l'entête LIM-70)
├─ 1. RECHERCHE D'UNE RÉCEPTION À ASSIGNER
│ ├─ Filtrer les réceptions ayant des supports fictifs (séquence 8000*)
│ │ sur une image de quai dont CstAtt06 est vide (pas de PK assigné)
│ ├─ Filtre big-bag : si CstAtt01 du support = true (big-bag)
│ │ → le PK doit figurer dans le paramètre PK_BIGBAG
│ ├─ Trier : ordres big-bag prioritaires (si PK l'autorise), puis FIFO
│ │ sur la date de création de la réception
│ └─ Prendre la PREMIÈRE réception éligible
│
├─ 2. ASSIGNATION DU PK
│ └─ Set CstAtt06 = code du PK sur TOUS les supports de cette réception
│
└─ 3. CRÉATION DES TÂCHES
├─ Pour CHAQUE support fictif de la réception :
│ créer 1 tâche : sous-emplacement image de quai → PK (station)
├─ Statut initial : "en attente"
└─ Toutes les palettes d'une réception → même PK, en une seule passe
```
## Détails des étapes
### 1. Recherche d'une réception
Le job cherche parmi toutes les réceptions non-production celles qui ont
des supports fictifs (séquence 8000*) positionnés sur une image de quai,
dont **CstAtt06 est vide** (pas encore assignés à un PK). Les supports
de production n'ont pas de réception associée et sont donc naturellement
exclus.
**Filtre big-bag** : si les supports de la réception ont `CstAtt01 =
true` (big-bag déclaré lors de la déclaration image de quai), le PK doit
figurer dans le paramètre `PK_BIGBAG`. Si aucun PK compatible n'est
libre, la réception attend.
**Ordre de priorité** : ordres contenant des big-bags d'abord (si le
poste l'autorise), puis FIFO sur la date de création de la réception.
### 2. Assignation du PK
Une fois la réception trouvée, le **CstAtt06** de **tous les supports
fictifs** de cette réception est mis à jour avec le code du PK assigné.
Ce CstAtt sert également à identifier le poste d'origine en cas de
notification de rejet au PIE.
### 3. Création des tâches
Pour chaque support fictif de la réception sur l'image de quai :
- **Origine** : sous-emplacement de l'image de quai
- **Destination** : PK (station). Le sous-emplacement (TP) de
destination est choisi automatiquement par le WMS au moment de la
génération du mouvement
([LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60))
- **Statut** : "en attente"
Le WMS gère ensuite le passage "en attente" → "généré" via le standard
`Task_GenerateMovementJob_PR`, selon la capacité en temps réel du PK. Le
module AGV/GNA envoie les tâches à la flotte iGo.
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| PK_BIGBAG | Liste des PK compatibles big-bag (séparés par `;`) | _(vide)_ |
## Points d'attention
⚠️ Un PK compatible big-bag (`PK_BIGBAG`) peut aussi traiter des
réceptions sans big-bag — le filtre ne s'applique que dans le sens
"big-bag vers PK non compatible".
⚠️ Toutes les palettes d'une même réception vont vers le **même PK** en
une seule passe. Pas de répartition entre PK.
⚠️ Le CstAtt06 empêche le re-traitement d'une réception déjà assignée
lors d'exécutions successives du job.
⚠️ Le nombre de tâches créées peut dépasser le nombre de TP du PK
(ex : 10 tâches pour 3 TP). Le WMS gère le flux "en attente" → "créé"
selon la capacité temps réel.
## Questions ouvertes
_(aucune question ouverte identifiée dans cette tâche)_
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-74 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Ticket Jira | 2026 |
| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) | Ticket Jira (Mega Job) | 2026 |
| [LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60) | Ticket Jira (sous-emplacement auto) | 2026 |
wiki/limagrain/05-agv/job-reception-production.md
+160
View File
@@ -0,0 +1,160 @@
---
title: "Job AGV — Réception production vers ASRS"
tags: [agv, job, reception, production, asrs, pie]
status: draft
standard_ref: architecture/galileo-integration.md
jira_refs: [LIM-71, LIM-64, LIM-66]
confluence_refs: []
sources: ["LIM-71 LOT1.2 RECEPTION PRODUCTION AGV Job de création des tâches images de quai ASRS.md"]
last_updated: 2026-05-12
author: Arthur
---
# Job AGV — Réception production vers ASRS
> **Résumé** : job périodique (30 s) qui crée les tâches de déplacement
> AGV depuis les images de quai vers le buffer d'entrée production
> (alimentant le PIE de l'ASRS). Concerne uniquement les réceptions
> production (CstAtt04 = "ASN").
> **Standard EasyWMS** : → voir
> [Galileo Integration](../../architecture/galileo-integration.md),
> [Galileo Integration](../../architecture/galileo-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au
> standard.
## Contexte projet
Dans le flux de réception production, les palettes arrivent de la
production (ou de l'ancien magasin) et vont **directement dans l'ASRS**
sans passer par un poste de travail. Elles sont déchargées par un
cariste sur une image de quai puis déclarées via le TRF en type
"Production"
([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)).
Ce job crée les tâches de déplacement AGV depuis les images de quai
vers le buffer d'entrée production, qui a une route virtuelle vers une
table d'entrée du convoyeur.
> **Périmètre** : uniquement les réceptions de type Production (supports
> avec CstAtt04 = "ASN"). Les réceptions fournisseur / intersite /
> retour client sont gérées par le
> [Mega Job d'assignation PK](../03-picking/job-assignation-pk.md)
> ([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)).
## Process complet de réception production
```mermaid
sequenceDiagram
participant Cariste
participant TRF as TRF (LIM-64)
participant Job as Job AGV (LIM-71)
participant AGV
participant PIE as PIE (LIM-66)
participant ASRS
Cariste->>TRF: Décharge palette sur image de quai
TRF->>TRF: Déclaration type "Production"
Note over TRF: Support fictif séq. 8000*<br/>CstAtt04 = "ASN"
Job->>Job: Détecte support éligible
Job->>Job: Crée tâche "En attente"
Note over Job: Origine = image de quai<br/>Dest = stratégie rangement
Job-->>AGV: Tâche passe "Créé" → GNA → iGo
AGV->>PIE: Transport vers entrée production
PIE->>PIE: Suppression support virtuel<br/>Création palette ASN
PIE->>ASRS: Stockage ou rejet
```
## Configuration du job
- **Type** : job périodique
- **Fréquence** : toutes les **30 secondes**
## Logique d'éligibilité
Le job parcourt tous les supports positionnés sur des images de quai.
Un support est éligible si **toutes** les conditions suivantes sont
réunies :
| Condition | Détail |
|-----------|--------|
| Séquence 8000* | Support fictif créé lors de la déclaration image de quai ([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)) |
| CstAtt04 = "ASN" | Support de type production |
| CstAtt06 vide | Pas encore traité par ce job |
| Aucune tâche active | Statuts actifs = Bloqué, Créé, En attente, En attente d'annulation, En cours. Statuts historiques (ignorés) = Annulé, Terminé |
La double vérification CstAtt06 + absence de tâche active est une
**sécurité anti-doublon**.
## Traitement d'un support éligible
### Marquage
Le job positionne `CstAtt06` = valeur du paramètre
`DESTINATION_PRODUCTION` (ex : "ENTREE_PRODUCTION").
### Création de la tâche
| Champ | Valeur |
|-------|--------|
| Origine | Sous-emplacement de l'image de quai |
| Destination | Déterminée par la **stratégie de rangement** configurée (MU d'entrée Est ou Ouest, Est par défaut) |
| Statut initial | "En attente" |
Le passage "en attente" → "créé" est géré par le WMS standard
(`Task_GenerateMovementJob_PR`). Le module AGV / GNA écoute ce
changement et envoie les tâches à la flotte iGo.
## Redirection si PIE saturé
Gérée en **standard** par le système de routes et distances configuré
dans EasyS :
- Route principale : distance 1
- Routes secondaires : distance 2
On ferme le PIE de production → le WMS redirige automatiquement vers
les autres entrées disponibles. Ce job envoie toujours vers la même
destination ; c'est le WMS qui reroute si nécessaire.
> ⚠️ À vérifier si faisable avec plusieurs poumons, plusieurs PIE et
> si la config EasyS actuelle est prête pour ce mode dégradé.
## Paramètres
| Paramètre | Description | Valeur par défaut |
|-----------|-------------|-------------------|
| DESTINATION_PRODUCTION | Code du buffer d'entrée production (destination des tâches AGV) | ENTREE_PRODUCTION |
## Points d'attention
- Un support non ASN (fournisseur, intersite, retour) sur une image
de quai est **ignoré** — il est géré par le
[Mega Job](../03-picking/job-assignation-pk.md) (LIM-70)
- Le marquage CstAtt06 a été simplifié en cours de développement
(certains cas de tests marqués "Plus utilisé") — la vérification
par absence de tâche active reste la sécurité principale
- La stratégie de rangement détermine l'entrée Est/Ouest ; le
paramètre DESTINATION_PRODUCTION n'est plus directement utilisé
comme destination de tâche
## Questions ouvertes
- [ ] Redirection multi-poumons / multi-PIE : config EasyS prête ?
(@Nicolas)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification
par tâche active suffit ? (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création initiale depuis LIM-71 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-71](https://easywmsfrance.atlassian.net/browse/LIM-71) | Ticket Jira | 2026 |
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira (déclaration image quai) | 2026 |
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (passage PIE) | 2026 |
wiki/limagrain/05-agv/still-igo-integration.md
+604
View File
@@ -0,0 +1,604 @@
---
title: "Intégration Still iGo — API PACS et architecture"
tags: [agv, still, igo, pacs, api, integration, architecture]
status: draft
standard_ref: modules/agv.md
jira_refs: []
confluence_refs: []
sources: ["CR technique - iGO STILL - fonctionnement et flux API + correspondance avec le module AGV EasyWMS Opus 4.7 v1.md"]
last_updated: 2026-05-12
author: Arthur
---
# Intégration Still iGo — API PACS et architecture
> **Résumé** : documentation complète de l'intégration du fleet manager
> **iGO easy** (STILL / KION Group) avec EasyWMS chez Limagrain.
> Couvre l'API REST PACS 2.3, le cycle de vie des transports, le mapping
> avec le module AGV standard, l'architecture cible à 4 composants et
> les réponses FAQ STILL contractuelles.
> **Standard EasyWMS** : → voir [AGV — Automated Guided Vehicles](../../modules/agv.md)
> Le standard communique par **tables d'échange DB** (EAG/AGE/AGS).
> Chez Limagrain, iGO easy remplace le protocole historique par une
> **API REST HTTPS** — un middleware (pool IIS C#) assure la traduction.
## Contexte projet
Limagrain utilise des AGV **Still EXV CB iGo** (gerbeurs électriques
automatisés) pour les transports internes entre images de quai, PIE,
postes de picking et zones de stockage. Le fleet manager est
**iGO easy** (variante simplifiée de PACS — Productized Automated
Concept Solutions), motorisé par le moteur interne **E'tricc**.
La communication est **100 % REST HTTPS** (port 7002, TLS 1.2) — pas
de PLC ni de tables d'échange SQL directes entre WMS et iGO. Le modèle
est **pull + push** : le WMS pousse les ordres (`POST /transports`),
iGO pousse les changements d'état via webhook (callback POST vers une
URL exposée par le WMS).
## Vue d'ensemble iGO / PACS
```mermaid
flowchart LR
subgraph WMS["Hôte (EasyWMS)"]
EasyWMS["EasyWMS + CstAGV"]
end
subgraph FleetMgr["iGO easy / PACS Fleet Manager"]
Etricc["Moteur E'tricc"]
MyMA["MyMA admin UI"]
Etricc <--> MyMA
end
subgraph Fleet["Flotte AGV"]
EXV["EXV CB iGo<br/>(gerbeur ~3.4m)"]
end
EasyWMS <-->|"HTTPS REST<br/>port 7002<br/>TLS 1.2 + X-API-Key"| Etricc
Etricc -.->|"callback POST<br/>vers WMS"| EasyWMS
Etricc <--> Fleet
```
Concepts clés :
- Pas de notion de routes/segments côté WMS : iGO ne demande qu'une
`sourceLocation` et une `destinationLocation` — la trajectoire
physique est gérée par iGO en interne.
- **Décision tardive** (Group / decision point) : si la destination
exacte est inconnue à la création, on donne un `destinationGroupId`.
iGO place le transport en `RequestDestination` et interroge le WMS
quand l'AGV arrive au point de décision.
- **Load** = container EasyWMS — passé directement dans le payload de
création du transport (pas de `POST /api/loads` préalable — FAQ #5).
## Stack technique iGO (MyMA)
| Composant | Détail |
|-----------|--------|
| Backend | .NET 8.0 (C#) |
| Frontend | Vue 3.2 |
| Base de données | Postgres 12+ (défaut), SQL Server 2019 ou MySQL 8.0 |
| OS serveur | Windows 11/Server 2016-2022, Ubuntu 18.04 |
| Hardware (low) | 4 cores @2.26 GHz, 8 Go RAM, 500 Go RAID5, dual PSU |
| Hardware (high) | 8 cores, 16 Go RAM, 1 To, dual PSU |
### Ports réseau
| Service | Port |
|---------|------|
| Front-end admin MyMA | 82 |
| Backend REST interne | 50005 |
| API Host (HTTPS REST) | **7002** |
| Postgres | 5432 |
## Véhicule — Still EXV CB iGo
Gerbeur électrique automatisé (EXV = Elektro-Vertikal) — se déplace
sur ses propres roues et lève la charge avec le mât. Pas de couloir
mécanique ni de canal compact.
| Caractéristique | Valeur |
|-----------------|--------|
| Longueur totale (l1) | 3 383 mm |
| Longueur jusqu'au dosseret (l2) | 2 083 mm |
| Largeur tablier fourche | 1 000 / 920 / 1 109 mm |
| Fourche (s / e / l) | 50 / 100 / 1 300 mm |
| Hauteur véhicule (arche / mât) | 2 447 / 2 015 mm |
## Modèle de ressources API
L'API PACS 2.3 expose **8 ressources** :
| Ressource iGO | Équivalent EasyWMS | Description |
|----------------|-------------------|-------------|
| **Transport** | `AgvTask` | L'ordre de transport (le cœur) |
| **Vehicle** | AGV station (type 65) | Le véhicule physique |
| **Load** | `Container` / LPN | La charge physique |
| **LoadType** | `ContainerType` | Catalogue de types de charge |
| **Location** | `Location` (`IRealLocation`) | Point physique du warehouse |
| **Group** | `WorkingZone` | Ensemble de locations (décision tardive) |
| **System** | — | État global + abonnements |
### Champs clés du Transport
| Champ iGO | Type | Équivalent EasyWMS |
|-----------|------|--------------------|
| `id` | string | (généré par iGO) |
| `transportHostId` | string | `OrderExtId` (= `Task.TaskNumber`) |
| `sourceLocationId` / `sourceGroupId` | string | `LoadLocation` |
| `destinationLocationId` / `destinationGroupId` | string | `UnloadLocation` |
| `load` | Load | Container (`PalletId`, type, dimensions) |
| `priority` | int 0-10 | Priority 0-4 (conversion inversée) |
| `suspended` | bool | (pas d'équivalent — `false` par défaut) |
| `customMetaData` | dict | `HasTopper`, `PalletType`, etc. |
| `status` | enum | `AgvStatus` (mapping § ci-dessous) |
### Champs clés du Vehicle
| Champ | Type | Description |
|-------|------|-------------|
| `id` | string | Identifiant véhicule |
| `mode` | enum | Manual / Automatic / SemiAutomatic / Removed / Disabled |
| `status` | enum | Idle / Executing / Charging / Faulted / Manual |
| `pose` | object (x, y, orientation) | Position physique temps réel |
| `batteryLevel` | int | % batterie |
| `errors` | array | Codes/labels d'erreur |
## Inventaire des endpoints API
Tous sur `https://[IP]:7002/api/...` avec header `X-API-Key`.
### Transports
| Verbe | URL | Effet |
|-------|-----|-------|
| GET | `/api/transports` | Liste des transports en mémoire |
| POST | `/api/transports` | **Créer un transport** |
| GET | `/api/transports/{id}` | Détail d'un transport |
| POST | `/api/transports/{id}/final-destination` | Fixer destination finale (group → location) |
| POST | `/api/transports/{id}/final-source` | Fixer source finale (group → location) |
| POST | `/api/transports/{id}/suspend` | Mettre en pause |
| POST | `/api/transports/{id}/release` | Relancer après suspend |
| POST | `/api/transports/{id}/cancel` | Annuler |
| POST | `/api/transports/{id}/priority?priority={0-10}` | Changer priorité |
| POST | `/api/transports/subscription?callbackUrl=…` | S'abonner aux events transport |
| DELETE | `/api/transports/subscription?callbackUrl=…` | Se désabonner |
### Vehicles
| Verbe | URL | Effet |
|-------|-----|-------|
| GET | `/api/vehicles` / `/{id}` | Lecture véhicules |
| POST | `/api/vehicles/suspend` | Suspendre toute la flotte |
| POST | `/api/vehicles/resume` | Relancer toute la flotte |
| POST | `/api/vehicles/{id}/suspend` / `.../resume` | Suspend/resume un AGV |
| POST | `/api/vehicles/restart` | Redémarrer la flotte |
| POST | `/api/vehicles/subscription?callbackUrl=…` | S'abonner aux events vehicle |
### Autres
| Verbe | URL | Effet |
|-------|-----|-------|
| GET | `/api/system` | Status global + subscriptions |
| GET | `/api/groups` / `/{id}` | Lecture des groupes |
| GET | `/api/loads` / `/{id}` | Lecture des loads |
| POST | `/api/loads` | Créer une load (non recommandé — FAQ #5) |
| GET | `/api/locations` / `/{id}` | Lecture des locations |
| GET | `/api/load-types` | Catalogue des types |
### Endpoints callback côté WMS (webhook receiver)
| URL côté WMS | Body reçu | Déclenchement |
|-------------|-----------|---------------|
| `POST /agv/transport-event` | Objet Transport complet | Changement d'état transport |
| `POST /agv/vehicle-event` | Objet Vehicle complet | Changement d'état véhicule |
## Cycle de vie d'un Transport
```mermaid
flowchart TD
Req[Requested] --> Pen[Pending]
Pen --> Asg[Assigned]
Asg -->|source = Group| RS[RequestSource]
Asg -->|source = Location| Ret[Retrieving]
RS -->|final source set| Ret
RS -->|AGV arrivé sans réponse| WS[WaitSource]
WS -->|final source set| Ret
Ret --> Rtd[Retrieved]
Rtd -->|dest = Group| RD[RequestDestination]
Rtd -->|dest = Location| Sto[Storing]
RD -->|final dest set| Sto
RD -->|AGV arrivé sans réponse| WD[WaitDestination]
WD -->|final dest set| Sto
Sto --> Std[Stored]
Std --> Fin[Finished]
Asg -.cancel.-> Can[Cancelled]
Pen -.cancel.-> Can
Ret -.error.-> Abo[Aborted]
Sto -.error.-> Abo
```
États terminaux : **Finished**, **Cancelled**, **Aborted**.
> ⚠️ Le statut `New` est un état interne instantané d'iGO — il
> n'apparaît jamais dans les callbacks. Le premier état observable est
> `Requested` (FAQ #4).
### Mapping états iGO → phases EasyWMS
| iGO Transport.status | Phase AGV EasyWMS | AgvStatus | Notes |
|---------------------|-------------------|-----------|-------|
| Requested | — | (après POST) | Premier état observable |
| Pending | 100 (Order accepted) | `Sent` | En file d'attente iGO |
| Assigned | 103 (Vehicle assigned) | (Sent) | ⚠️ Pas de Vehicle.id dans le payload (FAQ #1) |
| RequestSource | 104 (Load permission) | `PendingToBeLoad` | Uniquement en mode Group |
| Retrieving | — | (Sent) | AGV en route / chargement |
| Retrieved | 106 (Load confirmed) | (Sent) | **Vehicle.id disponible ici** (FAQ #1) |
| RequestDestination | 108 (Unload permission) | `PendingToBeUnload` | Uniquement en mode Group |
| Storing | — | — | AGV en dépose |
| Stored / Finished | 110 (Unload confirmed) | (purge) | Transport terminé |
| Cancelled | 255 | (Cancelled) | Annulé |
| Aborted | 255 | (Cancelled) | Erreur irrécupérable — aucun code d'erreur dans le payload (FAQ #2) |
### Différence sémantique majeure : CanPick / CanDrop
Le standard EasyWMS attend une **demande explicite d'autorisation**
(phases 104 / 108) quand `CanPick` / `CanDrop` sont à `false`. iGO ne
demande l'autorisation **qu'au point de décision d'un Group**. Si la
source/destination est une Location connue dès la création, iGO
exécute directement sans demander d'autorisation.
Pour reproduire le comportement EasyWMS dans iGO, il faut **forcer
l'usage de Groups** (même mono-location) là où EasyWMS aurait
`CanPick = false`.
### Conversion de priorité
| EasyWMS | iGO | Suggestion |
|---------|-----|------------|
| 0 — Urgent | 10 — Highest | mapping direct |
| 1 — High | 8 | |
| 2 — Normal | 5 | |
| 3 — Low | 3 | |
| 4 — VeryLow | 1 | |
## Flux nominal — création et exécution
```mermaid
sequenceDiagram
autonumber
participant WMS as EasyWMS
participant iGO as iGO easy
participant V as Vehicle
WMS->>iGO: POST /api/transports
iGO-->>WMS: 200 OK (status=Requested)
iGO->>WMS: callback (Pending)
iGO->>V: assigne véhicule
iGO->>WMS: callback (Assigned)
V->>iGO: arrivé source
iGO->>WMS: callback (Retrieving)
V->>iGO: chargé
iGO->>WMS: callback (Retrieved)
V->>iGO: arrivé destination
iGO->>WMS: callback (Storing)
V->>iGO: déchargé
iGO->>WMS: callback (Stored → Finished)
```
### Flux avec décision tardive (Group)
```mermaid
sequenceDiagram
autonumber
participant WMS
participant iGO
participant V as Vehicle
WMS->>iGO: POST /api/transports {destinationGroupId}
iGO-->>WMS: 200 OK (Requested)
iGO->>WMS: callback (Assigned → Retrieving → Retrieved)
V->>iGO: arrivé au decision point
iGO->>WMS: callback (RequestDestination)
WMS->>iGO: POST /final-destination {destinationId}
iGO-->>WMS: 200 OK
iGO->>WMS: callback (Storing → Stored → Finished)
```
> ⚠️ Si le WMS ne répond pas assez vite, iGO bascule de
> `RequestDestination` vers `WaitDestination` (AGV arrivé et en
> attente). Symétrique côté source : `RequestSource` → `WaitSource`.
### Annulation
Un transport **ne peut pas être annulé après l'état `Retrieved`**
(FAQ #6). Si un cancel arrive côté WMS après `Retrieved`, deux
options : attendre `Finished` puis créer une tâche retour, ou
intervenir manuellement.
## Sécurité et abonnements
### Authentification
**`X-API-Key`** (confirmé par STILL — FAQ #8). Le header
`Authorization: Bearer` mentionné dans certaines parties de la doc
PACS est obsolète. La clé est fixe, fournie par le PM STILL, stockée
chiffrée dans la config du middleware.
### TLS
HTTPS avec TLS 1.2. Certificats **auto-signés** côté iGO — le WMS
doit les truster explicitement (import dans le keystore).
### Modèle d'abonnement
Au démarrage du WMS :
1. `POST /api/transports/subscription?callbackUrl=https://wms/agv/events/transport`
2. `POST /api/vehicles/subscription?callbackUrl=https://wms/agv/events/vehicle`
À l'arrêt : `DELETE` sur les mêmes URLs. Le endpoint callback doit
être en HTTPS, retourner **200 OK rapidement** (< 1s), traitement
asynchrone derrière. Le listener doit être **idempotent** : clé de
déduplication = `transport.id + status` (FAQ #9).
## Mapping erreurs iGO → EasyWMS
| Code EasyWMS | Famille | Équivalent iGO |
|-------------|---------|----------------|
| 1001-1014 | Configuration | `HTTP 400 BadRequest` à la création |
| 2003 | Extraction error | `Transport.status = Aborted` + `Vehicle.errors[]` |
| 2004 | Putaway error | idem |
| 2005 | Manual cancel | `Transport.status = Cancelled` en callback |
| 2500-2503 | Communication | Erreurs HTTP 5xx / timeouts |
| 2700 | Wrong container | `Vehicle.errors[]` + `status = Faulted` |
> ⚠️ Le payload `Aborted` ne contient **aucun code d'erreur** (FAQ #2).
> Pour enrichir le `Flags` AGE, il faut faire un `GET /api/vehicles/{id}`
> complémentaire pour récupérer `errors[].errorCode`.
## Mapping verbes / opérations
| Action métier | EasyWMS (Operation + EAG) | iGO (REST) |
|--------------|--------------------------|------------|
| Créer un ordre | `Operation = Create` + ligne EAG | `POST /api/transports` |
| Modifier un ordre | `Operation = Update` + ligne EAG | `POST /priority`, `/final-source`, `/final-destination` |
| Annuler un ordre | `Operation = Delete` + ligne EAG | `POST /api/transports/{id}/cancel` |
| Suspendre un ordre | (pas d'équivalent) | `POST /suspend` |
| Reprendre un ordre | (pas d'équivalent) | `POST /release` |
| Suspendre la flotte | (pas d'équivalent) | `POST /api/vehicles/suspend` |
| Auth load | EAG `Update` (CanPick=true) | `POST /final-source` |
| Auth unload | EAG `Update` (CanDrop=true) | `POST /final-destination` |
## Architecture cible — Pattern à 4 composants
### Principe directeur
EasyWMS communique avec les fleet managers externes via une **base
intermédiaire** (5 tables). Côté Mecalux, la **Gateway AGV** (existante)
mediate entre les workflows et les tables. Côté flotte, un **middleware
à développer** (pool IIS C# .NET 8) traduit les tables vers/depuis
l'API REST PACS.
**Le custom CstAGV n'est pas modifié.** L'intégration iGO consiste
uniquement à fournir le middleware.
```mermaid
flowchart LR
subgraph EasyWMS["EasyWMS (existant)"]
Process[Process<br/>Putaway/Picking/Shipping]
AgvCore[Module AGV core<br/>+ CstAGV]
GwMec[Gateway AGV Mecalux<br/>workflows ↔ tables]
end
subgraph DB["Base intermédiaire"]
OQ[(AGV_OUTPUTQUEUE)]
EAG[(AGV_EAG)]
IQ[(AGV_INPUTQUEUE)]
AGE[(AGV_AGE)]
AGS[(AGV_AGS)]
end
subgraph Pool["Pool IIS C# .NET 8 — À DÉVELOPPER"]
Pump[Pompe sortante<br/>poll OUTPUTQUEUE → API iGO]
Hook[Webhook receiver<br/>callbacks iGO → tables]
end
subgraph KION["iGO / PACS (STILL)"]
iGO[API REST port 7002]
end
Process --> AgvCore --> GwMec
GwMec --> OQ & EAG
GwMec -.poll.-> IQ & AGE & AGS
Pump -.poll.-> OQ
Pump -.lit.-> EAG
Pump -->|HTTPS X-API-Key| iGO
iGO -.webhook.-> Hook
Hook --> IQ & AGE & AGS
```
### Composants existants — RIEN à modifier
| Composant | Rôle | Statut |
|-----------|------|--------|
| CstAGV (workflows) | Logique métier AGV | ✅ Existant |
| Gateway AGV Mecalux | Mediator workflows ↔ tables | ✅ Existant |
| Tables AGV_* (5) | Base intermédiaire | ✅ Existantes |
| Vues SmartUI AGV | Monitoring opérateur | ✅ Existantes |
### Middleware pool IIS — seul livrable nouveau
| Aspect | Description |
|--------|-------------|
| Forme | Pool IIS C# ASP.NET Core (.NET 8.0) |
| Hébergement | Serveur Mecalux (co-localisé ou VM séparée) |
| Rôle | Pompe sortante + webhook receiver dans un service unique |
| Accès BDD | Connection vers les 5 tables AGV_* |
| Sécurité | `X-API-Key` sortant + HTTPS entrant (TLS 1.2) |
#### Pompe sortante (OUTPUTQUEUE → API iGO)
Polling régulier (1-5 s) sur `AGV_OUTPUTQUEUE WHERE processedDate IS
NULL ORDER BY creationDate ASC`. Pour chaque ligne : récupère
`batchId` → lit `AGV_EAG` → interprète l'`Operation` (C/U/D) → appel
REST iGO. Après ack synchrone (200 OK) : marque `processedDate`.
#### Webhook receiver (callbacks → tables)
Controller ASP.NET Core exposant deux endpoints HTTPS. À réception :
insert dans `AGV_INPUTQUEUE` → insert dans `AGV_AGE` ou `AGV_AGS`
avec le mapping Status → EventType/Flags (cf. tableau ci-dessous).
Horodatage `DateTime.UtcNow` à la réception (iGO ne fournit pas de
timestamp — FAQ #3).
### Mapping Status iGO → (EventType, Flags) AGE
| iGO Transport.status | EventType | Flags | Notes |
|---------------------|-----------|-------|-------|
| Pending | 100 | 0 | Order accepted |
| Assigned | 103 | 0 | Vehicle assigned — `StationNumber=null` (FAQ #1) |
| Retrieved | 106 | 0 | Load confirmed — `Vehicle.id` disponible ici |
| Stored / Finished | 110 | 0 | Unload confirmed |
| Cancelled | 255 | 0 | Annulé |
| Aborted | — | 2003/2004 | À enrichir via `GET /api/vehicles/{id}` (FAQ #2) |
### Pattern de boot du middleware
À chaque démarrage :
1. Vérifier la base intermédiaire accessible
2. Vérifier l'API iGO : `GET /api/system`
3. Vérifier les subscriptions actives — (re)créer si absentes
4. Réconcilier les transports : `GET /api/transports` vs
`AGV_OUTPUTQUEUE` non acquittées → générer les lignes AGE manquantes
5. Démarrer le polling sortant
### Logique d'annulation côté middleware
À la lecture d'un EAG `Operation=Delete`, le middleware doit vérifier
le status iGO courant :
- **Requested / Pending / Assigned / Retrieving** → `POST /cancel` ✅
- **Retrieved / Storing / Stored** → ❌ Cancel impossible (FAQ #6) →
écrire un Flags d'erreur dans AGE → notification opérateur →
fallback (attendre Finished + tâche retour, ou RFT)
- **Cancelled / Aborted / Finished** → no-op (déjà terminal)
### Comparaison avec les Gateways historiques
| Aspect | EasyWMSGateway2015 (Galileo) | GatewayRocla2015 | Pool IIS iGO |
|--------|------------------------------|------------------|--------------|
| Communication aval | TCP socket (port 3000) | TCP socket (port 50011) | HTTPS REST (port 7002) |
| Format messages | Frames GALILEO bas niveau | Frames Rocla propriétaires | JSON REST |
| Auth | `TokenUser` dans config | Intégrée au protocole | `X-API-Key` |
| Architecture | Monolithique | Monolithique (Gateway + middleware fusionnés) | **Découplée** via tables AGV_* |
| Liaison Mecalux | (autre architecture) | Abonnement direct WF (héritage EasyB) | Tables AGV_* (archi moderne) |
> La pool IIS iGO **ne doit pas** être un fork de GatewayRocla2015
> (ancienne architecture monolithique). Développement **from scratch**
> sur ASP.NET Core .NET 8 recommandé.
## Workflows EasyWMS — impact iGO
Avec le pattern Gateway iGO + tables AGV_*, **aucun workflow EasyWMS
ni la Gateway AGV Mecalux n'a besoin d'être modifié**. La spécificité
iGO est entièrement encapsulée dans le middleware.
| Workflow | Comportement avec Gateway iGO |
|----------|-------------------------------|
| `MovementCreatedEventHandler_PR` | ✅ Inchangé — déclencheur |
| `AgvTask_CreateTaskFromMovement_PR` | ✅ Inchangé |
| `SerializeAgvTasks_PR` | ✅ Inchangé — écrit EAG, le middleware lit et POST |
| `ProcessEvents_PR` + `ProcessEvent_*_PR` | ✅ Inchangé — poll AGE comme d'habitude |
| `ProcessErrors_PR` | ✅ Inchangé — réagit aux Flags dans AGE |
| `Agvtask_CanPick/CanDrop_PendingToBeSent_PR` | ✅ Inchangé — écrit EAG, le middleware appelle `/final-source` ou `/final-destination` |
| `TaskCanceledEventHandler_PR` | ✅ Inchangé — écrit EAG Delete, le middleware gère |
| Workflows RFT | ✅ Inchangés — fallback préservé |
## FAQ STILL — réponses contractuelles
Réponses obtenues de STILL en avril 2026. Valeur contractuelle.
| # | Question | Réponse | Impact |
|---|----------|---------|--------|
| 1 | Vehicle.id dès Assigned ? | **Non**, seulement à partir de `Retrieved` | Insérer StationNumber dans AGE uniquement à partir de Retrieved |
| 2 | Code d'erreur dans payload Aborted ? | **Non**, juste le statut | Enrichir via `GET /api/vehicles/{id}` (errors[]) |
| 3 | Timestamp dans callbacks ? | **Non** | Horodater à la réception (`DateTime.UtcNow`) |
| 4 | Statut New vs Requested ? | New = interne instantané, traiter `Requested` comme premier état | Ignorer New |
| 5 | Créer la Load avant le Transport ? | **Non**, passer les infos dans le transport | Ne PAS appeler `POST /api/loads` |
| 6 | Annulation après Retrieved ? | **Non** | Vérifier status iGO avant cancel |
| 7 | Cas d'usage de suspended ? | Pré-création transport avant dispo palette | `suspended = false` par défaut |
| 8 | X-API-Key vs Bearer ? | **X-API-Key** | Jamais Bearer |
| 9 | Retry webhook en cas d'indispo ? | Oui, mais fréquence inconnue | Listener idempotent (transport.id + status) |
| 10 | Persistance après reboot iGO ? | **Oui** | Boot : vérifier subscriptions + réconcilier via GET /transports |
| 11 | Communication directe ou via iGo Flow ? | **Directe** avec l'API PACS | Pas de couche iGo Flow |
### Points encore ouverts avec STILL
| # | Sujet | Statut |
|---|-------|--------|
| 3b | Fréquence des vehicle/event (pose updates) | ❌ Ouvert |
| 5b | customMetaData (taille, caractères, ré-émis ?) | ❌ Ouvert |
| 6b | Création/modification de Location via API | ❌ Ouvert (API GET only) |
| 7b | Pallet Shuttle (LoadType = 1) | ❌ Ouvert |
| 8b | Multi-warehouse | ❌ Ouvert |
| 9b | HasTopper (attribut véhicule) | ❌ Ouvert |
## Points d'attention
⚠️ **CanPick/CanDrop** : pour reproduire le standard EasyWMS, forcer
l'usage de Groups même mono-location.
⚠️ **Priorité inversée** : EasyWMS 0=Urgent, iGO 10=Max — conversion
à coder dans le middleware.
⚠️ **Pas de routing exposé** : iGO gère ses routes en interne — pas
d'équivalent à "Routes between stations" en EasyS, pas d'erreur
"Disabled route" côté iGO.
⚠️ **Annulation après chargement impossible** : la logique
`AgvTask_SetCancelledTask_PR` qui déclenche la recherche de relocation
après chargement n'a plus de sens dans le mapping iGO.
⚠️ **Tests de charge webhook à mener** : simuler Gateway iGO down
pendant 30s / 1min / 5min pour observer le comportement réel d'iGO
(retries, intervalles, abandon).
## Capacités nouvelles iGO (hors standard EasyWMS)
- **Suspend / Resume / Restart** d'une flotte ou d'un véhicule individuel
- **Pose temps réel** (x, y, orientation) → dashboard live possible
- **Battery level** → seuils de notification possibles
## Questions ouvertes
- [ ] Fréquence des callbacks `vehicle/event` pour les mises à jour de
position — risque de flood (@Nicolas)
- [ ] Taille max et caractères autorisés dans `customMetaData` (@STILL)
- [ ] Les `customMetaData` sont-elles ré-émises dans les callbacks
transport ? (@STILL)
- [ ] Création/modification de Location via API iGO — limité à GET
pour l'instant (@STILL)
- [ ] Gestion Pallet Shuttle via iGO (LoadType = 1) — hors scope
actuel ? (@Théo)
- [ ] Multi-warehouse : iGO suppose un seul site — impact si extension
future ? (@Michael)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-12 | Arthur | Création initiale depuis CR technique iGO STILL |
## Références
| Source | Type | Date |
|--------|------|------|
| CR technique iGO STILL — fonctionnement et flux API v1 | CR technique | 2026-04-28 |
| 2510_PACS-2.3-Host-Interface-Technical-Specifications | Spec API STILL | 2025-10 |
| iGo easy 2.3 - Host Interface Specifications | Spec API STILL | 2025 |
| IT requirements R1 20250929 | Spec infra STILL | 2025-09-29 |
| Technical specification EXV CB iGo | Datasheet véhicule | 2025 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005100000021
+225
View File
@@ -0,0 +1,225 @@
---
title: "Données principales et stock — Mapping ITM et attributs"
tags: [ERP, ITM, article, stock, attributs-logistiques, lot-SAP, mapping, CstAtt]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: ["Données principales + stock - LIMAGRAIN - DEV"]
sources: ["Données principales + stock - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Données principales et stock — Mapping ITM et attributs
> **Résumé** : architecture retenue pour la gestion des articles et du stock
> dans EasyWMS chez Limagrain, mapping du message ITM, attributs logistiques,
> profils et gestion des poids.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les décisions ci-dessous sont issues des ateliers d'interfaçage EasyWMS / SAP
réalisés entre le 05/01/2026 et le 23/02/2026, consolidées le 27/02/2026.
## Architecture retenue : Lot SAP = Article WMS
Le code article dans EasyWMS est le **code lot SAP** (et non le code produit
SAP). L'option concaténation code produit + lot SAP a été étudiée et écartée.
Le **code produit SAP** est géré comme un attribut au niveau du stock (pas de
la fiche article), car un même lot SAP peut correspondre à plusieurs produits
différents (ex. : changement de destination).
| Relation | Type | Statut |
|----------|------|--------|
| Lot SAP ↔ Lot Officiel | 1 pour 1 | ✅ Validé par Limagrain |
| Code article WMS = Code lot SAP | — | ✅ Validé |
| Code produit SAP = Attribut logistique du stock | — | ✅ Validé |
### Côté SAP
Il existe une base article avec des codes articles uniques. Les articles sont
gérés au lot. Chaque article peut avoir plusieurs codes lots SAP. Chaque code
lot SAP a un équivalent code lot OFFICIEL national (relation 1:1).
### Côté EasyWMS
Chaque lot SAP est descendu via le fichier ITM. L'article SAP devient un
attribut du lot SAP (et non l'inverse).
**Code article WMS = code lot SAP**
## Unité de base selon le type d'article
| Type article | Description | Unité de base WMS |
|--------------|-------------|-------------------|
| FERT | Produit fini | BAG (sac) |
| ZSIZ | Semi-fini calibré | KG |
L'unité de base dans le WMS est l'unité logistique (pas l'unité de base SAP).
Un même produit peut exister en BAG et en KG = codes articles WMS différents.
## Mapping fiche article (message ITM)
| Champ EasyWMS | Champ SAP | Remarque |
|---------------|-----------|----------|
| ItemCode | Code lot SAP | Clé principale |
| Alias | Lot officiel | Relation 1:1, scannable |
| OwnerCode | — | Constante "MECALUX" (technique) |
| Description | Description longue | Affichage PC |
| AltDescription | Description courte (MAKTL) | Affichage mobile, < 65 car. |
| Type | FERT / ZSIZ / etc. | + description du type |
| Family | Traitement commercial | Ex : "20 : R - Cruiser OSR" — pas de séparation familles en préparation |
| BaseUoM | BAG ou KG | Selon type d'article |
| Weight | Poids brut du sac | Poids unitaire théorique |
| ContainerQty | Nb sacs par palette | Palette pleine standard (= Bag/Pal) |
| ContainerType | Palette | Un seul type de palette |
| CstAtt02 | Espèce | Ex : M = Maïs, S = Tournesol — pour ordonnancement picking |
| CstAtt03 | Génération | Génération article rattachée au lot SAP |
| CstAtt04 | Variété | Ex : "LG50465" |
| CstAtt05 | Big bag | True / False |
| CstAtt06 | GTIN | Ne peut être un alias car non unique |
| CstAtt07 | Semences essais | True / False |
| CstAtt08 | Size (calibre) | — |
| CstAtt09 | Field production area | — |
| CstAtt10 | Stage | ⚠️ À ajouter — requis pour étiquette échantillon |
| Conversion.Principale.CstAtt01 | Poids unitaire article | Poids théorique ERP |
## Profils logistiques
| Type d'article | Profil | Description |
|----------------|--------|-------------|
| Articles classiques | PROFIL_STANDARD | Gestion code produit + propriétaire + description + pays destination |
| Palettes bois vides | PROFIL_PALETTE | Gestion palette bois vide |
## Attributs logistiques du stock
> **Décision du 11/02/2026** : les Custom Attributes au niveau du stock
> (CstAtt01–04) ont été **supprimés** au profit des attributs logistiques
> standards du WMS. Les modes de capture sont désactivés pour éviter la
> customisation de tous les écrans.
| Champ EasyWMS (balise API) | Libellé affiché WMS | Champ SAP | Remarque |
|----------------------------|---------------------|-----------|----------|
| Lot | Lot | Code produit SAP | Différencie les produits pour un même lot SAP |
| Color | Couleur | Code propriétaire SAP | ≠ "MECALUX" technique |
| Source | Source | Description courte SAP | Désignation courte |
| Size | Taille | Pays de destination | Peut changer en cours de vie du stock |
> ⚠️ Les noms de balises API (Color, Size…) ne correspondent pas aux données
> métier. Le renommage d'affichage est géré dans le WMS.
> **Point à tester** : en réception, la création du stock via les attributs
> logistiques doit être validée (approche standard ou custom — à confirmer
> par les tests).
## Gestion des codes clients / fournisseurs
La base client/fournisseur SAP **n'est pas interfacée** avec le WMS.
Les codes sont gérés via des constantes + champ texte libre :
| Flux | Champ code | Champ Source |
|------|------------|--------------|
| ROR Fournisseur | SupplierCode = "FOURNISSEUR" | Code fournisseur SAP + libellé |
| ROR Retour client | AccountCode = "CLIENT" | Code client SAP + libellé |
| SOR / RUT Client | AccountCode = "CLIENT" | Code client SAP + libellé |
| SOR Production | AccountCode = "PRODUCTION" | — |
## Gestion des poids
| Situation | Comportement ERP |
|-----------|-----------------|
| Article en BAG (UdM ≠ KG) | L'ERP ne s'intéresse qu'à la quantité de sacs — les écarts de poids sont ignorés |
| Article en KG | Seule la quantité en KG intéresse l'ERP — si le poids change (balance), le WMS modifie la quantité |
Le poids théorique de la ligne de stock (quantité × poids unitaire, hors
poids palette) est transmis via l'attribut logistique `Weight`.
## Champs NON utilisés dans ITM
Les champs suivants sont explicitement exclus du mapping :
Stock Label, Classification ABC, Alertes stock (min/max), Image produit,
Code danger (pas d'impact logistique), Températures min/max, Cross-docking,
Gerbabilité (gérée via ordonnancement picking), Picking message, IsPacking.
## Conversions
- Unité de base = BAG ou KG (pas de conversion supplémentaire identifiée)
- Pas de gestion financière ni de découpage dans les sacs
- Le nombre de sacs par palette pleine est géré dans la conversion container
(champ `ContainerQty`)
## Types de supports
| Type | Usage | Statut |
|------|-------|--------|
| EWM-PAL00 / PALETTE_US | Palette standard (un seul type) | ✅ Confirmé |
| BIGBAG | Attribut de la HU (pas type séparé) | ✅ Validé |
| Octobin | Hors périmètre phase 1 | ❌ |
La création de types de supports est techniquement lourde (nécessite passage
par support Mecalux, impact design entrepôt). Les BigBag sont déclarés par
l'opérateur au poste de réception. Le WMS ajuste le calcul de poids (+2 kg
environ).
## Z-Bags (sacs vides)
Stockés dans le magasin automatique (SRS) **uniquement pour livraison aux
clients**, pas pour l'approvisionnement production. Doivent respecter les
mêmes formats et règles que les palettes produits. → À valider
fonctionnellement.
## Paramètres généraux de l'interface
| Paramètre | Valeur |
|-----------|--------|
| Format | JSON |
| Opération par défaut | 3 = Upsert |
| Mode de mise à jour | Complete = true (fiche complète à chaque envoi) |
| OwnerCode (technique) | "MECALUX" |
| Site | WF02 |
## Points d'attention
⚠️ Le CstAtt10 (Stage) est **à ajouter** — il est requis pour l'étiquette
d'échantillonnage.
⚠️ Les noms de balises API stock (Color, Size, Source) sont détournés de
leur usage standard — ne pas confondre avec les concepts habituels.
⚠️ Les CstAtt au niveau du stock ont été supprimés (décision 11/02/2026)
au profit des attributs logistiques standards — vérifier l'impact sur les
développements en cours.
⚠️ Le mode Complete = true signifie que chaque ITM contient la fiche
complète (pas de delta) — attention à la volumétrie.
⚠️ La base client/fournisseur n'est pas interfacée : le code est descendu
dans chaque message ROR/SOR/RUT, pas maintenu en master data.
## Questions ouvertes
- [ ] CstAtt10 Stage — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
- [ ] Création stock via attributs logistiques en réception — standard ou
custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis page Confluence DEV |
| 2026-05-06 | Arthur | Ajout champs non utilisés, conversions, types supports, Z-Bags (CR consolidé) |
## Références
| Source | Type | Date |
|--------|------|------|
| Données principales + stock - LIMAGRAIN - DEV | Page Confluence | 27/02/2026 |
| Ateliers interfaçage EasyWMS/SAP | Ateliers | 05/01 → 23/02/2026 |
| Notes complémentaires 11/02/2026 | Note | 11/02/2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers | 23/02/2026 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005300000022
+219
View File
@@ -0,0 +1,219 @@
---
title: "Intégration GNA → SAP-CPI"
tags: [ERP, GNA, SAP-CPI, OAuth, middleware, API, BOO]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: [LIM-89]
confluence_refs: []
sources:
- "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md"
last_updated: 2026-05-12
author: Arthur
---
# Intégration GNA → SAP-CPI
> **Résumé** : mise en place de la communication entre le GNA (middleware
> EasyWMS) et SAP-CPI (middleware cloud SAP) pour l'envoi de tous les
> messages WMS sortants. Authentification OAuth 2.0 client_credentials,
> endpoint unique, routage par MessageType.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> L'intégration standard cible généralement un ERP via API REST classique
> (OAuth password grant). Chez Limagrain, la cible est **SAP-CPI** avec
> un mécanisme spécifique.
> Voir aussi : [LOC — Message périodique](loc-message-periodique.md),
> [Référence messages](messages-reference.md),
> [Mapping ERP-WMS](mapping-erp-wms.md)
## Contexte projet
Dans le cadre du projet Limagrain, le middleware GNA doit envoyer les
messages WMS vers SAP via la plateforme **SAP-CPI** (Cloud Platform
Integration). Une implémentation de référence existe chez un autre client
(AD) mais communique avec un ERP SAP-AIG via une API REST classique
(OAuth password grant).
L'intégration Limagrain est différente : elle cible **SAP-CPI** avec un
**endpoint unique** et une authentification **OAuth 2.0 client_credentials**.
## Architecture technique
### Script principal
Le script `CommonExportWebApi.boo` est le point d'entrée pour tous les
exports WMS → SAP-CPI. Il gère l'authentification, le formatage et
l'envoi des messages.
### Flux de communication
```mermaid
sequenceDiagram
participant WMS as EasyWMS
participant GNA as GNA (BOO)
participant OAuth as SAP OAuth Server
participant CPI as SAP-CPI
WMS->>GNA: Transaction WMS (LOC.SEND, REF01, etc.)
GNA->>GNA: Vérifier cache token
alt Token expiré ou absent
GNA->>OAuth: POST /oauth/token (client_credentials)
OAuth-->>GNA: Bearer token + expiration
GNA->>GNA: Sauvegarder token sur disque
end
GNA->>CPI: POST /http/ATHInboundMessage
Note right of CPI: Body: {MessageType, MessageSAP, data}
CPI-->>GNA: HTTP 200 / erreur
alt Erreur HTTP (hors 401)
GNA->>CPI: Retry backoff (2s, 4s, 8s, 16s)
end
alt HTTP 401
GNA->>GNA: Échec immédiat (token invalide)
end
```
## Authentification OAuth 2.0
### Mécanisme
1. Le GNA obtient un **token bearer** auprès du serveur SAP via un POST
sur `/oauth/token` avec `client_id` et `client_secret`
2. Le grant type est `client_credentials` (pas de password grant)
3. Le token est **mis en cache sur disque** (fichier JSON) avec gestion
de l'expiration (marge de sécurité de 60 secondes)
4. À chaque envoi, le GNA vérifie le cache : si le token est encore valide,
il le réutilise ; sinon il en demande un nouveau
## Envoi des messages — Format du body
Pour chaque message WMS exporté, le GNA envoie un POST vers l'endpoint
unique SAP-CPI `/http/ATHInboundMessage` avec le body JSON suivant :
```json
{
"MessageType": "<type_message_WMS>",
"MessageSAP": "<code_CPI>",
"data": "<contenu_message>"
}
```
Le champ `MessageType` permet au iFlow CPI de **router le message** vers
le bon traitement SAP.
## Table de correspondance MessageType → MessageSAP
Le champ `MessageSAP` est déterminé par une table de correspondance entre
le préfixe du MessageType WMS (3 premiers caractères) et le code SAP-CPI :
| Code CPI | Équivalent WMS | Description |
|----------|----------------|-------------|
| ATH214 | Check flux retour (batch) | Vérification lot retour client |
| ATH215 | REF (type = Supplier) | Finalisation réception fournisseur |
| ATH217 | REF (type = Return) | Finalisation réception retour |
| ATH201 | LOC | Message périodique delta mouvements |
| ATH202 | LOF | Finalisation chargement |
> ⚠️ Si un type de message n'a pas de correspondance dans la table, un
> **warning** est logué et le champ MessageSAP n'est pas inclus dans le
> body.
### Détermination conditionnelle du MessageSAP pour REF
Le message REF peut être routé vers **ATH215** (Supplier) ou **ATH217**
(Return) selon le type de préavis de réception (InboundOrder) lié :
1. Le **REF01Observer.boo** récupère le type de préavis via une requête
LINQ sur `Context.RecLineInboundOrderLines` → `Context.InboundOrders`
2. Le type est transmis dans le champ `RecCustomAttributes.CstAtt20` du
message REF01
3. Le script `CommonExportWebApi.boo` lit `CstAtt20` dans le payload JSON
pour déterminer le `MessageSAP` :
- Type Supplier → `ATH215`
- Type Return → `ATH217`
## Gestion des erreurs — Retry avec backoff
| Situation | Comportement |
|-----------|-------------|
| HTTP 200 | Succès — message envoyé |
| HTTP 401 | **Échec immédiat** — token invalide, pas de retry |
| Autre erreur HTTP | **Retry backoff exponentiel** : 2s → 4s → 8s → 16s |
## Configuration requise
Six clés `CPI_*` à ajouter dans `CommonAppSettings.config`
(section `appSettings`) :
| Clé | Description |
|-----|-------------|
| CPI_AUTH_URL | URL du serveur d'authentification SAP OAuth |
| CPI_CLIENT_ID | Identifiant OAuth |
| CPI_CLIENT_SECRET | Secret OAuth (en clair dans le config) |
| CPI_ENDPOINT_URL | Endpoint unique SAP-CPI (`/http/ATHInboundMessage`) |
| CPI_TOKEN_PATH | Chemin du fichier cache token sur disque |
| CPI_TIMEOUT | Timeout HTTP en secondes (auth + messages) |
## Fichiers impactés
| Fichier | Modification |
|---------|-------------|
| `Scripts2015/CommonExportWebApi.boo` | Script principal d'export WMS → SAP-CPI |
| `Scripts2015/EasyWMS/XML/REF01/REF01Observer.boo` | Ajout requête InboundOrderType + écriture CstAtt20 |
| `Configuration/LIMAGRAI2512/CommonAppSettings.config` | Ajout des 6 clés CPI_* |
## Logging
Chaque étape (connexion, récupération token, envoi message) doit être
loguée avec les détails de la requête et de la réponse. Le body JSON
est logué en **format indenté** pour faciliter le debug.
> ⚠️ Le **token ne doit jamais être logué** (sécurité).
## Cas de tests
- [ ] Le GNA compile sans erreur
- [ ] L'authentification OAuth client_credentials fonctionne (HTTP 200)
- [ ] Le token est mis en cache sur disque et réutilisé tant qu'il est
valide
- [ ] Les messages WMS sont envoyés en POST avec le bon format JSON
- [ ] Le champ MessageSAP est présent avec la bonne valeur selon le type
- [ ] REF type Supplier → MessageSAP = ATH215
- [ ] REF type Return → MessageSAP = ATH217
- [ ] CstAtt20 renseigné dans le message REF01 par le REF01Observer
- [ ] Warning logué si MessageType sans correspondance
- [ ] Retry backoff fonctionne (hors 401)
- [ ] Logs détaillés et lisibles (JSON indenté, token masqué)
- [ ] HTTP 401 → échec immédiat sans retry
## Points d'attention
⚠️ Le **secret OAuth est en clair** dans le fichier de configuration —
accès au fichier à restreindre.
⚠️ La marge de 60 secondes sur l'expiration du token évite les races
conditions mais peut générer des re-authentifications prématurées sous
forte charge.
⚠️ Le backoff exponentiel plafonne à 16 secondes — si SAP-CPI est
durablement indisponible, les messages seront perdus (pas de file
d'attente persistante).
## Questions ouvertes
- [ ] Faut-il implémenter une file d'attente persistante pour les
messages en échec après 4 retries ? (@Nicolas)
- [ ] Le secret OAuth doit-il être chiffré dans le config ?
(@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis LIM-89 |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-89](https://easywmsfrance.atlassian.net/browse/LIM-89) | Ticket Jira | 2026 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005500000023
+494
View File
@@ -0,0 +1,494 @@
---
title: "LOC — Message périodique (spécification complète)"
tags: [ERP, LOC, custom, delta, mouvement, stock, JSON, SAP, GNA]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: [LIM-76]
confluence_refs: []
sources:
- "LOC - Etat des lieux V2.md"
- "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"
- "LIM-76 LOT1.2 [GNA] Message LOC.md"
last_updated: 2026-05-12
author: Arthur
---
# LOC — Message périodique (spécification complète)
> **Résumé** : spécification du message custom LOC, envoyé du WMS vers SAP
> toutes les 5 minutes via le GNA, contenant le delta des HU modifiées.
> Le LOC remplace les messages PCK, MOVE, STV et STC et devient le **seul
> canal** de notification des mouvements de stock vers SAP.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce message est un **[CUSTOM]** — il n'existe pas dans le standard EasyWMS.
> Voir aussi : [Référence messages](messages-reference.md),
> [Flux ERP outbound](../04-outbound/flux-erp-outbound.md),
> [Intégration GNA → SAP-CPI](gna-sap-cpi.md)
## Contexte projet
Le LOC est un message custom envoyé du WMS vers SAP **toutes les 5 minutes**
(✅ reconfirmé le 30/04/2026), contenant l'état de toutes les HU ayant subi
une modification durant la période écoulée.
Il **remplace** les messages PCK et MOVE (supprimés) et centralise la
communication des mouvements physiques vers l'ERP. Le LOC ne transmet pas
l'intégralité de la base, uniquement le **delta sur la fenêtre de 5 minutes**
(basé sur la `CreationDate` des transactions WMS).
### Pourquoi le LOC plutôt que des STV purs ?
Limagrain (Nicolas Sanchez) a exprimé que les STV en delta (+/-)
ne sont **pas fiables** : si un message se perd ou est mal intégré, l'écart
est définitivement perdu. Limagrain souhaite recevoir des **quantités
absolues** que SAP prend pour argent comptant et compare à ses propres
données pour générer les écritures de delta.
Le LOC est un **fork fonctionnel du WSC** (Warehouse Stock Count) adapté
pour ne remonter que le delta des 5 dernières minutes, formaté selon un
JSON spécifique attendu par SAP.
### Décisions structurantes
- **STV désactivé** (post-processing coupé) — le LOC devient le **seul canal**
de notification des mouvements de stock vers SAP
- **STC désactivé** — les changements de statut hors retour sont limités au
B6 (blocage logistique) et sont couverts par le LOC (action R/U).
Les statuts des retours sont remontés dans le REF
## Architecture technique
### Chaîne de traitement
```
Job (toutes les 5 min) → Workflow → Transaction custom LOC.SEND → GNA →
Script BOO (requêtes WMS + agrégation + formatage JSON) → POST API SAP
```
### Côté WMS
1. Un **Job** s'exécute toutes les 5 minutes
2. Ce job appelle un **Workflow custom** dont le seul rôle est de **créer
une transaction custom** `LOC.SEND`
3. Le Workflow et la transaction ne portent aucune logique métier côté WMS —
toute la logique est dans le GNA
### Côté GNA
1. Un **script BOO** dédié au message LOC est créé dans le GNA
2. Le GNA détecte la transaction custom `LOC.SEND`
3. À réception, le script BOO :
- Collecte toutes les transactions WMS pertinentes sur le delta de temps
- Agrège les données par HU et détermine le code ACTION pour chaque
mouvement
- Construit le JSON au format attendu par SAP
- Effectue un **appel POST** vers l'API SAP-CPI (voir
[Intégration GNA → SAP-CPI](gna-sap-cpi.md))
### Détection du delta
1. À chaque exécution, enregistrer un timestamp de dernière exécution
2. Récupérer toutes les transactions dont `CreationDate > dernier_timestamp`
et `CreationDate ≤ timestamp_courant`
3. Agréger par HU, déterminer le code ACTION pour chaque mouvement
4. Générer le JSON et envoyer
5. **Si aucune transaction pertinente sur le delta → pas d'envoi de LOC**
## Couverture fonctionnelle — 7 codes ACTION
| Code | Signification | Déclencheur |
|------|---------------|-------------|
| **B** | Déplacement bin-to-bin | Déplacement de HU d'une zone à une autre |
| **U** | Set to Unrestricted (déblocage) | Déblocage statut B6 |
| **R** | Set to Restricted (blocage) | Blocage statut B6 |
| **S** | Scrap quantity (suppression) | Suppression de stock / support |
| **T** | Transfert inter-HU | Transfert de quantité entre deux HU |
| **C** | Correction de poids | Ajustement de quantité (valeur absolue) |
| **P** | Assignation client | Palette positionnée sur image de quai |
### Palettes exclues du LOC
**Exclure les palettes liées à une réception non fermée** (= dont le REF
n'a pas encore été envoyé). Seules les HU déjà connues de SAP via un REF
préalable doivent apparaître dans le LOC.
## Format JSON attendu par SAP
### Paramètres d'import
| Réf. | Champ | Type | Description |
|------|-------|------|-------------|
| 1 | IV_LGNUM | CHAR 4 | Numéro d'entrepôt (valeur fixe : `"WF02"`) — config EasyS |
| 2 | IV_TREATMENT_ID | CHAR 24 | Horodatage de génération du LOC |
### Structure JSON
```json
{
"IV_LGNUM": "WF02",
"IV_TREATMENT_ID": "<HORODATAGE_GENERATION_LOC>",
"IT_CREATE": [
{
"MATNR": "<CODE_PRODUIT_SAP>",
"BATCHID": "<LOT_SAP>",
"ACTION": "<CODE_ACTION>",
"ANFME": "<QUANTITE_OU_VIDE>",
"ALTME": "<UDM_OU_VIDE>",
"VLPLA": "<ZONE_STOCKAGE_ORIGINE>",
"NLPLA": "<ZONE_STOCKAGE_DESTINATION>",
"VLENR": "<CODE_SUPPORT_ORIGINE>",
"NLENR": "<CODE_SUPPORT_DESTINATION>",
"REASON": "<CODE_RAISON_OU_VIDE>",
"VBELN": "<CODE_LIVRAISON_OU_VIDE>",
"POSNR": "<LIGNE_LIVRAISON_OU_VIDE>"
}
]
}
```
### Table IT_CREATE — Champs (1:n)
| Réf. | Champ | Type | Description |
|------|-------|------|-------------|
| 1 | MATNR | CHAR 40 | Code produit SAP — vide si action B ou P |
| 2 | BATCHID | CHAR 10 | Code lot SAP — vide si action B ou P |
| 3 | ACTION | CHAR 1 | Code action : B, U, R, S, T, C, P |
| 4 | ANFME | NUM 13.3 | Quantité (absolue ou transférée selon action) — vide si B, U/R, P |
| 5 | ALTME | CHAR 3 | Unité de mesure (BAG, KG) — vide si action B ou P |
| 6 | VLPLA | CHAR 18 | Zone de stockage origine |
| 7 | NLPLA | CHAR 18 | Zone de stockage destination |
| 8 | VLENR | CHAR 20 | Code HU (palette) source — SSCC |
| 9 | NLENR | CHAR 20 | Code HU (palette) destination — SSCC |
| 10 | REASON | CHAR 4 | Code raison scrap — uniquement pour action S (ZSC1) |
| 11 | VBELN | — | Code livraison sortante SAP — uniquement pour action P |
| 12 | POSNR | — | Ligne de livraison sortante SAP — uniquement pour action P |
### Données stock/container à récupérer par ligne LOC
Pour chaque HU identifiée dans les transactions du delta :
- **Code produit SAP** : attribut logistique LotCode du stock
- **Code lot SAP** : ItemCode du stock (= code article WMS)
- **Quantité** : quantité actuelle de la ligne de stock (UdM de base WMS =
unité alternative SAP)
- **UdM** : BAG ou KG
- **Zone de stockage** : zone WMS du container (origine et destination)
- **Code support** : ContainerCode (SSCC)
- **Code livraison sortante** : ShippingOrderCode si action P
## Règles de remplissage par action
| Champ | B (déplacement) | U/R (statut) | S (suppression) | T (transfert) | C (correction) | P (assignation) |
|-------|-----------------|--------------|-----------------|---------------|----------------|-----------------|
| MATNR | Vide | Code produit | Code produit | Code produit | Code produit | Vide |
| BATCHID | Vide | Lot SAP | Lot SAP | Lot SAP | Lot SAP | Vide |
| ACTION | B | U ou R | S | T | C | P |
| ANFME | Vide | Vide | Qté supprimée | Qté transférée | Qté absolue | Vide |
| ALTME | Vide | UdM | UdM | UdM | UdM | Vide |
| VLPLA | Zone origine | Zone actuelle | Zone actuelle | Zone HU source | Zone actuelle | Vide |
| NLPLA | Zone destination | Vide | Vide | Zone HU dest. | Vide | Image de quai |
| VLENR | Code HU | Code HU | Code HU | Code HU source | Code HU | Code HU |
| NLENR | Vide | Vide | Vide | Code HU dest. | Vide | Vide |
| REASON | Vide | Vide | ZSC1 | Vide | Vide | Vide |
| VBELN | Vide | Vide | Vide | Vide | Vide | Code livraison |
| POSNR | Vide | Vide | Vide | Vide | Vide | Ligne livraison |
## Règles métier par type d'action
### ACTION = B (Déplacement bin-to-bin)
Déplacement de HU d'une zone à une autre. **Pas de quantité, pas de code
article, pas de lot** — seuls les champs zone et support sont renseignés.
Le contenu de la HU n'est pas rediscuté.
### ACTION = U / R (Déblocage / Blocage statut)
Hors flux retour, le seul statut autorisé est le **B6** (blocage
logistique). ACTION=R pour bloquer, ACTION=U pour débloquer.
Les statuts exotiques des retours (B6, F2, F9, etc.) sont gérés dans
le **REF** de la réception retour, pas dans le LOC.
### ACTION = S (Suppression / Scrap)
REASON est renseigné **uniquement** pour cette action. Valeur : `ZSC1`
(scrapping normal). Pas d'autre valeur possible.
### ACTION = T (Transfert inter-HU)
Source et destination **dans la même ligne** (VLENR + NLENR). ANFME =
quantité transférée (pas le solde restant).
Si le transfert passe par une étape intermédiaire (table de travail),
transmettre chaque étape séparément avec un emplacement matérialisé.
**Cas picking** : 5 tâches alimentant la même palette fille = 5 lignes
ACTION=T dans le même LOC, dans l'ordre chronologique.
**Création de palette au picking** : si le SSCC en NLENR est inconnu de
SAP, SAP crée automatiquement la HU (type palette standard). Le LOC ne
crée que la structure palette — le stock est transféré depuis une palette
source connue.
### ACTION = C (Correction de quantité)
Quantité **absolue** comptée/validée (pas un écart). SAP calcule le
delta. REASON n'est pas renseigné.
### ACTION = P (Assignation client)
Déclencheur : palette physiquement positionnée sur l'**image de quai**
(pas l'assignation logique). Champs obligatoires :
- ACTION = P
- VLENR = Code HU
- NLPLA = Image de quai de la HU
- VBELN = Code livraison sortante SAP (= SorCode côté WMS)
- POSNR = Ligne de livraison sortante SAP (= ligne d'OS associée à
l'article)
Les champs MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON sont
**vides** pour cette action.
## Transactions WMS sources
| Transaction WMS | Action LOC | Données à récupérer |
|-----------------|------------|---------------------|
| CON.MOVE | **B** (déplacement) | ContainerCode, zone origine, zone destination |
| CON.LOCATE | **B** (déplacement) | Idem |
| STK.MOVE | **B** ou **T** | ContainerCode source et dest. Si ContainerTo ≠ ContainerCode → T avec qté transférée |
| STK.ADJ | **C** (correction) | ContainerCode, quantité absolue actuelle après ajustement, UdM |
| CST.STK | **U** ou **R** | ContainerCode, nouveau statut (B6 uniquement hors retour) |
| STK.PICKING | **T** (transfert) | Container source, container destination (palette fille), qté transférée |
| CON.DELETE | **S** (suppression) | ContainerCode, quantité supprimée |
> ⚠️ Vérifier si d'autres transactions sont utiles pour le LOC
> (ex. STK.SCR pour le scrap depuis RF).
## Zones de stockage (VLPLA / NLPLA)
Les codes zone WMS ne correspondent pas directement aux codes emplacement
SAP. Une **table de correspondance** est nécessaire, réalisée via un
paramètre EasyS (ex : `[TK_5_A:TK_5][TK_5_B:TK_5]`).
### Zones attendues par SAP
| Zone SAP | Correspondance WMS |
|----------|--------------------|
| ASRS1 | TK1 (compartiment anoxie) |
| ASRS2 | TK2 (compartiment du milieu) |
| ASRS3 | Zone accessible du TK3 uniquement (grand compartiment) |
| ASRS4 | Zone accessible du TK4 uniquement (grand compartiment) |
| ASRS34 | Zone accessible des deux TK3 et TK4 (grand compartiment) |
| PICKING | Si présent sur un PK/TP |
| QUAI | Si présent sur un emplacement d'image de quai ou sur le quai |
## Horodatage (IV_TREATMENT_ID)
IV_TREATMENT_ID = horodatage du moment de **génération du LOC** (pas
l'heure de chaque transaction individuelle). Toutes les lignes d'un
même LOC partagent le même horodatage.
Format : `YYYYMMDD` — limité à 24 caractères (CHAR 24).
## Ordre des lignes
Les lignes dans IT_CREATE doivent être dans l'**ordre chronologique**
des transactions WMS. SAP traite les lignes dans l'ordre du fichier.
## Contraintes de longueur
| Champ | Type | Longueur max |
|-------|------|--------------|
| IV_LGNUM | CHAR | 4 |
| IV_TREATMENT_ID | CHAR | 24 |
| MATNR | CHAR | 40 |
| BATCHID | CHAR | 10 |
| ACTION | CHAR | 1 |
| ANFME | NUM | 13.3 (13 entiers, 3 décimales) |
| ALTME | CHAR | 3 |
| VLPLA | CHAR | 18 |
| NLPLA | CHAR | 18 |
| VLENR | CHAR | 20 |
| NLENR | CHAR | 20 |
| REASON | CHAR | 4 |
## Désactivation STV et STC
### STV
Désactiver le post-processing des transactions STK.ADJ → plus de
génération de message STV. Le LOC couvre ce besoin via ACTION=C.
**Vérifications préalables obligatoires :**
- Lister toutes les transactions qui génèrent un STV et confirmer que le
LOC couvre chaque cas
- Vérifier que le middleware GNA n'a pas d'autre dépendance au STV
### STC
Désactiver le post-processing des transactions CST.STK → plus de
génération de message STC. Le LOC couvre le B6 via ACTION=R/U.
Mêmes vérifications à effectuer que pour le STV. Documenter les
résultats de cette analyse dans un commentaire de la tâche avant de
procéder à la désactivation.
## Critères d'acceptation
1. Un job WMS tourne toutes les 5 minutes et crée une transaction custom
LOC.SEND
2. Le GNA détecte cette transaction et génère un JSON LOC conforme
3. Le JSON est envoyé en POST à l'endpoint SAP
4. Les 7 codes ACTION (B, U, R, S, T, C, P) sont correctement générés
5. ACTION=B : ANFME, ALTME, MATNR, BATCHID, NLENR, REASON, VBELN, POSNR
vides — seuls VLPLA, NLPLA et VLENR renseignés
6. ACTION=U/R : MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés —
ANFME, NLPLA, NLENR, REASON, VBELN, POSNR vides
7. ACTION=S : REASON=ZSC1 — MATNR, BATCHID, ANFME, ALTME, VLPLA, VLENR
renseignés — NLPLA, NLENR, VBELN, POSNR vides
8. ACTION=T : VLENR et NLENR dans la même ligne — ANFME = qté transférée
(pas un solde) — REASON, VBELN, POSNR vides
9. ACTION=C : ANFME = quantité absolue (pas un delta) — NLPLA, NLENR,
REASON, VBELN, POSNR vides
10. ACTION=P : VLENR, NLPLA (image de quai), VBELN, POSNR renseignés —
MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON vides
11. Palettes liées à une réception non fermée (pas de REF envoyé) exclues
12. Lignes dans IT_CREATE dans l'ordre chronologique des transactions WMS
13. IV_TREATMENT_ID = horodatage de génération (CHAR 24)
14. Aucune transaction pertinente sur le delta → pas d'envoi de LOC
15. Contraintes de longueur respectées sur tous les champs
16. STV et STC désactivés après validation de l'analyse d'impact
17. Picking N tâches → N lignes ACTION=T dans l'ordre chronologique
18. SSCC inconnu en NLENR lors d'un ACTION=T → LOC ne bloque pas, SAP
crée la HU automatiquement
## Cas de tests
### Architecture et Job
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-01 | 1 | Déclenchement job toutes les 5 min | 3 transactions LOC.SEND en 15 min |
| CT-02 | 2,3 | GNA détecte LOC.SEND et génère JSON | JSON conforme + POST HTTP 200 |
| CT-03 | 14 | Aucune transaction sur le delta | Aucun POST vers SAP |
### ACTION=B — Déplacement
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-10 | 4,5 | Déplacement via CON.MOVE | ACTION=B, seuls VLPLA/NLPLA/VLENR renseignés |
| CT-11 | 4,5 | Déplacement via CON.LOCATE | Idem CT-10 |
| CT-12 | 4,5 | STK.MOVE sans changement HU (ContainerTo=ContainerCode) | ACTION=B (pas T) |
### ACTION=U/R — Blocage / Déblocage
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-20 | 4,6 | Blocage HU via CST.STK (→ B6) | ACTION=R, MATNR/BATCHID/ALTME/VLPLA/VLENR renseignés |
| CT-21 | 4,6 | Déblocage HU via CST.STK (← B6) | ACTION=U |
| CT-22 | 6 | Changement statut hors B6 (hors retour) | Aucune ligne dans le LOC |
### ACTION=S — Suppression / Scrap
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-30 | 4,7 | CON.DELETE sur une HU | ACTION=S, REASON=ZSC1, qté et champs stock renseignés |
| CT-31 | 7 | Plusieurs suppressions | Chaque ligne S a REASON=ZSC1 uniquement |
### ACTION=T — Transfert inter-HU
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-40 | 4,8 | STK.MOVE avec ContainerTo ≠ ContainerCode | ACTION=T, VLENR+NLENR+ANFME renseignés |
| CT-41 | 4,8 | STK.PICKING | ACTION=T, ANFME = qté transférée (pas solde) |
| CT-42 | 17 | 3 pickings → même palette fille | 3 lignes T dans l'ordre chronologique |
| CT-43 | 18 | Picking vers SSCC inconnu SAP | Ligne T générée, LOC ne bloque pas |
| CT-44 | 8 | Transfert via table de travail | 2 lignes distinctes (pas de fusion) |
### ACTION=C — Correction de quantité
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-50 | 4,9 | STK.ADJ (ajustement) | ACTION=C, ANFME = qté absolue après ajustement |
| CT-51 | 9 | Vérification REASON vide | REASON vide pour action C |
### ACTION=P — Assignation client
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-60 | 4,10 | Palette sur image de quai | ACTION=P, VLENR/NLPLA/VBELN/POSNR renseignés |
| CT-61 | 10 | Champs vides vérifiés | MATNR/BATCHID/ANFME/ALTME/VLPLA/NLENR/REASON vides |
### Filtre d'exclusion
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-70 | 11 | HU réception non fermée (pas de REF) | Aucune ligne dans le LOC |
| CT-71 | 11 | HU réception fermée (REF envoyé) | Ligne présente dans le LOC |
### Ordre chronologique et horodatage
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-80 | 12 | 3 transactions dans l'ordre | Lignes dans l'ordre chronologique |
| CT-81 | 13 | IV_TREATMENT_ID | Horodatage de génération, ≤ 24 car. |
### Contraintes de longueur et cas combinés
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-90 | 15 | Valeurs aux limites de longueur | JSON sans troncature |
| CT-91 | 15 | ANFME avec décimales | Format NUM 13.3 respecté |
| CT-100 | 16 | STK.ADJ après désactivation STV | Pas de STV, LOC contient ACTION=C |
| CT-101 | 16 | CST.STK après désactivation STC | Pas de STC, LOC contient ACTION=R |
| CT-110 | 4,12 | Plusieurs actions dans le même delta | 4 lignes, 4 actions, ordre chronologique |
| CT-111 | 2 | IV_LGNUM | Toujours "WF02" |
| CT-112 | — | HU multi-lignes de stock | Plusieurs entrées dans IT_CREATE |
## Points d'attention
⚠️ **STV et STC désactivés** — vérifier qu'aucun autre process métier ne
dépend d'eux (middleware GNA, reporting).
⚠️ Le filtrage GNA des STV avec motif "STR" devient caduc si le STV est
globalement désactivé.
⚠️ Le LOC ne doit jamais transmettre de palettes dont la réception n'est
pas fermée (pas de REF envoyé).
⚠️ Pour ACTION=B, les champs MATNR, BATCHID, ANFME, ALTME sont tous vides.
⚠️ Les quantités sont des valeurs **absolues** sauf pour ACTION=S (quantité
supprimée) et ACTION=T (quantité transférée).
⚠️ IV_LGNUM = `"WF02"` (pas "WL02" — corrigé depuis spec V2).
## Questions ouvertes
- [ ] Cas palette déposée sur image de quai → chargée → OS fermé →
LOF/SOF envoyé avant le LOC : la HU ne sera pas mentionnée dans le LOC
(@Limagrain)
- [ ] HU multi-lignes de stock : comportement exact à confirmer (CT-112)
(@Fabien)
- [ ] Vérifier si d'autres transactions WMS sont utiles pour le LOC
(ex. STK.SCR) (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-06 | Arthur | Création depuis spec LOC V2 (réunion 30/04/2026) |
| 2026-05-12 | Arthur | Refonte complète depuis LIM-76 : architecture technique GNA/BOO, ACTION=P confirmé avec VBELN/POSNR, IV_LGNUM corrigé WF02, zones SAP détaillées, contraintes de longueur, 25+ cas de tests, critères d'acceptation |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76) | Ticket Jira (LOT 1.2) | 2026 |
| LOC - Etat des lieux V2 | Spécification technique | 30/04/2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
| Réunion LOC 30/04/2026 | Réunion Arthur + Justine + Nicolas | 30/04/2026 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005700000024
+173
View File
@@ -0,0 +1,173 @@
---
title: "Mapping ERP-WMS — Changement article et propriétaire"
tags: [ERP, mapping, CHG, STR, article, propriétaire, custom]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Mapping ERP-WMS — Changement article et propriétaire
> **Résumé** : processus [CUSTOM] de changement d'article et de propriétaire
> en cours de vie du stock, via message CHG.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Voir aussi : [Données principales et stock](donnees-principales.md) pour
> le mapping complet ITM, attributs logistiques et architecture article/lot.
## Contexte projet
Chez Limagrain, l'article (numéro, description et destination) et le
propriétaire peuvent être modifiés en cours de vie du stock. Ces changements
sont notifiés par un message CHG descendant de SAP vers EasyWMS.
Le message standard STR (Stock Transfer Request) est aussi utilisé pour
les demandes de changement de statut de stock.
## Message STR — Demande de Changement de Stock
### Cas d'usage
L'ERP envoie un STR pour :
- Changement de code article (produit SAP + description)
- Changement de propriétaire
- Blocage/déblocage de lot
### Règles d'acceptation
- **Accepté** si la palette n'est pas assignée à une commande ou en cours
de mouvement
- **Refusé** si palette "client" ou en préparation → code erreur API explicite
(ERR renvoyé à SAP)
### Interaction STV/GNA
L'ajustement de stock avec motif "STR" est filtré par le middleware GNA
(pas de retraitement STV pour éviter les doublons). Ce mécanisme devient
caduc si le STV est globalement désactivé (décision 30/04/2026).
### Monitoring
Limagrain mettra en place un **monitoring des erreurs** STR pour les cas
de refus. Les refus sont attendus en fonctionnement normal (palette en
cours de préparation au moment du STR).
## Message CHG — Changement article / propriétaire
### Contenu du message
| Champ | Description | Modifié si |
|-------|-------------|------------|
| Numéro de HU | Identifiant palette | Toujours présent |
| Lot Officiel | Lot de référence | Toujours présent |
| Code nouvel article | Nouveau code article | Changement article |
| Description nouvel article | Libellé | Changement article |
| Destination | Nouvelle destination | Changement article |
| Propriétaire Limagrain | Nouveau propriétaire | Changement propriétaire |
### Contrainte d'exécution
Le changement ne peut avoir lieu **que si le stock n'est pas assigné à
un processus** (picking, expédition, regroupement, etc.).
Si le stock est assigné → le message CHG génère un message **ERR** pour
informer SAP que le changement est impossible.
## Statut de stock
### Changement sur poste de travail
[CUSTOM] L'utilisateur peut changer le statut du stock sur le poste de
travail **uniquement** lors du processus de **retour commandes clients**,
pour appliquer :
- **F9** — Sacs sales
- **B6** — Non conforme
Un commentaire est associé au statut et remonté dans le message d'interface
(STC) pour informer l'ERP.
### Attributs du statut de stock
[CUSTOM] 3 attributs relatifs au statut de stock chez Limagrain :
1. **Statut de stock** : valeur du statut (ex : F9, B6)
2. **Commentaire** : raison du changement (liste déroulante contextuelle)
3. **Date de changement** : horodatage automatique
Les commentaires sont présentés sous une liste déroulante avec les
possibilités dépendant du statut sélectionné.
### Autonomie Limagrain
Limagrain peut créer ses propres statuts de stock :
- Menu « Données principales » → « Types de verrous » → « Statut de stock »
- Bouton « Nouveau » → remplir les champs requis
## Diagramme de séquence — Changement article
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
SAP->>WMS: CHG (nouveau code article, description, destination)
alt Stock non assigné
WMS->>WMS: MAJ article sur les lignes de stock
Note over WMS: Pas de confirmation retour
else Stock assigné à un processus
WMS->>SAP: ERR (changement impossible)
end
```
## Diagramme de séquence — Changement statut (retour client)
```mermaid
sequenceDiagram
participant OP as Opérateur
participant WMS as EasyWMS
participant SAP
OP->>WMS: Changement statut (F9 ou B6) + commentaire
WMS->>WMS: MAJ statut ligne de stock
WMS->>SAP: STC (notification changement statut)
```
## Points d'attention
⚠️ Le CHG ne renvoie pas de confirmation positive — seule l'erreur (ERR)
est remontée si le changement échoue.
⚠️ Le changement de statut sur poste est limité au processus retour client
(pas en picking ni en regroupement).
⚠️ Le message STR (standard) est aussi utilisé pour des demandes de
changement de statut initiées par SAP.
## Questions ouvertes
- [ ] Liste exhaustive des statuts de stock Limagrain prévus au démarrage (@Justine)
- [ ] Liste des commentaires par statut — validée ? (@Justine)
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas d'échec ? (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-06 | Arthur | Ajout section STR détaillée (CR consolidé ERP) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005900000025
+321
View File
@@ -0,0 +1,321 @@
---
title: "Catalogue des messages ERP — Référence complète"
tags: [ERP, messages, interface, SAP, catalogue, ITM, ASN, ROR, ROF, REF, SOR, RUT, SOF, LOF, PCK, MOV, STV, STR, STC, SCR, WSC, COR, COF, LOC, ERR, CHG]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Catalogue des messages ERP — Référence complète
> **Résumé** : tableau de référence de tous les messages d'interface entre
> SAP EWM et EasyWMS chez Limagrain, classés par domaine fonctionnel.
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication entre SAP EWM et EasyWMS utilise XML + Webservice.
Le détail des champs est dans le document « Liste Interfaces LIMAGRAIN »
(fichier séparé). Cette page référence la typologie et le rôle de chaque
message.
## Tableau synthétique
### SAP → EasyWMS (flux entrants)
| Domaine | Message | Standard/Custom | Description | Statut |
|---------|---------|-----------------|-------------|--------|
| Master Data | ITM | Standard | Fiche article (Lot SAP) | ✅ Validé |
| Réception | ASN | Standard | Réception production (1 par palette) | ✅ Validé |
| Réception | ROR | Standard | Réceptions externes + retours clients | ✅ Validé |
| Expédition | SOR | Standard | Ordres de sortie (prod/recertif) | ✅ Validé |
| Expédition | RUT | Standard | Routes / tournées client | ✅ Validé |
| Stock | STR | Standard | Demande changement de stock (article, statut) | ✅ Validé |
| Inventaire | COR | Standard | Demande d'échantillonnage | ✅ Validé |
| Inventaire | SCR | Standard | Demande image de stock de l'entrepôt | ✅ Validé |
### EasyWMS → SAP (flux sortants)
| Domaine | Message | Standard/Custom | Description | Statut |
|---------|---------|-----------------|-------------|--------|
| Réception | REF | Standard | Finalisation de réception (+ zone stockage) | ✅ Validé |
| Réception | ROF | Standard | Clôture d'ordre d'entrée | ✅ Validé |
| Expédition | SOF | Standard | Finalisation ordre de sortie | 🟡 Phase 2 |
| Expédition | LOF | Standard | Finalisation de chargement | ✅ Validé |
| Stock | STV | Standard | Variation de stock | ⚠️ **DÉSACTIVÉ** (remplacé par LOC) |
| Stock | STC | Standard | Notification changement de statut | ⚠️ **DÉSACTIVÉ** (remplacé par LOC) |
| Stock | LOC | [CUSTOM] | Message périodique delta 5 min | ✅ Validé |
| Stock | WSC | Standard | Image de stock journalière | 🟡 Volumétrie à vérifier |
| Inventaire | COF | Standard | Confirmation d'échantillonnage | 🟡 Traitement à confirmer |
| Expédition | PCK | [CUSTOM] | Passage conteneur client | ⚠️ **REMPLACÉ** par LOC |
| Erreur | ERR | Standard | Erreur d'importation de message | ✅ Validé |
### Flux supprimés ou non retenus
| Message | Statut | Raison |
|---------|--------|--------|
| MOV | **Supprimé** | Redondant avec LOC + STR combinés |
| PCK | **Remplacé** par LOC | Le LOC périodique couvre le besoin |
| STV | **Désactivé** | Le LOC devient le seul canal stock (décision 30/04/2026) |
| STC | **Désactivé** | Statuts hors retour = B6 uniquement via LOC |
| ACC/SUP | **Non transmis** par l'ERP | Base client/fournisseur non interfacée |
| ROC | **Non utilisé** a priori | À confirmer côté Limagrain |
### Messages bidirectionnels / custom
| Domaine | Message | Direction | Standard/Custom | Description |
|---------|---------|-----------|-----------------|-------------|
| Réception | API Lot | WMS ↔ ERP | [CUSTOM] | Demande/réponse lot SAP pour retours clients |
| Stock | CHG | ERP → WMS | [CUSTOM] | Changement article et/ou propriétaire |
## Messages custom détaillés
### PCK — Passage Conteneur Client
- **Déclencheur** : stock préparé, passage en conteneur client EasyWMS
- **Contenu** : information passage conteneur client
- **Envoyé pour** : commande client, consommation OF hors recert, messagerie
- **Voir** : [Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
### ~~MOV — Movement~~ ANNULÉ
> **ANNULÉ** — décision réunion client, jugé inutile.
- ~~**Déclencheur** : déplacement de stock entre palettes~~
- ~~**Contenu** : palette d'origine, palette de destination, quantité~~
### LOC — Message périodique (détaillé)
- **Déclencheur** : Job toutes les 5 min → WF → transaction `LOC.SEND` → GNA
(script BOO) → POST SAP-CPI
- **Remplace** : PCK, MOVE, STV, STC
- **Actions** : B (déplacement), U/R (statut B6), S (suppression), T (transfert
inter-HU), C (correction quantité), **P (assignation client)**
- **Quantités** : valeurs absolues (pas des écarts) sauf ACTION=S et T
- **Exclusion** : palettes dont la réception n'est pas fermée (pas de REF)
- **Approche technique** : fork du WSC avec filtre temporel sur CreationDate
- **Transport** : via GNA → SAP-CPI (OAuth 2.0 client_credentials) —
code CPI : **ATH201**
- **Voir** : [Spécification complète LOC](loc-message-periodique.md),
[Intégration GNA → SAP-CPI](gna-sap-cpi.md),
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
### STV — Variation de Stock (⚠️ DÉSACTIVÉ)
> ⚠️ **Décision 30/04/2026** : le STV est désactivé (post-processing coupé).
> Le LOC devient le seul canal de notification des mouvements de stock vers SAP.
- **Direction** : WMS → SAP
- **Rôle initial** : notifier les ajustements de quantités manuels (hors flux
standards réception/expédition)
- **Mapping clé** :
| Balise | Utilisation |
|--------|-------------|
| Operation | C (positif) / D (négatif) |
| Site | WF02 |
| ItemCode | Code lot SAP |
| OwnerCode | MECALUX |
| ContainerCode | Numéro HU |
| FilterAttributes | Attributs du stock existant modifié |
| Attributes | Attributs du stock nouvellement créé |
| ReasonCode | AJUSTEMENT MANUEL |
| ERPReasonCode | ZSC1 |
| Comment | Facultatif (opérateur) |
- **Point ouvert** : Limagrain doit définir comment gérer côté ERP un STV de
type "création de stock" (l'ERP n'autorise pas la création de stock par ce
biais aujourd'hui)
- **Raison désactivation** : Limagrain préfère des quantités absolues (LOC)
plutôt que des écarts +/- (STV) — si un message se perd, l'écart est
définitivement perdu
### STR — Demande de Changement de Stock
- **Direction** : ERP → WMS
- **Cas d'usage** : changement de code article (produit SAP + description),
changement de propriétaire, blocage/déblocage de lot
- **Règles d'acceptation** :
- **Accepté** si la palette n'est pas assignée à une commande ou en cours
de mouvement
- **Refusé** si palette "client" ou en préparation (code erreur API explicite)
- **Interaction avec STV** : ajustement avec motif "STR" → le middleware (GNA)
ne traite pas les STV avec ce motif pour éviter les doublons
- **Monitoring** : Limagrain mettra en place un monitoring des erreurs pour
les cas de refus
- **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
### COR — Demande d'Échantillonnage
- **Direction** : ERP → WMS
- **Usage** : **uniquement** pour les demandes d'échantillonnage (pas pour les
inventaires physiques classiques, gérés dans EasyWMS en phase 1)
- **Mapping** :
| Balise | Valeur |
|--------|--------|
| Description | "ECHANTILLONNAGE" (en dur, discriminant WMS) |
| Code | Numéro du lot d'inspection SAP |
| Priority | 3 (basse) |
| ProductCode | Code lot SAP |
| LotCode | Code produit SAP |
| Color, Source, Size | Attributs logistiques standards |
- **Flux** : COR envoyé → WMS fait venir la palette sur un poste de travail →
opérateur prélève → palette repart en stockage → COF envoyé
- **Règle** : un article en cours d'échantillonnage **n'est pas disponible**
pour les ordres de sortie
- **Voir** : [Échantillonnage](../03-picking/echantillonnage.md)
### COF — Confirmation d'Échantillonnage
- **Direction** : WMS → ERP
- **Mapping** :
| Balise | Description |
|--------|-------------|
| CountCode | Numéro du lot d'inspection |
| Status | Closed (effectué) ou Cancelled (annulé) |
| UpdateDate | Date/heure de changement |
- **Point ouvert** : Limagrain doit confirmer si le COF sera traité côté ERP.
Si non traité, risque de demandes en double.
### WSC — Image de Stock Journalière
- **Direction** : WMS → ERP
- **Rôle** : image de stock complète pour vérification de cohérence. Contient
l'ensemble du stock : code OS, statut palette, toutes les informations
disponibles
- **Démarrage** : export manuel EasyWMS + export SAP + comparaison.
Automatisation possible ultérieurement (quotidien à heure fixe)
- **Point d'attention** : Limagrain doit vérifier sa capacité à traiter ce
fichier (volumétrie potentiellement élevée pour CPI)
- **Déclenchement** : transaction `SCR.REQ` ou `STOCKSYNC.ASKED`
### STC — Notification Changement de Statut (⚠️ DÉSACTIVÉ)
> ⚠️ **Décision 30/04/2026** : le STC est désactivé. Les changements de statut
> hors retour sont limités au B6 (blocage logistique standard) et sont couverts
> par le LOC (action R/U). Les statuts des retours sont remontés dans le REF.
### CHG — Changement article / propriétaire
- **Déclencheur** : modification article ou propriétaire dans SAP
- **Contenu** : numéro de HU, lot officiel, code nouvel article, description,
destination, propriétaire Limagrain
- **Contrainte** : le stock ne doit pas être assigné à un processus (sinon ERR)
- **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
### API Lot SAP — Retours clients
- **Déclencheur** : lot officiel inconnu lors d'un retour client
- **Contenu (demande)** : lot officiel à vérifier
- **Contenu (réponse)** : lot SAP correspondant + attributs logistiques
- **Parallèle** : un ITM est descendu avec les infos article
- **Voir** : [Réception retour](../01-inbound/reception-retour.md)
## Flux par processus
### Réception production (ASN)
```
SAP → ASN → EasyWMS → (réception + stockage) → REF → SAP
→ ROF → SAP
→ LOC (delta 5 min) → SAP
```
### Réception extérieure / retour (ROR)
```
SAP → ROR → EasyWMS → (réception + contrôle) → REF → SAP
→ ROF → SAP
→ LOC (delta 5 min) → SAP
```
### Expédition client (RUT)
```
SAP → RUT → EasyWMS → (picking + chargement) → LOC (delta 5 min) → SAP
→ LOF → SAP
→ SOF → SAP (phase 2)
```
### Consommation OF (SOR)
```
SAP → SOR → EasyWMS → (sortie) → LOC (delta 5 min) → SAP
→ SOF → SAP (phase 2)
```
### Échantillonnage
```
SAP → COR → EasyWMS → (prélèvement poste) → COF → SAP
```
### Image stock (vérification cohérence)
```
SAP → SCR → EasyWMS → WSC → SAP (image complète)
```
### Changement de stock
```
SAP → STR → EasyWMS → (MAJ stock) → LOC (delta 5 min) → SAP
OU → ERR → SAP (si stock assigné)
```
## Points d'attention
⚠️ **STV et STC désactivés** (décision 30/04/2026) — le LOC est le seul canal
de notification des mouvements de stock vers SAP.
⚠️ Le message CHG est rejeté (ERR) si le stock est assigné à un processus
en cours.
⚠️ MOV, PCK sont **supprimés/remplacés** — le LOC couvre tous ces besoins.
⚠️ L'ASN envoie 1 palette par message (pas d'agrégation — permet suppression
individuelle en cas d'annulation).
⚠️ Le STR est refusé si la palette est assignée "client" ou en préparation.
Le middleware GNA filtre les STV avec motif "STR" pour éviter les doublons
(caduc si STV globalement désactivé).
⚠️ Le COF n'est utile que si SAP le traite — sinon risque de demandes
d'échantillonnage en double.
## Questions ouvertes
- [ ] Détail champ par champ de chaque message — document séparé à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
- [ ] Confirmer si le COF sera traité côté ERP (@Limagrain)
- [ ] Vérifier capacité de traitement du WSC quotidien — volumétrie (@Limagrain)
- [ ] Confirmer retour fournisseur : SOR simple ou RUT ? (@Limagrain)
- [ ] Effets de bord désactivation STV — lister toutes les transactions
STK.ADJ et vérifier couverture LOC (@Mecalux)
- [ ] Effets de bord désactivation STC — idem pour CST.STK (@Mecalux)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure JSON, flag client) |
| 2026-05-06 | Arthur | Enrichissement complet depuis CR consolidé ERP (STV, STR, COR/COF, WSC, flux supprimés, désactivation STV/STC) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 05/01 → 23/02/2026 |
| Expédition - LIMAGRAIN - DEV | Page ateliers DEV | 2026 |
wiki/limagrain/06-erp-interface/.fuse_hidden0000005b00000026
+58
View File
@@ -0,0 +1,58 @@
---
title: "Interface ERP — Vue d'ensemble"
tags: [erp, interface, messages, index]
status: draft
last_updated: 2026-05-05
---
# Interface ERP — Vue d'ensemble
> **Périmètre** : catalogue de messages ERP (SOR, RUT, SOF, LOF, ASN),
> mapping champs ERP↔WMS, monitoring de l'interface.
> **Standard EasyWMS** : voir [ERP Integration](../../architecture/erp-integration.md)
## Pages de cette section
- [Référence messages](messages-reference.md)
- [Données principales et stock](donnees-principales.md)
- [LOC — Message périodique](loc-message-periodique.md)
- [Intégration GNA → SAP-CPI](gna-sap-cpi.md)
- [Mapping ERP-WMS](mapping-erp-wms.md)
- [Monitoring interface](interface-monitoring.md)
## Vue synthétique de l'interface ERP Limagrain
```mermaid
flowchart LR
subgraph SAP[SAP EWM]
ITM[ITM]
ASN[ASN]
ROR[ROR]
RUT[RUT]
SOR[SOR]
STR[STR]
SCR[SCR]
COR[COR]
CHG[CHG]
end
subgraph WMS[EasyWMS]
ROF[ROF]
REF[REF]
SOF[SOF]
LOF[LOF]
PCK[PCK]
MOV[MOV]
STV[STV]
STC[STC]
WSC[WSC]
LOC[LOC]
ERR[ERR]
end
SAP -->|ERP → WMS| WMS
WMS -->|WMS → ERP| SAP
```
> **21 messages** au total : 9 entrants (ERP → WMS), 11 sortants (WMS → ERP),
> 1 bidirectionnel (API Lot). Voir [Référence messages](messages-reference.md)
> pour le détail.
wiki/limagrain/06-erp-interface/_index.md
+58
View File
@@ -0,0 +1,58 @@
---
title: "Interface ERP — Vue d'ensemble"
tags: [erp, interface, messages, index]
status: draft
last_updated: 2026-05-05
---
# Interface ERP — Vue d'ensemble
> **Périmètre** : catalogue de messages ERP (SOR, RUT, SOF, LOF, ASN),
> mapping champs ERP↔WMS, monitoring de l'interface.
> **Standard EasyWMS** : voir [ERP Integration](../../concepts/erp-interface.md)
## Pages de cette section
- [Référence messages](messages-reference.md)
- [Données principales et stock](donnees-principales.md)
- [LOC — Message périodique](loc-message-periodique.md)
- [Intégration GNA → SAP-CPI](gna-sap-cpi.md)
- [Mapping ERP-WMS](mapping-erp-wms.md)
- [Monitoring interface](interface-monitoring.md)
## Vue synthétique de l'interface ERP Limagrain
```mermaid
flowchart LR
subgraph SAP[SAP EWM]
ITM[ITM]
ASN[ASN]
ROR[ROR]
RUT[RUT]
SOR[SOR]
STR[STR]
SCR[SCR]
COR[COR]
CHG[CHG]
end
subgraph WMS[EasyWMS]
ROF[ROF]
REF[REF]
SOF[SOF]
LOF[LOF]
PCK[PCK]
MOV[MOV]
STV[STV]
STC[STC]
WSC[WSC]
LOC[LOC]
ERR[ERR]
end
SAP -->|ERP → WMS| WMS
WMS -->|WMS → ERP| SAP
```
> **21 messages** au total : 9 entrants (ERP → WMS), 11 sortants (WMS → ERP),
> 1 bidirectionnel (API Lot). Voir [Référence messages](messages-reference.md)
> pour le détail.
wiki/limagrain/06-erp-interface/donnees-principales.md
+225
View File
@@ -0,0 +1,225 @@
---
title: "Données principales et stock — Mapping ITM et attributs"
tags: [ERP, ITM, article, stock, attributs-logistiques, lot-SAP, mapping, CstAtt]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: ["Données principales + stock - LIMAGRAIN - DEV"]
sources: ["Données principales + stock - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Données principales et stock — Mapping ITM et attributs
> **Résumé** : architecture retenue pour la gestion des articles et du stock
> dans EasyWMS chez Limagrain, mapping du message ITM, attributs logistiques,
> profils et gestion des poids.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les décisions ci-dessous sont issues des ateliers d'interfaçage EasyWMS / SAP
réalisés entre le 05/01/2026 et le 23/02/2026, consolidées le 27/02/2026.
## Architecture retenue : Lot SAP = Article WMS
Le code article dans EasyWMS est le **code lot SAP** (et non le code produit
SAP). L'option concaténation code produit + lot SAP a été étudiée et écartée.
Le **code produit SAP** est géré comme un attribut au niveau du stock (pas de
la fiche article), car un même lot SAP peut correspondre à plusieurs produits
différents (ex. : changement de destination).
| Relation | Type | Statut |
|----------|------|--------|
| Lot SAP ↔ Lot Officiel | 1 pour 1 | ✅ Validé par Limagrain |
| Code article WMS = Code lot SAP | — | ✅ Validé |
| Code produit SAP = Attribut logistique du stock | — | ✅ Validé |
### Côté SAP
Il existe une base article avec des codes articles uniques. Les articles sont
gérés au lot. Chaque article peut avoir plusieurs codes lots SAP. Chaque code
lot SAP a un équivalent code lot OFFICIEL national (relation 1:1).
### Côté EasyWMS
Chaque lot SAP est descendu via le fichier ITM. L'article SAP devient un
attribut du lot SAP (et non l'inverse).
**Code article WMS = code lot SAP**
## Unité de base selon le type d'article
| Type article | Description | Unité de base WMS |
|--------------|-------------|-------------------|
| FERT | Produit fini | BAG (sac) |
| ZSIZ | Semi-fini calibré | KG |
L'unité de base dans le WMS est l'unité logistique (pas l'unité de base SAP).
Un même produit peut exister en BAG et en KG = codes articles WMS différents.
## Mapping fiche article (message ITM)
| Champ EasyWMS | Champ SAP | Remarque |
|---------------|-----------|----------|
| ItemCode | Code lot SAP | Clé principale |
| Alias | Lot officiel | Relation 1:1, scannable |
| OwnerCode | — | Constante "MECALUX" (technique) |
| Description | Description longue | Affichage PC |
| AltDescription | Description courte (MAKTL) | Affichage mobile, < 65 car. |
| Type | FERT / ZSIZ / etc. | + description du type |
| Family | Traitement commercial | Ex : "20 : R - Cruiser OSR" — pas de séparation familles en préparation |
| BaseUoM | BAG ou KG | Selon type d'article |
| Weight | Poids brut du sac | Poids unitaire théorique |
| ContainerQty | Nb sacs par palette | Palette pleine standard (= Bag/Pal) |
| ContainerType | Palette | Un seul type de palette |
| CstAtt02 | Espèce | Ex : M = Maïs, S = Tournesol — pour ordonnancement picking |
| CstAtt03 | Génération | Génération article rattachée au lot SAP |
| CstAtt04 | Variété | Ex : "LG50465" |
| CstAtt05 | Big bag | True / False |
| CstAtt06 | GTIN | Ne peut être un alias car non unique |
| CstAtt07 | Semences essais | True / False |
| CstAtt08 | Size (calibre) | — |
| CstAtt09 | Field production area | — |
| CstAtt10 | Stage | ⚠️ À ajouter — requis pour étiquette échantillon |
| Conversion.Principale.CstAtt01 | Poids unitaire article | Poids théorique ERP |
## Profils logistiques
| Type d'article | Profil | Description |
|----------------|--------|-------------|
| Articles classiques | PROFIL_STANDARD | Gestion code produit + propriétaire + description + pays destination |
| Palettes bois vides | PROFIL_PALETTE | Gestion palette bois vide |
## Attributs logistiques du stock
> **Décision du 11/02/2026** : les Custom Attributes au niveau du stock
> (CstAtt01–04) ont été **supprimés** au profit des attributs logistiques
> standards du WMS. Les modes de capture sont désactivés pour éviter la
> customisation de tous les écrans.
| Champ EasyWMS (balise API) | Libellé affiché WMS | Champ SAP | Remarque |
|----------------------------|---------------------|-----------|----------|
| Lot | Lot | Code produit SAP | Différencie les produits pour un même lot SAP |
| Color | Couleur | Code propriétaire SAP | ≠ "MECALUX" technique |
| Source | Source | Description courte SAP | Désignation courte |
| Size | Taille | Pays de destination | Peut changer en cours de vie du stock |
> ⚠️ Les noms de balises API (Color, Size…) ne correspondent pas aux données
> métier. Le renommage d'affichage est géré dans le WMS.
> **Point à tester** : en réception, la création du stock via les attributs
> logistiques doit être validée (approche standard ou custom — à confirmer
> par les tests).
## Gestion des codes clients / fournisseurs
La base client/fournisseur SAP **n'est pas interfacée** avec le WMS.
Les codes sont gérés via des constantes + champ texte libre :
| Flux | Champ code | Champ Source |
|------|------------|--------------|
| ROR Fournisseur | SupplierCode = "FOURNISSEUR" | Code fournisseur SAP + libellé |
| ROR Retour client | AccountCode = "CLIENT" | Code client SAP + libellé |
| SOR / RUT Client | AccountCode = "CLIENT" | Code client SAP + libellé |
| SOR Production | AccountCode = "PRODUCTION" | — |
## Gestion des poids
| Situation | Comportement ERP |
|-----------|-----------------|
| Article en BAG (UdM ≠ KG) | L'ERP ne s'intéresse qu'à la quantité de sacs — les écarts de poids sont ignorés |
| Article en KG | Seule la quantité en KG intéresse l'ERP — si le poids change (balance), le WMS modifie la quantité |
Le poids théorique de la ligne de stock (quantité × poids unitaire, hors
poids palette) est transmis via l'attribut logistique `Weight`.
## Champs NON utilisés dans ITM
Les champs suivants sont explicitement exclus du mapping :
Stock Label, Classification ABC, Alertes stock (min/max), Image produit,
Code danger (pas d'impact logistique), Températures min/max, Cross-docking,
Gerbabilité (gérée via ordonnancement picking), Picking message, IsPacking.
## Conversions
- Unité de base = BAG ou KG (pas de conversion supplémentaire identifiée)
- Pas de gestion financière ni de découpage dans les sacs
- Le nombre de sacs par palette pleine est géré dans la conversion container
(champ `ContainerQty`)
## Types de supports
| Type | Usage | Statut |
|------|-------|--------|
| EWM-PAL00 / PALETTE_US | Palette standard (un seul type) | ✅ Confirmé |
| BIGBAG | Attribut de la HU (pas type séparé) | ✅ Validé |
| Octobin | Hors périmètre phase 1 | ❌ |
La création de types de supports est techniquement lourde (nécessite passage
par support Mecalux, impact design entrepôt). Les BigBag sont déclarés par
l'opérateur au poste de réception. Le WMS ajuste le calcul de poids (+2 kg
environ).
## Z-Bags (sacs vides)
Stockés dans le magasin automatique (SRS) **uniquement pour livraison aux
clients**, pas pour l'approvisionnement production. Doivent respecter les
mêmes formats et règles que les palettes produits. → À valider
fonctionnellement.
## Paramètres généraux de l'interface
| Paramètre | Valeur |
|-----------|--------|
| Format | JSON |
| Opération par défaut | 3 = Upsert |
| Mode de mise à jour | Complete = true (fiche complète à chaque envoi) |
| OwnerCode (technique) | "MECALUX" |
| Site | WF02 |
## Points d'attention
⚠️ Le CstAtt10 (Stage) est **à ajouter** — il est requis pour l'étiquette
d'échantillonnage.
⚠️ Les noms de balises API stock (Color, Size, Source) sont détournés de
leur usage standard — ne pas confondre avec les concepts habituels.
⚠️ Les CstAtt au niveau du stock ont été supprimés (décision 11/02/2026)
au profit des attributs logistiques standards — vérifier l'impact sur les
développements en cours.
⚠️ Le mode Complete = true signifie que chaque ITM contient la fiche
complète (pas de delta) — attention à la volumétrie.
⚠️ La base client/fournisseur n'est pas interfacée : le code est descendu
dans chaque message ROR/SOR/RUT, pas maintenu en master data.
## Questions ouvertes
- [ ] CstAtt10 Stage — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
- [ ] Création stock via attributs logistiques en réception — standard ou
custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis page Confluence DEV |
| 2026-05-06 | Arthur | Ajout champs non utilisés, conversions, types supports, Z-Bags (CR consolidé) |
## Références
| Source | Type | Date |
|--------|------|------|
| Données principales + stock - LIMAGRAIN - DEV | Page Confluence | 27/02/2026 |
| Ateliers interfaçage EasyWMS/SAP | Ateliers | 05/01 → 23/02/2026 |
| Notes complémentaires 11/02/2026 | Note | 11/02/2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers | 23/02/2026 |
wiki/limagrain/06-erp-interface/gna-sap-cpi.md
+265
View File
@@ -0,0 +1,265 @@
---
title: "Intégration GNA → SAP-CPI"
tags: [ERP, GNA, SAP-CPI, OAuth, middleware, API, BOO]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: [LIM-89]
confluence_refs: []
sources:
- "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md"
- "recap_session_LIM-72_13-05-2026.md"
last_updated: 2026-05-13
author: Arthur
---
# Intégration GNA → SAP-CPI
> **Résumé** : mise en place de la communication entre le GNA (middleware
> EasyWMS) et SAP-CPI (middleware cloud SAP) pour l'envoi de tous les
> messages WMS sortants. Authentification OAuth 2.0 client_credentials,
> endpoint unique, routage par MessageType.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> L'intégration standard cible généralement un ERP via API REST classique
> (OAuth password grant). Chez Limagrain, la cible est **SAP-CPI** avec
> un mécanisme spécifique.
> Voir aussi : [LOC — Message périodique](loc-message-periodique.md),
> [Référence messages](messages-reference.md),
> [Mapping ERP-WMS](mapping-erp-wms.md)
## Contexte projet
Dans le cadre du projet Limagrain, le middleware GNA doit envoyer les
messages WMS vers SAP via la plateforme **SAP-CPI** (Cloud Platform
Integration). Une implémentation de référence existe chez un autre client
(AD) mais communique avec un ERP SAP-AIG via une API REST classique
(OAuth password grant).
L'intégration Limagrain est différente : elle cible **SAP-CPI** avec un
**endpoint unique** et une authentification **OAuth 2.0 client_credentials**.
## Architecture technique
### Script principal
Le script `CommonExportWebApi.boo` est le point d'entrée pour tous les
exports WMS → SAP-CPI. Il gère l'authentification, le formatage et
l'envoi des messages.
### Flux de communication
```mermaid
sequenceDiagram
participant WMS as EasyWMS
participant GNA as GNA (BOO)
participant OAuth as SAP OAuth Server
participant CPI as SAP-CPI
WMS->>GNA: Transaction WMS (LOC.SEND, REF01, etc.)
GNA->>GNA: Vérifier cache token
alt Token expiré ou absent
GNA->>OAuth: POST /oauth/token (client_credentials)
OAuth-->>GNA: Bearer token + expiration
GNA->>GNA: Sauvegarder token sur disque
end
GNA->>CPI: POST /http/ATHInboundMessage
Note right of CPI: Body: {MessageType, MessageSAP, data}
CPI-->>GNA: HTTP 200 / erreur
alt Erreur HTTP (hors 401)
GNA->>CPI: Retry backoff (2s, 4s, 8s, 16s)
end
alt HTTP 401
GNA->>GNA: Échec immédiat (token invalide)
end
```
## Authentification OAuth 2.0
### Mécanisme
1. Le GNA obtient un **token bearer** auprès du serveur SAP via un POST
sur `/oauth/token` avec `client_id` et `client_secret`
2. Le grant type est `client_credentials` (pas de password grant)
3. Le token est **mis en cache sur disque** (fichier JSON) avec gestion
de l'expiration (marge de sécurité de 60 secondes)
4. À chaque envoi, le GNA vérifie le cache : si le token est encore valide,
il le réutilise ; sinon il en demande un nouveau
## Envoi des messages — Format du body
Pour chaque message WMS exporté, le GNA envoie un POST vers l'endpoint
unique SAP-CPI `/http/ATHInboundMessage` avec le body JSON suivant :
```json
{
"MessageType": "<type_message_WMS>",
"MessageSAP": "<code_CPI>",
"data": "<contenu_message>"
}
```
Le champ `MessageType` permet au iFlow CPI de **router le message** vers
le bon traitement SAP.
## Table de correspondance MessageType → MessageSAP
Le champ `MessageSAP` est déterminé par une table de correspondance entre
le préfixe du MessageType WMS (3 premiers caractères) et le code SAP-CPI :
| Code CPI | Équivalent WMS | Description |
|----------|----------------|-------------|
| ATH214 | Check flux retour (batch) | Vérification lot retour client |
| ATH215 | REF (type = Supplier) | Finalisation réception fournisseur |
| ATH217 | REF (type = Return) | Finalisation réception retour |
| ATH201 | LOC | Message périodique delta mouvements |
| ATH202 | LOF | Finalisation chargement |
> ⚠️ Si un type de message n'a pas de correspondance dans la table, un
> **warning** est logué et le champ MessageSAP n'est pas inclus dans le
> body.
### Détermination conditionnelle du MessageSAP pour REF
Le message REF peut être routé vers **ATH215** (Supplier) ou **ATH217**
(Return) selon le type de préavis de réception (InboundOrder) lié :
1. Le **REF01Observer.boo** récupère le type de préavis via une requête
LINQ sur `Context.RecLineInboundOrderLines` → `Context.InboundOrders`
2. Le type est transmis dans le champ `RecCustomAttributes.CstAtt20` du
message REF01
3. Le script `CommonExportWebApi.boo` lit `CstAtt20` dans le payload JSON
pour déterminer le `MessageSAP` :
- Type Supplier → `ATH215`
- Type Return → `ATH217`
## Cartographie complète des interfaces Athenzat
Tous les flux entre SAP et EasyWMS sont identifiés par un code ATH.
Source : doc CPI Maxime Tourrette (24/04/2026) + mail S15 Justine.
### Flux SAP → EasyWMS (entrants)
| Code ATH | Type SAP | Type Easy | Description |
|----------|----------|-----------|-------------|
| ATH002 | BATMAS | ITM01 | Fiche article (Item) |
| ATH103A | DELIVRY07 | ROR01 | Ordre de réception (Inbound delivery) |
| ATH108 | ORDRSP | ROR01 | Ordre de réception retour (Return delivery) |
| ATH103B | SHPUNT7 | RUT | Ordre de sortie (Outbound delivery) |
| ATH102BOM | LOIPRO | SOR | Ordre d'expédition (Shipping order) |
| ATH111 | ZSTKATH11 | ASN / STR | HU à recevoir / HU change |
| ATH302 | ZQMINSPLOT | COR | Tâche inventaire / échantillon |
### Flux EasyWMS → SAP (sortants via CPI)
| Code ATH | Type Easy | Type SAP | Description |
|----------|-----------|----------|-------------|
| ATH214 | Z_IATH214 | Z_IAT214 | Check Batch (vérification lot retour) |
| ATH215 | REF | Z_IAT215 | Bon de réception fournisseur |
| ATH217 | REF | Z_IAT217 | Bon de réception retour |
| ATH201 | LOC / STV | Z_IAT201 | Mouvement stock (rangement ASRS, mvt HU, prep mix, customer flag, stock adjust) |
| ATH202 | LOF | Z_IAT202 | Chargement (Loading / Goods Issue) |
> **Note** : les flux ATH103A/B, ATH108, ATH111, ATH302 utilisent
> l'infrastructure GNA standard (pas de custom CPI côté EasyWMS).
> Seuls les flux sortants (ATH2xx) passent par `CommonExportWebApi.boo`.
> **Note** : le flux ATH214 est le seul appelé **directement depuis un
> workflow** (pas via GNA/BOO). Voir [Réception retour](../01-inbound/reception-retour.md).
## Gestion des erreurs — Retry avec backoff
| Situation | Comportement |
|-----------|-------------|
| HTTP 200 | Succès — message envoyé |
| HTTP 401 | **Échec immédiat** — token invalide, pas de retry |
| Autre erreur HTTP | **Retry backoff exponentiel** : 2s → 4s → 8s → 16s |
## Configuration requise
Six clés `CPI_*` à ajouter dans `CommonAppSettings.config`
(section `appSettings`) :
| Clé | Description |
|-----|-------------|
| CPI_AUTH_URL | URL du serveur d'authentification SAP OAuth |
| CPI_CLIENT_ID | Identifiant OAuth |
| CPI_CLIENT_SECRET | Secret OAuth (en clair dans le config) |
| CPI_ENDPOINT_URL | Endpoint unique SAP-CPI (`/http/ATHInboundMessage`) |
| CPI_TOKEN_PATH | Chemin du fichier cache token sur disque |
| CPI_TIMEOUT | Timeout HTTP en secondes (auth + messages) |
**Valeurs environnement TEST** :
- `CPI_AUTH_URL` :
`https://vilm-cpi-test-73ltxp48.authentication.eu30.hana.ondemand.com/oauth/token`
- `CPI_ENDPOINT_URL` :
`https://vilm-cpi-test-73ltxp48.it-cpi020-rt.cfapps.eu30.hana.ondemand.com/http/ATHInboundMessage`
- Environnement PROD : URLs à définir
## Fichiers impactés
| Fichier | Modification |
|---------|-------------|
| `Scripts2015/CommonExportWebApi.boo` | Script principal d'export WMS → SAP-CPI |
| `Scripts2015/EasyWMS/XML/REF01/REF01Observer.boo` | Ajout requête InboundOrderType + écriture CstAtt20 |
| `Configuration/LIMAGRAI2512/CommonAppSettings.config` | Ajout des 6 clés CPI_* |
## Logging
Chaque étape (connexion, récupération token, envoi message) doit être
loguée avec les détails de la requête et de la réponse. Le body JSON
est logué en **format indenté** pour faciliter le debug.
> ⚠️ Le **token ne doit jamais être logué** (sécurité).
## Cas de tests
- [ ] Le GNA compile sans erreur
- [ ] L'authentification OAuth client_credentials fonctionne (HTTP 200)
- [ ] Le token est mis en cache sur disque et réutilisé tant qu'il est
valide
- [ ] Les messages WMS sont envoyés en POST avec le bon format JSON
- [ ] Le champ MessageSAP est présent avec la bonne valeur selon le type
- [ ] REF type Supplier → MessageSAP = ATH215
- [ ] REF type Return → MessageSAP = ATH217
- [ ] CstAtt20 renseigné dans le message REF01 par le REF01Observer
- [ ] Warning logué si MessageType sans correspondance
- [ ] Retry backoff fonctionne (hors 401)
- [ ] Logs détaillés et lisibles (JSON indenté, token masqué)
- [ ] HTTP 401 → échec immédiat sans retry
## Points d'attention
⚠️ Le **secret OAuth est en clair** dans le fichier de configuration —
accès au fichier à restreindre.
⚠️ La marge de 60 secondes sur l'expiration du token évite les races
conditions mais peut générer des re-authentifications prématurées sous
forte charge.
⚠️ Le backoff exponentiel plafonne à 16 secondes — si SAP-CPI est
durablement indisponible, les messages seront perdus (pas de file
d'attente persistante).
## Questions ouvertes
- [ ] Faut-il implémenter une file d'attente persistante pour les
messages en échec après 4 retries ? (@Nicolas)
- [ ] Le secret OAuth doit-il être chiffré dans le config ?
(@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-12 | Arthur | Création depuis LIM-89 |
| 2026-05-13 | Arthur | Ajout cartographie ATH complète, URLs TEST, note ATH214 hors GNA |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-89](https://easywmsfrance.atlassian.net/browse/LIM-89) | Ticket Jira | 2026 |
| Athenzat SAP-CPI Webservices Documentation v1.0 | PDF (Maxime Tourrette) | 2026-04-24 |
| Mail Justine S15 | Cartographie interfaces | 2026-04 |
wiki/limagrain/06-erp-interface/loc-message-periodique.md
+494
View File
@@ -0,0 +1,494 @@
---
title: "LOC — Message périodique (spécification complète)"
tags: [ERP, LOC, custom, delta, mouvement, stock, JSON, SAP, GNA]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: [LIM-76]
confluence_refs: []
sources:
- "LOC - Etat des lieux V2.md"
- "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"
- "LIM-76 LOT1.2 [GNA] Message LOC.md"
last_updated: 2026-05-12
author: Arthur
---
# LOC — Message périodique (spécification complète)
> **Résumé** : spécification du message custom LOC, envoyé du WMS vers SAP
> toutes les 5 minutes via le GNA, contenant le delta des HU modifiées.
> Le LOC remplace les messages PCK, MOVE, STV et STC et devient le **seul
> canal** de notification des mouvements de stock vers SAP.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce message est un **[CUSTOM]** — il n'existe pas dans le standard EasyWMS.
> Voir aussi : [Référence messages](messages-reference.md),
> [Flux ERP outbound](../04-outbound/flux-erp-outbound.md),
> [Intégration GNA → SAP-CPI](gna-sap-cpi.md)
## Contexte projet
Le LOC est un message custom envoyé du WMS vers SAP **toutes les 5 minutes**
(✅ reconfirmé le 30/04/2026), contenant l'état de toutes les HU ayant subi
une modification durant la période écoulée.
Il **remplace** les messages PCK et MOVE (supprimés) et centralise la
communication des mouvements physiques vers l'ERP. Le LOC ne transmet pas
l'intégralité de la base, uniquement le **delta sur la fenêtre de 5 minutes**
(basé sur la `CreationDate` des transactions WMS).
### Pourquoi le LOC plutôt que des STV purs ?
Limagrain (Nicolas Sanchez) a exprimé que les STV en delta (+/-)
ne sont **pas fiables** : si un message se perd ou est mal intégré, l'écart
est définitivement perdu. Limagrain souhaite recevoir des **quantités
absolues** que SAP prend pour argent comptant et compare à ses propres
données pour générer les écritures de delta.
Le LOC est un **fork fonctionnel du WSC** (Warehouse Stock Count) adapté
pour ne remonter que le delta des 5 dernières minutes, formaté selon un
JSON spécifique attendu par SAP.
### Décisions structurantes
- **STV désactivé** (post-processing coupé) — le LOC devient le **seul canal**
de notification des mouvements de stock vers SAP
- **STC désactivé** — les changements de statut hors retour sont limités au
B6 (blocage logistique) et sont couverts par le LOC (action R/U).
Les statuts des retours sont remontés dans le REF
## Architecture technique
### Chaîne de traitement
```
Job (toutes les 5 min) → Workflow → Transaction custom LOC.SEND → GNA →
Script BOO (requêtes WMS + agrégation + formatage JSON) → POST API SAP
```
### Côté WMS
1. Un **Job** s'exécute toutes les 5 minutes
2. Ce job appelle un **Workflow custom** dont le seul rôle est de **créer
une transaction custom** `LOC.SEND`
3. Le Workflow et la transaction ne portent aucune logique métier côté WMS —
toute la logique est dans le GNA
### Côté GNA
1. Un **script BOO** dédié au message LOC est créé dans le GNA
2. Le GNA détecte la transaction custom `LOC.SEND`
3. À réception, le script BOO :
- Collecte toutes les transactions WMS pertinentes sur le delta de temps
- Agrège les données par HU et détermine le code ACTION pour chaque
mouvement
- Construit le JSON au format attendu par SAP
- Effectue un **appel POST** vers l'API SAP-CPI (voir
[Intégration GNA → SAP-CPI](gna-sap-cpi.md))
### Détection du delta
1. À chaque exécution, enregistrer un timestamp de dernière exécution
2. Récupérer toutes les transactions dont `CreationDate > dernier_timestamp`
et `CreationDate ≤ timestamp_courant`
3. Agréger par HU, déterminer le code ACTION pour chaque mouvement
4. Générer le JSON et envoyer
5. **Si aucune transaction pertinente sur le delta → pas d'envoi de LOC**
## Couverture fonctionnelle — 7 codes ACTION
| Code | Signification | Déclencheur |
|------|---------------|-------------|
| **B** | Déplacement bin-to-bin | Déplacement de HU d'une zone à une autre |
| **U** | Set to Unrestricted (déblocage) | Déblocage statut B6 |
| **R** | Set to Restricted (blocage) | Blocage statut B6 |
| **S** | Scrap quantity (suppression) | Suppression de stock / support |
| **T** | Transfert inter-HU | Transfert de quantité entre deux HU |
| **C** | Correction de poids | Ajustement de quantité (valeur absolue) |
| **P** | Assignation client | Palette positionnée sur image de quai |
### Palettes exclues du LOC
**Exclure les palettes liées à une réception non fermée** (= dont le REF
n'a pas encore été envoyé). Seules les HU déjà connues de SAP via un REF
préalable doivent apparaître dans le LOC.
## Format JSON attendu par SAP
### Paramètres d'import
| Réf. | Champ | Type | Description |
|------|-------|------|-------------|
| 1 | IV_LGNUM | CHAR 4 | Numéro d'entrepôt (valeur fixe : `"WF02"`) — config EasyS |
| 2 | IV_TREATMENT_ID | CHAR 24 | Horodatage de génération du LOC |
### Structure JSON
```json
{
"IV_LGNUM": "WF02",
"IV_TREATMENT_ID": "<HORODATAGE_GENERATION_LOC>",
"IT_CREATE": [
{
"MATNR": "<CODE_PRODUIT_SAP>",
"BATCHID": "<LOT_SAP>",
"ACTION": "<CODE_ACTION>",
"ANFME": "<QUANTITE_OU_VIDE>",
"ALTME": "<UDM_OU_VIDE>",
"VLPLA": "<ZONE_STOCKAGE_ORIGINE>",
"NLPLA": "<ZONE_STOCKAGE_DESTINATION>",
"VLENR": "<CODE_SUPPORT_ORIGINE>",
"NLENR": "<CODE_SUPPORT_DESTINATION>",
"REASON": "<CODE_RAISON_OU_VIDE>",
"VBELN": "<CODE_LIVRAISON_OU_VIDE>",
"POSNR": "<LIGNE_LIVRAISON_OU_VIDE>"
}
]
}
```
### Table IT_CREATE — Champs (1:n)
| Réf. | Champ | Type | Description |
|------|-------|------|-------------|
| 1 | MATNR | CHAR 40 | Code produit SAP — vide si action B ou P |
| 2 | BATCHID | CHAR 10 | Code lot SAP — vide si action B ou P |
| 3 | ACTION | CHAR 1 | Code action : B, U, R, S, T, C, P |
| 4 | ANFME | NUM 13.3 | Quantité (absolue ou transférée selon action) — vide si B, U/R, P |
| 5 | ALTME | CHAR 3 | Unité de mesure (BAG, KG) — vide si action B ou P |
| 6 | VLPLA | CHAR 18 | Zone de stockage origine |
| 7 | NLPLA | CHAR 18 | Zone de stockage destination |
| 8 | VLENR | CHAR 20 | Code HU (palette) source — SSCC |
| 9 | NLENR | CHAR 20 | Code HU (palette) destination — SSCC |
| 10 | REASON | CHAR 4 | Code raison scrap — uniquement pour action S (ZSC1) |
| 11 | VBELN | — | Code livraison sortante SAP — uniquement pour action P |
| 12 | POSNR | — | Ligne de livraison sortante SAP — uniquement pour action P |
### Données stock/container à récupérer par ligne LOC
Pour chaque HU identifiée dans les transactions du delta :
- **Code produit SAP** : attribut logistique LotCode du stock
- **Code lot SAP** : ItemCode du stock (= code article WMS)
- **Quantité** : quantité actuelle de la ligne de stock (UdM de base WMS =
unité alternative SAP)
- **UdM** : BAG ou KG
- **Zone de stockage** : zone WMS du container (origine et destination)
- **Code support** : ContainerCode (SSCC)
- **Code livraison sortante** : ShippingOrderCode si action P
## Règles de remplissage par action
| Champ | B (déplacement) | U/R (statut) | S (suppression) | T (transfert) | C (correction) | P (assignation) |
|-------|-----------------|--------------|-----------------|---------------|----------------|-----------------|
| MATNR | Vide | Code produit | Code produit | Code produit | Code produit | Vide |
| BATCHID | Vide | Lot SAP | Lot SAP | Lot SAP | Lot SAP | Vide |
| ACTION | B | U ou R | S | T | C | P |
| ANFME | Vide | Vide | Qté supprimée | Qté transférée | Qté absolue | Vide |
| ALTME | Vide | UdM | UdM | UdM | UdM | Vide |
| VLPLA | Zone origine | Zone actuelle | Zone actuelle | Zone HU source | Zone actuelle | Vide |
| NLPLA | Zone destination | Vide | Vide | Zone HU dest. | Vide | Image de quai |
| VLENR | Code HU | Code HU | Code HU | Code HU source | Code HU | Code HU |
| NLENR | Vide | Vide | Vide | Code HU dest. | Vide | Vide |
| REASON | Vide | Vide | ZSC1 | Vide | Vide | Vide |
| VBELN | Vide | Vide | Vide | Vide | Vide | Code livraison |
| POSNR | Vide | Vide | Vide | Vide | Vide | Ligne livraison |
## Règles métier par type d'action
### ACTION = B (Déplacement bin-to-bin)
Déplacement de HU d'une zone à une autre. **Pas de quantité, pas de code
article, pas de lot** — seuls les champs zone et support sont renseignés.
Le contenu de la HU n'est pas rediscuté.
### ACTION = U / R (Déblocage / Blocage statut)
Hors flux retour, le seul statut autorisé est le **B6** (blocage
logistique). ACTION=R pour bloquer, ACTION=U pour débloquer.
Les statuts exotiques des retours (B6, F2, F9, etc.) sont gérés dans
le **REF** de la réception retour, pas dans le LOC.
### ACTION = S (Suppression / Scrap)
REASON est renseigné **uniquement** pour cette action. Valeur : `ZSC1`
(scrapping normal). Pas d'autre valeur possible.
### ACTION = T (Transfert inter-HU)
Source et destination **dans la même ligne** (VLENR + NLENR). ANFME =
quantité transférée (pas le solde restant).
Si le transfert passe par une étape intermédiaire (table de travail),
transmettre chaque étape séparément avec un emplacement matérialisé.
**Cas picking** : 5 tâches alimentant la même palette fille = 5 lignes
ACTION=T dans le même LOC, dans l'ordre chronologique.
**Création de palette au picking** : si le SSCC en NLENR est inconnu de
SAP, SAP crée automatiquement la HU (type palette standard). Le LOC ne
crée que la structure palette — le stock est transféré depuis une palette
source connue.
### ACTION = C (Correction de quantité)
Quantité **absolue** comptée/validée (pas un écart). SAP calcule le
delta. REASON n'est pas renseigné.
### ACTION = P (Assignation client)
Déclencheur : palette physiquement positionnée sur l'**image de quai**
(pas l'assignation logique). Champs obligatoires :
- ACTION = P
- VLENR = Code HU
- NLPLA = Image de quai de la HU
- VBELN = Code livraison sortante SAP (= SorCode côté WMS)
- POSNR = Ligne de livraison sortante SAP (= ligne d'OS associée à
l'article)
Les champs MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON sont
**vides** pour cette action.
## Transactions WMS sources
| Transaction WMS | Action LOC | Données à récupérer |
|-----------------|------------|---------------------|
| CON.MOVE | **B** (déplacement) | ContainerCode, zone origine, zone destination |
| CON.LOCATE | **B** (déplacement) | Idem |
| STK.MOVE | **B** ou **T** | ContainerCode source et dest. Si ContainerTo ≠ ContainerCode → T avec qté transférée |
| STK.ADJ | **C** (correction) | ContainerCode, quantité absolue actuelle après ajustement, UdM |
| CST.STK | **U** ou **R** | ContainerCode, nouveau statut (B6 uniquement hors retour) |
| STK.PICKING | **T** (transfert) | Container source, container destination (palette fille), qté transférée |
| CON.DELETE | **S** (suppression) | ContainerCode, quantité supprimée |
> ⚠️ Vérifier si d'autres transactions sont utiles pour le LOC
> (ex. STK.SCR pour le scrap depuis RF).
## Zones de stockage (VLPLA / NLPLA)
Les codes zone WMS ne correspondent pas directement aux codes emplacement
SAP. Une **table de correspondance** est nécessaire, réalisée via un
paramètre EasyS (ex : `[TK_5_A:TK_5][TK_5_B:TK_5]`).
### Zones attendues par SAP
| Zone SAP | Correspondance WMS |
|----------|--------------------|
| ASRS1 | TK1 (compartiment anoxie) |
| ASRS2 | TK2 (compartiment du milieu) |
| ASRS3 | Zone accessible du TK3 uniquement (grand compartiment) |
| ASRS4 | Zone accessible du TK4 uniquement (grand compartiment) |
| ASRS34 | Zone accessible des deux TK3 et TK4 (grand compartiment) |
| PICKING | Si présent sur un PK/TP |
| QUAI | Si présent sur un emplacement d'image de quai ou sur le quai |
## Horodatage (IV_TREATMENT_ID)
IV_TREATMENT_ID = horodatage du moment de **génération du LOC** (pas
l'heure de chaque transaction individuelle). Toutes les lignes d'un
même LOC partagent le même horodatage.
Format : `YYYYMMDD` — limité à 24 caractères (CHAR 24).
## Ordre des lignes
Les lignes dans IT_CREATE doivent être dans l'**ordre chronologique**
des transactions WMS. SAP traite les lignes dans l'ordre du fichier.
## Contraintes de longueur
| Champ | Type | Longueur max |
|-------|------|--------------|
| IV_LGNUM | CHAR | 4 |
| IV_TREATMENT_ID | CHAR | 24 |
| MATNR | CHAR | 40 |
| BATCHID | CHAR | 10 |
| ACTION | CHAR | 1 |
| ANFME | NUM | 13.3 (13 entiers, 3 décimales) |
| ALTME | CHAR | 3 |
| VLPLA | CHAR | 18 |
| NLPLA | CHAR | 18 |
| VLENR | CHAR | 20 |
| NLENR | CHAR | 20 |
| REASON | CHAR | 4 |
## Désactivation STV et STC
### STV
Désactiver le post-processing des transactions STK.ADJ → plus de
génération de message STV. Le LOC couvre ce besoin via ACTION=C.
**Vérifications préalables obligatoires :**
- Lister toutes les transactions qui génèrent un STV et confirmer que le
LOC couvre chaque cas
- Vérifier que le middleware GNA n'a pas d'autre dépendance au STV
### STC
Désactiver le post-processing des transactions CST.STK → plus de
génération de message STC. Le LOC couvre le B6 via ACTION=R/U.
Mêmes vérifications à effectuer que pour le STV. Documenter les
résultats de cette analyse dans un commentaire de la tâche avant de
procéder à la désactivation.
## Critères d'acceptation
1. Un job WMS tourne toutes les 5 minutes et crée une transaction custom
LOC.SEND
2. Le GNA détecte cette transaction et génère un JSON LOC conforme
3. Le JSON est envoyé en POST à l'endpoint SAP
4. Les 7 codes ACTION (B, U, R, S, T, C, P) sont correctement générés
5. ACTION=B : ANFME, ALTME, MATNR, BATCHID, NLENR, REASON, VBELN, POSNR
vides — seuls VLPLA, NLPLA et VLENR renseignés
6. ACTION=U/R : MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés —
ANFME, NLPLA, NLENR, REASON, VBELN, POSNR vides
7. ACTION=S : REASON=ZSC1 — MATNR, BATCHID, ANFME, ALTME, VLPLA, VLENR
renseignés — NLPLA, NLENR, VBELN, POSNR vides
8. ACTION=T : VLENR et NLENR dans la même ligne — ANFME = qté transférée
(pas un solde) — REASON, VBELN, POSNR vides
9. ACTION=C : ANFME = quantité absolue (pas un delta) — NLPLA, NLENR,
REASON, VBELN, POSNR vides
10. ACTION=P : VLENR, NLPLA (image de quai), VBELN, POSNR renseignés —
MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON vides
11. Palettes liées à une réception non fermée (pas de REF envoyé) exclues
12. Lignes dans IT_CREATE dans l'ordre chronologique des transactions WMS
13. IV_TREATMENT_ID = horodatage de génération (CHAR 24)
14. Aucune transaction pertinente sur le delta → pas d'envoi de LOC
15. Contraintes de longueur respectées sur tous les champs
16. STV et STC désactivés après validation de l'analyse d'impact
17. Picking N tâches → N lignes ACTION=T dans l'ordre chronologique
18. SSCC inconnu en NLENR lors d'un ACTION=T → LOC ne bloque pas, SAP
crée la HU automatiquement
## Cas de tests
### Architecture et Job
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-01 | 1 | Déclenchement job toutes les 5 min | 3 transactions LOC.SEND en 15 min |
| CT-02 | 2,3 | GNA détecte LOC.SEND et génère JSON | JSON conforme + POST HTTP 200 |
| CT-03 | 14 | Aucune transaction sur le delta | Aucun POST vers SAP |
### ACTION=B — Déplacement
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-10 | 4,5 | Déplacement via CON.MOVE | ACTION=B, seuls VLPLA/NLPLA/VLENR renseignés |
| CT-11 | 4,5 | Déplacement via CON.LOCATE | Idem CT-10 |
| CT-12 | 4,5 | STK.MOVE sans changement HU (ContainerTo=ContainerCode) | ACTION=B (pas T) |
### ACTION=U/R — Blocage / Déblocage
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-20 | 4,6 | Blocage HU via CST.STK (→ B6) | ACTION=R, MATNR/BATCHID/ALTME/VLPLA/VLENR renseignés |
| CT-21 | 4,6 | Déblocage HU via CST.STK (← B6) | ACTION=U |
| CT-22 | 6 | Changement statut hors B6 (hors retour) | Aucune ligne dans le LOC |
### ACTION=S — Suppression / Scrap
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-30 | 4,7 | CON.DELETE sur une HU | ACTION=S, REASON=ZSC1, qté et champs stock renseignés |
| CT-31 | 7 | Plusieurs suppressions | Chaque ligne S a REASON=ZSC1 uniquement |
### ACTION=T — Transfert inter-HU
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-40 | 4,8 | STK.MOVE avec ContainerTo ≠ ContainerCode | ACTION=T, VLENR+NLENR+ANFME renseignés |
| CT-41 | 4,8 | STK.PICKING | ACTION=T, ANFME = qté transférée (pas solde) |
| CT-42 | 17 | 3 pickings → même palette fille | 3 lignes T dans l'ordre chronologique |
| CT-43 | 18 | Picking vers SSCC inconnu SAP | Ligne T générée, LOC ne bloque pas |
| CT-44 | 8 | Transfert via table de travail | 2 lignes distinctes (pas de fusion) |
### ACTION=C — Correction de quantité
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-50 | 4,9 | STK.ADJ (ajustement) | ACTION=C, ANFME = qté absolue après ajustement |
| CT-51 | 9 | Vérification REASON vide | REASON vide pour action C |
### ACTION=P — Assignation client
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-60 | 4,10 | Palette sur image de quai | ACTION=P, VLENR/NLPLA/VBELN/POSNR renseignés |
| CT-61 | 10 | Champs vides vérifiés | MATNR/BATCHID/ANFME/ALTME/VLPLA/NLENR/REASON vides |
### Filtre d'exclusion
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-70 | 11 | HU réception non fermée (pas de REF) | Aucune ligne dans le LOC |
| CT-71 | 11 | HU réception fermée (REF envoyé) | Ligne présente dans le LOC |
### Ordre chronologique et horodatage
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-80 | 12 | 3 transactions dans l'ordre | Lignes dans l'ordre chronologique |
| CT-81 | 13 | IV_TREATMENT_ID | Horodatage de génération, ≤ 24 car. |
### Contraintes de longueur et cas combinés
| CT | CA | Description | Résultat attendu |
|----|-----|-------------|------------------|
| CT-90 | 15 | Valeurs aux limites de longueur | JSON sans troncature |
| CT-91 | 15 | ANFME avec décimales | Format NUM 13.3 respecté |
| CT-100 | 16 | STK.ADJ après désactivation STV | Pas de STV, LOC contient ACTION=C |
| CT-101 | 16 | CST.STK après désactivation STC | Pas de STC, LOC contient ACTION=R |
| CT-110 | 4,12 | Plusieurs actions dans le même delta | 4 lignes, 4 actions, ordre chronologique |
| CT-111 | 2 | IV_LGNUM | Toujours "WF02" |
| CT-112 | — | HU multi-lignes de stock | Plusieurs entrées dans IT_CREATE |
## Points d'attention
⚠️ **STV et STC désactivés** — vérifier qu'aucun autre process métier ne
dépend d'eux (middleware GNA, reporting).
⚠️ Le filtrage GNA des STV avec motif "STR" devient caduc si le STV est
globalement désactivé.
⚠️ Le LOC ne doit jamais transmettre de palettes dont la réception n'est
pas fermée (pas de REF envoyé).
⚠️ Pour ACTION=B, les champs MATNR, BATCHID, ANFME, ALTME sont tous vides.
⚠️ Les quantités sont des valeurs **absolues** sauf pour ACTION=S (quantité
supprimée) et ACTION=T (quantité transférée).
⚠️ IV_LGNUM = `"WF02"` (pas "WL02" — corrigé depuis spec V2).
## Questions ouvertes
- [ ] Cas palette déposée sur image de quai → chargée → OS fermé →
LOF/SOF envoyé avant le LOC : la HU ne sera pas mentionnée dans le LOC
(@Limagrain)
- [ ] HU multi-lignes de stock : comportement exact à confirmer (CT-112)
(@Fabien)
- [ ] Vérifier si d'autres transactions WMS sont utiles pour le LOC
(ex. STK.SCR) (@Fabien)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-06 | Arthur | Création depuis spec LOC V2 (réunion 30/04/2026) |
| 2026-05-12 | Arthur | Refonte complète depuis LIM-76 : architecture technique GNA/BOO, ACTION=P confirmé avec VBELN/POSNR, IV_LGNUM corrigé WF02, zones SAP détaillées, contraintes de longueur, 25+ cas de tests, critères d'acceptation |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76) | Ticket Jira (LOT 1.2) | 2026 |
| LOC - Etat des lieux V2 | Spécification technique | 30/04/2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
| Réunion LOC 30/04/2026 | Réunion Arthur + Justine + Nicolas | 30/04/2026 |
wiki/limagrain/06-erp-interface/mapping-erp-wms.md
+173
View File
@@ -0,0 +1,173 @@
---
title: "Mapping ERP-WMS — Changement article et propriétaire"
tags: [ERP, mapping, CHG, STR, article, propriétaire, custom]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Mapping ERP-WMS — Changement article et propriétaire
> **Résumé** : processus [CUSTOM] de changement d'article et de propriétaire
> en cours de vie du stock, via message CHG.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
> Voir aussi : [Données principales et stock](donnees-principales.md) pour
> le mapping complet ITM, attributs logistiques et architecture article/lot.
## Contexte projet
Chez Limagrain, l'article (numéro, description et destination) et le
propriétaire peuvent être modifiés en cours de vie du stock. Ces changements
sont notifiés par un message CHG descendant de SAP vers EasyWMS.
Le message standard STR (Stock Transfer Request) est aussi utilisé pour
les demandes de changement de statut de stock.
## Message STR — Demande de Changement de Stock
### Cas d'usage
L'ERP envoie un STR pour :
- Changement de code article (produit SAP + description)
- Changement de propriétaire
- Blocage/déblocage de lot
### Règles d'acceptation
- **Accepté** si la palette n'est pas assignée à une commande ou en cours
de mouvement
- **Refusé** si palette "client" ou en préparation → code erreur API explicite
(ERR renvoyé à SAP)
### Interaction STV/GNA
L'ajustement de stock avec motif "STR" est filtré par le middleware GNA
(pas de retraitement STV pour éviter les doublons). Ce mécanisme devient
caduc si le STV est globalement désactivé (décision 30/04/2026).
### Monitoring
Limagrain mettra en place un **monitoring des erreurs** STR pour les cas
de refus. Les refus sont attendus en fonctionnement normal (palette en
cours de préparation au moment du STR).
## Message CHG — Changement article / propriétaire
### Contenu du message
| Champ | Description | Modifié si |
|-------|-------------|------------|
| Numéro de HU | Identifiant palette | Toujours présent |
| Lot Officiel | Lot de référence | Toujours présent |
| Code nouvel article | Nouveau code article | Changement article |
| Description nouvel article | Libellé | Changement article |
| Destination | Nouvelle destination | Changement article |
| Propriétaire Limagrain | Nouveau propriétaire | Changement propriétaire |
### Contrainte d'exécution
Le changement ne peut avoir lieu **que si le stock n'est pas assigné à
un processus** (picking, expédition, regroupement, etc.).
Si le stock est assigné → le message CHG génère un message **ERR** pour
informer SAP que le changement est impossible.
## Statut de stock
### Changement sur poste de travail
[CUSTOM] L'utilisateur peut changer le statut du stock sur le poste de
travail **uniquement** lors du processus de **retour commandes clients**,
pour appliquer :
- **F9** — Sacs sales
- **B6** — Non conforme
Un commentaire est associé au statut et remonté dans le message d'interface
(STC) pour informer l'ERP.
### Attributs du statut de stock
[CUSTOM] 3 attributs relatifs au statut de stock chez Limagrain :
1. **Statut de stock** : valeur du statut (ex : F9, B6)
2. **Commentaire** : raison du changement (liste déroulante contextuelle)
3. **Date de changement** : horodatage automatique
Les commentaires sont présentés sous une liste déroulante avec les
possibilités dépendant du statut sélectionné.
### Autonomie Limagrain
Limagrain peut créer ses propres statuts de stock :
- Menu « Données principales » → « Types de verrous » → « Statut de stock »
- Bouton « Nouveau » → remplir les champs requis
## Diagramme de séquence — Changement article
```mermaid
sequenceDiagram
participant SAP
participant WMS as EasyWMS
SAP->>WMS: CHG (nouveau code article, description, destination)
alt Stock non assigné
WMS->>WMS: MAJ article sur les lignes de stock
Note over WMS: Pas de confirmation retour
else Stock assigné à un processus
WMS->>SAP: ERR (changement impossible)
end
```
## Diagramme de séquence — Changement statut (retour client)
```mermaid
sequenceDiagram
participant OP as Opérateur
participant WMS as EasyWMS
participant SAP
OP->>WMS: Changement statut (F9 ou B6) + commentaire
WMS->>WMS: MAJ statut ligne de stock
WMS->>SAP: STC (notification changement statut)
```
## Points d'attention
⚠️ Le CHG ne renvoie pas de confirmation positive — seule l'erreur (ERR)
est remontée si le changement échoue.
⚠️ Le changement de statut sur poste est limité au processus retour client
(pas en picking ni en regroupement).
⚠️ Le message STR (standard) est aussi utilisé pour des demandes de
changement de statut initiées par SAP.
## Questions ouvertes
- [ ] Liste exhaustive des statuts de stock Limagrain prévus au démarrage (@Justine)
- [ ] Liste des commentaires par statut — validée ? (@Justine)
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas d'échec ? (@Nicolas)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-06 | Arthur | Ajout section STR détaillée (CR consolidé ERP) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/06-erp-interface/messages-reference.md
+321
View File
@@ -0,0 +1,321 @@
---
title: "Catalogue des messages ERP — Référence complète"
tags: [ERP, messages, interface, SAP, catalogue, ITM, ASN, ROR, ROF, REF, SOR, RUT, SOF, LOF, PCK, MOV, STV, STR, STC, SCR, WSC, COR, COF, LOC, ERR, CHG]
status: draft
standard_ref: architecture/erp-integration.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
last_updated: 2026-05-06
author: Arthur
---
# Catalogue des messages ERP — Référence complète
> **Résumé** : tableau de référence de tous les messages d'interface entre
> SAP EWM et EasyWMS chez Limagrain, classés par domaine fonctionnel.
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
La communication entre SAP EWM et EasyWMS utilise XML + Webservice.
Le détail des champs est dans le document « Liste Interfaces LIMAGRAIN »
(fichier séparé). Cette page référence la typologie et le rôle de chaque
message.
## Tableau synthétique
### SAP → EasyWMS (flux entrants)
| Domaine | Message | Standard/Custom | Description | Statut |
|---------|---------|-----------------|-------------|--------|
| Master Data | ITM | Standard | Fiche article (Lot SAP) | ✅ Validé |
| Réception | ASN | Standard | Réception production (1 par palette) | ✅ Validé |
| Réception | ROR | Standard | Réceptions externes + retours clients | ✅ Validé |
| Expédition | SOR | Standard | Ordres de sortie (prod/recertif) | ✅ Validé |
| Expédition | RUT | Standard | Routes / tournées client | ✅ Validé |
| Stock | STR | Standard | Demande changement de stock (article, statut) | ✅ Validé |
| Inventaire | COR | Standard | Demande d'échantillonnage | ✅ Validé |
| Inventaire | SCR | Standard | Demande image de stock de l'entrepôt | ✅ Validé |
### EasyWMS → SAP (flux sortants)
| Domaine | Message | Standard/Custom | Description | Statut |
|---------|---------|-----------------|-------------|--------|
| Réception | REF | Standard | Finalisation de réception (+ zone stockage) | ✅ Validé |
| Réception | ROF | Standard | Clôture d'ordre d'entrée | ✅ Validé |
| Expédition | SOF | Standard | Finalisation ordre de sortie | 🟡 Phase 2 |
| Expédition | LOF | Standard | Finalisation de chargement | ✅ Validé |
| Stock | STV | Standard | Variation de stock | ⚠️ **DÉSACTIVÉ** (remplacé par LOC) |
| Stock | STC | Standard | Notification changement de statut | ⚠️ **DÉSACTIVÉ** (remplacé par LOC) |
| Stock | LOC | [CUSTOM] | Message périodique delta 5 min | ✅ Validé |
| Stock | WSC | Standard | Image de stock journalière | 🟡 Volumétrie à vérifier |
| Inventaire | COF | Standard | Confirmation d'échantillonnage | 🟡 Traitement à confirmer |
| Expédition | PCK | [CUSTOM] | Passage conteneur client | ⚠️ **REMPLACÉ** par LOC |
| Erreur | ERR | Standard | Erreur d'importation de message | ✅ Validé |
### Flux supprimés ou non retenus
| Message | Statut | Raison |
|---------|--------|--------|
| MOV | **Supprimé** | Redondant avec LOC + STR combinés |
| PCK | **Remplacé** par LOC | Le LOC périodique couvre le besoin |
| STV | **Désactivé** | Le LOC devient le seul canal stock (décision 30/04/2026) |
| STC | **Désactivé** | Statuts hors retour = B6 uniquement via LOC |
| ACC/SUP | **Non transmis** par l'ERP | Base client/fournisseur non interfacée |
| ROC | **Non utilisé** a priori | À confirmer côté Limagrain |
### Messages bidirectionnels / custom
| Domaine | Message | Direction | Standard/Custom | Description |
|---------|---------|-----------|-----------------|-------------|
| Réception | API Lot | WMS ↔ ERP | [CUSTOM] | Demande/réponse lot SAP pour retours clients |
| Stock | CHG | ERP → WMS | [CUSTOM] | Changement article et/ou propriétaire |
## Messages custom détaillés
### PCK — Passage Conteneur Client
- **Déclencheur** : stock préparé, passage en conteneur client EasyWMS
- **Contenu** : information passage conteneur client
- **Envoyé pour** : commande client, consommation OF hors recert, messagerie
- **Voir** : [Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
### ~~MOV — Movement~~ ANNULÉ
> **ANNULÉ** — décision réunion client, jugé inutile.
- ~~**Déclencheur** : déplacement de stock entre palettes~~
- ~~**Contenu** : palette d'origine, palette de destination, quantité~~
### LOC — Message périodique (détaillé)
- **Déclencheur** : Job toutes les 5 min → WF → transaction `LOC.SEND` → GNA
(script BOO) → POST SAP-CPI
- **Remplace** : PCK, MOVE, STV, STC
- **Actions** : B (déplacement), U/R (statut B6), S (suppression), T (transfert
inter-HU), C (correction quantité), **P (assignation client)**
- **Quantités** : valeurs absolues (pas des écarts) sauf ACTION=S et T
- **Exclusion** : palettes dont la réception n'est pas fermée (pas de REF)
- **Approche technique** : fork du WSC avec filtre temporel sur CreationDate
- **Transport** : via GNA → SAP-CPI (OAuth 2.0 client_credentials) —
code CPI : **ATH201**
- **Voir** : [Spécification complète LOC](loc-message-periodique.md),
[Intégration GNA → SAP-CPI](gna-sap-cpi.md),
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md)
### STV — Variation de Stock (⚠️ DÉSACTIVÉ)
> ⚠️ **Décision 30/04/2026** : le STV est désactivé (post-processing coupé).
> Le LOC devient le seul canal de notification des mouvements de stock vers SAP.
- **Direction** : WMS → SAP
- **Rôle initial** : notifier les ajustements de quantités manuels (hors flux
standards réception/expédition)
- **Mapping clé** :
| Balise | Utilisation |
|--------|-------------|
| Operation | C (positif) / D (négatif) |
| Site | WF02 |
| ItemCode | Code lot SAP |
| OwnerCode | MECALUX |
| ContainerCode | Numéro HU |
| FilterAttributes | Attributs du stock existant modifié |
| Attributes | Attributs du stock nouvellement créé |
| ReasonCode | AJUSTEMENT MANUEL |
| ERPReasonCode | ZSC1 |
| Comment | Facultatif (opérateur) |
- **Point ouvert** : Limagrain doit définir comment gérer côté ERP un STV de
type "création de stock" (l'ERP n'autorise pas la création de stock par ce
biais aujourd'hui)
- **Raison désactivation** : Limagrain préfère des quantités absolues (LOC)
plutôt que des écarts +/- (STV) — si un message se perd, l'écart est
définitivement perdu
### STR — Demande de Changement de Stock
- **Direction** : ERP → WMS
- **Cas d'usage** : changement de code article (produit SAP + description),
changement de propriétaire, blocage/déblocage de lot
- **Règles d'acceptation** :
- **Accepté** si la palette n'est pas assignée à une commande ou en cours
de mouvement
- **Refusé** si palette "client" ou en préparation (code erreur API explicite)
- **Interaction avec STV** : ajustement avec motif "STR" → le middleware (GNA)
ne traite pas les STV avec ce motif pour éviter les doublons
- **Monitoring** : Limagrain mettra en place un monitoring des erreurs pour
les cas de refus
- **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
### COR — Demande d'Échantillonnage
- **Direction** : ERP → WMS
- **Usage** : **uniquement** pour les demandes d'échantillonnage (pas pour les
inventaires physiques classiques, gérés dans EasyWMS en phase 1)
- **Mapping** :
| Balise | Valeur |
|--------|--------|
| Description | "ECHANTILLONNAGE" (en dur, discriminant WMS) |
| Code | Numéro du lot d'inspection SAP |
| Priority | 3 (basse) |
| ProductCode | Code lot SAP |
| LotCode | Code produit SAP |
| Color, Source, Size | Attributs logistiques standards |
- **Flux** : COR envoyé → WMS fait venir la palette sur un poste de travail →
opérateur prélève → palette repart en stockage → COF envoyé
- **Règle** : un article en cours d'échantillonnage **n'est pas disponible**
pour les ordres de sortie
- **Voir** : [Échantillonnage](../03-picking/echantillonnage.md)
### COF — Confirmation d'Échantillonnage
- **Direction** : WMS → ERP
- **Mapping** :
| Balise | Description |
|--------|-------------|
| CountCode | Numéro du lot d'inspection |
| Status | Closed (effectué) ou Cancelled (annulé) |
| UpdateDate | Date/heure de changement |
- **Point ouvert** : Limagrain doit confirmer si le COF sera traité côté ERP.
Si non traité, risque de demandes en double.
### WSC — Image de Stock Journalière
- **Direction** : WMS → ERP
- **Rôle** : image de stock complète pour vérification de cohérence. Contient
l'ensemble du stock : code OS, statut palette, toutes les informations
disponibles
- **Démarrage** : export manuel EasyWMS + export SAP + comparaison.
Automatisation possible ultérieurement (quotidien à heure fixe)
- **Point d'attention** : Limagrain doit vérifier sa capacité à traiter ce
fichier (volumétrie potentiellement élevée pour CPI)
- **Déclenchement** : transaction `SCR.REQ` ou `STOCKSYNC.ASKED`
### STC — Notification Changement de Statut (⚠️ DÉSACTIVÉ)
> ⚠️ **Décision 30/04/2026** : le STC est désactivé. Les changements de statut
> hors retour sont limités au B6 (blocage logistique standard) et sont couverts
> par le LOC (action R/U). Les statuts des retours sont remontés dans le REF.
### CHG — Changement article / propriétaire
- **Déclencheur** : modification article ou propriétaire dans SAP
- **Contenu** : numéro de HU, lot officiel, code nouvel article, description,
destination, propriétaire Limagrain
- **Contrainte** : le stock ne doit pas être assigné à un processus (sinon ERR)
- **Voir** : [Mapping ERP-WMS](mapping-erp-wms.md)
### API Lot SAP — Retours clients
- **Déclencheur** : lot officiel inconnu lors d'un retour client
- **Contenu (demande)** : lot officiel à vérifier
- **Contenu (réponse)** : lot SAP correspondant + attributs logistiques
- **Parallèle** : un ITM est descendu avec les infos article
- **Voir** : [Réception retour](../01-inbound/reception-retour.md)
## Flux par processus
### Réception production (ASN)
```
SAP → ASN → EasyWMS → (réception + stockage) → REF → SAP
→ ROF → SAP
→ LOC (delta 5 min) → SAP
```
### Réception extérieure / retour (ROR)
```
SAP → ROR → EasyWMS → (réception + contrôle) → REF → SAP
→ ROF → SAP
→ LOC (delta 5 min) → SAP
```
### Expédition client (RUT)
```
SAP → RUT → EasyWMS → (picking + chargement) → LOC (delta 5 min) → SAP
→ LOF → SAP
→ SOF → SAP (phase 2)
```
### Consommation OF (SOR)
```
SAP → SOR → EasyWMS → (sortie) → LOC (delta 5 min) → SAP
→ SOF → SAP (phase 2)
```
### Échantillonnage
```
SAP → COR → EasyWMS → (prélèvement poste) → COF → SAP
```
### Image stock (vérification cohérence)
```
SAP → SCR → EasyWMS → WSC → SAP (image complète)
```
### Changement de stock
```
SAP → STR → EasyWMS → (MAJ stock) → LOC (delta 5 min) → SAP
OU → ERR → SAP (si stock assigné)
```
## Points d'attention
⚠️ **STV et STC désactivés** (décision 30/04/2026) — le LOC est le seul canal
de notification des mouvements de stock vers SAP.
⚠️ Le message CHG est rejeté (ERR) si le stock est assigné à un processus
en cours.
⚠️ MOV, PCK sont **supprimés/remplacés** — le LOC couvre tous ces besoins.
⚠️ L'ASN envoie 1 palette par message (pas d'agrégation — permet suppression
individuelle en cas d'annulation).
⚠️ Le STR est refusé si la palette est assignée "client" ou en préparation.
Le middleware GNA filtre les STV avec motif "STR" pour éviter les doublons
(caduc si STV globalement désactivé).
⚠️ Le COF n'est utile que si SAP le traite — sinon risque de demandes
d'échantillonnage en double.
## Questions ouvertes
- [ ] Détail champ par champ de chaque message — document séparé à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
- [ ] Confirmer si le COF sera traité côté ERP (@Limagrain)
- [ ] Vérifier capacité de traitement du WSC quotidien — volumétrie (@Limagrain)
- [ ] Confirmer retour fournisseur : SOR simple ou RUT ? (@Limagrain)
- [ ] Effets de bord désactivation STV — lister toutes les transactions
STK.ADJ et vérifier couverture LOC (@Mecalux)
- [ ] Effets de bord désactivation STC — idem pour CST.STK (@Mecalux)
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
| 2026-05-05 | Arthur | MOV annulé, LOC détaillé (5 min, delta, structure JSON, flag client) |
| 2026-05-06 | Arthur | Enrichissement complet depuis CR consolidé ERP (STV, STR, COR/COF, WSC, flux supprimés, désactivation STV/STC) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 05/01 → 23/02/2026 |
| Expédition - LIMAGRAIN - DEV | Page ateliers DEV | 2026 |
wiki/limagrain/07-admin/.fuse_hidden0000005d00000027
+91
View File
@@ -0,0 +1,91 @@
---
title: "Contacts projet Limagrain"
tags: [admin, contacts, équipe, annuaire]
status: draft
jira_refs: []
confluence_refs: []
sources: ["Liste de contacts.md"]
last_updated: 2026-05-06
author: Arthur
---
# Contacts projet Limagrain
> **Résumé** : annuaire complet des intervenants du projet Limagrain
> (client, intégrateur, partenaires).
## Limagrain
| Nom | Mail | Poste |
|-----|------|-------|
| Antoine MARTIN | antoine.martin@limagrain.com | Assistant CDP IT |
| Xavier SUAREZ | xavier.suarez@limagrain.com | Nouveau CDP IT |
| Emilie BERNARD | emilie.bernard@limagrain.com | Ancienne CDP IT |
| Jean-Baptiste ROUVET | jean-baptiste.rouvet@limagrain.com | CDP OT |
| Thierry CHANNEBOUX | thierry.channeboux@limagrain.com | CPG |
| Nicolas SANCHEZ | nicolas.sanchez@limagrain.com | Expert IT |
| Alexandre COUTURIER | alexandre.couturier@limagrain.com | — |
| Leila CHAJJAOUI | leila.chajjaoui@limagrain.com | Experte IT (équipe Nicolas SANCHEZ) |
| Maxime TOURRETTE | maxime.tourrette@limagrain.com | Développeur IT Expert |
| Anne-Marie LARIVAILLE | anne-marie.larivaille@limagrain.com | Experte processus métier logistique |
| David BONNAVENTURE | david.bonnaventure@limagrain.com | Responsable entrepôt (équipe Olivier SERINDAT) |
| Olivier SERINDAT | olivier.serindat@limagrain.com | Responsable logistique |
## Externes Limagrain
| Nom | Mail | Poste |
|-----|------|-------|
| Brice FOLIO | ext-brice.folio@limagrain.com | — |
| Cyril MALLET | ext-cyril.mallet@limagrain.com | Responsable Infra (gestion VM) |
## Delaware (Middleware SAP)
| Nom | Mail | Poste |
|-----|------|-------|
| David RITTELMEYER | david.rittelmeyer@delaware.pro | Ancien chef de projet |
## Still (AGV)
| Nom | Mail | Poste |
|-----|------|-------|
| Yann RODRIGUES | Yann.RODRIGUES@still.fr | Ingénieur commercial |
| — | broumegoux@ceres-solutions.com | Responsable chantier (Bâtiment) |
| Vincent DOITEAU | vincent.doiteau@kiongroup.com | Expert technique AGV |
## Mecalux
| Nom | Poste |
|-----|-------|
| Justine BEUTIN | DP WMS |
| Mallaury MELGAR | CPG |
| Théo LE PAIH | CPG |
| Abdallah BOUALLAG | — |
| Hedi ABDELKRIM | Resp. Automatisme |
| Robert Bryan BRAVO BALSECA | Technique ROB Espagne |
| Gilles MAILLET | Dir. ROB |
| Thierry AMEIL | Resp. Opérations chantier ROB |
| Adrian EGUZQUIZA | Référent technique WMS |
| Antoine CREPIN MAILLET | Commercial grand compte ROB |
| Sefi FRANCO | Resp. ADV |
| Franck MICHEL | Dir. Commerce + SAV ROB |
| Vincent DAMIEN | Resp. Électrique ROB |
| Yoan WINNYKAMEN | Resp. Design & Solution ROB |
| Henri DAHAN | Resp. IT ROB |
| Benjamin ANDRIEU | Resp. Pôle Technique ROB |
| Albert FORES | Engineering Manager (Espagne) |
| Jordi CHILLON | Electrical Designer Engineer ROB (Espagne) |
| Saloua CHERIF | Nouvelle recrue IT pôle automatisme |
| Slim BEN OTHMAN | Référent technique service Hurington Mecalux Autom |
| Arthur RIA | Chef de projet technique EasyWMS |
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-06 | Arthur | Création initiale depuis annuaire projet |
## Références
| Source | Type | Date |
|--------|------|------|
| Liste de contacts | Annuaire Obsidian | 06/02/2026 |
wiki/limagrain/07-admin/.fuse_hidden0000005f00000028
+149
View File
@@ -0,0 +1,149 @@
---
title: "Utilisateurs et groupes — Permissions EasyWMS"
tags: [admin, utilisateurs, groupes, permissions, RBAC]
status: draft
standard_ref: modules/user-management.md
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
last_updated: 2026-05-05
author: Arthur
---
# Utilisateurs et groupes — Permissions EasyWMS
> **Résumé** : définition des 3 groupes d'utilisateurs Limagrain et
> leurs permissions respectives dans EasyWMS.
> **Standard EasyWMS** : → voir [User Management](../../modules/user-management.md)
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
## Contexte projet
Les utilisateurs EasyWMS sont classés en groupes avec des permissions
hiérarchiques. Limagrain définit 3 groupes par défaut. Les profils
« Administrateur » pourront adapter les droits après formation.
## Groupe Opérateur
Permissions de base pour l'exploitation quotidienne :
### Menu Entrepôt
- Stock — consultation
- Conteneurs — consultation, mouvements et extractions
- Emplacements — consultation
- Tâches — consultation
- Carte de l'entrepôt — consultation
### Menu Expédition
- Ordres d'expéditions — consultation
### Menu Réception
- Ordres de réception — consultation
### Menu Station de travail
- Station de rejet
- Station PIE (réceptions, picking, regroupement, échantillonnage, ...)
- Station PK (picking)
## Groupe Manager
Inclut tous les droits **Opérateur** + permissions supplémentaires :
### Menu Entrepôt
- Stock — droits complets
- Conteneurs — droits complets
- Emplacements — droits complets
- Tâches — droits complets
- Gestion ajustement de stock — droits complets
- Verrous — droits complets
### Menu Expédition
- Ordres d'expéditions — droits complets
### Menu Réception
- Ordres de réception — droits complets
### Menu Data Master
- Articles — droits complets (unités, rotations, types et familles)
- Conversions — droits complets
- Types de verrous — droits complets
- Raisons d'ajustement — droits complets
### Menu Inventaire
- Inventaire — droits complets
### Menu Contrôle
- Stations — droits complets
- Stations de travail — droits complets
- Mouvements — droits complets
- Allées — droits complets
- Assignations de stations — droits complets
## Groupe Administrateur
Inclut tous les droits **Opérateur** + **Manager** + permissions supplémentaires :
### Menu Contrôle
- Transactions
### Menu Organisation
- Gestion des utilisateurs et groupes
- Gestion des sessions (consultation et fermeture)
### Menu Rapports
- Extraits de stock
### Menu Configuration
- Gestion des stratégies de rangement et d'assignation
- Paramètres
### Menu Défauts
- Historique des défauts et disponibilité de l'entrepôt
## Autonomie post-formation
Après la formation EasyWMS, Limagrain sera autonome sur la gestion des
droits :
- Création de nouveaux groupes
- Modification des permissions existantes
- Attribution des utilisateurs aux groupes
## Points d'attention
⚠️ Les droits ci-dessus sont les droits **par défaut**. Ils seront
adaptés si nécessaire après formation.
⚠️ Seul le groupe Administrateur peut modifier les stratégies de
rangement et les paramètres système.
⚠️ L'accès aux stations de travail (PIE, PK, rejet) est réservé
au groupe Opérateur et supérieur.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
wiki/limagrain/07-admin/.fuse_hidden0000006100000029
+24
View File
@@ -0,0 +1,24 @@
---
title: "Administration — Vue d'ensemble"
tags: [admin, rbac, ad, index]
status: draft
last_updated: 2026-05-05
---
# Administration — Vue d'ensemble
> **Périmètre** : gestion utilisateurs et groupes, paramètres projet,
> éléments AD customs.
> **Standard EasyWMS** : voir [Application Dictionary](../../concepts/application-dictionary.md)
## Pages de cette section
- [Utilisateurs et groupes](utilisateurs-groupes.md)
- [Paramètres projet](parametres-projet.md)
- [AD Customs](ad-customs.md)
- [Contacts projet](contacts-projet.md)
## Vue synthétique
<!-- À compléter -->
wiki/limagrain/07-admin/_index.md
+24
View File
@@ -0,0 +1,24 @@
---
title: "Administration — Vue d'ensemble"
tags: [admin, rbac, ad, index]
status: draft
last_updated: 2026-05-05
---
# Administration — Vue d'ensemble
> **Périmètre** : gestion utilisateurs et groupes, paramètres projet,
> éléments AD customs.
> **Standard EasyWMS** : voir [Application Dictionary](../../architecture/application-dictionary.md)
## Pages de cette section
- [Utilisateurs et groupes](utilisateurs-groupes.md)
- [Paramètres projet](parametres-projet.md)
- [AD Customs](ad-customs.md)
- [Contacts projet](contacts-projet.md)
## Vue synthétique
<!-- À compléter -->
wiki/limagrain/07-admin/ad-customs.md
+116
View File
@@ -0,0 +1,116 @@
---
title: "AD Customs — Éléments personnalisés"
tags: [admin, AD, customs, CstAtt, Container]
status: draft
standard_ref: concepts/application-dictionary.md
jira_refs: [LIM-14]
confluence_refs: []
sources: ["recap_session_LIM-72_13-05-2026.md"]
last_updated: 2026-05-13
author: Arthur
---
# AD Customs — Éléments personnalisés
> **Résumé** : inventaire des Custom Attributes (CstAtt) et éléments AD
> personnalisés pour le projet Limagrain. Référence centralisée pour le
> développement et la maintenance.
> **Standard EasyWMS** : → voir
> [Application Dictionary](../../concepts/application-dictionary.md)
> Ce qui suit documente les **personnalisations Limagrain**.
## Contexte projet
Le projet Limagrain utilise de nombreux CstAtt sur les entités
Container, Réception, Stock et OE pour piloter les flux customs
(réception, picking, clôture, etc.). Cette page centralise le mapping
complet pour éviter les conflits et faciliter la maintenance.
## CstAtt Container (support / palette)
Source : [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
| CstAtt | Donnée | Type | Tâche | Statut |
|--------|--------|------|-------|--------|
| 01 | Big-bag potentiel (réception contient big-bag) | bool | LIM-64 | Utilisé |
| 02 | Contient big-bag | bool | LIM-67 | Utilisé |
| 03 | À anoxier | bool | LIM-67 | Utilisé |
| 04 | Support ASN | bool | LIM-64 | Utilisé |
| 05 | Programme de filmage | int | LIM-67 | Utilisé |
| 06 | Code PK assigné | string | LIM-70 | Utilisé |
| 07 | Date fin d'anoxie | datetime | — | Utilisé |
| 08 | Code réception (conteneur virtuel) | string | — | Utilisé |
| 09 | CERTIFICATION (fausse palette) | string | — | Utilisé |
| 10 | Réception en cours au PK | bool | — | Utilisé |
| 11 | Rangé ASRS après réception | bool | LIM-73 | Utilisé |
| 12 | **Proposé** : code OE associé | string | LIM-64 (évol.) | Libre |
| 13 | Étiquetée au PK | bool | LIM-XX | À réserver |
| 14-20 | — | — | — | **Libres** |
> **Proposition CstAtt12** : stocker le code OE (association palette ↔
> ordre d'entrée) dès l'image de quai. Permettrait de pré-remplir la
> sélection de réception au PK (LIM-72) et d'optimiser le routage AGV
> (LIM-70). Impact planning à évaluer — reporté après réponses aux
> questions ouvertes.
> **CstAtt13 — Étiquetée au PK** : flag utilisé par l'étiqueteuse
> automatique au poste de sortie TK pour éviter une ré-impression.
> Valeurs : `true` = déjà étiquetée au PK (l'étiqueteuse auto
> n'imprime pas), `false` = pas encore étiquetée, `error` = impression
> échouée. Vérifier avec LIM-14 qu'il n'y a pas de conflit avec le
> CstAtt12 proposé.
## CstAtt Réception
| CstAtt | Donnée | Type | Tâche |
|--------|--------|------|-------|
| 01 | Flag clôture en cours (retours) | bool | LIM-73 |
Voir [Réception retour — Clôture](../01-inbound/reception-retour.md)
pour le détail du mécanisme.
## CstAtt OE (InboundOrder)
| CstAtt | Donnée | Type | Tâche |
|--------|--------|------|-------|
| 01 | Hors tolérance (au moins 1 ligne OE hors tolérance) | bool | LIM-73 |
Voir [Réception fournisseur — Clôture](../01-inbound/reception-fournisseur.md).
## CstAtt Stock (StockLine)
Les CstAtt stock portent principalement les attributs logistiques
descendus de SAP. Voir
[Données principales](../06-erp-interface/donnees-principales.md)
pour le mapping détaillé.
## CstAtt OS (OutboundOrder / ShippingOrder)
| CstAtt | Donnée | Type | Tâche |
|--------|--------|------|-------|
| CstAtt | Verrou séquençage TK (blocage stacker crane) | bool | LIM-84 |
Voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md).
## Points d'attention
⚠️ Les CstAtt Container 14-20 sont libres. Tout nouvel usage doit être
documenté ici et dans LIM-14.
⚠️ Le CstAtt11 Container est posé une seule fois (rangement ASRS) et
n'est jamais remis à false, même si le support ressort ensuite.
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-13 | Arthur | Création avec table CstAtt Container complète depuis LIM-14 |
| 2026-05-13 | Arthur | Réservation CstAtt13 Container pour flag étiquetage PK |
## Références
| Source | Type | Date |
|--------|------|------|
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira | 2025 |
| recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |
wiki/limagrain/07-admin/contacts-projet.md
+91
View File
@@ -0,0 +1,91 @@
---
title: "Contacts projet Limagrain"
tags: [admin, contacts, équipe, annuaire]
status: draft
jira_refs: []
confluence_refs: []
sources: ["Liste de contacts.md"]
last_updated: 2026-05-06
author: Arthur
---
# Contacts projet Limagrain
> **Résumé** : annuaire complet des intervenants du projet Limagrain
> (client, intégrateur, partenaires).
## Limagrain
| Nom | Mail | Poste |
|-----|------|-------|
| Antoine MARTIN | antoine.martin@limagrain.com | Assistant CDP IT |
| Xavier SUAREZ | xavier.suarez@limagrain.com | Nouveau CDP IT |
| Emilie BERNARD | emilie.bernard@limagrain.com | Ancienne CDP IT |
| Jean-Baptiste ROUVET | jean-baptiste.rouvet@limagrain.com | CDP OT |
| Thierry CHANNEBOUX | thierry.channeboux@limagrain.com | CPG |
| Nicolas SANCHEZ | nicolas.sanchez@limagrain.com | Expert IT |
| Alexandre COUTURIER | alexandre.couturier@limagrain.com | — |
| Leila CHAJJAOUI | leila.chajjaoui@limagrain.com | Experte IT (équipe Nicolas SANCHEZ) |
| Maxime TOURRETTE | maxime.tourrette@limagrain.com | Développeur IT Expert |
| Anne-Marie LARIVAILLE | anne-marie.larivaille@limagrain.com | Experte processus métier logistique |
| David BONNAVENTURE | david.bonnaventure@limagrain.com | Responsable entrepôt (équipe Olivier SERINDAT) |
| Olivier SERINDAT | olivier.serindat@limagrain.com | Responsable logistique |
## Externes Limagrain
| Nom | Mail | Poste |
|-----|------|-------|
| Brice FOLIO | ext-brice.folio@limagrain.com | — |
| Cyril MALLET | ext-cyril.mallet@limagrain.com | Responsable Infra (gestion VM) |
## Delaware (Middleware SAP)
| Nom | Mail | Poste |
|-----|------|-------|
| David RITTELMEYER | david.rittelmeyer@delaware.pro | Ancien chef de projet |
## Still (AGV)
| Nom | Mail | Poste |
|-----|------|-------|
| Yann RODRIGUES | Yann.RODRIGUES@still.fr | Ingénieur commercial |
| — | broumegoux@ceres-solutions.com | Responsable chantier (Bâtiment) |
| Vincent DOITEAU | vincent.doiteau@kiongroup.com | Expert technique AGV |
## Mecalux
| Nom | Poste |
|-----|-------|
| Justine BEUTIN | DP WMS |
| Mallaury MELGAR | CPG |
| Théo LE PAIH | CPG |
| Abdallah BOUALLAG | — |
| Hedi ABDELKRIM | Resp. Automatisme |
| Robert Bryan BRAVO BALSECA | Technique ROB Espagne |
| Gilles MAILLET | Dir. ROB |
| Thierry AMEIL | Resp. Opérations chantier ROB |
| Adrian EGUZQUIZA | Référent technique WMS |
| Antoine CREPIN MAILLET | Commercial grand compte ROB |
| Sefi FRANCO | Resp. ADV |
| Franck MICHEL | Dir. Commerce + SAV ROB |
| Vincent DAMIEN | Resp. Électrique ROB |
| Yoan WINNYKAMEN | Resp. Design & Solution ROB |
| Henri DAHAN | Resp. IT ROB |
| Benjamin ANDRIEU | Resp. Pôle Technique ROB |
| Albert FORES | Engineering Manager (Espagne) |
| Jordi CHILLON | Electrical Designer Engineer ROB (Espagne) |
| Saloua CHERIF | Nouvelle recrue IT pôle automatisme |
| Slim BEN OTHMAN | Référent technique service Hurington Mecalux Autom |
| Arthur RIA | Chef de projet technique EasyWMS |
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-06 | Arthur | Création initiale depuis annuaire projet |
## Références
| Source | Type | Date |
|--------|------|------|
| Liste de contacts | Annuaire Obsidian | 06/02/2026 |
wiki/limagrain/07-admin/utilisateurs-groupes.md
BIN
View File
Binary file not shown.
wiki/limagrain/08-transverse/.fuse_hidden000000630000002a
+267
View File
@@ -0,0 +1,267 @@
---
title: "Questions ouvertes — Suivi projet"
tags: [transverse, questions, suivi, à-confirmer]
status: draft
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", LIM-62_gestion-camions.md, LIM-63_64_65.md, "LIM-69 - LOT1.3 Modes de travail des PK.md", "LIM-70 LOT1.3 [AGV][JOB] MEGA JOB.md", "LIM-71 LOT1.2 RECEPTION PRODUCTION AGV.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "LIM-76 LOT1.2 [GNA] Message LOC.md", "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md", "LIM-85 LOT2.1 Configuration stratégies defragmentation.md", "LIM-87 LOT2.1 Défragmentation client quai non assigné.md", "LIM-88 LOT2.1 Séquençage shipping par STOP.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md"]
last_updated: 2026-05-12
author: Arthur
---
# Questions ouvertes — Suivi projet
> **Résumé** : centralisation de toutes les questions ouvertes identifiées
> lors de l'intégration de l'AF V1.5 dans le wiki projet.
## Réception / Inbound
- [ ] Processus de blocage long terme entrée quai — quand est-il utilisé
concrètement ? (@Théo)
- [ ] Notifications agent de quai à l'arrivée du camion — supprimées dans
AF V1.5, à confirmer exclusion définitive (@Justine)
- [ ] Assignation borne / quai — supprimée dans AF V1.5, à confirmer (@Justine)
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à
valider avec le client (@Justine)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
ZPL (@Théo)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
palettes impossibles à réceptionner ? (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? Actuellement non obligatoire
(LIM-62, 09/03/2026). (@Justine)
→ voir [Gestion des camions](../01-inbound/gestion-camions.md)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
- [x] ~~Détail des cas d'erreur API SAP flux retour client~~ → Documenté
via LIM-72 : payload requête/réponse, séquence d'échange, timeout/retry
- [ ] URL exacte endpoint API SAP (SAP_LOT_VERIFY_URL) — à définir
(@Fabien)
- [ ] Vérification "vendu par Limagrain" dans la réponse API : est-ce
EV_DEPLOY dans ET_BATCH ou un autre champ ? (@Fabien)
- [ ] Gestion du token SAP : récupération avant chaque appel ou clé
privée ? (@Fabien)
- [ ] Cas product code manquant en base après réponse OK API SAP :
délai d'attente avant Réessayer ? (@Fabien)
- [ ] Retour client — palette refusée au PIE non supprimée : comment
gérer si le client oublie de la retirer du WMS ? Clôture REF bloquée
indéfiniment (LIM-73 §1.3.1) (@Justine)
- [ ] WF de clôture OE à modifier pour bloquer l'auto-close quand
CstAtt01 OE = true — ticket dédié à créer ? (LIM-73 §1.3.2)
(@Nicolas)
- [x] ~~LOC custom (LIM-76) : développement hors scope LIM-73~~ →
Spécifié dans LIM-76 : filtre d'exclusion REF non envoyé documenté
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
## Stockage / ASRS
- [ ] Défragmentation custom (LIM-87) — **rupture de stock** sur un OS
de la tournée (CT-13) : option A (RUT non éligible, attente nouveau
SOR) ou option B (défrag sur palettes disponibles) ?
(@Justine — vérifier avec le client)
→ voir [Défragmentation](../02-stockage/defragmentation.md)
- [ ] Défragmentation custom (LIM-87) — **MAX_DEFRAG_ATTEMPT** :
impacte-t-il uniquement la défrag par rotation ou aussi la défrag
client ? (@Nicolas)
→ voir [Défragmentation](../02-stockage/defragmentation.md)
## Stockage / ASRS
- [ ] Automatisation des étapes 1 et 2 du processus d'anoxie — développement
custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
- [ ] Nombre exact de piles de palettes vides en tampon au sol (@Théo)
## Picking / Préparation
- [ ] Fréquence d'exécution du Mega Job d'assignation PK — à définir
(@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Sous-WF pour regroupement et échantillonnage : tickets à créer ?
(@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Interaction PK_BIGBAG et modes : si P5 est en regroupement,
accepte-t-il les big-bags en réception ? (@Michael)
- [x] ~~Lien entre picking AF V1.5 et CR V3.0 picking combinatoire~~ →
Architecture clarifiée : specs V1.0/V1.1 + arbitrage réu. 11/05/2026
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md) et
[Placement PS → PK](../03-picking/placement-ps-pk.md)
- [x] ~~Programme de filmage exact~~ → 8 programmes documentés (A→H : Tournesol/Maïs&Blé × Sacs/BigBag × Complet/Réduit)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
- [ ] Le prélèvement de 200g en échantillonnage est-il déduit du stock
ou négligé ? (@Nicolas)
- [ ] Séquençage TK→PS (LIM-84) : comportement si erreur du process —
OS reste bloqué avec CstAtt = false ? (@Nicolas)
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
- [ ] Séquençage TK→PS (LIM-84) : impact perf si beaucoup d'OS Released
simultanément — contention sur les événements ? (@Fabien)
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
## Expédition / Outbound
- [ ] Ordonnancement des palettes dans le canal du poumon d'expédition
ASRS — géré par le WMS ou naturellement via l'ordre de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ? (@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
— à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie carton en parallèle sur un poste ? (@Justine)
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
- [ ] Réunion technique Still pour le problème dépose AGV sur image de
quai (@Théo)
- [ ] Custom fermeture messagerie pour support non client avec supports
clients (@Nicolas)
- [ ] Clôture manuelle en cas d'expédition partielle — workflow opérateur
détaillé (@Justine)
- [ ] Séquençage shipping STOP (LIM-88) — 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. (@Nicolas)
→ voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
- [ ] Séquençage shipping STOP (LIM-88) — 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 [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
- [x] ~~Processus exact de remplacement sac endommagé~~ → Flux litige
documenté : bouton Problème + verrou support + buffer litige
- [x] ~~Emplacement au sol messagerie carton~~ → Solution retenue :
emplacement au sol par transporteur (pas d'image de quai classique)
## ERP / Interfaces
- [ ] Détail champ par champ de chaque message — document « Liste Interfaces
LIMAGRAIN » à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas
d'échec ? (@Nicolas)
- [ ] Liste exhaustive des statuts de stock prévus au démarrage (@Justine)
- [ ] Liste des commentaires par statut de stock — validée ? (@Justine)
- [ ] CstAtt10 (Stage) — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
- [ ] Création stock via attributs logistiques en réception — standard ou
custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
- [x] ~~Gestion STV type "création de stock"~~ → STV désactivé, remplacé
par le LOC (ACTION=C pour corrections, ACTION=T pour transferts)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] StopNumber (RUT) : vérifier que SAP envoie un numéro d'arrêt de
livraison et pas de chargement (@Limagrain)
- [ ] Numéro de ligne SOF/LOF : confirmer le nombre de caractères du numéro
de ligne SAP (padLeft "0") (@Limagrain)
- [ ] Confirmer si le COF sera traité côté ERP — risque demandes en
double (@Limagrain)
- [ ] Confirmer la règle de mélange des marques sur palette (@Limagrain)
- [ ] Fournir la plage GS1 SSCC (@Limagrain)
- [ ] Planifier un atelier étiquettes avec Antoine (@Limagrain / @Mecalux)
- [ ] Confirmer le stockage des Z-Bags dans l'ASRS (format palettes
respecté ?) (@Limagrain / @Mecalux)
- [ ] Vérifier capacité de traitement du WSC quotidien —
volumétrie (@Limagrain)
- [ ] LOC — Cas palette sur image de quai puis chargée avant le prochain
cycle LOC : la HU ne sera pas mentionnée dans le LOC (LIM-76 point #3)
(@Limagrain) → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — HU multi-lignes de stock (2 articles/lots) : comportement
exact à confirmer (LIM-76 CT-112) (@Fabien)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — Vérifier si d'autres transactions WMS sont utiles
(ex. STK.SCR) (@Fabien)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] GNA SAP-CPI — File d'attente persistante pour messages en échec
après 4 retries ? (@Nicolas)
→ voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] GNA SAP-CPI — Secret OAuth doit-il être chiffré dans le config ?
(@Fabien)
→ voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] Retour fournisseur : ce flux est-il utilisé ? Si oui, SOR simple ou
RUT ? (@Limagrain)
- [ ] Clarifier comportement lot officiel lors changement de
destination (@Limagrain)
- [ ] Vérifier le traitement interne du LOF (absence de ligne = non
expédié) (@Limagrain)
- [ ] EstimatedNumCont : vérifier disponibilité dans SAP pour chaque
commande client (ROR) (@Limagrain)
## AGV / Still
- [ ] Interface AGV — document séparé à intégrer quand disponible (@Arthur)
- [ ] Impact fonctionnel des interfaces AGV sur les flux (@Théo)
- [ ] Redirection multi-poumons / multi-PIE pour réception production :
config EasyS prête ? (@Nicolas) → voir
[Job réception production](../05-agv/job-reception-production.md)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification par
tâche active suffit ? (@Fabien) → voir
[Job réception production](../05-agv/job-reception-production.md)
## Admin / Transverse
- [ ] Rapports standards — exclus de l'AF V1.5, périmètre à définir (@Justine)
- [ ] Vues EasyWMS — sauf impact processus fonctionnel, exclus AF V1.5 (@Justine)
- [ ] Layout complet (postes de picking inclus) — exclus AF V1.5 (@Théo)
## Points fermés (ateliers expédition DEV)
Les points suivants ont été tranchés lors des ateliers DEV expédition :
- [x] **SOR au numéro de support** → Fermé : jamais au numéro de support
- [x] **FEFO sans DLC** → Fermé : abandonné, FIFO journalier retenu
- [x] **Message MOV** → Fermé : annulé (inutile)
- [x] **Gestion FIFO canal** → Fermé : FIFO 24h standard, économie de
mouvement prioritaire
- [x] **Custom attributes vs attributs logistiques** → Tranché : attributs
logistiques avec masquage écrans inutiles
- [x] **Process litige sac endommagé** → Fermé : flux décrit (bouton
Problème + verrou support + buffer litige), à confirmer avec client
- [x] **Statut de stock F2 si aucun statut** → Fermé : REDFLAG, pousser
pour ne pas faire
- [x] **Anoxie : flux automatique** → Fermé : à prévoir si temps disponible
- [x] **Fréquence image de stock (WSC)** → Fermé : à définir (toutes les
X heures)
## Éléments exclus de l'AF V1.5
Pour mémoire, les éléments suivants sont explicitement exclus du périmètre :
- Choix fournisseur AGV + communication AGV (sauf impact fonctionnel)
- Rapports standards
- Vues EasyWMS (sauf impact processus fonctionnel)
- Vues graphiques application EasyWMS
- Définition des champs / messages interfaces ERP (document séparé)
- Gestion des palettes (type film, octobins, armoires multi lots, ...)
- Layout complet (postes de picking inclus)
- Études électriques / architecture PLC (OT)
- Interfaces machines (OT)
- Choix des équipements tiers (OT)
- Matériel informatique, écrans, PC, imprimantes (IT)
- Monitoring énergétique (OT)
- Planning tests OT/IT + mise en service OT/IT
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|--------------|
| 2026-05-05 | Arthur | Création initiale — consolidation questions AF V1.5 |
| 2026-05-05 | Arthur | Ajout 10 questions depuis ateliers DEV Confluence (réception) |
| 2026-05-05 | Arthur | Ajout 11 questions expédition, 2 fermées, 9 points tranchés (ateliers DEV) |
| 2026-05-06 | Arthur | Ajout 13 questions ERP consolidées (CR ateliers interfaçage) |
| 2026-05-12 | Arthur | Ajout 7 questions (LIM-69/70/71/72) : Mega Job fréquence, sous-WF, PK_BIGBAG, redirection multi-PIE, CstAtt06, API SAP (URL, token, EV_DEPLOY, product code). 1 question fermée (API SAP documentée) |
| 2026-05-12 | Arthur | Ajout 3 questions (LIM-73) : palette refusée PIE non supprimée (retour), WF clôture OE à modifier, LOC custom LIM-76 |
| 2026-05-12 | Arthur | LIM-76/89 : 2 questions fermées (LOC custom LIM-76, STV création stock), 5 nouvelles (LOC palette chargée avant cycle, HU multi-lignes, transactions supplémentaires, file d'attente GNA, secret OAuth) |
| 2026-05-12 | Arthur | Ajout 2 questions picking (LIM-84) : erreur process séquençage, contention événements |
| 2026-05-12 | Arthur | Ajout 4 questions (LIM-85/87/88) : rupture stock défrag CT-13, MAX_DEFRAG_ATTEMPT, retour PF rangement standard, bascule quai |
| 2026-05-12 | Arthur | Fermée : architecture picking V1.5/V3.0 clarifiée (réu. 11/05/2026, specs V1.0/V1.1) |
## Références
| Source | Type | Date |
|--------|------|------|
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
wiki/limagrain/08-transverse/.fuse_hidden000000650000002b
+22
View File
@@ -0,0 +1,22 @@
---
title: "Transverse — Vue d'ensemble"
tags: [transverse, jira, architecture, index]
status: draft
last_updated: 2026-05-05
---
# Transverse — Vue d'ensemble
> **Périmètre** : tickets Jira clés, décisions d'architecture, questions ouvertes,
> historique du projet.
## Pages de cette section
- [Tickets Jira clés](jira-tickets-cles.md)
- [Décisions architecture](decisions-architecture.md)
- [Questions ouvertes](questions-ouvertes.md)
- [Historique projet](historique-projet.md)
## Vue synthétique
<!-- À compléter -->
wiki/limagrain/08-transverse/_index.md
+22
View File
@@ -0,0 +1,22 @@
---
title: "Transverse — Vue d'ensemble"
tags: [transverse, jira, architecture, index]
status: draft
last_updated: 2026-05-05
---
# Transverse — Vue d'ensemble
> **Périmètre** : tickets Jira clés, décisions d'architecture, questions ouvertes,
> historique du projet.
## Pages de cette section
- [Tickets Jira clés](jira-tickets-cles.md)
- [Décisions architecture](decisions-architecture.md)
- [Questions ouvertes](questions-ouvertes.md)
- [Historique projet](historique-projet.md)
## Vue synthétique
<!-- À compléter -->
wiki/limagrain/08-transverse/questions-ouvertes.md
+296
View File
@@ -0,0 +1,296 @@
---
title: "Questions ouvertes — Suivi projet"
tags: [transverse, questions, suivi, à-confirmer]
status: draft
jira_refs: []
confluence_refs: []
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "Expédition - LIMAGRAIN - DEV - Confluence.md", "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md", LIM-62_gestion-camions.md, LIM-63_64_65.md, "LIM-69 - LOT1.3 Modes de travail des PK.md", "LIM-70 LOT1.3 [AGV][JOB] MEGA JOB.md", "LIM-71 LOT1.2 RECEPTION PRODUCTION AGV.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "LIM-76 LOT1.2 [GNA] Message LOC.md", "LIM-89 GNA Mise en place de la communication API EasyWMS SAP CPI.md", "LIM-85 LOT2.1 Configuration stratégies defragmentation.md", "LIM-87 LOT2.1 Défragmentation client quai non assigné.md", "LIM-88 LOT2.1 Séquençage shipping par STOP.md", "REU PICKING SEQUENCAGE 11-05-2026 - Analyse comparative notes + AF + devops.md", "CR technique - iGO STILL - fonctionnement et flux API v1.md", "recap_session_LIM-72_13-05-2026.md", "reu_still_sur_site.pdf"]
last_updated: 2026-05-13
author: Arthur
---
# Questions ouvertes — Suivi projet
> **Résumé** : centralisation de toutes les questions ouvertes identifiées
> lors de l'intégration de l'AF V1.5 dans le wiki projet.
## Réception / Inbound
- [ ] Processus de blocage long terme entrée quai — quand est-il utilisé
concrètement ? (@Théo)
- [ ] Notifications agent de quai à l'arrivée du camion — supprimées dans
AF V1.5, à confirmer exclusion définitive (@Justine)
- [ ] Assignation borne / quai — supprimée dans AF V1.5, à confirmer (@Justine)
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
- [ ] Position étiquette image de quai (devant/côté palette) — à
valider avec le client (@Justine)
- [ ] Utilisation du ROC (confirmation de réception) — point interne
Limagrain (@Justine)
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
faisabilité technique (@Nicolas)
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
réception (@Nicolas)
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
ZPL (@Théo)
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
palettes impossibles à réceptionner ? (@Justine)
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
la cohérence de l'affichage chauffeur ? Actuellement non obligatoire
(LIM-62, 09/03/2026). (@Justine)
→ voir [Gestion des camions](../01-inbound/gestion-camions.md)
- [ ] Poids variable — vérifier si le standard gère la capture de
poids avec poids moyen activé (@Nicolas)
- [x] ~~Détail des cas d'erreur API SAP flux retour client~~ → Documenté
via LIM-72 : payload requête/réponse, séquence d'échange, timeout/retry
- [x] ~~URL exacte endpoint API SAP (SAP_LOT_VERIFY_URL)~~ → Endpoint
CPI unique `/http/ATHInboundMessage` avec `MessageType = "ATH214"`.
URLs TEST documentées. URLs PROD à définir.
→ voir [Réception retour](../01-inbound/reception-retour.md)
- [x] ~~Gestion du token SAP~~ → OAuth 2.0 client_credentials, cache
token sur disque, gestion expiration côté WMS
→ voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] **[A1 BLOQUANT]** Champs manquants dans ET_BATCH (réponse ATH214) :
description article, pays de destination, propriétaire Limagrain — sans
ces champs, le dialogue de choix multi-lot ne fonctionne pas
(@Vincent Goyet / @Pierre Gaudy — mail 13/05/2026)
→ voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[A2]** Nom final du champ de déploiement : `EV_DEPLOY` ou
`ZDEPLOY` ? Ambigu dans les échanges (@Vincent Goyet — mail 13/05/2026)
→ voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[A3]** Délai typique entre réponse ATH214 et push ITM via ATH002 :
dimensionnement du polling 5s / timeout 1 min
(@Vincent Goyet — mail 13/05/2026)
- [ ] **[A4 IMPORTANT]** Vérification "déployé" pour les lots déjà connus
en base WMS (pas d'appel ATH214) : info disponible dans l'ITM ou appel
systématique nécessaire ? Trou fonctionnel dans le design actuel
(@Vincent Goyet — mail 13/05/2026)
→ voir [Réception retour](../01-inbound/reception-retour.md)
- [ ] **[B1]** Étiquette stock retour client : en complément de la RFID ?
Quels champs ? Format A6 ? Imprimante dédiée ?
(@Leila / @Antoine — mail 13/05/2026)
- [ ] **[B2 IMPORTANT]** Flux de rejet PIE retour client : destination
exacte, notifications, actions opérateur, notification SAP,
suppression palette (@Leila / @Antoine — mail 13/05/2026)
→ voir [Contrôle qualité réception](../01-inbound/controle-qualite-reception.md)
- [ ] **[PS — reporté]** Association palette ↔ OE dès l'image de quai
via CstAtt12 Container — faisable techniquement (modification LIM-64),
impact planning à évaluer, reporté après réponses A1-B2
→ voir [AD Customs](../07-admin/ad-customs.md)
- [ ] Retour client — palette refusée au PIE non supprimée : comment
gérer si le client oublie de la retirer du WMS ? Clôture REF bloquée
indéfiniment (LIM-73 §1.3.1) (@Justine)
- [ ] WF de clôture OE à modifier pour bloquer l'auto-close quand
CstAtt01 OE = true — ticket dédié à créer ? (LIM-73 §1.3.2)
(@Nicolas)
- [x] ~~LOC custom (LIM-76) : développement hors scope LIM-73~~ →
Spécifié dans LIM-76 : filtre d'exclusion REF non envoyé documenté
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
## Stockage / ASRS
- [ ] Défragmentation custom (LIM-87) — **rupture de stock** sur un OS
de la tournée (CT-13) : option A (RUT non éligible, attente nouveau
SOR) ou option B (défrag sur palettes disponibles) ?
(@Justine — vérifier avec le client)
→ voir [Défragmentation](../02-stockage/defragmentation.md)
- [ ] Défragmentation custom (LIM-87) — **MAX_DEFRAG_ATTEMPT** :
impacte-t-il uniquement la défrag par rotation ou aussi la défrag
client ? (@Nicolas)
→ voir [Défragmentation](../02-stockage/defragmentation.md)
- [ ] Automatisation des étapes 1 et 2 du processus d'anoxie — développement
custom validé ? (@Nicolas)
- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
- [ ] Nombre exact de piles de palettes vides en tampon au sol (@Théo)
## Picking / Préparation
- [ ] Fréquence d'exécution du Mega Job d'assignation PK — à définir
(@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Sous-WF pour regroupement et échantillonnage : tickets à créer ?
(@Michael) → voir [Job assignation PK](../03-picking/job-assignation-pk.md)
- [ ] Interaction PK_BIGBAG et modes : si P5 est en regroupement,
accepte-t-il les big-bags en réception ? (@Michael)
- [x] ~~Lien entre picking AF V1.5 et CR V3.0 picking combinatoire~~ →
Architecture clarifiée : specs V1.0/V1.1 + arbitrage réu. 11/05/2026
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md) et
[Placement PS → PK](../03-picking/placement-ps-pk.md)
- [x] ~~Programme de filmage exact~~ → 8 programmes documentés (A→H : Tournesol/Maïs&Blé × Sacs/BigBag × Complet/Réduit)
- [ ] Gestion du picking négatif dans l'interface opérateur (@Nicolas)
- [ ] Interface opérateur vue regroupement — maquette validée ? (@Fabien)
- [ ] Format de l'étiquette d'échantillonnage — validé ? (@Justine)
- [ ] Le prélèvement de 200g en échantillonnage est-il déduit du stock
ou négligé ? (@Nicolas)
- [ ] Séquençage TK→PS (LIM-84) : comportement si erreur du process —
OS reste bloqué avec CstAtt = false ? (@Nicolas)
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
- [ ] Séquençage TK→PS (LIM-84) : impact perf si beaucoup d'OS Released
simultanément — contention sur les événements ? (@Fabien)
→ voir [Séquençage TK → PS](../03-picking/sequencage-tk-ps.md)
## Expédition / Outbound
- [ ] Ordonnancement des palettes dans le canal du poumon d'expédition
ASRS — géré par le WMS ou naturellement via l'ordre de stockage ? (@Nicolas)
- [ ] Fermeture auto OS si chargement complet — standard ou custom ? (@Nicolas)
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
à paramétrer et tester (@Fabien)
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
— à documenter dans le TMS (@Théo)
- [ ] Combien de commandes messagerie carton en parallèle sur un poste ? (@Justine)
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
- [ ] Réunion technique Still pour le problème dépose AGV sur image de
quai (@Théo)
- [ ] Custom fermeture messagerie pour support non client avec supports
clients (@Nicolas)
- [ ] Clôture manuelle en cas d'expédition partielle — workflow opérateur
détaillé (@Justine)
- [ ] Séquençage shipping STOP (LIM-88) — 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. (@Nicolas)
→ voir [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
- [ ] Séquençage shipping STOP (LIM-88) — 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 [Séquençage shipping par STOP](../04-outbound/sequencage-shipping-stop.md)
- [x] ~~Processus exact de remplacement sac endommagé~~ → Flux litige
documenté : bouton Problème + verrou support + buffer litige
- [x] ~~Emplacement au sol messagerie carton~~ → Solution retenue :
emplacement au sol par transporteur (pas d'image de quai classique)
## ERP / Interfaces
- [ ] Détail champ par champ de chaque message — document « Liste Interfaces
LIMAGRAIN » à intégrer (@Arthur)
- [ ] Format exact du message CHG (@Nicolas)
- [ ] CHG envoie-t-il un acquittement positif ou juste ERR en cas
d'échec ? (@Nicolas)
- [ ] Liste exhaustive des statuts de stock prévus au démarrage (@Justine)
- [ ] Liste des commentaires par statut de stock — validée ? (@Justine)
- [ ] CstAtt10 (Stage) — quand sera-t-il ajouté au mapping ITM ? (@Nicolas)
- [ ] Création stock via attributs logistiques en réception — standard ou
custom ? À valider par tests (@Fabien)
- [ ] Impact suppression CstAtt stock sur les développements existants (@Nicolas)
- [x] ~~Gestion STV type "création de stock"~~ → STV désactivé, remplacé
par le LOC (ACTION=C pour corrections, ACTION=T pour transferts)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] StopNumber (RUT) : vérifier que SAP envoie un numéro d'arrêt de
livraison et pas de chargement (@Limagrain)
- [ ] Numéro de ligne SOF/LOF : confirmer le nombre de caractères du numéro
de ligne SAP (padLeft "0") (@Limagrain)
- [ ] Confirmer si le COF sera traité côté ERP — risque demandes en
double (@Limagrain)
- [ ] Confirmer la règle de mélange des marques sur palette (@Limagrain)
- [ ] Fournir la plage GS1 SSCC (@Limagrain)
- [ ] Planifier un atelier étiquettes avec Antoine (@Limagrain / @Mecalux)
- [ ] Confirmer le stockage des Z-Bags dans l'ASRS (format palettes
respecté ?) (@Limagrain / @Mecalux)
- [ ] Vérifier capacité de traitement du WSC quotidien —
volumétrie (@Limagrain)
- [ ] LOC — Cas palette sur image de quai puis chargée avant le prochain
cycle LOC : la HU ne sera pas mentionnée dans le LOC (LIM-76 point #3)
(@Limagrain) → voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — HU multi-lignes de stock (2 articles/lots) : comportement
exact à confirmer (LIM-76 CT-112) (@Fabien)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] LOC — Vérifier si d'autres transactions WMS sont utiles
(ex. STK.SCR) (@Fabien)
→ voir [LOC message périodique](../06-erp-interface/loc-message-periodique.md)
- [ ] GNA SAP-CPI — File d'attente persistante pour messages en échec
après 4 retries ? (@Nicolas)
→ voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] GNA SAP-CPI — Secret OAuth doit-il être chiffré dans le config ?
(@Fabien)
→ voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
- [ ] Retour fournisseur : ce flux est-il utilisé ? Si oui, SOR simple ou
RUT ? (@Limagrain)
- [ ] Clarifier comportement lot officiel lors changement de
destination (@Limagrain)
- [ ] Vérifier le traitement interne du LOF (absence de ligne = non
expédié) (@Limagrain)
- [ ] EstimatedNumCont : vérifier disponibilité dans SAP pour chaque
commande client (ROR) (@Limagrain)
## AGV / Still
- [x] ~~Interface AGV — document séparé à intégrer quand disponible~~ →
Intégré via CR technique iGO STILL v1 (2026-04-28)
→ voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Impact fonctionnel des interfaces AGV sur les flux (@Théo)
- [ ] Redirection multi-poumons / multi-PIE pour réception production :
config EasyS prête ? (@Nicolas) → voir
[Job réception production](../05-agv/job-reception-production.md)
- [ ] CstAtt06 encore nécessaire comme marqueur si la vérification par
tâche active suffit ? (@Fabien) → voir
[Job réception production](../05-agv/job-reception-production.md)
- [ ] Fréquence des callbacks `vehicle/event` iGO pour les mises à
jour de position — risque de flood du webhook receiver (@Nicolas)
→ voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Taille max et caractères autorisés dans `customMetaData` iGO
(@STILL)
→ voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Les `customMetaData` sont-elles ré-émises dans les callbacks
transport iGO ? (@STILL)
→ voir [Intégration Still iGo](../05-agv/still-igo-integration.md)
- [ ] Création/modification de Location via API iGO — actuellement
GET only (@STILL)
→ voir [Stations et routes AGV](../05-agv/agv-stations-routes.md)
- [ ] Gestion Pallet Shuttle via iGO (LoadType = 1) — hors scope
actuel ? (@Théo)
- [ ] Multi-warehouse iGO : un seul site supposé — impact extension
future ? (@Michael)
- [ ] Visite terrain 29/05 — confirmation par Still de l'espace max
palette/convoyeur ~45 mm (@Théo)
-> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
- [ ] Visite terrain 29/05 — mesure réelle SAS7 lors de l'implantation
(@Abdennaim)
-> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
- [ ] Visite terrain 29/05 — solution Still pour augmenter distance
mât/bord palette : quel impact sur les specs AGV ? (@Théo / @Still)
-> voir [Troubleshooting AGV](../05-agv/agv-troubleshooting.md)
## Admin / Transverse
- [ ] Rapports standards — exclus de l'AF V1.5, périmètre à définir (@Justine)
- [ ] Vues EasyWMS — sauf impact processus fonctionnel, exclus AF V1.5 (@Justine)
- [ ] Layout complet (postes de picking inclus) — exclus AF V1.5 (@Théo)
## Points fermés (ateliers expédition DEV)
Les points suivants ont été tranchés lors des ateliers DEV expédition :
- [x] **SOR au numéro de support** → Fermé : jamais au numéro de support
- [x] **FEFO sans DLC** → Fermé : abandonné, FIFO journalier retenu
- [x] **Message MOV** → Fermé : annulé (inutile)
- [x] **Gestion FIFO canal** → Fermé : FIFO 24h standard, économie de
mouvement prioritaire
- [x] **Custom attributes vs attributs logistiques** → Tranché : attributs
logistiques avec masquage écrans inutiles
- [x] **Process litige sac endommagé** → Fermé : flux décrit (bouton
Problème + verrou support + buffer litige), à confirmer avec client
- [x] **Statut de stock F2 si aucun statut** → Fermé : REDFLAG, pousser
pour ne pas faire
- [x] **Anoxie : flux automatique** → Fermé : à prévoir si temps disponible
- [x] **Fréquence image de stock (WSC)** → Fermé : à définir (toutes les
X heures)
## Éléments exclus de l'AF V1.5
Pour mémoire, les éléments suivants sont explicitement exclus du périmètre :
- Choix fournisseur AGV
- Layout complet (postes de picking inclus)
- Rapports standards
- Vues EasyWMS hors impact processus fonctionnel
## Historique des modifications
| Date | Auteur | Modification |
|------|--------|-------------|
| 2026-05-05 | Arthur | Création depuis AF V1.5 |
| 2026-05-05 | Arthur | Ajout questions ateliers DEV réception + expédition |
| 2026-05-06 | Arthur | Ajout 13 questions ERP consolidées + LIM-62/63/64/65 |
| 2026-05-12 | Arthur | Ajout questions LIM-66→76, LIM-80→89, picking séquençage, AGV iGO |
| 2026-05-13 | Arthur | Fermeture URL API + token SAP, ajout A1-A4 + B1-B2 + PS (récap LIM-72) |
| 2026-05-13 | Arthur | Ajout 3 questions terrain AGV (visite Still/Mecalux 29/05) |
wiki/limagrain/README.md
+97
View File
@@ -0,0 +1,97 @@
---
title: "Wiki Limagrain — Table des matières"
tags: [index, limagrain]
status: draft
last_updated: 2026-05-12
---
# Wiki Limagrain — Table des matières
> **Périmètre** : ce wiki documente les spécificités projet Limagrain par rapport
> au standard EasyWMS. Pour les concepts génériques, se référer au
> [wiki standard](../_index.md).
## Sections
### 01 — Inbound
- [Vue d'ensemble](01-inbound/_index.md)
- [Gestion des camions](01-inbound/gestion-camions.md)
- [Réception fournisseur](01-inbound/reception-fournisseur.md)
- [Réception retour](01-inbound/reception-retour.md)
- [Contrôle qualité réception](01-inbound/controle-qualite-reception.md)
- [Étiquette RFID](01-inbound/etiquette-rfid.md)
- [Flux ERP inbound](01-inbound/flux-erp-inbound.md)
### 02 — Stockage
- [Vue d'ensemble](02-stockage/_index.md)
- [ASRS / Miniload](02-stockage/asrs-miniload.md)
- [Configuration Galileo](02-stockage/galileo-config.md)
- [Stratégies de putaway](02-stockage/putaway-strategies.md)
- [Zones de stockage](02-stockage/zones-stockage.md)
- [Défragmentation](02-stockage/defragmentation.md)
- [Processus d'anoxie](02-stockage/processus-anoxie.md)
- [Gestion des palettes vides](02-stockage/palettes-vides.md)
### 03 — Picking
- [Vue d'ensemble](03-picking/_index.md)
- [Picking combinatoire](03-picking/picking-combinatoire.md)
- [Stations de picking](03-picking/stations-picking.md)
- [Job d'assignation PK (Mega Job)](03-picking/job-assignation-pk.md)
- [Séquençage TK → PS](03-picking/sequencage-tk-ps.md)
- [Séquençage TK → PS — Historique](03-picking/sequencage-tk-ps-historique.md)
- [Placement PS → PK (choix de table)](03-picking/placement-ps-pk.md)
- [Waves et groupes](03-picking/waves-groupes.md)
- [Replenishment](03-picking/replenishment.md)
- [Consolidation / Regroupement](03-picking/consolidation-regroupement.md)
- [Échantillonnage](03-picking/echantillonnage.md)
### 04 — Outbound
- [Vue d'ensemble](04-outbound/_index.md)
- [Flux expédition](04-outbound/flux-expedition.md)
- [Shipping Orders](04-outbound/shipping-orders.md)
- [Séquençage shipping par STOP](04-outbound/sequencage-shipping-stop.md)
- [Consolidation et chargement](04-outbound/consolidation-chargement.md)
- [Flux ERP outbound](04-outbound/flux-erp-outbound.md)
### 05 — AGV
- [Vue d'ensemble](05-agv/_index.md)
- [Intégration Still iGo](05-agv/still-igo-integration.md)
- [Stations et routes AGV](05-agv/agv-stations-routes.md)
- [Job réception production → ASRS](05-agv/job-reception-production.md)
- [Job réception fournisseur/retour → PK](05-agv/job-reception-pk.md)
- [Troubleshooting AGV](05-agv/agv-troubleshooting.md)
### 06 — Interface ERP
- [Vue d'ensemble](06-erp-interface/_index.md)
- [Référence messages](06-erp-interface/messages-reference.md)
- [Données principales et stock](06-erp-interface/donnees-principales.md)
- [LOC — Message périodique](06-erp-interface/loc-message-periodique.md)
- [Intégration GNA → SAP-CPI](06-erp-interface/gna-sap-cpi.md)
- [Mapping ERP-WMS](06-erp-interface/mapping-erp-wms.md)
- [Monitoring interface](06-erp-interface/interface-monitoring.md)
### 07 — Administration
- [Vue d'ensemble](07-admin/_index.md)
- [Utilisateurs et groupes](07-admin/utilisateurs-groupes.md)
- [Paramètres projet](07-admin/parametres-projet.md)
- [AD Customs](07-admin/ad-customs.md)
- [Contacts projet](07-admin/contacts-projet.md)
### 08 — Transverse
- [Vue d'ensemble](08-transverse/_index.md)
- [Tickets Jira clés](08-transverse/jira-tickets-cles.md)
- [Décisions architecture](08-transverse/decisions-architecture.md)
- [Questions ouvertes](08-transverse/questions-ouvertes.md)
- [Historique projet](08-transverse/historique-projet.md)
## Ressources
- [Glossaire Limagrain](glossaire-limagrain.md)
wiki/limagrain/glossaire-limagrain.md
+182
View File
@@ -0,0 +1,182 @@
---
title: "Glossaire Limagrain"
tags: [glossaire, limagrain, référence]
status: draft
last_updated: 2026-05-13
author: Arthur
---
# Glossaire Limagrain
> **Résumé** : termes et acronymes spécifiques au projet Limagrain, complémentaires
> au [glossaire standard EasyWMS](../glossary.md).
| Terme | Signification |
|-------|---------------|
| CstAtt | Custom Attribute — handshake dans le picking combinatoire |
| CR V3.0 | Change Request version 3.0 — architecture 4 jobs picking combinatoire |
| SOR | Shipping Order Request — message ERP entrant, crée un ordre d'expédition |
| RUT | Route — message ERP entrant, définit une tournée transporteur |
| SOF | Shipping Order Fulfilled — message ERP sortant, ordre expédié |
| LOF | Load Order Fulfilled — message ERP sortant, chargement camion terminé |
| ASN | Advanced Shipping Notice — pré-avis de réception avec contenu connu |
| PIE | Station de pesée automatique |
| PDL | Picking Dedicated Location — emplacement dédié picking |
| ASRS | Automatic Storage and Retrieval System — stockage automatique |
| TK | Transstockeur (miniload) |
| TMS | Transport Management System (Galileo chez Mecalux) |
| AD | Application Dictionary — framework métadonnées EasyWMS |
| HU | Handling Unit — palette identifiée par un numéro unique (étiquette RFID) |
| ROR | Reception Order Request — message ERP entrant, crée un ordre de réception |
| ROF | Reception Order Fulfilled — message ERP sortant, ordre de réception clôturé |
| REF | Reception Fulfilled — message ERP sortant, réception individuelle finalisée |
| ITM | Item Master — message ERP entrant, synchronisation des articles/lots |
| STV | Stock Variation — message WMS sortant, notification de variation de stock |
| STR | Stock Request — message ERP entrant, demande changement statut/propriétaire/article |
| STC | Stock Confirmation — message WMS sortant, confirmation changement statut |
| PCK | Passage Conteneur Client — message WMS sortant [CUSTOM], info passage en conteneur client |
| LOC | Location — message WMS sortant [CUSTOM], info emplacement de stockage |
| MOV | Movement — message WMS sortant [CUSTOM], info déplacement stock entre palettes |
| CHG | Change — message ERP entrant [CUSTOM], changement article ou propriétaire |
| ERR | Error — message WMS sortant, erreur d'importation de message |
| MAG01 | Magasin automatique Limagrain — 4 allées TK |
| NIMP15 | Type palette vide — US 100×120 conforme ISPM15 |
| FERT | Produit fini (type article SAP) |
| ZSIZ | Semi-fini calibré (type article SAP) — déclenche ajustement poids au PIE |
| NAV | Navette — convoyeur de transfert entre zones |
| TE | Table d'Entrée — station d'entrée vers l'ASRS |
| TS | Table de Sortie — station de sortie depuis l'ASRS |
| ET | Table intermédiaire (Estación de Transferencia) |
| REAC | Poste de reconditionnement |
| TP | Table de Préparation — emplacement sur un îlot de travail |
| PK | Poste de travail (Picking station) |
| L&F | Lost & Found — emplacement virtuel pour conteneurs perdus |
| GNA | Generic Network Adapter — service communication ERP ↔ EasyWMS |
| SCR | Stock Count Request — message ERP entrant, demande image de stock |
| WSC | Warehouse Stock Confirmation — message WMS sortant, confirmation image de stock |
| COR | Count Order Request — message ERP entrant, demande d'inventaire |
| F9 | Statut de stock « Sacs sales » — applicable au retour client |
| B6 | Statut de stock « Non conforme » — applicable au retour client |
| WF02 | Code site Limagrain dans l'interface ERP |
| PROFIL_STANDARD | Profil logistique articles classiques (code produit + propriétaire + description + destination) |
| PROFIL_PALETTE | Profil logistique palettes bois vides |
| ItemCode | Champ EasyWMS contenant le code lot SAP (= clé article WMS) |
| Bag/Pal | Nombre de sacs par palette (= ContainerQty dans ITM) |
| DESADV | Type message SAP pour livraison fournisseur/intersite (utilisé dans ROR) |
| ORDRSP | Type message SAP pour retour client (utilisé dans ROR) |
| vassist | Virtual assistant — outil SmartUI pour configurer les modes de postes de travail |
| WfAction | Workflow Action — bouton custom dans la workstation (ex. réappro palettes vides) |
| ZPL | Zebra Programming Language — format requis pour imprimantes étiquettes RFID |
| QUAI_TEMPORAIRE | Quai fictif par défaut assigné aux OS, accessible par toutes les images de quai |
| QUAI_RECERTIF | Quai virtuel destination des palettes en recertification (route via PK) |
| CstData | Custom Data — données transmises à Galileo (ex: programme filmage, commande impression) |
| STOP | Numéro d'arrêt dans une tournée RUT — ordonnance le chargement (inverse de l'ordre de livraison) |
| isCritical | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| isRequired | Flag SOR.Line — rend une ligne obligatoire pour l'expédition |
| AllowAssignStockExcess | Flag SOR.Line — autorise l'assignation même si le stock dépasse la demande |
| OnStockAdjust | Workflow WMS qui recalcule l'assignation après ajustement de stock au picking |
| StackerCrane_SortTasks_PR | Workflow de tri des tâches de picking par gerbabilité (stack) |
| COF | Count Order Fulfilled — message WMS sortant, confirmation échantillonnage |
| SSCC | Serial Shipping Container Code — identifiant unique palette (étiquette GS1) |
| GS1 | Organisation de normalisation — fournit les plages SSCC |
| CPI | Canal Point d'Intégration SAP — middleware traitement messages (volumétrie WSC) |
| Z-Bag | Sacs vides (emballage) — stockés en ASRS pour livraison client uniquement |
| SingleReceipt | Paramètre ROR : true = pas de reliquat WMS (une seule réception par ordre) |
| AutoReleaseDate | Date de libération automatique d'un SOR/RUT (PlannedShippingDate - 48h) |
| TransactionalLineList | Flag SOR : true = tout ou rien (refus total si une ligne est en erreur) |
| CompleteSorList | Flag RUT : true = SOR absents de la mise à jour sont supprimés |
| ERPReasonCode | Code motif ERP (ex: ZSC1) transmis dans les messages de variation stock |
| OutboundClassCode | Classification du type de sortie : PRODUCTION, RECERTIFICATION, CLIENT |
| IsSlave | Flag conteneur LOF : true = palette support (pas le stock directement) |
| QUAI_RECERTIFICATION | Quai fictif assigné aux SOR de recertification dans le message ERP |
| PARKING | Emplacement fictif d'attente camion — quai par défaut avant assignation réelle |
| CST_DockStationsWorkloadForView | Entité custom affichant l'occupation des quais (réceptions + tournées + plaques) |
| InboundClassCode | Code de classe de préavis de réception — contrôle de cohérence à la création réception |
| PALETTE_US | Type de support virtuel créé lors de la déclaration image de quai |
| HORS TOLERANCE | Verrou support posé au PIE si écart de poids détecté (hors retour) — palette admise en ASRS |
| ECART RETOUR | Verrou support posé au PIE si écart de poids sur un retour client — palette rejetée |
| FILMAGES | Paramètre WMS contenant la liste des programmes de filmage (`code;libellé|…`) |
| CstAtt02 (support) | Flag Big Bag sur le support (`true`/`false`) — set au poste de travail réception |
| CstAtt03 (support) | Flag anoxie sur le support (`true`) — set au poste de travail réception |
| CstAtt05 (support) | Programme de filmage (`0`, `A`, `B`…) — set au poste de travail réception |
| AI (GS1) | Application Identifier — préfixe numérique dans un QR Code GS1 identifiant le type de donnée |
| MODES_PKxx | Paramètre SmartUI définissant les modes autorisés + priorité pour un PK (`MODE;PRIO\|…`) |
| PK_ADJACENT | Paramètre SmartUI listant les paires de postes adjacents (`PK01;PK02\|…`) |
| PK_BIGBAG | Paramètre définissant quels PK autorisent les big-bags (P5, P6 avec palan) |
| Mega Job | Job unique « chef d'orchestre » des assignations de tâches vers les PK ([LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) |
| DESTINATION_PRODUCTION | Paramètre du job LIM-71 — code du buffer d'entrée production pour les tâches AGV |
| CstAtt04 (support) | Type de réception du support : "ASN" = production, sinon = fournisseur/intersite/retour |
| CstAtt06 (support) | Marqueur de traitement du job LIM-71 — contient la destination après traitement |
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots retour client |
| EV_RETURN | Champ réponse API SAP : "X" = lot valide |
| ET_BATCH | Tableau réponse API SAP : lots autorisés avec MATNR, CHARG, BATCH_OFF, EV_DEPLOY |
| EV_DEPLOY | Champ ET_BATCH : "X" = lot autorisé pour la réception retour |
| CstAtt11 (support) | Marqueur de rangement ASRS pour retour client — `true` une fois le support rangé, jamais remis à false |
| CstAtt01 (réception) | Flag clôture retour en cours — `true` = en attente de rangement ASRS complet |
| CstAtt01 (OE) | Flag hors tolérance — `true` = bloque auto-close OE et ROF, affichage rouge |
| AutoCloseReception | Paramètre WMS : `true` = clôture auto de la réception quand conditions custom remplies |
| AutoCloseInboundOrder | Paramètre WMS : `true` = auto-clôture OE à 100 % ou dans tolérance (ROF envoyé) |
| Reception_Close_PR_V2 | Workflow custom de clôture de réception — gère condition retour (A) et tolérance par ligne (B) |
| NON RANGEE | Valeur zone de stockage dans le REF pour supports non encore rangés en ASRS (fournisseur/intersite uniquement) |
| Mini Job | Sous-workflow du Mega Job — exécute l'assignation effective pour un type de tâche |
| LOC.SEND | Transaction custom WMS déclenchée par le job LOC — signal au GNA pour générer le message LOC |
| BOO (script) | Script Boo exécuté par le GNA — contient la logique métier d'agrégation et formatage des messages |
| SAP-CPI | SAP Cloud Platform Integration — middleware cloud SAP réceptionnant les messages WMS via API REST |
| ATHInboundMessage | Endpoint unique SAP-CPI recevant tous les messages WMS (`/http/ATHInboundMessage`) |
| MessageSAP | Code de routage CPI (ATH201=LOC, ATH202=LOF, ATH214=batch, ATH215=REF Supplier, ATH217=REF Return) |
| CstAtt20 (REF) | Type de préavis de réception (Supplier/Return) — set par REF01Observer pour routage CPI |
| CPI_AUTH_URL | Clé config GNA — URL du serveur d'authentification OAuth SAP |
| CPI_ENDPOINT_URL | Clé config GNA — endpoint unique SAP-CPI |
| VBELN | Code livraison sortante SAP — champ LOC pour ACTION=P (= SorCode côté WMS) |
| POSNR | Ligne de livraison sortante SAP — champ LOC pour ACTION=P |
| ASRS1..4 / ASRS34 | Codes zones SAP correspondant aux TK1-4 pour le message LOC |
| PK_TRANSPORTEUR_MESSAGERIE | Paramètre par transporteur — contient le code PK assigné aux commandes Messagerie de ce transporteur |
| MAX_NB_BUFFER_PK | Paramètre de capacité buffer par PK (valeur par défaut : 3) |
| ES_X | Zone d'attente (buffer) devant les postes de sortie — stockage temporaire des palettes en attente de séquençage |
| TaskCreatedEvent | Événement WMS déclenché à la création d'une tâche — utilisé pour le séquençage TK→PS |
| OutboundOrderReleasedEvent | Événement WMS déclenché au (re)lancement d'un OS — utilisé pour le séquençage TK→PS |
| PC | Palette Complète — palette d'expédition sans besoin de picking |
| PP | Palette de Picking — palette mère qui part au PK pour prélèvement |
| PF | Palette Fille — palette sortie du picking, retour ASRS |
| Défrag client custom | Custom LIM-87 : défrag shipping par tournée quand quai non assigné — éligibilité tout-ou-rien au niveau RUT |
| Stacker crane tri multi-TK | Custom LIM-88 : override WF tri stacker crane pour analyser les STOP sur tous les TK (pattern Bardinet) |
| Line.CstAtt | Numéro de séquence (entier) sur chaque tâche de picking — définit l'ordre de sortie ASRS. Ex-aequo possibles |
| OS.CstAtt | Flag booléen sur l'OS : `false` = séquences non calculées (stacker_crane bloqué), `true` = prêt |
| CONTROLE_TRAITEMENT_COMMERCIAL | Paramètre booléen contrôlant le traitement commercial dans le séquençage picking |
| iGO easy | Fleet manager AGV STILL (KION Group) — variante simplifiée de PACS |
| PACS | Productized Automated Concept Solutions — offre fleet manager KION large couvrant iGO |
| E'tricc | Moteur interne du fleet manager iGO/PACS |
| MyMA | Suite logicielle admin KION : Vue3 + .NET8 + Postgres — héberge iGO côté admin |
| EXV CB iGo | Modèle physique AGV — gerbeur électrique automatisé STILL (longueur 3 383 mm) |
| Transport (iGO) | Ordre de transport iGO — équivalent de l'`AgvTask` EasyWMS |
| Load (iGO) | Charge physique iGO — équivalent du `Container` EasyWMS |
| LoadType (iGO) | Catalogue de types de charge iGO — équivalent du `ContainerType` |
| Location (iGO) | Point physique iGO avec `possibleActions` — équivalent de `IRealLocation` |
| Group (iGO) | Ensemble de Locations iGO pour décision tardive — équivalent de `WorkingZone` |
| transportHostId | Identifiant hôte (WMS) du transport iGO — correspond à `OrderExtId` (= TaskNumber) |
| X-API-Key | Méthode d'authentification officielle API iGO (confirmée par STILL, FAQ #8) |
| Gateway iGO | Pool IIS C# .NET 8 — middleware côté flotte à développer par Mecalux pour traduire tables AGV_* ↔ API REST PACS |
| AGV_OUTPUTQUEUE | Table FIFO sortante — ordres WMS vers fleet manager (via middleware) |
| AGV_INPUTQUEUE | Table FIFO entrante — phases/statuts fleet manager vers WMS (via middleware) |
| AGV_EAG | Table data des ordres AGV — payload détaillé de chaque ordre (lu par le middleware via batchId) |
| AGV_AGE | Table data des phases AGV — payload détaillé de chaque événement reçu du fleet manager |
| AGV_AGS | Table data des statuts AGV — payload détaillé du statut de chaque véhicule |
| ATH002 | Code interface SAP → EasyWMS — fiche article (BATMAS → ITM01) |
| ATH103A | Code interface SAP → EasyWMS — ordre de réception fournisseur (DELIVRY07 → ROR01) |
| ATH108 | Code interface SAP → EasyWMS — ordre de réception retour (ORDRSP → ROR01) |
| ATH103B | Code interface SAP → EasyWMS — ordre de sortie (SHPUNT7 → RUT) |
| ATH102BOM | Code interface SAP → EasyWMS — ordre d'expédition production (LOIPRO → SOR) |
| ATH111 | Code interface SAP → EasyWMS — HU à recevoir ou changement HU (ZSTKATH11 → ASN/STR) |
| ATH302 | Code interface SAP → EasyWMS — tâche inventaire/échantillon (ZQMINSPLOT → COR) |
| ATH214 | Code interface EasyWMS → SAP — vérification lot retour client (Z_IATH214) |
| ATH215 | Code interface EasyWMS → SAP — bon de réception fournisseur (Z_IAT215 → REF) |
| ATH217 | Code interface EasyWMS → SAP — bon de réception retour (Z_IAT217 → REF) |
| ATH201 | Code interface EasyWMS → SAP — mouvement stock (Z_IAT201 → LOC/STV) |
| ATH202 | Code interface EasyWMS → SAP — chargement / goods issue (Z_IAT202 → LOF) |
| IV_LGNUM | Champ ATH214 requête — code site (CHAR 4, toujours "WF02") |
| IV_BATCH_OFF | Champ ATH214 requête — lot officiel scanné (CHAR 30) |
| IV_RETURN | Champ ATH214 requête — code OE retour (CHAR 10) |
| MATNR | Champ ATH214 réponse — product code SAP = code lot WMS (CHAR 40, mapping inversé) |
| CHARG | Champ ATH214 réponse — lot SAP = code article WMS (CHAR 10, mapping inversé) |
| ItemAlias | Entité EasyWMS — alias d'un article (utilisé pour le lot officiel Limagrain) |
| CstAtt12 (support) | **Proposé** : code OE associé à la palette dès l'image de quai (LIM-64 évol., reporté) |