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

màj wiki avec retour MES lot-5 AD

Browse Source
This commit is contained in:
Arthur Ria
2026-05-20 09:41:27 +02:00
commit 23eb3f3c84
4106 changed files with 469381 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/sources/archives/LIM-72 LOT1.3 [RETOUR] Flux complet PK.md
+295
View File
@@ -0,0 +1,295 @@
# Contexte
Le WMS dispose d'un flux dédié aux retours clients. Les palettes retournées suivent un process similaire au flux fournisseur/intersite ([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) : elles passent par un poste de travail (PK) pour identification et déclaration avant d'aller vers l'ASRS.
Les **différences majeures** par rapport au flux fournisseur/intersite sont :
- Le **statut de stock est modifiable** par l'opérateur (contrairement au fournisseur où il est verrouillé)
- La **tolérance est illimitée** : les articles non prévus dans le retour sont acceptés
- Un mécanisme de **vérification de lot via appel API SAP** est nécessaire pour les lots inconnus du WMS
- Le **verrou en cas d'écart de poids au PIE** est de type "ECART RETOUR" (au lieu de "HORS TOLERANCE")
Résumé du process complet de réception retour client :
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] ← cette tâche**
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
---
# Développement
Le traitement au PK reprend les mêmes étapes que le flux fournisseur ([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)) avec les adaptations décrites ci-dessous. Les étapes **identiques** au flux fournisseur sont indiquées comme telles.
### 1. Sélection de la réception
**Identique à LIM-67.** Affichage "Client: CODE - NOM" (au lieu de "Fournisseur: CODE - NOM") sur tous les écrans du process.
### 2. Big bag
**Identique à LIM-67.** Toggle BIG BAG ON/OFF → CstAtt02 du support.
### 3. Scan du lot officiel et vérification
C'est l'étape clé qui différencie le flux retour du flux fournisseur.
L'opérateur scanne le QR code du lot officiel sur le sac (ou saisie manuelle). Le WMS doit alors vérifier si le lot est connu.
#### Rappel : Structure des articles chez Limagrain
Chez Limagrain, le **code article WMS = lot SAP** (cf. [Données principales](https://easywmsfrance.atlassian.net/wiki/spaces/LIM/pages/3001429819394/Donn+es+principales)). 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 on dit "le lot est inconnu du WMS", cela signifie qu'**aucun article (ITM) n'existe dans le WMS avec ce lot officiel comme alias**. Il faut donc demander à SAP de nous envoyer la fiche article complète.
#### 3.1 Logique de vérification
`Scan / saisie du lot officiel (=Alias EasyWMS) │ ▼ Le lot officiel (=Alias EasyWMS) est-il connu du WMS ? (= existe-t-il un article Easy avec cet alias ?) │ ┌────┴────┐ ▼ ▼ OUI NON │ │ │ ▼ │ Appel API vers SAP depuis le workflow : │ "Je ne connais pas ce lot officiel (=Alias EasyWMS), │ envoie-moi la fiche article Easy" (voir 3.2) │ │ │ ▼ │ ATTENTE : le WMS attend que SAP lui │ pousse l'ITM via appel API direct (voir 3.3) │ │ │ ┌────┴────┐ │ ▼ ▼ │ ITM reçu Timeout / Erreur SAP │ │ │ │ │ ▼ │ │ Erreur : "Enregistrement impossible, │ │ le lot (SAP) n'existe pas" │ │ → Intervention manager │ │ │ ▼ │ L'article EasyWMS (=Lot SAP) existe │ maintenant dans le WMS │ │ ▼ ▼ Le lot SAP ou officiel?? (=Alias EasyWMS) a-t-il été vendu par Limagrain ? (info dans la réponse API) │ ┌────┴────┐ ▼ ▼ OUI NON │ │ │ ▼ │ Erreur : "Enregistrement impossible, │ le lot (SAP) n'a pas été vendu par Limagrain" │ → Intervention manager │ ▼ Le lot SAP ou officiel?? correspond à plusieurs articles SAP (=lot EasyWMS)? (plusieurs product codes pour ce lot) │ ┌────┴────┐ ▼ ▼ NON OUI │ │ │ ▼ │ Dialogue de choix de l'article (=lot EasyWMS) │ parmi les product codes disponibles │ (filtré par pays d'origine) │ │ ▼ ▼ OK → Continuer la déclaration du contenu`
#### 3.2 Appel API SAP — Vérification du lot officiel
Quand le lot officiel est inconnu du WMS, un appel API REST est fait **directement depuis le workflow** vers SAP. Cet appel sert à **notifier SAP** que le WMS a besoin de la fiche article associée à ce lot.
**Ce qui se passe ensuite** : SAP reçoit la demande, retrouve le lot dans sa base, et **appelle directement l'API du WMS** pour pousser l'ITM (fiche article complète). Le lot SAP devient le code article WMS, le lot officiel est stocké en alias.
> **Note** : Il n'y a pas de GNA dans cette boucle. Les appels sont directs : WMS → SAP (demande) puis SAP → WMS (ITM via API).
**Gestion du token :**
- Récupération d'un token avant chaque appel (ou utilisation d'une clé privée selon la config SAP)
**Payload de requête :**
`POST /api/v1/lot/verify { IV_LGNUM:"WF02", IV_MATNR: "000000000000020955", IV_CHARG: "2023293649", IV_BATCH_OFF:"F0964D002488", IV_RETURN:"0060004127" }`
IV_LGNUM : Toujours égal à WF02
IV_BATCH_OFF : Numéro de lot officiel (Cst)à vérifier
IV_RETURN : Code du retour client (ordre d’entrée)
Les autres champs restent vides.
**Payload de réponse :**
`{ "EV_RETURN" : "X" "ET_RETURN" : [ { "TYPE": "C", "ID": "DDDDDDDDDDDDDDDDDDDD", "NUMBER": "123", "MESSAGE": "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE", "LOG_NO": "FFFFFFFFFFFFFFFFFFFFF", "LOG_MSG_NO": "123456", "MESSAGE_V1": "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG", "MESSAGE_V2": "HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH", "MESSAGE_V3": "IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII", "MESSAGE_V4": "JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ", "PARAMETER": "KKKKKKKKKKKKKKKKKKKKKKKKKKKKKK", "ROW": "1234567890", "FIELD": "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM, "SYSTEM": "NNNNNNNNNN", }, { "TYPE": "C", "ID": "DDDDDDDDDDDDDDDDDDDD", "NUMBER": "123", "MESSAGE": "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE", "LOG_NO": "FFFFFFFFFFFFFFFFFFFFF", "LOG_MSG_NO": "123456", "MESSAGE_V1": "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG", "MESSAGE_V2": "HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH", "MESSAGE_V3": "IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII", "MESSAGE_V4": "JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ", "PARAMETER": "KKKKKKKKKKKKKKKKKKKKKKKKKKKKKK", "ROW": "1234567890", "FIELD": "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM, "SYSTEM": "NNNNNNNNNN", } ] "ET_BATCH" : [ { MATNR: "000000000000020955", CHARG: "2023293649", BATCH_OFF:"F0964D002488", EV_DEPLOY:"X" }, { MATNR: "000000000000020948", CHARG: "2023293632", BATCH_OFF:"F0964D002477", EV_DEPLOY:"" } }`
Si la valeur dans EV_RETURN = X alors le lot est bon, sinon le lot n’est pas valide.
Si celui-ci est bon alors on va récupérer les lots autorisés qui pourront être saisis par l’opérateur dans le ET_BATCH : Il faut récupérer tous les champs “BATCH_OFF” qui seront listé si le EV_DEPLOY est à “X”.
**Séquence complète de l'échange :**
`WMS (workflow) SAP │ │ │── POST /api/v1/lot/verify ──────────>│ │ { lotCode, siteCode } │ │ │ │<── Réponse JSON ───────────────────── │ │ (OK/NOK + infos lot) │ │ │ │ Si OK : │ │ │ │ SAP appelle l'API WMS ──────>│ │<── POST ApplicationService/ITM ──────│ │ (fiche article complète : │ │ lot SAP = code article, │ │ lot officiel = alias, │ │ CstAtt, conversions, etc.) │ │ │ │ Article disponible en base WMS │ │ │ │ Vérification : product code existe ? │ │ OUI → continuer │ │ NON → proposer de réessayer │`
#### 3.3 Écran d'attente pendant la réception de l'ITM
Après l'appel API, le WMS doit attendre que SAP lui pousse l'ITM via l'API. Pendant cette attente :
- **Écran d'attente** affiché à l'opérateur avec message "Vérification du lot en cours..."
- **Refresh automatique** toutes les 5 secondes : le WMS vérifie si l'article est apparu en base en vérifiant **si un Alias correspondant au lot officiel** existe en base.
- **Bouton "Réessayer"** visible à la fin du timeout (relance un nouvel appel API vers SAP)
- **Timeout** : 1 minute maximum par tentative
- **Nombre maximum de tentatives** : 5
**Ce que vérifie le refresh** : à chaque refresh (toutes les 5 secondes), le WMS regarde si un article avec le lot officiel scanné existe désormais dans la table des articles. Si oui → l'ITM est arrivé via l'API, on continue. Si non → on attend le prochain refresh.
Comportement en cas d'échec :
| | |
|---|---|
|Tentative|Action|
|1 à 4|Timeout (1 min sans que l'ITM arrive) → message "Erreur de communication avec SAP. Réessayer ?" + bouton Réessayer|
|5|Timeout → message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." + bouton "Annuler" qui revient à l'écran du scan du lot|
### 3.4 Choix du code lot (multi-résultat)
Si l’API a renvoyé plusieurs résultats dans le ET_BATCH, alors il faut afficher un dialog avec la liste des codes lots disponibles pour que l’opérateur en choisisse un dans la liste.
Si l’API a renvoyé un seul résultat alors on affiche par l'écran de sélection et on choisi automatiquement le bon code lot.
### 4. Déclaration du contenu
**Similaire à LIM-67** avec les adaptations suivantes :
| | | |
|---|---|---|
|Étape|Action|Différence vs fournisseur|
|1|Affichage du stock attendu (Article, Lot SAP, Lot officiel, Quantité)|Identique|
|2|Scan du QR code lot officiel (ou saisie manuelle)|**+ Vérification API SAP** (voir section 3)|
|3|Déclaration quantité|Affichage quantité attendue + UdM, prompt non pré-rempli (identique)|
|3 bis|Flag big-bag (bouton custom)|Identique (CstAtt02)|
|4|Statut de stock|**Modifiable** (boutons visibles, contrairement à LIM-67 où ils sont masqués)|
|5|Flag "À anoxier"|Identique (CstAtt03 = true)|
|6|Programme de filmage|Identique (paramètre FILMAGES → CstAtt05)|
|7|Impression étiquette RFID|Identique ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68))|
|8|Validation → évacuation AGV|Identique|
### 5. Statut de stock — Modifiable
Contrairement au flux fournisseur ([LIM-67](https://easywmsfrance.atlassian.net/browse/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)
---
## Paramètres
Les paramètres existants de LIM-67 sont réutilisés :
| | | | |
|---|---|---|---|
|Paramètre|Description|Valeur par défaut|Tâche d'origine|
|FILMAGES|Programmes de filmage (format clé;libellé séparés par \|)|0;Pas de filmage\|1;Programme 1\|2;Programme 2\|3;Programme 3|LIM-67|
Nouveaux paramètres :
| | | |
|---|---|---|
|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 de l'écran d'attente (en secondes)|5|
---
## Cas de tests
### 1. Sélection de la réception — Affichage client
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|1|Affichage CODE - NOM client sur l'écran de sélection|OE retour client existant avec code et nom client renseignés|Arriver sur l'écran de sélection de la réception|Le client s'affiche sous la forme "Client: CODE - NOM"|||
|2|Affichage CODE - NOM client sur tous les écrans du process|OE retour client avec code et nom renseignés|Dérouler le process complet|Le libellé "Client: CODE - NOM" est présent sur chaque écran du workflow|||
---
### 2. Big bag
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|3|État initial Big Bag = NON|Support en cours de paramétrage|Arriver sur l'écran de paramétrage du support|La ligne affiche "BIG BAG : NON" et le bouton "BIG BAG ON" est visible|||
|4|Activation Big Bag|Écran de paramétrage affiché, état initial NON|Cliquer sur "BIG BAG ON"|La ligne passe à "BIG BAG : OUI", le bouton devient "BIG BAG OFF", CstAtt02 = true|||
|5|Désactivation Big Bag après activation|Big Bag activé (OUI)|Cliquer sur "BIG BAG OFF"|La ligne repasse à "NON", CstAtt02 = false|||
---
### 3. Lot connu du WMS — Pas d'appel API
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|6|Lot connu du WMS → pas d'appel API|Un article existe dans le WMS avec le lot officiel scanné comme alias|Scanner le lot officiel|Pas d'appel API SAP, pas d'écran d'attente. Le process continue directement vers la déclaration du contenu|||
|7|Lot connu + vendu par Limagrain → OK|Lot connu, marqué comme vendu|Scanner le lot officiel|Le process continue normalement|||
|8|Lot connu + NON vendu par Limagrain → Erreur|Lot connu du WMS mais non vendu par Limagrain|Scanner le lot officiel|Message d'erreur : "Enregistrement impossible, le lot n'a pas été vendu par Limagrain". Intervention manager requise|||
---
### 4. Lot inconnu → Appel API SAP + réception ITM
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|9|Lot inconnu → appel API déclenché|Aucun article dans le WMS avec ce lot officiel comme alias|Scanner le lot officiel|Appel API SAP déclenché depuis le workflow. Écran d'attente "Vérification du lot en cours..." affiché|||
|10|API OK + ITM poussé par SAP + 1 article → process continue|SAP répond OK (1 article). SAP appelle l'API WMS pour pousser l'ITM. L'article apparaît en base|Scanner lot inconnu, attendre|Le refresh détecte que le product code existe en base → le process continue automatiquement, pas de dialogue de choix|||
|11|API OK + ITM poussés par SAP + plusieurs articles → dialogue|SAP répond OK (3 articles, pays différents). SAP pousse 3 ITM via l'API WMS|Scanner lot inconnu, attendre|Les 3 product codes sont détectés en base par le refresh. Dialogue de sélection affiché avec les 3 articles (code lot SAP, lot officiel, pays d'origine)|||
|12|API OK mais ITM pas encore reçu par le WMS → timeout + réessayer|SAP répond OK (1 article) mais l'ITM n'a pas encore été poussé : le product code n'apparaît pas en base|Scanner lot inconnu, attendre 1 minute|Timeout atteint (12 cycles de refresh sans trouver l'article en base) → message "Erreur de communication avec SAP. Réessayer ?"|||
|13|API OK + ITM arrive au bout de 30 secondes → succès|SAP répond OK. SAP pousse l'ITM via l'API WMS après 30 secondes|Scanner lot inconnu, attendre|Au 6ème cycle de refresh (~30s), le product code apparaît en base → le process continue automatiquement|||
|14|API NOK → lot n'existe pas dans SAP|SAP répond immédiatement avec LOT_NOT_FOUND|Scanner lot inconnu|Message d'erreur immédiat (pas d'attente ITM) : "Enregistrement impossible, le lot n'existe pas". Intervention manager|||
|15|API NOK → lot non vendu par Limagrain|SAP répond immédiatement avec LOT_NOT_SOLD|Scanner lot inconnu|Message d'erreur immédiat : "Enregistrement impossible, le lot n'a pas été vendu par Limagrain". Intervention manager|||
---
### 5. Écran d'attente — Timeout et réessais
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|16|Écran d'attente avec refresh toutes les 5 secondes|Appel API envoyé, en attente que SAP pousse l'ITM|Observer l'écran|Message "Vérification du lot en cours..." visible. Le WMS vérifie en base si le product code est apparu toutes les 5 secondes|||
|17|Bouton Réessayer visible pendant l'attente|Appel API envoyé, en attente|Observer l'écran|Le bouton "Réessayer" est visible et cliquable (relance un nouvel appel API vers SAP)|||
|18|Timeout 1ère tentative → message + Réessayer|ITM non reçu via l'API après 60 secondes (12 refresh sans résultat)|Attendre le timeout|Message "Erreur de communication avec SAP. Réessayer ?" avec bouton Réessayer|||
|19|Clic Réessayer → nouvel appel API|Timeout atteint, tentative 1/5|Cliquer sur "Réessayer"|Nouvel appel API lancé vers SAP depuis le workflow, écran d'attente réaffiché, compteur de tentatives incrémenté|||
|20|ITM arrive après 2 échecs → succès au 3ème essai|2 tentatives en timeout, 3ème appel → SAP pousse l'ITM via API → article en base|Cliquer Réessayer 2 fois|Au 3ème essai, le refresh détecte le product code en base → process continue|||
|21|5ème tentative échouée → message final|4 tentatives en timeout, 5ème sans résultat|Attendre le 5ème timeout|Message final "Impossible de contacter SAP après 5 tentatives. Veuillez contacter votre responsable." Seul le bouton Annuler est visible|||
|22|Bouton Annuler après 5 échecs → retour au scan lot|5 tentatives échouées, message final affiché|Cliquer sur "Annuler"|Retour à l'écran de scan du lot officiel. L'opérateur peut scanner un autre lot ou appeler un manager|||
|23|ITM reçu très vite (< 5s) → pas d'attente prolongée|SAP pousse l'ITM via API immédiatement, article en base en < 5s|Scanner lot inconnu|Au premier cycle de refresh (~5s), le product code est détecté en base → le process continue|||
---
### 6. Choix de l'article (multi-résultat) et vérification product code en base
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|24|1 article + product code existe en base → pas de dialogue|SAP renvoie 1 article et pousse l'ITM, product code en base|Attendre la réception de l'ITM|Pas de dialogue de choix. L'article est automatiquement sélectionné, le process continue|||
|25|Plusieurs articles + tous les product codes en base → dialogue|SAP renvoie 3 articles et pousse 3 ITM, les 3 product codes en base|Attendre la réception des ITM|Dialogue affiché avec 3 lignes : Code lot SAP, Lot officiel, Pays d'origine|||
|26|Sélection d'un article dans la liste|Dialogue de choix affiché avec 3 articles|Sélectionner le 2ème article|Le stock est créé avec le product code sélectionné, le process continue|||
|27|Annulation du dialogue de choix|Dialogue de choix affiché|Cliquer Annuler / Retour|Retour au scan du lot officiel, pas de stock créé|||
|28|Plusieurs articles mais 1 product code manquant en base → réessayer|SAP renvoie 2 articles. 1 ITM reçu (product code en base), 1 ITM pas encore poussé par SAP|Attendre|Le WMS détecte que 1 des 2 product codes est absent de la base → propose de réessayer l'appel API|||
|29|1 article mais product code absent en base → réessayer|SAP renvoie 1 article OK, mais l'ITM n'est pas encore poussé par SAP|Attendre|Le WMS détecte que le product code n'existe pas en base → propose de réessayer|||
---
### 7. Statut de stock — Modifiable
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|30|Boutons de modification visibles en retour client|Flux retour client, écran statut de stock|Arriver sur l'écran du statut de stock|Les boutons de changement de statut sont **visibles** et fonctionnels (contrairement au flux fournisseur LIM-67 où ils sont masqués)|||
|31|Modification du statut de stock|Flux retour, statut initial "Conforme"|Cliquer sur un bouton statut (ex : "Sac sale")|Le statut de stock est modifié en base|||
|32|Écran date de fin de statut affiché|Flux retour, statut modifié|Valider le changement de statut|L'écran de saisie de date de fin de statut s'affiche (contrairement au fournisseur où il est skippé)|||
|33|Écran commentaire statut affiché|Flux retour, date saisie ou skippée|Valider la date|L'écran de commentaire s'affiche (contrairement au fournisseur où il est skippé)|||
|34|Pas de modification → statut conservé|Flux retour, boutons visibles|Ne pas modifier le statut, valider directement|Le statut initial est conservé en base|||
---
### 8. Anoxie, filmage et étiquette RFID
| | | | | | | |
|---|---|---|---|---|---|---|
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|35|CstAtt03 = true après validation (anoxie)|Support traité via flux retour|Compléter le process|CstAtt03 du support = true en base|||
|36|Dialogue filmage affiché après prompt code support|Paramètre FILMAGES renseigné|Valider le prompt code support|Le dialogue de sélection du programme de filmage s'affiche|||
|37|Sélection filmage → CstAtt05 enregistré|Process en cours|Sélectionner "Programme 2"|CstAtt05 du support = 2 en base|||
|38|Impression étiquette RFID auto après filmage|Process retour client, imprimante disponible|Valider le choix de filmage|L'étiquette RFID ([LIM-68](https://easywmsfrance.atlassian.net/browse/LIM-68)) s'imprime automatiquement|||
---
### 9. Tolérance illimitée
| | | | | | | |
| --- | ------------------------------------------ | ------------------------------------------------------------------------ | -------------------- | --------------------------------------------------------------------------------- | --- | --- |
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
| 39 | Article non prévu dans le retour → accepté | OE retour avec lignes A et B. L'opérateur déclare un article C non prévu | Déclarer l'article C | L'article C est accepté (création de ligne non prévue autorisée en retour client) | | |
| 40 | Quantité supérieure au prévu → acceptée | Ligne OE prévoit 50 sacs. L'opérateur déclare 80 | Saisir quantité 80 | La quantité 80 est acceptée (tolérance illimitée) | | |
| 41 | Quantité inférieure au prévu → acceptée | Ligne OE prévoit 50 sacs. L'opérateur déclare 30 | Saisir quantité 30 | La quantité 30 est acceptée. La réception sera fermée manuellement | | |