mcp-wms-wiki/wiki/limagrain/01-inbound/reception-retour.md

title, tags, status, standard_ref, jira_refs, confluence_refs, sources, last_updated, author

title	tags	status	standard_ref	jira_refs	confluence_refs	sources	last_updated	author
Réception retour commandes clients	inbound réception retour client API lot	draft	concepts/reception.md	LIM-93 LIM-72 LIM-67 LIM-68 LIM-66 LIM-64 LIM-70 LIM-73 LIM-90		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 Jira LIM-93 (V2, préprod, revue de code en cours 2026-07-17) Jira LIM-73 (revue de code validée 2026-06-02, relecture 2026-07-17) Jira LIM-90 (revue de code terminée 2026-06-03) recap_session_LIM-72_13-05-2026.md	2026-07-17	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 Ce qui suit documente les spécificités Limagrain par rapport au standard.

⚠️ V1 annulé → V2 (LIM-93) intégré : le ticket LIM-72 « Flux complet PK V1 » est Annulé(e). Le traitement retour au PK est repris et livré par LIM-93 (V2, En cours de test client / préprod). Le contenu ci-dessous reflète la version définitive V2 (description + revue de code, relecture 2026-07-17). Différences majeures V2 vs V1 : appel ATH214 systématique (plus de branche « lot connu »), champ ZDEPLOY confirmé, nouveaux champs ET_BATCH, sélection du statut de stock en étape dédiée avant la quantité (statut fictif « Stock conforme »), étiquette = RFID LIM-68 enrichie (A5 Zebra, pas de rapport séparé), rejet PIE renvoyé au PK pour recomptage (placeholder, solution technique à définir).

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
2	Déplacement AGV → poste de travail	LIM-70
3	Traitement au poste de travail	LIM-72 (V1 annulé) → LIM-93 (V2)
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	-

Voir Réception fournisseur pour le détail du déchargement camion et des déclarations initiales (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 appelle systématiquement l'API SAP ATH214, que le lot soit déjà connu en base ou non.

Changement V2 (confirmation Vincent Goyet, 13/05) : l'appel ATH214 est désormais systématique. Il n'y a plus de branche « lot connu → pas d'appel ». La vérification « vendu par Limagrain » (flag ZDEPLOY) passe toujours par SAP. Cela ferme le trou fonctionnel A4 (lots connus non re-vérifiés).

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

flowchart TD
    A[Scan / saisie lot officiel] --> D[Appel API SAP ATH214<br/>SYSTÉMATIQUE<br/>IV_BATCH_OFF + IV_RETURN]
    D --> R{EV_RETURN = X ?}
    R -- Non --> Z[Erreur SAP<br/>afficher ET_RETURN]
    R -- Oui --> C{Au moins un<br/>ZDEPLOY = X ?}
    C -- Non --> K[Erreur : lot non vendu<br/>par Limagrain]
    C -- Oui --> B{Article déjà en base ?<br/>= alias existant ?}
    B -- Non --> E[SAP pousse l'ITM<br/>via ATH002/ITM01<br/>Écran attente refresh 5s / timeout 1 min]
    E --> F{Alias trouvé en base ?}
    F -- Non / Timeout --> G{Tentative < 5 ?}
    G -- Oui --> H[Bouton Réessayer]
    H --> D
    G -- Non --> I[Erreur finale :<br/>contacter responsable]
    F -- Oui --> J
    B -- Oui --> J{Plusieurs lots<br/>ZDEPLOY = X ?}
    J -- Non --> L[Sélection automatique<br/>→ déclaration contenu]
    J -- Oui --> M[Dialogue choix lot SAP<br/>Variété - Trt commercial - Destination code]
    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 pour le détail de l'architecture et de l'authentification OAuth 2.0.

Séquence d'échange :

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 :

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 :

{
  "EV_RETURN": "X",
  "ET_RETURN": [ { "TYPE": "...", "MESSAGE": "..." } ],
  "ET_BATCH": [
    {
      "MATNR": "000000000000020955",
      "CHARG": "2023293649",
      "BATCH_OFF": "F0964D002488",
      "DESCRIPTION": "Tournesol variété XYZ",
      "DESTINATION": "FR",
      "OWNER": "LFS",
      "ZDEPLOY": "X",
      "VAR_DESC": "LG50459 SX",
      "COM_TRT_DESC": "Korit"
    }
  ]
}

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[].DESCRIPTION	CHAR 40	Description article SAP
ET_BATCH[].DESTINATION	CHAR 18	Pays de destination
ET_BATCH[].OWNER	CHAR 10	Propriétaire Limagrain
ET_BATCH[].ZDEPLOY	CHAR 1	"X" = déployé/vendu, "" = non
ET_BATCH[].VAR_DESC	-	Variété (ajout Justine 08/07)
ET_BATCH[].COM_TRT_DESC	-	Traitement commercial (ajout Justine 08/07)

⚠️ 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).

Traitement de la réponse (V2) :

1. Si EV_RETURN = "" → afficher le message d'erreur de ET_RETURN à l'opérateur
2. Si EV_RETURN = "X" → filtrer ET_BATCH pour ne garder que les entrées avec ZDEPLOY = "X" (lots déployés/vendus)
3. Si aucune entrée ZDEPLOY = "X" → erreur « le lot n'a pas été vendu par Limagrain »
4. Sinon → vérifier l'existence des articles en base (voir écran d'attente ITM), puis sélection automatique ou dialogue multi-lot

