màj wiki avec retour MES lot-5 AD
This commit is contained in:
Arthur Ria
@@ -0,0 +1,239 @@
|
||||
---
|
||||
title: "Contrôle qualité réception — Vérification poids PIE"
|
||||
tags: [inbound, PIE, poids, verrou, inventaire, qualité]
|
||||
status: draft
|
||||
standard_ref: architecture/galileo-integration.md
|
||||
jira_refs: [LIM-66]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Contrôle qualité réception — Vérification poids PIE
|
||||
|
||||
> **Résumé** : mécanisme [CUSTOM] de contrôle de poids au passage PIE avec
|
||||
> calcul de tolérance par type article, application automatique de verrous
|
||||
> et mise à jour du poids unitaire.
|
||||
|
||||
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
|
||||
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
|
||||
**tous les processus** (réception production, extérieure, retour, picking,
|
||||
regroupement, échantillonnage).
|
||||
|
||||
## Contrôles au PIE
|
||||
|
||||
Le PIE effectue les contrôles suivants :
|
||||
|
||||
| Contrôle | Critère de validation |
|
||||
|----------|----------------------|
|
||||
| Étiquette RFID | Connue (détectable) |
|
||||
| Hauteur | ≤ 1900 mm |
|
||||
| Largeur | ≤ 1100 mm |
|
||||
| Longueur | ≤ 1300 mm |
|
||||
| Poids | ≤ 1250 kg |
|
||||
| État palette bois | Correct (lames TK ne doivent pas toucher le bois, pas de ski manquant) |
|
||||
|
||||
> Les erreurs sont configurables par type dans easyS — possibilité
|
||||
> d'envoyer vers différentes destinations selon le type d'erreur
|
||||
> (station error type). Exemple : scotch qui dépasse → station de
|
||||
> reconditionnement, palette vraiment non conforme → rejet complet.
|
||||
|
||||
## Formule de calcul du poids
|
||||
|
||||
### Étape 1 — Poids des lignes de stock
|
||||
|
||||
```
|
||||
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
|
||||
```
|
||||
|
||||
### Étape 2 — Répartition au prorata entre lignes de stock
|
||||
|
||||
Le poids mesuré est réparti au prorata entre les différentes lignes
|
||||
de stock.
|
||||
|
||||
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
|
||||
(champ « Poids » de la ligne de stock), puis poids conversion ITM
|
||||
(champ « Poids théorique » de la ligne de stock).
|
||||
|
||||
**Formules :**
|
||||
|
||||
```
|
||||
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
|
||||
Poids réel de la ligne = Poids lignes de stock × Ratio
|
||||
```
|
||||
|
||||
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
|
||||
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
|
||||
Poids mesuré au PIE = 60 kg (hors palette bois).
|
||||
|
||||
| Article | Poids théorique | Ratio | Poids réel calculé |
|
||||
|---------|-----------------|-------|---------------------|
|
||||
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
|
||||
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
|
||||
| **Total** | 50 kg | 100 % | **60 kg** |
|
||||
|
||||
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
|
||||
|
||||
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
|
||||
unitaire mesuré :
|
||||
|
||||
```
|
||||
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
|
||||
```
|
||||
|
||||
| Donnée | Champ WMS |
|
||||
|--------|-----------|
|
||||
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
|
||||
| Poids réel pesé (total) | Champ standard « poids balance » du support |
|
||||
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
|
||||
|
||||
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
|
||||
> précédente), c'est ce poids unitaire qui est utilisé dans les calculs
|
||||
> de ratio à l'étape 2 — à la place du poids théorique ITM.
|
||||
|
||||
> **Mise à jour du stock : OUI** — le poids calculé est stocké dans
|
||||
> CstAtt01 de la ligne de stock.
|
||||
> **Mise à jour de l'ITM : NON** — le poids théorique de la fiche
|
||||
> article reste inchangé. Raison : le poids varie en fonction de la
|
||||
> production (début/fin de prod), chaque pesée est unique.
|
||||
|
||||
> Le poids est quand même appliqué et recalculé, même en cas de
|
||||
> blocage (verrou).
|
||||
|
||||
## Vérification de la tolérance et blocage
|
||||
|
||||
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
|
||||
revue de code.
|
||||
|
||||
### [CUSTOM] Palettes mono-référence
|
||||
|
||||
**Condition de blocage** : si l'écart de poids correspond à un écart
|
||||
d'une ligne de stock (article manquant ou en trop → écart ≥ poids
|
||||
unitaire de l'article) → blocage via verrou sur le **support** (pas sur
|
||||
le stock) + alerte SmartUI.
|
||||
|
||||
### [CUSTOM] Palettes multi-références — seuil d'alerte
|
||||
|
||||
Pour les palettes contenant plusieurs articles différents, le système
|
||||
utilise le **plus petit poids unitaire** comme seuil d'alerte. Si
|
||||
l'écart total ≥ poids du plus petit article → blocage + alerte.
|
||||
|
||||
### Verrous appliqués
|
||||
|
||||
Deux verrous possibles selon le flux :
|
||||
|
||||
| Verrou | Flux | Comportement post-PIE |
|
||||
|--------|------|----------------------|
|
||||
| **HORS TOLERANCE** | Tous sauf retour client | La palette **entre quand même dans l'ASRS** malgré le verrou |
|
||||
| **ECART RETOUR** | Retour client uniquement | La palette est **refusée et envoyée en rejet** (destination gérée par EasyS) |
|
||||
|
||||
### Notification
|
||||
|
||||
- Création d'une **notification SmartUI** via le circuit classique de
|
||||
notifications basé sur un event (pas d'event custom)
|
||||
- Le verrou est posé sur le **support** (pas sur le stock)
|
||||
- Notification dédiée au rejet générée dans le cas ECART RETOUR
|
||||
|
||||
### Comportement selon le flux (détail)
|
||||
|
||||
| Processus | Verrou appliqué | Action |
|
||||
|-----------|-----------------|--------|
|
||||
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
|
||||
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
|
||||
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
|
||||
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
|
||||
Dans tous les cas, le poids est quand même appliqué et recalculé.
|
||||
|
||||
### [CUSTOM] Type ZSIZ — Ajustement automatique
|
||||
|
||||
Si le type d'article est **ZSIZ** (semi-fini calibré / big-bag), un
|
||||
message d'ajustement de stock est envoyé vers SAP via **WSC** contenant
|
||||
le poids réel de la HU, **indépendamment de la tolérance**.
|
||||
|
||||
**Gestion du timing avec le REF :**
|
||||
|
||||
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
|
||||
pas encore la palette (REF pas encore envoyé)
|
||||
- **Solution** : chaque palette présente dans un REF est flaguée dans
|
||||
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
|
||||
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
|
||||
REF, un event déclenche la transaction
|
||||
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
|
||||
à SAP
|
||||
|
||||
## Gestion des verrous
|
||||
|
||||
### Consultation
|
||||
|
||||
Vue « Entrepôt → Verrous conteneur » :
|
||||
|
||||
- Verrou appliqué par conteneur
|
||||
- Date d'application
|
||||
- Possibilité de débloquer (lever le verrou)
|
||||
|
||||
### Impact sur l'expédition
|
||||
|
||||
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
|
||||
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
|
||||
avant tout processus suivant (picking, regroupement, échantillonnage).
|
||||
|
||||
### [CUSTOM] Dérogation poids
|
||||
|
||||
Pour les processus de **regroupement** et **échantillonnage**, si la palette
|
||||
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
|
||||
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
|
||||
|
||||
## Post-traitements
|
||||
|
||||
- Réception production : **ASO et ASK désactivés**
|
||||
- Les messages post-PIE ne sont pas générés pour le flux production
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le contrôle poids s'applique à **chaque** passage PIE — une palette
|
||||
peut passer le PIE plusieurs fois (réception → picking → restockage).
|
||||
|
||||
⚠️ Le poids est porté par le **stock** (CstAtt01 de la ligne), pas par
|
||||
la fiche article ITM — chaque pesée est unique.
|
||||
|
||||
⚠️ Les palettes avec verrou « Réception » sont prioritaires dans
|
||||
l'assignation de stock pour l'échantillonnage (permet de combiner
|
||||
recomptage + échantillonnage).
|
||||
|
||||
⚠️ Verrou posé sur le **support** (pas sur le stock) — différent du
|
||||
comportement standard.
|
||||
|
||||
⚠️ Pour les palettes multi-références, le seuil d'alerte est le plus
|
||||
petit poids unitaire parmi toutes les lignes de stock.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [ ] Valeurs exactes des tolérances par type article (@Justine)
|
||||
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
|
||||
- [ ] Poids variable — vérifier si le standard gère la capture de
|
||||
poids avec poids moyen activé (@Nicolas)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement : prorata, multi-ref, verrou support, ZSIZ timing |
|
||||
| 2026-05-12 | Arthur | LIM-66 : verrous HORS TOLERANCE / ECART RETOUR, CstAtt01 poids unitaire, comportement post-PIE |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
|
||||
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Étiquette support RFID — Format mono-référence"
|
||||
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-68]
|
||||
confluence_refs: []
|
||||
sources: [LIM-68_Etiquette_RFID.md]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Étiquette support RFID — Format mono-référence
|
||||
|
||||
> **Résumé** : étiquette A5 imprimée lors de la réception
|
||||
> fournisseur/intersite, contenant les informations du support (code,
|
||||
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au
|
||||
> standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
|
||||
ses HU (supports) dans le flux de réception fournisseur/intersite.
|
||||
L'étiquette est imprimée automatiquement à la confirmation de création
|
||||
du conteneur sur le poste de travail (voir
|
||||
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
|
||||
peut aussi être réimprimée depuis le menu principal du poste (action
|
||||
« Imprimer étiquette »).
|
||||
|
||||
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
|
||||
attente déploiement pour test.
|
||||
|
||||
## Format A5 — Contenu de l'étiquette
|
||||
|
||||
| N | Champ | Source WMS | Remarque |
|
||||
|---|-------|-----------|----------|
|
||||
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
|
||||
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
|
||||
| 2 | Code-barres | Code 128 du code support au format GS1 | |
|
||||
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
|
||||
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
|
||||
| 5 | Traitement commercial | `ITM.Family.Description` | |
|
||||
| 6 | Variety print on bag | Tel quel | |
|
||||
| 7 | — | `ITM.CstAtt03` | |
|
||||
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
|
||||
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
|
||||
| 10 | Code GTIN | `ITM.CstAtt05` | |
|
||||
| 11 | Date | — | Vide (date non connue de l'ERP) |
|
||||
| 12 | QR Code GS1 | Voir section ci-dessous | |
|
||||
|
||||
## QR Code GS1
|
||||
|
||||
Le QR Code GS1 encode les identifiants suivants :
|
||||
|
||||
| AI (Application Identifier) | Contenu | Source |
|
||||
|------------------------------|---------|--------|
|
||||
| `00` | Numéro HU (code support) | Code support WMS |
|
||||
| `01` | Code GTIN | `ITM.CstAtt05` |
|
||||
| `10` | Lot officiel | Premier Alias de l'article |
|
||||
| `21` | Lot SAP | `ITM.Code` |
|
||||
| `37` | Quantité | Quantité déclarée |
|
||||
|
||||
> La date de production (AI `11`) a été **supprimée** du QR Code.
|
||||
|
||||
## Encodage RFID (ZPL)
|
||||
|
||||
L'impression de l'étiquette combine l'impression physique (texte,
|
||||
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
|
||||
des commandes **ZPL** (Zebra Programming Language).
|
||||
|
||||
### Structure de base
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
; --- Encodage RFID ---
|
||||
^RFW,H^FD<données>^FS
|
||||
|
||||
; --- Contenu imprimé ---
|
||||
^FO50,50^ADN,36,20^FD<texte affiché>^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
### Commandes ZPL utilisées
|
||||
|
||||
| Commande | Rôle |
|
||||
|----------|------|
|
||||
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
|
||||
| `^MMT` | Active le mode RFID sur l'imprimante |
|
||||
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
|
||||
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
|
||||
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
|
||||
|
||||
### Exemple concret
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
^MMT
|
||||
^RS8,,,1
|
||||
^RFW,A,0,5,3^FDSupport123456789012^FS
|
||||
^FO30,20^A0N,30,25^FDRapport de support^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
## Points d'attention
|
||||
|
||||
- L'imprimante doit être **compatible ZPL** avec encodage RFID
|
||||
(contrainte fournisseur à valider — voir question ouverte dans
|
||||
[Réception fournisseur](reception-fournisseur.md))
|
||||
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
|
||||
4 octets = 20 octets en banque User 3)
|
||||
- L'étiquette est au format **A5 paysage**
|
||||
- La date (champ 11) est volontairement vide car non connue de l'ERP
|
||||
au moment de la réception
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
|
||||
@@ -0,0 +1,195 @@
|
||||
---
|
||||
title: "Flux ERP inbound — Messages réception"
|
||||
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
|
||||
status: draft
|
||||
standard_ref: architecture/erp-integration.md
|
||||
jira_refs: []
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
|
||||
last_updated: 2026-05-06
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Flux ERP inbound — Messages réception
|
||||
|
||||
> **Résumé** : catalogue des messages ERP liés aux processus de réception
|
||||
> chez Limagrain, avec direction, déclencheur et contenu principal.
|
||||
|
||||
> **Standard EasyWMS** : → voir [ERP Integration](../../architecture/erp-integration.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
|
||||
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
|
||||
Pour les messages d'expédition, voir
|
||||
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
|
||||
|
||||
## Messages entrants (SAP → EasyWMS)
|
||||
|
||||
### ITM — Item Master
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Création/modification article dans SAP |
|
||||
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
|
||||
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
|
||||
|
||||
> ⚠️ Chez Limagrain, les **lots SAP** sont gérés comme des articles (descendus
|
||||
> via ITM). L'article Limagrain est un attribut du lot SAP.
|
||||
|
||||
### ASN — Advanced Shipping Notice
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Création HU avec code SSCC en production |
|
||||
| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation — permet suppression individuelle en cas d'annulation) |
|
||||
| Contenu | Numéro HU, article, lot SAP, [CUSTOM] propriétaire Limagrain, statut de stock, quantité (unités de vente) |
|
||||
| Timing | Envoyé dès création de la HU avec code SSCC |
|
||||
|
||||
**Attributs logistiques dans les lignes ASN** :
|
||||
|
||||
| Attribut logistique | Champ SAP | Usage |
|
||||
|---------------------|-----------|-------|
|
||||
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
|
||||
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
|
||||
| Source | Description produit | Désignation courte SAP |
|
||||
| Size | Destination (Pays) | Peut changer |
|
||||
|
||||
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
|
||||
statut (champ vide ou absent du JSON).
|
||||
|
||||
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
|
||||
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
|
||||
numéro de série.
|
||||
|
||||
### ROR — Reception Order Request
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
|
||||
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
|
||||
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
|
||||
|
||||
**Types de réception (InboundType)** :
|
||||
|
||||
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|
||||
|-------------|-------|--------------------------|-----------|
|
||||
| 0 (Fournisseur) | Livraisons DESADV | SupplierCode = "FOURNISSEUR" | Précisée par SAP (override profil) |
|
||||
| 1 (Retour) | Retours clients ORDRSP | AccountCode = "CLIENT" | Illimitée (ReceiveLessAllowed=true) |
|
||||
| 3 (Transfert) | Transferts inter-sites | — | 0% (palettes identifiées) |
|
||||
|
||||
**Paramètres clés** : SingleReceipt = true (pas de reliquat WMS),
|
||||
FreeQuantity non nécessaire. Pas de SSCC dans le ROR (récupéré au scan
|
||||
RFID en réception).
|
||||
|
||||
### [CUSTOM] API Lot SAP (retours clients uniquement)
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
|
||||
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
|
||||
| Requête | Lot officiel |
|
||||
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
|
||||
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
|
||||
|
||||
## Messages sortants (EasyWMS → SAP)
|
||||
|
||||
### REF — Reception Fulfilled
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
|
||||
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
|
||||
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
|
||||
| Contrainte | L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF |
|
||||
| Données | S'appuie sur les données **réelles** (pas théoriques) |
|
||||
|
||||
### ROF — Reception Order Fulfilled
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | Validation/clôture de l'ordre d'entrée |
|
||||
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
|
||||
| Reliquats | Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat |
|
||||
| Hors tolérance | ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise) |
|
||||
|
||||
### [CUSTOM] LOC — Location
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
|
||||
| Contenu | Numéro HU, station départ, station arrivée, workzone arrivée, emplacement arrivée |
|
||||
| Condition | Généré uniquement si stations départ et arrivée sont différentes |
|
||||
|
||||
## Diagramme de séquence — Réception production
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant SAP
|
||||
participant WMS as EasyWMS
|
||||
participant GAL as Galileo/PIE
|
||||
|
||||
SAP->>WMS: ITM (article/lot)
|
||||
Note over SAP,WMS: En amont
|
||||
SAP->>WMS: ASN (pré-notif HU)
|
||||
Note over SAP,WMS: À l'expédition source
|
||||
GAL->>WMS: Event PIE (RFID + poids)
|
||||
WMS->>WMS: Contrôle poids + rangement
|
||||
WMS->>GAL: Tâche stockage
|
||||
GAL->>WMS: End (palette stockée)
|
||||
WMS->>SAP: LOC (emplacement)
|
||||
```
|
||||
|
||||
## Diagramme de séquence — Réception extérieure
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant SAP
|
||||
participant WMS as EasyWMS
|
||||
participant PK as Poste travail
|
||||
participant GAL as Galileo/PIE
|
||||
|
||||
SAP->>WMS: ROR (ordre réception)
|
||||
WMS->>PK: Palette sur poste
|
||||
PK->>WMS: Déclaration contenu
|
||||
WMS->>GAL: Tâche évacuation → PIE
|
||||
GAL->>WMS: Event PIE
|
||||
WMS->>WMS: Contrôle + rangement
|
||||
GAL->>WMS: End (stockée)
|
||||
WMS->>SAP: LOC
|
||||
PK->>WMS: Clôture réception
|
||||
WMS->>SAP: REF (avec emplacements)
|
||||
WMS->>SAP: ROF
|
||||
```
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le message REF est retardé jusqu'à validation PIE de tous les conteneurs
|
||||
(peut prendre du temps si file d'attente PIE longue).
|
||||
|
||||
⚠️ Le message LOC n'est pas standard — c'est un [CUSTOM] spécifique
|
||||
Limagrain pour traçabilité emplacement dans SAP.
|
||||
|
||||
⚠️ Les modifications dans les master data ne doivent **pas** être faites
|
||||
directement dans EasyWMS (risque d'écrasement par prochain ITM).
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) — depuis CR consolidé ERP |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
|
||||
@@ -0,0 +1,348 @@
|
||||
---
|
||||
title: "Gestion des camions — Arrivée, quais et déclaration image de quai"
|
||||
tags: [inbound, camion, quai, TRF, image-de-quai, étiquette, SmartUI]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65]
|
||||
confluence_refs: []
|
||||
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
|
||||
last_updated: 2026-05-06
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Gestion des camions — Arrivée, quais et déclaration image de quai
|
||||
|
||||
> **Résumé** : flux complet depuis l'arrivée physique d'un camion jusqu'à la
|
||||
> déclaration des palettes sur une image de quai (poumon de réception). Couvre
|
||||
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
|
||||
> TRF de déclaration et l'impression d'étiquettes support.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
> Le standard prévoit la création manuelle de réceptions et leur association à
|
||||
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
|
||||
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
|
||||
> déclaration des palettes sur les images de quai.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
|
||||
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
|
||||
orientés via un affichage extérieur. Après déchargement physique, un cariste
|
||||
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
|
||||
qu'après cette déclaration que les AGV viennent récupérer les palettes.
|
||||
|
||||
Ce processus est commun à tous les types de réception (production, extérieure,
|
||||
retour). Les flux spécifiques de chaque type sont documentés dans les pages
|
||||
dédiées : [Réception fournisseur](reception-fournisseur.md),
|
||||
[Réception retour](reception-retour.md).
|
||||
|
||||
## Flux fonctionnel global
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant CH as Chauffeur
|
||||
participant AQ as Agent de quai
|
||||
participant SM as SmartUI
|
||||
participant AFF as Affichage extérieur
|
||||
participant CAR as Cariste (TRF)
|
||||
participant WMS as EasyWMS
|
||||
participant AGV as AGV
|
||||
|
||||
CH->>AQ: Annonce arrivée camion
|
||||
AQ->>SM: Crée réception + saisie plaque
|
||||
SM->>SM: Vérifie classes OE identiques
|
||||
AQ->>SM: Assigne quai (ou PARKING)
|
||||
SM->>AFF: Mise à jour affichage (WS)
|
||||
AFF->>CH: Plaque + quai assigné
|
||||
CH->>CH: Se gare au quai indiqué
|
||||
CH->>CAR: Déchargement physique
|
||||
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
|
||||
CAR->>CAR: TRF > Réceptions > Image de quai
|
||||
CAR->>WMS: Déclare nb palettes, poumon, position
|
||||
WMS->>WMS: Crée palettes virtuelles PALETTE_US
|
||||
WMS-->>CAR: Impression étiquettes (si type Autre)
|
||||
AGV->>AGV: Récupère palettes sur image de quai
|
||||
```
|
||||
|
||||
## Étape 1 — Annonce du camion (LIM-62)
|
||||
|
||||
### Création de la réception
|
||||
|
||||
L'agent de quai accède à la vue **Ordre d'entrée > Réceptions** dans SmartUI.
|
||||
Il crée une nouvelle réception en saisissant :
|
||||
|
||||
- **Plaque d'immatriculation** (champ "Camion", ex-"Document") — non
|
||||
obligatoire à la création, peut être renseignée après coup
|
||||
- **Destination** : `PARKING` (quai fictif d'attente) par défaut, ou un quai
|
||||
réel si disponible
|
||||
- **Ordres d'entrée** : sélection des OE du camion
|
||||
|
||||
### Contrôle de classe
|
||||
|
||||
> **Règle** : il est interdit de créer une réception mélangeant des OE de
|
||||
> classes de préavis de réception différentes (`InboundClassCode`).
|
||||
|
||||
Si l'utilisateur sélectionne des OE de classes différentes, un message
|
||||
d'erreur bloque la création :
|
||||
|
||||
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
|
||||
> classes de préavis de réception différentes"*
|
||||
|
||||
Ce contrôle est implémenté dans le `VAssistCreateReceptionOE` (steps 2 et 3)
|
||||
et dans la vue des ordres d'entrées. L'exception compare le `InboundClassCode`
|
||||
de chaque OE sélectionné au premier de la liste.
|
||||
|
||||
## Étape 2 — Assignation du quai (LIM-62)
|
||||
|
||||
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
|
||||
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
|
||||
assigne un quai réel.
|
||||
|
||||
### Règles d'assignation
|
||||
|
||||
- Le quai et l'image de quai sont réservés dès la sélection
|
||||
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
|
||||
place restante)
|
||||
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
|
||||
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
|
||||
libération
|
||||
- Modification possible a posteriori
|
||||
|
||||
### Tableau d'occupation des quais
|
||||
|
||||
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
|
||||
réceptions, tournées et OS associés avec les plaques correspondantes :
|
||||
|
||||
| Quai | Réceptions / Camions |
|
||||
|------|----------------------|
|
||||
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
|
||||
| QUAI_01 | |
|
||||
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
|
||||
| ... | |
|
||||
|
||||
Ce tableau est aussi disponible dans le `VAssistReceptionAssignDock` (step 1
|
||||
utilise l'entité `CST_DockStationsWorkloadForView` au lieu de `Station`).
|
||||
|
||||
## Étape 3 — Affichage chauffeur (LIM-63)
|
||||
|
||||
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
|
||||
sur le parking les quais assignés avec les plaques d'immatriculation.
|
||||
|
||||
### Spécifications
|
||||
|
||||
- Afficher uniquement les quais avec des réceptions ou OS associés
|
||||
- Prévoir l'affichage de **6 quais + le parking** sans scroll
|
||||
- Afficher les plaques (champ "Camion" / Document)
|
||||
|
||||
> **Référence technique** : dialogue EasyBuilder, cf. [documentation
|
||||
> Mecalux](https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md)
|
||||
|
||||
## Étape 4 — Déclaration image de quai via TRF (LIM-64)
|
||||
|
||||
Après déchargement physique, le cariste déclare les palettes via un menu TRF
|
||||
dédié **Réceptions > Image de quai**.
|
||||
|
||||
### Règle de déchargement physique
|
||||
|
||||
Le cariste doit décharger en commençant par l'emplacement le **plus éloigné
|
||||
du quai** en suivant un ordre précis. Cela permet d'identifier les
|
||||
emplacements occupés pour les AGV.
|
||||
|
||||
### Workflow 7 écrans
|
||||
|
||||
Le parcours d'écrans dépend du type de réception :
|
||||
|
||||
- **Production** : écrans 1, 3, 4, 5, 7
|
||||
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
|
||||
|
||||
#### Écran 1 — Type de réception
|
||||
|
||||
Choix parmi :
|
||||
|
||||
- Production
|
||||
- Autres (fournisseur, intersite, retours, etc.)
|
||||
- Pile de palette
|
||||
|
||||
Échap : retour menu.
|
||||
|
||||
#### Écran 2 — Sélection de la réception
|
||||
|
||||
Uniquement si type = **Autres**. L'opérateur choisit la réception concernée.
|
||||
|
||||
Échap : retour écran 1.
|
||||
|
||||
#### Écran 3 — Nombre de palettes
|
||||
|
||||
Prompt : « Nombre de palettes de la réception »
|
||||
|
||||
Validation :
|
||||
|
||||
- Nombre entre 1 et 26 inclus
|
||||
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
|
||||
|
||||
Message d'erreur explicatif si invalide. Échap : retour écran 2.
|
||||
|
||||
#### Écran 4 — Choix image de quai (poumon)
|
||||
|
||||
Le workflow liste tous les poumons liés aux quais (réception + expédition)
|
||||
puis filtre :
|
||||
|
||||
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
|
||||
tâches de shipping en destination
|
||||
- Exclure les poumons pleins (supports = capacité)
|
||||
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
|
||||
dernier conteneur
|
||||
|
||||
> **Double check** : au moment du choix effectif, les vérifications sont
|
||||
> refaites — entre l'affichage de la liste et la sélection, la réalité a pu
|
||||
> changer.
|
||||
|
||||
Échap : retour écran 3.
|
||||
|
||||
#### Écran 5 — Sous-emplacement de départ
|
||||
|
||||
Prompt : « Sous-emplacement de la première palette de la réception »
|
||||
|
||||
Validation :
|
||||
|
||||
- Nombre valide
|
||||
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
|
||||
palettes déclaré) doivent être **vides**
|
||||
|
||||
Exemple : si des palettes d'une autre réception occupent la position 5, et
|
||||
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
|
||||
position 5 est occupée.
|
||||
|
||||
Échap : retour écran 4.
|
||||
|
||||
#### Écran 6 — Présence de big-bags
|
||||
|
||||
Uniquement si type = **Autres**.
|
||||
|
||||
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
|
||||
|
||||
Boutons OUI / NON. L'information est conservée pour la suite du flux.
|
||||
|
||||
Échap : retour écran 4.
|
||||
|
||||
#### Écran 7 — Validation et création
|
||||
|
||||
Récapitulatif affiché :
|
||||
|
||||
- Image de quai
|
||||
- Type de réception
|
||||
- Nombre de palettes
|
||||
- Sous-emplacement de départ
|
||||
- Présence de big-bags (si applicable)
|
||||
|
||||
À la validation :
|
||||
|
||||
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
|
||||
sous-emplacements consécutifs à partir de la position de départ
|
||||
2. **Séquence spéciale** : 18 caractères commençant par `8`
|
||||
(ex : `800000000000000001`, `800000000000000002`, etc.)
|
||||
— cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
|
||||
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
|
||||
par palette déclarée (format LIM-65)
|
||||
|
||||
Échap : retour écran 5. Après validation : retour écran 2.
|
||||
|
||||
> **Validation de sécurité** : si le poumon ou la position de départ est
|
||||
> devenu indisponible entre l'écran 5 et la validation, un message d'erreur
|
||||
> est affiché. Idem si la réception sélectionnée a été supprimée entre-temps.
|
||||
|
||||
## Étiquette support image de quai (LIM-65)
|
||||
|
||||
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
|
||||
(pas pour la production).
|
||||
|
||||
| Champ | Contenu |
|
||||
|-------|---------|
|
||||
| CODE | Code du support (séquence 8xxx) |
|
||||
| RECEPTION | Code de la réception |
|
||||
| DATE | Date d'impression |
|
||||
| EMPL. | Sous-emplacement du poumon |
|
||||
| QR Code | Code du support |
|
||||
|
||||
## Implémentation technique (AD customs)
|
||||
|
||||
### Entités
|
||||
|
||||
| Entité | Usage |
|
||||
|--------|-------|
|
||||
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
|
||||
|
||||
### Queries
|
||||
|
||||
| Query | Entité cible |
|
||||
|-------|-------------|
|
||||
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
|
||||
|
||||
### Vues modifiées
|
||||
|
||||
| Vue | Modification |
|
||||
|-----|-------------|
|
||||
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
|
||||
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
|
||||
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
|
||||
|
||||
### Ressources i18n
|
||||
|
||||
| Code | FR | EN |
|
||||
|------|----|----|
|
||||
| `CST_Reception_MultiClassError` | Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes | Can't create reception with inbound orders with different inbound order class |
|
||||
| `CST_Prop_Reception_Document` | Camion | Truck |
|
||||
| `CST_Prop_Station_Workload` | Assignations / Camions | Assignations / Trucks |
|
||||
| `CST_Reception_DockWorkload_Panel_Title` | Occupation des quais | Docks workload |
|
||||
|
||||
> **Note** : toutes les ressources custom sont préfixées `CST_` (convention
|
||||
> Mecalux France validée lors de la revue de code).
|
||||
|
||||
### Revue de code
|
||||
|
||||
- **05/03/2026** — Vincent Charvet : implémentation initiale
|
||||
([`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166))
|
||||
- **06/03/2026** — Nicolas Chabanis : revue non valide (préfixes ressources,
|
||||
commentaire `//Custom end` manquant, Column Span, titre colonne)
|
||||
- **09/03/2026** — Nicolas Chabanis : **revue validée**
|
||||
|
||||
## Points d'attention
|
||||
|
||||
- La plaque du camion n'est **pas obligatoire** à la création de la réception
|
||||
— elle peut être renseignée après coup (confirmé 09/03/2026)
|
||||
- Le déchargement doit respecter l'ordre : emplacement le plus éloigné
|
||||
d'abord, sinon les AGV ne peuvent pas identifier correctement les positions
|
||||
occupées
|
||||
- La capacité maximale d'un poumon est de **26 emplacements**
|
||||
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
|
||||
(elles arrivent déjà étiquetées via ASN)
|
||||
- Le double-check de disponibilité du poumon au moment du choix est
|
||||
**critique** pour éviter les collisions entre opérateurs simultanés
|
||||
- Les séquences de supports virtuels commencent par `8` et font 18 caractères
|
||||
— ne pas confondre avec les séquences SSCC standard
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [ ] Gestion TRF si AGV pas prêts au démarrage — lié aussi à la déclaration
|
||||
image de quai (@Théo)
|
||||
- [ ] Position étiquette image de quai (devant/côté palette) — à valider
|
||||
avec le client (@Justine)
|
||||
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
|
||||
la cohérence de l'affichage chauffeur ? (@Justine)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|-------------|
|
||||
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
|
||||
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
|
||||
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
|
||||
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
|
||||
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
|
||||
@@ -0,0 +1,601 @@
|
||||
---
|
||||
title: "Réception fournisseur — Production et extérieures/intersites"
|
||||
tags: [inbound, réception, production, ASN, ROR, PIE, clôture, REF, ROF]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-67, LIM-73]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Réception fournisseur — Production et extérieures/intersites
|
||||
|
||||
> **Résumé** : deux flux de réception distincts chez Limagrain — production
|
||||
> (directe ASRS via ASN) et extérieures/intersites (passage poste de travail
|
||||
> via ROR). Le déchargement camion est une étape commune.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
|
||||
|
||||
1. **Réception depuis la production** (flux majoritaire)
|
||||
2. **Réceptions extérieures / transferts intersites**
|
||||
|
||||
Le troisième type (retours client) est couvert dans
|
||||
[Réception retour](reception-retour.md).
|
||||
|
||||
## Étape commune — Arrivée et déclaration du camion
|
||||
|
||||
> **Page dédiée** : le flux complet d'arrivée camion, d'assignation de quai,
|
||||
> d'affichage chauffeur et de déclaration image de quai via TRF est documenté
|
||||
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
|
||||
> Ce qui suit est un résumé.
|
||||
|
||||
### [CUSTOM] Réservation image de quai
|
||||
|
||||
1. Camion arrive → agent de quai crée une **réception** dans la vue
|
||||
« Ordre d'entrée > Réceptions » (SmartUI)
|
||||
2. Saisie de la **plaque d'immatriculation** et de la **destination** :
|
||||
« PARKING » par défaut (quai fictif d'attente) ou quai réel si disponible
|
||||
3. Sélection des OE (ordres d'entrée) concernés — chaque OE est flagué
|
||||
via un CstAtt
|
||||
4. Agent consulte la disponibilité des quais via un graphique dans la vue
|
||||
des réceptions et assigne un quai réel
|
||||
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
|
||||
|
||||
**Contraintes d'assignation image de quai :**
|
||||
|
||||
- Quai et image de quai **réservés** dès la sélection — réutilisation possible
|
||||
si place restante (gestion manuelle)
|
||||
- Blocage si flux différent (ex : expédition en cours sur ce quai)
|
||||
- Blocage si l'image de quai a des supports associés à un OS (expédition)
|
||||
ou inversement
|
||||
- Si aucun quai disponible → attente de libération
|
||||
- Il faut empêcher de créer une réception avec des OE de **classes de
|
||||
préavis différentes** (message d'erreur bloquant)
|
||||
|
||||
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
|
||||
|
||||
### Déchargement physique
|
||||
|
||||
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
|
||||
- Permet d'identifier précisément les emplacements occupés pour les AGV
|
||||
|
||||
### [CUSTOM] Déclaration sur l'image de quai
|
||||
|
||||
Menu TRF custom : Réception > Images de quai > Déclaration
|
||||
|
||||
**Séquence commune :**
|
||||
|
||||
1. Scan de l'image de quai
|
||||
2. Choix du type de réception (Production / Fournisseur / Retour client /
|
||||
Palettes vides)
|
||||
3. Saisie du nombre de palettes + emplacement de départ
|
||||
4. Association à la réception (auto pour Production via CstAtt « ASN »,
|
||||
sélection manuelle de l'OE pour les autres)
|
||||
5. Prompt big-bag (Oui/Non) — sauté pour Production
|
||||
6. Écran de validation
|
||||
7. Création des supports dans le WMS
|
||||
|
||||
**Pour les réceptions extérieures/retours client :**
|
||||
|
||||
- Impression d'une **étiquette par support** à coller sur la palette
|
||||
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
|
||||
- Vérification capacité image de quai
|
||||
|
||||
### Création tâches de mouvement AGV
|
||||
|
||||
- EasyWMS indique **point de prise** et **point de dépose** uniquement
|
||||
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
|
||||
- Pour réceptions nécessitant un poste : assignation automatique selon
|
||||
contraintes déclarées (mode, big-bag, distance la plus courte)
|
||||
- Assignation manuelle également possible
|
||||
- Si aucun poste disponible → tâche en attente
|
||||
|
||||
### Libérations
|
||||
|
||||
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
|
||||
de palettes dessus (vérification via supports présents)
|
||||
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
|
||||
|
||||
---
|
||||
|
||||
## Flux 1 — Réception depuis la production
|
||||
|
||||
### Flux physique
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Cariste
|
||||
participant Quai/Poumon
|
||||
participant AGV
|
||||
participant Buffer
|
||||
participant PIE_01
|
||||
participant ASRS
|
||||
Cariste->>Quai/Poumon: Déchargement
|
||||
Note over Quai/Poumon: Supports virtuels créés
|
||||
AGV->>Buffer: Transport support virtuel
|
||||
Buffer->>PIE_01: Convoyeur entrée production
|
||||
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
|
||||
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
|
||||
alt PIE OK
|
||||
PIE_01->>ASRS: Stockage (stratégie rangement)
|
||||
else PIE NOK
|
||||
PIE_01->>Cariste: Rejet → poumon au sol + notification
|
||||
end
|
||||
```
|
||||
|
||||
### Résumé du processus
|
||||
|
||||
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
|
||||
2. Déplacement AGV → entrée production (via supports virtuels)
|
||||
3. Passage PIE (suppression support virtuel + validation palette ASN)
|
||||
4. Stockage ou rejet
|
||||
5. Libération quai / image de quai
|
||||
|
||||
### 1) [CUSTOM] Pré-notification ASN
|
||||
|
||||
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
|
||||
depuis l'ancien magasin). Contenu :
|
||||
|
||||
- Numéro unique HU
|
||||
- Article / Lot SAP
|
||||
- [CUSTOM] Propriétaire Limagrain
|
||||
- Statut de stock
|
||||
- Quantité (unités de vente)
|
||||
|
||||
Batch possible : jusqu'à **500 conteneurs par message ASN**.
|
||||
|
||||
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
|
||||
> L'étiquette est collée sur la housse.
|
||||
|
||||
### 2) [CUSTOM] Supports virtuels et déplacement AGV
|
||||
|
||||
**Principe des supports virtuels :**
|
||||
|
||||
- Création de supports « virtuels » identiques à de vrais supports mais
|
||||
avec une **séquence différente (8000)** pour les identifier
|
||||
- La flotte AGV déplace la palette fictive jusqu'au PIE
|
||||
- Le tracking s'effectue avec le support virtuel sur le premier convoyeur
|
||||
|
||||
**Destination** : entrée production (convoyeur vers ASRS). L'AGV dépose
|
||||
sur un **buffer d'entrée** (type POUMON MINILOAD AD) — jamais directement
|
||||
sur le PIE.
|
||||
|
||||
**Suppression du support virtuel :**
|
||||
|
||||
- Basée sur le fonctionnement standard des routes AGV
|
||||
- Surveillance des **containerMovedEvent**
|
||||
- Filtre : type palette ASN + destination type PIE → suppression du
|
||||
support virtuel (séquence 8000)
|
||||
|
||||
### [CUSTOM] Redirection si entrée production saturée
|
||||
|
||||
En cas de blocage long terme sur l'entrée production :
|
||||
|
||||
- **Solution standard** : système de routes avec distances — route
|
||||
principale distance 1, routes secondaires distance 2
|
||||
- On ferme le PIE de production → le WMS redirige automatiquement vers
|
||||
les autres entrées disponibles
|
||||
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
|
||||
proche de l'entrée)
|
||||
|
||||
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
|
||||
> configuration easyS qui téléportent automatiquement les palettes.
|
||||
|
||||
### 3) Passage au PIE et création palette ASN
|
||||
|
||||
**Séquence au PIE :**
|
||||
|
||||
1. Fin d'ordre AGV au PIE → suppression du support virtuel
|
||||
(via containerMovedEvent)
|
||||
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
|
||||
3. Le ratio poids s'effectue au niveau de l'article
|
||||
|
||||
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
|
||||
RFID connue (ASN). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md) pour le
|
||||
détail des contrôles PIE et la répartition du poids.
|
||||
|
||||
**PIE OK :**
|
||||
|
||||
- [CUSTOM] Aucun message ASO généré
|
||||
- [CUSTOM] Vérification poids — tolérance par type article, verrou
|
||||
« Réception » sur le **support** si écart > seuil
|
||||
- Mise à jour CstAtt01 de la ligne de stock (poids unitaire calculé)
|
||||
- [CUSTOM] Si type article ZSIZ → message ajustement stock vers SAP
|
||||
via WSC (poids réel HU) — voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md) pour
|
||||
la gestion du timing avec le REF
|
||||
- Stratégie de rangement appliquée
|
||||
- Réservation canal optimale selon nb palettes ASN restantes
|
||||
|
||||
**PIE NOK :**
|
||||
|
||||
- Rejet standard — plus besoin d'étiquette spécifique
|
||||
- Palette dirigée automatiquement vers un **poumon au sol** (zone de
|
||||
rejet)
|
||||
- **Notification SmartUI** envoyée aux opérateurs
|
||||
- Opérateur se rend physiquement à la zone de rejet pour corriger
|
||||
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
|
||||
RENVOI » et crée une tâche vers un poumon dédié
|
||||
- [CUSTOM] Aucun message ASK généré
|
||||
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
|
||||
travail d'origine)
|
||||
|
||||
---
|
||||
|
||||
## Flux 2 — Réceptions extérieures / transferts intersites
|
||||
|
||||
### Flux physique
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Cariste
|
||||
participant Quai/Poumon
|
||||
participant AGV
|
||||
participant Poste PK
|
||||
participant Filmeuse
|
||||
participant PIE_02/03
|
||||
participant ASRS
|
||||
Cariste->>Quai/Poumon: Déchargement
|
||||
AGV->>Poste PK: Transport vers poste de travail
|
||||
Poste PK->>Poste PK: Traitement réception
|
||||
AGV->>Filmeuse: Évacuation (filmage si demandé)
|
||||
Filmeuse->>PIE_02/03: Table d'entrée
|
||||
PIE_02/03->>PIE_02/03: Contrôles
|
||||
alt PIE OK
|
||||
PIE_02/03->>ASRS: Stockage
|
||||
else PIE NOK
|
||||
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
|
||||
end
|
||||
```
|
||||
|
||||
### Résumé du processus
|
||||
|
||||
1. Déclaration sur l'image de quai
|
||||
2. Déplacement AGV → poste de travail
|
||||
3. Traitement au poste de travail (constitution mono-ref + déclaration)
|
||||
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
|
||||
5. Passage PIE
|
||||
6. Stockage ou rejet
|
||||
7. Clôture de la réception
|
||||
8. Libération quai / image de quai
|
||||
|
||||
### 1) Notification ROR
|
||||
|
||||
Message **ROR** de SAP → EasyWMS :
|
||||
|
||||
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
|
||||
contenir N livraisons)
|
||||
- Articles / Lots SAP / Quantités (en unités de vente)
|
||||
- Pas de création de lignes autorisée
|
||||
- Tolérance quantité : **0 %** pour intersites (palettes déjà
|
||||
identifiées), paramétrable **par ligne ROR** pour extérieures
|
||||
(uniquement en dépassement %)
|
||||
- `IsSingleReceipt = true` — le WMS ne gère pas de reliquats
|
||||
automatiques. Si réception incomplète, SAP crée une nouvelle
|
||||
livraison
|
||||
- `InboundType = 0` (Standard) pour les deux sous-types
|
||||
|
||||
| Élément SAP | Correspondance EasyWMS | Remarque |
|
||||
|-------------|------------------------|----------|
|
||||
| Commande d'achat | — | Peut être cadencée en plusieurs livraisons |
|
||||
| Livraison | 1 ROR | Un ROR = une livraison |
|
||||
| Camion | N livraisons | Un camion peut contenir plusieurs livraisons |
|
||||
|
||||
> Les transferts intersites : le site émetteur est considéré comme un
|
||||
> fournisseur dans EasyWMS.
|
||||
|
||||
### 2) [CUSTOM] Gestion des SSCC
|
||||
|
||||
- Les numéros SSCC **ne sont pas envoyés** dans le ROR
|
||||
(`LineList>ContainerCode`)
|
||||
- Le SSCC est récupéré au moment du **scan RFID** en réception
|
||||
- Si SSCC présent sur la palette → conservation lors de la réédition
|
||||
RFID
|
||||
- Si SSCC absent → création d'un nouveau SSCC et ré-étiquetage
|
||||
|
||||
> Raison : éviter la complexification du process si l'étiquette est
|
||||
> endommagée.
|
||||
|
||||
### 3) [CUSTOM] Déplacement vers poste de travail
|
||||
|
||||
Assignation automatique du poste selon :
|
||||
|
||||
1. Non bloqué
|
||||
2. En service
|
||||
3. Mode autorise la réception
|
||||
4. Capacité compatible avec la déclaration
|
||||
5. Distance la plus courte
|
||||
|
||||
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
|
||||
|
||||
### 4) Constitution palettes mono référence
|
||||
|
||||
Les palettes à destination ASRS doivent être **mono référence** autant
|
||||
que possible. Si multi-référence à l'arrivée :
|
||||
|
||||
- Opérateur dispose manuellement une palette vide sur une TP
|
||||
(non géré par le WMS)
|
||||
- Tri de marchandise pour constituer des conteneurs mono-ref
|
||||
|
||||
> Le process de constitution mono-référence est **standard** — pas de
|
||||
> développement spécifique.
|
||||
|
||||
### 5) [CUSTOM] Traitement au poste de travail
|
||||
|
||||
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
|
||||
attente CDP.
|
||||
|
||||
Les opérateurs utilisent le mode **Tâches automatiques** sur PC. Le
|
||||
code de réception est récupéré automatiquement via le `CstAtt08` du
|
||||
conteneur présent sur le poste.
|
||||
|
||||
**Affichage fournisseur** : sur **tous les écrans** du process,
|
||||
afficher `"Fournisseur: CODE - NOM"`.
|
||||
|
||||
#### a) Confirmation de création support (Big Bag)
|
||||
|
||||
Si le conteneur scanné est un **conteneur virtuel** de réception, un
|
||||
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
|
||||
|
||||
- Ligne `"BIG BAG : NON"` (état initial)
|
||||
- Bouton **"BIG BAG ON"** → toggle vers `"BIG BAG : OUI"` / **"BIG BAG
|
||||
OFF"**
|
||||
- Valeur `true`/`false` stockée dans **CstAtt02** du support
|
||||
- Impression automatique d'une **étiquette RFID** dès confirmation —
|
||||
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
|
||||
|
||||
#### b) Menu principal du poste
|
||||
|
||||
Écran central avec 5 actions — les informations du support actuel sont
|
||||
toujours affichées à droite. Après chaque action, retour à ce menu.
|
||||
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Ajouter stock** | Sélection article, lot, quantité (écrans standard). Afficher quantité attendue + UdM sans pré-remplir le prompt. Statut de stock affiché mais **non modifiable** (boutons masqués). Écrans date fin de statut et commentaire **skippés**. Pour l'anoxie : set **CstAtt03** du support à `true` |
|
||||
| **Nouveau support** | Scan emplacement, confirmation de création (retour à l'étape a). Le nouveau conteneur devient le support actif |
|
||||
| **Changer de support** | Scan du code support à sélectionner comme support actif |
|
||||
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
|
||||
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
|
||||
|
||||
#### c) Action « Terminer »
|
||||
|
||||
**Vérification fermeture réception** : si le conteneur actuel est le
|
||||
**dernier** de la réception (nombre de conteneurs virtuels avec
|
||||
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
|
||||
`CstAtt10 = true`), proposer la fermeture de la réception avec
|
||||
uniquement l'option confirmer.
|
||||
|
||||
**Sélection du programme de filmage** : dialogue avec liste issue du
|
||||
paramètre **"FILMAGES"** :
|
||||
|
||||
```
|
||||
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
|
||||
```
|
||||
|
||||
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
|
||||
**CstAtt05** du support et transmise à Galileo en custom data.
|
||||
|
||||
Après validation, une **tâche d'évacuation** est générée pour le
|
||||
transport AGV du poste de travail vers la table d'entrée.
|
||||
|
||||
#### Résumé des CstAtt support (poste de travail)
|
||||
|
||||
| CstAtt | Contenu | Set par |
|
||||
|--------|---------|---------|
|
||||
| CstAtt02 | Flag Big Bag (`true`/`false`) | Écran confirmation support |
|
||||
| CstAtt03 | Flag anoxie (`true`) | Action « Ajouter stock » |
|
||||
| CstAtt05 | Programme de filmage (`0`, `A`, `B`…) | Action « Terminer » |
|
||||
| CstAtt08 | Code de réception | Déclaration image de quai |
|
||||
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
|
||||
|
||||
### 6) Déplacement AGV → table d'entrée et filmage
|
||||
|
||||
- L'AGV déplace le conteneur vers la table d'entrée
|
||||
- **Gestion du filmage** : le programme de filmage est transmis à
|
||||
Galileo via custom data au moment du passage. Si le PIE dit NOK →
|
||||
pas de filmage (custom data non transmis). Le filmage ne se fait que
|
||||
si le PIE valide la palette
|
||||
|
||||
### 7) Passage PIE
|
||||
|
||||
Identique au flux production (mêmes formules de répartition poids,
|
||||
mêmes contrôles PIE). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md).
|
||||
|
||||
**Différence en cas de rejet PIE** : la palette est dirigée vers un
|
||||
**poumon au sol** avec **notification SmartUI** (ancienne approche de
|
||||
renvoi au poste de travail d'origine abandonnée — risque de blocage
|
||||
AGV/table/poste). CstAtt du support flagué avec le poste de travail
|
||||
d'origine.
|
||||
|
||||
---
|
||||
|
||||
## Clôture des réceptions (extérieures/intersites)
|
||||
|
||||
Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) — LOT
|
||||
1.3.
|
||||
|
||||
La clôture concerne uniquement les flux passant par un poste de travail
|
||||
(extérieures, intersites, retours client). La réception production (ASN)
|
||||
n'est pas concernée (pas de clôture manuelle).
|
||||
|
||||
**Relation réception ↔ OE** : une réception peut servir **plusieurs
|
||||
OE**, mais un OE est servi par **une seule réception**. Si la réception
|
||||
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
|
||||
livraison (donc nouvel OE).
|
||||
|
||||
### Paramétrage
|
||||
|
||||
- `IsSingleReceipt = true` — une seule réception par OE, pas de
|
||||
reliquats WMS
|
||||
- `AutoCloseReception = true` — le WMS clôture automatiquement la
|
||||
réception quand les conditions custom sont remplies (§ Déclenchement)
|
||||
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
|
||||
OE complété à 100 % ou dans la tolérance est auto-clôturé (ROF
|
||||
envoyé) et auto-archivé (absent de la vue). Les OE en écart hors
|
||||
tolérance restent ouverts
|
||||
|
||||
### Deux niveaux de clôture
|
||||
|
||||
| Niveau | Description | Message ERP |
|
||||
|--------|-------------|-------------|
|
||||
| Réception | Clôture d'une livraison physique | REF |
|
||||
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
|
||||
|
||||
### Déclenchement de l'auto-close (LIM-73 §1.1)
|
||||
|
||||
L'auto-close de la réception se déclenche — et le bouton « Fermer
|
||||
réception » n'est visible — que si les deux conditions suivantes sont
|
||||
**simultanément** remplies :
|
||||
|
||||
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
|
||||
n'est présente (plus de palettes à venir de l'image de quai)
|
||||
2. **ET** :
|
||||
- **Si Workstation** : au plus **1** palette réelle au PK avec
|
||||
`CstAtt10 = true` (la dernière en cours)
|
||||
- **Si Vue Réception** : **aucune** palette réelle au PK avec
|
||||
`CstAtt10 = true`
|
||||
|
||||
Si au moins une ligne est **hors tolérance**, un message d'avertissement
|
||||
s'affiche : « La réception a été clôturée mais les quantités reçues sont
|
||||
hors tolérance, voir avec le manager pour réguler les quantités attendues
|
||||
puis fermer l'ordre d'entrée ».
|
||||
|
||||
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
|
||||
|
||||
Le workflow standard de clôture est modifié pour deux comportements :
|
||||
|
||||
**Partie A — Condition retours** : si la réception est de type retour
|
||||
client, la clôture et le REF sont différés jusqu'au rangement ASRS
|
||||
complet. Voir [Réception retour — Clôture](reception-retour.md) pour le
|
||||
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
|
||||
|
||||
**Partie B — Pose CstAtt01 OE hors tolérance** : à la clôture effective,
|
||||
pour chaque **ligne article hors tolérance** (en plus ou en moins) :
|
||||
|
||||
1. Rechercher le **premier OE** (FirstOrDefault) parmi les OE associés
|
||||
contenant ce combo code article / lot
|
||||
2. Poser `CstAtt01 = true` sur cet OE
|
||||
|
||||
> En pratique un combo code article/lot n'est jamais partagé entre
|
||||
> plusieurs OE d'une même réception — le FirstOrDefault est
|
||||
> déterministe.
|
||||
|
||||
Les OE flaggés ne se clôturent pas automatiquement (ROF bloqué) et
|
||||
s'affichent en rouge dans la vue (voir § Clôture des OE ci-dessous).
|
||||
|
||||
### Contenu du REF (custom)
|
||||
|
||||
Un seul REF est envoyé par réception (pas de REF progressif, car
|
||||
`IsSingleReceipt = true`). Contenu :
|
||||
|
||||
- Numéros de conteneurs réceptionnés
|
||||
- Lignes de stocks associées
|
||||
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
|
||||
du support) :
|
||||
- Fournisseur / intersite : si un support se trouve hors de l'ASRS
|
||||
au moment du REF → valeur **"NON RANGEE"**
|
||||
- Retour client : ce cas ne se produit pas (REF conditionné au
|
||||
rangement complet — voir [Réception retour](reception-retour.md))
|
||||
- [CUSTOM] Attributs stock remontés : code produit SAP, code
|
||||
propriétaire réel, description courte, pays de destination, lot SAP
|
||||
|
||||
**LOC** : envoyé sur delta de 5 min (palette créée/déplacée/supprimée).
|
||||
Le LOC ne prend pas en compte les palettes liées à une réception non
|
||||
fermée (standard dans le WSC forké — développement dédié
|
||||
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
|
||||
|
||||
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
|
||||
|
||||
| Situation OE | Clôture | ROF | Affichage vue OE |
|
||||
|--------------|---------|-----|------------------|
|
||||
| Reçu = attendu | Auto-close | Envoi auto | Auto-archivé → absent |
|
||||
| Écart dans la tolérance | Auto-close (custom) | Envoi auto | Auto-archivé → absent |
|
||||
| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** — bouton restreint |
|
||||
|
||||
**Visibilité du bouton « Clôturer l'OE »** :
|
||||
|
||||
- OE sans écart ou dans la tolérance : accessible à tous (standard),
|
||||
mais auto-archivé donc invisible
|
||||
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
|
||||
**uniquement pour les profils non-opérateurs** (admin, manager, chef
|
||||
d'équipe). Masqué pour les opérateurs standards
|
||||
|
||||
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
|
||||
clôture manuellement l'OE → ROF envoyé.
|
||||
|
||||
### Réception excédentaire (> % autorisé)
|
||||
|
||||
Le WMS bloque. Solutions possibles :
|
||||
|
||||
| Solution | Description |
|
||||
|----------|-------------|
|
||||
| Modifier la commande | Message ROR UPSERT depuis SAP |
|
||||
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
|
||||
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ En cas de blocage long terme sur l'entrée production, le WMS
|
||||
redirige automatiquement vers les autres entrées via le système de
|
||||
routes avec distances (fermeture du PIE de production).
|
||||
|
||||
⚠️ Les palettes issues de réceptions extérieures/intersites reçoivent
|
||||
**automatiquement** le flag « A anoxier ».
|
||||
|
||||
⚠️ L'impression étiquettes réception au déchargement n'est possible que
|
||||
pour les réceptions extérieures et retours clients (pas production).
|
||||
|
||||
⚠️ Les rejets PIE sont dirigés vers un **poumon au sol** avec
|
||||
notification SmartUI (ancienne approche de renvoi au PK abandonnée).
|
||||
|
||||
⚠️ Le process de constitution mono-référence est **standard** (pas de
|
||||
développement spécifique).
|
||||
|
||||
⚠️ Filmage : transmis à Galileo via custom data — uniquement si PIE OK.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [x] Programme de filmage — interface définie dans LIM-67 : paramètre
|
||||
FILMAGES avec format `code;libellé|…`, stocké dans CstAtt05
|
||||
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
|
||||
- [ ] Utilisation du ROC (confirmation de réception) — point interne
|
||||
Limagrain (@Justine)
|
||||
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
|
||||
faisabilité technique (@Nicolas)
|
||||
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
|
||||
réception (@Nicolas)
|
||||
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
|
||||
ZPL (@Théo)
|
||||
- [ ] Position étiquette image de quai (devant/côté) — à valider
|
||||
avec le client (@Justine)
|
||||
- [ ] Poids variable — vérifier si le standard gère la capture de
|
||||
poids (@Nicolas)
|
||||
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
|
||||
les palettes impossibles à réceptionner ? (@Justine)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
|
||||
| 2026-05-12 | Arthur | LIM-67 : workflow complet poste de travail, Big Bag CstAtt02, anoxie CstAtt03, filmage CstAtt05/FILMAGES, fermeture réception |
|
||||
| 2026-05-12 | Arthur | LIM-73 : réécriture complète section clôture — AutoCloseReception=true, conditions CstAtt08/CstAtt10, Reception_Close_PR_V2 (tolérance par ligne, CstAtt01 OE hors tolérance), REF custom (zone stockage / "NON RANGEE"), clôture OE (tableau 3 cas, bouton restreint non-opérateur), impact LOC (LIM-76) |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
|
||||
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira | 2026 |
|
||||
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF) | 2026 |
|
||||
@@ -0,0 +1,400 @@
|
||||
---
|
||||
title: "Réception retour commandes clients"
|
||||
tags: [inbound, réception, retour, client, API, lot]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Réception retour commandes clients
|
||||
|
||||
> **Résumé** : processus spécifique de réception des retours client, avec
|
||||
> interrogation API SAP pour validation lot, et déclaration enrichie sur
|
||||
> poste de travail.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Les retours client suivent un flux similaire aux réceptions extérieures
|
||||
(passage poste de travail obligatoire) mais avec des particularités :
|
||||
|
||||
- `InboundType = 1` (Return) — vs 0 (Standard) pour les autres flux
|
||||
- Création de lignes autorisée (article non attendu possible)
|
||||
- Tolérance illimitée : profil de réception par défaut configuré en
|
||||
« illimité » sur tous les articles
|
||||
- `ReceiveLessAllowed = true` — réception partielle toujours autorisée
|
||||
- Interrogation API SAP pour valider le lot officiel
|
||||
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
|
||||
|
||||
## Process complet de réception retour client
|
||||
|
||||
| Étape | Description | Ticket |
|
||||
|-------|-------------|--------|
|
||||
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
|
||||
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
|
||||
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
|
||||
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
|
||||
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
|
||||
| 6 | Stockage ou rejet | — |
|
||||
| 7 | Clôture de la réception | — |
|
||||
| 8 | Libération quai / image de quai | — |
|
||||
|
||||
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
|
||||
du déchargement camion et des déclarations initiales
|
||||
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
|
||||
flux fournisseur au PK).
|
||||
|
||||
## Notification ROR
|
||||
|
||||
Message ROR de SAP (type ORDRSP) avec :
|
||||
|
||||
- Numéro de réception
|
||||
- Articles / Lots / Quantités attendues
|
||||
- Codes articles **génériques** (codes uniques avec nomenclature
|
||||
précise, pas réutilisables — assure la traçabilité)
|
||||
|
||||
**Différence clé** : cette réception **autorise la création de lignes**.
|
||||
Limagrain peut recevoir un article non présent dans le ROR initial.
|
||||
Un article inconnu de la base EasyWMS = ROR refusé. Un article connu
|
||||
mais non prévu dans le retour = accepté (tolérance illimitée).
|
||||
|
||||
## [CUSTOM] Identification lot — Interrogation API SAP
|
||||
|
||||
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
|
||||
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
|
||||
|
||||
### Rappel : structure des articles chez Limagrain
|
||||
|
||||
Chez Limagrain, le **code article WMS = lot SAP** (cf.
|
||||
[Données principales](../06-erp-interface/donnees-principales.md)).
|
||||
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
|
||||
complète), et le code produit est un attribut stocké en CstAtt du stock.
|
||||
Le **lot officiel** est l'alias de l'article dans le WMS.
|
||||
|
||||
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
|
||||
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
|
||||
SAP d'envoyer la fiche article complète.
|
||||
|
||||
### Logique de vérification
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
|
||||
B -- Oui --> C{Vendu par Limagrain ?}
|
||||
B -- Non --> D[Appel API SAP]
|
||||
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
|
||||
E --> F{ITM reçu via API WMS ?}
|
||||
F -- Oui --> C
|
||||
F -- Non / Timeout --> G{Tentative < 5 ?}
|
||||
G -- Oui --> H[Bouton Réessayer]
|
||||
H --> D
|
||||
G -- Non --> I[Erreur finale :<br/>contacter responsable]
|
||||
C -- Oui --> J{Plusieurs articles ?}
|
||||
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
|
||||
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
|
||||
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
|
||||
M --> L
|
||||
```
|
||||
|
||||
### Appel API SAP — Vérification du lot officiel
|
||||
|
||||
L'appel API REST est fait **directement depuis le workflow** (pas via
|
||||
GNA). Il sert à notifier SAP que le WMS a besoin de la fiche article.
|
||||
|
||||
**Séquence d'échange :**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant WF as WMS (workflow)
|
||||
participant SAP
|
||||
WF->>SAP: POST /api/v1/lot/verify
|
||||
Note over WF,SAP: Payload : IV_LGNUM, IV_BATCH_OFF,<br/>IV_RETURN
|
||||
SAP-->>WF: Réponse JSON (EV_RETURN, ET_BATCH)
|
||||
alt EV_RETURN = "X" (OK)
|
||||
SAP->>WF: POST ApplicationService/ITM
|
||||
Note over SAP,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
|
||||
WF->>WF: Vérif : product code existe en base ?
|
||||
alt OK
|
||||
WF->>WF: Continuer
|
||||
else Absent
|
||||
WF->>WF: Proposer réessayer
|
||||
end
|
||||
else EV_RETURN ≠ "X" (NOK)
|
||||
WF->>WF: Erreur immédiate
|
||||
end
|
||||
```
|
||||
|
||||
**Payload de requête :**
|
||||
|
||||
```json
|
||||
POST /api/v1/lot/verify
|
||||
{
|
||||
"IV_LGNUM": "WF02",
|
||||
"IV_MATNR": "",
|
||||
"IV_CHARG": "",
|
||||
"IV_BATCH_OFF": "<lot officiel à vérifier>",
|
||||
"IV_RETURN": "<code du retour client (OE)>"
|
||||
}
|
||||
```
|
||||
|
||||
- `IV_LGNUM` : toujours "WF02"
|
||||
- `IV_BATCH_OFF` : numéro de lot officiel scanné
|
||||
- `IV_RETURN` : code du retour client (ordre d'entrée)
|
||||
- Les autres champs restent vides
|
||||
|
||||
**Payload de réponse (champs clés) :**
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| `EV_RETURN` | "X" = lot valide, sinon invalide |
|
||||
| `ET_RETURN[]` | Tableau de messages (TYPE, MESSAGE, etc.) |
|
||||
| `ET_BATCH[]` | Lots autorisés : `MATNR` (code article SAP), `CHARG` (lot SAP), `BATCH_OFF` (lot officiel), `EV_DEPLOY` ("X" = autorisé) |
|
||||
|
||||
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
|
||||
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
|
||||
pour l'opérateur.
|
||||
|
||||
### Écran d'attente pendant la réception de l'ITM
|
||||
|
||||
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
|
||||
l'ITM. Pendant cette attente :
|
||||
|
||||
- **Message** : "Vérification du lot en cours..."
|
||||
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
|
||||
un **alias correspondant au lot officiel** existe en base
|
||||
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
|
||||
- **Timeout** : 1 minute maximum par tentative
|
||||
- **Nombre maximum de tentatives** : 5
|
||||
|
||||
| Tentative | Comportement en cas de timeout |
|
||||
|-----------|-------------------------------|
|
||||
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
|
||||
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
|
||||
|
||||
### Choix du code lot (multi-résultat)
|
||||
|
||||
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
|
||||
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
|
||||
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
|
||||
un (filtrage par pays d'origine).
|
||||
|
||||
Si un **seul résultat** → sélection automatique, pas de dialogue.
|
||||
|
||||
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
|
||||
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
|
||||
physiquement présent sur la palette.
|
||||
|
||||
**Gestion dans le REF :** le code générique envoyé dans le ROR est
|
||||
remplacé par le vrai code lot dans le REF (custom).
|
||||
|
||||
## Déclaration au poste de travail (LIM-72)
|
||||
|
||||
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
|
||||
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
|
||||
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
|
||||
différences :
|
||||
|
||||
| # | Étape | Différence vs fournisseur (LIM-67) |
|
||||
|---|-------|------------------------------------|
|
||||
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
|
||||
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
|
||||
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
|
||||
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
|
||||
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
|
||||
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
|
||||
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
|
||||
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
|
||||
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
|
||||
| 9 | Validation → évacuation AGV | Identique |
|
||||
|
||||
### Statut de stock — Modifiable
|
||||
|
||||
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
|
||||
verrouillé (boutons masqués), dans le flux retour client :
|
||||
|
||||
- Les **boutons de changement de statut sont visibles** et fonctionnels
|
||||
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
|
||||
Non conforme, etc.)
|
||||
- Les écrans de **date de fin de statut** et **commentaire** suivent
|
||||
le comportement standard (non skippés contrairement au fournisseur)
|
||||
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
|
||||
(non conforme) — assignables uniquement dans ce processus
|
||||
|
||||
### Tolérance illimitée
|
||||
|
||||
- **Article non prévu** dans le retour → accepté (création de ligne
|
||||
autorisée)
|
||||
- **Quantité supérieure** au prévu → acceptée
|
||||
- **Quantité inférieure** au prévu → acceptée (réception fermée
|
||||
manuellement)
|
||||
|
||||
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
|
||||
> **abandonné** — remplacé par un message d'avertissement si le poste
|
||||
> adjacent est déjà ouvert (voir
|
||||
> [Stations picking](../03-picking/stations-picking.md)).
|
||||
|
||||
## Constitution palettes mono référence
|
||||
|
||||
Obligation de constituer des palettes **mono référence** avant stockage.
|
||||
Si la palette retour est multi-ref :
|
||||
|
||||
- Opérateur appelle une palette vide sur une TP disponible
|
||||
- Tri de marchandise
|
||||
|
||||
## Calcul poids et passage PIE
|
||||
|
||||
Identique aux réceptions extérieures (mêmes formules de répartition
|
||||
prorata, mêmes contrôles). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md).
|
||||
|
||||
**Différences pour les retours client :**
|
||||
|
||||
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
|
||||
pour les autres flux) — verrou posé sur le **support** (pas sur
|
||||
le stock)
|
||||
- Action requise en cas d'écart : **recomptage du nombre de sacs**
|
||||
- Rejet PIE : dirigé vers **poumon au sol** + notification SmartUI
|
||||
(ancienne approche de renvoi au PK abandonnée)
|
||||
|
||||
## Clôture — Spécificités retour client (LIM-73)
|
||||
|
||||
Le mécanisme général de clôture (déclenchement auto-close, tolérance par
|
||||
ligne, CstAtt01 OE hors tolérance, clôture OE) est documenté dans
|
||||
[Réception fournisseur — Clôture](reception-fournisseur.md). Cette
|
||||
section décrit le **delta retour client** : le REF est conditionné au
|
||||
rangement ASRS complet.
|
||||
|
||||
### Contexte métier
|
||||
|
||||
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
|
||||
ne doit être envoyé que lorsque **tous les supports** de la réception
|
||||
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
|
||||
notamment PIE).
|
||||
|
||||
Pour les autres types de réception (fournisseur / intersite), le REF est
|
||||
émis à la clôture de la réception, quelle que soit la position des
|
||||
supports.
|
||||
|
||||
### CstAtt11 — Marqueur de rangement ASRS
|
||||
|
||||
À chaque fin de tâche de rangement dans l'ASRS :
|
||||
|
||||
- Vérifier si le support provient d'une réception de type **retour**
|
||||
- Si oui → `CstAtt11 = true` sur le support
|
||||
- Sinon → aucune action
|
||||
|
||||
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
|
||||
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
|
||||
condition de clôture reste satisfaisable même si une palette a déjà été
|
||||
expédiée entre-temps.
|
||||
|
||||
### Statut « Clôture en cours »
|
||||
|
||||
Dans la vue des réceptions, le statut visuel est piloté par le
|
||||
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
|
||||
|
||||
| CstAtt01 réception | État | Affichage |
|
||||
|---------------------|------|-----------|
|
||||
| null / vide | En attente | Standard |
|
||||
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
|
||||
|
||||
Pour les réceptions non-retour, CstAtt01 de la réception n'est pas
|
||||
utilisé (affichage standard).
|
||||
|
||||
### Adaptation Reception_Close_PR_V2 — Partie A (retours)
|
||||
|
||||
- **Si non-retour** → clôture immédiate, génération REF (standard)
|
||||
- **Si retour** :
|
||||
- Vérifier que **tous les supports** ont `CstAtt11 = true`
|
||||
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
|
||||
générer REF
|
||||
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
|
||||
« Clôture en cours »). Le WF est rejoué à chaque event
|
||||
_task finished_ sur un support de la réception
|
||||
|
||||
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
|
||||
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
|
||||
> effectuée.
|
||||
|
||||
### Zone de stockage dans le REF
|
||||
|
||||
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
|
||||
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
|
||||
|
||||
### Récapitulatif CstAtt clôture retour
|
||||
|
||||
| CstAtt | Entité | Rôle |
|
||||
|--------|--------|------|
|
||||
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
|
||||
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours |
|
||||
| CstAtt11 | Support (palette réelle) | `true` quand le support retour a fini son rangement ASRS — **introduit par LIM-73** |
|
||||
| CstAtt01 | Réception (retour uniquement) | `true` = clôture en attente de rangement complet — **introduit par LIM-73** |
|
||||
| CstAtt01 | OE (ordre d'entrée) | `true` = hors tolérance, bloque auto-close et ROF — **introduit par LIM-73** |
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le changement de statut de stock (F9, B6) n'est autorisé sur poste de
|
||||
travail **que** dans le processus retour client.
|
||||
|
||||
⚠️ Un commentaire est associé au statut et remonté dans le message
|
||||
d'interface ERP.
|
||||
|
||||
⚠️ Les palettes retour reçoivent automatiquement le flag « A anoxier »
|
||||
(risque contamination).
|
||||
|
||||
⚠️ L'API lot SAP est une interrogation synchrone — timeout 1 min,
|
||||
refresh 5s, 5 essais max avant erreur finale.
|
||||
|
||||
⚠️ Les codes articles génériques du ROR doivent être **uniques** (pas
|
||||
réutilisables) pour assurer la traçabilité.
|
||||
|
||||
## Paramètres spécifiques retour client
|
||||
|
||||
Les paramètres existants de LIM-67 sont réutilisés (FILMAGES, etc.).
|
||||
Paramètres additionnels pour l'API SAP :
|
||||
|
||||
| Paramètre | Description | Valeur par défaut |
|
||||
|-----------|-------------|-------------------|
|
||||
| SAP_LOT_VERIFY_URL | URL de l'endpoint API SAP pour la vérification des lots | _(à définir)_ |
|
||||
| SAP_LOT_VERIFY_TIMEOUT | Timeout d'un appel API SAP (en secondes) | 60 |
|
||||
| SAP_LOT_VERIFY_MAX_RETRIES | Nombre maximum de tentatives | 5 |
|
||||
| SAP_LOT_VERIFY_REFRESH | Intervalle de refresh écran d'attente (en secondes) | 5 |
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [x] ~~Format exact du message API lot SAP (requête/réponse)~~ — documenté
|
||||
via LIM-72 (payload POST /api/v1/lot/verify + réponse ET_BATCH)
|
||||
- [ ] URL exacte de l'endpoint SAP (SAP_LOT_VERIFY_URL) à définir
|
||||
(@Fabien)
|
||||
- [ ] Vérification "vendu par Limagrain" : est-ce le champ EV_DEPLOY
|
||||
dans ET_BATCH ou un autre champ de la réponse ? (@Fabien)
|
||||
- [ ] Gestion du token SAP : récupération avant chaque appel ou clé
|
||||
privée ? Mécanisme à préciser (@Fabien)
|
||||
- [ ] Cas du product code manquant en base après réponse OK :
|
||||
combien de temps attendre avant de proposer Réessayer ? (@Fabien)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
|
||||
| 2026-05-12 | Arthur | Flux complet PK retour (LIM-72) : process 8 étapes, API SAP détaillée (payload, séquence, écran attente, retry), statut stock modifiable, tolérance illimitée, paramètres SAP_LOT_VERIFY_*, choix article multi-résultat |
|
||||
| 2026-05-12 | Arthur | LIM-73 : clôture retour client — REF conditionné au rangement ASRS complet (CstAtt11), statut « Clôture en cours » (CstAtt01 réception, jaune), Reception_Close_PR_V2 partie A (event replay), CstAtt01 OE hors tolérance, récap CstAtt clôture |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
|
||||
| [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) | Ticket Jira | 2026 |
|
||||
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (flux fournisseur PK) | 2026 |
|
||||
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira (étiquette RFID) | 2026 |
|
||||
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture REF/ROF retours) | 2026 |
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Inbound — Vue d'ensemble"
|
||||
tags: [inbound, index]
|
||||
status: draft
|
||||
last_updated: 2026-05-12
|
||||
---
|
||||
|
||||
# Inbound — Vue d'ensemble
|
||||
|
||||
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
|
||||
> messages ERP inbound.
|
||||
|
||||
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
|
||||
> [Order Inbound](../../concepts/order-inbound.md)
|
||||
|
||||
## Pages de cette section
|
||||
|
||||
- [Gestion des camions](gestion-camions.md) — arrivée, quais, déclaration image de quai
|
||||
- [Réception fournisseur](reception-fournisseur.md)
|
||||
- [Réception retour](reception-retour.md)
|
||||
- [Contrôle qualité réception](controle-qualite-reception.md)
|
||||
- [Étiquette RFID](etiquette-rfid.md) — format A5, QR GS1, encodage ZPL
|
||||
- [Flux ERP inbound](flux-erp-inbound.md)
|
||||
|
||||
## Vue synthétique du flux inbound Limagrain
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
CAM[Camion arrive] --> PARK[Quai Parking]
|
||||
PARK --> QUAI[Assignation quai + image]
|
||||
QUAI --> DECH[Déchargement sur poumon]
|
||||
DECH --> DECL{Déclaration type}
|
||||
|
||||
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
|
||||
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
|
||||
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
|
||||
|
||||
PROD --> PIE1[PIE_01 contrôle]
|
||||
VIDE --> PIE1
|
||||
|
||||
EXT --> PK[Traitement sur poste PK]
|
||||
PK --> AGV2[AGV → Entrée postes PIE_02/03]
|
||||
AGV2 --> PIE2[PIE_02/03 contrôle]
|
||||
|
||||
PIE1 -->|OK| ASRS[Stockage ASRS]
|
||||
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
|
||||
PIE2 -->|OK| ASRS
|
||||
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
|
||||
|
||||
ASRS --> LOC[Message LOC → SAP]
|
||||
PK --> REF[Clôture → REF + ROF → SAP]
|
||||
```
|
||||
|
||||
## 3 types de réception
|
||||
|
||||
| Type | Message ERP | Passage poste | Entrée PIE |
|
||||
|------|-------------|---------------|------------|
|
||||
| Production | ASN | Non | PIE_01 (côté quais) |
|
||||
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
|
||||
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Inbound — Vue d'ensemble"
|
||||
tags: [inbound, index]
|
||||
status: draft
|
||||
last_updated: 2026-05-12
|
||||
---
|
||||
|
||||
# Inbound — Vue d'ensemble
|
||||
|
||||
> **Périmètre** : réception fournisseur, retours, contrôle qualité à réception,
|
||||
> messages ERP inbound.
|
||||
|
||||
> **Standard EasyWMS** : voir [Reception](../../concepts/reception.md),
|
||||
> [Order Inbound](../../concepts/order-inbound.md)
|
||||
|
||||
## Pages de cette section
|
||||
|
||||
- [Gestion des camions](gestion-camions.md) — arrivée, quais, déclaration image de quai
|
||||
- [Réception fournisseur](reception-fournisseur.md)
|
||||
- [Réception retour](reception-retour.md)
|
||||
- [Contrôle qualité réception](controle-qualite-reception.md)
|
||||
- [Étiquette RFID](etiquette-rfid.md) — format A5, QR GS1, encodage ZPL
|
||||
- [Flux ERP inbound](flux-erp-inbound.md)
|
||||
|
||||
## Vue synthétique du flux inbound Limagrain
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
CAM[Camion arrive] --> PARK[Quai Parking]
|
||||
PARK --> QUAI[Assignation quai + image]
|
||||
QUAI --> DECH[Déchargement sur poumon]
|
||||
DECH --> DECL{Déclaration type}
|
||||
|
||||
DECL -->|Production| PROD[AGV → Entrée quais PIE_01]
|
||||
DECL -->|Extérieure/Retour| EXT[AGV → Poste de travail]
|
||||
DECL -->|Palettes vides| VIDE[AGV → Entrée quais PIE_01]
|
||||
|
||||
PROD --> PIE1[PIE_01 contrôle]
|
||||
VIDE --> PIE1
|
||||
|
||||
EXT --> PK[Traitement sur poste PK]
|
||||
PK --> AGV2[AGV → Entrée postes PIE_02/03]
|
||||
AGV2 --> PIE2[PIE_02/03 contrôle]
|
||||
|
||||
PIE1 -->|OK| ASRS[Stockage ASRS]
|
||||
PIE1 -->|NOK| REJ1[Rejet / Reconditionnement]
|
||||
PIE2 -->|OK| ASRS
|
||||
PIE2 -->|NOK| REJ2[Rejet → Poste d'origine]
|
||||
|
||||
ASRS --> LOC[Message LOC → SAP]
|
||||
PK --> REF[Clôture → REF + ROF → SAP]
|
||||
```
|
||||
|
||||
## 3 types de réception
|
||||
|
||||
| Type | Message ERP | Passage poste | Entrée PIE |
|
||||
|------|-------------|---------------|------------|
|
||||
| Production | ASN | Non | PIE_01 (côté quais) |
|
||||
| Extérieure / Intersite | ROR | Oui | PIE_02/03 (côté postes) |
|
||||
| Retour client | ROR + API lot | Oui | PIE_02/03 (côté postes) |
|
||||
@@ -0,0 +1,268 @@
|
||||
---
|
||||
title: "Contrôle qualité réception — Vérification poids PIE"
|
||||
tags: [inbound, PIE, poids, verrou, inventaire, qualité]
|
||||
status: draft
|
||||
standard_ref: architecture/galileo-integration.md
|
||||
jira_refs: [LIM-66]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-66_Passage_PIE.md, wiki-update-poids-PIE-tolerance.md]
|
||||
last_updated: 2026-05-13
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Contrôle qualité réception — Vérification poids PIE
|
||||
|
||||
> **Résumé** : mécanisme [CUSTOM] de contrôle de poids au passage PIE avec
|
||||
> calcul de tolérance par type article, application automatique de verrous
|
||||
> et mise à jour du poids unitaire.
|
||||
|
||||
> **Standard EasyWMS** : → voir [GALILEO Integration](../../architecture/galileo-integration.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Chez Limagrain, chaque passage au PIE déclenche une vérification de poids
|
||||
qui sert d'**inventaire permanent** par pesée. Ce mécanisme s'applique à
|
||||
**tous les processus** (réception production, extérieure, retour, picking,
|
||||
regroupement, échantillonnage).
|
||||
|
||||
## Contrôles au PIE
|
||||
|
||||
Le PIE effectue les contrôles suivants :
|
||||
|
||||
| Contrôle | Critère de validation |
|
||||
|----------|----------------------|
|
||||
| Étiquette RFID | Connue (détectable) |
|
||||
| Hauteur | ≤ 1900 mm |
|
||||
| Largeur | ≤ 1100 mm |
|
||||
| Longueur | ≤ 1300 mm |
|
||||
| Poids | ≤ 1250 kg |
|
||||
| État palette bois | Correct (lames TK ne doivent pas toucher le bois, pas de ski manquant) |
|
||||
|
||||
> Les erreurs sont configurables par type dans easyS — possibilité
|
||||
> d'envoyer vers différentes destinations selon le type d'erreur
|
||||
> (station error type). Exemple : scotch qui dépasse → station de
|
||||
> reconditionnement, palette vraiment non conforme → rejet complet.
|
||||
|
||||
## Formule de calcul du poids
|
||||
|
||||
### Étape 1 — Poids des lignes de stock
|
||||
|
||||
```
|
||||
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
|
||||
```
|
||||
|
||||
### Étape 2 — Répartition au prorata entre lignes de stock
|
||||
|
||||
Le poids mesuré est réparti au prorata entre les différentes lignes
|
||||
de stock.
|
||||
|
||||
**Source du poids théorique (par ordre de priorité)** : ancienne pesée
|
||||
(champ « Poids » de la ligne de stock), puis poids conversion ITM
|
||||
(champ « Poids théorique » de la ligne de stock).
|
||||
|
||||
**Formules :**
|
||||
|
||||
```
|
||||
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
|
||||
Poids réel de la ligne = Poids lignes de stock × Ratio
|
||||
```
|
||||
|
||||
**Exemple :** 5 lignes d'article A (ITM = 2 kg), 1 ligne d'article B
|
||||
(ITM = 40 kg). Poids théorique total = (5 × 2) + (1 × 40) = 50 kg.
|
||||
Poids mesuré au PIE = 60 kg (hors palette bois).
|
||||
|
||||
| Article | Poids théorique | Ratio | Poids réel calculé |
|
||||
|---------|-----------------|-------|---------------------|
|
||||
| A (× 5) | 2 kg (ITM) | 20 % | 2,4 kg par ligne |
|
||||
| B (× 1) | 40 kg (ITM) | 80 % | 48 kg |
|
||||
| **Total** | 50 kg | 100 % | **60 kg** |
|
||||
|
||||
### Étape 3 — Mise à jour du poids unitaire (CstAtt01)
|
||||
|
||||
Le **CstAtt01** de chaque ligne de stock est mis à jour avec le poids
|
||||
unitaire mesuré :
|
||||
|
||||
```
|
||||
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
|
||||
```
|
||||
|
||||
| Donnée | Champ WMS |
|
||||
|--------|-----------|
|
||||
| Poids unitaire mesuré | **CstAtt01** de la ligne de stock |
|
||||
| Poids réel pesé (total) | Champ standard « poids balance » du support |
|
||||
| Poids réel de la ligne | Champ « Poids réel » de la ligne de stock |
|
||||
|
||||
> **Priorité CstAtt01** : si CstAtt01 a déjà une valeur (pesée
|
||||
> précédente), c'est ce poids unitaire qui est utilisé comme référence
|
||||
> pour **tous les calculs du passage PIE** — ratio (étape 2) **et**
|
||||
> seuil de tolérance (vérification ci-dessous) — à la place du poids
|
||||
> théorique ITM.
|
||||
|
||||
> **Mise à jour du stock : OUI** — le poids calculé est stocké dans
|
||||
> CstAtt01 de la ligne de stock.
|
||||
> **Mise à jour de l'ITM : NON** — le poids théorique de la fiche
|
||||
> article reste inchangé. Raison : le poids varie en fonction de la
|
||||
> production (début/fin de prod), chaque pesée est unique.
|
||||
|
||||
> Le poids est quand même appliqué et recalculé, même en cas de
|
||||
> blocage (verrou).
|
||||
|
||||
## Vérification de la tolérance et blocage
|
||||
|
||||
Ref. [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) — en
|
||||
revue de code.
|
||||
|
||||
### Poids de référence pour le seuil de tolérance
|
||||
|
||||
Le "poids unitaire de l'article" utilisé comme seuil de tolérance suit
|
||||
la même règle de priorité que le ratio :
|
||||
|
||||
| Situation | Poids de référence utilisé |
|
||||
|-----------|---------------------------|
|
||||
| CstAtt01 renseigné (pesée précédente) | **CstAtt01** (poids unitaire mesuré) |
|
||||
| CstAtt01 vide (premier passage PIE) | **Poids ITM** (conversion article) |
|
||||
|
||||
**Conséquence sur les passages successifs** : après un premier passage
|
||||
PIE qui recalibre le poids unitaire (ex. ITM = 10 kg, mesuré = 30 kg),
|
||||
le seuil de tolérance au passage suivant sera basé sur 30 kg (CstAtt01).
|
||||
Un écart de 20 kg (2 unités au poids ITM d'origine) ne déclenchera pas
|
||||
de blocage car il reste inférieur à 1 unité au poids recalibré (30 kg).
|
||||
|
||||
> Validé par le client (échange Justine BEUTIN / Olivier, mai 2026).
|
||||
|
||||
### [CUSTOM] Palettes mono-référence
|
||||
|
||||
**Condition de blocage** : si l'écart de poids correspond à un écart
|
||||
d'une ligne de stock (article manquant ou en trop → écart ≥ poids
|
||||
unitaire de référence, cf. tableau ci-dessus) → blocage via verrou sur
|
||||
le **support** (pas sur le stock) + alerte SmartUI.
|
||||
|
||||
### [CUSTOM] Palettes multi-références — seuil d'alerte
|
||||
|
||||
Pour les palettes contenant plusieurs articles différents, le système
|
||||
utilise le **plus petit poids unitaire de référence** (CstAtt01 si
|
||||
renseigné, sinon ITM, par ligne) comme seuil d'alerte. Si l'écart
|
||||
total ≥ ce plus petit poids → blocage + alerte.
|
||||
|
||||
### Verrous appliqués
|
||||
|
||||
Deux verrous possibles selon le flux :
|
||||
|
||||
| Verrou | Flux | Comportement post-PIE |
|
||||
|--------|------|----------------------|
|
||||
| **HORS TOLERANCE** | Tous sauf retour client | La palette **entre quand même dans l'ASRS** malgré le verrou |
|
||||
| **ECART RETOUR** | Retour client uniquement | La palette est **refusée et envoyée en rejet** (destination gérée par EasyS) |
|
||||
|
||||
### Notification
|
||||
|
||||
- Création d'une **notification SmartUI** via le circuit classique de
|
||||
notifications basé sur un event (pas d'event custom)
|
||||
- Le verrou est posé sur le **support** (pas sur le stock)
|
||||
- Notification dédiée au rejet générée dans le cas ECART RETOUR
|
||||
|
||||
### Comportement selon le flux (détail)
|
||||
|
||||
| Processus | Verrou appliqué | Action |
|
||||
|-----------|-----------------|--------|
|
||||
| Réception production | HORS TOLERANCE | Stockage ASRS avec verrou |
|
||||
| Réception extérieure/intersite | HORS TOLERANCE | Stockage ASRS avec verrou |
|
||||
| Retour client (InboundType=1) | ECART RETOUR | Rejet (pas de stockage ASRS) |
|
||||
| Picking | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
| Regroupement | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
| Échantillonnage | HORS TOLERANCE | Stockage avec verrou, recomptage sur poste |
|
||||
|
||||
Dans tous les cas, le poids est quand même appliqué et recalculé.
|
||||
|
||||
### [CUSTOM] Type ZSIZ — Ajustement automatique
|
||||
|
||||
Si le type d'article est **ZSIZ** (semi-fini calibré / big-bag), un
|
||||
message d'ajustement de stock est envoyé vers SAP via **WSC** contenant
|
||||
le poids réel de la HU, **indépendamment de la tolérance**.
|
||||
|
||||
**Gestion du timing avec le REF :**
|
||||
|
||||
- **Problématique** : au moment du PIE, l'ERP ne connaît peut-être
|
||||
pas encore la palette (REF pas encore envoyé)
|
||||
- **Solution** : chaque palette présente dans un REF est flaguée dans
|
||||
le WMS. Si palette connue de l'ERP → transaction d'écart de poids
|
||||
immédiate. Si palette inconnue → flag de l'écart, puis à l'envoi du
|
||||
REF, un event déclenche la transaction
|
||||
- Le flag d'écart de poids est inclus dans le fichier **LOC** envoyé
|
||||
à SAP
|
||||
|
||||
## Gestion des verrous
|
||||
|
||||
### Consultation
|
||||
|
||||
Vue « Entrepôt → Verrous conteneur » :
|
||||
|
||||
- Verrou appliqué par conteneur
|
||||
- Date d'application
|
||||
- Possibilité de débloquer (lever le verrou)
|
||||
|
||||
### Impact sur l'expédition
|
||||
|
||||
Un verrou empêchant l'expédition bloque l'assignation du stock à un ordre
|
||||
de sortie. Le verrou « Réception » déclenche un **recomptage obligatoire**
|
||||
avant tout processus suivant (picking, regroupement, échantillonnage).
|
||||
|
||||
### [CUSTOM] Dérogation poids
|
||||
|
||||
Pour les processus de **regroupement** et **échantillonnage**, si la palette
|
||||
a un excédent de poids non corrigeable, l'opérateur peut depuis son poste
|
||||
de travail **autoriser** la palette à passer le PIE même si hors tolérance.
|
||||
|
||||
## Post-traitements
|
||||
|
||||
- Réception production : **ASO et ASK désactivés**
|
||||
- Les messages post-PIE ne sont pas générés pour le flux production
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le contrôle poids s'applique à **chaque** passage PIE — une palette
|
||||
peut passer le PIE plusieurs fois (réception → picking → restockage).
|
||||
|
||||
⚠️ Le poids est porté par le **stock** (CstAtt01 de la ligne), pas par
|
||||
la fiche article ITM — chaque pesée est unique.
|
||||
|
||||
⚠️ Les palettes avec verrou « Réception » sont prioritaires dans
|
||||
l'assignation de stock pour l'échantillonnage (permet de combiner
|
||||
recomptage + échantillonnage).
|
||||
|
||||
⚠️ Verrou posé sur le **support** (pas sur le stock) — différent du
|
||||
comportement standard.
|
||||
|
||||
⚠️ Pour les palettes multi-références, le seuil d'alerte est le plus
|
||||
petit poids unitaire parmi toutes les lignes de stock.
|
||||
|
||||
⚠️ Après un passage PIE qui recalibre fortement le poids (ex. ITM
|
||||
10 kg → CstAtt01 30 kg), le seuil de tolérance au passage suivant
|
||||
est proportionnellement plus large. C'est le comportement attendu :
|
||||
chaque pesée fait foi pour la suivante.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [x] Tolérances : le seuil est dynamique (CstAtt01 > ITM), validé par
|
||||
le client (mai 2026). Pas de valeur fixe par type article.
|
||||
- [ ] Valeur du poids palette bois fixe (PALETTE_US) (@Théo)
|
||||
- [ ] Poids variable — vérifier si le standard gère la capture de
|
||||
poids avec poids moyen activé (@Nicolas)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement : prorata, multi-ref, verrou support, ZSIZ timing |
|
||||
| 2026-05-12 | Arthur | LIM-66 : verrous HORS TOLERANCE / ECART RETOUR, CstAtt01 poids unitaire, comportement post-PIE |
|
||||
| 2026-05-13 | Arthur | Clarification tolérance CstAtt01 > ITM pour passages PIE successifs (validation client) |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
|
||||
| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira | 2026 |
|
||||
| Échange Justine BEUTIN / Olivier (Limagrain) | Validation client | mai 2026 |
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Étiquette support RFID — Format mono-référence"
|
||||
tags: [inbound, outbound, RFID, étiquette, ZPL, GS1, support]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-68]
|
||||
confluence_refs: []
|
||||
sources: [LIM-68_Etiquette_RFID.md]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Étiquette support RFID — Format mono-référence
|
||||
|
||||
> **Résumé** : étiquette A5 imprimée lors de la réception
|
||||
> fournisseur/intersite, contenant les informations du support (code,
|
||||
> article, lot, GTIN) avec un QR Code GS1 et un encodage RFID via ZPL.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au
|
||||
> standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Le client Limagrain souhaite un rapport d'étiquette personnalisé pour
|
||||
ses HU (supports) dans le flux de réception fournisseur/intersite.
|
||||
L'étiquette est imprimée automatiquement à la confirmation de création
|
||||
du conteneur sur le poste de travail (voir
|
||||
[Réception fournisseur](reception-fournisseur.md) — étape 5a). Elle
|
||||
peut aussi être réimprimée depuis le menu principal du poste (action
|
||||
« Imprimer étiquette »).
|
||||
|
||||
Ref. [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) —
|
||||
attente déploiement pour test.
|
||||
|
||||
## Format A5 — Contenu de l'étiquette
|
||||
|
||||
| N | Champ | Source WMS | Remarque |
|
||||
|---|-------|-----------|----------|
|
||||
| — | Quantité | Quantité + UdM | En haut de l'étiquette |
|
||||
| 1 | Code support (court) | 6 derniers chiffres du code support | **En gras** |
|
||||
| 2 | Code-barres | Code 128 du code support au format GS1 | |
|
||||
| 3 | Code support (complet) | Code support avec préfixe `(00)` | |
|
||||
| 4 | Espèce (Specie) | `ITM.CstAtt01` | |
|
||||
| 5 | Traitement commercial | `ITM.Family.Description` | |
|
||||
| 6 | Variety print on bag | Tel quel | |
|
||||
| 7 | — | `ITM.CstAtt03` | |
|
||||
| 8 | Lot officiel (Official Batch) | Premier Alias de l'article | |
|
||||
| 9 | Lot interne (Internal Batch) | `ITM.Code` | = Lot SAP |
|
||||
| 10 | Code GTIN | `ITM.CstAtt05` | |
|
||||
| 11 | Date | — | Vide (date non connue de l'ERP) |
|
||||
| 12 | QR Code GS1 | Voir section ci-dessous | |
|
||||
|
||||
## QR Code GS1
|
||||
|
||||
Le QR Code GS1 encode les identifiants suivants :
|
||||
|
||||
| AI (Application Identifier) | Contenu | Source |
|
||||
|------------------------------|---------|--------|
|
||||
| `00` | Numéro HU (code support) | Code support WMS |
|
||||
| `01` | Code GTIN | `ITM.CstAtt05` |
|
||||
| `10` | Lot officiel | Premier Alias de l'article |
|
||||
| `21` | Lot SAP | `ITM.Code` |
|
||||
| `37` | Quantité | Quantité déclarée |
|
||||
|
||||
> La date de production (AI `11`) a été **supprimée** du QR Code.
|
||||
|
||||
## Encodage RFID (ZPL)
|
||||
|
||||
L'impression de l'étiquette combine l'impression physique (texte,
|
||||
codes-barres) et l'encodage de la puce RFID intégrée, le tout via
|
||||
des commandes **ZPL** (Zebra Programming Language).
|
||||
|
||||
### Structure de base
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
; --- Encodage RFID ---
|
||||
^RFW,H^FD<données>^FS
|
||||
|
||||
; --- Contenu imprimé ---
|
||||
^FO50,50^ADN,36,20^FD<texte affiché>^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
### Commandes ZPL utilisées
|
||||
|
||||
| Commande | Rôle |
|
||||
|----------|------|
|
||||
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
|
||||
| `^MMT` | Active le mode RFID sur l'imprimante |
|
||||
| `^RS8,,,1` | Timeout RFID = 8, 1 retry en cas d'échec d'encodage |
|
||||
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
|
||||
| `^FD…^FS` | Donnée à encoder (18 caractères max) |
|
||||
|
||||
### Exemple concret
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
^MMT
|
||||
^RS8,,,1
|
||||
^RFW,A,0,5,3^FDSupport123456789012^FS
|
||||
^FO30,20^A0N,30,25^FDRapport de support^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
## Points d'attention
|
||||
|
||||
- L'imprimante doit être **compatible ZPL** avec encodage RFID
|
||||
(contrainte fournisseur à valider — voir question ouverte dans
|
||||
[Réception fournisseur](reception-fournisseur.md))
|
||||
- Le code support encodé en RFID fait **18 caractères** (5 blocs de
|
||||
4 octets = 20 octets en banque User 3)
|
||||
- L'étiquette est au format **A5 paysage**
|
||||
- La date (champ 11) est volontairement vide car non connue de l'ERP
|
||||
au moment de la réception
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-12 | Arthur | Création initiale depuis LIM-68 |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| [LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68) | Ticket Jira | 2026 |
|
||||
@@ -0,0 +1,195 @@
|
||||
---
|
||||
title: "Flux ERP inbound — Messages réception"
|
||||
tags: [inbound, ERP, ASN, ROR, ROF, REF, ITM, interface]
|
||||
status: draft
|
||||
standard_ref: architecture/erp-integration.md
|
||||
jira_refs: []
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "CR CONSOLIDES REU ERP LIMAGRAIN V1 - CR.md"]
|
||||
last_updated: 2026-05-06
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Flux ERP inbound — Messages réception
|
||||
|
||||
> **Résumé** : catalogue des messages ERP liés aux processus de réception
|
||||
> chez Limagrain, avec direction, déclencheur et contenu principal.
|
||||
|
||||
> **Standard EasyWMS** : → voir [ERP Integration](../../concepts/erp-interface.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
La communication ERP se fait via **XML + Webservice** entre SAP EWM et
|
||||
EasyWMS (service GNA). Tous les messages de réception sont documentés ici.
|
||||
Pour les messages d'expédition, voir
|
||||
[Flux ERP outbound](../04-outbound/flux-erp-outbound.md).
|
||||
|
||||
## Messages entrants (SAP → EasyWMS)
|
||||
|
||||
### ITM — Item Master
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Création/modification article dans SAP |
|
||||
| Contenu | Code lot SAP, description, propriétaire, UdM, poids brut, conversions, profils, type conteneur, quantité complète, type article (FERT/ZSIZ) |
|
||||
| [CUSTOM] | Espèce, génération, marque, variété, traitement commercial, packing unit, code GTIN, semences essais, size, field production area |
|
||||
|
||||
> ⚠️ Chez Limagrain, les **lots SAP** sont gérés comme des articles (descendus
|
||||
> via ITM). L'article Limagrain est un attribut du lot SAP.
|
||||
|
||||
### ASN — Advanced Shipping Notice
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Création HU avec code SSCC en production |
|
||||
| Architecture | **1 ASN = 1 palette de production** (pas d'agrégation — permet suppression individuelle en cas d'annulation) |
|
||||
| Contenu | Numéro HU, article, lot SAP, [CUSTOM] propriétaire Limagrain, statut de stock, quantité (unités de vente) |
|
||||
| Timing | Envoyé dès création de la HU avec code SSCC |
|
||||
|
||||
**Attributs logistiques dans les lignes ASN** :
|
||||
|
||||
| Attribut logistique | Champ SAP | Usage |
|
||||
|---------------------|-----------|-------|
|
||||
| LotCode | Code produit SAP | Différencie produits pour même lot SAP |
|
||||
| Color | Propriétaire réel SAP | ≠ "MECALUX" technique |
|
||||
| Source | Description produit | Désignation courte SAP |
|
||||
| Size | Destination (Pays) | Peut changer |
|
||||
|
||||
**Statuts de stock** : gérés dès l'ASN. Si stock OK : ne PAS envoyer de
|
||||
statut (champ vide ou absent du JSON).
|
||||
|
||||
**Champs NON utilisés** : DivisionType, ReceiptOrderCode, IsSlave,
|
||||
Height/Volume (recalculé au pesage PIE), dates fabrication/expiration,
|
||||
numéro de série.
|
||||
|
||||
### ROR — Reception Order Request
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | ERP → WMS |
|
||||
| Déclencheur | Planification réception dans SAP (extérieures, intersites, retours) |
|
||||
| Contenu | Numéro de réception, articles, lots SAP, quantités (unités de vente) |
|
||||
| Structure | 1 ROR = 1 livraison SAP (un camion peut contenir plusieurs livraisons) |
|
||||
|
||||
**Types de réception (InboundType)** :
|
||||
|
||||
| InboundType | Usage | AccountCode/SupplierCode | Tolérance |
|
||||
|-------------|-------|--------------------------|-----------|
|
||||
| 0 (Fournisseur) | Livraisons DESADV | SupplierCode = "FOURNISSEUR" | Précisée par SAP (override profil) |
|
||||
| 1 (Retour) | Retours clients ORDRSP | AccountCode = "CLIENT" | Illimitée (ReceiveLessAllowed=true) |
|
||||
| 3 (Transfert) | Transferts inter-sites | — | 0% (palettes identifiées) |
|
||||
|
||||
**Paramètres clés** : SingleReceipt = true (pas de reliquat WMS),
|
||||
FreeQuantity non nécessaire. Pas de SSCC dans le ROR (récupéré au scan
|
||||
RFID en réception).
|
||||
|
||||
### [CUSTOM] API Lot SAP (retours clients uniquement)
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP (requête) puis ERP → WMS (réponse) |
|
||||
| Déclencheur | Scan lot officiel inconnu sur poste de travail |
|
||||
| Requête | Lot officiel |
|
||||
| Réponse OK | Lot SAP, articles possibles, descriptions, destinations + déclenchement ITM |
|
||||
| Réponse NOK | Message erreur ("lot n'existe pas" ou "lot non vendu") |
|
||||
|
||||
## Messages sortants (EasyWMS → SAP)
|
||||
|
||||
### REF — Reception Fulfilled
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | **Clôture manuelle** de la réception (action opérateur) |
|
||||
| Contenu | Conteneurs réceptionnés, lignes de stock, [CUSTOM] zone de stockage pour chaque palette, 4 attributs logistiques + lot SAP |
|
||||
| Structure | Un seul REF par réception (pas de progressif, car SingleReceipt=true). Le ReceiptCode (en-tête) = code réception WMS. Le code de l'ordre d'entrée est au niveau de la **ligne** (`LneRecOrdersPotential`) |
|
||||
| Contrainte | L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF |
|
||||
| Données | S'appuie sur les données **réelles** (pas théoriques) |
|
||||
|
||||
### ROF — Reception Order Fulfilled
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | Validation/clôture de l'ordre d'entrée |
|
||||
| Rôle | Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat |
|
||||
| Reliquats | Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat |
|
||||
| Hors tolérance | ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise) |
|
||||
|
||||
### [CUSTOM] LOC — Location
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Direction | WMS → ERP |
|
||||
| Déclencheur | Palette stockée dans l'ASRS (rangement effectif) |
|
||||
| Contenu | Numéro HU, station départ, station arrivée, workzone arrivée, emplacement arrivée |
|
||||
| Condition | Généré uniquement si stations départ et arrivée sont différentes |
|
||||
|
||||
## Diagramme de séquence — Réception production
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant SAP
|
||||
participant WMS as EasyWMS
|
||||
participant GAL as Galileo/PIE
|
||||
|
||||
SAP->>WMS: ITM (article/lot)
|
||||
Note over SAP,WMS: En amont
|
||||
SAP->>WMS: ASN (pré-notif HU)
|
||||
Note over SAP,WMS: À l'expédition source
|
||||
GAL->>WMS: Event PIE (RFID + poids)
|
||||
WMS->>WMS: Contrôle poids + rangement
|
||||
WMS->>GAL: Tâche stockage
|
||||
GAL->>WMS: End (palette stockée)
|
||||
WMS->>SAP: LOC (emplacement)
|
||||
```
|
||||
|
||||
## Diagramme de séquence — Réception extérieure
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant SAP
|
||||
participant WMS as EasyWMS
|
||||
participant PK as Poste travail
|
||||
participant GAL as Galileo/PIE
|
||||
|
||||
SAP->>WMS: ROR (ordre réception)
|
||||
WMS->>PK: Palette sur poste
|
||||
PK->>WMS: Déclaration contenu
|
||||
WMS->>GAL: Tâche évacuation → PIE
|
||||
GAL->>WMS: Event PIE
|
||||
WMS->>WMS: Contrôle + rangement
|
||||
GAL->>WMS: End (stockée)
|
||||
WMS->>SAP: LOC
|
||||
PK->>WMS: Clôture réception
|
||||
WMS->>SAP: REF (avec emplacements)
|
||||
WMS->>SAP: ROF
|
||||
```
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le message REF est retardé jusqu'à validation PIE de tous les conteneurs
|
||||
(peut prendre du temps si file d'attente PIE longue).
|
||||
|
||||
⚠️ Le message LOC n'est pas standard — c'est un [CUSTOM] spécifique
|
||||
Limagrain pour traçabilité emplacement dans SAP.
|
||||
|
||||
⚠️ Les modifications dans les master data ne doivent **pas** être faites
|
||||
directement dans EasyWMS (risque d'écrasement par prochain ITM).
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-06 | Arthur | Enrichissement ASN (1 par palette, attributs logistiques, champs non utilisés), ROR (InboundType, tolérances, SingleReceipt), REF (clôture manuelle, zone stockage, contrainte rangement), ROF (rôle, reliquats, hors tolérance) — depuis CR consolidé ERP |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| CR CONSOLIDES REU ERP LIMAGRAIN V1 | CR ateliers interfaçage | 23/02/2026 |
|
||||
@@ -0,0 +1,348 @@
|
||||
---
|
||||
title: "Gestion des camions — Arrivée, quais et déclaration image de quai"
|
||||
tags: [inbound, camion, quai, TRF, image-de-quai, étiquette, SmartUI]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-62, LIM-63, LIM-64, LIM-65]
|
||||
confluence_refs: []
|
||||
sources: [LIM-62_gestion-camions.md, LIM-63_64_65.md]
|
||||
last_updated: 2026-05-06
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Gestion des camions — Arrivée, quais et déclaration image de quai
|
||||
|
||||
> **Résumé** : flux complet depuis l'arrivée physique d'un camion jusqu'à la
|
||||
> déclaration des palettes sur une image de quai (poumon de réception). Couvre
|
||||
> l'annonce camion, l'assignation de quai, l'affichage chauffeur, le workflow
|
||||
> TRF de déclaration et l'impression d'étiquettes support.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
> Le standard prévoit la création manuelle de réceptions et leur association à
|
||||
> des ordres d'entrée ; Limagrain ajoute une couche de gestion physique des
|
||||
> camions (plaque, quai, affichage chauffeur) et un workflow TRF dédié pour la
|
||||
> déclaration des palettes sur les images de quai.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Chez Limagrain, le flux de réception commence **avant** le déchargement : un
|
||||
agent de quai annonce le camion, lui assigne un quai, et les chauffeurs sont
|
||||
orientés via un affichage extérieur. Après déchargement physique, un cariste
|
||||
déclare les palettes sur l'image de quai via un workflow TRF dédié. Ce n'est
|
||||
qu'après cette déclaration que les AGV viennent récupérer les palettes.
|
||||
|
||||
Ce processus est commun à tous les types de réception (production, extérieure,
|
||||
retour). Les flux spécifiques de chaque type sont documentés dans les pages
|
||||
dédiées : [Réception fournisseur](reception-fournisseur.md),
|
||||
[Réception retour](reception-retour.md).
|
||||
|
||||
## Flux fonctionnel global
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant CH as Chauffeur
|
||||
participant AQ as Agent de quai
|
||||
participant SM as SmartUI
|
||||
participant AFF as Affichage extérieur
|
||||
participant CAR as Cariste (TRF)
|
||||
participant WMS as EasyWMS
|
||||
participant AGV as AGV
|
||||
|
||||
CH->>AQ: Annonce arrivée camion
|
||||
AQ->>SM: Crée réception + saisie plaque
|
||||
SM->>SM: Vérifie classes OE identiques
|
||||
AQ->>SM: Assigne quai (ou PARKING)
|
||||
SM->>AFF: Mise à jour affichage (WS)
|
||||
AFF->>CH: Plaque + quai assigné
|
||||
CH->>CH: Se gare au quai indiqué
|
||||
CH->>CAR: Déchargement physique
|
||||
Note over CAR: Décharge depuis l'emplacement<br/>le plus éloigné du quai
|
||||
CAR->>CAR: TRF > Réceptions > Image de quai
|
||||
CAR->>WMS: Déclare nb palettes, poumon, position
|
||||
WMS->>WMS: Crée palettes virtuelles PALETTE_US
|
||||
WMS-->>CAR: Impression étiquettes (si type Autre)
|
||||
AGV->>AGV: Récupère palettes sur image de quai
|
||||
```
|
||||
|
||||
## Étape 1 — Annonce du camion (LIM-62)
|
||||
|
||||
### Création de la réception
|
||||
|
||||
L'agent de quai accède à la vue **Ordre d'entrée > Réceptions** dans SmartUI.
|
||||
Il crée une nouvelle réception en saisissant :
|
||||
|
||||
- **Plaque d'immatriculation** (champ "Camion", ex-"Document") — non
|
||||
obligatoire à la création, peut être renseignée après coup
|
||||
- **Destination** : `PARKING` (quai fictif d'attente) par défaut, ou un quai
|
||||
réel si disponible
|
||||
- **Ordres d'entrée** : sélection des OE du camion
|
||||
|
||||
### Contrôle de classe
|
||||
|
||||
> **Règle** : il est interdit de créer une réception mélangeant des OE de
|
||||
> classes de préavis de réception différentes (`InboundClassCode`).
|
||||
|
||||
Si l'utilisateur sélectionne des OE de classes différentes, un message
|
||||
d'erreur bloque la création :
|
||||
|
||||
> *"Impossible de créer une réception avec des ordres d'entrée ayant des
|
||||
> classes de préavis de réception différentes"*
|
||||
|
||||
Ce contrôle est implémenté dans le `VAssistCreateReceptionOE` (steps 2 et 3)
|
||||
et dans la vue des ordres d'entrées. L'exception compare le `InboundClassCode`
|
||||
de chaque OE sélectionné au premier de la liste.
|
||||
|
||||
## Étape 2 — Assignation du quai (LIM-62)
|
||||
|
||||
L'agent consulte les disponibilités via le **tableau d'occupation des quais**
|
||||
(ViewDetailPanel dans la vue `ReceptionVList`). Il sélectionne la réception et
|
||||
assigne un quai réel.
|
||||
|
||||
### Règles d'assignation
|
||||
|
||||
- Le quai et l'image de quai sont réservés dès la sélection
|
||||
- Un quai partiellement occupé peut être réutilisé (gestion manuelle de la
|
||||
place restante)
|
||||
- ~~Blocage si flux différent (ex : expédition)~~ — supprimé
|
||||
- Si aucun quai disponible → l'opérateur conserve `PARKING` et attend une
|
||||
libération
|
||||
- Modification possible a posteriori
|
||||
|
||||
### Tableau d'occupation des quais
|
||||
|
||||
Le panneau `CST_Docks_Workload` (Column Span = 2) affiche pour chaque quai les
|
||||
réceptions, tournées et OS associés avec les plaques correspondantes :
|
||||
|
||||
| Quai | Réceptions / Camions |
|
||||
|------|----------------------|
|
||||
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
|
||||
| QUAI_01 | |
|
||||
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
|
||||
| ... | |
|
||||
|
||||
Ce tableau est aussi disponible dans le `VAssistReceptionAssignDock` (step 1
|
||||
utilise l'entité `CST_DockStationsWorkloadForView` au lieu de `Station`).
|
||||
|
||||
## Étape 3 — Affichage chauffeur (LIM-63)
|
||||
|
||||
Un écran d'affichage extérieur (WS / dialogue EasyWMS) montre aux chauffeurs
|
||||
sur le parking les quais assignés avec les plaques d'immatriculation.
|
||||
|
||||
### Spécifications
|
||||
|
||||
- Afficher uniquement les quais avec des réceptions ou OS associés
|
||||
- Prévoir l'affichage de **6 quais + le parking** sans scroll
|
||||
- Afficher les plaques (champ "Camion" / Document)
|
||||
|
||||
> **Référence technique** : dialogue EasyBuilder, cf. [documentation
|
||||
> Mecalux](https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md)
|
||||
|
||||
## Étape 4 — Déclaration image de quai via TRF (LIM-64)
|
||||
|
||||
Après déchargement physique, le cariste déclare les palettes via un menu TRF
|
||||
dédié **Réceptions > Image de quai**.
|
||||
|
||||
### Règle de déchargement physique
|
||||
|
||||
Le cariste doit décharger en commençant par l'emplacement le **plus éloigné
|
||||
du quai** en suivant un ordre précis. Cela permet d'identifier les
|
||||
emplacements occupés pour les AGV.
|
||||
|
||||
### Workflow 7 écrans
|
||||
|
||||
Le parcours d'écrans dépend du type de réception :
|
||||
|
||||
- **Production** : écrans 1, 3, 4, 5, 7
|
||||
- **Autres** (fournisseur, intersite, retours) : écrans 1, 2, 3, 4, 5, 6, 7
|
||||
|
||||
#### Écran 1 — Type de réception
|
||||
|
||||
Choix parmi :
|
||||
|
||||
- Production
|
||||
- Autres (fournisseur, intersite, retours, etc.)
|
||||
- Pile de palette
|
||||
|
||||
Échap : retour menu.
|
||||
|
||||
#### Écran 2 — Sélection de la réception
|
||||
|
||||
Uniquement si type = **Autres**. L'opérateur choisit la réception concernée.
|
||||
|
||||
Échap : retour écran 1.
|
||||
|
||||
#### Écran 3 — Nombre de palettes
|
||||
|
||||
Prompt : « Nombre de palettes de la réception »
|
||||
|
||||
Validation :
|
||||
|
||||
- Nombre entre 1 et 26 inclus
|
||||
- Somme des supports déjà présents sur le poumon + nombre saisi ≤ 26
|
||||
|
||||
Message d'erreur explicatif si invalide. Échap : retour écran 2.
|
||||
|
||||
#### Écran 4 — Choix image de quai (poumon)
|
||||
|
||||
Le workflow liste tous les poumons liés aux quais (réception + expédition)
|
||||
puis filtre :
|
||||
|
||||
- Exclure les poumons ayant des supports clients (liés à des OS) ou des
|
||||
tâches de shipping en destination
|
||||
- Exclure les poumons pleins (supports = capacité)
|
||||
- Exclure les poumons sans assez d'emplacements libres consécutifs après le
|
||||
dernier conteneur
|
||||
|
||||
> **Double check** : au moment du choix effectif, les vérifications sont
|
||||
> refaites — entre l'affichage de la liste et la sélection, la réalité a pu
|
||||
> changer.
|
||||
|
||||
Échap : retour écran 3.
|
||||
|
||||
#### Écran 5 — Sous-emplacement de départ
|
||||
|
||||
Prompt : « Sous-emplacement de la première palette de la réception »
|
||||
|
||||
Validation :
|
||||
|
||||
- Nombre valide
|
||||
- L'emplacement de départ et tous les suivants (pour atteindre le nombre de
|
||||
palettes déclaré) doivent être **vides**
|
||||
|
||||
Exemple : si des palettes d'une autre réception occupent la position 5, et
|
||||
qu'on déclare 5 palettes à partir de la position 3, c'est rejeté car la
|
||||
position 5 est occupée.
|
||||
|
||||
Échap : retour écran 4.
|
||||
|
||||
#### Écran 6 — Présence de big-bags
|
||||
|
||||
Uniquement si type = **Autres**.
|
||||
|
||||
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
|
||||
|
||||
Boutons OUI / NON. L'information est conservée pour la suite du flux.
|
||||
|
||||
Échap : retour écran 4.
|
||||
|
||||
#### Écran 7 — Validation et création
|
||||
|
||||
Récapitulatif affiché :
|
||||
|
||||
- Image de quai
|
||||
- Type de réception
|
||||
- Nombre de palettes
|
||||
- Sous-emplacement de départ
|
||||
- Présence de big-bags (si applicable)
|
||||
|
||||
À la validation :
|
||||
|
||||
1. **Création des palettes virtuelles** : type `PALETTE_US`, réparties sur les
|
||||
sous-emplacements consécutifs à partir de la position de départ
|
||||
2. **Séquence spéciale** : 18 caractères commençant par `8`
|
||||
(ex : `800000000000000001`, `800000000000000002`, etc.)
|
||||
— cf. [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14)
|
||||
3. **Impression étiquettes** : uniquement si type = **Autres**, une étiquette
|
||||
par palette déclarée (format LIM-65)
|
||||
|
||||
Échap : retour écran 5. Après validation : retour écran 2.
|
||||
|
||||
> **Validation de sécurité** : si le poumon ou la position de départ est
|
||||
> devenu indisponible entre l'écran 5 et la validation, un message d'erreur
|
||||
> est affiché. Idem si la réception sélectionnée a été supprimée entre-temps.
|
||||
|
||||
## Étiquette support image de quai (LIM-65)
|
||||
|
||||
Format **A5 paysage**. Imprimée pour chaque palette de type "Autres"
|
||||
(pas pour la production).
|
||||
|
||||
| Champ | Contenu |
|
||||
|-------|---------|
|
||||
| CODE | Code du support (séquence 8xxx) |
|
||||
| RECEPTION | Code de la réception |
|
||||
| DATE | Date d'impression |
|
||||
| EMPL. | Sous-emplacement du poumon |
|
||||
| QR Code | Code du support |
|
||||
|
||||
## Implémentation technique (AD customs)
|
||||
|
||||
### Entités
|
||||
|
||||
| Entité | Usage |
|
||||
|--------|-------|
|
||||
| `CST_DockStationsWorkloadForView` | Affichage occupation des quais dans les vues réception |
|
||||
|
||||
### Queries
|
||||
|
||||
| Query | Entité cible |
|
||||
|-------|-------------|
|
||||
| `CST_DockStationsWorkload_ForView` | `CST_DockStationsWorkloadForView` |
|
||||
|
||||
### Vues modifiées
|
||||
|
||||
| Vue | Modification |
|
||||
|-----|-------------|
|
||||
| `ReceptionVList` | ViewDetailPanel `CST_Docks_Workload` (Column Span = 2) — occupation quais |
|
||||
| `VAssistCreateReceptionOE` | Exception steps 2 et 3 — blocage classes OE différentes |
|
||||
| `VAssistReceptionAssignDock` | Step 1 : entité `CST_DockStationsWorkloadForView` remplace `Station` |
|
||||
|
||||
### Ressources i18n
|
||||
|
||||
| Code | FR | EN |
|
||||
|------|----|----|
|
||||
| `CST_Reception_MultiClassError` | Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes | Can't create reception with inbound orders with different inbound order class |
|
||||
| `CST_Prop_Reception_Document` | Camion | Truck |
|
||||
| `CST_Prop_Station_Workload` | Assignations / Camions | Assignations / Trucks |
|
||||
| `CST_Reception_DockWorkload_Panel_Title` | Occupation des quais | Docks workload |
|
||||
|
||||
> **Note** : toutes les ressources custom sont préfixées `CST_` (convention
|
||||
> Mecalux France validée lors de la revue de code).
|
||||
|
||||
### Revue de code
|
||||
|
||||
- **05/03/2026** — Vincent Charvet : implémentation initiale
|
||||
([`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166))
|
||||
- **06/03/2026** — Nicolas Chabanis : revue non valide (préfixes ressources,
|
||||
commentaire `//Custom end` manquant, Column Span, titre colonne)
|
||||
- **09/03/2026** — Nicolas Chabanis : **revue validée**
|
||||
|
||||
## Points d'attention
|
||||
|
||||
- La plaque du camion n'est **pas obligatoire** à la création de la réception
|
||||
— elle peut être renseignée après coup (confirmé 09/03/2026)
|
||||
- Le déchargement doit respecter l'ordre : emplacement le plus éloigné
|
||||
d'abord, sinon les AGV ne peuvent pas identifier correctement les positions
|
||||
occupées
|
||||
- La capacité maximale d'un poumon est de **26 emplacements**
|
||||
- Les palettes de type "Production" ne génèrent **pas** d'étiquettes au TRF
|
||||
(elles arrivent déjà étiquetées via ASN)
|
||||
- Le double-check de disponibilité du poumon au moment du choix est
|
||||
**critique** pour éviter les collisions entre opérateurs simultanés
|
||||
- Les séquences de supports virtuels commencent par `8` et font 18 caractères
|
||||
— ne pas confondre avec les séquences SSCC standard
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [ ] Gestion TRF si AGV pas prêts au démarrage — lié aussi à la déclaration
|
||||
image de quai (@Théo)
|
||||
- [ ] Position étiquette image de quai (devant/côté palette) — à valider
|
||||
avec le client (@Justine)
|
||||
- [ ] Faut-il rendre la saisie du camion (plaque) obligatoire pour garantir
|
||||
la cohérence de l'affichage chauffeur ? (@Justine)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|-------------|
|
||||
| 2026-05-06 | Arthur | Création initiale depuis LIM-62, LIM-63, LIM-64, LIM-65 |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) | Ticket Jira | 18/02/2026 |
|
||||
| [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63) | Ticket Jira | 2026 |
|
||||
| [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) | Ticket Jira | 2026 |
|
||||
| [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65) | Ticket Jira | 2026 |
|
||||
| [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) | Ticket Jira (séquences supports) | 2026 |
|
||||
@@ -0,0 +1,614 @@
|
||||
---
|
||||
title: "Réception fournisseur — Production et extérieures/intersites"
|
||||
tags: [inbound, réception, production, ASN, ROR, PIE, clôture, REF, ROF]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-67, LIM-73]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", LIM-67_Postes_Travail_Reception.md, "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md"]
|
||||
last_updated: 2026-05-12
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Réception fournisseur — Production et extérieures/intersites
|
||||
|
||||
> **Résumé** : deux flux de réception distincts chez Limagrain — production
|
||||
> (directe ASRS via ASN) et extérieures/intersites (passage poste de travail
|
||||
> via ROR). Le déchargement camion est une étape commune.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Limagrain gère 3 types de réception. Cette page couvre les deux premiers :
|
||||
|
||||
1. **Réception depuis la production** (flux majoritaire)
|
||||
2. **Réceptions extérieures / transferts intersites**
|
||||
|
||||
Le troisième type (retours client) est couvert dans
|
||||
[Réception retour](reception-retour.md).
|
||||
|
||||
## Étape commune — Arrivée et déclaration du camion
|
||||
|
||||
> **Page dédiée** : le flux complet d'arrivée camion, d'assignation de quai,
|
||||
> d'affichage chauffeur et de déclaration image de quai via TRF est documenté
|
||||
> en détail dans [Gestion des camions](gestion-camions.md) (LIM-62/63/64/65).
|
||||
> Ce qui suit est un résumé.
|
||||
|
||||
### [CUSTOM] Réservation image de quai
|
||||
|
||||
1. Camion arrive → agent de quai crée une **réception** dans la vue
|
||||
« Ordre d'entrée > Réceptions » (SmartUI)
|
||||
2. Saisie de la **plaque d'immatriculation** et de la **destination** :
|
||||
« PARKING » par défaut (quai fictif d'attente) ou quai réel si disponible
|
||||
3. Sélection des OE (ordres d'entrée) concernés — chaque OE est flagué
|
||||
via un CstAtt
|
||||
4. Agent consulte la disponibilité des quais via un graphique dans la vue
|
||||
des réceptions et assigne un quai réel
|
||||
5. [CUSTOM] Écran parking (via WS) affiche plaque + n° quai pour le chauffeur
|
||||
|
||||
**Contraintes d'assignation image de quai :**
|
||||
|
||||
- Quai et image de quai **réservés** dès la sélection — réutilisation possible
|
||||
si place restante (gestion manuelle)
|
||||
- Blocage si flux différent (ex : expédition en cours sur ce quai)
|
||||
- Blocage si l'image de quai a des supports associés à un OS (expédition)
|
||||
ou inversement
|
||||
- Si aucun quai disponible → attente de libération
|
||||
- Il faut empêcher de créer une réception avec des OE de **classes de
|
||||
préavis différentes** (message d'erreur bloquant)
|
||||
|
||||
Voir aussi [Quais et poumons](../04-outbound/consolidation-chargement.md).
|
||||
|
||||
### Déchargement physique
|
||||
|
||||
- Cariste décharge palettes depuis emplacement **le plus éloigné du quai**
|
||||
- Permet d'identifier précisément les emplacements occupés pour les AGV
|
||||
|
||||
### [CUSTOM] Déclaration sur l'image de quai
|
||||
|
||||
Menu TRF custom : Réception > Images de quai > Déclaration
|
||||
|
||||
**Séquence commune :**
|
||||
|
||||
1. Scan de l'image de quai
|
||||
2. Choix du type de réception (Production / Fournisseur / Retour client /
|
||||
Palettes vides)
|
||||
3. Saisie du nombre de palettes + emplacement de départ
|
||||
4. Association à la réception (auto pour Production via CstAtt « ASN »,
|
||||
sélection manuelle de l'OE pour les autres)
|
||||
5. Prompt big-bag (Oui/Non) — sauté pour Production
|
||||
6. Écran de validation
|
||||
7. Création des supports dans le WMS
|
||||
|
||||
**Pour les réceptions extérieures/retours client :**
|
||||
|
||||
- Impression d'une **étiquette par support** à coller sur la palette
|
||||
(ROR.Code + date + « À réceptionner » + code support + empl. image de quai)
|
||||
- Vérification capacité image de quai
|
||||
|
||||
### Création tâches de mouvement AGV
|
||||
|
||||
- EasyWMS indique **point de prise** et **point de dépose** uniquement
|
||||
- Sens prise/dépose géré par le gestionnaire de flotte AGV (iGo)
|
||||
- Pour réceptions nécessitant un poste : assignation automatique selon
|
||||
contraintes déclarées (mode, big-bag, distance la plus courte)
|
||||
- Assignation manuelle également possible
|
||||
- Si aucun poste disponible → tâche en attente
|
||||
|
||||
### Libérations
|
||||
|
||||
- **Image de quai** : libérée **automatiquement** quand il n'y a plus
|
||||
de palettes dessus (vérification via supports présents)
|
||||
- **Quai** : libéré **manuellement** par l'agent au départ du véhicule
|
||||
|
||||
---
|
||||
|
||||
## Flux 1 — Réception depuis la production
|
||||
|
||||
### Flux physique
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Cariste
|
||||
participant Quai/Poumon
|
||||
participant AGV
|
||||
participant Buffer
|
||||
participant PIE_01
|
||||
participant ASRS
|
||||
Cariste->>Quai/Poumon: Déchargement
|
||||
Note over Quai/Poumon: Supports virtuels créés
|
||||
AGV->>Buffer: Transport support virtuel
|
||||
Buffer->>PIE_01: Convoyeur entrée production
|
||||
Note over PIE_01: Suppression support virtuel (containerMovedEvent)
|
||||
PIE_01->>PIE_01: Déplacement palette ASN + contrôles
|
||||
alt PIE OK
|
||||
PIE_01->>ASRS: Stockage (stratégie rangement)
|
||||
else PIE NOK
|
||||
PIE_01->>Cariste: Rejet → poumon au sol + notification
|
||||
end
|
||||
```
|
||||
|
||||
### Résumé du processus
|
||||
|
||||
1. Déclaration sur l'image de quai (voir étape commune ci-dessus)
|
||||
2. Déplacement AGV → entrée production (via supports virtuels)
|
||||
3. Passage PIE (suppression support virtuel + validation palette ASN)
|
||||
4. Stockage ou rejet
|
||||
5. Libération quai / image de quai
|
||||
|
||||
### 1) [CUSTOM] Pré-notification ASN
|
||||
|
||||
Message **ASN** descendu de SAP **avant** l'arrivée physique (expédition
|
||||
depuis l'ancien magasin). Contenu :
|
||||
|
||||
- Numéro unique HU
|
||||
- Article / Lot SAP
|
||||
- [CUSTOM] Propriétaire Limagrain
|
||||
- Statut de stock
|
||||
- Quantité (unités de vente)
|
||||
|
||||
Batch possible : jusqu'à **500 conteneurs par message ASN**.
|
||||
|
||||
> Les palettes sont étiquetées RFID en sortie de production (hors EasyWMS).
|
||||
> L'étiquette est collée sur la housse.
|
||||
|
||||
### 2) [CUSTOM] Supports virtuels et déplacement AGV
|
||||
|
||||
**Principe des supports virtuels :**
|
||||
|
||||
- Création de supports « virtuels » identiques à de vrais supports mais
|
||||
avec une **séquence différente (8000)** pour les identifier
|
||||
- La flotte AGV déplace la palette fictive jusqu'au PIE
|
||||
- Le tracking s'effectue avec le support virtuel sur le premier convoyeur
|
||||
|
||||
**Destination** : entrée production (convoyeur vers ASRS). L'AGV dépose
|
||||
sur un **buffer d'entrée** (type POUMON MINILOAD AD) — jamais directement
|
||||
sur le PIE.
|
||||
|
||||
**Suppression du support virtuel :**
|
||||
|
||||
- Basée sur le fonctionnement standard des routes AGV
|
||||
- Surveillance des **containerMovedEvent**
|
||||
- Filtre : type palette ASN + destination type PIE → suppression du
|
||||
support virtuel (séquence 8000)
|
||||
|
||||
### [CUSTOM] Redirection si entrée production saturée
|
||||
|
||||
En cas de blocage long terme sur l'entrée production :
|
||||
|
||||
- **Solution standard** : système de routes avec distances — route
|
||||
principale distance 1, routes secondaires distance 2
|
||||
- On ferme le PIE de production → le WMS redirige automatiquement vers
|
||||
les autres entrées disponibles
|
||||
- **Élément à bloquer** : le PIE (pas un élément physiquement plus
|
||||
proche de l'entrée)
|
||||
|
||||
> Pour les tests sans AGV : utilisation de **routes virtuelles** en
|
||||
> configuration easyS qui téléportent automatiquement les palettes.
|
||||
|
||||
### 3) Passage au PIE et création palette ASN
|
||||
|
||||
**Séquence au PIE :**
|
||||
|
||||
1. Fin d'ordre AGV au PIE → suppression du support virtuel
|
||||
(via containerMovedEvent)
|
||||
2. Déplacement de la palette depuis l'emplacement « ASN » au PIE
|
||||
3. Le ratio poids s'effectue au niveau de l'article
|
||||
|
||||
Contrôles : dimensions (1300×1100×1900), poids (≤1250 kg), état palette,
|
||||
RFID connue (ASN). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md) pour le
|
||||
détail des contrôles PIE et la répartition du poids.
|
||||
|
||||
**PIE OK :**
|
||||
|
||||
- [CUSTOM] Aucun message ASO généré
|
||||
- [CUSTOM] Vérification poids — tolérance par type article, verrou
|
||||
« Réception » sur le **support** si écart > seuil
|
||||
- Mise à jour CstAtt01 de la ligne de stock (poids unitaire calculé)
|
||||
- [CUSTOM] Si type article ZSIZ → message ajustement stock vers SAP
|
||||
via WSC (poids réel HU) — voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md) pour
|
||||
la gestion du timing avec le REF
|
||||
- Stratégie de rangement appliquée
|
||||
- Réservation canal optimale selon nb palettes ASN restantes
|
||||
|
||||
**PIE NOK :**
|
||||
|
||||
- Rejet standard — plus besoin d'étiquette spécifique
|
||||
- Palette dirigée automatiquement vers un **poumon au sol** (zone de
|
||||
rejet)
|
||||
- **Notification SmartUI** envoyée aux opérateurs
|
||||
- Opérateur se rend physiquement à la zone de rejet pour corriger
|
||||
- Si non corrigeable : bouton custom édite étiquette « NON CONFORME,
|
||||
RENVOI » et crée une tâche vers un poumon dédié
|
||||
- [CUSTOM] Aucun message ASK généré
|
||||
- [CUSTOM] CstAtt du support flagué avec « Prod » (pas de poste de
|
||||
travail d'origine)
|
||||
|
||||
---
|
||||
|
||||
## Flux 2 — Réceptions extérieures / transferts intersites
|
||||
|
||||
### Flux physique (extérieur)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Cariste
|
||||
participant Quai/Poumon
|
||||
participant AGV
|
||||
participant Poste PK
|
||||
participant Filmeuse
|
||||
participant PIE_02/03
|
||||
participant ASRS
|
||||
Cariste->>Quai/Poumon: Déchargement
|
||||
AGV->>Poste PK: Transport vers poste de travail
|
||||
Poste PK->>Poste PK: Traitement réception
|
||||
AGV->>Filmeuse: Évacuation (filmage si demandé)
|
||||
Filmeuse->>PIE_02/03: Table d'entrée
|
||||
PIE_02/03->>PIE_02/03: Contrôles
|
||||
alt PIE OK
|
||||
PIE_02/03->>ASRS: Stockage
|
||||
else PIE NOK
|
||||
PIE_02/03->>Poste PK: Rejet → poumon au sol + notification
|
||||
end
|
||||
```
|
||||
|
||||
### Résumé du processus (extérieur)
|
||||
|
||||
1. Déclaration sur l'image de quai
|
||||
2. Déplacement AGV → poste de travail
|
||||
3. Traitement au poste de travail (constitution mono-ref + déclaration)
|
||||
4. Déplacement AGV → table d'entrée (+ filmage si demandé)
|
||||
5. Passage PIE
|
||||
6. Stockage ou rejet
|
||||
7. Clôture de la réception
|
||||
8. Libération quai / image de quai
|
||||
|
||||
### 1) Notification ROR
|
||||
|
||||
Message **ROR** de SAP → EasyWMS :
|
||||
|
||||
- Numéro de réception (1 ROR = 1 livraison SAP, un camion peut
|
||||
contenir N livraisons)
|
||||
- Articles / Lots SAP / Quantités (en unités de vente)
|
||||
- Pas de création de lignes autorisée
|
||||
- Tolérance quantité : **0 %** pour intersites (palettes déjà
|
||||
identifiées), paramétrable **par ligne ROR** pour extérieures
|
||||
(uniquement en dépassement %)
|
||||
- `IsSingleReceipt = true` — le WMS ne gère pas de reliquats
|
||||
automatiques. Si réception incomplète, SAP crée une nouvelle
|
||||
livraison
|
||||
- `InboundType = 0` (Standard) pour les deux sous-types
|
||||
|
||||
| Élément SAP | Correspondance EasyWMS | Remarque |
|
||||
|-------------|------------------------|----------|
|
||||
| Commande d'achat | — | Peut être cadencée en plusieurs livraisons |
|
||||
| Livraison | 1 ROR | Un ROR = une livraison |
|
||||
| Camion | N livraisons | Un camion peut contenir plusieurs livraisons |
|
||||
|
||||
> Les transferts intersites : le site émetteur est considéré comme un
|
||||
> fournisseur dans EasyWMS.
|
||||
|
||||
### 2) [CUSTOM] Gestion des SSCC
|
||||
|
||||
- Les numéros SSCC **ne sont pas envoyés** dans le ROR
|
||||
(`LineList>ContainerCode`)
|
||||
- Le SSCC est récupéré au moment du **scan RFID** en réception
|
||||
- Si SSCC présent sur la palette → conservation lors de la réédition
|
||||
RFID
|
||||
- Si SSCC absent → création d'un nouveau SSCC et ré-étiquetage
|
||||
|
||||
> Raison : éviter la complexification du process si l'étiquette est
|
||||
> endommagée.
|
||||
|
||||
### 3) [CUSTOM] Déplacement vers poste de travail
|
||||
|
||||
Assignation automatique du poste selon :
|
||||
|
||||
1. Non bloqué
|
||||
2. En service
|
||||
3. Mode autorise la réception
|
||||
4. Capacité compatible avec la déclaration
|
||||
5. Distance la plus courte
|
||||
|
||||
Assignation manuelle aussi possible. Si aucun poste disponible → attente.
|
||||
|
||||
### 4) Constitution palettes mono référence
|
||||
|
||||
Les palettes à destination ASRS doivent être **mono référence** autant
|
||||
que possible. Si multi-référence à l'arrivée :
|
||||
|
||||
- Opérateur dispose manuellement une palette vide sur une TP
|
||||
(non géré par le WMS)
|
||||
- Tri de marchandise pour constituer des conteneurs mono-ref
|
||||
|
||||
> Le process de constitution mono-référence est **standard** — pas de
|
||||
> développement spécifique.
|
||||
|
||||
### 5) [CUSTOM] Traitement au poste de travail
|
||||
|
||||
Ref. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) — en
|
||||
attente CDP.
|
||||
|
||||
Les opérateurs utilisent le mode **Tâches automatiques** sur PC. Le
|
||||
code de réception est récupéré automatiquement via le `CstAtt08` du
|
||||
conteneur présent sur le poste.
|
||||
|
||||
**Affichage fournisseur** : sur **tous les écrans** du process,
|
||||
afficher `"Fournisseur: CODE - NOM"`.
|
||||
|
||||
#### a) Confirmation de création support (Big Bag)
|
||||
|
||||
Si le conteneur scanné est un **conteneur virtuel** de réception, un
|
||||
écran de confirmation crée le nouveau support « réel ». Sur cet écran :
|
||||
|
||||
- Ligne `"BIG BAG : NON"` (état initial)
|
||||
- Bouton **"BIG BAG ON"** → toggle vers `"BIG BAG : OUI"` / **"BIG BAG
|
||||
OFF"**
|
||||
- Valeur `true`/`false` stockée dans **CstAtt02** du support
|
||||
- Impression automatique d'une **étiquette RFID** dès confirmation —
|
||||
voir [Étiquette RFID](etiquette-rfid.md) (LIM-68)
|
||||
|
||||
#### b) Menu principal du poste
|
||||
|
||||
Écran central avec 5 actions — les informations du support actuel sont
|
||||
toujours affichées à droite. Après chaque action, retour à ce menu.
|
||||
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Ajouter stock** | Sélection article, lot, quantité (écrans standard). Afficher quantité attendue + UdM sans pré-remplir le prompt. Statut de stock affiché mais **non modifiable** (boutons masqués). Écrans date fin de statut et commentaire **skippés**. Pour l'anoxie : set **CstAtt03** du support à `true` |
|
||||
| **Nouveau support** | Scan emplacement, confirmation de création (retour à l'étape a). Le nouveau conteneur devient le support actif |
|
||||
| **Changer de support** | Scan du code support à sélectionner comme support actif |
|
||||
| **Imprimer étiquette** | Réimpression de l'étiquette RFID (voir [Étiquette RFID](etiquette-rfid.md)) |
|
||||
| **Terminer** | Vérification fermeture + filmage + évacuation (voir ci-dessous) |
|
||||
|
||||
#### c) Action « Terminer »
|
||||
|
||||
**Vérification fermeture réception** : si le conteneur actuel est le
|
||||
**dernier** de la réception (nombre de conteneurs virtuels avec
|
||||
`CstAtt08 = codeRecep` + conteneurs avec `CstAtt08 = codeRecep` et
|
||||
`CstAtt10 = true`), proposer la fermeture de la réception avec
|
||||
uniquement l'option confirmer.
|
||||
|
||||
**Sélection du programme de filmage** : dialogue avec liste issue du
|
||||
paramètre **"FILMAGES"** :
|
||||
|
||||
```
|
||||
Valeur par défaut : 0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
|
||||
```
|
||||
|
||||
La valeur choisie (`0`, `A`, `B`, `C`…) est stockée dans le
|
||||
**CstAtt05** du support et transmise à Galileo en custom data.
|
||||
|
||||
Après validation, une **tâche d'évacuation** est générée pour le
|
||||
transport AGV du poste de travail vers la table d'entrée.
|
||||
|
||||
#### Résumé des CstAtt support (poste de travail)
|
||||
|
||||
| CstAtt | Contenu | Set par |
|
||||
|--------|---------|---------|
|
||||
| CstAtt02 | Flag Big Bag (`true`/`false`) | Écran confirmation support |
|
||||
| CstAtt03 | Flag anoxie (`true`) | Action « Ajouter stock » |
|
||||
| CstAtt05 | Programme de filmage (`0`, `A`, `B`…) | Action « Terminer » |
|
||||
| CstAtt08 | Code de réception | Déclaration image de quai |
|
||||
| CstAtt10 | Flag support traité (`true`) | Fin de traitement |
|
||||
|
||||
### 6) Déplacement AGV → table d'entrée et filmage
|
||||
|
||||
- L'AGV déplace le conteneur vers la table d'entrée
|
||||
- **Gestion du filmage** : le programme de filmage est transmis à
|
||||
Galileo via custom data au moment du passage. Si le PIE dit NOK →
|
||||
pas de filmage (custom data non transmis). Le filmage ne se fait que
|
||||
si le PIE valide la palette
|
||||
|
||||
### 7) Passage PIE
|
||||
|
||||
Identique au flux production (mêmes formules de répartition poids,
|
||||
mêmes contrôles PIE). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md).
|
||||
|
||||
**Différence en cas de rejet PIE** : la palette est dirigée vers un
|
||||
**poumon au sol** avec **notification SmartUI** (ancienne approche de
|
||||
renvoi au poste de travail d'origine abandonnée — risque de blocage
|
||||
AGV/table/poste). CstAtt du support flagué avec le poste de travail
|
||||
d'origine.
|
||||
|
||||
---
|
||||
|
||||
## Clôture des réceptions (extérieures/intersites)
|
||||
|
||||
Ref. [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) — LOT
|
||||
1.3.
|
||||
|
||||
La clôture concerne uniquement les flux passant par un poste de travail
|
||||
(extérieures, intersites, retours client). La réception production (ASN)
|
||||
n'est pas concernée (pas de clôture manuelle).
|
||||
|
||||
**Relation réception ↔ OE** : une réception peut servir **plusieurs
|
||||
OE**, mais un OE est servi par **une seule réception**. Si la réception
|
||||
associée à un OE est incomplète, SAP gère le reliquat via une nouvelle
|
||||
livraison (donc nouvel OE).
|
||||
|
||||
### Paramétrage
|
||||
|
||||
- `IsSingleReceipt = true` — une seule réception par OE, pas de
|
||||
reliquats WMS
|
||||
- `AutoCloseReception = true` — le WMS clôture automatiquement la
|
||||
réception quand les conditions custom sont remplies (§ Déclenchement)
|
||||
- `AutoCloseInboundOrder = true` — à la clôture de la réception, chaque
|
||||
OE complété à 100 % ou dans la tolérance est auto-clôturé (ROF
|
||||
envoyé) et auto-archivé (absent de la vue). Les OE en écart hors
|
||||
tolérance restent ouverts
|
||||
|
||||
### Deux niveaux de clôture
|
||||
|
||||
| Niveau | Description | Message ERP |
|
||||
|--------|-------------|-------------|
|
||||
| Réception | Clôture d'une livraison physique | REF |
|
||||
| Ordre d'entrée (OE) | Clôture de la commande complète | ROF |
|
||||
|
||||
### Déclenchement de l'auto-close (LIM-73 §1.1)
|
||||
|
||||
L'auto-close de la réception se déclenche — et le bouton « Fermer
|
||||
réception » n'est visible — que si les deux conditions suivantes sont
|
||||
**simultanément** remplies :
|
||||
|
||||
1. **Aucune palette fictive** ayant `CstAtt08 = <code de la réception>`
|
||||
n'est présente (plus de palettes à venir de l'image de quai)
|
||||
2. **ET** :
|
||||
- **Si Workstation** : au plus **1** palette réelle au PK avec
|
||||
`CstAtt10 = true` (la dernière en cours)
|
||||
- **Si Vue Réception** : **aucune** palette réelle au PK avec
|
||||
`CstAtt10 = true`
|
||||
|
||||
Si au moins une ligne est **hors tolérance**, un message d'avertissement
|
||||
s'affiche : « La réception a été clôturée mais les quantités reçues sont
|
||||
hors tolérance, voir avec le manager pour réguler les quantités attendues
|
||||
puis fermer l'ordre d'entrée ».
|
||||
|
||||
### [CUSTOM] Adaptation Reception_Close_PR_V2 (LIM-73 §1.3)
|
||||
|
||||
Le workflow standard de clôture est modifié pour deux comportements :
|
||||
|
||||
**Partie A — Condition retours** : si la réception est de type retour
|
||||
client, la clôture et le REF sont différés jusqu'au rangement ASRS
|
||||
complet. Voir [Réception retour — Clôture](reception-retour.md) pour le
|
||||
détail (CstAtt11, CstAtt01 réception, statut « Clôture en cours »).
|
||||
|
||||
**Partie B — Pose CstAtt01 OE hors tolérance** : à la clôture effective,
|
||||
pour chaque **ligne article hors tolérance** (en plus ou en moins) :
|
||||
|
||||
1. Rechercher le **premier OE** (FirstOrDefault) parmi les OE associés
|
||||
contenant ce combo code article / lot
|
||||
2. Poser `CstAtt01 = true` sur cet OE
|
||||
|
||||
> En pratique un combo code article/lot n'est jamais partagé entre
|
||||
> plusieurs OE d'une même réception — le FirstOrDefault est
|
||||
> déterministe.
|
||||
|
||||
Les OE flaggés ne se clôturent pas automatiquement (ROF bloqué) et
|
||||
s'affichent en rouge dans la vue (voir § Clôture des OE ci-dessous).
|
||||
|
||||
### Contenu du REF (custom)
|
||||
|
||||
Un seul REF est envoyé par réception (pas de REF progressif, car
|
||||
`IsSingleReceipt = true`). Contenu :
|
||||
|
||||
- Numéros de conteneurs réceptionnés
|
||||
- Lignes de stocks associées
|
||||
- [CUSTOM] **Zone de stockage** (récupérée depuis le code emplacement
|
||||
du support) :
|
||||
- Fournisseur / intersite : si un support se trouve hors de l'ASRS
|
||||
au moment du REF → valeur **"NON RANGEE"**
|
||||
- Retour client : ce cas ne se produit pas (REF conditionné au
|
||||
rangement complet — voir [Réception retour](reception-retour.md))
|
||||
- [CUSTOM] Attributs stock remontés : code produit SAP, code
|
||||
propriétaire réel, description courte, pays de destination, lot SAP
|
||||
|
||||
**LOC** : envoyé sur delta de 5 min (palette créée/déplacée/supprimée).
|
||||
Le LOC ne prend pas en compte les palettes liées à une réception non
|
||||
fermée (standard dans le WSC forké — développement dédié
|
||||
[LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76)).
|
||||
|
||||
### Clôture des ordres d'entrée (OE) (LIM-73 §2)
|
||||
|
||||
| Situation OE | Clôture | ROF | Affichage vue OE |
|
||||
|--------------|---------|-----|------------------|
|
||||
| Reçu = attendu | Auto-close | Envoi auto | Auto-archivé → absent |
|
||||
| Écart dans la tolérance | Auto-close (custom) | Envoi auto | Auto-archivé → absent |
|
||||
| Écart hors tolérance (`CstAtt01 OE = true`) | Manuelle par non-opérateur | Envoyé manuellement | **Rouge** — bouton restreint |
|
||||
|
||||
**Visibilité du bouton « Clôturer l'OE »** :
|
||||
|
||||
- OE sans écart ou dans la tolérance : accessible à tous (standard),
|
||||
mais auto-archivé donc invisible
|
||||
- OE hors tolérance (CstAtt01 OE = true, **rouge**) : bouton visible
|
||||
**uniquement pour les profils non-opérateurs** (admin, manager, chef
|
||||
d'équipe). Masqué pour les opérateurs standards
|
||||
|
||||
Le manager régularise dans SAP (envoi éventuel d'un nouveau ROR) puis
|
||||
clôture manuellement l'OE → ROF envoyé.
|
||||
|
||||
### Réception excédentaire (> % autorisé)
|
||||
|
||||
Le WMS bloque. Solutions possibles :
|
||||
|
||||
| Solution | Description |
|
||||
|----------|-------------|
|
||||
| Modifier la commande | Message ROR UPSERT depuis SAP |
|
||||
| Réception aveugle | Sans lien fournisseur (nécessite gestion REF BLIND) |
|
||||
| Nouvelle commande | Créer une nouvelle commande d'achat pour le reliquat |
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ En cas de blocage long terme sur l'entrée production, le WMS
|
||||
redirige automatiquement vers les autres entrées via le système de
|
||||
routes avec distances (fermeture du PIE de production).
|
||||
|
||||
⚠️ Les palettes issues de réceptions extérieures/intersites reçoivent
|
||||
**automatiquement** le flag « A anoxier » (CstAtt03).
|
||||
|
||||
⚠️ L'impression étiquettes réception au déchargement n'est possible que
|
||||
pour les réceptions extérieures et retours clients (pas production).
|
||||
|
||||
⚠️ Les rejets PIE sont dirigés vers un **poumon au sol** avec
|
||||
notification SmartUI (ancienne approche de renvoi au PK abandonnée).
|
||||
|
||||
⚠️ Le process de constitution mono-référence est **standard** (pas de
|
||||
développement spécifique).
|
||||
|
||||
⚠️ Filmage : transmis à Galileo via custom data (CstAtt05) — uniquement
|
||||
si PIE OK. Paramètre SmartUI `FILMAGES` définit la liste des programmes.
|
||||
|
||||
⚠️ `AutoCloseReception = true` mais la clôture effective dépend des
|
||||
CstAtt08/CstAtt10 (tous supports traités). La clôture OE est
|
||||
automatique si conditions remplies (`AutoCloseInboundOrder`).
|
||||
|
||||
⚠️ Le CstAtt01 poids unitaire mesuré (PIE) est **prioritaire** sur le
|
||||
poids ITM pour tous les calculs suivants.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [x] Programme de filmage exact — documenté, 8 programmes A→H,
|
||||
paramètre SmartUI `FILMAGES` (LIM-67)
|
||||
- [ ] Gestion TRF si AGV pas prêts au démarrage (@Théo)
|
||||
- [ ] Utilisation du ROC (confirmation de réception) — point interne
|
||||
Limagrain (@Justine)
|
||||
- [ ] Création fournisseurs/clients à la volée dans EasyWMS —
|
||||
faisabilité technique (@Nicolas)
|
||||
- [ ] Vérifier fonctionnement ExceedPercentageAllowed vs profil de
|
||||
réception (@Nicolas)
|
||||
- [ ] Choix fournisseur imprimantes RFID — exiger compatibilité
|
||||
ZPL (@Théo)
|
||||
- [ ] Position étiquette image de quai (devant/côté) — à valider
|
||||
avec le client (@Justine)
|
||||
- [ ] Poids variable — vérifier si le standard gère la capture de
|
||||
poids (@Nicolas)
|
||||
- [ ] Surplus non réceptionné hors tolérance — quelle solution pour
|
||||
les palettes impossibles à réceptionner ? (@Justine)
|
||||
- [ ] Palette refusée PIE mais non supprimée — comment gérer le
|
||||
support qui reste en base ? (@Nicolas) (LIM-73)
|
||||
- [ ] WF clôture OE : faut-il modifier le WF existant ou en créer
|
||||
un nouveau pour la condition CstAtt01 ? (@Fabien) (LIM-73)
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|--------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV Confluence |
|
||||
| 2026-05-12 | Arthur | Réécriture section traitement poste travail (LIM-67) : menu 5 actions, CstAtt02/03/05/08/10, filmage FILMAGES |
|
||||
| 2026-05-12 | Arthur | Réécriture section clôture (LIM-73) : AutoCloseReception=true, Reception_Close_PR_V2, REF custom, clôture OE 3 cas |
|
||||
| 2026-05-13 | Arthur | Restauration sections tronquées (points d'attention, questions, historique, références) |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
|
||||
| Réception - LIMAGRAIN - DEV - Confluence | Page ateliers DEV | 2026 |
|
||||
| [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) | Ticket Jira (postes travail) | 2026 |
|
||||
| [LIM-73](https://easywmsfrance.atlassian.net/browse/LIM-73) | Ticket Jira (clôture/REF) | 2026 |
|
||||
@@ -0,0 +1,466 @@
|
||||
---
|
||||
title: "Réception retour commandes clients"
|
||||
tags: [inbound, réception, retour, client, API, lot]
|
||||
status: draft
|
||||
standard_ref: concepts/reception.md
|
||||
jira_refs: [LIM-72, LIM-67, LIM-68, LIM-66, LIM-64, LIM-70, LIM-73]
|
||||
confluence_refs: []
|
||||
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md", "LIM-72 LOT1.3 [RETOUR] Flux complet PK.md", "LIM-73 - LOT1.3 [RECEPTION] Fermetures, REF et gestion retours.md", "recap_session_LIM-72_13-05-2026.md"]
|
||||
last_updated: 2026-05-13
|
||||
author: Arthur
|
||||
---
|
||||
|
||||
# Réception retour commandes clients
|
||||
|
||||
> **Résumé** : processus spécifique de réception des retours client, avec
|
||||
> interrogation API SAP pour validation lot, et déclaration enrichie sur
|
||||
> poste de travail.
|
||||
|
||||
> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md)
|
||||
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
||||
|
||||
## Contexte projet
|
||||
|
||||
Les retours client suivent un flux similaire aux réceptions extérieures
|
||||
(passage poste de travail obligatoire) mais avec des particularités :
|
||||
|
||||
- `InboundType = 1` (Return) — vs 0 (Standard) pour les autres flux
|
||||
- Création de lignes autorisée (article non attendu possible)
|
||||
- Tolérance illimitée : profil de réception par défaut configuré en
|
||||
« illimité » sur tous les articles
|
||||
- `ReceiveLessAllowed = true` — réception partielle toujours autorisée
|
||||
- Interrogation API SAP pour valider le lot officiel
|
||||
- `AccountCode` = code client SAP (le client doit exister dans EasyWMS)
|
||||
|
||||
## Process complet de réception retour client
|
||||
|
||||
| Étape | Description | Ticket |
|
||||
|-------|-------------|--------|
|
||||
| 1 | Déclaration sur l'image de quai | [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64) |
|
||||
| 2 | Déplacement AGV → poste de travail | [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) |
|
||||
| 3 | **Traitement au poste de travail** | [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72) |
|
||||
| 4 | Déplacement AGV → table d'entrée (+ filmage si demandé) | — |
|
||||
| 5 | Passage PIE | [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) |
|
||||
| 6 | Stockage ou rejet | — |
|
||||
| 7 | Clôture de la réception | — |
|
||||
| 8 | Libération quai / image de quai | — |
|
||||
|
||||
Voir [Réception fournisseur](reception-fournisseur.md) pour le détail
|
||||
du déchargement camion et des déclarations initiales
|
||||
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) pour le
|
||||
flux fournisseur au PK).
|
||||
|
||||
## Notification ROR
|
||||
|
||||
Message ROR de SAP (type ORDRSP) avec :
|
||||
|
||||
- Numéro de réception
|
||||
- Articles / Lots / Quantités attendues
|
||||
- Codes articles **génériques** (codes uniques avec nomenclature
|
||||
précise, pas réutilisables — assure la traçabilité)
|
||||
|
||||
**Différence clé** : cette réception **autorise la création de lignes**.
|
||||
Limagrain peut recevoir un article non présent dans le ROR initial.
|
||||
Un article inconnu de la base EasyWMS = ROR refusé. Un article connu
|
||||
mais non prévu dans le retour = accepté (tolérance illimitée).
|
||||
|
||||
## [CUSTOM] Identification lot — Interrogation API SAP
|
||||
|
||||
Lors du scan du lot officiel sur le poste de travail, le WMS vérifie
|
||||
d'abord si le lot est connu localement. Si oui, pas d'appel API. Sinon :
|
||||
|
||||
### Rappel : structure des articles chez Limagrain
|
||||
|
||||
Chez Limagrain, le **code article WMS = lot SAP** (cf.
|
||||
[Données principales](../06-erp-interface/donnees-principales.md)).
|
||||
Chaque lot SAP est descendu via le fichier **ITM** (fiche article
|
||||
complète), et le code produit est un attribut stocké en CstAtt du stock.
|
||||
Le **lot officiel** est l'alias de l'article dans le WMS.
|
||||
|
||||
Quand le lot est "inconnu du WMS", cela signifie qu'**aucun article
|
||||
(ITM) n'existe avec ce lot officiel comme alias**. Il faut demander à
|
||||
SAP d'envoyer la fiche article complète.
|
||||
|
||||
### Logique de vérification
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Scan / saisie lot officiel] --> B{Lot officiel connu du WMS ?<br/>= alias article existant ?}
|
||||
B -- Oui --> C{Vendu par Limagrain ?}
|
||||
B -- Non --> D[Appel API SAP]
|
||||
D --> E[Écran attente<br/>refresh 5s / timeout 1 min]
|
||||
E --> F{ITM reçu via API WMS ?}
|
||||
F -- Oui --> C
|
||||
F -- Non / Timeout --> G{Tentative < 5 ?}
|
||||
G -- Oui --> H[Bouton Réessayer]
|
||||
H --> D
|
||||
G -- Non --> I[Erreur finale :<br/>contacter responsable]
|
||||
C -- Oui --> J{Plusieurs articles ?}
|
||||
C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
|
||||
J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
|
||||
J -- Oui --> M[Dialogue choix article<br/>par pays d'origine]
|
||||
M --> L
|
||||
```
|
||||
|
||||
### Appel API SAP — Vérification du lot officiel (ATH214)
|
||||
|
||||
L'appel API REST est fait **directement depuis le workflow** (pas via
|
||||
GNA). Il sert à notifier SAP que le WMS a besoin de la fiche article.
|
||||
|
||||
> **Architecture CPI** : tous les flux WMS → SAP passent par un
|
||||
> **endpoint unique** SAP CPI, différencié par le champ `MessageType`
|
||||
> dans l'enveloppe JSON. Le flux retour utilise `MessageType = "ATH214"`.
|
||||
> Voir [Intégration GNA → SAP-CPI](../06-erp-interface/gna-sap-cpi.md)
|
||||
> pour le détail de l'architecture et de l'authentification OAuth 2.0.
|
||||
|
||||
**Séquence d'échange :**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant WF as WMS (workflow)
|
||||
participant CPI as SAP CPI
|
||||
participant SAP as SAP ECC
|
||||
|
||||
WF->>CPI: GET /http/ATHInboundMessage<br/>MessageType: ATH214
|
||||
Note over WF,CPI: Auth: OAuth 2.0 Bearer token<br/>Body: { MessageType, data }
|
||||
CPI->>SAP: Z_IATH214 (check batch)
|
||||
SAP-->>CPI: Réponse (EV_RETURN, ET_BATCH)
|
||||
CPI-->>WF: Réponse JSON
|
||||
alt EV_RETURN = "X" (OK)
|
||||
SAP->>CPI: ATH002 (push ITM automatique)
|
||||
CPI->>WF: POST ApplicationService/ITM
|
||||
Note over CPI,WF: Fiche article complète :<br/>lot SAP = code article,<br/>lot officiel = alias
|
||||
WF->>WF: Poll alias en base (5s)
|
||||
alt Alias trouvé
|
||||
WF->>WF: Continuer
|
||||
else Timeout 1 min
|
||||
WF->>WF: Proposer réessayer
|
||||
end
|
||||
else EV_RETURN ≠ "X" (NOK)
|
||||
WF->>WF: Erreur immédiate
|
||||
end
|
||||
```
|
||||
|
||||
**Authentification OAuth 2.0 :**
|
||||
|
||||
- Grant type : `client_credentials`
|
||||
- Token endpoint TEST :
|
||||
`https://vilm-cpi-test-73ltxp48.authentication.eu30.hana.ondemand.com/oauth/token`
|
||||
- Token endpoint PROD : à définir
|
||||
- Body : `x-www-form-urlencoded` avec `grant_type`, `client_id`,
|
||||
`client_secret`
|
||||
- Le token est envoyé en header `Authorization: Bearer <token>`
|
||||
- Expiration gérée côté WMS (cache + renouvellement)
|
||||
|
||||
**Payload de requête :**
|
||||
|
||||
```json
|
||||
GET /http/ATHInboundMessage
|
||||
{
|
||||
"MessageType": "ATH214",
|
||||
"data": {
|
||||
"IV_LGNUM": "WF02",
|
||||
"IV_MATNR": "",
|
||||
"IV_CHARG": "",
|
||||
"IV_BATCH_OFF": "<lot officiel scanné>",
|
||||
"IV_RETURN": "<code OE retour>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Champ | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `IV_LGNUM` | CHAR 4 | Toujours `"WF02"` |
|
||||
| `IV_MATNR` | CHAR 40 | OPTIONNEL - code lot WMS (= product code SAP) |
|
||||
| `IV_CHARG` | CHAR 10 | OPTIONNEL - code article WMS (= lot SAP) |
|
||||
| `IV_BATCH_OFF` | CHAR 30 | Lot officiel scanné sur le sac |
|
||||
| `IV_RETURN` | CHAR 10 | Numéro du document de retour (code OE) |
|
||||
|
||||
> ⚠️ **Méthode HTTP** : `GET` avec body JSON — spécifique SAP CPI.
|
||||
> Header `Connection: keep-alive` requis.
|
||||
|
||||
**Payload de réponse :**
|
||||
|
||||
```json
|
||||
{
|
||||
"EV_RETURN": "X",
|
||||
"ET_RETURN": [ { "TYPE": "...", "MESSAGE": "..." } ],
|
||||
"ET_BATCH": [
|
||||
{
|
||||
"MATNR": "000000000000020955",
|
||||
"CHARG": "2023293649",
|
||||
"BATCH_OFF": "F0964D002488",
|
||||
"EV_DEPLOY": "X"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
| Champ | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `EV_RETURN` | CHAR 1 | `"X"` = aucune erreur, vide = erreur |
|
||||
| `ET_RETURN[]` | Table | Messages d'erreur ou de succès SAP |
|
||||
| `ET_BATCH[].MATNR` | CHAR 40 | Code lot WMS = product code SAP |
|
||||
| `ET_BATCH[].CHARG` | CHAR 10 | Code article WMS = lot SAP |
|
||||
| `ET_BATCH[].BATCH_OFF` | CHAR 30 | Lot officiel |
|
||||
| `ET_BATCH[].EV_DEPLOY` | CHAR 1 | `"X"` = déployé/vendu, `""` = non |
|
||||
|
||||
> ⚠️ **Mapping inversé CHARG / MATNR** : contrairement à la
|
||||
> nomenclature SAP standard, `MATNR` (Material Number) porte ici le
|
||||
> **product code** (= code lot WMS), et `CHARG` (Charge/Batch) porte le
|
||||
> **code article WMS** (= lot SAP). Ce mapping est confirmé par Michael
|
||||
> Chaudier et Vincent Goyet (avril 2026).
|
||||
|
||||
> ⚠️ **À confirmer** : le nom du champ de déploiement est ambigu dans
|
||||
> les échanges — `EV_DEPLOY` ou `ZDEPLOY` ? En attente de clarification
|
||||
> (question A2 dans
|
||||
> [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
|
||||
|
||||
Si `EV_RETURN = "X"`, on récupère dans `ET_BATCH` tous les
|
||||
`BATCH_OFF` dont `EV_DEPLOY = "X"` — ce sont les lots autorisés
|
||||
pour l'opérateur.
|
||||
|
||||
### Écran d'attente pendant la réception de l'ITM
|
||||
|
||||
Après l'appel API, SAP appelle directement l'API du WMS pour pousser
|
||||
l'ITM. Pendant cette attente :
|
||||
|
||||
- **Message** : "Vérification du lot en cours..."
|
||||
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si
|
||||
un **alias correspondant au lot officiel** existe en base
|
||||
- **Bouton "Réessayer"** visible (relance un nouvel appel API)
|
||||
- **Timeout** : 1 minute maximum par tentative
|
||||
- **Nombre maximum de tentatives** : 5
|
||||
|
||||
| Tentative | Comportement en cas de timeout |
|
||||
|-----------|-------------------------------|
|
||||
| 1 à 4 | Message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer |
|
||||
| 5 | Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton Annuler → retour au scan lot |
|
||||
|
||||
### Choix du code lot (multi-résultat)
|
||||
|
||||
Si l'API a renvoyé **plusieurs résultats** dans `ET_BATCH` (plusieurs
|
||||
`BATCH_OFF` avec `EV_DEPLOY = "X"`), un dialogue de sélection est
|
||||
affiché avec la liste des codes lots disponibles. L'opérateur en choisit
|
||||
un (filtrage par pays d'origine).
|
||||
|
||||
Si un **seul résultat** → sélection automatique, pas de dialogue.
|
||||
|
||||
**Pourquoi le choix article ?** Un lot SAP peut être associé à plusieurs
|
||||
articles (dépend du pays d'origine). L'opérateur doit choisir l'article
|
||||
physiquement présent sur la palette.
|
||||
|
||||
**Gestion dans le REF :** le code générique envoyé dans le ROR est
|
||||
remplacé par le vrai code lot dans le REF (custom).
|
||||
|
||||
## Déclaration au poste de travail (LIM-72)
|
||||
|
||||
Le traitement au PK reprend les mêmes étapes que le flux fournisseur
|
||||
([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec des
|
||||
adaptations. Le tableau ci-dessous récapitule chaque étape et ses
|
||||
différences :
|
||||
|
||||
| # | Étape | Différence vs fournisseur (LIM-67) |
|
||||
|---|-------|------------------------------------|
|
||||
| 1 | Sélection de la réception | Affichage "**Client: CODE - NOM**" (au lieu de "Fournisseur") sur tous les écrans |
|
||||
| 2 | Big bag (CstAtt02) | Identique — toggle ON/OFF |
|
||||
| 3 | Scan lot officiel + vérification | **+ Vérification API SAP** (voir section ci-dessus) |
|
||||
| 4 | Déclaration quantité | Identique — affichage qté attendue + UdM, prompt non pré-rempli |
|
||||
| 4bis | Flag big-bag (bouton custom) | Identique (CstAtt02) |
|
||||
| 5 | Statut de stock | **Modifiable** — boutons visibles (masqués dans LIM-67) |
|
||||
| 6 | Flag "À anoxier" | Identique (CstAtt03 = true) |
|
||||
| 7 | Programme de filmage | Identique (paramètre FILMAGES → CstAtt05) |
|
||||
| 8 | Impression étiquette RFID | Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) |
|
||||
| 9 | Validation → évacuation AGV | Identique |
|
||||
|
||||
### Statut de stock — Modifiable
|
||||
|
||||
Contrairement au flux fournisseur (LIM-67) où le statut de stock est
|
||||
verrouillé (boutons masqués), dans le flux retour client :
|
||||
|
||||
- Les **boutons de changement de statut sont visibles** et fonctionnels
|
||||
- L'opérateur peut modifier le statut (ex : Conforme, Sac sale,
|
||||
Non conforme, etc.)
|
||||
- Les écrans de **date de fin de statut** et **commentaire** suivent
|
||||
le comportement standard (non skippés contrairement au fournisseur)
|
||||
- [CUSTOM] Statuts spécifiques retour : **F9** (sacs sales), **B6**
|
||||
(non conforme) — assignables uniquement dans ce processus
|
||||
|
||||
### Tolérance illimitée
|
||||
|
||||
- **Article non prévu** dans le retour → accepté (création de ligne
|
||||
autorisée)
|
||||
- **Quantité supérieure** au prévu → acceptée
|
||||
- **Quantité inférieure** au prévu → acceptée (réception fermée
|
||||
manuellement)
|
||||
|
||||
> Le prompt type de poste (3 ou 6 TP) prévu initialement est
|
||||
> **abandonné** — remplacé par un message d'avertissement si le poste
|
||||
> adjacent est déjà ouvert (voir
|
||||
> [Stations picking](../03-picking/stations-picking.md)).
|
||||
|
||||
## Constitution palettes mono référence
|
||||
|
||||
Obligation de constituer des palettes **mono référence** avant stockage.
|
||||
Si la palette retour est multi-ref :
|
||||
|
||||
- Opérateur appelle une palette vide sur une TP disponible
|
||||
- Tri de marchandise
|
||||
|
||||
## Calcul poids et passage PIE
|
||||
|
||||
Identique aux réceptions extérieures (mêmes formules de répartition
|
||||
prorata, mêmes contrôles). Voir
|
||||
[Contrôle qualité réception](controle-qualite-reception.md).
|
||||
|
||||
**Différences pour les retours client :**
|
||||
|
||||
- Verrou si écart poids : **« Écart inventaire »** (vs « Réception »
|
||||
pour les autres flux) — verrou posé sur le **support** (pas sur
|
||||
le stock)
|
||||
- Action requise en cas d'écart : **recomptage du nombre de sacs**
|
||||
- Rejet PIE : dirigé vers **poumon au sol** + notification SmartUI
|
||||
(ancienne approche de renvoi au PK abandonnée)
|
||||
|
||||
## Clôture — Spécificités retour client (LIM-73)
|
||||
|
||||
Le mécanisme général de clôture (déclenchement auto-close, tolérance par
|
||||
ligne, CstAtt01 OE hors tolérance, clôture OE) est documenté dans
|
||||
[Réception fournisseur — Clôture](reception-fournisseur.md). Cette
|
||||
section décrit le **delta retour client** : le REF est conditionné au
|
||||
rangement ASRS complet.
|
||||
|
||||
### Contexte métier
|
||||
|
||||
Pour les retours clients, le REF influe sur la **facturation SAP**. Il
|
||||
ne doit être envoyé que lorsque **tous les supports** de la réception
|
||||
sont rangés dans l'ASRS (et ont passé l'ensemble des contrôles,
|
||||
notamment PIE).
|
||||
|
||||
Pour les autres types de réception (fournisseur / intersite), le REF est
|
||||
émis à la clôture de la réception, quelle que soit la position des
|
||||
supports.
|
||||
|
||||
### CstAtt11 — Marqueur de rangement ASRS
|
||||
|
||||
À chaque fin de tâche de rangement dans l'ASRS :
|
||||
|
||||
- Vérifier si le support provient d'une réception de type **retour**
|
||||
- Si oui → `CstAtt11 = true` sur le support
|
||||
- Sinon → aucune action
|
||||
|
||||
Le CstAtt11 est posé une fois et n'est **jamais remis à false**, même si
|
||||
le support ressort ensuite de l'ASRS (picking). Cela garantit que la
|
||||
condition de clôture reste satisfaisable même si une palette a déjà été
|
||||
expédiée entre-temps.
|
||||
|
||||
### Statut « Clôture en cours »
|
||||
|
||||
Dans la vue des réceptions, le statut visuel est piloté par le
|
||||
`CstAtt01 de la réception` (posé par Reception_Close_PR_V2) :
|
||||
|
||||
| CstAtt01 réception | État | Affichage |
|
||||
|---------------------|------|-----------|
|
||||
| null / vide | En attente | Standard |
|
||||
| true | Clôture en attente de rangement ASRS complet | **« Clôture en cours »**, ligne en **jaune** |
|
||||
|
||||
Pour les réceptions non-retour, CstAtt01 de la réception n'est pas
|
||||
utilisé (affichage standard).
|
||||
|
||||
### Adaptation Reception_Close_PR_V2 — Partie A (retours)
|
||||
|
||||
- **Si non-retour** → clôture immédiate, génération REF (standard)
|
||||
- **Si retour** :
|
||||
- Vérifier que **tous les supports** ont `CstAtt11 = true`
|
||||
- **Oui** → `CstAtt01 réception = false`, fermer la réception,
|
||||
générer REF
|
||||
- **Non** → ne pas fermer, `CstAtt01 réception = true` (statut
|
||||
« Clôture en cours »). Le WF est rejoué à chaque event
|
||||
_task finished_ sur un support de la réception
|
||||
|
||||
> Si une palette est refusée au PIE puis retirée du retour (ROR), le
|
||||
> client doit la **supprimer du WMS**, sinon la clôture ne sera jamais
|
||||
> effectuée.
|
||||
|
||||
### Zone de stockage dans le REF
|
||||
|
||||
Pour les retours, le REF n'est émis qu'une fois tous les supports rangés
|
||||
en ASRS → la valeur sera toujours une zone réelle (jamais "NON RANGEE").
|
||||
|
||||
### Récapitulatif CstAtt clôture retour
|
||||
|
||||
| CstAtt | Entité | Rôle |
|
||||
|--------|--------|------|
|
||||
| CstAtt08 | Palette fictive | Code réception — détecte l'absence de palettes fictives restantes (§ auto-close) |
|
||||
| CstAtt10 | Palette réelle au PK | `true` pendant traitement PK — détecte qu'aucune palette n'est en cours de traitement |
|
||||
| CstAtt11 | Palette réelle | `true` quand rangée en ASRS — condition de clôture retour |
|
||||
| CstAtt01 | Réception | `true` = clôture en attente de rangement ASRS (affichage jaune) |
|
||||
|
||||
## État du développement LIM-72
|
||||
|
||||
### Implémenté (commit 8401f5456d, 28/04/2026)
|
||||
|
||||
- Entité `CST_StockStatus` : CstAtt 1 applicable en retour, CstAtt 2 =
|
||||
ZLOG, CstAtt 3 = ZINCO
|
||||
- Query `CST_StockStatus_AllowedForReturn` : filtre statuts autorisés
|
||||
- Workflow `CST_Return_Stock_GetStatus_UI` : sélection statut simplifié
|
||||
- Workflow `Reception_FilterLinesByProductAndContainer_UI_V1` : retrait
|
||||
filtre quantité (tolérance illimitée)
|
||||
- Dialog `CST_GetProductQuantity_Prompt` : option SelectStatus ajoutée
|
||||
|
||||
### Reste à développer
|
||||
|
||||
- Appel API SAP ATH214 + gestion token OAuth 2.0
|
||||
- Écran d'attente ITM (polling alias 5s, timeout 1 min, 5 tentatives)
|
||||
- Dialogue choix multi-lot (quand ET_BATCH contient plusieurs articles)
|
||||
- Impression étiquette stock retour client (rapport custom à créer)
|
||||
- Configuration flux de rejet PIE retours (verrou ECART RETOUR,
|
||||
destination, notification)
|
||||
|
||||
## Points d'attention
|
||||
|
||||
⚠️ Le paramètre `SAP_LOT_VERIFY_URL` doit pointer vers l'endpoint CPI
|
||||
unique `/http/ATHInboundMessage`, pas vers `/api/v1/lot/verify`.
|
||||
|
||||
⚠️ Le `MessageType` doit être `"ATH214"` dans l'enveloppe JSON.
|
||||
|
||||
⚠️ Pour les lots **déjà connus** en base WMS, le flag "déployé" n'est
|
||||
pas vérifié dans le design actuel — trou fonctionnel identifié (question
|
||||
A4 dans [Questions ouvertes](../08-transverse/questions-ouvertes.md)).
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- [ ] Champs manquants ET_BATCH : description article, pays destination,
|
||||
propriétaire (@Vincent Goyet) — A1
|
||||
- [ ] Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ?
|
||||
(@Vincent Goyet) — A2
|
||||
- [ ] Délai ATH214 → push ITM dimensionnement polling
|
||||
(@Vincent Goyet) — A3
|
||||
- [ ] Vérification "déployé" pour lots déjà connus sans ATH214
|
||||
(@Vincent Goyet) — A4
|
||||
- [ ] Étiquette stock retour : format, champs, imprimante
|
||||
(@Leila / @Antoine) — B1
|
||||
- [ ] Flux rejet PIE retour : destination, notification, actions
|
||||
(@Leila / @Antoine) — B2
|
||||
|
||||
## Historique des modifications
|
||||
|
||||
| Date | Auteur | Modification |
|
||||
|------|--------|-------------|
|
||||
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
||||
| 2026-05-05 | Arthur | Enrichissement depuis ateliers DEV réception |
|
||||
| 2026-05-12 | Arthur | Intégration LIM-72 (process complet 8 étapes, API SAP, CstAtt) |
|
||||
| 2026-05-12 | Arthur | Intégration LIM-73 (clôture retour, CstAtt11, REF conditionné) |
|
||||
| 2026-05-13 | Arthur | Correction API : endpoint CPI unique + ATH214, auth OAuth 2.0, mapping CHARG/MATNR, état dev, questions ouvertes |
|
||||
|
||||
## Références
|
||||
|
||||
| Source | Type | Date |
|
||||
|--------|------|------|
|
||||
| Jira LIM-72 | Ticket | 2025 |
|
||||
| Jira LIM-73 | Ticket | 2025 |
|
||||
| Jira LIM-14 | Ticket (CstAtt) | 2025 |
|
||||
| Athenzat SAP-CPI Webservices Documentation v1.0 | PDF | 2026-04-24 |
|
||||
| Mail Michael Chaudier ↔ Vincent Goyet | Échange | 2026-04-07/10 |
|
||||
| Mail Justine ↔ Leila ↔ Vincent Goyet ↔ Maxime Tourrette | Échange | 2026-04-24/29 |
|
||||
| recap_session_LIM-72_13-05-2026.md | Récap session | 2026-05-13 |
|
||||
Reference in New Issue
Block a user