mcp-wms-wiki/wiki_old_13-05-2026/sources/archives/LIM-72 LOT1.3 [RETOUR] Flux complet PK.md

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

2. Déplacement AGV → Poste de travail : 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

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) 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). 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)
8	Validation → évacuation AGV	Identique

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

---

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