màj wiki avec retour MES lot-5 AD
This commit is contained in:
@@ -0,0 +1,314 @@
|
||||
---
|
||||
share_link: https://share.note.sx/uc935cyz#vOQlhfdMxOminHSh1eTDEwZPIjIqu+M5iViaJkJc6ks
|
||||
share_updated: 2026-04-30T14:32:15+02:00
|
||||
---
|
||||
# LOC — Spécification du message périodique (EasyWMS → SAP)
|
||||
|
||||
**Projet :** Athenza (Limagrain) — Interfaçage WMS/ERP
|
||||
**Dernière mise à jour :** 30/04/2026
|
||||
**Historique :** CR ateliers fév. 2026 + mails Nicolas Sanchez (24-25/02, 02/03) + réunion [[Réu LOC 30-04-2026]] (Arthur, Justine, Nicolas)
|
||||
|
||||
---
|
||||
## 1. Contexte et objectif
|
||||
|
||||
Le LOC est un **message custom** (non standard EasyWMS) envoyé du WMS vers SAP **toutes les 5 minutes** (✅ reconfirmé le 30/04), contenant l'état de toutes les HU (Handling Units) ayant subi une modification durant la période écoulée.
|
||||
|
||||
Il **remplace** les messages PCK et MOVE (supprimés du périmètre) et centralise la communication des mouvements physiques vers l'ERP. Le LOC ne transmet pas l'intégralité de la base, uniquement le **delta sur la fenêtre de 5 minutes** (basé sur la `CreationDate` des transactions WMS).
|
||||
|
||||
### Pourquoi le LOC plutôt que des STV purs ?
|
||||
|
||||
Nicolas Sanchez (Limagrain) a exprimé que les STV en delta (écarts +/-) ne sont **pas fiables** pour eux : si un message se perd ou est mal intégré, l'écart est définitivement perdu. Limagrain souhaite recevoir des **quantités absolues** (dernière valeur connue) que SAP prend pour argent comptant et compare lui-même à ses propres données pour générer les écritures de delta.
|
||||
|
||||
**Décision réunion 30/04 :** Les STV seront **désactivés** (post-processing coupé). Le LOC devient le **seul canal** de notification des mouvements de stock vers SAP. De même, les STC seront **désactivés** : les changements de statut hors retour sont limités au B6 (blocage logistique standard) et sont couverts par le LOC (action R/U). Les statuts des retours sont remontés dans le REF.
|
||||
|
||||
→ Vérifier les effets de bord de la désactivation STV et STC (cf. §6).
|
||||
|
||||
---
|
||||
|
||||
## 2. Couverture fonctionnelle
|
||||
|
||||
Le LOC doit couvrir les événements suivants sur les HU :
|
||||
|
||||
| Événement | Code ACTION | Description |
|
||||
| ---------------------- | ---------------- | --------------------------------------------------------------------- |
|
||||
| Déplacement | **B** | Changement de zone de stockage d'une HU |
|
||||
| Déblocage de statut | **U** | Déblocage qualité |
|
||||
| Blocage de statut | **R** | Blocage qualité (en dehors des retours : uniquement B6) |
|
||||
| Suppression / Scrap | **S** | HU supprimée ou sacs percés |
|
||||
| Transfert inter-HU | **T** | Transfert de stock d'une palette à une autre (découpage/regroupement) |
|
||||
| Correction de quantité | **C** | Ajustement de quantité/poids (ex. passage PIE) |
|
||||
| Assignation client | **⚠️ À définir** | Palette assignée à un OS et positionnée sur image de quai (cf. §4.7) |
|
||||
|
||||
### Palettes exclues du LOC
|
||||
|
||||
Le LOC **ne doit pas** prendre en compte les palettes liées à une **réception non fermée** (= réception dont le REF n'a pas encore été envoyé). Cela garantit que le WMS ne communique à SAP que les supports déjà connus via un REF préalable.
|
||||
|
||||
**Précision réunion 30/04 :** "Réception non fermée" signifie que toutes les palettes ont été traitées. Pour les réceptions normales, les palettes sont traitées mais pas forcément rangées. Pour les retours, les palettes doivent être traitées, vérifiées et rangées (car le REF retour déclenche la facturation).
|
||||
|
||||
---
|
||||
|
||||
## 3. Format JSON attendu par SAP
|
||||
|
||||
```json
|
||||
{
|
||||
"IV_LGNUM": "WL02",
|
||||
"IV_TREATMENT_ID": "<HORODATAGE_GENERATION_LOC>",
|
||||
"IT_CREATE": [
|
||||
{
|
||||
"MATNR": "<CODE_PRODUIT_SAP>",
|
||||
"BATCHID": "<LOT_SAP>",
|
||||
"ACTION": "<CODE_ACTION>",
|
||||
"ANFME": "<QUANTITE_OU_VIDE>",
|
||||
"ALTME": "<UDM_OU_VIDE>",
|
||||
"VLPLA": "<ZONE_STOCKAGE_ORIGINE>",
|
||||
"NLPLA": "<ZONE_STOCKAGE_DESTINATION>",
|
||||
"VLENR": "<CODE_SUPPORT_ORIGINE>",
|
||||
"NLENR": "<CODE_SUPPORT_DESTINATION>",
|
||||
"REASON": "<CODE_RAISON>",
|
||||
"SORCODE": "<CODE_ORDRE_SORTIE>"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> **Note :** Le champ `SORCODE` est un ajout proposé suite à la réunion du 30/04. Nom de champ à confirmer avec Limagrain (cf. §4.7).
|
||||
|
||||
### Mapping des champs
|
||||
|
||||
| Champ JSON | Source WMS | Description | Obligatoire |
|
||||
| ----------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------ |
|
||||
| `IV_LGNUM` | Constante | Toujours `"WL02"` (site/dépôt SAP) | Oui |
|
||||
| `IV_TREATMENT_ID` | Généré | Horodatage du moment de **génération du LOC** (pas de la transaction EasyWMS liée) | Oui |
|
||||
| `MATNR` | Stock → LotCode (attribut logistique) | Code produit SAP | Oui |
|
||||
| `BATCHID` | Stock → ItemCode | Code lot SAP (= code article WMS) | Oui |
|
||||
| `ACTION` | Déterminé par le type de mouvement | Code action (B/U/R/S/T/C + à définir pour client) | Oui |
|
||||
| `ANFME` | Stock → Quantity | Quantité en **unité alternative** (unité de base pour EasyWMS) (BAG ou KG). **Vide/auto-fermant si déplacement simple (ACTION=B)** | Selon action |
|
||||
| `ALTME` | Stock → UoM | Unité de mesure alternative (unité de base pour EasyWMS) (`KG` ou `BAG`). **Vide/auto-fermant si déplacement simple** | Selon action |
|
||||
| `VLPLA` | Zone de stockage WMS (source) | Zone de stockage d'origine | Oui |
|
||||
| `NLPLA` | Zone de stockage WMS (destination) | Zone de stockage de destination | Oui |
|
||||
| `VLENR` | Container → ContainerCode (source) | Code support (HU) d'origine | Oui |
|
||||
| `NLENR` | Container → ContainerCode (destination) | Code support (HU) de destination | Selon action |
|
||||
| `REASON` | Variable | Code motif — **uniquement sur ACTION=S** (cf. §4.3). Vide sinon. | Selon action |
|
||||
| `SORCODE` | OutboundOrder → Code | Code ordre de sortie (livraison) — **uniquement quand palette assignée client et sur image de quai** | Selon action |
|
||||
|
||||
### Précisions sur ANFME/ALTME (réunion 30/04)
|
||||
|
||||
L'unité transmise dans `ALTME` est l'**unité alternative SAP** (= unité logistique/de manutention), pas l'unité de base SAP (qui est le millier de grains). Concrètement pour le WMS, c'est simplement l'UdM du stock :
|
||||
|
||||
- **Sacs** : `ALTME = "BAG"`, `ANFME` = nombre de sacs
|
||||
- **Big bags (gérés en KG)** : `ALTME = "KG"`, `ANFME` = poids en KG
|
||||
- **Cas 2 big bags** : 1 BAG + 1 BAG (pas des KG additionnés), car chaque big bag = 1 unité de manutention
|
||||
|
||||
**Comportement par action :**
|
||||
|
||||
| ACTION | ANFME | ALTME | Comportement |
|
||||
| --------------- | ------------------------ | -------- | -------------------------------------------------------------------------- |
|
||||
| B (déplacement) | **Vide** | **Vide** | Pas de quantité — on déplace la HU entière, le contenu n'est pas rediscuté |
|
||||
| U/R (statut) | Quantité actuelle | UdM | Quantité absolue sur la HU |
|
||||
| S (suppression) | Quantité supprimée | UdM | Ex. 1 sac percé = suppression car stock benné |
|
||||
| T (transfert) | Quantité transférée | UdM | Quantité déplacée de HU source vers HU destination |
|
||||
| C (correction) | Quantité comptée/validée | UdM | Valeur absolue après contrôle |
|
||||
|
||||
---
|
||||
|
||||
## 4. Règles métier par type d'action
|
||||
|
||||
### 4.1 ACTION = B (Déplacement)
|
||||
|
||||
- Se déclenche lors d'un changement de zone de stockage.
|
||||
- `VLPLA` = zone d'origine, `NLPLA` = zone de destination.
|
||||
- `VLENR` = code HU.
|
||||
- **`ANFME` et `ALTME` sont vides / auto-fermants** (✅ confirmé le 30/04). La HU se déplace avec tout son contenu, on ne reprécise pas la quantité.
|
||||
- `MATNR` et `BATCHID` ne sont pas précisés non plus (auto-fermants), le contenu de la HU n'est pas rediscuté.
|
||||
|
||||
### 4.2 ACTION = U / R (Déblocage / Blocage statut)
|
||||
|
||||
- Se déclenche lors d'un changement de statut qualité.
|
||||
- `VLENR` = code HU concerné.
|
||||
|
||||
**Règles de statut (réunion 30/04) :**
|
||||
|
||||
- **Hors flux retour :** Le seul changement de statut autorisé est le **B6** (blocage logistique standard). Les opérateurs/gestionnaires ne peuvent pas appliquer d'autres statuts (F9, sacs sales, etc.) en dehors du flux retour. Le LOC envoie ACTION=R pour bloquer, ACTION=U pour débloquer.
|
||||
- **Flux retour :** Les statuts exotiques (B6, F2, F9, sac propre, sac sale, bloqué qualité Q4, etc.) sont gérés dans le **REF** de la réception retour, pas dans le LOC. Le LOC ne s'occupe que du B6 hors retour.
|
||||
- **Statut Q4 (blocage qualité)** : Personne ne doit y toucher, ni opérateurs ni gestionnaires. Seul le process qualité officiel peut le lever.
|
||||
|
||||
→ Les statuts retour sont remontés dans le REF via un attribut dédié (à ajouter dans le REF si pas déjà fait).
|
||||
|
||||
### 4.3 ACTION = S (Suppression / Scrap)
|
||||
|
||||
- **Cas sac percé** : `ANFME` = 1, `ALTME` = BAG, `REASON` = code motif spécifique (≠ ZSC1).
|
||||
- **Cas suppression palette** : `ANFME` = quantité supprimée.
|
||||
- **`REASON` (ZSC1) est utilisé uniquement avec ACTION=S** (✅ confirmé le 30/04). Pour les autres actions, le champ REASON est vide ou absent.
|
||||
|
||||
### 4.4 ACTION = T (Transfert inter-HU)
|
||||
|
||||
- **Découpage ou regroupement** de stock entre deux palettes.
|
||||
- `VLENR` = HU source, `NLENR` = HU destination.
|
||||
- `ANFME`/`ALTME` = quantité **transférée** (pas la quantité totale restante).
|
||||
- Un simple mouvement de mise à jour des deux HU séparément n'est **pas acceptable** pour Limagrain — il faut explicitement lier source et destination dans la même ligne.
|
||||
- **Il faut toujours une origine ET une destination** (emplacement matérialisé). Si le transfert passe par une table intermédiaire, soit on transmet toutes les étapes (HU→table, table→HU), soit on regroupe. Nicolas accepte les étapes intermédiaires à condition que chaque étape ait un code support et un emplacement.
|
||||
|
||||
**Cas du picking (réunion 30/04) :**
|
||||
|
||||
Lors d'un picking avec découpage (ex. 50 sacs → 20 + 30 sur deux palettes), le LOC envoie des lignes ACTION=T pour chaque mouvement. Si 5 tâches de picking alimentent la même palette fille, le LOC contient 5 lignes dans le même `IT_CREATE`, dans l'ordre chronologique. SAP traite les lignes dans l'ordre du fichier.
|
||||
|
||||
**Création de palette au picking :** La palette fille est une **nouvelle HU** créée à la volée au poste de travail. SAP ne la connaît pas encore. À réception du LOC avec un code SSCC inconnu en `NLENR`, SAP **crée automatiquement la palette** (support par défaut, type palette standard). Ce mécanisme remplace le besoin d'un flag "palette nouvelle" — c'est implicite : si le SSCC est inconnu de SAP, c'est une création (uniquement pour le LOC et hors flux réception)
|
||||
|
||||
> **Important :** Ce mécanisme ne crée que la palette (structure HU), pas du stock ex nihilo. Le stock est transféré (ACTION=T) depuis une palette source connue.
|
||||
|
||||
### 4.5 ACTION = C (Correction de quantité)
|
||||
|
||||
- Se déclenche après un contrôle (passage PIE, inventaire).
|
||||
- `ANFME` = **quantité comptée/validée** (valeur absolue, pas un écart).
|
||||
- `ALTME` = KG pour big bags, BAG pour sacs.
|
||||
- `VLENR` = numéro de la HU.
|
||||
- SAP calcule lui-même le delta entre la quantité LOC et celle qu'il a en stock.
|
||||
- **`REASON` n'est pas renseigné pour ACTION=C** (pas de ZSC1). Le PIE ne génère pas de motif.
|
||||
|
||||
**Exemples concrets :**
|
||||
|
||||
- Big bag passant au PIE : poids réel 980 au lieu de 990 → `ANFME: "980"`, `ALTME: "KG"`
|
||||
- Palette de sacs contrôlée : 72 sacs au lieu de 75 → `ANFME: "72"`, `ALTME: "BAG"`
|
||||
|
||||
### 4.6 Découpage sur quai (hors process nominal)
|
||||
|
||||
**Réunion 30/04 :** Le découpage sur le quai **n'est pas prévu** dans l'analyse fonctionnelle. Si une palette est assignée client, le WMS interdit les découpages dessus. Cependant, en situation d'urgence opérationnelle (AGV tous occupés, livraison client urgente), des manipulations manuelles peuvent arriver. Conséquences : le LOC pourrait être en erreur côté SAP car le mouvement concerne une palette client. Intervention manuelle nécessaire (cas par cas). On ne code pas de gestion spécifique pour l'instant — on traitera si le cas se présente en production.
|
||||
|
||||
### 4.7 Assignation client (palette sur image de quai)
|
||||
|
||||
**Réunion 30/04 — Besoin confirmé par Nicolas :** Limagrain veut savoir quand une palette est positionnée sur l'image de quai et assignée à une livraison. C'est le moment où la palette est physiquement sur l'image de quai (pas la réservation logique en amont).
|
||||
|
||||
**Informations attendues :**
|
||||
|
||||
- Un **code action** dédié (valeur à définir par Nicolas — pas encore dans la liste B/U/R/S/T/C)
|
||||
- Le **numéro de livraison** = `SorCode` (code ordre de sortie WMS) → à ajouter comme champ supplémentaire dans le JSON (nom de champ à confirmer par Nicolas/Olivier)
|
||||
|
||||
**Statut :** 🔴 Nicolas doit revenir avec la valeur du code action et le nom du champ pour le SorCode. Le format exact reste à préciser.
|
||||
|
||||
---
|
||||
|
||||
## 5. Zones de stockage (VLPLA / NLPLA)
|
||||
|
||||
### Principe (réunion 30/04)
|
||||
|
||||
Les valeurs `VLPLA` et `NLPLA` correspondent aux **zones de stockage WMS** (pas aux emplacements précis). Une table de correspondance côté Mecalux peut être nécessaire pour mapper les zones WMS vers les codes emplacement SAP.
|
||||
|
||||
### Zones identifiées
|
||||
|
||||
| Zone | Granularité | Nombre | Notes |
|
||||
| -------------------------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **ASRS / Transstockeurs** | 1 zone par TK | 5 | Aujourd'hui en préprod : 1 seule zone de stockage pour tous les TK, à découper (besoin aussi pour les stratégies de rangement) |
|
||||
| **Images de quai** | 1 par image de quai | 11 | Nicolas veut le numéro précis de l'image de quai (pas juste "image de quai" générique). |
|
||||
| **Postes de travail (PK)** | 1 par PK | | |
|
||||
| **Tables de travail** | À déterminer | À déterminer | Nicolas peut "faire son deuil" du détail table par table. Un code global "table" peut suffire si le SSCC de destination est renseigné. |
|
||||
| | | | |
|
||||
|
||||
### Prochaine étape
|
||||
|
||||
Mecalux produit la **liste exhaustive de toutes les zones de stockage** (VLPLA/NLPLA possibles) avec leur code. Nicolas valide cette liste.
|
||||
|
||||
---
|
||||
|
||||
## 6. Approche technique de développement
|
||||
|
||||
### Option retenue : WSC custom schedulé
|
||||
|
||||
Le LOC sera développé comme un **fork du WSC** (Warehouse Stock Count), adapté pour ne remonter que le delta des 5 dernières minutes. Le WSC standard est déclenché par la transaction `SCR.REQ` ou `STOCKSYNC.ASKED` et retourne un snapshot complet ; le LOC réutilisera le mécanisme de collecte mais appliquera un filtre temporel.
|
||||
|
||||
### Transactions WMS à surveiller pour alimenter le LOC
|
||||
|
||||
|Transaction WMS|Post-processed ?|Action LOC correspondante|Notes|
|
||||
|---|---|---|---|
|
||||
|`CON.MOVE`|Non|**B** (déplacement)|Mouvement de container sans tâche putaway|
|
||||
|`CON.LOCATE`|Non|**B** (déplacement)|Putaway en ASRS|
|
||||
|`STK.MOVE`|Non|**B** / **T**|Mouvement de stock — si ContainerTo ≠ ContainerCode → ACTION=T|
|
||||
|`STK.ADJ`|Oui → STV (**à désactiver**)|**C** (correction)|Ajustement quantité — STV sera désactivé|
|
||||
|`CST.STK`|Oui → STC (**à désactiver**)|**U** ou **R**|Changement statut qualité — STC sera désactivé|
|
||||
|`STK.PICKING`|Non|**T** (transfert)|Le picking déplace du stock d'une HU vers une autre|
|
||||
|`CON.DELETE`|Non|**S** (suppression)|Suppression de container|
|
||||
|`STK.SCR`|Non|**S** (scrap)|Scrap depuis RF|
|
||||
|
||||
> **Note :** `STK.MOVE` et `CON.MOVE` ne sont **pas** post-processed (pas de message ERP standard associé). C'est précisément pour cette raison que le LOC est nécessaire : il couvre un vide fonctionnel.
|
||||
|
||||
### Désactivation STV et STC (décision 30/04)
|
||||
|
||||
**STV : désactivé.** Le LOC couvre 100% des cas d'ajustement de stock. Vérifier qu'aucun autre process métier ne dépend du STV (ex. : middleware GNA, reporting). Le filtrage GNA des STV avec motif "STR" devient caduc si le STV est globalement désactivé.
|
||||
|
||||
**STC : désactivé.** Hors flux retour, le seul statut qui change est le B6, couvert par le LOC (R/U). Les statuts retour passent par le REF. Vérifier qu'aucun autre process ne dépend du STC.
|
||||
|
||||
→ **Action Mecalux :** Lister exhaustivement toutes les transactions qui génèrent un STV ou un STC et vérifier que le LOC couvre chaque cas. Documenter les éventuels effets de bord.
|
||||
|
||||
### Détection du delta
|
||||
|
||||
Le delta de 5 minutes se base sur la **CreationDate** des transactions pour détecter les mouvements :
|
||||
|
||||
1. À chaque exécution, enregistrer un timestamp de dernière exécution.
|
||||
2. À l'exécution suivante, récupérer toutes les transactions dont `CreationDate > dernier_timestamp` et `CreationDate ≤ timestamp_courant`.
|
||||
3. Agréger par HU, déterminer le code ACTION pour chaque mouvement.
|
||||
4. Générer le JSON et envoyer.
|
||||
|
||||
### Horodatage (IV_TREATMENT_ID)
|
||||
|
||||
**Décision réunion 30/04 :** L'horodatage dans `IV_TREATMENT_ID` est l'heure de **génération du LOC** (pas l'heure de chaque transaction individuelle). Si un LOC contient 50 mouvements, ils ont tous le même horodatage. SAP traite les lignes dans l'ordre du fichier (ordre chronologique des transactions). Nicolas valide que c'est plus simple pour eux.
|
||||
|
||||
→ Nicolas soumet le point à Olivier pour validation définitive, mais considère que c'est acceptable.
|
||||
|
||||
---
|
||||
|
||||
## 7. Retours clients — Compléments (réunion 30/04)
|
||||
|
||||
### Création de HU pour les retours
|
||||
|
||||
**Décision :** Pour les retours, toute palette entrante est **ré-étiquetée** avec un nouveau SSCC, même si elle avait déjà un SSCC connu. C'est une nouvelle palette systématiquement (palette standard). SAP n'a donc pas besoin de flag "palette nouvelle" pour les retours — le REF contient le nouveau SSCC, et SAP le crée à la volée.
|
||||
|
||||
### Données retour dans le REF
|
||||
|
||||
Le REF retour doit contenir (à vérifier/ajouter si absent) :
|
||||
|
||||
- **Lot officiel** (= alias WMS) — à renvoyer dans le REF
|
||||
- **Lot SAP** (= code article WMS / ItemCode)
|
||||
- **Statut de stock** (B6, F2, F9, sac propre, sac sale, etc.) — dans le REF, pas dans le LOC
|
||||
- **ZLOG et ZINCO** — à remonter dans le REF également
|
||||
|
||||
---
|
||||
|
||||
## 8. Synthèse des décisions validées
|
||||
|
||||
| # | Décision | Source | Statut |
|
||||
| --- | --------------------------------------------------------------------------------- | ---------------------------------- | ---------------------------------- |
|
||||
| 1 | Le LOC est un message delta (pas full stock) envoyé toutes les 5 min | CR consolidé §13, reconfirmé 30/04 | ✅ Validé |
|
||||
| 2 | Les quantités sont des valeurs **absolues** (pas des écarts) sauf pour ACTION=S | Mail Nicolas 25/02 | ✅ Validé |
|
||||
| 3 | Le LOC remplace PCK et MOVE | CR consolidé §17 | ✅ Validé |
|
||||
| 4 | Les palettes liées à des réceptions ouvertes sont exclues | CR §3 | ✅ Validé |
|
||||
| 5 | Sacs percés : ACTION=S, quantité=1, REASON spécifique | Mail Nicolas 02/03 | ✅ Validé |
|
||||
| 6 | Ajustements inventaire (PIE) : quantité comptée, pas en écart | Mail Nicolas 02/03 | ✅ Validé |
|
||||
| 7 | Transferts : VLENR + NLENR ensemble + quantité transférée | Mail Nicolas 25/02 | ✅ Validé |
|
||||
| 8 | REASON (ZSC1) **uniquement sur ACTION=S** | Réunion 30/04 | ✅ Validé |
|
||||
| 9 | Le LOC est un WSC custom (fork) avec delta temporel | Notes internes | ✅ Retenu |
|
||||
| 10 | **STV désactivé** — le LOC est le seul canal stock | Réunion 30/04 | ✅ Validé (vérifier effets de bord) |
|
||||
| 11 | **STC désactivé** — statuts hors retour = B6 uniquement via LOC | Réunion 30/04 | ✅ Validé (vérifier effets de bord) |
|
||||
| 12 | ACTION=B : **pas de quantité** (ANFME/ALTME vides, MATNR/BATCHID vides) | Réunion 30/04 | ✅ Validé |
|
||||
| 13 | Horodatage = heure de génération du LOC (pas heure transaction) | Réunion 30/04 | ✅ Validé (soumis à Olivier) |
|
||||
| 14 | Zones de stockage : 1/TK + image de quai précise + PK | Réunion 30/04 | ✅ Validé |
|
||||
| 15 | Retours : toujours nouvelle palette + ré-étiquetage SSCC | Réunion 30/04 | ✅ Validé |
|
||||
| 16 | Picking : création palette fille à la volée dans SAP (SSCC inconnu = création) | Réunion 30/04 | ✅ Validé |
|
||||
| 17 | Transferts inter-HU : toujours une origine + destination matérialisée | Réunion 30/04 | ✅ Validé |
|
||||
| 18 | Découpage palettes clients sur quai : non prévu, intervention manuelle si urgence | Réunion 30/04 | ✅ Validé |
|
||||
| 19 | Retour REF : renvoyer lot officiel + lot SAP + statut stock + ZLOG/ZINCO | Réunion 30/04 | ✅ Validé |
|
||||
| 20 | Statuts hors retour : uniquement B6. Q4 intouchable. | Réunion 30/04 | ✅ Validé |
|
||||
|
||||
---
|
||||
|
||||
## 9. Points ouverts
|
||||
|
||||
| # | Sujet | Responsable | Statut |
|
||||
| --- | -------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------ |
|
||||
| 1 | **Code action pour assignation client** : quelle valeur ? | Limagrain | 🔴 Ouvert |
|
||||
| 2 | **Champ JSON pour SorCode** : quel nom de champ pour le numéro de livraison ? | Limagrain | 🔴 Ouvert |
|
||||
| 3 | **Effets de bord désactivation STV** : lister toutes les transactions STK.ADJ et vérifier couverture LOC | Mecalux | 🔴 Ouvert |
|
||||
| 4 | **Effets de bord désactivation STC** : idem pour CST.STK | Mecalux | 🔴 Ouvert |
|
||||
| 5 | **Liste zones de stockage** : produire la liste exhaustive VLPLA/NLPLA | Mecalux | 🔴 Ouvert |
|
||||
| 6 | **Validation liste zones de stockage** par Nicolas | Limagrain | 🔴 En attente de #5 |
|
||||
| 7 | **Horodatage** : Nicolas soumet à Olivier la décision "heure de génération" | Limagrain | 🔴 Ouvert |
|
||||
| 8 | **Transferts via table intermédiaire** : définir la cinématique WMS (transactions, étapes) | Mecalux | 🔴 Ouvert |
|
||||
| 9 | **Validation template JSON final** (avec champs ajoutés) | Limagrain + Mecalux | 🔴 À faire après résolution #1 et #2 |
|
||||
Reference in New Issue
Block a user