É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 entrées avec ZDEPLOY = "X"), le dialogue CST_EtBatchSelector est affiché avec la liste des lots SAP disponibles. L'opérateur en choisit un.

Format d'affichage d'une ligne (revu Justine, 08/07) :

VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR)

soit Variété - Traitement commercial - Pays destination (product code). Ce format remplace l'affichage d'origine CHARG / BATCH_OFF / DESCRIPTION / DESTINATION / OWNER.

Si un seul résultat ZDEPLOY = "X" → sélection automatique, pas de dialogue.

Pourquoi le choix article ? Un lot officiel peut correspondre à plusieurs lots SAP (dépend notamment de la destination). L'opérateur doit choisir le lot 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-93)

Le traitement au PK reprend les mêmes étapes que le flux fournisseur (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 systématique (voir section ci-dessus)
4	Statut de stock	Étape dédiée AVANT la quantité (V2) - dialogue avec statut fictif « Stock conforme » en tête (voir ci-dessous)
5	Déclaration quantité	Identique - affichage qté attendue + UdM, prompt non pré-rempli. Bouton statut supprimé (ESC renvoie au dialogue statut)
5bis	Flag big-bag (bouton custom)	Identique (CstAtt02)
6	Attributs logistiques	Auto-validés si présents/uniques dans le ROR, sinon demandés (voir ci-dessous)
7	Flag "À anoxier"	Identique (CstAtt03 = true)
8	Programme de filmage	Identique (paramètre FILMAGES → CstAtt05)
9	Impression étiquette RFID	Enrichie - RFID LIM-68 + code produit / lots SAP / lot officiel, format A5 Zebra (voir ci-dessous)
10	Validation → évacuation AGV	Identique

Statut de stock - Modifiable, en étape dédiée (V2)

Contrairement au flux fournisseur (LIM-67) où le statut de stock est verrouillé (boutons masqués), dans le flux retour client l'opérateur peut choisir le statut. Le choix se fait désormais dans une étape dédiée, avant la saisie de la quantité (et non plus via un bouton sur l'écran quantité).

