màj wiki avec retour MES lot-5 AD
This commit is contained in:
Arthur Ria
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 | — |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
| Mes
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -0,0 +1,488 @@
|
||||
---
|
||||
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 (é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 |
|
||||
@@ -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 | — |
|
||||
@@ -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 |
|
||||
Reference in New Issue
Block a user