• Un dialogue liste les statuts autorisés en retour (query CST_StockStatus_AllowedForReturn, CstAtt1 = applicable en réception)
• En position 0 de la liste : un statut fictif « Stock conforme » qui, s'il est choisi, n'applique aucun statut (paramètre RECEPTION_CONFORM_STOCK_STATUS). Cela permet à « n'avoir aucun statut » d'être un vrai choix explicite (demande client 09/06)
• Le bouton « statut » de l'écran quantité est supprimé ; la touche ESC depuis l'écran quantité renvoie au dialogue des statuts
• Les écrans de date de fin de statut et commentaire suivent le comportement standard (non skippés contrairement au fournisseur)
• Un message d'avertissement s'affiche si « Stock conforme » est sélectionné pour une ligne qui ne demande pas de statut
• [CUSTOM] Statuts spécifiques retour : F9 (sacs sales), B6 (non conforme) - assignables uniquement dans ce processus. Catalogue complet des 8 statuts et remontée REF : voir Statuts de stock retour et remontée REF (LIM-90)

Attributs logistiques - Auto-validation (V2)

Les attributs logistiques (lot officiel, etc.) sont validés automatiquement s'ils sont renseignés dans le ROR et uniques pour l'article. Sinon :

• Un attribut manquant → demandé à l'opérateur
• Le ROR possède plusieurs lignes avec le même lot SAP mais des attributs logistiques différents → l'attribut est demandé (EasyWMS ne peut pas deviner à quelle ligne la réception se rattache)

Étiquette RFID enrichie (V2)

Il n'y a pas de rapport d'étiquette stock séparé. L'étiquette imprimée automatiquement après validation du filmage est l'étiquette HU/RFID de LIM-68, enrichie de champs supplémentaires. Elle est glissée entre les sacs de la palette.

Champs ajoutés (en plus du contenu standard LIM-68) :

• Code produit (MATNR / product code SAP)
• Lot SAP (CHARG / code article WMS)
• Lot officiel (BATCH_OFF / alias)

Format : A5 Zebra (pas A6). Imprimante : dédiée au PK.

Impact LIM-68 : la tâche LIM-68 devra intégrer ces champs supplémentaires et le format A5 Zebra.

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

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.

Différences pour les retours client :

• Verrou si écart poids : « ECART RETOUR » (vs « HORS TOLERANCE » pour les autres flux) - verrou posé sur le support (pas sur le stock)
• Action requise en cas d'écart : recomptage du nombre de sacs

Flux de rejet PIE (⚠️ placeholder V2 - solution technique à définir)

Changement V2 (confirmation Leila Chajjaoui, 13/05) : le client souhaite que les palettes retour rejetées au PIE (verrou ECART RETOUR) retournent au PK pour recomptage immédiat. L'approche V1 (poumon de rejet au sol + notification SmartUI) ne correspond pas au besoin et est abandonnée.

Points à résoudre avant implémentation :

• Routage AGV retour PIE → PK : comment EasyS gère-t-il le renvoi vers un PK ?
• Relance du workflow de déclaration sur la même palette : peut-on ré-ouvrir la palette au PK sans perdre les données déjà déclarées, ou faut-il repartir de zéro ?
• Gestion du verrou ECART RETOUR : levé automatiquement au retour au PK, ou levé manuellement par le responsable ?
• Impact sur la clôture : une palette en boucle PIE ↔ PK bloque-t-elle indéfiniment la clôture ?

Cette section sera complétée une fois la solution technique définie (question B2 dans Questions ouvertes).

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. 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 (WF Container_MovedEventHandler_Warehouse_PR, sur fin de tâche APS) :

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

[CUSTOM] Détection du mode retour (revue de code validée 2026-06-02)

Éléments techniques propres au flux retour issus de la revue de code LIM-73 (le socle clôture / tolérance est dans Réception fournisseur) :

Élément	Type	Rôle
CST_Reception_GetReceptionFromContainer	WF	Si aucune réception trouvée pour le conteneur, recherche un retour au code correspondant ; si trouvé → returnMode = true
Reception_Supplier_ChooseReception_UI	WF/UI	Ajout du paramètre formel CST_ReturnMode
WorkStation_Reception_Supplier_UI	WF/UI	Ajout de l'attribut CST_ReturnMode
WorkStation_Reception_Supplier_ConfirmReceivedStock_UI	WF/UI	Si retour → création du stock via une commande différente
CST_View_WaitForFullPutaway	Ressource	Libellé du statut « Clôture en cours » : FR « En attente de rangement [CST 1] », EN « Waiting for full putaway [CST 1] »

Statuts de stock retour et remontée REF (LIM-90)

Statut : préprod / test client. Revue de code terminée (03/06, après une première itération NOK 02/06 : commentaires // Custom manquants sur REF01.boo / REF01Observer.boo).

Custom du message REF + GNA pour remonter à SAP le statut de stock (codes SAP ZLOG/ZINCO) et le lot officiel lors des réceptions retour client. Réutilise la détermination retour/fournisseur de LIM-89 : les balises ZLOG/ZINCO ne sont posées que si la réception est de type retour.

Le STC étant désactivé (décision 30/04), le REF est le seul canal de remontée des statuts pour les retours.

Catalogue des 8 statuts (master data)

F2 (« Conforme sac propre ») = absence de statut dans le WMS : rien à créer. SAP interprète l'absence de statut comme F2 (ZLOG 0002 / ZINCO 0001).

Libellé statut WMS	ZLOG (CstAtt2)	ZINCO (CstAtt3)	Bloque picking	Bloque shipping
(F9) Conforme sac sale	0002	0091	Non	Non
(B6) Non conforme - Sacs ouverts	0001	0002	Oui	Oui
(B6) Non conforme - Lot de l'année précédente	0001	0003	Oui	Oui
(B6) Non conforme - Certificat absent	0001	0004	Oui	Oui
(B6) Non conforme - Anomalie couture	0001	0005	Oui	Oui
(B6) Non conforme - Article externe - Hors LMG	0001	0006	Oui	Oui
(B6) Non conforme - Article non prévu	0001	0007	Oui	Oui
(B6) Non conforme - Sac ouvert / endommagé	0001	0008	Oui	Oui

⚠️ Les blocages picking/shipping par statut sont à confirmer avec le client (proposition ci-dessus : F9 ne bloque rien, tous les B6 bloquent picking et shipping).

Balises REF ajoutées (par ligne de stock)

Balise	Contenu	Cas F2 (sans statut)
LneStockStatus	Libellé du statut (ex. « (B6) Non conforme - Sacs ouverts »)	vide
LneStockZLOG	Valeur CstAtt2 du statut	vide
LneStockZINCO	Valeur CstAtt3 du statut	vide
LneStockOfficialLot	Alias de l'article WMS = lot officiel SAP (1er alias dont la valeur diffère du code article), ajouté sous LneItemCode	vide/absent si pas d'alias

Implémentation GNA (revue de code)

Fichier	Rôle
REF01.boo	Ajout du header du message REF (nouvelles données)
REF01Observer.boo	Cœur : récupère l'alias selon le code produit ; récupère les CstAtt du statut de stock et les pose uniquement si la réception est de type retour
REF01.xsd	Structure du message REF avec les données custom

Entité CST_StockStatus (déjà cataloguée, CstAtt2 = ZLOG, CstAtt3 = ZINCO) : voir AD Customs.

Un REF non-retour (fournisseur / intersite) ne porte pas de ZLOG/ZINCO ; le lot officiel reste présent si l'article a un alias.

Prérequis : le REF retour est conditionné au rangement ASRS complet (LIM-73, CstAtt11).

[CUSTOM] Éléments techniques (LIM-93, revue de code)

Statut : LIM-93 « En cours de test client (préprod) ». Le socle statut de stock a une revue de code validée (26/06) ; la partie API ATH214 est en cours de revue (voir caveat plus bas).

Statut de stock - sélection en étape dédiée

Implémentation (commits 5b36a4c5a3 11/06, 55f8ced13f 12/06 ; revue de code validée 26/06) :

Élément	Type	Rôle
CST_StockStatus	Entité	CstAtt1 = applicable en réception, CstAtt2 = ZLOG, CstAtt3 = ZINCO
CST_StockStatus_AllowedForReturn	Query	Statuts sélectionnables en réception retour (CstAtt1)
CST_StockStatus_ForView	Query	Query de la vue StockStatusVList
StockStatusVList	Vue	Affichage des CstAtt 1, 2 et 3
CST_Return_Stock_GetStatus_UI	WF	Clone simplifié de Stock_GetStatus_UI pour le retour ; ajoute le statut fictif « Stock conforme » en tête (paramètre RECEPTION_CONFORM_STOCK_STATUS)
Reception_GetQuantityAndUom_UI	WF	Suppression du bouton de sélection de statut sur l'écran quantité
WorkStation_Reception_Supplier_UI	WF	Déplacement de la sélection du statut avant la quantité
Reception_FilterLinesByProductAndContainer_UI_V1	WF	Retrait du filtre qui exclut les lignes déjà réceptionnées → autorise la réception en excès (tolérance illimitée)
Reception_Supplier_CheckReceptionStatus_UI_V1	WF	Autorise la création de ligne pour les réceptions de type retour
CST_GetProductQuantity_Prompt	Dialog	Suppression de l'option de sélection de statut
RECEPTION_CONFORM_STOCK_STATUS	Paramètre	Nom du statut fictif « Stock conforme »

API ATH214 - vérification lot

Implémentation (commit d33037da72 25/05 ; champs VAR_DESC/COM_TRT_DESC fa5f2f863d 08/07 ; auto-validation attributs 02364f440f 07/07) :

Élément	Type	Rôle
CST_Reception_Return_ATH214_Request_UI	WF	Gère la requête ATH214 vers SAP CPI et renvoie la liste ET_BATCH
CST_Reception_Return_ATH214_CheckData_UI	WF	Process réception classe « Retour » : demande le code OE et la sélection du lot parmi ceux renvoyés par SAP
CST_Reception_Return_ATH214_CheckData_Product_UI	WF	Vérifie l'existence du produit en base et gère l'attente de l'ITM (ATH002)
CaptureProductLotAttributeForReception_UI	WF	Réutilise le lot sélectionné dans CST_Reception_Return_ATH214_CheckData_UI
GetReceptionProductByIA	WF	En classe « Retour », permet de sélectionner un article/alias qui n'existe pas encore
CST_EtBatch	Record	Modèle de données d'une entrée ET_BATCH (+ champs VarDesc, ComTrtDesc)
CST_EtBatchList	List	Liste de CST_EtBatch
CST_EtBatchSelector	Dialog	Sélecteur multi-lot (VAR_DESC - COM_TRT_DESC - DESTINATION (MATNR))
CST_Reception_Return_API_TimeoutOption	Dialog	Options en cas d'échec de communication selon le nombre de timeouts
CST_LogWebServiceCommunication	Toggle	Active le logging de la communication API ATH214

Ressources principales : CST_Reception_Return_API_SelectLot, ..._Error, ..._MultiLot, ..._NoDeployedLot, ..._Timeout, ..._TimeoutExceededTry_1, ..._WaitingResponse, CST_Reception_Return_Prompt_InboundOrderCode, CST_Reception_Return_API_LotSelectionColumnHeader.

⚠️ Caveat revue de code (Maxime Halgand 16/07 → Vincent Charvet 17/07) : sur CST_Reception_Return_ATH214_Request_UI, l'appel est lancé en tâche async (Task.Factory.StartNew) pour afficher les écrans sans attendre ; callResult est mis à jour dans la tâche. Le timeout vient du HttpClient (100 s par défaut, soit ~200 s max : token + data). Seul cas de boucle infinie résiduel : si LogManager.GetLogger lève une exception (hors try/catch), callResult n'est jamais mis à jour → à corriger avant validation.

Points d'attention

⚠️ Endpoint CPI unique /http/ATHInboundMessage avec MessageType = "ATH214" dans l'enveloppe JSON. Les paramètres V1 SAP_LOT_VERIFY_* sont remplacés par SAP_CPI_TOKEN_URL, SAP_CPI_ENDPOINT_URL, SAP_ATH214_TIMEOUT (60 s), SAP_ATH214_MAX_RETRIES (5), SAP_ATH214_REFRESH_INTERVAL (5000 ms) - voir Paramètres projet.

⚠️ La vérification « déployé » (ZDEPLOY) des lots déjà connus en base est désormais assurée par l'appel ATH214 systématique (V2). Le trou fonctionnel A4 est fermé.

Questions ouvertes

• Champs manquants ET_BATCH : description article, pays destination, propriétaire - A1 → Résolu : DESCRIPTION, DESTINATION, OWNER ajoutés, plus VAR_DESC (variété) et COM_TRT_DESC (traitement commercial)
• Nom final champ déploiement : EV_DEPLOY ou ZDEPLOY ? - A2 → Résolu : ZDEPLOY (confirmé V2)
• Délai ATH214 → push ITM dimensionnement polling - A3 → Résolu : polling 5000 ms, timeout 60 s, 5 tentatives (paramétrés)
• Vérification "déployé" pour lots déjà connus sans ATH214 - A4 → Résolu : appel ATH214 systématique
• Étiquette stock retour : format, champs, imprimante - B1 → Résolu : pas de rapport séparé, RFID LIM-68 enrichie (A5 Zebra, imprimante dédiée PK)
• Flux rejet PIE retour (B2) : le client veut un renvoi au PK pour recomptage (approche poumon abandonnée). Routage AGV PIE → PK, relance du workflow sur la même palette, levée du verrou ECART RETOUR, impact clôture - solution technique à définir (@Leila / @Antoine)

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
2026-07-17	Arthur	LIM-72 confirmé Annulé(e) (V1) → repris par LIM-93 (V2) : notes de supersession ajoutées (résumé, table process, état dev) ; contenu V1 conservé comme référence à valider. Détail définitif différé à la relecture de LIM-93
2026-07-17	Arthur	Relecture revue de code LIM-73 (validée 02/06, préprod) : sous-section « Détection du mode retour » (WF returnMode, Container_MovedEventHandler_Warehouse_PR pour CstAtt11, ressource CST_View_WaitForFullPutaway)
2026-07-17	Arthur	Intégration LIM-90 (revue de code terminée 03/06, préprod) : section « Statuts de stock retour et remontée REF » (catalogue 8 statuts ZLOG/ZINCO + blocage picking/shipping, F2 = absence de statut, balises LneStockStatus/LneStockZLOG/LneStockZINCO/LneStockOfficialLot, GNA REF01.boo/REF01Observer.boo/REF01.xsd, réutilise détermination retour LIM-89)
2026-07-17	Arthur	Intégration LIM-93 V2 (préprod, revue de code en cours) : appel ATH214 systématique (résout A4), champs ET_BATCH DESCRIPTION/DESTINATION/OWNER/ZDEPLOY/VAR_DESC/COM_TRT_DESC (résout A1/A2), dialogue multi-lot reformaté, statut de stock en étape dédiée + statut fictif « Stock conforme » (RECEPTION_CONFORM_STOCK_STATUS), auto-validation attributs logistiques, étiquette RFID enrichie A5 Zebra (résout B1, impact LIM-68), rejet PIE renvoi au PK placeholder (B2), section « Éléments techniques » (WF/dialogs/records ATH214 + caveat boucle infinie), verrou PIE renommé « ECART RETOUR »

Références

Source	Type	Date
LIM-72	Ticket Jira (V1, Annulé)	2026
LIM-93	Ticket Jira (V2 - description + revue de code, préprod)	2026-07-17
Commits LIM-93 : d33037da72 (API ATH214), 5b36a4c5a3 / 55f8ced13f (statut de stock), 02364f440f (auto-validation attributs), fa5f2f863d (VAR_DESC/COM_TRT_DESC)	Git	2026-05/07
LIM-73	Ticket Jira (clôture/REF retour) - revue de code validée, préprod	2026-06-02
LIM-90	Ticket Jira (statuts ZLOG/ZINCO + lot officiel) - revue de code terminée, préprod	2026-06-03
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