màj wiki avec retour MES lot-5 AD
This commit is contained in:
Arthur Ria
@@ -0,0 +1,98 @@
|
||||
# Stratégies de rangement - fonctionnement
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000092590103)
|
||||
> Dernière mise à jour : 05/11/2024 (v3)
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Les stratégies de stockage permettent de définir des règles de rangement suivant les propriétaires ou les types d'articles. Elles sont accessibles via **Configuration → Stratégies de stockage**.
|
||||
|
||||
---
|
||||
|
||||
## Fonctionnement
|
||||
|
||||
### Principe de priorité
|
||||
|
||||
Le WMS parcourt les stratégies une par une jusqu'à trouver celle qui correspond au stock à ranger. Plusieurs stratégies peuvent exister pour un même type d'article — elles sont départagées par leur **numéro de séquence** : plus ce numéro est bas, plus la stratégie est prioritaire.
|
||||
|
||||
La stratégie de **dernière séquence** doit être applicable à tous les articles (emplacement disponible quelconque) pour éviter qu'aucune proposition ne soit faite à l'opérateur.
|
||||
|
||||
Les boutons **"Augmenter séquence"** et **"Diminuer séquence"** permettent d'ajuster les priorités.
|
||||
|
||||
### Créer une nouvelle stratégie
|
||||
|
||||
Cliquer sur **"Nouveau"**. Deux onglets sont disponibles :
|
||||
- **Critères** : définit si le stock à ranger peut utiliser cette stratégie
|
||||
- **Règles** : définit comment rechercher les emplacements disponibles
|
||||
|
||||
#### Onglet Critères
|
||||
|
||||
Définir un **nom** (et éventuellement une description). Le champ **"Rechercher un emplacement pour"** propose :
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| Conteneur client | Stratégies pour ranger un conteneur d'expédition |
|
||||
| Conteneur vide | Stratégies de rangement des conteneurs vides |
|
||||
| Profil de stockage | Applicable uniquement aux articles ayant le profil indiqué *(attention : si un article a un profil de stockage, seules les stratégies avec ce profil sont utilisables)* |
|
||||
| Conteneur ou stock | Pour du stock libre ou des conteneurs |
|
||||
|
||||
**Stock libre** : si coché, la stratégie s'applique uniquement au stock libre (pas aux conteneurs).
|
||||
|
||||
Dans la section **Stock**, il est possible de filtrer par : statut de stock, fournisseur, rotation ABC, type d'article, propriétaire, codes danger.
|
||||
|
||||
> La partie **Station d'origine** est nécessaire pour les installations avec robotique.
|
||||
|
||||
#### Onglet Règles
|
||||
|
||||
**Zone "Rechercher un emplacement"**
|
||||
|
||||
| Paramètre | Description |
|
||||
|-----------|-------------|
|
||||
| **Mode de stockage** | N'importe quel / Conteneur uniquement / Stock Libre uniquement |
|
||||
| **Valable si** | Emplacement vide ou avec stock / Avec stock uniquement / Canal vide uniquement / Canal avec stock uniquement |
|
||||
| Type de rayonnage | Pour les emplacements gérés par position |
|
||||
| Emplacement | Force le rangement sur un emplacement précis |
|
||||
| Coordonnée X / Y | Filtre par coordonnée |
|
||||
| Côté | 0 = gauche, 1 = droite |
|
||||
| Hauteur min/max | Filtre par hauteur d'emplacement |
|
||||
| Poids max | Filtre par poids maximum autorisé |
|
||||
| **Article assigné** | Recherche les emplacements associés à l'article (picking dédié) |
|
||||
| Type / Allée | Filtre par type de rack ou allée |
|
||||
| Zone | Limite la zone de stockage |
|
||||
| Température min/max | Filtre par plage de température |
|
||||
| Entrepôt annexe | Recherche dans un sous-entrepôt spécifique |
|
||||
|
||||
> Les emplacements de CrossDocking sont rattachés au sous-entrepôt de crossdocking. Si ce champ n'est pas renseigné, le WMS prend en compte les deux sous-entrepôts.
|
||||
|
||||
**Zone "Appliquer restrictions"**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| Appliquer restrictions | Utilise les restrictions définies dans Configuration → Restrictions de rangement |
|
||||
| Articles combinés | Cherche un emplacement avec articles compatibles au mélange |
|
||||
| Mélanger des conversions | Autorise le mélange de conversions différentes |
|
||||
| Combiner attributs logistiques | Autorise le mélange d'attributs logistiques |
|
||||
| Utiliser jours de mélange | Utilise les jours de mélange du profil logistique |
|
||||
| Mélanger types de conteneurs | Autorise les types de conteneurs différents |
|
||||
| Rangement partiel de stock | Autorise un rangement même si tout le stock ne rentre pas |
|
||||
|
||||
**Zone "Order locations"**
|
||||
|
||||
Permet d'ordonner les emplacements restants. Ordre par défaut recommandé : Coord X ASC (séquence 1), Coord Y ASC (séquence 2).
|
||||
|
||||
Options disponibles : Coord X/Y ASC/DESC, Distance ASC/DESC, Type conteneur identique, Stock article identique, Positions libres ASC/DESC, Profondeur ASC/DESC, Hauteur ASC/DESC, Distance emplacement article, Side ASC/DESC, Volume max/DESC.
|
||||
|
||||
---
|
||||
|
||||
## Fin de la stratégie
|
||||
|
||||
Sauvegarder puis **activer** la stratégie. Pour ne plus l'utiliser, la **désactiver**.
|
||||
|
||||
## Modifier une stratégie existante
|
||||
|
||||
1. Aller dans **Configuration → Stratégies de stockage**
|
||||
2. **Désactiver** la stratégie à modifier
|
||||
3. La sélectionner et cliquer sur **"Éditer"**
|
||||
4. Modifier, **sauvegarder** puis **réactiver**
|
||||
@@ -0,0 +1,27 @@
|
||||
# Stratégie d'assignation de stock : Vidage de bacs
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000049401857)
|
||||
> Dernière mise à jour : 25/05/2022 (v5)
|
||||
|
||||
---
|
||||
|
||||
## Paramétrage
|
||||
|
||||
Menu → **Configuration → Stratégies d'Assignation de Stock**
|
||||
|
||||
- **Mode d'efficacité** : Vidage de bacs
|
||||
- **Logique d'efficacité** : Après l'efficacité
|
||||
|
||||
---
|
||||
|
||||
## Workflows
|
||||
|
||||
**`StockAssignProcess_CalculateOutboundLogicAndEfficiency_PR`** : Choisit entre la logique et l'efficacité.
|
||||
|
||||
**`StockAssignProcess_CalculateEfficiencyMode_PR`** : Exécute le workflow du mode d'efficacité choisi.
|
||||
|
||||
**`StockAssignProcess_CalculateEfficiencyModeToEmpty_PR`** : Ordonne la liste des stocks disponibles pour le picking par ordre de priorité à vider selon les paramètres de la configuration. Les stocks sont ensuite sélectionnés un par un jusqu'à atteindre la quantité totale à assigner.
|
||||
|
||||
L'ordonnancement des stocks est réalisé dans l'activité de code **"Order stock when none location is emptied"**.
|
||||
|
||||
> *(Work in progress — analyse des 200 lignes d'orderby de l'activité en cours)*
|
||||
@@ -0,0 +1,54 @@
|
||||
# Réapprovisionnement lors du picking
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000048582679)
|
||||
> Dernière mise à jour : 21/06/2024 (v10)
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
Dans le fonctionnement standard du WMS, lorsqu'un ordre de sortie est libéré et qu'aucun emplacement de picking ne contient de stock (mais qu'il en existe en source de réapprovisionnement), une tâche de picking est créée sur un emplacement de picking vide. Ces tâches sont **automatiquement ignorées** par défaut lorsqu'un opérateur réalise un ordre de sortie et que l'emplacement est toujours vide.
|
||||
|
||||
Il existe **3 paramètres globaux** permettant de modifier ce comportement :
|
||||
|
||||
---
|
||||
|
||||
## PICKING_ALLOW_WAITING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT
|
||||
|
||||
Permet à l'opérateur de **prendre lui-même la décision** : effectuer le réapprovisionnement lui-même, ajuster le stock, ou ignorer.
|
||||
|
||||
Lorsque l'opérateur veut préparer l'ordre, il est averti du message **"Possible wait for replenish"**. Si l'emplacement de picking est vide à son arrivée, il peut choisir l'action à effectuer.
|
||||
|
||||
**Workflows concernés :**
|
||||
- `ExecutePicking_WaitForReplenishment_UI`
|
||||
|
||||
---
|
||||
|
||||
## PICKING_ALLOW_STARTING_DECISION_ON_WAIT_FOR_REPLENISHMENT
|
||||
|
||||
Permet à l'opérateur de **refuser un ordre de sortie** lui étant attribué s'il contient une ou plusieurs tâches en attente de réapprovisionnement (menu Tâches → Tâches de Picking).
|
||||
|
||||
**Workflows concernés :**
|
||||
- `Outbound_ObtainPickingTask_ExecuteTask_UI_v1` → récupère le booléen `waitForReplenishment` via `ExecutePicking_IncreaseReplenishPriorityAndGetIfCanDoTask_PR`
|
||||
- `Helper_ParameterAsBoolean_PR` → retourne la valeur booléenne du paramètre
|
||||
- `Outbound_ObtainPickingTask_ConfirmWaitForReplenish_UI` → affiche l'écran de confirmation si le paramètre est à `true`
|
||||
|
||||
---
|
||||
|
||||
## PICKING_ALLOW_UNLOADING_ON_LOCATION_ON_WAIT_FOR_REPLENISHMENT
|
||||
|
||||
Permet à l'opérateur de **stocker un conteneur client** plutôt que d'aller le déposer à la destination s'il reste des tâches de picking en attente de réappro.
|
||||
|
||||
**Workflow concerné :** `Expedition_FinishExpedition_GetShowStoreButton_PR` → récupère la valeur du paramètre et vérifie si le conteneur est plein et s'il reste des tâches de picking.
|
||||
|
||||
**Déroulé opérateur :**
|
||||
1. Après avoir effectué toutes les tâches possibles sans réapprovisionnement, cliquer sur **Finir** (`ExecutePicking_SelectOriginLocation_UI`)
|
||||
2. L'écran de dépose apparaît (`Expedition_FinishExpedition_ShowLocationToUnload_UI`)
|
||||
3. Cliquer sur **Stocker** (`Equipment_Unload_ContainerUnloadOnUnknownLocation_UI_V2`)
|
||||
4. Lors de la reprise ultérieure de la commande, possibilité de réutiliser un conteneur client (`Outbound_SelectContainerToCreate_UI`)
|
||||
|
||||
---
|
||||
|
||||
## Stratégies de réapprovisionnement
|
||||
|
||||
Voir la page dédiée : [Stratégies de réapprovisionnement](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000181358593)
|
||||
@@ -0,0 +1,81 @@
|
||||
# Gestion Pré emballage / Précolisage
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000054841396)
|
||||
> Dernière mise à jour : 29/04/2022 (v3)
|
||||
|
||||
---
|
||||
|
||||
## Généralités
|
||||
|
||||
La fonction de préemballage calcule le nombre de conteneurs/colis clients nécessaires à l'expédition d'une commande afin d'optimiser l'utilisation des ressources.
|
||||
|
||||
Deux vues sont associées :
|
||||
- **Configuration → Stratégie de préemballage** : paramétrage
|
||||
- **Ordre de sortie → Lignes de pré emballage** : visualisation des conteneurs créés par commande
|
||||
|
||||
---
|
||||
|
||||
## Paramétrage d'une stratégie de préemballage
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| **Code** | Nom de la stratégie |
|
||||
| **Type de commande** | Fusion / Ordre de départ sans envoi / Vague |
|
||||
| **Processus** | Emballage / Préparation |
|
||||
| **Type de précolisage** | Calculé par EasyWMS / Calculé par l'opérateur |
|
||||
| **Mode de travail** | Strict (l'opérateur ne peut rien changer) / Pas strict (l'opérateur peut changer) |
|
||||
| **Logique de pré emballage** | **Nombre minimum de colis** : prend le plus grand conteneur possible pour minimiser le nombre de colis. **Volume minimum** : prend le plus petit conteneur possible |
|
||||
|
||||
> ⚠️ Bien **activer la stratégie** après configuration.
|
||||
|
||||
L'**association des types de conteneurs** se fait depuis EasyS (conteneurs déjà créés ou nouveaux).
|
||||
|
||||
---
|
||||
|
||||
## Configuration requise (calcul par EasyWMS)
|
||||
|
||||
- Les **types de conteneurs** doivent être configurés dans EasyS (les associer aux équipements)
|
||||
- Les **dimensions et poids** des articles doivent être renseignés dans les conversions
|
||||
- Les **restrictions de mélange** des articles doivent être définies (fiche article / famille / type)
|
||||
|
||||
---
|
||||
|
||||
## Cas d'utilisation testés
|
||||
|
||||
| Cas | Résultat |
|
||||
|-----|----------|
|
||||
| Ordre de départ / Strict / Nombre minimum / poids normal | 1 conteneur Carton L |
|
||||
| Ordre de départ / Strict / Nombre minimum / poids > seuil | Carton L car Poids < 20 kg |
|
||||
| Ordre de départ / Strict / Nombre minimum / famille non mélangeable | Articles dans colis différents ✅ |
|
||||
| Ordre de départ / Strict / Nombre minimum / type non mélangeable | ❌ NON FONCTIONNEL (articles mélangés) |
|
||||
| Ordre de départ / Strict / Volume minimum | 3 conteneurs différents |
|
||||
| Vague / Strict / Volume minimum | Calcul par commande |
|
||||
| **Calcul par l'opérateur** | ❌ NE FONCTIONNE PAS |
|
||||
|
||||
---
|
||||
|
||||
## Calcul par l'ERP (fichier SOR02)
|
||||
|
||||
Balises de précolisage dans `SOR02` :
|
||||
|
||||
```xml
|
||||
<PrepackagingConfiguration>
|
||||
<Operation>S</Operation>
|
||||
<PrepackagingProcess>Picking</PrepackagingProcess>
|
||||
<PrepackagingWorkingMode>Strict</PrepackagingWorkingMode>
|
||||
<PrepackagingContainers transactional="true" complete="false">
|
||||
<PrepackagingContainer>
|
||||
<Operation>S</Operation>
|
||||
<PrepOrderContainer>0203214687</PrepOrderContainer>
|
||||
<PrepContainerType>CartonS</PrepContainerType>
|
||||
<PrepackagingLines>
|
||||
<PrepackagingLine>
|
||||
<Operation>S</Operation>
|
||||
<OrderLineNumber>1</OrderLineNumber>
|
||||
<Quantity>2</Quantity>
|
||||
</PrepackagingLine>
|
||||
</PrepackagingLines>
|
||||
</PrepackagingContainer>
|
||||
</PrepackagingContainers>
|
||||
</PrepackagingConfiguration>
|
||||
```
|
||||
@@ -0,0 +1,46 @@
|
||||
# Gestion Picking dédié / Management Picking Dedicated
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000053334066)
|
||||
> Dernière mise à jour : 27/04/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
## Généralités
|
||||
|
||||
Les emplacements de prélèvement peuvent être divisés en tiroirs, chaque tiroir étant étiqueté et affecté à un article particulier. Ces **"locations de picking dédiées"** se gèrent dans l'interface web.
|
||||
|
||||
---
|
||||
|
||||
## Configuration nécessaire
|
||||
|
||||
### Dans EasyS / Emplacement
|
||||
|
||||
Cocher :
|
||||
- **Allow product location**
|
||||
- **Allow replenish at source**
|
||||
- **Allow picking**
|
||||
|
||||
### Dans SmartUI
|
||||
|
||||
Menu **Entrepôt / Emplacements consacrés au picking** :
|
||||
|
||||
- Renseigner le **niveau de réapprovisionnement** (seuil min)
|
||||
- Renseigner la **capacité max**
|
||||
- Cocher **Étiquetté** (obligatoire)
|
||||
- Renseigner un **Texte personnalisé**
|
||||
- Imprimer les codes-barres des pickings dédiés
|
||||
|
||||
---
|
||||
|
||||
## Résultats de tests (27/04/22)
|
||||
|
||||
### Points négatifs
|
||||
|
||||
- **Manque d'ergonomie** : les pickings dédiés affichent `Code emplacement [Label]` (ex. `B-1-4 [Clavier M]`). Avec beaucoup de pickings, l'opérateur a du mal à trouver le bon.
|
||||
- **Solution proposée** : nommer les labels avec un code ordonné, ex. `B-1-4 [01 Clavier M]`, `B-1-4 [02 Clavier L]`...
|
||||
- **Destination non affichée** lors des tâches de rangement
|
||||
- **Capacité max non respectée** : il a été possible de ranger 26 ex. alors que la capacité max est de 15
|
||||
|
||||
### Points positifs
|
||||
|
||||
- ✅ **Le réapprovisionnement selon seuil min fonctionne** : une tâche de réapprovisionnement est créée pour atteindre le seuil max
|
||||
@@ -0,0 +1,80 @@
|
||||
# Gestion du cross-docking
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000060051609)
|
||||
> Dernière mise à jour : 02/09/2024 (v8)
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Le cross-docking permet, dès la réception, de distinguer les produits pouvant compléter des commandes en rupture de ceux pouvant être rangés en stock.
|
||||
|
||||
**Conditions préalables :**
|
||||
- La réception doit être faite sur le TRF (pas de réception possible sur le poumon de réception)
|
||||
- Les articles doivent autoriser le cross-docking (vue article dans SmartUI)
|
||||
|
||||
---
|
||||
|
||||
## Types de cross-docking
|
||||
|
||||
### Cross-docking direct
|
||||
|
||||
Permet de poser le stock directement sur le quai ou le poumon d'expédition, sans passer par une zone de stockage.
|
||||
|
||||
**Conditions supplémentaires :**
|
||||
- L'ordre de sortie doit être libéré (et en rupture)
|
||||
- Un quai de chargement ou un poumon doit être assigné à la commande
|
||||
|
||||
**Conditions sur l'ordre de sortie :**
|
||||
- La commande n'est pas configurée pour suivre les lignes dans l'ordre
|
||||
- L'ordre ne fait pas partie d'un itinéraire
|
||||
- La commande n'a pas de lignes marquées comme requises pour l'expédition
|
||||
|
||||
> Documentation Mecalux : [crossdocking_oportunity.md](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/crossdocking/crossdocking_manual/crossdocking_oportunity.md)
|
||||
|
||||
### Cross-docking indirect
|
||||
|
||||
Lors de la réception, le stock est rangé sur un emplacement de stockage dédié au cross-docking. Au picking, l'opérateur est envoyé sur cet emplacement.
|
||||
|
||||
**Conditions supplémentaires :**
|
||||
- Les emplacements de stockage doivent permettre le crossdocking
|
||||
- Une stratégie de rangement cross-docking doit être créée
|
||||
|
||||
> Documentation Mecalux : [crossdocking_warehouse.md](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/crossdocking/crossdocking_manual/crossdocking_warehouse.md)
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
### Sur EasyS
|
||||
|
||||
1. Créer un rack pour les emplacements de cross-docking
|
||||
2. Cocher **Is Crossdocking location = true**
|
||||
3. Associer les emplacements à une zone Warehouse de type **Cross docking**
|
||||
4. Paramétrer les workingZones pour inclure les process de crossdocking et/ou déchargement
|
||||
|
||||
### Sur SmartUI
|
||||
|
||||
1. Sur les articles, cocher **Cross-docking** dans les données avancées
|
||||
2. Créer une stratégie de rangement cross-docking (**en position 1** pour qu'elle passe avant les autres) :
|
||||
|
||||
**Onglet Critères :**
|
||||
- Activer le cross-docking
|
||||
- ⚠️ Sans critères supplémentaires, TOUS les articles seront traités en cross-docking à la réception. Ajouter des critères sur l'état des ordres de sortie attendus (ex. statut "En attente") pour éviter ça.
|
||||
|
||||
**Onglet Règles :**
|
||||
- Zone : mettre la zone de cross-docking créée dans EasyS
|
||||
|
||||
---
|
||||
|
||||
## Fonctionnement
|
||||
|
||||
Lors d'une réception, le WMS vérifie si des articles reçus sont présents dans des lignes d'ordres de sortie. Si oui, le cross-docking est mis en place. Le type (direct ou indirect) est déterminé par l'état de la commande (en rupture ou pas, quai assigné ou pas).
|
||||
|
||||
---
|
||||
|
||||
## Remarques
|
||||
|
||||
- En cross-docking direct, si l'ordre de sortie a un poumon assigné, le stock peut être envoyé vers le poumon plutôt que le quai (pour une opération de colisage).
|
||||
- Si un emplacement de cross-dock existe, le WMS redirige vers cet emplacement même s'il y a déjà du stock en réserve.
|
||||
- En cross-docking direct standard, **aucune étiquette n'est imprimée**, même pour une palette complète.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Gestion de la gerbabilité
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000130371621)
|
||||
> Dernière mise à jour : 22/11/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
La gerbabilité est renseignée sur la fiche article, de **0 à 10**.
|
||||
|
||||
- **Valeur basse** → article considéré comme **solide** → pické **en premier**, placé en **bas** de la palette
|
||||
- **Valeur élevée** → article considéré comme **fragile** → pické **en dernier**, placé **sur le dessus** de la palette
|
||||
|
||||
Cette gestion prend automatiquement le pas sur le chemin de picking classique lorsqu'elle est utilisée.
|
||||
|
||||
Si tous les articles à prélever ont la **même gerbabilité**, le chemin de picking classique s'applique.
|
||||
|
||||
La gerbabilité est renseignée dans la balise `<Stack>` du fichier **ITM01**.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Ajouter image fiche article via ITM01
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000130371614)
|
||||
> Dernière mise à jour : 22/11/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
## Si l'image est stockée en local
|
||||
|
||||
Par défaut, le WMS cherche les images dans :
|
||||
```
|
||||
C:\inetpub\wwwroot\SmartUIServices\Imagenes\EasyWMS
|
||||
```
|
||||
|
||||
La balise `<ImageName>` de l'ITM01 doit contenir **uniquement le nom du fichier** (avec extension `.jpg` ou `.png`).
|
||||
|
||||
**Exemple :** Pour le fichier `GINI.png` :
|
||||
```xml
|
||||
<ImageName>GINI.png</ImageName>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Si l'image est disponible via une URL
|
||||
|
||||
1. Se connecter à la machine et ouvrir le fichier **`appsettings.json`** dans `C:\inetpub\wwwroot\SmartUIServices`
|
||||
2. Renseigner la **partie fixe de l'URL** dans la balise `"UserImagesURI"`
|
||||
3. Dans l'ITM01, la balise `<ImageName>` ne doit contenir que le **nom du fichier** (avec extension)
|
||||
|
||||
**Exemple :** Pour l'URL `https://pim.example.com/media/879507f2_R26_0203_BLK_1.jpg`
|
||||
- `UserImagesURI` = `https://pim.example.com/media/`
|
||||
- `<ImageName>` = `879507f2_R26_0203_BLK_1.jpg`
|
||||
@@ -0,0 +1,94 @@
|
||||
# Modèles d'expédition
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000092557518)
|
||||
> Dernière mise à jour : 15/02/2024 (v2)
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Les modèles d'expéditions (**Configuration → Modèle d'expédition**) permettent de regrouper automatiquement les commandes sous forme de vague ou de groupes en fonction de critères spécifiques.
|
||||
|
||||
Ils suivent un **principe de priorité par numéro de séquence** (comme les stratégies de rangement) : plus le numéro est bas, plus la priorité est haute.
|
||||
|
||||
---
|
||||
|
||||
## Informations de base (tous les modèles)
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Code | Code du modèle |
|
||||
| Prefix | Préfixe pour le nom du groupe ou de la vague |
|
||||
| Priorité | Priorité de la vague/groupe créé |
|
||||
| Mode d'assignement | Libération automatique ou manuelle |
|
||||
| Nb max de groupes créés | Limite le nombre de groupes/vagues actifs |
|
||||
| Nb max de groupes libérés | Limite le nombre en préparation |
|
||||
| Trié par | Ordre de traitement des commandes (recommandé : date de création croissante) |
|
||||
|
||||
Il est possible d'affecter une stratégie d'assignation de stock ou une stratégie de pré-emballage au modèle.
|
||||
|
||||
---
|
||||
|
||||
## Modèles pour groupes automatiques (onglet "Picking d'ordres groupés")
|
||||
|
||||
**Critères de regroupement :** transporteur, commandes mono-ligne, commandes mono-unité, critère personnalisé.
|
||||
|
||||
**Taille du groupe :** nombre max de commandes, de lignes, volume max.
|
||||
|
||||
**Filtres de commandes :** stock rangé, crossdocking, UdM des lignes, critère personnalisé.
|
||||
|
||||
**Dégroupage :**
|
||||
- Emplacement de dégroupage (mur de tri)
|
||||
- Poumons (zones emballage)
|
||||
|
||||
**Conditions minimum :** quantité min, nb min de commandes.
|
||||
|
||||
---
|
||||
|
||||
## Modèles pour vagues automatiques (onglet "Vague de picking")
|
||||
|
||||
**Critères :** transporteur, critère personnalisé.
|
||||
|
||||
**Taille :** nombre max de commandes.
|
||||
|
||||
**Filtres :** volume max, UdM des lignes, critère personnalisé, nb min de commandes.
|
||||
|
||||
Option **"Generate tasks on release"** : si coché, les tâches sont créées à la libération ; sinon, à la sélection par l'opérateur.
|
||||
|
||||
---
|
||||
|
||||
## Modèles pour commandes unitaires (onglet "Picking d'ordre")
|
||||
|
||||
Filtres : UdM des lignes, critère personnalisé.
|
||||
|
||||
---
|
||||
|
||||
## Planificateur
|
||||
|
||||
Permet une exécution automatique entre deux heures sur des jours sélectionnés, avec un intervalle en minutes.
|
||||
|
||||
> Si deux créneaux horaires sont nécessaires (ex. 9h-10h et 15h-16h), dupliquer le modèle.
|
||||
|
||||
---
|
||||
|
||||
## Ajout d'un critère
|
||||
|
||||
Un modèle doit avoir **au moins un critère**. Un critère permet d'exclure les commandes ne respectant pas les conditions définies.
|
||||
|
||||
**Paramètres principaux (onglet "Ordre d'expédition") :** Code, Description, Type (Customer, Transfer, DirectTransfer, Fabrication, Manuel, Retour…), Classe, Propriétaire, Mono-ligne, Mono-unité, Suivre séquence, Libération auto, Transporteur, Type transport, Nb heures avant libération/chargement, Nb heures de retard, Pays/Ville/Code postal.
|
||||
|
||||
**Paramètres (onglet "Ligne d'ordre d'expédition") :** Type d'article, Famille d'article, Danger, Gerbabilité, Volumineux, Single parcel.
|
||||
|
||||
---
|
||||
|
||||
## Syntaxe des critères personnalisés
|
||||
|
||||
La syntaxe suit le **LINQ** :
|
||||
|
||||
```csharp
|
||||
// Critère sur l'ordre de sortie (ex. source = "WEB")
|
||||
o.Source == "WEB"
|
||||
|
||||
// Critère sur la ligne d'ordre de sortie
|
||||
l.Item.ItemType.Code == "FROID"
|
||||
```
|
||||
@@ -0,0 +1,47 @@
|
||||
# Transactions
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000063885446)
|
||||
> Dernière mise à jour : 31/05/2024 (v4)
|
||||
|
||||
---
|
||||
|
||||
L'écran des transactions permet d'avoir un aperçu précis de toutes les actions réalisées dans le WMS.
|
||||
|
||||
Les transactions dont le **Type de Transaction** a le **"Post-Traitement" activé** entraînent l'envoi d'un message à l'ERP.
|
||||
|
||||
Lorsqu'une transaction est en statut **"Envoyé"** ou **"Génération d'erreur"**, il est possible de regénérer le fichier envoyé à l'ERP (les modifications du code BOO associé seront prises en compte).
|
||||
|
||||
---
|
||||
|
||||
## Liste des types de transactions les plus utilisées
|
||||
|
||||
| Type de transaction | Post-Traitement | Signification | Commentaires |
|
||||
|---------------------|----------------|---------------|--------------|
|
||||
| INO.CST.001 | ✅ Oui | Changement de statut d'un ordre d'entrée | Colonne Document1 = code ordre d'entrée, Document2 = statut. Fichier **ROC** envoyé |
|
||||
| INO.CLS.001 | ✅ Oui | Fermeture d'un ordre d'entrée | Fichier **ROF** envoyé |
|
||||
| INO.CNL.001 | ✅ Oui | Annulation de l'ordre d'entrée | Fichier **ROC** envoyé |
|
||||
| REC.CST.001 | ✅ Oui | Changement de statut d'une réception | Fichier **REC** envoyé |
|
||||
| REC.CLS.001 | ✅ Oui | Fermeture d'une réception | Fichier **REF** envoyé |
|
||||
| REC.CNL.001 | ✅ Oui | Annulation d'une réception | Fichier **REC** envoyé |
|
||||
| OUT.CST.001 | ✅ Oui | Changement de statut d'un ordre de sortie | Fichier **SOC** envoyé |
|
||||
| OUT.CLS.001 | ✅ Oui | Fermeture d'un ordre de sortie | Fichier **SOF** envoyé |
|
||||
| OUT.CNL.001 | ✅ Oui | Annulation d'un ordre de sortie | Fichier **SOC** envoyé |
|
||||
| STK.ADJ.001 | ✅ Oui | Ajustement (création/suppression) d'un stock | Fichier **STV** envoyé |
|
||||
| STK.PICKING | ❌ Non | Picking fait sur un stock | Document1 = code ordre de sortie |
|
||||
| STK.SHIPPED | ❌ Non | Stock expédié (supprimé du WMS) | Document1 = code ordre de sortie |
|
||||
| STK.LOAD | ❌ Non | Stock chargé sur le quai | |
|
||||
| STK.LOCATE | ❌ Non | Stock rangé pour la première fois | |
|
||||
| STK.MOVE | ❌ Non | Stock déplacé | |
|
||||
| STK.RECEP | ❌ Non | Stock reçu | |
|
||||
| CST.STK.001 | ✅ Oui | Modification du statut de stock | Fichier **STC** envoyé |
|
||||
| STK.SEND.L&F | ❌ Non | Envoi d'un stock vers le LostFound | Toujours associé à CON.SEND.L&F |
|
||||
| STK.RESTORE.L&F | ❌ Non | Retour d'un stock depuis le LostFound | |
|
||||
| CON.CREATE | ❌ Non | Création d'un conteneur | |
|
||||
| CON.DELETE | ❌ Non | Suppression d'un conteneur | |
|
||||
| CON.MOV | ❌ Non | Déplacement d'un conteneur | |
|
||||
| CON.SEND.L&F | ❌ Non | Envoi d'un conteneur vers le LostFound | |
|
||||
| CON.RESTORE.L&F | ❌ Non | Retour d'un conteneur depuis le LostFound | |
|
||||
| CON.ASN.001 | ✅ Oui | Réception d'un conteneur depuis l'ASN | |
|
||||
| CON.CNL.ASN | ❌ Non | Annulation d'un conteneur ASN | |
|
||||
| TSK.CANCEL | ❌ Non | Annulation d'une tâche | Document1 = code ordre de sortie |
|
||||
| LOAD.CLS.001 | ✅ Oui | Chargement fermé | Fichier **LOF** envoyé à l'ERP |
|
||||
@@ -0,0 +1,36 @@
|
||||
# Préparation papier
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000113168398)
|
||||
> Dernière mise à jour : 06/10/2022 (v2)
|
||||
|
||||
---
|
||||
|
||||
## Paramétrage en amont
|
||||
|
||||
Affecter les droits suivants aux utilisateurs via l'onglet **Web** de la vue **Permissions des groupes d'utilisateurs**, menu **Sorties/Ordres de Sortie** :
|
||||
|
||||
- Préparer avec FR
|
||||
- Générer lot
|
||||
- Imprimer préparation de commande papier
|
||||
|
||||
---
|
||||
|
||||
## Processus
|
||||
|
||||
1. **Libérer l'ordre de sortie**
|
||||
|
||||
2. **Préparer sur papier** : cliquer sur "_Préparer Préparation de commande papier_"
|
||||
|
||||
3. **Vérifier qu'un poumon ou un quai est bien affecté** à la commande, puis **Générer un lot de préparation**
|
||||
|
||||
4. **Imprimer le bon de préparation** via "_Imprimer préparation de commande papier_"
|
||||
|
||||
5. Le préparateur **effectue le picking** en suivant le bon imprimé
|
||||
|
||||
6. **Confirmer la prise** via le menu _Confirmer le lot_
|
||||
|
||||
7. **Flasher le numéro de lot** présent sur le bon de préparation :
|
||||
- Si la commande est **complète** → scanner de nouveau le numéro de lot pour terminer la préparation
|
||||
- Sinon → scanner les tâches incomplètes une par une et renseigner la quantité réellement prélevée
|
||||
|
||||
8. Scanner le numéro de lot pour indiquer que la préparation est terminée → la commande passe à l'état **"Préparé"** et le stock est transféré sur le poumon/quai d'expédition.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Articles alternatifs
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000113922049)
|
||||
> Dernière mise à jour : 03/10/2023 (v7)
|
||||
|
||||
---
|
||||
|
||||
Si un article est en rupture, le WMS peut choisir un article de substitution selon la configuration. La mise en place nécessite 3 étapes.
|
||||
|
||||
---
|
||||
|
||||
## 1. Modification du SOR
|
||||
|
||||
Dans le SOR01 ou SOR02, ajouter dans la balise `<Line>` des articles concernés :
|
||||
|
||||
```xml
|
||||
<LneTerms>
|
||||
<LneTrmAlternative>true</LneTrmAlternative>
|
||||
</LneTerms>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Profil d'expédition
|
||||
|
||||
Tous les articles concernés par la substitution doivent avoir un **profil d'expédition** configuré (**Données principales → Détails d'articles → Profils d'expédition**).
|
||||
|
||||
Choisir un **mode de réservation d'articles alternatifs** (X = article demandé, Y = article de substitution) :
|
||||
|
||||
| Mode | Comportement |
|
||||
|------|-------------|
|
||||
| **Partiel** | Additionne X et Y pour atteindre la quantité demandée. Priorise X. |
|
||||
| **Substitution** | Choisit X ou Y de façon exclusive (l'article dont la quantité est la plus proche de celle demandée). |
|
||||
| **Tout ou rien** | Si la combinaison X+Y n'atteint pas la quantité totale, prend uniquement X peu importe la quantité. |
|
||||
|
||||
> ⚠️ Pour les composants de kits non-montés, utiliser obligatoirement le mode **"Partiel"**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Choix de l'article de substitution
|
||||
|
||||
Dans **Données principales → Articles**, sélectionner l'**article qui sera remplacé** et cliquer sur **"Ajouter Alternatif"** :
|
||||
|
||||
1. Article de base
|
||||
2. À partir de quelle quantité on le remplace / Par tranches de combien
|
||||
3. Article de substitution
|
||||
4. Quantité de l'article de substitution utilisée pour remplacer la quantité définie en 2.
|
||||
5. Durée d'activation (laisser vide = ad vitam aeternam)
|
||||
|
||||
---
|
||||
|
||||
## 4. Remontée d'informations dans le SOF
|
||||
|
||||
| Cas | Comportement dans le SOF |
|
||||
|-----|--------------------------|
|
||||
| Seul X pické | `<LneDIsAlternative>false</LneDIsAlternative>` |
|
||||
| X et Y pickés | Deux `<LneDetail>` : un avec `LneDIsAlternative=false` (X), un avec `LneDIsAlternative=true` (Y) |
|
||||
| Seul Y pické | Un seul `<LneDetail>` avec `LneDIsAlternative=true` — `<LneItemCode>` contient toujours X (l'article demandé) |
|
||||
@@ -0,0 +1,86 @@
|
||||
# Gestion des KIT
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000114413577)
|
||||
> Dernière mise à jour : 31/12/2025 (v8)
|
||||
|
||||
---
|
||||
|
||||
## 1.1 Présentation
|
||||
|
||||
Un kit est un article résultant de l'assemblage de plusieurs autres articles. Les données peuvent être envoyées via le fichier **KIT** ou créées dans **Données principales → Kit**.
|
||||
|
||||
**Un article peut être configuré comme Kit uniquement s'il est géré par un profil logistique avec l'attribut logistique "Version".**
|
||||
|
||||
### Kit sans montage
|
||||
|
||||
Les composants sont livrés directement au client sans assemblage en entrepôt. Si au moins un composant est en rupture, tout le kit est considéré en rupture.
|
||||
|
||||
### Kit avec montage
|
||||
|
||||
Des **ordres de fabrication** (via fichier **WOR** ou manuellement) permettent d'assembler le kit. À la fabrication, le stock des composants est automatiquement décrémenté.
|
||||
|
||||
**Montage sur demande** : si activé + l'OS est en "Réapprovisionnement automatique" → un ordre de travail est créé automatiquement à l'intégration d'une commande avec kit en rupture.
|
||||
|
||||
> Doc MSSCC : [kit_assembly_configuration01.md](https://msscc.mecalux.com/documentation/documentation/master/EN/configurations/kits/kit_assembly_configuration01.md)
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Création d'un article de KIT
|
||||
|
||||
Dans **Données Principales → Kit** :
|
||||
|
||||
1. Article de kit + propriétaire
|
||||
2. Version du kit (doit être une valeur permise par le profil logistique)
|
||||
3. Unité de mesure de base
|
||||
4. À assembler ou non
|
||||
5. Si à assembler : Montage sur demande possible ?
|
||||
|
||||
Ajouter les composants avec **"Ajouter composant"** : article, quantité, composant principal.
|
||||
|
||||
> ⚠️ Si l'erreur d'activation s'affiche : l'article de kit utilise un profil logistique sans version ou sans méthode de contrôle en réception → assigner un profil adéquat.
|
||||
|
||||
---
|
||||
|
||||
## 1.3 Création / Modification / Annulation d'un ordre de travail
|
||||
|
||||
| Mode de création | Description |
|
||||
|-----------------|-------------|
|
||||
| Depuis l'ERP | Fichier WOR. OF créé au statut "En attente". Fichier WOF remonté à la clôture/annulation. |
|
||||
| Manuel SmartUI | Menu Ordres de travail > Ordres de travail. Fichier KST remonté à la clôture. |
|
||||
| Manuel TRF | Menu Kits > Demande de composants. OF créé et libéré automatiquement. ⚠️ AUCUNE remontée ERP. |
|
||||
| Automatique | Si "Montage sur demande" = OUI. Déclenché à la réception d'une commande avec kit en rupture. |
|
||||
|
||||
**Modification selon le statut de l'OF :**
|
||||
|
||||
| Statut | Actions possibles |
|
||||
|--------|------------------|
|
||||
| En attente | Modification de tous les champs |
|
||||
| Libéré | Modification de la quantité et de la priorité uniquement |
|
||||
| En cours (≥1 kit assemblé) | Modification quantité (≥ déjà assemblée) et priorité |
|
||||
| Annulation | Possible uniquement si aucun kit n'a encore été assemblé |
|
||||
|
||||
---
|
||||
|
||||
## 1.4 Approvisionnement et montage/démontage
|
||||
|
||||
À la libération d'un ordre de travail, le WMS vérifie le stock disponible sur la zone de kit. Si insuffisant, un **ordre d'approvisionnement** est créé et libéré automatiquement.
|
||||
|
||||
---
|
||||
|
||||
## 1.5 Clôture d'un ordre de travail
|
||||
|
||||
- **Automatique** : lorsque tous les kits demandés ont été assemblés/désassemblés
|
||||
- **Manuelle** : possible à tout moment si au moins 1 kit a été assemblé/désassemblé
|
||||
- À la clôture : fichier **WOF** remonté à l'ERP (si OF depuis ERP ou SmartUI)
|
||||
|
||||
---
|
||||
|
||||
## 1.6 Gestion des ruptures de kits
|
||||
|
||||
| | **Montage sur demande = OUI** | **Montage sur demande = NON** |
|
||||
|---|---|---|
|
||||
| **Création de l'OF** | Automatique | Manuelle |
|
||||
| **Détection de la rupture** | Automatique + OF créé | Consultation manuelle de la vue Ordres de Sortie |
|
||||
| **Délai de traitement** | Immédiat à l'intégration | Dépend de la fréquence de consultation |
|
||||
|
||||
> ⚠️ Sans "Montage sur demande", EasyWMS ne génère **aucune alerte automatique** (notification, email). Il est de la responsabilité du client de consulter régulièrement la vue des Ordres de Sortie.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Processus d'inventaire
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000120639489)
|
||||
> Dernière mise à jour : 05/12/2023 (v5)
|
||||
|
||||
---
|
||||
|
||||
## Inventaire à l'aveugle ou non
|
||||
|
||||
À la création d'un inventaire dans SmartUI, il est possible de choisir si l'inventaire est **à l'aveugle** (données non pré-remplies, comme un inventaire physique) ou **guidé** (choix dans une liste).
|
||||
|
||||
Pour cela, activer la coche **"Est renseigné"** dans les lignes d'inventaire.
|
||||
|
||||
> L'avantage : pour un même inventaire, certains emplacements (ex. picking) peuvent être pré-remplis et d'autres (ex. réserve) non.
|
||||
|
||||
Si le champ n'apparaît pas : sélectionner une ligne d'inventaire et cliquer sur **"Visibilité"**. Si toujours absent, supprimer la condition de visibilité dans la vue `CountOrderLineVList` en la mettant en commentaire (`/* condition */`) et en forçant `true`.
|
||||
|
||||
---
|
||||
|
||||
## Inventaire avec attributs logistiques différents (numéros de série)
|
||||
|
||||
Lors d'un inventaire sur des articles avec numéro de série (attribut unique par article) :
|
||||
|
||||
1. Le WMS demande un numéro de série → saisir le premier (ex. `A`)
|
||||
2. Il boucle sur cet écran pour chaque exemplaire de l'article → saisir un numéro différent pour chaque (ex. `B`, `C`...)
|
||||
3. Cliquer sur **"Terminé"** une fois tous les numéros saisis
|
||||
4. Saisir l'article suivant de l'emplacement, ou cliquer sur **"Fin"**
|
||||
|
||||
Le WMS indiquera qu'il n'a pas trouvé l'article original (sans numéro de série) → cliquer sur **"Introuvable"**. Cela supprime la ligne de stock sans numéro de série et crée les nouvelles lignes avec numéro de série.
|
||||
@@ -0,0 +1,68 @@
|
||||
# Configuration ABC
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000125292551)
|
||||
> Dernière mise à jour : 05/06/2024 (v12)
|
||||
|
||||
---
|
||||
|
||||
## 1 - Fonctionnement des classements ABC
|
||||
|
||||
1. Plus la valeur de mouvement d'un classement est élevée, plus il est **important** (A > B > C)
|
||||
2. Les articles ayant le **plus de mouvements** sont classés dans les classements les plus hauts
|
||||
3. L'affectation représente la **part cumulée** du mouvement : un article A = top 50%, un article B = top 80% (50+30), etc.
|
||||
4. Lorsqu'un article chevauche 2 classifications :
|
||||
- **Inclusif** → prend le classement le plus important
|
||||
- **Exclusif** → prend le classement le moins important
|
||||
|
||||
---
|
||||
|
||||
## 2 - Création des classements ABC
|
||||
|
||||
Menu : **Données Principales → Détails d'articles → Classement ABC**
|
||||
|
||||
Règles :
|
||||
- Plus le **pourcentage de mouvement minimum** est important, plus la rotation est importante
|
||||
- Pas de doublons de pourcentage
|
||||
- La somme des pourcentages ne doit pas dépasser 100
|
||||
|
||||
---
|
||||
|
||||
## 3 - 1ère assignation
|
||||
|
||||
Pour la première assignation, tous les articles sont assignés à la **rotation la moins importante**. À faire dans l'import de la base article. Lors de la création d'un nouvel article, ce champ doit être renseigné.
|
||||
|
||||
---
|
||||
|
||||
## 4 - Évaluation ABC
|
||||
|
||||
Menu : **Tableaux de Bord → Evaluation ABC** *(sur les dernières versions)*
|
||||
|
||||
Paramètres de l'évaluation :
|
||||
- **Date** : Start-end date ou By number of day
|
||||
- **Mouvements** : types de tâches à prendre en compte (au moins un)
|
||||
- **Type de calcul** : Inclusive / Exclusive
|
||||
|
||||
Après exécution, **rafraîchir la grille** pour voir les résultats. Ces résultats persistent jusqu'à la prochaine évaluation.
|
||||
|
||||
---
|
||||
|
||||
## 5 - Traitement des résultats
|
||||
|
||||
- **Lignes rouges** : classification ABC surévaluée par rapport à l'évaluation
|
||||
- **Lignes vertes** : classification ABC sous-évaluée
|
||||
- Les articles conformes n'apparaissent pas dans la grille
|
||||
|
||||
Il est possible de modifier la classification directement depuis cette vue.
|
||||
|
||||
---
|
||||
|
||||
## 6 - Notification ERP
|
||||
|
||||
Un bouton permet d'envoyer à l'ERP la liste des articles mal classés via un fichier **SAC**.
|
||||
|
||||
Pour activer : **Configuration → Types de transaction** → rechercher `SAC.SEND.001` → activer la notification de lecture d'insertion et le post-traitement.
|
||||
|
||||
**Liens complémentaires :**
|
||||
- [Evaluation ABC](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/inventory_management/evaluation_abc/evaluation_abc_index.md)
|
||||
- [Calcul ABC](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/inventory_management/evaluation_abc/calculation_type_abc.md)
|
||||
- [Fichier SAC](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/ERP/masters/sac.md)
|
||||
@@ -0,0 +1,50 @@
|
||||
# Tense Flow (Flux tendu)
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000136728577)
|
||||
> Dernière mise à jour : 29/01/2024 (v5)
|
||||
|
||||
---
|
||||
|
||||
Le flux tendu permet de faire du picking directement depuis un ou plusieurs supports, notamment pour préparer directement depuis la réception sans avoir à ranger.
|
||||
|
||||
---
|
||||
|
||||
## Configuration EasyS
|
||||
|
||||
1. Ajouter l'élément **"Tense Flow"** et un **poumon associé** (ex. PREPARATION)
|
||||
2. Associer l'élément à une allée (Count, Load, Pick, Put, Unload)
|
||||
3. Associer l'élément au poumon PREPARATION (Delivery Stage)
|
||||
4. Configurer les emplacements avec les options requises
|
||||
|
||||
> ⚠️ Bien paramétrer tous les emplacements (poumons et racks) comme **source de réapprovisionnement pour le flux tendu** (`Allow origin of replenishement of tense flow`). Lors du lancement en flux tendu, le système crée d'abord une tâche de réappro vers le poumon associé.
|
||||
|
||||
---
|
||||
|
||||
## Utilisation fonctionnelle
|
||||
|
||||
### 1. Lancer en flux tendu (SmartUI)
|
||||
|
||||
Cliquer sur le bouton **"Lancer en flux tendu"** sur l'ordre de sortie.
|
||||
|
||||
→ La commande passe à l'état **"Assigné"** et une tâche de réapprovisionnement est créée automatiquement vers le poumon PREPARATION.
|
||||
|
||||
### 2. Réaliser le flux tendu (TRF)
|
||||
|
||||
Menu TRF : **Tâches → Tâches à flux tendu**
|
||||
|
||||
Réaliser la tâche de réappro pour transférer le stock vers le poumon.
|
||||
|
||||
### 3. Picking virtuel (TRF)
|
||||
|
||||
Menu TRF : **Ordres de sortie → Picking virtuel**
|
||||
|
||||
1. Scanner le support source
|
||||
2. Créer un **nouveau conteneur client** (utiliser le bouton "Générer SSCC")
|
||||
3. Scanner le conteneur créé ou l'emplacement
|
||||
4. Saisir l'article et la quantité (+ éventuels attributs logistiques)
|
||||
|
||||
Le système propose ensuite de ranger les articles restants en stock via les stratégies de rangement classiques.
|
||||
|
||||
### 4. Fin du flux tendu
|
||||
|
||||
Une fois tous les supports remplis, les transférer vers le poumon EXPEDITION (tâche créée automatiquement), puis continuer la commande (chargement camion, colisage, ou transfert vers le quai d'expédition).
|
||||
@@ -0,0 +1,27 @@
|
||||
# Fonctionnement des routes / tournées
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000136663127)
|
||||
> Dernière mise à jour : 06/12/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
Les routes/tournées permettent d'envoyer des commandes dans un ordre précis défini par un TMS. Au lieu d'un fichier SOR, un fichier **RUT** est utilisé. Ce fichier contient un en-tête de tournée et toutes les commandes avec leur **numéro d'arrêt**. L'objectif est de charger le camion dans l'**ordre inverse des numéros d'arrêt** (dernier client servi chargé en premier).
|
||||
|
||||
---
|
||||
|
||||
## Processus
|
||||
|
||||
1. **Intégration du fichier RUT** → les commandes apparaissent dans la vue des commandes, mais doivent être traitées depuis la **vue des tournées**
|
||||
|
||||
2. **Lancer la tournée** → libère automatiquement chacune des commandes avec les assignations de stock
|
||||
|
||||
3. **Préparer les commandes** de manière habituelle dans l'ordre souhaité
|
||||
|
||||
4. **Créer un chargement camion** et l'assigner à la tournée
|
||||
- La création peut être automatique si un template est configuré (créé à la libération de la tournée)
|
||||
- ⚠️ Bien ajouter un **quai** au chargement camion
|
||||
|
||||
5. **Chargement camion sur TRF** : scanner les conteneurs dans l'ordre attendu
|
||||
- Si un conteneur avec le mauvais numéro d'arrêt est scanné → message d'erreur demandant si le chargement doit quand même être effectué
|
||||
|
||||
> 💡 Idéalement, le prochain conteneur à scanner devrait être affiché à l'opérateur pour qu'il le cible directement (custom potentiel).
|
||||
@@ -0,0 +1,46 @@
|
||||
# ASN - Commande de type `<DirectTransfer>`
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000173166593)
|
||||
> Dernière mise à jour : 16/02/2023 (v3)
|
||||
|
||||
---
|
||||
|
||||
## Principes
|
||||
|
||||
Les commandes `<DirectTransfer>` (balise `<SorType>` du fichier SOR02) nécessitent **au moins deux entrepôts** dans le WMS. Elles permettent d'expédier de la marchandise d'un dépôt source vers un dépôt de destination.
|
||||
|
||||
> ⚠️ **Aucun ordre d'entrée ni aucune réception** ne sont créés dans le dépôt de destination.
|
||||
|
||||
---
|
||||
|
||||
## Préparation de la commande
|
||||
|
||||
Identique à une commande client standard. Suite à la fermeture de l'ordre de sortie sur le dépôt source, les conteneurs expédiés sont automatiquement créés sur l'emplacement **"Asn"** du dépôt de destination.
|
||||
|
||||
Visualisation dans SmartUI : **Entrepôt → Conteneurs ASN**
|
||||
|
||||
---
|
||||
|
||||
## Réception de conteneurs
|
||||
|
||||
Menu TRF : **Réception → Préavis** de l'entrepôt de destination
|
||||
|
||||
- Réceptionner sur le poumon ou l'équipement
|
||||
- Scanner le conteneur réceptionné (aucune autre validation requise)
|
||||
- Un fichier **ASO01** est généré automatiquement
|
||||
|
||||
> Par définition, le transfert direct évite de recontrôler la marchandise sur le dépôt de destination.
|
||||
|
||||
---
|
||||
|
||||
## Suppression de conteneurs
|
||||
|
||||
Si un conteneur n'est pas arrivé ou n'est pas conforme : SmartUI → **Entrepôt → Conteneurs ASN** → sélectionner le conteneur → cliquer sur **"Supprimer"**.
|
||||
|
||||
→ Génère un fichier **ASK01**.
|
||||
|
||||
---
|
||||
|
||||
## Point d'attention
|
||||
|
||||
> ⚠️ Les fichiers ASO01 et ASK01 **ne contiennent aucune information sur la commande de transfert d'origine**. L'ERP doit faire lui-même le rapprochement de tous les conteneurs des fichiers ASO et ASK pour confirmer ou infirmer la réception complète d'un transfert.
|
||||
@@ -0,0 +1,48 @@
|
||||
# ASN - Commande de type `<Transfer>`
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000176803841)
|
||||
> Dernière mise à jour : 16/02/2023 (v4)
|
||||
|
||||
---
|
||||
|
||||
## Principe
|
||||
|
||||
Les commandes `<Transfer>` (balise `<SorType>` du fichier SOR02) nécessitent **au moins deux entrepôts** dans le WMS.
|
||||
|
||||
**Différence avec `<DirectTransfer>`** : un **ordre d'entrée est automatiquement créé** dans le dépôt de destination suite à la confirmation d'expédition depuis le dépôt source. Cet ordre d'entrée a le même code que la commande source.
|
||||
|
||||
---
|
||||
|
||||
## Préparation de la commande
|
||||
|
||||
Identique à une commande client standard. Suite à la fermeture, les conteneurs sont créés sur l'emplacement **"Asn"** du dépôt de destination, et un **ordre d'entrée** est automatiquement créé avec les conteneurs attendus.
|
||||
|
||||
---
|
||||
|
||||
## Réception de conteneurs
|
||||
|
||||
> ⚠️ Si **`AutoCreateReceptionFromRecorder`** = `true` sur le dépôt de destination → une réception se créé automatiquement. Sinon, la créer manuellement.
|
||||
|
||||
Menu TRF : **Réception → Préavis** de l'entrepôt de destination → scanner chaque conteneur.
|
||||
|
||||
Lorsque tous les conteneurs attendus sont scannés, l'opérateur peut fermer la réception.
|
||||
|
||||
> ⚠️ Si **`AutoCloseInboundOrder`** = `true` → l'ordre d'entrée se ferme automatiquement après la fermeture de la réception (génération du fichier **ROF02**).
|
||||
|
||||
Un fichier **ASO01** est généré à la réception de chaque conteneur.
|
||||
|
||||
---
|
||||
|
||||
## Suppression de conteneurs
|
||||
|
||||
Contrairement au `<DirectTransfer>`, la suppression d'un conteneur non arrivé se fait en **fermant l'ordre d'entrée** partiellement reçu.
|
||||
|
||||
→ Génère un fichier **ASK01**.
|
||||
|
||||
---
|
||||
|
||||
## Point d'attention
|
||||
|
||||
> ⚠️ Les fichiers ASO01 et ASK01 ne contiennent aucune information sur la commande de transfert. Pour un `<Transfer>`, l'ERP doit privilégier le fichier **ROF02** qui contient tous les conteneurs réceptionnés.
|
||||
|
||||
> Utilisé chez RAUD depuis le hub LRM vers les autres sites (MOR, LAM, etc.)
|
||||
@@ -0,0 +1,99 @@
|
||||
# Stratégies de réapprovisionnement
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000181358593)
|
||||
> Dernière mise à jour : 17/04/2024 (v9)
|
||||
|
||||
---
|
||||
|
||||
## Sur seuil → "Routine"
|
||||
|
||||
Le réapprovisionnement sur seuil est le plus utilisé. Il crée automatiquement des tâches de réapprovisionnement lorsque la quantité à l'emplacement de picking atteint le seuil minimum paramétré.
|
||||
|
||||
### Configuration EasyS
|
||||
|
||||
**Emplacements à réapprovisionner (picking) :**
|
||||
- Allow picking
|
||||
- Allow product location
|
||||
- Allow replenish
|
||||
|
||||
**Emplacements de réserve (source) :**
|
||||
- Allow replenish at source
|
||||
|
||||
### Paramétrage SmartUI
|
||||
|
||||
**1/** Créer les assignations picking : **Entrepôt → Gestion des emplacements picking**
|
||||
- Définir le **seuil minimum** : par conteneur (cocher "Réapprovisionnement de conteneur") ou en unité de base
|
||||
- Définir la **capacité max** (seuil maximum)
|
||||
|
||||
**2/** Activer le réapprovisionnement automatique de l'emplacement picking dédié
|
||||
|
||||
**3/** Créer une stratégie de réapprovisionnement de type **"routine"** : **Configuration → Stratégie de réapprovisionnement**
|
||||
|
||||
Filtres disponibles : article, propriétaire, type d'article, sous-entrepôt (entrepôt annexe vers), zone de stockage (destination zone).
|
||||
|
||||
**Champ "Mode efficacité"** :
|
||||
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| **Efficacité** | Réduit au maximum le nombre de tâches nécessaires pour atteindre la capacité |
|
||||
| **Emplacement le plus proche** | Sélectionne le support disponible le plus proche |
|
||||
| **À vider** | Sélectionne le support permettant de vider l'emplacement de réserve (peu utile si réappro au conteneur) |
|
||||
|
||||
**4/** Activer la stratégie de réapprovisionnement
|
||||
|
||||
**5/** Activer le job **"TryToReplenishProductLocations"** et vérifier qu'il tourne régulièrement (1-2 min) : **Configuration → Processus**
|
||||
|
||||
**6/** Vérifier la présence de stock disponible :
|
||||
- Pas de statut empêchant le réapprovisionnement
|
||||
- Pas de blocage emplacement
|
||||
- Pas de tâche de shipping assignée au conteneur
|
||||
|
||||
**7/** Les tâches de réapprovisionnement se créent automatiquement (autant que nécessaire pour atteindre la capacité)
|
||||
|
||||
> ⚠️ Pour modifier une stratégie existante, la **désactiver** au préalable.
|
||||
|
||||
---
|
||||
|
||||
## Sur demande opérateur → "Conclure"
|
||||
|
||||
Permet de créer des tâches de réapprovisionnement en **priorité élevée** suite à une demande manuelle de l'opérateur.
|
||||
|
||||
### Configuration EasyS
|
||||
|
||||
Identique au réapprovisionnement sur seuil (Allow picking + Allow product location + Allow replenish pour les pickings, Allow replenish at source pour les réserves).
|
||||
|
||||
### Paramétrage SmartUI
|
||||
|
||||
**1/** Créer les assignations picking (mêmes champs que pour "Routine", le réappro automatique ou manuel peut être activé)
|
||||
|
||||
**2/** Créer une stratégie de type **"conclure"**
|
||||
|
||||
**3/** Activer la stratégie
|
||||
|
||||
**4/** Vérifier la présence de stock disponible
|
||||
|
||||
**5/** Déclenchement manuel :
|
||||
- Via SmartUI (vue emplacements picking) : cliquer sur **"Réapprovisionner maintenant"**
|
||||
- Via TRF : menu **Réapprovisionnement** → sous-menu souhaité
|
||||
|
||||
**6/** Les tâches se créent automatiquement
|
||||
|
||||
---
|
||||
|
||||
## Dynamique → "Exiger"
|
||||
|
||||
Permet la création automatique des emplacements de picking en fonction des besoins présents dans les commandes libérées.
|
||||
|
||||
### Paramétrage SmartUI
|
||||
|
||||
**1/** Créer une stratégie de type **"exiger"** (mêmes filtres et mode efficacité que les autres)
|
||||
|
||||
**2/** Activer la stratégie
|
||||
|
||||
**3/** Vérifier la présence de stock disponible
|
||||
|
||||
### Fonctionnement
|
||||
|
||||
Les stratégies de réapprovisionnement sur commandes fonctionnent aussi en réapprovisionnement statique (via la balise `EnableReplenishment` du fichier ROR, sans activer l'assignation automatique d'article à l'emplacement).
|
||||
|
||||
Si le stock présent est supérieur au seuil minimum mais inférieur au besoin de la commande, une tâche de réapprovisionnement est automatiquement créée au lancement de la commande pour atteindre le seuil maximum.
|
||||
@@ -0,0 +1,79 @@
|
||||
# Validation ajustements de stock
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000184078351)
|
||||
> Dernière mise à jour : 03/03/2023 (v2)
|
||||
|
||||
> ℹ️ Uniquement pour les WMS datant d'après le **22/02/2023**
|
||||
|
||||
---
|
||||
|
||||
## Explications
|
||||
|
||||
Tous les ajustements de stocks manuels (inventaire, suppression via TRF ou SmartUI) produisent habituellement un fichier **STV** et une ligne dans la vue des Ajustements de stocks.
|
||||
|
||||
La nouvelle version permet une **validation manuelle** avant que le STV soit envoyé ou non à l'ERP.
|
||||
|
||||
Les ajustements restent en statut **"Pending"** jusqu'à validation ou annulation par un responsable.
|
||||
|
||||
> ⚠️ **La modification du stock est prise en compte par le WMS quelle que soit la validation.** Cette fonctionnalité n'impacte que la **communication avec l'ERP**.
|
||||
|
||||
- **Pending** : pas de transaction, pas de communication ERP
|
||||
- **Validé** : STV envoyé à l'ERP
|
||||
- **Annulé** : les changements de stock sont annulés en base, aucune transaction ou message ERP créé
|
||||
|
||||
---
|
||||
|
||||
## Mise en place
|
||||
|
||||
### Profil d'inventaire (Count Profile)
|
||||
|
||||
**Configuration → Count Profiles** → Nouveau
|
||||
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| **Never** | Ne requiert jamais de validation |
|
||||
| **Always** | Requiert toujours une validation |
|
||||
| **According to tolerance** | Requiert une validation uniquement si l'ajustement dépasse la tolérance définie |
|
||||
|
||||
**Paramètres de tolérance :**
|
||||
|
||||
| Paramètre | Description |
|
||||
|-----------|-------------|
|
||||
| Maximum positive percentage variance | % max d'augmentation autorisé sans validation |
|
||||
| Maximum negative percentage variance | % max de diminution autorisé sans validation |
|
||||
| Maximum positive adjust | Augmentation max (en unité de base) autorisée sans validation |
|
||||
| Maximum negative adjust | Diminution max (en unité de base) autorisée sans validation |
|
||||
|
||||
> ℹ️ Il n'est pas encore possible de créer ces profils via ITM.
|
||||
|
||||
### Article
|
||||
|
||||
Modifier l'article et lui assigner un **profil d'inventaire**.
|
||||
|
||||
---
|
||||
|
||||
## Validation du mouvement
|
||||
|
||||
**Vue des ajustements de stocks** → sélectionner une ligne → deux actions disponibles :
|
||||
|
||||
**Droits requis :** groupe SuperAdmin ou Administrateur (pas Manager/Opérateur par défaut).
|
||||
|
||||
> Le groupe de sécurité n'a aucun impact sur le déclenchement de la validation — même en SuperAdmin sur TRF, si l'article a un profil d'inventaire, la validation dans SmartUI est requise.
|
||||
|
||||
### Cancel
|
||||
|
||||
- **Variation négative** : le WMS propose de remettre le stock supprimé à l'emplacement d'origine (ou un autre emplacement au choix)
|
||||
- **Variation positive** : le WMS demande sur quel emplacement retirer le stock ajouté
|
||||
|
||||
### Validate
|
||||
|
||||
Aucune confirmation requise — le STV est envoyé immédiatement.
|
||||
|
||||
---
|
||||
|
||||
## Historique
|
||||
|
||||
La vue par défaut n'affiche que les mouvements **"Pending"**. Pour voir l'historique complet, activer l'historique dans la vue.
|
||||
|
||||
- **Vert** : validé, ou sans profil, ou profil "Never", ou en dessous de la tolérance
|
||||
- **Rouge** : refusé
|
||||
@@ -0,0 +1,96 @@
|
||||
# Chargement camion
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000207671297)
|
||||
> Dernière mise à jour : 14/11/2024 (v7)
|
||||
|
||||
---
|
||||
|
||||
En standard, deux modes existent :
|
||||
|
||||
- **Sans poumon** : la commande est expédiée automatiquement à la dépose sur le quai
|
||||
- **Avec poumon + quai** : une étape de contrôle permet de valider les palettes chargées dans le camion avant l'expédition
|
||||
|
||||
---
|
||||
|
||||
## 1. Les différents modes de chargement
|
||||
|
||||
| Interface | Mode | Description |
|
||||
|-----------|------|-------------|
|
||||
| SmartUI | Automatique (planifié) | Création automatique à la libération de la commande + contrôle des conteneurs |
|
||||
| SmartUI | Non planifié | Création automatique à la libération + sans contrôle |
|
||||
| SmartUI | Manuel (planifié) | Création manuelle + contrôle des conteneurs |
|
||||
| TRF | Manuel sans contrôle | Création manuelle, sans contrôle des conteneurs (à titre indicatif) |
|
||||
| TRF | Depuis une tournée | Chargement lié à une tournée existante |
|
||||
|
||||
---
|
||||
|
||||
## 2. Configuration EasyS
|
||||
|
||||
Nécessite au minimum **un poumon** et **un quai** d'expédition.
|
||||
|
||||
Le poumon peut être renseigné dans le fichier SOR02 via la balise `<PrpPackingLocation>`, ou affecté manuellement dans SmartUI (Ordres de sortie → "Assigner quai/poumon").
|
||||
|
||||
---
|
||||
|
||||
## 3. Paramétrage SmartUI
|
||||
|
||||
**Configuration → Chargements**
|
||||
|
||||
Configurations disponibles par type de commande : unitaires, tournées, groupes, commandes fusionnées, vagues, grouper par transporteur.
|
||||
|
||||
**Modes de création :**
|
||||
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| **Automatique** | Créé à la libération. Un chargement par commande. Contrôle strict : erreur si conteneur d'une autre commande est scanné. |
|
||||
| **Non planifiée** | Créé à la libération. Pas de contrôle des conteneurs scannés. |
|
||||
| **Manuel** | Création manuelle. Contrôle strict des conteneurs. |
|
||||
|
||||
**Options supplémentaires :**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| Immatriculation du camion | Obligatoire / Non requis / En option |
|
||||
| Numéro de plomb | Obligatoire / Non requis / En option |
|
||||
| **Fermeture automatique** | Le chargement se ferme automatiquement au chargement du dernier conteneur → sortie de stock + fermeture commande |
|
||||
| **Fermeture partielle** | Permet de fermer même si tous les conteneurs ne sont pas chargés. Un chargement "reliquat" est créé automatiquement (code suffixé `_2`, `_3`...) |
|
||||
| Validation des quantités | Idem que pour le picking |
|
||||
| **Autoriser chargement de tout le stock** | Affiche un bouton TRF pour charger tout le stock libre en une seule fois |
|
||||
|
||||
---
|
||||
|
||||
## 4. Process TRF — Création de chargement
|
||||
|
||||
Il est possible de créer un chargement depuis le TRF : **Ordres de sortie → Chargement camion → Charger les conteneurs → Nouveau**.
|
||||
|
||||
> Pour désactiver cette possibilité, renseigner tous les types de commande avec une valeur autre que "Non planifiée". Si au moins un champ est à "Non planifiée", les opérateurs peuvent créer des chargements depuis le TRF.
|
||||
|
||||
---
|
||||
|
||||
## 5. Process TRF — Réalisation du chargement
|
||||
|
||||
1. Menu : **Ordres de sortie → Chargement camion → Charger les conteneurs**
|
||||
2. Filtrer par quai/poumon ou par chargement
|
||||
3. Sélectionner le chargement (statut **"Ready to load"** si toute la commande est préparée)
|
||||
4. Scanner les palettes à charger
|
||||
- Bouton **"Conteneur"** : affiche les conteneurs restants à charger
|
||||
- Bouton **"Effectuer"** : clôture le chargement même si toutes les palettes ne sont pas chargées
|
||||
|
||||
> ℹ️ Pendant le chargement, le statut passe à **"Loading"** (en rouge sur TRF).
|
||||
|
||||
---
|
||||
|
||||
## 6. Impression BL
|
||||
|
||||
Si l'impression du BL est paramétrée pour se déclencher automatiquement à la clôture de la commande, la **fermeture du chargement camion déclenche cette impression** — y compris pour un chargement partiel.
|
||||
|
||||
En cas de chargement en deux fois (reliquat) : le BL est imprimé à chaque fermeture et reprend **l'intégralité des lignes expédiées** de la commande.
|
||||
|
||||
---
|
||||
|
||||
## 7. Déchargement de camion (TRF)
|
||||
|
||||
Menu : **Décharger les conteneurs**
|
||||
|
||||
1. Scanner le conteneur à décharger
|
||||
2. Scanner l'emplacement de dépose (par défaut : le poumon de fin de préparation)
|
||||
@@ -0,0 +1,96 @@
|
||||
# Déclencheurs impressions documents et étiquettes
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000254529537)
|
||||
> Dernière mise à jour : 04/09/2023 (v4)
|
||||
|
||||
---
|
||||
|
||||
## Bon de réception
|
||||
|
||||
- Menu **Réceptions → Réception** → sélectionner une réception → **Imprimer rapport → Stock reçu**
|
||||
|
||||
---
|
||||
|
||||
## Étiquette support
|
||||
|
||||
- Menu **Entrepôt → Support** → sélectionner un support → **Imprimer étiquette**
|
||||
- Menu **Entrepôt → Stock** → sélectionner une ligne de stock → **Imprimer étiquettes de support**
|
||||
- Balise `<EnableLabelPrinting>` du fichier **ROR01** (booléen)
|
||||
- Support monoréférence → paramètre `DEFAUT_RECEPTION_LABEL_CONTAINER_REPORT_NAME` (nb copies : `NUM_COPIES_RECEPTION_LABEL`)
|
||||
- Support multiréférence → paramètre `DEFAULT_RECEPTION_LABEL_MULTIREFERENCE_CONTAINER_REPORT_NAME`
|
||||
|
||||
---
|
||||
|
||||
## Étiquette support expédition
|
||||
|
||||
- Balise `<PrpContLabels>` du fichier **SOR01** → impression automatique à la dépose sur le poumon/quai
|
||||
- Bouton **"Document printings"** de SmartUI sur le POUMON → case **"Impression automatique de l'étiquette du support du client"** (si imprimante affectée)
|
||||
- Menu **Entrepôt → Supports** → sélectionner un support d'un ordre de sortie → **Imprimer étiquettes clients**
|
||||
- Rapport imprimé : paramètre `CLIENT_CONTAINER_LABEL_REPORT`
|
||||
|
||||
---
|
||||
|
||||
## Liste de conditionnement par support
|
||||
|
||||
- Bouton **"Document printings"** de SmartUI sur le POUMON → case **"Impression automatique de la liste de colisage"**
|
||||
- Menu **Sorties → Ordres de sortie** → sélectionner la commande → **Imprimer rapport → Liste de conditionnement (par support)**
|
||||
- Menu **Entrepôt → Supports** → sélectionner un support → **Imprimer la liste de colisage**
|
||||
- Balise `<DlvPrintDocumentation>` du fichier **SOR02** (booléen, si module transporteur)
|
||||
- Rapport imprimé : paramètre `CLIENT_CONTAINER_PACKING_REPORT`
|
||||
|
||||
---
|
||||
|
||||
## Liste de conditionnement par article
|
||||
|
||||
- Paramètre `OUTBOUND_ORDER_PACKINGLIST_AUTOPRINT` à `true` → impression automatique à la fermeture de l'ordre de sortie
|
||||
- Imprimante : `OUTBOUND_ORDER_PACKINGLIST_DEFAULT_PRINTER`
|
||||
- Nb copies : `OUTBOUND_ORDER_PACKINGLIST_NUM_COPIES`
|
||||
- Nom du rapport : `OUTBOUND_ORDER_PACKINGLIST_REPORT_NAME`
|
||||
- Menu **Sorties → Ordres de sortie** → sélectionner la commande → **Imprimer rapport → Liste de conditionnement (par article)**
|
||||
|
||||
---
|
||||
|
||||
## Étiquette article
|
||||
|
||||
- Balise `<EnablePrintingItemLabel>` du fichier **ROR01** (booléen)
|
||||
- Rapport : paramètre `DEFAULT_RECEPTION_LABEL_ITEM_REPORT_NAME`
|
||||
- Menu **Données principales → Articles** → sélectionner une ligne → **Imprimer étiquette**
|
||||
|
||||
---
|
||||
|
||||
## BL (Bon de livraison)
|
||||
|
||||
- Menu **Sorties → Ordres de sortie** → sélectionner la commande → **Imprimer rapport → Note de livraison**
|
||||
- Si module transporteur : menu **Livraisons → Transporteurs/Agences** → cocher **"Imprimer bon de livraison"** → impression automatique à la clôture du colis (après appel transporteur)
|
||||
|
||||
> ⚠️ **L'impression du BL automatique n'existe pas en standard sans module transporteur !**
|
||||
> Contournement habituel : renseigner le nom du rapport BL dans le paramètre `OUTBOUND_ORDER_PACKINGLIST_REPORT_NAME` (normalement utilisé pour la liste de conditionnement par article).
|
||||
|
||||
---
|
||||
|
||||
## Étiquette transporteur *(module transporteur uniquement)*
|
||||
|
||||
- Balise `<DlvPrintLabel>` du fichier **SOR02** (booléen)
|
||||
- Menu **Livraisons → Transporteurs/Agences** → cocher **"Imprimer étiquette"** → impression automatique à la clôture du colis
|
||||
- Menu **Livraisons → Colis** → **Imprimer étiquette du colis**
|
||||
|
||||
---
|
||||
|
||||
## Feuille de transport (feuille de route)
|
||||
|
||||
- Menu **Configuration → Chargement** → champ **"Nombre d'exemplaires"** + champ **"Document de transport"** (nom du rapport)
|
||||
- Menu **Sorties → Chargements camion** → sélectionner une ligne → **Feuille de transport**
|
||||
|
||||
---
|
||||
|
||||
## Différence de liste de conditionnement
|
||||
|
||||
- Menu **Sorties → Ordres de sortie** → sélectionner la commande → **Imprimer rapport → Différence de liste de conditionnement**
|
||||
|
||||
---
|
||||
|
||||
## Étiquette emplacement
|
||||
|
||||
- Menu **Entrepôt → Emplacements**
|
||||
- Un seul emplacement : sélectionner l'emplacement → **Imprimer étiquette**
|
||||
- Plusieurs emplacements : ne sélectionner aucune ligne → **Imprimer intervalle d'emplacements**
|
||||
@@ -0,0 +1,82 @@
|
||||
# Process d'assignation de stock
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000255021069)
|
||||
> Dernière mise à jour : 11/02/2026 (v7)
|
||||
|
||||
---
|
||||
|
||||
## Concept d'assignation
|
||||
|
||||
Le process d'assignation consiste à trouver le stock valide pour une ligne de commande.
|
||||
|
||||
Chaque ligne de commande (`OutboundLine`) est associée à au moins un détail (`OutboundOrderLineDetails`). Plusieurs détails existent dans 2 cas :
|
||||
- L'article commandé est un **kit non assemblé** (les détails correspondent aux composants)
|
||||
- L'article a des **articles alternatifs** : si le WMS ne trouve pas l'article principal, il crée un nouveau détail avec l'article alternatif et passe la quantité de l'article principal à 0
|
||||
|
||||
---
|
||||
|
||||
## Le process d'assignation détaillé
|
||||
|
||||
Workflow principal : **`StockAssignProcess_AssignOutboundLine_PR`**
|
||||
|
||||
Sous-workflow par détail : **`StockAssignProcess_AssignOutboundOrderLineDetails_PR`**
|
||||
|
||||
### Étapes
|
||||
|
||||
**1. Récupération des détails**
|
||||
|
||||
Workflow : `StockAssignProcess_GetLockAndUpdateDetail_PR`
|
||||
|
||||
> Pour récupérer des données supplémentaires sur un détail, modifier le Select de la requête dans ce workflow.
|
||||
|
||||
**2. Recherche du stock**
|
||||
|
||||
Workflow : `StockAssignProcess_GetAvailableStockForOutboundOrderLineDetails_PR`
|
||||
|
||||
> Pour ajouter des filtres sur le stock assignable (ex. par CstAtt), modifier la requête **`Stocks_AssignableForProductOutboundOrderLineDetailsAndStockAssignStrategy`** en ajoutant un `where`. Les filtres seront alors visibles dans SmartUI via le bouton **"Trace d'assignations de stock"**.
|
||||
|
||||
**3. Application de la stratégie d'assignation**
|
||||
|
||||
Pour les kits, ordres de fabrication et TenseFlow : le WMS cherche en priorité le stock déjà sur la zone associée (zone de montage, zone d'approvisionnement production/TenseFlow) → Workflow `StockAssignProcess_CalculateByAssignmentManufacturingAndKits_PR`
|
||||
|
||||
Pour les détails "normaux" : application des priorités (statut préféré, UdM préférée…), puis :
|
||||
- **`Stocks_ApplyOutboundLogic_PR`** : applique la logique d'expédition (FIFO, FEFO…)
|
||||
- **`StockAssignProcess_CalculateEfficiencyMode_PR`** : applique l'efficacité
|
||||
|
||||
Stock final défini par : **`StockAssignProcess_ValidateStockList_PR`**
|
||||
|
||||
**4. Création des assignations et des tâches**
|
||||
|
||||
- **`StockAssignProcess_CreateAssignments_PR`** : crée les assignations (visibles dans SmartUI → Allocations de stock)
|
||||
- **`Outbound_StockAssignCreateOrderLineDetailsTasks_PR`** : crée les tâches selon le type d'assignation
|
||||
|
||||
---
|
||||
|
||||
## Différents types d'assignation
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| **PickingLocations** | Tâches de picking sur emplacements autorisant le picking |
|
||||
| **ReplenishmentAssignment** | Emplacement autorise le réappro + stock insuffisant au picking. Crée une tâche de picking + une tâche de réapprovisionnement en parallèle. (Réappro statique et dynamique) |
|
||||
| **ShippingContainer** | Tâches d'expédition de conteneurs. Choisi quand toute la quantité d'un article (conteneur mono-ref) est nécessaire et que l'emplacement autorise les expéditions. |
|
||||
| **PickingContainer** | Pour le TenseFlow. Crée d'abord une tâche "BufferReplenishment" vers la zone d'approvisionnement. Puis au picking virtuel, des tâches de picking virtuel sont générées. |
|
||||
|
||||
---
|
||||
|
||||
## Autres notions
|
||||
|
||||
**Gestion des Kits** : si un composant est manquant, le WMS n'assigne aucun composant du kit.
|
||||
|
||||
**Crossdocking** : si l'article autorise le crossdocking, le WMS ne réassigne pas la ligne si une réception de cet article est en attente. Il est conseillé de désactiver cette fonctionnalité si non souhaitée, en mettant en commentaire la partie correspondante dans la requête.
|
||||
|
||||
---
|
||||
|
||||
## Customs courants
|
||||
|
||||
### Générer uniquement des tâches de picking
|
||||
|
||||
Utile pour les vagues (le process par vague ne prend que les tâches de picking).
|
||||
|
||||
Modifier le workflow **`StockAssignProcess_GetStockToAssignForStrategy_PR`**.
|
||||
|
||||
Si la version du WMS possède la fonctionnalité de fusion des assignations, modifier également **`Outbound_CreatePickingLocationsTasks_PR`**.
|
||||
@@ -0,0 +1,71 @@
|
||||
# Stratégie de remplissage de canaux
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000425218370)
|
||||
> Dernière mise à jour : 25/06/2024 (v3)
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Les stratégies de remplissage de canaux permettent, comme les stratégies de rangement, la recherche d'emplacement disponible mais pour un **nombre indéfini de supports**.
|
||||
|
||||
Utilisations typiques : emplacements **push-back**, **Pallet Shuttle**, zones au sol avec nombre prédéfini de supports.
|
||||
|
||||
> ⚠️ Les stratégies de remplissage de canaux sont **vérifiées avant les stratégies de rangement classiques** → elles sont prioritaires. Bien paramétrer les critères pour éviter qu'ils soient trop génériques.
|
||||
>
|
||||
> Les stratégies de remplissage de canaux **n'ont pas de séquence** : le WMS prend la première stratégie éligible de la liste.
|
||||
|
||||
---
|
||||
|
||||
## Fonctionnement
|
||||
|
||||
1. Au scan d'un support pendant le rangement, le WMS recherche une stratégie de remplissage de canaux éligible
|
||||
2. Une recherche d'emplacement est effectuée selon les règles de la stratégie
|
||||
3. Une **réservation d'emplacement** est créée pour l'ensemble des supports concernés
|
||||
|
||||
> ℹ️ La réservation est créée **au moment du rangement** uniquement — pas de job qui réserve des emplacements en amont selon le stock existant.
|
||||
|
||||
---
|
||||
|
||||
## Paramétrage
|
||||
|
||||
### Configuration EasyS
|
||||
|
||||
Types de racks requis :
|
||||
- APS
|
||||
- Push Back
|
||||
- Dynamic Push Back
|
||||
- Multi-Compact
|
||||
|
||||
> ℹ️ Sans ces types de rack, la requête `EmptyChannels_ForContainer` ne récupère pas les emplacements disponibles.
|
||||
|
||||
Les emplacements doivent avoir un **nombre de supports autorisé** cohérent (le WMS se base sur cette donnée pour calculer la capacité).
|
||||
|
||||
### Critères de la stratégie
|
||||
|
||||
Définissent quels supports sont éligibles.
|
||||
|
||||
**⚠️ Deux champs sont OBLIGATOIRES :**
|
||||
|
||||
**Postes sources à considérer** : définit depuis quel poste source un support est éligible. Si l'équipement utilisé ne fait pas partie de cette liste, la stratégie ne s'applique pas même si le support correspond aux critères.
|
||||
|
||||
**Stations à considérer pour les supports candidats** : définit les zones tampons à prendre en compte pour calculer le nombre de supports à stocker. Exemple : si seul `RECEPTION` est renseigné, le WMS cherche les autres supports éligibles sur cet emplacement et recherche un emplacement avec assez de place pour tous les stocker.
|
||||
|
||||
### Règles de la stratégie
|
||||
|
||||
Filtrent les destinations candidates :
|
||||
- Zones de stockage triées par ordre de priorité
|
||||
- Préférences de rangement
|
||||
- Hauteur min/max à l'emplacement
|
||||
- Poids total des supports
|
||||
- **Utiliser l'équilibrage des allées** (booléen) : prend en compte la balance d'équilibrage configurée dans l'onglet des stratégies de rangement
|
||||
|
||||
**Paramétrage du temps de réservation** : durée maximale des réservations d'emplacements. Une fois le temps dépassé, les réservations disparaissent.
|
||||
|
||||
---
|
||||
|
||||
## Réservation des emplacements
|
||||
|
||||
Lors de la recherche d'emplacement, le WMS génère des réservations en fonction du nombre de supports à ranger (présents sur la station des supports candidats).
|
||||
|
||||
La vue des réservations affiche : stratégie d'origine, emplacement, article, propriétaire, **nombre de supports RESTANTS** dans la réservation, type de hauteur PLC.
|
||||
@@ -0,0 +1,70 @@
|
||||
# Utilisation des chariots à emplacement
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000428560387)
|
||||
> Dernière mise à jour : 20/03/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Les chariots à emplacement facilitent la **préparation multiple** sans création de supports individuels. Le WMS gère automatiquement l'affectation des emplacements du chariot aux commandes.
|
||||
|
||||
- Utilisable **uniquement en modes de picking multiple** : groupes de commandes et vagues
|
||||
- Peut éviter la configuration de TRF à emplacement supplémentaire
|
||||
- Une fois le picking terminé, le chariot est déposé directement en emballage
|
||||
|
||||
---
|
||||
|
||||
## Création d'un chariot
|
||||
|
||||
### 1. Création des types de divisions
|
||||
|
||||
Les divisions définissent le nombre et les codes des emplacements du chariot.
|
||||
|
||||
Menu SmartUI dédié (non précisé dans la doc — à localiser dans l'interface).
|
||||
|
||||
Il est possible de créer autant de colonnes et de rangées que souhaité (testé jusqu'à 20×20).
|
||||
|
||||
> ℹ️ Le WMS crée temporairement une séquence avec le nom de base `Section{sequence}`. Le nom saisi sera repris pour guider l'opérateur lors du picking.
|
||||
|
||||
### 2. Création du chariot et association de la division
|
||||
|
||||
Menu SmartUI : onglet **Carts**
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| Code | Code à scanner lors du picking et de l'emballage |
|
||||
| Emplacement de rangement | **OBLIGATOIRE** |
|
||||
| Type de division | Si non renseigné : 1 chariot = 1 emplacement |
|
||||
|
||||
**Statuts du chariot :**
|
||||
- **Ouvert** : disponible
|
||||
- **Fermé** : déjà occupé (stock en attente d'emballage)
|
||||
|
||||
---
|
||||
|
||||
## Picking avec chariot
|
||||
|
||||
### Sélection du chariot
|
||||
|
||||
Au démarrage d'une vague ou d'un groupe, le TRF propose d'utiliser un chariot. Scanner le code du chariot disponible.
|
||||
|
||||
Lors du premier dépôt de stock sur le chariot, le WMS propose à l'opérateur de choisir l'emplacement (division). Pour les tâches suivantes d'un même ordre, le WMS redirige automatiquement vers l'emplacement déjà utilisé.
|
||||
|
||||
La colonne **Division** affiche : `CodeChariot_CodeSection`.
|
||||
|
||||
### Cas d'erreur : chariot déjà fermé
|
||||
|
||||
Si un chariot au statut "Fermé" est sélectionné et que plus aucun emplacement n'est disponible → le WMS indique qu'aucune tâche n'est disponible et repasse le chariot à **"Ouvert"**.
|
||||
|
||||
Pour décharger le chariot : bouton **"Fermer"** dans la liste des tâches → menu TRF **Rangement → Stock de chariots** → deux options :
|
||||
- **Ranger le chariot entièrement** (le WMS ne redirige pas vers l'emballage)
|
||||
- **Décharger en mode stock libre**
|
||||
|
||||
---
|
||||
|
||||
## Emballage avec chariot
|
||||
|
||||
Lors de l'emballage, scanner le code du chariot → le WMS indique la présence de divisions.
|
||||
|
||||
Scanner la division souhaitée (ou afficher la liste des divisions avec du stock) → process standard d'emballage avec comme origine `CodeChariot_CodeSection`.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Modification de la séquence de création des SSCC
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000431902721)
|
||||
> Dernière mise à jour : 21/03/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
Il est possible de modifier le **préfixe des SSCC** créés par le WMS (en picking et en réception si le toolkit est activé) directement dans **EasyS**.
|
||||
|
||||
Utile notamment lorsque le client souhaite des codes supports respectant la norme **GS1**.
|
||||
|
||||
---
|
||||
|
||||
## Procédure
|
||||
|
||||
1. Dans EasyS, **double-cliquer sur le nom de l'entrepôt**
|
||||
2. Remplir le **préfixe souhaité** dans la case correspondante
|
||||
3. **Sauvegarder**
|
||||
@@ -0,0 +1,73 @@
|
||||
# Création d'un attribut logistique sans mode de capture
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000438095876)
|
||||
> Dernière mise à jour : 17/02/2026 (v3)
|
||||
|
||||
---
|
||||
|
||||
Cet exemple montre comment créer un profil logistique avec un numéro de série **sans mode de capture**, afin de l'auto-générer dans le code.
|
||||
|
||||
> ⚠️ Une fois configuré, il ne sera plus possible d'éditer la valeur des attributs logistiques depuis SmartUI ou un TRF sans faire de customs.
|
||||
|
||||
---
|
||||
|
||||
## Étape 1 — Création du profil logistique
|
||||
|
||||
Créer un profil logistique, puis lui ajouter un attribut logistique du type voulu.
|
||||
|
||||
> Le mode de saisie est obligatoire à la création — en mettre un **Manuel** (il sera supprimé par la suite).
|
||||
|
||||
---
|
||||
|
||||
## Étape 2 — Récupération des données
|
||||
|
||||
Récupérer les identifiants nécessaires en lançant la query suivante sur la **reading** :
|
||||
|
||||
```csharp
|
||||
Context.LogisticAttributes.Select(la => new {
|
||||
la.Name,
|
||||
la.Id,
|
||||
la.LogisticProfileId,
|
||||
la.LogisticProfileCode,
|
||||
})
|
||||
```
|
||||
|
||||
Identifier l'attribut nouvellement créé et noter :
|
||||
- **Son ID** (LogisticAttributeId)
|
||||
- **L'ID de son profil logistique** (ProfileId)
|
||||
|
||||
Puis générer un nouveau GUID via une query scalaire sur la **writing** (cocher **"Is scalar"**) :
|
||||
|
||||
```csharp
|
||||
Guid.NewGuid()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Étape 3 — Exécution de la commande
|
||||
|
||||
Lancer un **Run Command** sur `LogisticAttributeCreateLogisticCaptureCommand` avec les champs suivants :
|
||||
|
||||
| Champ | Valeur |
|
||||
|-------|--------|
|
||||
| CaptureMode | `2` |
|
||||
| CaptureProcess | `2` |
|
||||
| LogisticAttributeId | ID de l'attribut (récupéré étape 2) |
|
||||
| LogisticCaptureId | Le GUID créé (récupéré étape 2) |
|
||||
| ProfileId | ID du profil logistique (récupéré étape 2) |
|
||||
|
||||
Après exécution, le message de succès doit s'afficher.
|
||||
|
||||
---
|
||||
|
||||
## Étape 4 — Suppression du précédent mode de capture
|
||||
|
||||
L'attribut logistique possède maintenant **2 modes de capture** (le Manuel créé initialement + le nouveau vide).
|
||||
|
||||
Éditer le profil logistique et **supprimer le mode Manuel** ajouté lors de la création de l'attribut.
|
||||
|
||||
---
|
||||
|
||||
## Étape 5 — Rendu final
|
||||
|
||||
L'attribut doit toujours être présent avec une **ligne vide** dans le mode de saisie — ce qui confirme que la configuration est correcte.
|
||||
@@ -0,0 +1,87 @@
|
||||
# Split de marchandise en réception
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000520769548)
|
||||
> Dernière mise à jour : 10/03/2026 (v6)
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Chez certains clients, il est nécessaire d'éclater la marchandise réceptionnée sur deux zones pour remplir les emplacements pickings dédiés jusqu'à leur capacité, puis mettre le surplus en réserve. Cas identifiés : **ROUJE** et **NEUT**.
|
||||
|
||||
> L'exemple suivant détaille le fonctionnement chez **NEUT** (réception aveugle, fournisseur et retour client, en stock libre sur l'équipement).
|
||||
|
||||
---
|
||||
|
||||
## Logique d'implantation
|
||||
|
||||
**Principe :**
|
||||
1. La marchandise est réceptionnée sur l'équipement en stock libre
|
||||
2. Le WMS calcule la quantité nécessaire pour atteindre la capacité de l'emplacement picking dédié
|
||||
3. Cette quantité est déposée sur le **tampon PICKING**
|
||||
4. Le surplus est déposé sur le **tampon RESERVE**
|
||||
5. Un second opérateur range ensuite :
|
||||
- Le stock du tampon PICKING → vers les emplacements de picking dédiés
|
||||
- Les supports du tampon RESERVE → vers les emplacements racks à palette
|
||||
|
||||
---
|
||||
|
||||
## Paramétrage général
|
||||
|
||||
| Élément | Configuration |
|
||||
|---------|---------------|
|
||||
| **Tampon PICKING** | Mode de stockage : stock libre. Zone de stockage : RECEPTION. Zone de travail : RECEPTION. Sous-entrepôt : PICKING. |
|
||||
| **Tampon RESERVE** | Mode de stockage : conteneur et stock *(pas "Container" uniquement, sinon jamais proposé)*. Zone de stockage : RECEPTION. Zone de travail : RECEPTION. Sous-entrepôt : RESERVE. |
|
||||
| **Équipements de réception** | Type d'équipement RECEPTION. Zone de travail RECEPTION uniquement. |
|
||||
| **Zone de travail RECEPTION** | Seuls les équipements de type RECEPTION y ont accès. |
|
||||
|
||||
> ⚠️ Pour les projets avec préparation par groupes de commandes, les stations de dégroupage et les emplacements des murs ne doivent **pas** appartenir au sous-entrepôt PICKING.
|
||||
>
|
||||
> ⚠️ Bien créer les **routes** des tampons PICKING et RESERVE (groupe d'équipement + station).
|
||||
|
||||
---
|
||||
|
||||
## Stratégies de rangement
|
||||
|
||||
**4 stratégies nécessaires :**
|
||||
|
||||
**1. Réception → tampon PICKING** (pour les équipements dont le nom commence par `REC_`)
|
||||
- Critères : station d'origine = équipement de type RECEPTION
|
||||
- Règles : zone de stockage = PICKING, emplacement avec article assigné (non plein), rangement partiel autorisé
|
||||
|
||||
**2. Réception → tampon RESERVE** (pour les équipements de type RECEPTION)
|
||||
- Critères : station d'origine = équipement de type RECEPTION
|
||||
- Règles : zone de stockage = RESERVE
|
||||
|
||||
**3. Tampon PICKING → emplacements de picking dédiés** (équipements ayant accès à toutes les zones de travail)
|
||||
- Critères : station d'origine = tampon PICKING
|
||||
- Règles : article assigné, zone de stockage = PICKING
|
||||
|
||||
**4. Tampon RESERVE → emplacements racks à palette** (équipements ayant accès à toutes les zones de travail)
|
||||
- Critères : station d'origine = tampon RESERVE
|
||||
- Règles : zone de stockage = PALETTE
|
||||
|
||||
---
|
||||
|
||||
## Customs nécessaires
|
||||
|
||||
### 1. Empêcher la dépose en stock libre sur le tampon RESERVE
|
||||
|
||||
Workflows à modifier :
|
||||
- **`Equipment_Unload_ProductUnloadOnContainer_UI`** : ne pas afficher le bouton quand `location.code == "RESERVE"`
|
||||
- **`Equipment_Unload_ProductUnloadAllStockOnContainer_UI`** : idem
|
||||
|
||||
### 2. Calculer la bonne quantité à splitter lors de la réception
|
||||
|
||||
Logique après réception du stock :
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Aucun emplacement picking dédié pour l'article | Déposer sur tampon **RESERVE** |
|
||||
| Emplacement picking dédié existe et est non plein | Déposer sur tampon **PICKING** la quantité pour atteindre la capacité. Déposer le reste sur tampon **RESERVE** |
|
||||
| Emplacement picking dédié existe et est plein | Déposer sur tampon **RESERVE** |
|
||||
| Tâche de réappro en cours vers un picking dédié | Déposer sur tampon **RESERVE** |
|
||||
|
||||
> ⚠️ Sur le tampon RESERVE, le stock doit obligatoirement être déposé **sur un support** (existant ou nouveau code support).
|
||||
|
||||
> Référence JIRA de l'implémentation NEUT : [NEUT-58](https://easywmsfrance.atlassian.net/browse/NEUT-58)
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Réapprovisionnement entre 2 sous-entrepôts via une zone intermédiaire
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000720064518)
|
||||
> Dernière mise à jour : 17/10/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
## Besoin & Objectif
|
||||
|
||||
Contexte : 2 sous-entrepôts avec contrainte d'accès.
|
||||
|
||||
- **Sous-entrepôt A** (`WHST_ANCIEN_BAT`) : contient les emplacements pickings à réapprovisionner
|
||||
- **Sous-entrepôt B** (`WHST_TOUR`) : contient les emplacements réserves (en hauteur)
|
||||
- L'équipement `CACES6` (seul à accéder aux réserves en hauteur) **n'a pas le droit d'aller dans le sous-entrepôt A**
|
||||
|
||||
**Solution** : l'équipement CACES6 dépose le support sur une **zone intermédiaire**, puis un autre équipement le récupère pour effectuer le réapprovisionnement au picking.
|
||||
|
||||
---
|
||||
|
||||
## Documentation MSSCC
|
||||
|
||||
- [Exemple de config EasyS](https://msscc.mecalux.com/documentation/documentation/master/EN/configurations/replenishments/intermediate_stations.md)
|
||||
- [Explication de la configuration](https://msscc.mecalux.com/documentation/Implementation/master/ES/deployment/EasyS/configurations/IntermediateET/index.md)
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
Même dans un entrepôt 100% manuel, un élément d'automatisme de type **"Transport"** est nécessaire.
|
||||
|
||||
### Équipements
|
||||
|
||||
**2 groupes d'équipement :**
|
||||
- `EqGroup A` : équipement accédant aux emplacements pickings
|
||||
- `EqGroup B` : équipement accédant aux emplacements réserves
|
||||
|
||||
**2 types d'équipement :**
|
||||
|
||||
| Type | Accès zone de travail | Accès sous-entrepôts |
|
||||
|------|----------------------|----------------------|
|
||||
| PICKING | Zone de travail des pickings | **A et B** |
|
||||
| RESERVE | Zone de travail des réserves | **B uniquement** |
|
||||
|
||||
**Équipements créés :**
|
||||
- `PIK01` : type PICKING, groupe EqGroup A
|
||||
- `CACES06` : type RESERVE, groupe EqGroup B
|
||||
|
||||
### Configuration de l'élément "Transport"
|
||||
|
||||
- Type : **Transit**
|
||||
- Doit avoir des allées configurées
|
||||
- Le **sous-emplacement** (accessible en double-cliquant) doit être de type **"Buffer"** (⚠️ créé automatiquement en "Automatic" — le changer manuellement)
|
||||
- Le sous-entrepôt configuré sur cet emplacement doit être accessible par les 2 équipements
|
||||
|
||||
### Routes
|
||||
|
||||
| Route | Description |
|
||||
|-------|-------------|
|
||||
| Sur l'élément "Transport" | Une route vers le **sous-entrepôt A** |
|
||||
| Les 2 groupes d'équipement | Une route vers l'élément **"Transport"** |
|
||||
| EqGroup PICKING | Une route vers les **2 sous-entrepôts** |
|
||||
| EqGroup RESERVE | Une route vers le **sous-entrepôt B uniquement** |
|
||||
|
||||
> ⚠️ Les routes sont créées par défaut avec le transport "Galileo" — les modifier manuellement en **"RF"**.
|
||||
|
||||
---
|
||||
|
||||
## Fonctionnement
|
||||
|
||||
1. Au déclenchement du réapprovisionnement, une tâche est créée depuis l'emplacement réserve vers l'emplacement picking
|
||||
2. **CACES6** prend la tâche → dépose le support sur l'**emplacement intermédiaire** (tampon Buffer)
|
||||
3. **PIK01** prend la tâche dans **Tâches → Tâches de réapprovisionnement** → dépose le stock sur l'**emplacement picking de destination**
|
||||
|
||||
> Si un message d'erreur indique que "le support n'existe pas" lors du scan de l'emplacement intermédiaire, vérifier que `TRANSFERT_AUTOM_1` est bien de type **"Buffer"** et non "Automatic".
|
||||
@@ -0,0 +1,45 @@
|
||||
# Picking Manuel
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000914116618)
|
||||
> Dernière mise à jour : 21/02/2025 (v1)
|
||||
|
||||
---
|
||||
|
||||
Le picking Manuel permet de **créer une commande de sortie directement depuis le TRF**.
|
||||
|
||||
---
|
||||
|
||||
## Enchaînement des écrans
|
||||
|
||||
### 1. Informations générales de la commande
|
||||
|
||||
- Renseigner le **Code de sortie** (un code par défaut est proposé)
|
||||
- Choisir le **quai d'expédition**
|
||||
|
||||
### 2. Saisie des lignes de commandes
|
||||
|
||||
- Saisir l'**article** souhaité
|
||||
- Saisir la **quantité**
|
||||
- Répéter pour chaque ligne
|
||||
|
||||
### 3. Libérer la commande
|
||||
|
||||
Cette étape crée la commande de sortie, les lignes et les tâches de picking associées dans SmartUI.
|
||||
|
||||
> ⚠️ **Cette opération peut prendre du temps.**
|
||||
|
||||
### 4. Boucle de picking
|
||||
|
||||
Une fois la commande créée, le TRF est automatiquement redirigé vers la **phase de picking** standard.
|
||||
|
||||
---
|
||||
|
||||
## Conflits avec des modules
|
||||
|
||||
**Module 3PL** : le **nom du document** dans les fichiers SOC et SOF sont différents. Le nom du propriétaire est ajouté dans le SOF.
|
||||
|
||||
Exemple :
|
||||
- SOC : `MAN0000000000000000010`
|
||||
- SOF : `MAN0000000000000000010-CECOA`
|
||||
|
||||
**Module Transporteur** : risque de blocage car le picking manuel **ne permet pas la saisie d'un transporteur**.
|
||||
@@ -0,0 +1,115 @@
|
||||
# Fusion des commandes / Merge
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001434079279)
|
||||
> Dernière mise à jour : 31/12/2025 (v3)
|
||||
|
||||
---
|
||||
|
||||
## 1. Définition et périmètre
|
||||
|
||||
### Principe général
|
||||
|
||||
La fusion (« merge ») regroupe plusieurs **ordres de sortie** distincts en un seul ordre consolidé, pour préparer, conditionner et expédier en une seule opération.
|
||||
|
||||
> ⚠️ La fusion s'applique exclusivement aux **ordres de sortie**, pas aux livraisons (deliveries).
|
||||
|
||||
### Fusion de commande vs Fusion de livraison
|
||||
|
||||
| Aspect | Ordre de sortie | Livraison |
|
||||
|--------|----------------|-----------|
|
||||
| Définition | Commande unitaire avec lignes d'articles | Regroupement d'ordres expédiés ensemble |
|
||||
| Application de la fusion | **Oui** | Non (la livraison est le *résultat* de la fusion) |
|
||||
| Résultat de la fusion | Ordre consolidé avec toutes les lignes | Envoi physique avec les colis produits |
|
||||
|
||||
---
|
||||
|
||||
## 2. Conditions d'éligibilité
|
||||
|
||||
### Conditions obligatoires
|
||||
|
||||
- **Adresse d'expédition identique** (toutes les sous-balises de `<ShippingAddress>`)
|
||||
- **Adresse de livraison identique** (toutes les sous-balises de `<DeliveryAddress>` et `<DeliveryContact>`)
|
||||
- **Même type d'ordre** (Customer, Transfer, etc.)
|
||||
- **Statut "Waiting"**
|
||||
- **Extra Data identiques**
|
||||
|
||||
### Restrictions bloquantes
|
||||
|
||||
Un ordre ne peut pas être fusionné s'il est :
|
||||
- Déjà dans une autre fusion
|
||||
- Dans un groupement
|
||||
- Dans une vague
|
||||
- Assigné à une tournée
|
||||
|
||||
---
|
||||
|
||||
## 3. Processus de fusion
|
||||
|
||||
| Étape | Action | Initiateur |
|
||||
|-------|--------|-----------|
|
||||
| 1 | Création des commandes vers la même adresse | Client/ERP |
|
||||
| 2 | Déclenchement de la fusion via l'action **"Fusion"** | Opérateur (ou automatique si configuré) |
|
||||
| 3 | Préparation du stock (picking, colisage, chargement) | Opérateur |
|
||||
| 4 | Clôture de l'ordre fusionné → production des colis | Opérateur |
|
||||
| 5 | Génération de la livraison (delivery) | Système |
|
||||
|
||||
L'ordre fusionné possède son propre code, statut et date d'expédition — il est traité comme tout ordre standard. La **traçabilité ERP reste individualisée** par ordre d'origine.
|
||||
|
||||
---
|
||||
|
||||
## 4. Configuration technique
|
||||
|
||||
### Activation dans les fichiers SOR
|
||||
|
||||
```xml
|
||||
<Delivery>
|
||||
<DlvShareDeliveries>true</DlvShareDeliveries>
|
||||
</Delivery>
|
||||
```
|
||||
|
||||
### Paramètre système
|
||||
|
||||
**`ALLOW_MERGE_DIFFERENT_ACCOUNT`** : si activé, permet la fusion d'ordres appartenant à des comptes clients différents.
|
||||
|
||||
---
|
||||
|
||||
## 5. Prérequis et responsabilités client
|
||||
|
||||
> ⚠️ **Aucun processus automatique de fusion n'est inclus en standard.** La fusion est **manuelle** par défaut. Toute automatisation est un développement spécifique nécessitant analyse, validation et contractualisation.
|
||||
|
||||
Le client est responsable de :
|
||||
- La cohérence des données SOR (adresses, Extra Data identiques)
|
||||
- La configuration de `DlvShareDeliveries`
|
||||
- La définition des règles métier (quelles commandes fusionner)
|
||||
- Le comportement en cas d'anomalie (rupture, annulation, modification d'adresse)
|
||||
|
||||
---
|
||||
|
||||
## 6. Limitations connues
|
||||
|
||||
- Fusion possible uniquement sur des ordres au statut **"Waiting"**
|
||||
- Un ordre en cours de préparation ne peut pas être fusionné
|
||||
- La fusion **ne peut pas être annulée** une fois le picking initié
|
||||
- Les retours et SAV sont traités individuellement
|
||||
|
||||
---
|
||||
|
||||
## 7. Impacts opérationnels
|
||||
|
||||
| Aspect | Impact |
|
||||
|--------|--------|
|
||||
| Temps de picking | ✅ Optimisé (un seul passage) |
|
||||
| Temps de colisage | ⚠️ Variable (volumes importants) |
|
||||
| Temps de vérification | ⚠️ Augmenté (toutes les lignes fusionnées) |
|
||||
| Temps d'expédition | ✅ Réduit (un seul BL, un seul chargement) |
|
||||
|
||||
### Gestion des anomalies
|
||||
|
||||
| Anomalie | Comportement standard |
|
||||
|----------|----------------------|
|
||||
| Rupture de stock partielle | Fusion passe en statut **"Postponed"** jusqu'à disponibilité complète |
|
||||
| Annulation avant picking | Retrait de l'ordre de la fusion possible |
|
||||
| Annulation pendant picking | Intervention manuelle nécessaire |
|
||||
| Annulation après colisage | Décolisage requis puis re-traitement |
|
||||
| Modification d'adresse | L'ordre doit être exclu de la fusion |
|
||||
| Erreur transporteur | Stock bloqué en zone d'emballage, statut à corriger manuellement |
|
||||
@@ -0,0 +1,133 @@
|
||||
# Les poids
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001587367937)
|
||||
> Dernière mise à jour : 27/02/2026 (v3)
|
||||
|
||||
---
|
||||
|
||||
## 1. Vue d'ensemble
|
||||
|
||||
Le WMS gère plusieurs types de poids au niveau du **support (conteneur)** et des **lignes de stock**, pour contrôler la cohérence des marchandises, détecter les écarts et piloter les processus de réception, stockage et expédition.
|
||||
|
||||
---
|
||||
|
||||
## 2. Les 5 champs de poids au niveau du support
|
||||
|
||||
| Champ WMS | Nom FR | Définition | Quand mis à jour ? |
|
||||
|-----------|--------|------------|-------------------|
|
||||
| **Calculated Weight** | Poids calculé | Poids théorique (article) - ajustements (picking, etc.) | À chaque mouvement de stock |
|
||||
| **Scale Weight** | Poids balance | Poids mesuré physiquement au PIE | Au passage PIE uniquement |
|
||||
| **Theoretical Weight** | Poids théorique (article) | (Poids unitaire × quantité) + poids du support | À la création et à chaque ajustement |
|
||||
| **Real Weight** | Poids réel | `max(Calculated Weight, Theoretical Scale Weight)` | Recalculé automatiquement |
|
||||
| **Theoretical Scale Weight** | Poids théorique (balance) | Poids balance - ajustements | Après passage PIE puis à chaque ajustement |
|
||||
|
||||
> ⚠️ **Attention traduction** : "Poids théorique" est ambigu en français :
|
||||
> - **Poids théorique (article)** = Theoretical Weight (basé sur la fiche article)
|
||||
> - **Poids théorique (balance)** = Theoretical Scale Weight (basé sur la balance - ajustements)
|
||||
|
||||
### Formules de calcul
|
||||
|
||||
- **Poids théorique (article)** = poids unitaire fiche article × quantité + poids du support (défini dans EasyS)
|
||||
- **Poids balance** = valeur brute de la pesée au PIE
|
||||
- **Poids calculé** = poids théorique (article) - ajustements (picking, transferts…)
|
||||
- **Poids théorique (balance)** = poids balance - ajustements
|
||||
- **Poids réel** = `max(poids calculé, poids théorique (balance))`
|
||||
|
||||
---
|
||||
|
||||
## 3. Les poids au niveau des lignes de stock
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| **Poids (kg)** | Poids réel de la ligne |
|
||||
| **Poids théorique (kg)** | Poids théorique basé sur la fiche article |
|
||||
|
||||
Le poids des lignes est mis à jour lors des ajustements de stock, des pesées et des traitements custom **uniquement si l'article est géré en poids variable**.
|
||||
|
||||
Le PIE ne met à jour que les poids du **support**, pas directement ceux des lignes de stock.
|
||||
|
||||
---
|
||||
|
||||
## 4. Comportement à la création du stock
|
||||
|
||||
- Le **poids réel du stock** est à **0** à la création — alimenté uniquement au passage PIE, via StockAdjust, ou par custom
|
||||
- Le **poids théorique du stock** est calculé immédiatement depuis la fiche article
|
||||
- Le **poids du support** (type de palette) est **figé à la création** du conteneur → un changement ultérieur du poids dans EasyS n'a aucun effet sur les supports déjà créés
|
||||
|
||||
---
|
||||
|
||||
## 5. Le passage au PIE
|
||||
|
||||
1. La balance mesure le poids brut du support (marchandises + palette)
|
||||
2. **Scale Weight** est mis à jour avec cette valeur
|
||||
3. **Theoretical Scale Weight** est calculé : poids balance - ajustements existants
|
||||
4. **Real Weight** est recalculé : `max(Calculated Weight, Theoretical Scale Weight)`
|
||||
|
||||
> ⚠️ Le PIE n'affecte que les poids du **support**. Les lignes de stock sont mises à jour par répartition proportionnelle, pas directement par le PIE.
|
||||
|
||||
---
|
||||
|
||||
## 6. Poids variable et profil logistique
|
||||
|
||||
### Activation
|
||||
|
||||
Activer l'option **"Poids variable"** dans le **profil logistique** de l'article.
|
||||
|
||||
Lorsque le poids variable est activé, il est **obligatoire** d'indiquer le poids à la création du stock.
|
||||
|
||||
### Option "Poids moyen"
|
||||
|
||||
Permet de renseigner le poids dès la réception en se basant sur le poids de la ligne de réception.
|
||||
|
||||
Fonctionne si :
|
||||
- L'option **"poids moyen"** est activée dans le profil logistique
|
||||
- Le poids de la ligne de stock attendue est renseigné dans les **attributs logistiques** du ROR (ex. `"Weight": 20`)
|
||||
|
||||
### Limitation — StockAdjust
|
||||
|
||||
La commande **StockAdjust ne fonctionne pas** pour modifier le poids d'une ligne si l'article **n'est pas géré en poids variable** dans son profil logistique.
|
||||
|
||||
---
|
||||
|
||||
## 7. Vérification des poids à l'entrée en stock
|
||||
|
||||
Le workflow **`Stock_CheckWeightToCreateStockInContainer_UI`** vérifie le poids du stock à l'entrée :
|
||||
- Compare avec la fiche article
|
||||
- Si l'article est en poids variable et que la tolérance n'est pas respectée → génération d'une **alerte TRF**
|
||||
|
||||
---
|
||||
|
||||
## 8. Exemple de parcours complet
|
||||
|
||||
### Article standard (poids fixe) — support 25 kg, article 250 kg
|
||||
|
||||
| Étape | Calculé | Balance | Théorique (art.) | Réel | Théorique (balance) |
|
||||
|-------|---------|---------|-----------------|------|---------------------|
|
||||
| Création | 275 | 0 | 275 | 275 | 0 |
|
||||
| Passage PIE (280 kg) | 280 | 280 | 275 | 275 | 280 |
|
||||
|
||||
### Nouvelle palette (poids support EasyS modifié 25→24 kg)
|
||||
|
||||
| Étape | Calculé | Balance | Théorique (art.) | Réel | Théorique (balance) |
|
||||
|-------|---------|---------|-----------------|------|---------------------|
|
||||
| Nouvelle palette | 280 | 280 | 274 | 274 | 280 |
|
||||
|
||||
> Théorique (article) = 250 (stock) + 24 (nouveau poids palette) → confirme que le poids support est figé à la création.
|
||||
|
||||
### Article en poids variable — 10 SAC, poids 100 kg
|
||||
|
||||
| Étape | Calculé | Balance | Théorique (art.) | Réel | Théorique (balance) |
|
||||
|-------|---------|---------|-----------------|------|---------------------|
|
||||
| Création | 124 | 0 | 124 | 124 | 0 |
|
||||
| Passage PIE (107 kg) | 107 | 107 | 124 | 124 | 107 |
|
||||
|
||||
> Le PIE met à jour Scale Weight et Calculated Weight, mais le poids des lignes de stock n'est pas directement affecté.
|
||||
|
||||
---
|
||||
|
||||
## 9. Points ouverts
|
||||
|
||||
| # | Sujet | Statut |
|
||||
|---|-------|--------|
|
||||
| 1 | Workflow de rejet au PIE (similaire à `Stock_CheckWeightToCreateStockInContainer_UI` mais avec rejet plutôt qu'alerte TRF) | À confirmer |
|
||||
| 2 | Formule "poids pesé - poids théorique support (MCH)" → poids net estimé non stocké en tant que tel | À investiguer |
|
||||
@@ -0,0 +1,54 @@
|
||||
# Acronymes éléments mécaniques
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000652529673)
|
||||
> Dernière mise à jour : 10/09/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
Tableau de référence des acronymes utilisés pour les éléments mécaniques dans les installations Mecalux (Espagnol / Anglais).
|
||||
|
||||
| Acronyme | Espagnol | Anglais |
|
||||
|----------|----------|---------|
|
||||
| 2ECDF | | Double Telescopic fork with Combined Belts |
|
||||
| AP | Apilador de Paletas Vacías | Empty Pallet Stacker |
|
||||
| APC | Apilador de Paletas de Cadenas | Chain Pallet Stacker |
|
||||
| APR | Apilador de Paletas de Rodillos | Roller Pallet Stacker |
|
||||
| APS | Carro Satélite Automático / Pallet Shuttle Automático | Automatic Pallet Shuttle |
|
||||
| APS200 | Pallet Shuttle Automático (Supercondensadores) | Automatic Pallet Shuttle (SUPERCAP) |
|
||||
| ATC | Abatible Transportador de Cadenas | Lift up gate Chain Conveyor |
|
||||
| CME | | Voir tableau stations |
|
||||
| CT | Carro Transferidor | Transfer Car |
|
||||
| ECDF | | Telescopic fork |
|
||||
| EMS | Sistema electrovía aérea | Overhead electric monorail |
|
||||
| EP | Elevador Paletas | Pallet Lift |
|
||||
| EPDF | | Telescopic fork |
|
||||
| EPSF | | Telescopic fork |
|
||||
| IMS | Sistema electrovía invertida | Inverted electric monorail |
|
||||
| LBC | Transportador de Banda recto Continuo | Continuous Operation Belt Conveyor |
|
||||
| LRA | Transportador de Rodillos de Acúmulo | Buffering Roller Conveyor |
|
||||
| LRAB | Transportador de Rodillos de Acúmulo con Báscula | Scale Roller Conveyor |
|
||||
| LRC | Transportador de Rodillos recto Continuo | Continuous Operation Roller Conveyor |
|
||||
| LRD | Transportador de Rodillos Oblicuo de salida | Diverting Roller Conveyor |
|
||||
| LRI | Transportador de Rodillos Oblicua de inducción | Angle Induction Roller Conveyor |
|
||||
| LRL | Transportador de Rodillos Libres | Free Roller Conveyor |
|
||||
| LTM | Transportador Mixto | Box Transfer |
|
||||
| LZ | Lanzadera | Shuttle car |
|
||||
| ML-100 | Transelevador Monocolumna (1 caja hasta 100 kg) | Single Mast Boxes Stacker crane |
|
||||
| ML-50 | Transelevador Monocolumna (1 caja hasta 50 kg) | Single Mast Boxes Stacker crane |
|
||||
| MLB-100Q | Transelevador Bicolumna (4 cajas hasta 50 kg) | Double Mast Boxes Stacker crane |
|
||||
| MT | Transelevador Monocolumna | Single Mast Pallet stacker crane |
|
||||
| MTB | Transelevador Bicolumna | Double Mast Pallet stacker crane |
|
||||
| PIE | Puesto de identificación de Entradas | Entry Inspection Unit |
|
||||
| PK | Puesto de Picking | |
|
||||
| PS | Puesto de Salida | |
|
||||
| PSS | Pallet Shuttle Semiautomático | Semi automatic Pallet Shuttle |
|
||||
| PTL | Pick to Light / Put to Light | Pick to Light / Put to Light |
|
||||
| SGA | Sistema Gestión Almacenes | WMS |
|
||||
| STL | Sistema de Transporte Ligero | Miniload |
|
||||
| STP | Sistema de Transporte Pesado | Automated Warehouse / stacker cranes |
|
||||
| TC | Transportador de Cadenas | Chain Conveyor |
|
||||
| TG | Transportador Giratorio | Turntable conveyor |
|
||||
| TM | Transportador Mixto | Cross Transfer with Rollers and Chains |
|
||||
| TR-15 | Transportador de Rodillos (europaleta) | Roller Conveyor (europallet) |
|
||||
|
||||
> ℹ️ La liste complète (~100 acronymes) est disponible sur [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000652529673).
|
||||
@@ -0,0 +1,15 @@
|
||||
# Automation Dashboard
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001220136988)
|
||||
> Dernière mise à jour : 14/08/2025 (v2)
|
||||
|
||||
---
|
||||
|
||||
Cette page référence des documents sur le module Automation Dashboard :
|
||||
|
||||
- Présentation du module
|
||||
- Exemple de rapport de disponibilité machines
|
||||
- Exemple de rapport de disponibilité installation
|
||||
- Exemple de rapport de défauts "Galileo fault"
|
||||
|
||||
> ℹ️ Les rapports sont disponibles sous forme d'images et documents sur [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001220136988).
|
||||
@@ -0,0 +1,149 @@
|
||||
# Bases du fonctionnement robotique sur EasyWMS
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001373360137)
|
||||
> Dernière mise à jour : 27/11/2025 (v1)
|
||||
|
||||
---
|
||||
|
||||
## 1. Réceptions
|
||||
|
||||
### 1.1 Réception de supports sur une station PIE
|
||||
|
||||
La station **PIE** (Poste d'Identification et d'Entrées) introduit dans l'entrepôt automatisé des supports connus ou inconnus. Les supports portent une ou plusieurs étiquettes associées au support ou au stock.
|
||||
|
||||
**1.1.1 Identification par scanner automatique (ASN)**
|
||||
Un support notifié via ASN est introduit sur le PIE. L'étiquette est lue, le système cherche le code dans la liste ASN et décide de la destination.
|
||||
|
||||
**1.1.2 Création de supports vides**
|
||||
Configurer le PIE en mode "création de supports" dans la vue Contrôle – Stations. EasyWMS créera des supports avec les informations transmises par Galileo (code, poids, type de hauteur, etc.).
|
||||
|
||||
**1.1.3 Rejets**
|
||||
Si un contrôle physique ou informatique échoue au PIE, EasyWMS crée une tâche de rejet vers une station de rejet (retour en arrière ou mouvement vers une autre zone).
|
||||
|
||||
**1.1.4 Création de piles de palettes**
|
||||
L'utilisateur active le mode "insertion de piles de palettes" sur le pupitre Galileo. Galileo envoie l'événement avec `numéro de transport = 10`. Un code article et une quantité par pile doivent être définis dans EasyWMS.
|
||||
|
||||
### 1.2 Réception de stock sur un poste de picking
|
||||
|
||||
**1.2.1 Identification par scanner manuel (ASN)**
|
||||
Identique au PIE, sauf que l'identification est manuelle (douchette ou saisie).
|
||||
|
||||
**1.2.2 Réception d'un ordre d'entrée**
|
||||
L'opérateur réceptionne du stock lié à un ordre de réception existant et le place dans le support présent sur le poste.
|
||||
|
||||
**1.2.3 Insertion de supports vides**
|
||||
Activer les options "Insérer supports" et "Insérer supports vides" dans la vue station de travail, puis renseigner : code du support, type de support, type de division.
|
||||
|
||||
**1.2.4 Réapprovisionnement sur poste de picking**
|
||||
Deux conditions nécessaires :
|
||||
- Le stock à réapprovisionner doit exister (tables de préparation, emplacement ASN)
|
||||
- Des supports vides ou incomplets doivent être présents dans l'installation
|
||||
|
||||
Étapes :
|
||||
1. **Demande de supports** : sélectionner le stock à réapprovisionner → le système génère les tâches pour amener les supports au PK
|
||||
2. **Exécution** : les supports arrivent au PK, l'opérateur effectue le remplissage et confirme les tâches
|
||||
|
||||
---
|
||||
|
||||
## 2. Rangement
|
||||
|
||||
Dans les stations qui le permettent, EasyWMS effectue des recherches d'emplacement basées sur les **stratégies de rangement**.
|
||||
|
||||
### 2.1 Logique de rangement selon le nombre de profondeurs
|
||||
|
||||
**Racks d'1 profondeur :**
|
||||
- Hauteur ascendante (emplacements les plus petits possibles)
|
||||
- Rotation (zone adaptée à la classe de rotation)
|
||||
- Équilibrage de stock (par nombre de supports, supports avec même produit, supports en mouvement)
|
||||
|
||||
**Racks de 2 profondeurs :**
|
||||
- Hauteur ascendante + Rotation + Équilibrage
|
||||
- Mélange de produits → éviter pour limiter les relocalisations
|
||||
- Mélange d'attributs logistiques et quantités → éviter selon la logique d'expédition
|
||||
|
||||
**Racks de >2 profondeurs (APS) :**
|
||||
- Hauteur ascendante + Rotation + Équilibrage
|
||||
- Mélange de produits → **interdire** pour limiter les relocalisations
|
||||
- Mélange d'attributs → éviter si possible (utiliser le paramètre "jours de mélange" pour les dates proches)
|
||||
- **Réservation de canal** : EasyWMS analyse les ASN en attente pour choisir le type de tube adapté (ex. 6 ou 10 profondeurs)
|
||||
|
||||
### 2.2 Pourcentage d'emplacements vides
|
||||
|
||||
**Valeur standard : 5%** — nécessaire pour les relocalisations et l'absorption des variations de flux.
|
||||
|
||||
### 2.3 Exécution du rangement
|
||||
|
||||
1. Le support arrive à la station automatique → le TMS envoie un événement à EasyWMS
|
||||
2. EasyWMS vérifie que le support n'a pas déjà une tâche de rangement
|
||||
3. Récupération des stratégies de rangement valides
|
||||
4. Application des stratégies pour trouver un emplacement
|
||||
5. Si emplacement trouvé → création d'une tâche + transmission au TMS
|
||||
6. Si aucun emplacement → réservation de canal, rejet, ou attente d'action manuelle
|
||||
7. Le TMS exécute le déplacement physique
|
||||
8. En cas d'erreur de dépôt → nouvelle recherche dans la même allée ou une autre
|
||||
9. Une fois déposé → mise à jour dans EasyWMS + libération des réservations temporaires
|
||||
|
||||
---
|
||||
|
||||
## 3. Expéditions
|
||||
|
||||
### 3.1 Préparation de commandes sur un poste de picking
|
||||
|
||||
Les postes de picking extraient le stock des bacs pour préparer les commandes. Il faut associer au moins un **poste de préparation** et une **table de préparation (TP)** à la commande.
|
||||
|
||||
**3 modes de picking :**
|
||||
- **Direct/normal** : la quantité demandée est prélevée dans le support et déposée sur un support client
|
||||
- **Picking négatif** : utilisé quand la quantité demandée ≥ 60% du stock du support → on prélève l'excédent dans un nouveau support, le support original devient le support client
|
||||
- **Picking groupé** : la quantité est retirée pour plusieurs commandes simultanément
|
||||
|
||||
**Technologies d'aide :**
|
||||
- **PTT (Pick term tray)** : laser qui indique la division sur laquelle prélever/déposer
|
||||
- **PTL (Put to light)** : dispositifs avec écran/lumière/boutons sur les tables de préparation
|
||||
|
||||
Une fois toutes les tâches effectuées, le stock est déplacé vers : poste de sortie, quai/zone tampon, poste de consolidation, ou emplacement de stockage.
|
||||
|
||||
### 3.2 Expédition de supports complets
|
||||
|
||||
Quand tout le stock d'un support est assigné à une commande, l'ordre de sortie est préparé par "support complet".
|
||||
|
||||
**Gestion des postes de sortie (PS) :**
|
||||
- **Sans groupes de PS** : convoyeur utilisé indépendamment, pas de séquençage
|
||||
- **Avec groupes de PS** : plusieurs convoyeurs pour la même commande/camion, facilite le chargement
|
||||
|
||||
---
|
||||
|
||||
## 4. Gestion de l'entrepôt
|
||||
|
||||
### 4.1 Défragmentation
|
||||
|
||||
Réaménagement automatique des supports pour maintenir une disposition optimale.
|
||||
|
||||
**Deux familles :**
|
||||
- **Par rotation** : déplace les supports dans des zones de stockage inadaptées à leur classe de rotation
|
||||
- **Pour sorties** : déplace vers une zone dédiée les supports qui vont bientôt être expédiés (même ordre rangés ensemble)
|
||||
|
||||
Déclenchement : manuel ou par planificateurs de défragmentation.
|
||||
|
||||
### 4.2 Consolidation de stock rangé
|
||||
|
||||
Processus guidé pour envoyer des supports vers les postes de travail ou postes de sortie.
|
||||
|
||||
**3 types principaux :**
|
||||
1. **Sur PK avec 2 positions** : supports arrivent en ordre, l'opérateur remplit le support destination depuis les supports source
|
||||
2. **Sur PK avec 1 position + tables de préparation** : stock prélevé et déposé sur une TP puis inséré dans le dernier support
|
||||
3. **Dans une zone tampon** : ordres créés automatiquement, supports envoyés vers le PS + zone tampon, process guidé RF pour confirmer
|
||||
|
||||
### 4.3 Inventaires sur un poste de picking
|
||||
|
||||
1. Création d'un inventaire
|
||||
2. Ajout des lignes d'inventaire
|
||||
3. Lancement → tâches générées → supports envoyés au PK → comptage demandé
|
||||
|
||||
Si équipé d'un laser PTT : illumination de la division à compter.
|
||||
|
||||
### 4.4 Extractions ou relocalisations manuelles
|
||||
|
||||
Depuis la vue **Supports** :
|
||||
- **Déplacer vers PK** : sélectionner des supports et les envoyer à une station de picking
|
||||
- **Délocaliser support** : le système applique les stratégies de rangement pour choisir un nouvel emplacement
|
||||
- **Délocaliser vers l'allée/emplacement** : l'utilisateur choisit l'emplacement ou l'allée destination
|
||||
@@ -0,0 +1,659 @@
|
||||
---
|
||||
share_link: https://share.note.sx/im3nz19i#rs3hMlIlHLhx+9xZTI28Q4CRe6ja/cEnrQMbMavsUBg
|
||||
share_updated: 2026-03-03T16:05:42+01:00
|
||||
---
|
||||
# CR Consolidé — Ateliers d'interfaçage EasyWMS / SAP
|
||||
|
||||
**Projet :** Athenza (Limagrain) — Interfaçage WMS/ERP
|
||||
**Période :** 05 janvier 2026 → 23 février 2026 (7 ateliers)
|
||||
|
||||
---
|
||||
|
||||
## Table des matières
|
||||
|
||||
1. [[#1. Architecture générale et décisions structurantes]]
|
||||
2. [[#2. ITM — Fiche Article]]
|
||||
3. [[#3. ASN — Réception Production]]
|
||||
4. [[#4. ROR — Réceptions Externes et Retours Clients]]
|
||||
5. [[#5. REF — Finalisation de Réception]]
|
||||
6. [[#6. ROF — Clôture d'Ordre d'Entrée]]
|
||||
7. [[#7. SOR — Ordres de Sortie]]
|
||||
8. [[#8. RUT — Routes / Tournées Client]]
|
||||
9. [[#9. SOF — Finalisation Ordre de Sortie]]
|
||||
10. [[#10. LOF — Finalisation de Chargement]]
|
||||
11. [[#11. STV — Variation de Stock]]
|
||||
12. [[#12. STR — Demande de Changement de Stock]]
|
||||
13. [[#13. LOC — Message Périodique]]
|
||||
14. [[#14. COR / COF — Inventaire et Échantillonnage]]
|
||||
15. [[#15. WSC — Contrôle Journalier]]
|
||||
16. [[#16. Sujets transversaux]]
|
||||
17. [[#17. Flux supprimés ou non retenus]]
|
||||
18. [[#18. Synthèse de tous les messages]]
|
||||
19. [[#19. Points ouverts consolidés]]
|
||||
20. [[#20. Actions consolidées]]
|
||||
|
||||
---
|
||||
|
||||
## 1. Architecture générale et décisions structurantes
|
||||
|
||||
### 1.1 Gestion Article vs Lot — Architecture retenue
|
||||
|
||||
**Décision : Lot SAP = Article WMS (code article dans EasyWMS = code lot SAP)**
|
||||
|
||||
L'option d'une concaténation code produit + code lot SAP a été étudiée et écartée :
|
||||
|
||||
- **Avantages de l'option retenue :** Base article présente dans EasyWMS, gestion simplifiée des attributs.
|
||||
- **Inconvénients :** Changement d'article plus complexe (identifiant invariable sur le stock, nécessite suppression puis recréation), risque sur du stock en ASRS.
|
||||
|
||||
Le **code produit SAP** est géré comme un **attribut au niveau du stock** (pas de la fiche article), car un même lot SAP peut correspondre à plusieurs produits différents (ex. : changement de destination).
|
||||
|
||||
### 1.2 Relations clés
|
||||
|
||||
| Relation | Type | Statut |
|
||||
| ----------------------------------------------- | -------- | ---------------------- |
|
||||
| Lot SAP ↔ Lot Officiel | 1 pour 1 | ✅ Validé par Limagrain |
|
||||
| Code article WMS = Code lot SAP | — | ✅ Validé |
|
||||
| Code produit SAP = Attribut logistique du stock | — | ✅ Validé |
|
||||
|
||||
### 1.3 Communication API
|
||||
|
||||
|Paramètre|Valeur|
|
||||
|---|---|
|
||||
|Format|JSON|
|
||||
|Opération par défaut|3 = Upsert|
|
||||
|Mode de mise à jour|Complete = true (fiche complète à chaque envoi)|
|
||||
|Owner Code|Constante "MECALUX" (propriétaire technique)|
|
||||
|Site|WF02|
|
||||
|
||||
### 1.4 Passage aux attributs logistiques standards
|
||||
|
||||
**Changement majeur (validé le 16/02) :** Les informations initialement prévues en Custom Attributes au niveau du stock sont désormais gérées via les **attributs logistiques standards** du WMS.
|
||||
|
||||
| Donnée métier | Ancienne balise | Nouvelle balise API |
|
||||
| ---------------------- | ---------------- | ------------------- |
|
||||
| Code produit SAP | CustomAttribute1 | **Lot** |
|
||||
| Code propriétaire SAP | CustomAttribute2 | **Color** |
|
||||
| Description courte SAP | CustomAttribute3 | **Source** |
|
||||
| Pays de destination | CustomAttribute4 | **Size** |
|
||||
|
||||
Les noms de balises API ne correspondent pas aux données métier (ex. : "Color" = propriétaire SAP). Le renommage d'affichage sera fait dans le WMS.
|
||||
|
||||
### 1.5 Gestion des codes clients / fournisseurs
|
||||
|
||||
La base client/fournisseur SAP **ne sera pas interfacée** avec le WMS (trop volumineuse, non liée à un site).
|
||||
|
||||
**Solution retenue :**
|
||||
|
||||
| Flux | Champ code | Champ texte libre (Source) |
|
||||
| ----------------- | ---------------------------- | ------------------------------ |
|
||||
| ROR Fournisseur | SupplierCode = "FOURNISSEUR" | Code fournisseur SAP + libellé |
|
||||
| ROR Retour client | AccountCode = "CLIENT" | Code client SAP + libellé |
|
||||
| SOR Production | AccountCode = "PRODUCTION" | — |
|
||||
| RUT / SOR Client | AccountCode = "CLIENT" | Code client SAP + libellé |
|
||||
|
||||
### 1.6 Gestion des poids
|
||||
|
||||
|Situation|Comportement ERP|
|
||||
|---|---|
|
||||
|Article en BAG (UdM ≠ KG)|L'ERP ne s'intéresse qu'à la **quantité de sacs** ; les écarts de poids sont ignorés|
|
||||
|Article en KG|Seule la **quantité en KG** intéresse l'ERP ; si le poids change (balance), le WMS modifie la quantité|
|
||||
|
||||
Le **poids théorique** de la ligne de stock (quantité × poids unitaire, hors poids palette) sera transmis dans le ROR via les attributs logistiques (champ `Weight`).
|
||||
|
||||
---
|
||||
|
||||
## 2. ITM — Fiche Article
|
||||
|
||||
### 2.1 Unité de base selon le type d'article
|
||||
|
||||
| Type article | Description | Unité de base WMS |
|
||||
| ------------ | ----------------- | ----------------- |
|
||||
| FERT | Produit fini | BAG (sac) |
|
||||
| ZSIZ | Semi-fini calibré | KG |
|
||||
|
||||
L'unité de base dans le WMS est l'**unité logistique** (pas l'unité de base SAP). Un même produit peut exister en BAG et en KG = codes articles WMS différents.
|
||||
|
||||
### 2.2 Champs utilisés — Fiche article
|
||||
|
||||
|Champ EasyWMS|Champ SAP|Remarque|
|
||||
|---|---|---|
|
||||
|ItemCode|Code lot SAP|Clé principale|
|
||||
|Alias|Lot officiel|Relation 1:1, scannable|
|
||||
|OwnerCode|—|Constante "MECALUX"|
|
||||
|Description|Description longue|Affichage PC|
|
||||
|AltDescription|Description courte (MAKTL)|Affichage mobile, < 65 car.|
|
||||
|Type|FERT / ZSIZ / etc.|+ description du type|
|
||||
|Family|Traitement commercial|+ description|
|
||||
|BaseUoM|BAG ou KG|Selon type d'article|
|
||||
|Weight|Poids brut du sac|Poids unitaire théorique|
|
||||
|ContainerQty|Nb sacs par palette|Palette pleine standard|
|
||||
|ContainerType|Palette|Un seul type de palette|
|
||||
|
||||
### 2.3 Custom Attributes Article (ITM)
|
||||
|
||||
Les Custom Attributes de la fiche article (différents des attributs logistiques du stock) conservent les données intrinsèques au produit : espèce, génération, emballage (BigBag), GTIN, semences (vrai/faux), field production area, calibre (size), marque, et **Stage** (Custom Attribute 10, ajouté pour étiquette échantillon).
|
||||
|
||||
### 2.4 Profils logistiques (bloc Profiles dans ITM)
|
||||
|
||||
|Type d'article|Profil|Description|
|
||||
|---|---|---|
|
||||
|Articles classiques|PROFIL_STANDARD|Gestion Code produit + propriétaire + Description + Pays destination|
|
||||
|Palettes bois vides|PROFIL_PALETTE|Gestion palette bois vide|
|
||||
|
||||
### 2.5 Champs NON utilisés dans ITM
|
||||
|
||||
Stock Label, Classification ABC, Alertes stock (min/max), Image produit, Code danger (pas d'impact logistique), Températures min/max, Cross-docking, Gerbabilité (gérée via ordonnancement picking), Picking message, IsPacking.
|
||||
|
||||
### 2.6 Conversions
|
||||
|
||||
- Unité de base = BAG ou KG (pas de conversion supplémentaire identifiée pour l'instant)
|
||||
- Pas de gestion financière ni de découpage dans les sacs
|
||||
- Le nombre de sacs par palette pleine est géré dans la conversion container
|
||||
|
||||
---
|
||||
|
||||
## 3. ASN — Réception Production
|
||||
|
||||
### 3.1 Architecture
|
||||
|
||||
**1 ASN = 1 palette de production** (envoi dès création de la HU avec code SSCC). Pas d'agrégation de palettes — permet la suppression individuelle en cas d'annulation.
|
||||
|
||||
### 3.2 Attributs logistiques du stock (dans les lignes ASN)
|
||||
|
||||
|Attribut logistique|Champ SAP|Usage|
|
||||
|---|---|---|
|
||||
|LotCode|Code produit SAP|Différencie produits pour même lot SAP|
|
||||
|Color|Propriétaire réel SAP|≠ "MECALUX" technique|
|
||||
|Source|Description produit|Désignation courte SAP|
|
||||
|Size|Destination (Pays)|Peut changer|
|
||||
|
||||
### 3.3 Statuts de stock
|
||||
|
||||
Gérés dès l'ASN. Limagrain a la main directement dans le WMS pour créer et paramétrer les statuts (sacs sales, contrôle, déchirés, bloqués logistiques, etc.). Si stock OK : ne PAS envoyer de statut — envoyer champ vide ou ne pas inclure dans le JSON.
|
||||
|
||||
### 3.4 Champs NON utilisés dans ASN
|
||||
|
||||
DivisionType, ReceiptOrderCode, IsSlave, Height/Volume (recalculé au pesage PIE), attributs logistiques de dates (fabrication, expiration), numéro de série.
|
||||
|
||||
---
|
||||
|
||||
## 4. ROR — Réceptions Externes et Retours Clients
|
||||
|
||||
### 4.1 Structure
|
||||
|
||||
1 ROR = 1 livraison SAP. Un camion peut contenir plusieurs livraisons. SAP envoie les livraisons (pas les commandes d'achat).
|
||||
|
||||
### 4.2 Livraisons fournisseur (DESADV)
|
||||
|
||||
- InboundType = 0 (Fournisseur)
|
||||
- SupplierCode = "FOURNISSEUR" (en dur)
|
||||
- Source = code + libellé fournisseur SAP
|
||||
- Tolérances précisées par SAP (override le profil de réception par défaut)
|
||||
- Poids théorique transmis via attribut logistique `Weight`
|
||||
|
||||
### 4.3 Retours clients (ORDRSP)
|
||||
|
||||
| Champ | Valeur |
|
||||
| ------------------ | ------------------------------------- |
|
||||
| InboundType | 1 (Return) |
|
||||
| AccountCode | "CLIENT" (en dur) |
|
||||
| Source | Code + libellé client SAP |
|
||||
| Tolérances | Aucune (profil "illimité" par défaut) |
|
||||
| ReceiveLessAllowed | true |
|
||||
|
||||
### 4.4 Transferts inter-sites
|
||||
|
||||
- InboundType = 3 (Transfert)
|
||||
- Tolérance = 0% (palettes identifiées)
|
||||
- Le site émetteur = fournisseur dans EasyWMS
|
||||
|
||||
### 4.5 Retours avec codes lots inconnus
|
||||
|
||||
Mécanisme spécifique : SAP envoie un ROR avec codes articles génériques → scan du lot officiel sur le sac → appel API vers SAP pour vérification → si valide, stock créé avec le vrai code lot ; si invalide, stock refusé (intervention manager).
|
||||
|
||||
### 4.6 Gestion des SSCC dans le ROR
|
||||
|
||||
**Décision :** Ne pas envoyer les numéros SSCC dans le ROR. Le SSCC sera récupéré au moment du scan RFID en réception.
|
||||
|
||||
### 4.7 Paramètres clés ROR
|
||||
|
||||
- FreeQuantity : non nécessaire
|
||||
- SingleReceipt : toujours TRUE (pas de reliquat côté WMS)
|
||||
- Statut de stock : affiché à l'opérateur (informatif), pas de pop-up de modification
|
||||
|
||||
---
|
||||
|
||||
## 5. REF — Finalisation de Réception
|
||||
|
||||
### 5.1 Déclenchement
|
||||
|
||||
Envoyé à la **clôture manuelle de la réception** (action opérateur). Un seul REF par réception (pas de progressif, car SingleReceipt = true).
|
||||
|
||||
### 5.2 Contenu
|
||||
|
||||
- Le code de l'ordre d'entrée (livraison) est au niveau de la **ligne** (`LneRecOrdersPotential`), pas en en-tête
|
||||
- Le `ReceiptCode` en en-tête = code réception WMS (non utile côté SAP)
|
||||
- S'appuie sur les données **réelles** (pas théoriques)
|
||||
- **Ajout spécifique :** Zone de stockage (macro-emplacement) pour chaque palette
|
||||
- Les 4 attributs logistiques du stock sont présents + Lot SAP
|
||||
|
||||
### 5.3 Contrainte
|
||||
|
||||
L'emplacement de rangement n'est connu qu'après le stockage en ASRS → attendre que toutes les palettes soient stockées avant d'envoyer le REF.
|
||||
|
||||
---
|
||||
|
||||
## 6. ROF — Clôture d'Ordre d'Entrée
|
||||
|
||||
### 6.1 Rôle
|
||||
|
||||
Envoyé à la validation/clôture de l'ordre d'entrée. Récapitulatif de l'ensemble des stocks reçus. Signale à l'ERP que l'ordre est désormais fermé (même partiellement). Sans ROF, l'ERP ne clôturerait jamais la commande d'achat.
|
||||
|
||||
### 6.2 Adaptation Limagrain
|
||||
|
||||
Pas de gestion de reliquats par EasyWMS. Si réception incomplète, c'est SAP qui gère le reliquat. Comportement hors tolérance : ROF bloqué jusqu'à régularisation par le manager dans SAP (customisation requise).
|
||||
|
||||
---
|
||||
|
||||
## 7. SOR — Ordres de Sortie
|
||||
|
||||
### 7.1 Classification
|
||||
|
||||
|OutboundClassCode|Usage|AccountCode|
|
||||
|---|---|---|
|
||||
|PRODUCTION|Flux vers l'ancien magasin / M2I|PRODUCTION|
|
||||
|RECERTIFICATION|Flux vers postes de travail SRS|PRODUCTION|
|
||||
|CLIENT|Commandes clients|CLIENT|
|
||||
|
||||
### 7.2 Paramètres clés
|
||||
|
||||
|Paramètre|Valeur|Commentaire|
|
||||
|---|---|---|
|
||||
|OutboundType|0 (Customer)|Même pour production|
|
||||
|Priorité par défaut|3 (Basse)|Échelle : 0=Urgente → 4=Très basse|
|
||||
|AutoReleaseDate|PlannedShippingDate - 48h|Si < 48h → date passée = libération immédiate|
|
||||
|TransactionalLineList|True|Tout ou rien|
|
||||
|AllowAssignStockExcess|True|Palettes pleines, jamais de picking partiel|
|
||||
|Limite d'annulation|Statut "Chargé"|Avant = OK, après = refusé|
|
||||
|
||||
### 7.3 Gestion des ruptures (SOR Production)
|
||||
|
||||
SAP ne connaît pas la répartition stock entre ASRS et autres entrepôts. Beaucoup de lignes seront en rupture (affichage rouge = **normal et attendu**). Le WMS prépare ce qu'il peut, SAP supprime le résiduel 3-4 jours plus tard via un DELETE complet du SOR.
|
||||
|
||||
Pas de SOF en phase 1 pour la production. Détection des manquants = mode manuel.
|
||||
|
||||
### 7.4 Quai recertification
|
||||
|
||||
Pour les SOR de type recertification : `AssignedDockStationCode = "QUAI_RECERTIFICATION"` (quai fictif, renseigné par Limagrain).
|
||||
|
||||
---
|
||||
|
||||
## 8. RUT — Routes / Tournées Client
|
||||
|
||||
### 8.1 Structure
|
||||
|
||||
Un seul message contenant : **Route → SorList → Lignes**. Pas de fichiers RUT + SOR séparés.
|
||||
|
||||
### 8.2 En-tête Route
|
||||
|
||||
|Paramètre|Valeur|
|
||||
|---|---|
|
||||
|Code|Code transport SAP|
|
||||
|Priority|3 (Basse)|
|
||||
|EstimatedLoadDate|Date RDV camion sur site (UTC)|
|
||||
|AutoReleaseDate|EstimatedLoadDate - 48h|
|
||||
|TransactionalSorList|true (refus total si un SOR en erreur)|
|
||||
|CompleteSorList|true (SOR absents = supprimés)|
|
||||
|IgnoreNulls|false|
|
||||
|
||||
### 8.3 Commandes clients dans la Route (SorList)
|
||||
|
||||
|Paramètre|Valeur|
|
||||
|---|---|
|
||||
|OutboundType|0 (Customer)|
|
||||
|AccountCode|"CLIENT"|
|
||||
|OutboundClassCode|"CLIENT"|
|
||||
|Source|Code client SAP + Libellé|
|
||||
|StopNumber|Numéro d'arrêt de livraison (⚠️ à confirmer : livraison vs chargement)|
|
||||
|TransactionalLineList|true|
|
||||
|CompleteLineList|true|
|
||||
|OwnerCode|"MECALUX"|
|
||||
|
||||
### 8.4 Lignes de commande
|
||||
|
||||
- ProductCode = Code lot SAP
|
||||
- AllowAssignStockExcess = true (forcé)
|
||||
- RequiredToShip / IsCritical = true **seulement** si flag "complete delivery" coché dans SAP, sinon false
|
||||
- Attributs logistiques : LotCode (code produit SAP), Color (propriétaire SAP), Source (description), Size (pays destination)
|
||||
|
||||
### 8.5 Dates
|
||||
|
||||
EstimatedLoadDate et PlannedShippingDate contiendront la même valeur (chargement juste avant départ). Mecalux confirme que c'est accepté.
|
||||
|
||||
---
|
||||
|
||||
## 9. SOF — Finalisation Ordre de Sortie
|
||||
|
||||
### 9.1 Déclenchement
|
||||
|
||||
Automatiquement (commande préparée à 100%) ou manuellement (clic opérateur). Envoi multiple possible en cas d'expédition partielle.
|
||||
|
||||
### 9.2 Champs clés retournés
|
||||
|
||||
|Champ|Description|
|
||||
|---|---|
|
||||
|SorCode|Code ordre de sortie|
|
||||
|Status|Closed / Cancelled|
|
||||
|LneContCode|Code palette expédiée (HU)|
|
||||
|LneItemCode|Code article|
|
||||
|ShippedQuantity|Quantité réellement expédiée|
|
||||
|Attributs logistiques|Code produit SAP, Lot SAP, etc.|
|
||||
|
||||
### 9.3 Statut
|
||||
|
||||
- **Closed** = stock réellement expédié, supprimé du WMS
|
||||
- **Cancelled** = commande annulée, ShippedQuantity = 0 sur les lignes non expédiées
|
||||
|
||||
Activation possible via paramétrage WMS. Démarrage possible sans SOF, activation ultérieure si nécessaire. Utile potentiellement pour déclencher la création de HU dans MII.
|
||||
|
||||
---
|
||||
|
||||
## 10. LOF — Finalisation de Chargement
|
||||
|
||||
### 10.1 Contenu
|
||||
|
||||
État des lieux du chargement réel du camion. Ne contient **que les HU effectivement chargées**. Pas de ligne à 0 ni d'alerte pour les palettes non chargées. Peut regrouper plusieurs SOR/commandes.
|
||||
|
||||
### 10.2 Articulation LOF / SOF
|
||||
|
||||
|Message|Contenu|Granularité|
|
||||
|---|---|---|
|
||||
|SOF|Ce qui a été expédié par commande|Par ordre de sortie|
|
||||
|LOF|HU réellement chargées dans un camion|Par chargement|
|
||||
|
||||
### 10.3 Structure des conteneurs
|
||||
|
||||
Arborescence imbriquée : Palette support (IsSlave=TRUE) → Palette fille (IsSlave=FALSE) → Lignes de stock avec attributs logistiques.
|
||||
|
||||
Cas des supports remontés M2I : Palette US (IsSlave=TRUE) → Séparateur 1 (IsSlave=FALSE, avec stock) → Séparateur 2 (IsSlave=FALSE, avec stock).
|
||||
|
||||
---
|
||||
|
||||
## 11. STV — Variation de Stock
|
||||
|
||||
### 11.1 Principe
|
||||
|
||||
Message WMS → SAP pour notifier les ajustements de quantités manuels (hors flux standards réception/expédition).
|
||||
|
||||
### 11.2 Mapping clé
|
||||
|
||||
|Balise|Utilisation|
|
||||
|---|---|
|
||||
|Operation|C (positif) / D (négatif)|
|
||||
|Site|WF02|
|
||||
|ItemCode|Code lot SAP|
|
||||
|OwnerCode|MECALUX|
|
||||
|ContainerCode|Numéro HU|
|
||||
|FilterAttributes|Attributs du stock existant modifié|
|
||||
|Attributes|Attributs du stock nouvellement créé|
|
||||
|ReasonCode|AJUSTEMENT MANUEL|
|
||||
|ERPReasonCode|ZSC1|
|
||||
|Comment|Facultatif (opérateur)|
|
||||
|
||||
### 11.3 Point ouvert
|
||||
|
||||
Limagrain doit définir comment gérer côté ERP un STV de type "création de stock" (l'ERP n'autorise pas la création de stock par ce biais aujourd'hui).
|
||||
|
||||
---
|
||||
|
||||
## 12. STR — Demande de Changement de Stock
|
||||
|
||||
### 12.1 Cas d'usage
|
||||
|
||||
L'ERP envoie un STR pour : changement de code article (produit SAP + description), changement de propriétaire, blocage/déblocage de lot.
|
||||
|
||||
### 12.2 Règles
|
||||
|
||||
- **Accepté** si la palette n'est pas assignée à une commande ou en cours de mouvement
|
||||
- **Refusé** si palette "client" ou en préparation (code erreur API explicite)
|
||||
- Ajustement de stock avec **motif "STR"** → le middleware (GNA) ne traite pas les STV avec ce motif pour éviter les doublons
|
||||
|
||||
Limagrain mettra en place un **monitoring des erreurs** pour les cas de refus.
|
||||
|
||||
---
|
||||
|
||||
## 13. LOC — Message Périodique
|
||||
|
||||
### 13.1 Principe
|
||||
|
||||
Message delta envoyé **toutes les 5 minutes** contenant les HU modifiées durant la période. Remplace les messages PCK et MOVE (supprimés).
|
||||
|
||||
### 13.2 Couverture
|
||||
|
||||
Palettes déplacées, nouvellement créées, supprimées, assignées à un OS, ajustements de quantité/poids.
|
||||
|
||||
### 13.3 Codes ACTION
|
||||
|
||||
|Code|Signification|
|
||||
|---|---|
|
||||
|B|Déplacement d'une HU|
|
||||
|U|Déblocage de statut|
|
||||
|R|Blocage de statut|
|
||||
|S|Suppression / scrap|
|
||||
|T|Transfert de stock entre HU|
|
||||
|C|Correction de quantité (poids)|
|
||||
|
||||
### 13.4 Format JSON attendu par Limagrain
|
||||
|
||||
Structure avec les balises : IV_LGNUM (WL02), IV_TREATMENT_ID (horodatage), et pour chaque ligne : MATNR, BATCHID, ACTION, ANFME, ALTME, VLPLA, NLPLA, VLENR, NLENR, REASON (ZSC1).
|
||||
|
||||
### 13.5 ⚠️ Point ouvert majeur — Doublons STV/LOC
|
||||
|
||||
Lors d'un transfert palette A → palette B, le LOC envoie deux lignes sans lien entre elles → risque de deux mouvements d'inventaire fictifs côté ERP au lieu d'un transfert. De plus, les ajustements d'inventaire apparaîtront aussi dans le LOC si la palette a été modifiée dans les 5 dernières minutes → risque de doublon avec le STV.
|
||||
|
||||
**Mecalux étudie :** ajout de la palette précédente dans le LOC pour les actions T, et possibilité d'exclure du LOC les mouvements déjà couverts par un STV.
|
||||
|
||||
---
|
||||
|
||||
## 14. COR / COF — Inventaire et Échantillonnage
|
||||
|
||||
### 14.1 COR — Demande d'échantillonnage
|
||||
|
||||
Utilisé **uniquement pour les demandes d'échantillonnage** (pas pour les inventaires physiques classiques, gérés dans EasyWMS en phase 1).
|
||||
|
||||
|Balise|Valeur|
|
||||
|---|---|
|
||||
|Description|"ECHANTILLONNAGE" (en dur, discriminant WMS)|
|
||||
|Code|Numéro du lot d'inspection SAP|
|
||||
|Priority|3 (basse)|
|
||||
|ProductCode|Code lot SAP|
|
||||
|LotCode|Code produit SAP|
|
||||
|+ Color, Source, Size|Attributs logistiques standards|
|
||||
|
||||
Flux : COR envoyé → WMS fait venir la palette sur un poste de travail → opérateur prélève → palette repart en stockage → COF envoyé.
|
||||
|
||||
Un article en cours d'échantillonnage n'est **pas disponible** pour les ordres de sortie.
|
||||
|
||||
### 14.2 COF — Confirmation d'échantillonnage
|
||||
|
||||
|Balise|Description|
|
||||
|---|---|
|
||||
|CountCode|Numéro du lot d'inspection|
|
||||
|Status|Closed (effectué) ou Cancelled (annulé)|
|
||||
|UpdateDate|Date/heure de changement|
|
||||
|
||||
**Point ouvert :** Limagrain doit confirmer si le COF sera traité côté ERP. Si non traité, risque de demandes en double.
|
||||
|
||||
---
|
||||
|
||||
## 15. WSC — Contrôle Journalier
|
||||
|
||||
Image de stock complète pour vérification de cohérence. Contient l'ensemble du stock : code OS, statut palette, toutes les informations disponibles.
|
||||
|
||||
**Démarrage :** Export manuel EasyWMS + export SAP + comparaison. **Automatisation possible** ultérieurement (quotidien à heure fixe).
|
||||
|
||||
**Point d'attention :** Limagrain doit vérifier sa capacité à traiter ce fichier (volumétrie potentiellement élevée pour CPI).
|
||||
|
||||
---
|
||||
|
||||
## 16. Sujets transversaux
|
||||
|
||||
### 16.1 Types de supports
|
||||
|
||||
|Type|Usage|Statut|
|
||||
|---|---|---|
|
||||
|EWM-PAL00 / PALETTE_US|Palette standard (un seul type)|✅ Confirmé|
|
||||
|BIGBAG|Attribut de la HU (pas type séparé)|✅ Validé|
|
||||
|Octobin|Hors périmètre phase 1|❌|
|
||||
|
||||
La création de types de supports est techniquement lourde (nécessite passage par support Mecalux, impact design entrepôt).
|
||||
|
||||
Les BigBag sont déclarés par l'opérateur au poste de réception. Le WMS ajuste le calcul de poids (+2 kg environ).
|
||||
|
||||
### 16.2 Z-Bags (sacs vides)
|
||||
|
||||
**Décision :** Stockés dans le magasin automatique (SRS) **uniquement pour livraison aux clients**, pas pour l'approvisionnement production. Doivent respecter les mêmes formats et règles que les palettes produits. → À valider fonctionnellement.
|
||||
|
||||
### 16.3 Marque
|
||||
|
||||
Récupéré dans la fiche article mais **aucune règle de gestion appliquée pour l'instant** côté WMS. Règle de non-mélange sur palette à confirmer par Limagrain.
|
||||
|
||||
### 16.4 Étiquettes
|
||||
|
||||
Point dédié à planifier avec Antoine. Objectif : aligner ce qui est imprimé côté WMS vs SAP. L'étiquette échantillon nécessite le champ **Stage** (ajouté en Custom Attribute 10 dans ITM).
|
||||
|
||||
### 16.5 Outils de développement
|
||||
|
||||
| Outil | Description | Statut |
|
||||
| -------------------- | -------------------------------- | -------- |
|
||||
| ERP Tester | Mock serveur WMS pour tests API | ✅ Envoyé |
|
||||
| Base de test Mecalux | Base SaaS pour tests réels | En cours |
|
||||
| Documentation API | PDF complet + JSON + env Postman | ✅ Envoyé |
|
||||
|
||||
### 16.6 Absence Arthur — Mars 2026
|
||||
|
||||
Arthur sera absent durant le mois de mars. Les ateliers ERP sont terminés. Justine reste le point d'entrée principal.
|
||||
|
||||
---
|
||||
|
||||
## 17. Flux supprimés ou non retenus
|
||||
|
||||
|Flux|Statut|Raison|
|
||||
|---|---|---|
|
||||
|MOV|**Supprimé**|Redondant avec LOC + STR combinés|
|
||||
|PCK|**Remplacé** par LOC|Le LOC périodique couvre le besoin|
|
||||
|ACC/SUP|**Non transmis** par l'ERP|Base client/fournisseur non interfacée|
|
||||
|ROC|**Non utilisé** a priori|À confirmer côté Limagrain|
|
||||
|
||||
---
|
||||
|
||||
## 18. Synthèse de tous les messages
|
||||
|
||||
### SAP → EasyWMS (Flux entrants)
|
||||
|
||||
|Message|Description|Statut|
|
||||
|---|---|---|
|
||||
|**ITM**|Fiche Article (Lot SAP)|✅ Validé|
|
||||
|**ASN**|Réception Production (1 par palette)|✅ Validé|
|
||||
|**ROR**|Réceptions Externes + Retours Clients|✅ Validé|
|
||||
|**SOR**|Ordres de Sortie (Prod/Recertif)|✅ Validé|
|
||||
|**RUT**|Routes / Tournées Client|✅ Validé|
|
||||
|**COR**|Demande d'Échantillonnage|✅ Validé|
|
||||
|**STR**|Demande de Changement de Stock|✅ Validé|
|
||||
|
||||
### EasyWMS → SAP (Flux sortants)
|
||||
|
||||
|Message|Description|Statut|
|
||||
|---|---|---|
|
||||
|**REF**|Finalisation de Réception|✅ Validé (+ ajout zone de stockage)|
|
||||
|**ROF**|Clôture d'Ordre d'Entrée|✅ Validé|
|
||||
|**SOF**|Finalisation Ordre de Sortie|🟡 Phase 2 possible|
|
||||
|**LOF**|Finalisation de Chargement|✅ Validé|
|
||||
|**STV**|Variation de Stock|✅ Validé|
|
||||
|**STC**|Changement de Statut de Stock|🟡 À traiter|
|
||||
|**COF**|Confirmation d'Échantillonnage|🟡 Traitement à confirmer|
|
||||
|**LOC**|Message Périodique (delta 5 min)|✅ Validé (remplace PCK + MOV)|
|
||||
|**WSC**|Image de Stock Journalière|🟡 Volumétrie à vérifier|
|
||||
|
||||
---
|
||||
|
||||
## 19. Points ouverts consolidés
|
||||
|
||||
| # | Sujet | Responsable | Statut |
|
||||
| --- | ------------------------------------------------------------------------------------------------- | ------------------- | ------------ |
|
||||
| 1 | Gestion des transferts (Action T) dans le LOC et priorisation STV vs LOC pour éviter les doublons | Mecalux | 🔴 Ouvert |
|
||||
| 2 | Création de stock via STV : traitement côté ERP quand le WMS crée du stock de zéro | Limagrain | 🔴 Ouvert |
|
||||
| 3 | StopNumber (RUT) : vérifier que SAP envoie un numéro d'arrêt de livraison (pas de chargement) | Limagrain | 🔴 Ouvert |
|
||||
| 4 | Numéro de ligne SOF/LOF : confirmer le nombre de caractères du numéro de ligne SAP (padLeft "0") | Limagrain | 🔴 Ouvert |
|
||||
| 5 | Confirmer si le COF sera traité côté ERP | Limagrain | 🔴 Ouvert |
|
||||
| 6 | Confirmer la règle de mélange des marques sur palette | Limagrain | 🔴 Ouvert |
|
||||
| 7 | Fournir la plage GS1 SSCC | Limagrain | 🔴 Ouvert |
|
||||
| 8 | Planifier un atelier étiquettes avec Antoine | Limagrain / Mecalux | 🔴 Ouvert |
|
||||
| 9 | Ajouter Stage en Custom Attribute 10 dans ITM | Limagrain / Mecalux | 🔴 Ouvert |
|
||||
| 10 | Confirmer le stockage des Z-Bags dans l'ASRS (format palettes respecté ?) | Limagrain / Mecalux | 🟡 À valider |
|
||||
| 11 | Vérifier la capacité de traitement du WSC quotidien (volumétrie) | Limagrain | 🔴 Ouvert |
|
||||
| 12 | Retour fournisseur : confirmer si ce flux est utilisé. Si oui, SOR simple ou RUT ? | Limagrain | 🔴 Ouvert |
|
||||
| 13 | Clarifier comportement lot officiel lors changement de destination | Limagrain | 🔴 Ouvert |
|
||||
| 14 | Fournir liste complète des statuts de stock avec descriptions | Limagrain | 🔴 Ouvert |
|
||||
| 15 | Vérifier le traitement interne du LOF (absence de ligne = non expédié) | Limagrain | 🔴 Ouvert |
|
||||
| 16 | EstimatedNumCont : vérifier disponibilité dans SAP pour chaque commande client (ROR) | Limagrain | 🔴 Ouvert |
|
||||
|
||||
---
|
||||
|
||||
## 20. Actions consolidées
|
||||
|
||||
### Actions Mecalux (Arthur / Justine)
|
||||
|
||||
| Action | Statut |
|
||||
| ---------------------------------------------------------------------- | -------------- |
|
||||
| Mise à jour fichier Excel SharePoint ITM avec mapping final | ✅ Fait |
|
||||
| Fourniture exemple JSON complet et exhaustif ITM | ✅ Fait (12/02) |
|
||||
| Envoi lien ERP Tester + documentation utilisateur | ✅ Fait |
|
||||
| Envoi documentation API complète | ✅ Fait |
|
||||
| Étudier les champs Profiles ITM | ✅ Fait (12/02) |
|
||||
| Mise à jour fichier Excel ASN avec mapping validé | ✅ Fait |
|
||||
| Mise à jour fichier Excel SOR avec mapping validé | ✅ Fait |
|
||||
| Confirmer gestion numéro de ligne (0001 vs 1) | ✅ Fait (19/02) |
|
||||
| Fournir fichiers Excel ROR + REF + SOR + SOF mis à jour | ✅ Fait |
|
||||
| Fournir exemples JSON exhaustifs ASN | ⏳ Prévu 26/02 |
|
||||
| Fournir exemple JSON LOF (classique + supports remontés) | 🔴 À faire |
|
||||
| Fournir exemple WSC pour évaluation volumétrie | 🔴 À faire |
|
||||
| Ajouter zone de stockage dans le REF | 🔴 À faire |
|
||||
| Valider template JSON LOC avant développement | 🔴 À faire |
|
||||
| Étudier gestion transferts LOC et priorisation STV/LOC | 🔴 À faire |
|
||||
| Vérifier fonctionnement ExceedPercentageAllowed vs Profil de réception | 🔴 À faire |
|
||||
| Définir les codes erreur et motifs de refus pour STR | 🔴 À faire |
|
||||
| Définir le cadencement REF/ROF (custom) | 🔴 À faire |
|
||||
|
||||
### Actions Limagrain
|
||||
|
||||
| Action | Statut |
|
||||
| -------------------------------------------------------------------------------- | ------------ |
|
||||
| Valider si combo lot SAP/Officiel peut être partagé par plusieurs codes produits | ✅ Fait |
|
||||
| Confirmer délai 48h pour auto-release | ✅ Fait |
|
||||
| Clarifier comportement lot officiel lors changement destination | 🔴 À faire |
|
||||
| Fournir plage GS1 pour SSCC | 🔴 À faire |
|
||||
| Fournir dénomination exacte type palette par défaut | 🔴 À faire |
|
||||
| Fournir liste complète statuts de stock avec descriptions | 🔴 À faire |
|
||||
| Valider gestion Z-Bags - Stockage ASRS | 🟡 À valider |
|
||||
| Valider besoin champ Marque avec commerce | 🔴 À faire |
|
||||
| Fournir template JSON pour le LOC | 🔴 À faire |
|
||||
| Vérifier capacité de traitement du WSC quotidien | 🔴 À faire |
|
||||
| Mettre en place monitoring des erreurs STR | 🔴 À faire |
|
||||
| Tester intégration SOF pour création HU dans MII | 🔴 À faire |
|
||||
| Définir traitement ERP pour STV type "création de stock" | 🔴 À faire |
|
||||
| Confirmer StopNumber (livraison vs chargement) | 🔴 À faire |
|
||||
| Confirmer nombre de caractères numéro de ligne SAP | 🔴 À faire |
|
||||
| Confirmer traitement COF côté ERP | 🔴 À faire |
|
||||
| Confirmer retour fournisseur (SOR ou RUT) | 🔴 À faire |
|
||||
| Planifier atelier étiquettes avec Antoine | 🔴 À faire |
|
||||
|
||||
---
|
||||
|
||||
## Annexe — Liens utiles
|
||||
|
||||
- **Fichier Excels Limagrain (SharePoint)** : https://fromearthtolife.sharepoint.com/:x:/r/teams/LPH-PROJ-Athenza_IS/_layouts/15/Doc.aspx?sourcedoc=%7B0B6511B6-3B81-4D9D-86CA-FA27D3D4C0D0%7D&file=mapping%20easy%20sap.xlsx&action=default&mobileredirect=true
|
||||
|
||||
---
|
||||
|
||||
_Document consolidé le 23 février 2026 — basé sur les ateliers des 05/01, 26/01, 27/01, 29/01, 02/02, 16/02 et 23/02/2026_
|
||||
+935
@@ -0,0 +1,935 @@
|
||||
---
|
||||
share_link: https://share.note.sx/ziuyd353#P//B0nvVix4HFcZp0NAOVtbR3EXhPIYEtuv1VDkKkV4
|
||||
share_updated: 2026-04-30T09:33:12+02:00
|
||||
cssclasses:
|
||||
- full-width
|
||||
---
|
||||
# CR technique — iGO STILL : fonctionnement et flux API + correspondance avec le module AGV EasyWMS
|
||||
|
||||
> Compte-rendu technique simplifié du fleet manager **iGO easy** (alias **PACS Host API** côté KION/STILL) à partir des documents fournis dans le dossier STILL, suivi d'une table de correspondance complète avec le **module AGV EasyWMS** (cf. `CR_ModuleAGV.md`).
|
||||
>
|
||||
> Public : développeurs EasyWMS / intégration robotique. Date : 2026-04-28. Sources :
|
||||
>
|
||||
> - `2510_PACS-2.3-Host-Interface-Technical-Specifications_en-US--STILL-.pdf` (référence API la plus récente, 10/2025)
|
||||
> - `iGo easy 2.3 - Host Interface Specifications.pdf` (variante iGO easy — API identique au PACS 2.3)
|
||||
> - `IT requirements R1 20250929.pdf` (environnement MyMA — frontend Vue3 + backend .NET 8 + Postgres)
|
||||
> - `Technical specification EXV CB iGo.pdf` (datasheet véhicule — gerbeur EXV CB iGo)
|
||||
> - `Limagrain-LWM_Std_Interface_Compliance.xlsx` (matrice de compliance — _non lu automatiquement, format binaire ; sera abordé manuellement avec l'équipe Limagrain_)
|
||||
|
||||
---
|
||||
|
||||
## Sommaire
|
||||
|
||||
1. [Vue d'ensemble iGO / PACS](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#1-vue-densemble-igo--pacs)
|
||||
2. [Stack technique et déploiement](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#2-stack-technique-et-d%C3%A9ploiement)
|
||||
3. [Modèle de ressources](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#3-mod%C3%A8le-de-ressources)
|
||||
4. [Flux API principaux](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#4-flux-api-principaux)
|
||||
5. [Cycle de vie d'un Transport](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#5-cycle-de-vie-dun-transport)
|
||||
6. [Sécurité et abonnements aux events](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#6-s%C3%A9curit%C3%A9-et-abonnements-aux-events)
|
||||
7. [Table de correspondance EasyWMS AGV ↔ iGO](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#7-table-de-correspondance-easywms-agv--igo)
|
||||
8. [Points d'attention pour l'intégration](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#8-points-dattention-pour-lint%C3%A9gration)
|
||||
9. [FAQ STILL — réponses officielles](https://claude.ai/local_sessions/local_5e652410-ce93-46d4-bb6d-ec829a64d798#9-faq-still--r%C3%A9ponses-officielles)
|
||||
|
||||
---
|
||||
|
||||
## 1. Vue d'ensemble iGO / PACS
|
||||
|
||||
**iGO easy** (et son grand frère **PACS** — _Productized Automated Concept Solutions_) est le **fleet manager AGV** de KION Group / STILL. Le moteur sous-jacent s'appelle `E'tricc` (visible dans la phrase de la doc PACS « _all transports that are still in the memory of E'tricc_ »). Les deux versions exposent **strictement la même API REST** en version 2.3 — le PACS est l'offre commerciale large, iGO easy est la déclinaison « _easy_ » destinée à des installations plus simples.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph WMS["Hôte (WMS / WES / ERP)"]
|
||||
direction TB
|
||||
EasyWMS["EasyWMS"]
|
||||
end
|
||||
|
||||
subgraph FleetMgr["iGO easy / PACS Fleet Manager"]
|
||||
direction TB
|
||||
Etricc["Moteur E'tricc"]
|
||||
MyMA["MyMA - admin UI<br/>Vue3 + .NET8 + Postgres"]
|
||||
Etricc <--> MyMA
|
||||
end
|
||||
|
||||
subgraph Fleet["Flotte AGV"]
|
||||
EXV["EXV CB iGo<br/>(gerbeur ~3.4m)"]
|
||||
Other["...autres modèles STILL"]
|
||||
end
|
||||
|
||||
EasyWMS <-->|"HTTPS REST<br/>port 7002<br/>TLS 1.2 + Bearer"| Etricc
|
||||
Etricc -.->|"callback POST<br/>vers WMS"| EasyWMS
|
||||
Etricc <--> Fleet
|
||||
```
|
||||
|
||||
**Concepts clés à retenir :**
|
||||
|
||||
- **Pas de PLC, pas de tables d'échange SQL** côté hôte. Tout passe par REST sur HTTPS.
|
||||
- **Modèle pull + push** : le WMS _pousse_ les ordres (POST /transports) ; iGO _pousse_ les changements d'état via webhook (callback vers une URL exposée par le WMS).
|
||||
- **Pas de notion de routes/segments** côté WMS : iGO ne demande qu'une `sourceLocation` et une `destinationLocation`. La trajectoire physique entre les deux est entièrement gérée par iGO.
|
||||
- **Décision tardive (group / decision point)** : si on ne sait pas encore _où exactement_ charger ou décharger au moment de la création du transport, on peut donner un `sourceGroupId` / `destinationGroupId`. iGO place alors le transport en `RequestSource` / `RequestDestination` et **interroge** le WMS au moment où l'AGV arrive au point de décision.
|
||||
- **Charge utile (Load)** = container EasyWMS. Existe comme ressource indépendante (catalogue) avec dimensions et type.
|
||||
|
||||
---
|
||||
|
||||
## 2. Stack technique et déploiement
|
||||
|
||||
### 2.1 Environnement (MyMA)
|
||||
|
||||
D'après `IT requirements R1` :
|
||||
|
||||
|Composant|Détail|
|
||||
|---|---|
|
||||
|Backend|.NET 8.0 (C#)|
|
||||
|Frontend|Vue 3.2|
|
||||
|Base de données|**Postgres 12+** par défaut, SQL Server 2019 ou MySQL 8.0 supportés|
|
||||
|OS serveur|Windows 11 Pro/Ent, Windows Server 2016/2019/2022, Ubuntu 18.04|
|
||||
|Navigateurs admin|Edge, Chrome, Firefox|
|
||||
|Hardware (low)|4 cores @2.26 GHz, 8 Go RAM, 500 Go RAID5, dual PSU|
|
||||
|Hardware (high)|8 cores, 16 Go RAM, 1 To, dual PSU|
|
||||
|
||||
### 2.2 Ports réseau
|
||||
|
||||
|Service|Port|
|
||||
|---|---|
|
||||
|Front-end web (admin MyMA)|**82**|
|
||||
|Backend (REST interne)|**50005**|
|
||||
|API Host vers WMS (HTTPS REST)|**7002**|
|
||||
|Postgres|**5432**|
|
||||
|
||||
### 2.3 Wifi (pour terminaux opérateur si présents)
|
||||
|
||||
Signal min `-70 dBm`, SNR min `20 dB`, débit min `24 Mbps`, ping moyen `≤ 50 ms`.
|
||||
|
||||
### 2.4 Véhicule type — STILL EXV CB iGo
|
||||
|
||||
|Caractéristique|Valeur|
|
||||
|---|---|
|
||||
|Longueur totale (l1)|3 383 mm|
|
||||
|Longueur jusqu'au dosseret (l2)|2 083 mm|
|
||||
|Largeur tablier fourche (b3 / b1 / b2)|1 000 / 920 / 1 109 mm|
|
||||
|Fourche (s / e / l)|50 / 100 / **1 300 mm**|
|
||||
|Hauteur véhicule (arche / mât)|2 447 / 2 015 mm|
|
||||
|
||||
> Le véhicule est un **gerbeur électrique automatisé** (EXV = Elektro-Vertikal) — il se déplace sur ses propres roues et lève la charge avec le mât. Il n'a pas de notion de couloir mécanique ni de canal compact à l'instar d'un Pallet Shuttle.
|
||||
|
||||
---
|
||||
|
||||
## 3. Modèle de ressources
|
||||
|
||||
L'API expose **8 ressources** (chapitres 1-8 du PACS) :
|
||||
|
||||
```text
|
||||
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
|
||||
│ System │ │ Transport │ ─────▶│ Vehicle │
|
||||
│ (état global + │ │ (l'ordre du │ │ (AGV physique) │
|
||||
│ abonnements) │ │ WMS) │ └──────────────────┘
|
||||
└──────────────────┘ └────────┬─────────┘ ▲
|
||||
│ │ assignation
|
||||
▼ │
|
||||
┌──────────────────┐ ┌──────────────────┐
|
||||
│ Load │◀──────│ Location │
|
||||
│ (charge physique │ │ (point géo + │
|
||||
│ = container) │ │ actions) │
|
||||
└────────┬─────────┘ └────────┬─────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────┐ ┌──────────────────┐
|
||||
│ LoadType │ │ Group │
|
||||
│ (catalogue de │ │ (ensemble de │
|
||||
│ types) │ │ locations) │
|
||||
└──────────────────┘ └──────────────────┘
|
||||
```
|
||||
|
||||
### 3.1 Transport (l'ordre)
|
||||
|
||||
C'est l'**équivalent direct de l'`AgvTask`** côté EasyWMS.
|
||||
|
||||
|Champ|Type|Rôle|
|
||||
|---|---|---|
|
||||
|`id`|string|Id généré par iGO|
|
||||
|`transportHostId`|string|Id hôte (= `OrderExtId` côté EasyWMS)|
|
||||
|`sourceLocationId` _ou_ `sourceGroupId`|string|Source (un des deux requis)|
|
||||
|`destinationLocationId` _ou_ `destinationGroupId`|string|Destination (un des deux requis)|
|
||||
|`load`|Load|Charge embarquée|
|
||||
|`priority`|int 0-10|10 = max, 0 = min|
|
||||
|`suspended`|bool|Crée le transport mais sans l'exécuter|
|
||||
|`customMetaData`|dict (Key/Val)|Métadonnées libres|
|
||||
|`status`|enum|Voir § 5|
|
||||
|
||||
### 3.2 Vehicle (l'AGV)
|
||||
|
||||
|Champ|Type|Rôle|
|
||||
|---|---|---|
|
||||
|`id`|string|Identifiant véhicule|
|
||||
|`mode`|enum|`Manual / Automatic / SemiAutomatic / Removed / Disabled`|
|
||||
|`status`|enum|`Idle / Executing / Charging / Faulted / Manual`|
|
||||
|`pose`|object (x, y, orientation)|Position physique en temps réel|
|
||||
|`batteryLevel`|int|% batterie|
|
||||
|`loadId` / `loadHostId`|string|Charge embarquée|
|
||||
|`locationStationId`|string|Station courante|
|
||||
|`errors`|array|Codes/labels d'erreur|
|
||||
|
||||
### 3.3 Load et LoadType
|
||||
|
||||
`Load` = instance physique d'une charge (un container, une palette). Possède `loadHostId` (id côté WMS), `loadTypeId`, `locationId`, `dimensions` (W/D/H/Weight) et `customMetaData`.
|
||||
|
||||
`LoadType` = catalogue (id + dimensions par défaut). Endpoint en lecture seule (`GET /api/load-types`).
|
||||
|
||||
### 3.4 Location & Group
|
||||
|
||||
- **Location** : un point physique sur lequel un AGV peut faire des actions (`possibleActions`), avec types de véhicules et de charges autorisés et `actualLoads` courantes.
|
||||
- **Group** : un ensemble de Locations. Sert quand on veut différer le choix de la location finale jusqu'au point de décision (cas typique : zone de déchargement avec plusieurs alvéoles). Le WMS appelle alors `POST /api/transports/{id}/final-source` ou `/final-destination` pour fixer le choix.
|
||||
|
||||
### 3.5 System
|
||||
|
||||
État global : projet courant, `isRunning`, abonnements actifs, timestamp de démarrage.
|
||||
|
||||
---
|
||||
|
||||
## 4. Flux API principaux
|
||||
|
||||
### 4.1 Inventaire des endpoints
|
||||
|
||||
Tous sur `https://[IP]:7002/api/...` avec `X-API-Key` (header) et `Authorization: Bearer <token>` (header).
|
||||
|
||||
|Verbe|URL|Effet|
|
||||
|---|---|---|
|
||||
|GET|`/api/system`|Status global + liste des subscriptions|
|
||||
|GET|`/api/transports`|Liste de tous les transports en mémoire|
|
||||
|POST|`/api/transports`|**Créer un nouveau transport**|
|
||||
|GET|`/api/transports/{id}`|Détail d'un transport|
|
||||
|POST|`/api/transports/{id}/final-destination`|Fixer la destination finale (group → location)|
|
||||
|POST|`/api/transports/{id}/final-source`|Fixer la source finale (group → location)|
|
||||
|POST|`/api/transports/{id}/suspend`|Mettre en pause|
|
||||
|POST|`/api/transports/{id}/release`|Relancer après suspend|
|
||||
|POST|`/api/transports/{id}/cancel`|Annuler|
|
||||
|POST|`/api/transports/{id}/priority?priority={0-10}`|Changer la priorité|
|
||||
|POST|`/api/transports/subscription?callbackUrl=…`|S'abonner aux events transport|
|
||||
|DELETE|`/api/transports/subscription?callbackUrl=…`|Se désabonner|
|
||||
|GET|`/api/groups` / `/api/groups/{id}`|Lecture des groupes|
|
||||
|GET|`/api/loads` / `/api/loads/{id}`|Lecture des loads|
|
||||
|POST|`/api/loads`|Créer une load à une location|
|
||||
|POST|`/api/loads/{id}/location`|Déplacer une load (manuellement)|
|
||||
|DELETE|`/api/loads/{id}`|Supprimer une load|
|
||||
|GET|`/api/load-types`|Catalogue des types|
|
||||
|GET|`/api/locations` / `/api/locations/{id}`|Lecture des locations|
|
||||
|GET|`/api/vehicles` / `/api/vehicles/{id}`|Lecture véhicules|
|
||||
|POST|`/api/vehicles/suspend`|Suspendre **toute la flotte**|
|
||||
|POST|`/api/vehicles/resume`|Relancer toute la flotte|
|
||||
|POST|`/api/vehicles/{id}/suspend` / `.../resume`|Suspend/resume un AGV donné|
|
||||
|POST|`/api/vehicles/restart`|Redémarrer toute la flotte|
|
||||
|POST|`/api/vehicles/subscription?callbackUrl=…`|S'abonner aux events vehicle|
|
||||
|DELETE|`/api/vehicles/subscription?callbackUrl=…`|Se désabonner|
|
||||
|
||||
### 4.2 Endpoints à implémenter **côté WMS** (callbacks)
|
||||
|
||||
Spécifiés par le client (l'URL est passée à l'inscription).
|
||||
|
||||
|URL (côté WMS)|Body reçu|Quand iGO l'appelle|
|
||||
|---|---|---|
|
||||
|`POST /api/transport/event`|objet `Transport` complet|À chaque changement d'état d'un transport|
|
||||
|`POST /api/vehicles/event`|objet `Vehicle` complet|À chaque changement d'état d'un véhicule|
|
||||
|
||||
> ℹ️ Le contrat ne définit **pas** la fréquence ni le rate-limiting. À tester en charge — un transport qui passe par tous les états émet ~7 callbacks ; un véhicule qui se déplace peut en émettre beaucoup plus (pose updates).
|
||||
|
||||
### 4.3 Flux nominal — création et exécution d'un transport
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant WMS as EasyWMS
|
||||
participant iGO as iGO easy
|
||||
participant V as Vehicle
|
||||
|
||||
WMS->>iGO: POST /api/transports {sourceLocationId, destinationLocationId, load, priority, transportHostId}
|
||||
iGO-->>WMS: 200 OK Transport(id, status=Requested)
|
||||
iGO->>WMS: callback transport/event (status=Pending)
|
||||
iGO->>V: assigne le véhicule
|
||||
iGO->>WMS: callback transport/event (status=Assigned)
|
||||
Note over V: AGV se déplace<br/>vers source
|
||||
V->>iGO: arrivé source
|
||||
iGO->>WMS: callback (status=Retrieving)
|
||||
Note over V: AGV charge
|
||||
V->>iGO: chargé
|
||||
iGO->>WMS: callback (status=Retrieved)
|
||||
Note over V: AGV se déplace<br/>vers destination
|
||||
V->>iGO: arrivé destination
|
||||
iGO->>WMS: callback (status=Storing)
|
||||
Note over V: AGV décharge
|
||||
V->>iGO: déchargé
|
||||
iGO->>WMS: callback (status=Stored)
|
||||
iGO->>WMS: callback (status=Finished)
|
||||
```
|
||||
|
||||
### 4.4 Flux avec décision tardive (Group)
|
||||
|
||||
C'est le cas où le WMS ne sait pas, à la création, _quelle alvéole exacte_ utiliser :
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant WMS
|
||||
participant iGO
|
||||
participant V as Vehicle
|
||||
|
||||
WMS->>iGO: POST /api/transports {destinationGroupId="DOCK_OUT", ...}
|
||||
iGO-->>WMS: 200 OK (status=Requested)
|
||||
iGO->>WMS: callback (status=Pending)
|
||||
iGO->>WMS: callback (status=Assigned)
|
||||
iGO->>WMS: callback (status=Retrieving → Retrieved)
|
||||
Note over V: AGV se déplace<br/>vers le decision point<br/>du groupe DOCK_OUT
|
||||
V->>iGO: arrivé au decision point
|
||||
iGO->>WMS: callback (status=RequestDestination)
|
||||
Note over WMS: WMS choisit une<br/>alvéole précise dans<br/>le groupe DOCK_OUT
|
||||
WMS->>iGO: POST /api/transports/{id}/final-destination<br/>{destinationId: "DOCK_OUT_03"}
|
||||
iGO-->>WMS: 200 OK
|
||||
Note over V: AGV poursuit<br/>vers DOCK_OUT_03
|
||||
iGO->>WMS: callback (status=Storing → Stored → Finished)
|
||||
```
|
||||
|
||||
> ⚠️ Si le WMS **ne répond pas assez vite**, iGO bascule de `RequestDestination` vers `WaitDestination` (l'AGV est arrivé physiquement et attend). Symétrique côté source : `RequestSource` → `WaitSource`.
|
||||
|
||||
### 4.5 Annulation et suspension
|
||||
|
||||
```text
|
||||
Action Endpoint Effet
|
||||
─────────────────────────────────────────────────────────────────────────────────────
|
||||
Annuler POST /api/transports/{id}/cancel status=Cancelled (terminal)
|
||||
Suspendre POST /api/transports/{id}/suspend gel temporaire (peut être levé)
|
||||
Relancer POST /api/transports/{id}/release inverse de suspend
|
||||
Re-prioriser POST /api/transports/{id}/priority?p=N 0..10
|
||||
Suspendre flotte POST /api/vehicles/suspend tous les AGV s'arrêtent
|
||||
Reprendre flotte POST /api/vehicles/resume
|
||||
Redémarrer flotte POST /api/vehicles/restart reset hard
|
||||
```
|
||||
|
||||
> ⚠️ **Limite d'annulation confirmée par STILL** : un transport **ne peut pas être annulé après l'état `Retrieved`** (= AGV a déjà pris la palette) — cf. FAQ #6.
|
||||
>
|
||||
> **Conséquence côté EasyWMS** : la branche du `AgvTask_SetCancelledTask_PR` qui gérait l'annulation après chargement (et déclenchait la recherche de relocation) **n'a plus de sens dans le mapping iGO**. Si un cancel arrive côté WMS après `Retrieved`, il faut soit :
|
||||
>
|
||||
> 1. attendre la fin du transport (`Stored`) et faire alors une nouvelle tâche AGV de retour ;
|
||||
> 2. ou intervenir physiquement (intervention manuelle / fallback RFT) avant de cancel.
|
||||
|
||||
> 💤 **Le champ `suspended`** (paramètre du POST de création) n'a pas d'usage métier identifié par STILL côté WMS classique (cf. FAQ #7). À utiliser uniquement si on veut pré-créer un transport avant que la palette soit physiquement disponible.
|
||||
|
||||
---
|
||||
|
||||
## 5. Cycle de vie d'un Transport
|
||||
|
||||
État final possible : **`Finished`**, **`Cancelled`**, **`Aborted`**.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
New[New] --> Req[Requested]
|
||||
Req --> Pen[Pending]
|
||||
Pen --> Asg[Assigned]
|
||||
Asg -->|source = Group| RS[Request Source]
|
||||
Asg -->|source = Location| Ret[Retrieving]
|
||||
RS -->|final source set| Ret
|
||||
RS -->|AGV arrivé sans réponse| WS[Wait Source]
|
||||
WS -->|final source set| Ret
|
||||
Ret --> Rtd[Retrieved]
|
||||
Rtd -->|dest = Group| RD[Request Destination]
|
||||
Rtd -->|dest = Location| Sto[Storing]
|
||||
RD -->|final dest set| Sto
|
||||
RD -->|AGV arrivé sans réponse| WD[Wait Destination]
|
||||
WD -->|final dest set| Sto
|
||||
Sto --> Std[Stored]
|
||||
Std --> Fin[Finished]
|
||||
|
||||
Asg -.cancel.-> Can[Cancelled]
|
||||
Pen -.cancel.-> Can
|
||||
Ret -.error.-> Abo[Aborted]
|
||||
Sto -.error.-> Abo
|
||||
```
|
||||
|
||||
|État|Sens fonctionnel|
|
||||
|---|---|
|
||||
|`New`|État **interne instantané** — n'apparaît jamais dans les callbacks. À ignorer côté WMS. (cf. FAQ #4)|
|
||||
|`Requested`|**Premier état réellement observable** côté WMS, juste après le POST|
|
||||
|`Pending`|En file d'attente, en attente d'un AGV libre|
|
||||
|`Assigned`|Un AGV a été désigné|
|
||||
|`RequestSource` / `WaitSource`|Source = group ; iGO attend la décision finale du WMS|
|
||||
|`Retrieving`|AGV en route vers la source / en cours de chargement|
|
||||
|`Retrieved`|Charge prise|
|
||||
|`RequestDestination` / `WaitDestination`|Destination = group ; iGO attend la décision finale|
|
||||
|`Storing`|AGV en route vers destination / en cours de dépose|
|
||||
|`Stored`|Charge déposée|
|
||||
|`Finished`|Transport terminé proprement (état terminal)|
|
||||
|`Cancelled`|Annulé via `/cancel` (état terminal)|
|
||||
|`Aborted`|Erreur d'exécution irrécupérable (état terminal). ⚠ **Aucun code ni message d'erreur** dans le payload — seul le statut est transmis (cf. FAQ #2)|
|
||||
|
||||
> 🔑 **Identifiant véhicule** : il n'apparaît dans le payload **qu'à partir de l'état `Retrieved`** (et plus, après donc). À l'état `Assigned`, le payload ne contient pas encore le `Vehicle.id` (cf. FAQ #1). Les workflows EasyWMS (typiquement `ProcessEvent_TaskAssigned_PR` qui faisait le lien Equipment ↔ Task) doivent donc **être recalés sur `Retrieved`** pour le mapping iGO.
|
||||
|
||||
> ⏱️ **Pas de timestamp dans le payload** des callbacks (cf. FAQ #3). Si le WMS a besoin d'horodater, il doit le faire à réception (`DateTime.UtcNow`).
|
||||
|
||||
---
|
||||
|
||||
## 6. Sécurité et abonnements aux events
|
||||
|
||||
### 6.1 Sécurité
|
||||
|
||||
- **Transport** : HTTPS avec **TLS 1.2** ; certificats **auto-signés** → le WMS doit les _truster_ explicitement (import dans le keystore).
|
||||
- **Authentification** : ✅ **C'est `X-API-Key` qui est utilisé** (confirmé par STILL — cf. FAQ #8). Le header `Authorization: Bearer <token>` mentionné dans certaines parties de la doc est obsolète / à ignorer.
|
||||
- La clé est **fixe** (pas de refresh automatique) → fournie par le PM STILL.
|
||||
|
||||
### 6.2 Modèle d'abonnement
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant WMS
|
||||
participant iGO
|
||||
Note over WMS: au démarrage du WMS
|
||||
WMS->>iGO: POST /api/transports/subscription?callbackUrl=https://wms/agv/events/transport
|
||||
iGO-->>WMS: 204 No Content
|
||||
WMS->>iGO: POST /api/vehicles/subscription?callbackUrl=https://wms/agv/events/vehicle
|
||||
iGO-->>WMS: 204 No Content
|
||||
Note over iGO: en exploitation
|
||||
iGO->>WMS: POST https://wms/agv/events/transport (Transport JSON)
|
||||
WMS-->>iGO: 200 OK
|
||||
iGO->>WMS: POST https://wms/agv/events/vehicle (Vehicle JSON)
|
||||
WMS-->>iGO: 200 OK
|
||||
Note over WMS: à l'arrêt du WMS
|
||||
WMS->>iGO: DELETE /api/transports/subscription?callbackUrl=…
|
||||
WMS->>iGO: DELETE /api/vehicles/subscription?callbackUrl=…
|
||||
```
|
||||
|
||||
### 6.3 Bonnes pratiques côté EasyWMS
|
||||
|
||||
- **Idempotence** : iGO peut retransmettre un event en cas de timeout côté WMS. Le handler côté EasyWMS doit gérer le doublon (par exemple via `transport.id` + `status`).
|
||||
- **Re-souscription** au boot : si iGO redémarre, les abonnements en mémoire peuvent être perdus. Le WMS doit toujours appeler `GET /api/system` au démarrage et vérifier la présence de la subscription, et la recréer sinon.
|
||||
- **Endpoint callback** : doit être en HTTPS (sinon iGO refuse), retourner **200 OK** rapidement (idéalement < 1s), traitement asynchrone derrière.
|
||||
|
||||
---
|
||||
|
||||
## 7. Table de correspondance EasyWMS AGV ↔ iGO
|
||||
|
||||
### 7.1 Concepts métier
|
||||
|
||||
|EasyWMS (module AGV)|iGO easy / PACS|Commentaire|
|
||||
|---|---|---|
|
||||
|`AgvTask` (entité)|`Transport` (resource)|Cœur fonctionnel — l'ordre de transport|
|
||||
|`Container` / LPN|`Load`|La charge physique|
|
||||
|`ContainerType`|`LoadType`|Catalogue de types|
|
||||
|`Location` (`IRealLocation`)|`Location`|Point physique du warehouse|
|
||||
|`WorkingZone`|`Group`|Ensemble de locations à décision tardive|
|
||||
|AGV station (type 65)|`Vehicle`|Le véhicule lui-même|
|
||||
|`AgvLockType` (`AGV_Lock`)|`Location.isEnabled = false`|iGO n'a pas de typage de lock — juste un flag|
|
||||
|`ManualEquipment` (RFT fallback)|_(aucun équivalent)_|Concept WMS-uniquement|
|
||||
|`EagMessages` (table SQL)|API REST `POST /api/transports/...`|Tables ↔ HTTP|
|
||||
|`AgeMessages` (table SQL)|Webhook callback `POST /transport/event`|Tables ↔ HTTP|
|
||||
|`AgsMessages` (table SQL)|Webhook callback `POST /vehicles/event`|Status AGV|
|
||||
|
||||
### 7.2 Champs de l'ordre
|
||||
|
||||
|EasyWMS `AgvTask`|iGO `Transport`|Conversion|
|
||||
|---|---|---|
|
||||
|`OrderExtId` (long, = `Task.TaskNumber`)|`transportHostId` (string)|`OrderExtId.ToString()`|
|
||||
|`Id` (Guid)|`id` (string)|iGO génère son propre `id`|
|
||||
|`LoadLocation`|`sourceLocationId`|mapping direct par code location|
|
||||
|`UnloadLocation`|`destinationLocationId`|id direct|
|
||||
|(groupe de couloirs / décision tardive)|`sourceGroupId` / `destinationGroupId`|Pour WorkingZones|
|
||||
|`LoadType` (0=Container, 1=PalletShuttle)|`Load.loadTypeId`|iGO ne gère pas nativement le PS|
|
||||
|`PalletId`|`Load.loadHostId`|id côté WMS|
|
||||
|`PalletType`|`Load.loadTypeId`|référence au catalogue LoadType|
|
||||
|`Priority` (0=Urgent ... 4=VeryLow)|`priority` (10=max, 0=min)|**Conversion inversée** — voir ci-dessous|
|
||||
|`HasTopper`|`customMetaData["HASTOPPER"]`|passe en metadata|
|
||||
|`CanPick`, `CanDrop`|_(pas d'équivalent natif)_|Voir § 8|
|
||||
|`UnloadAisleNumber/Side/X/Y/Depth`|_(porté par la `Location`)_|iGO gère la géométrie en interne|
|
||||
|`StationNumber` (AGV courant)|`Vehicle.id` (vu en callback)|id du véhicule assigné|
|
||||
|`PreviousOrderId` (chaînage)|_(pas d'équivalent natif)_|À encoder en customMetaData|
|
||||
|`Status` (enum AgvStatus)|`status` (enum Transport)|Voir § 7.3|
|
||||
|`Operation` (Create/Update/Delete)|endpoints REST distincts|POST / final-* / cancel|
|
||||
|`WarehouseNumber` / `WarehouseCode`|_(pas exposé)_|iGO suppose un seul site|
|
||||
|
||||
**Conversion de priorité :**
|
||||
|
||||
|EasyWMS|iGO|Suggestion|
|
||||
|---|---|---|
|
||||
|0 — Urgent|10 — Highest|mapping direct|
|
||||
|1 — High|8||
|
||||
|2 — Normal|5||
|
||||
|3 — Low|3||
|
||||
|4 — VeryLow|1||
|
||||
|
||||
### 7.3 États / phases
|
||||
|
||||
|Phase AGV (EasyWMS)|EasyWMS `AgvStatus`|iGO `Transport.status`|Notes|
|
||||
|---|---|---|---|
|
||||
|(création)|`PendingToBeSend`|(pas encore envoyé)|côté WMS uniquement|
|
||||
|Envoi EAG|—|`New` → `Requested`|après `POST /api/transports`|
|
||||
|Phase 100 (Order accepted)|`Sent`|`Pending`|en file d'attente iGO|
|
||||
|Phase 103 (Vehicle assigned)|(Sent)|`Assigned`|véhicule affecté|
|
||||
|Phase 104 (Load permission)|`PendingToBeLoad`|`RequestSource` _(group only)_|iGO n'a ce comportement qu'en mode group|
|
||||
|(autorisation WMS load)|(Sent / re-export EAG)|`POST /final-source`|mais pas un _renvoi du même ordre_ — c'est un endpoint dédié|
|
||||
|Phase 106 (Load confirmed)|(Sent)|`Retrieving` → `Retrieved`|charge prise|
|
||||
|Phase 108 (Unload permission)|`PendingToBeUnload`|`RequestDestination` _(group only)_|idem auth load|
|
||||
|(autorisation WMS unload)|(Sent / re-export EAG)|`POST /final-destination`|endpoint dédié|
|
||||
|Phase 110 (Unload confirmed)|(Sent → purge)|`Storing` → `Stored` → `Finished`|terminé|
|
||||
|Phase 255 (Cancel by AGV)|`(Cancelled)`|`Cancelled` ou `Aborted`|aborted = erreur, cancelled = ordre annulé|
|
||||
|
||||
> 🎯 **Différence sémantique majeure** : EasyWMS attend une **demande explicite d'autorisation** (phases 104 / 108) **à chaque ordre** quand `CanPick` / `CanDrop` sont à `false`. iGO ne demande l'autorisation qu'**au point de décision d'un Group**. Si la `sourceLocation` est connue dès la création, iGO ne demande **aucune autorisation** — elle exécute directement.
|
||||
>
|
||||
> Pour reproduire le comportement EasyWMS dans iGO, il faut **forcer** l'usage de Groups, même mono-location, là où EasyWMS aurait CanPick = false.
|
||||
|
||||
### 7.4 Erreurs
|
||||
|
||||
|Code EasyWMS|Famille|Équivalent iGO|Remarque|
|
||||
|---|---|---|---|
|
||||
|1001-1014|Configuration (mauvaise station, ordre dupliqué…)|`HTTP 400 BadRequest` à la création|iGO refuse à la requête|
|
||||
|1003 (duplicate)||`HTTP 400` sur POST /transports si transportHostId déjà utilisé (à valider)||
|
||||
|1009 (cancellation error)||`HTTP 400/404` sur POST /cancel||
|
||||
|2003 (extraction error)|Exécution|`Transport.status = Aborted` + `Vehicle.errors[]`|erreur runtime|
|
||||
|2004 (putaway error)|Exécution|idem||
|
||||
|2005 (manual cancel from AGV UI)|Exécution|`Transport.status = Cancelled` reçu en callback||
|
||||
|2500-2503|Communication|erreurs **HTTP 5xx / timeouts**|au niveau réseau|
|
||||
|2700 (wrong/missing container)|Exécution|`Vehicle.errors[]` + `status = Faulted`|côté véhicule|
|
||||
|
||||
> 💡 Côté EasyWMS, les codes 1001-2700 sont stockés dans `agvEvent.Flags` et routés par `ProcessErrors_PR`. **La logique côté EasyWMS doit donc être étendue** pour transformer une réponse HTTP / un callback iGO en un `agvEvent.Flags` numérique, qui ensuite ré-utilise toute la machinerie standard de notification (`ProcessError1001_PR`, etc.).
|
||||
|
||||
### 7.5 Verbe / opération
|
||||
|
||||
|Action métier|EasyWMS (Operation + EAG)|iGO (REST)|
|
||||
|---|---|---|
|
||||
|Créer un ordre|`Operation = Create` + ligne EAG|`POST /api/transports`|
|
||||
|Modifier un ordre|`Operation = Update` + ligne EAG|(selon le cas) `POST /priority`, `POST /final-source`, `POST /final-destination`|
|
||||
|Annuler un ordre|`Operation = Delete` + ligne EAG|`POST /api/transports/{id}/cancel`|
|
||||
|Modifier priorité|`AgvTaskEditCommand` + `Operation = Update`|`POST /api/transports/{id}/priority?priority=N`|
|
||||
|Suspendre un ordre|(pas d'équivalent)|`POST /api/transports/{id}/suspend` ➕|
|
||||
|Reprendre un ordre|(pas d'équivalent)|`POST /api/transports/{id}/release` ➕|
|
||||
|Suspendre la flotte|(pas d'équivalent)|`POST /api/vehicles/suspend` ➕|
|
||||
|Demande d'auth load|EAG `Operation = Update` (CanPick=true)|`POST /api/transports/{id}/final-source`|
|
||||
|Demande d'auth unload|EAG `Operation = Update` (CanDrop=true)|`POST /api/transports/{id}/final-destination`|
|
||||
|
||||
➕ = capacité **nouvelle** offerte par iGO, sans contrepartie WMS — utile pour la maintenance.
|
||||
|
||||
### 7.6 Topologie / configuration
|
||||
|
||||
|EasyWMS|iGO|
|
||||
|---|---|
|
||||
|AGV créé en EasyS dans un _AGV equipment group_ (type 65)|`Vehicle` configuré dans MyMA|
|
||||
|`Routes` configurées en EasyS entre stations|Layout iGO, géré dans MyMA / iGO designer|
|
||||
|`LoadAisle` / `UnloadAisle` (couloirs manuels)|`Location.possibleActions`|
|
||||
|`Allow loading / Allow unloading` per location|`Location.isEnabled` + `possibleActions`|
|
||||
|`Manual loading aisle`|(pas d'équivalent — iGO calcule la trajectoire)|
|
||||
|`LocationLockType` "For AGV"|`Location.isEnabled = false` (binaire)|
|
||||
|Fault notification group AGV|callback `POST /vehicles/event` (errors[])|
|
||||
|
||||
### 7.7 Workflows EasyWMS impactés par l'intégration iGO
|
||||
|
||||
> 📖 **Vocabulaire** : dans la suite, l'expression **« Gateway iGO »** est utilisée comme raccourci pour désigner le **middleware côté flotte à développer pour iGO** (cf. § 8.4) — concrètement, **une pool IIS C# .NET 8** développée par Mecalux qui regroupe la pompe sortante (poll `AGV_OUTPUTQUEUE` → API iGO) et le webhook receiver (callbacks iGO → écrit `AGV_INPUTQUEUE`+`AGE`/`AGS`). Il **ne doit pas être confondu** avec la **Gateway AGV Mecalux**, qui elle existe déjà dans le module AGV core et joue un rôle différent (mediator côté Mecalux entre workflows et tables).
|
||||
|
||||
> ✅ **Avec le pattern Gateway iGO + Gateway AGV Mecalux + tables EAG/AGE/AGS (cf. § 8.4) : aucun workflow EasyWMS, ni la Gateway AGV Mecalux, n'a besoin d'être modifié.** La spécificité iGO est **entièrement encapsulée** dans le Gateway iGO, qui se contente de traduire le contenu des tables vers/depuis l'API REST PACS.
|
||||
|
||||
|Workflow EasyWMS|Comportement avec Gateway iGO|
|
||||
|---|---|
|
||||
|`MovementCreatedEventHandler_PR`|✅ Inchangé — toujours le déclencheur|
|
||||
|`AgvTask_CreateTaskFromMovement_PR`|✅ Inchangé — produit un `AgvTaskWF`|
|
||||
|`AgvTask_SetCreatedTask_PR`|✅ Inchangé — `Status = PendingToBeSend`|
|
||||
|`SerializeAgvTasks_PR` + `CreateMovTrackings_PR`|✅ Inchangé — écrit en table EAG. **Le Gateway iGO** lit cette ligne et exécute le `POST /api/transports`.|
|
||||
|`ProcessEvents_PR` + `ProcessEvent_*_PR`|✅ Inchangé — poll AGE comme d'habitude. **Le Gateway iGO** alimente AGE en traduisant les callbacks REST.|
|
||||
|`ProcessErrors_PR` + `ProcessError*_PR`|✅ Inchangé — réagit aux `Flags` dans AGE. **Le Gateway** est responsable d'inscrire un `Flags` cohérent (2003, 2004, etc.) à partir du `status=Aborted` + GET vehicles errors.|
|
||||
|`Agvtask_CanPick/CanDrop_PendingToBeSent_PR`|✅ Inchangé — réécrit une ligne EAG avec `CanPick=true`/`CanDrop=true`. **Le Gateway** reconnaît ce pattern et appelle `POST /transports/{id}/final-source` ou `/final-destination`.|
|
||||
|`TaskCanceledEventHandler_PR` + `AgvTask_SetCancelledTask_PR`|✅ Inchangé — écrit une ligne EAG `Operation=Delete`. **Le Gateway** appelle `POST /transports/{id}/cancel` (et signale impossibilité si statut iGO ≥ Retrieved).|
|
||||
|`MovementDestinationChanged_PR`|✅ Inchangé — émet un `Operation=Delete` puis `Operation=Create`. **Le Gateway** chaîne `cancel` puis nouveau `POST /transports`.|
|
||||
|Workflows RFT (`Equipment_AgvTask_*_UI`)|✅ Inchangés — fallback opérateur préservé si iGO indisponible|
|
||||
|`AGV_LocationLockType_Create_PR`|✅ Inchangé — init du LockType `AGV_Lock` côté EasyWMS. La pose effective du verrou n'a pas d'écho direct vers iGO (les locations iGO ne sont gérées que par MyMA).|
|
||||
|`Galileo_EventCreatedEventHandler_PR` (partial)|✅ Inchangé — non concerné par iGO (côté Galileo seulement)|
|
||||
|
||||
> 📌 **Conséquence projet** : la livraison du custom `CstAGV` n'a **rien à voir** avec l'intégration iGO. Le custom AGV reste tel qu'il est, et c'est le Gateway iGO (livrable séparé, service Windows à part) qui porte toute la couche d'adaptation. C'est la bonne séparation des responsabilités.
|
||||
|
||||
---
|
||||
|
||||
## 8. Points d'attention pour l'intégration
|
||||
|
||||
### 8.1 Différences structurelles
|
||||
|
||||
1. **Pas de tables d'échange** : il faut un service HTTP listener côté EasyWMS pour recevoir les callbacks. Exposé typiquement sur le serveur WMS, sécurisé en HTTPS, avec un certificat trusté par MyMA.
|
||||
2. **Pas de phases distinctes 100/103/104/106/108/110** dans iGO — tout est **état du Transport**. Le mapping en phases EasyWMS est un travail de traduction côté custom.
|
||||
3. **Pas de `CanPick`/`CanDrop` natifs** : pour reproduire la demande d'autorisation, il faut **passer par les Groups**. Conséquence : le layout iGO doit déclarer un Group pour chaque location qui doit demander auth.
|
||||
4. **Priorité 0-10** vs 0-4 : conversion bijective à fixer (cf. § 7.2).
|
||||
5. **Pas de routing exposé** : iGO gère ses routes en interne. Donc pas d'équivalent à `Routes between stations` en EasyS, et pas d'erreur `Disabled route` côté iGO.
|
||||
|
||||
### 8.2 Capacités nouvelles
|
||||
|
||||
iGO offre des capacités que l'AGV core EasyWMS n'expose pas :
|
||||
|
||||
- **Suspend / Resume / Restart** d'une flotte ou d'un véhicule individuel sur demande WMS.
|
||||
- **Pose temps réel** de chaque véhicule (`x, y, orientation`) → utilisable pour un dashboard live côté EasyWMS.
|
||||
- **Battery level** → permet de déclencher des événements ERP/notifs à seuils.
|
||||
|
||||
### 8.3 Sujets levés avec STILL — état au 28/04/2026
|
||||
|
||||
Le retour FAQ STILL a clos plusieurs questions (cf. § 9). Récapitulatif :
|
||||
|
||||
|#|Sujet|Statut|
|
||||
|---|---|---|
|
||||
|1|`X-API-Key` vs `Bearer token`|✅ **Résolu** : c'est `X-API-Key` (FAQ #8)|
|
||||
|2|Re-livraison des callbacks|🟡 **Partiel** : iGO retente, mais fréquence inconnue → à tester en charge (FAQ #9)|
|
||||
|3|Fréquence des `vehicle/event` (pose updates)|❌ Toujours ouvert|
|
||||
|4|Comportement queue saturée (transport `Pending` sans véhicule)|🟡 **Partiel** : on sait au moins que les transports survivent à un redémarrage iGO (FAQ #10)|
|
||||
|5|`customMetaData` (taille, caractères, ré-émis ?)|❌ Toujours ouvert|
|
||||
|6|Création/modification de `Location` via API|❌ Toujours ouvert (l'API n'expose que `GET`)|
|
||||
|7|Pallet Shuttle (LoadType = 1)|❌ Toujours ouvert|
|
||||
|8|Multi-warehouse|❌ Toujours ouvert|
|
||||
|9|HasTopper (attribut véhicule)|❌ Toujours ouvert|
|
||||
|10|`New` vs `Requested`|✅ **Résolu** : `New` est interne et instantané, traiter `Requested` comme premier état (FAQ #4)|
|
||||
|11|`Vehicle.id` disponible dès `Assigned` ?|✅ **Résolu** : non, seulement à partir de `Retrieved` (FAQ #1)|
|
||||
|12|Code/message d'erreur dans payload `Aborted`|✅ **Résolu** : aucun — juste le statut (FAQ #2)|
|
||||
|13|Timestamp dans les callbacks|✅ **Résolu** : aucun — le WMS doit horodater à réception (FAQ #3)|
|
||||
|14|Workflow `Load` : créer la palette avant ou avec le transport ?|✅ **Résolu** : ne pas créer — passer les infos directement dans le transport (FAQ #5)|
|
||||
|15|Annulation après chargement|✅ **Résolu** : non, impossible après `Retrieved` (FAQ #6)|
|
||||
|16|Cas d'usage du `suspended`|✅ **Résolu** : utile uniquement si pré-création d'un transport avant disponibilité de la palette (FAQ #7)|
|
||||
|17|Persistance après redémarrage iGO|✅ **Résolu** : oui, les données survivent (FAQ #10)|
|
||||
|18|Communication directe vs via `iGo Flow`|✅ **Résolu** : directement avec l'API PACS (FAQ #11)|
|
||||
|
||||
### 8.4 Architecture cible — Pattern à 4 composants (Gateway Mecalux + middleware pool IIS C#)
|
||||
|
||||
> 🔑 **Principe directeur (vérifié dans la doc Mecalux `Interface_Communications_AGVs_EN.pdf` et le contrat technique `RT_AGVs_EN.pdf`)** : EasyWMS communique avec les fleet managers externes via une **base intermédiaire dédiée aux communications** (5 tables réelles). Côté Mecalux, un service **Gateway AGV (existant)** mediate entre les workflows EasyWMS et les tables. Côté flotte, un **middleware à fournir** (à développer **par Mecalux** pour iGO, sous forme de pool IIS C# .NET 8) mediate entre ces tables et l'API REST PACS.
|
||||
>
|
||||
> **Le `EasyWMSGateway2015` que l'on connaît pour Galileo ne joue PAS le rôle de la Gateway AGV Mecalux** — il joue le rôle du middleware côté flotte (médiateur entre tables et TCP frames). Pour iGO, il faut son équivalent fonctionnel mais en REST/HTTPS, sous forme de pool IIS C#.
|
||||
>
|
||||
> **Le custom `CstAGV` n'est pas modifié.** L'intégration iGO consiste uniquement à fournir le middleware pool IIS.
|
||||
|
||||
#### 8.4.1 Schéma cible — 4 composants
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph EasyWMS["Côté Mecalux EasyWMS (existant)"]
|
||||
Process[Process<br/>Putaway/Picking/Shipping]
|
||||
Task[Task & Movement]
|
||||
AgvCore[Module AGV core<br/>workflows CstAGV]
|
||||
GwMec[Gateway AGV Mecalux<br/>service mediator<br/>workflows ↔ tables]
|
||||
MonitorView[Vues SmartUI<br/>AGV Tasks/Stations/<br/>Messages]
|
||||
end
|
||||
|
||||
subgraph DB["Intermediate database for communications"]
|
||||
direction TB
|
||||
OQ[(AGV_OUTPUTQUEUE<br/>FIFO sortante)]
|
||||
EAG[(AGV_EAG<br/>data ordres)]
|
||||
IQ[(AGV_INPUTQUEUE<br/>FIFO entrante)]
|
||||
AGE[(AGV_AGE<br/>data phases)]
|
||||
AGS[(AGV_AGS<br/>data statuts AGV)]
|
||||
end
|
||||
|
||||
subgraph FleetSide["Pool IIS C# .NET 8 — À DÉVELOPPER PAR MECALUX pour iGO"]
|
||||
direction TB
|
||||
Pump[Pompe sortante :<br/>poll OUTPUTQUEUE<br/>lit EAG via batchId<br/>+ POST API iGO]
|
||||
Hook[Webhook receiver :<br/>HTTPS endpoint<br/>écrit INPUTQUEUE+AGE/AGS]
|
||||
end
|
||||
|
||||
subgraph KION["iGO / PACS (existant chez STILL)"]
|
||||
iGO[API REST<br/>port 7002]
|
||||
end
|
||||
|
||||
Process --> Task --> AgvCore
|
||||
AgvCore -->|events workflow| GwMec
|
||||
GwMec -->|écrit OUTPUTQUEUE+EAG| OQ
|
||||
GwMec -->|écrit OUTPUTQUEUE+EAG| EAG
|
||||
GwMec -->|poll INPUTQUEUE+AGE/AGS| IQ
|
||||
GwMec -->|poll INPUTQUEUE+AGE/AGS| AGE
|
||||
GwMec -->|alimente| MonitorView
|
||||
|
||||
Pump -->|poll| OQ
|
||||
Pump -->|lit data via batchId| EAG
|
||||
Pump -->|HTTPS REST<br/>X-API-Key| iGO
|
||||
iGO -.webhook callback.-> Hook
|
||||
Hook -->|écrit| IQ
|
||||
Hook -->|écrit| AGE
|
||||
Hook -->|écrit| AGS
|
||||
```
|
||||
|
||||
#### 8.4.2 Composants existants côté Mecalux — RIEN à développer
|
||||
|
||||
|Composant|Rôle|Statut|
|
||||
|---|---|---|
|
||||
|`CstAGV` (workflows)|Logique métier AGV — création de tâches, gestion d'erreurs, fallback RFT, etc.|✅ Existant — non touché|
|
||||
|**Gateway AGV Mecalux**|Service mediator côté Mecalux : écoute events workflow → écrit `AGV_OUTPUTQUEUE` + `AGV_EAG` ; poll `AGV_INPUTQUEUE` → lit `AGV_AGE`/`AGV_AGS` → alimente vues SmartUI ; gère le `processedDate`|✅ Existant dans le module AGV — non touché|
|
||||
|Tables `AGV_INPUTQUEUE`, `AGV_OUTPUTQUEUE`, `AGV_EAG`, `AGV_AGE`, `AGV_AGS`|Intermediate database for communications|✅ Existantes|
|
||||
|Vues SmartUI (AGV Tasks/Stations/Messages)|Monitoring opérateur|✅ Existantes|
|
||||
|
||||
#### 8.4.3 Middleware côté flotte — pool IIS C# à développer **par Mecalux**
|
||||
|
||||
C'est **le seul livrable nouveau** de l'intégration. **Mecalux** (et non STILL) prend en charge ce développement, car le contrat avec les tables `AGV_*` est propriétaire Mecalux. Architecture cible :
|
||||
|
||||
|Aspect|Description|
|
||||
|---|---|
|
||||
|**Forme**|Pool **IIS** dédiée hébergeant un service ASP.NET Core (C#, .NET 8.0)|
|
||||
|**Hébergement**|Serveur Mecalux — peut être co-localisé avec EasyWMS ou sur une VM séparée selon la topologie projet|
|
||||
|**Rôle**|Service unique multi-thread combinant pompe sortante ET webhook receiver|
|
||||
|**Accès BDD**|Connection chaîne vers la base intermédiaire (les 5 tables `AGV_*`) — typiquement la même base que le WMS, ou une base dédiée si l'architecture projet le décide|
|
||||
|**Sécurité**|Header `X-API-Key` sortant + endpoint HTTPS entrant (TLS 1.2, certificat trusté ou auto-signé selon politique)|
|
||||
|
||||
##### A. Pompe sortante (poll `AGV_OUTPUTQUEUE` → API iGO)
|
||||
|
||||
|Aspect|Description|
|
||||
|---|---|
|
||||
|Mode|Background worker / hosted service ASP.NET Core — polling régulier (par ex. toutes les 1-5s) sur `AGV_OUTPUTQUEUE WHERE processedDate IS NULL ORDER BY creationDate ASC`|
|
||||
|Action|Pour chaque ligne queue : récupère le `id` (= `batchId`) → SELECT data correspondante dans `AGV_EAG WHERE batchId = <id>` → interprète l'`Operation` (`C`/`U`/`D`) → fait l'appel REST iGO adéquat|
|
||||
|Endpoints iGO appelés|`POST /api/transports` (Create), `POST /transports/{id}/cancel` (Delete), `POST /transports/{id}/priority`, `POST /transports/{id}/final-source`, `POST /transports/{id}/final-destination` (Update selon le pattern `CanPick`/`CanDrop`)|
|
||||
|Marquage|Après ack synchrone d'iGO (200 OK) : `UPDATE AGV_OUTPUTQUEUE SET processedDate = NOW() WHERE id = <id>`|
|
||||
|
||||
##### B. Webhook receiver (callbacks iGO → écrit `AGV_INPUTQUEUE` + `AGV_AGE`/`AGS`)
|
||||
|
||||
|Aspect|Description|
|
||||
|---|---|
|
||||
|Mode|Controller ASP.NET Core exposant deux endpoints HTTPS : `POST /agv/transport-event` et `POST /agv/vehicle-event` (URL configurable). Souscriptions iGO créées au boot via `POST /api/transports/subscription?callbackUrl=...` et `POST /api/vehicles/subscription?callbackUrl=...`|
|
||||
|Action|Pour chaque callback reçu : (1) `INSERT INTO AGV_INPUTQUEUE (message, creationDate) VALUES ('AGE'/'AGS', NOW())` → récupère le `id` généré → (2) `INSERT INTO AGV_AGE` (ou `AGV_AGS`) avec `batchId = <id>`, `Phase` (selon mapping iGO `status` → 100/103/106/110/255), `ErrorType` (0 ou code 2003/2004/2700 selon contexte), et tous les autres champs du payload Transport/Vehicle iGO|
|
||||
|Idempotence|Déduplication sur `transport.id + status` pour éviter les doubles inserts en cas de retry iGO (cf. FAQ #9). Implémentée via cache local distribué (par ex. table de dedupe interne avec TTL)|
|
||||
|Horodatage|`creationDate = NOW()` UTC à la réception, car iGO ne fournit pas de timestamp (cf. FAQ #3)|
|
||||
|Réponse|200 OK rapidement (< 1s) après insertion en base — le traitement métier est différé à la Gateway AGV Mecalux qui poll `AGV_INPUTQUEUE`|
|
||||
|
||||
##### Pattern de boot du middleware
|
||||
|
||||
À chaque démarrage de la pool IIS :
|
||||
|
||||
1. Vérifier la base intermédiaire accessible (connection string + ping `SELECT 1`)
|
||||
2. Vérifier l'API iGO accessible : `GET /api/system`
|
||||
3. Récupérer la liste des subscriptions actives via `GET /api/system` (champ `subscriptions`) → comparer avec ce qui est attendu → (re)créer les manquantes via `POST /api/transports/subscription` et `POST /api/vehicles/subscription`
|
||||
4. Réconcilier les transports : `GET /api/transports` → comparer avec les `AGV_OUTPUTQUEUE` non encore acquittées → générer les lignes `AGV_INPUTQUEUE` + `AGV_AGE` manquantes pour les events perdus pendant la coupure
|
||||
5. Démarrer le hosted service de polling sortant
|
||||
|
||||
> 💡 **Une seule pool IIS** héberge les deux fonctions (pompe + webhook). C'est plus simple à exploiter (un seul service à monitorer, un seul recycling, un seul fichier de logs) et c'est le pattern recommandé pour iGO.
|
||||
|
||||
#### 8.4.4 Mapping `Status` iGO → couple `(EventType, Flags)` AGE
|
||||
|
||||
C'est le cœur de la traduction entrante côté webhook receiver :
|
||||
|
||||
|iGO `Transport.status`|Inséré dans AGE comme|
|
||||
|---|---|
|
||||
|`Pending`|`EventType=100, Flags=0` (Order accepted)|
|
||||
|`Assigned`|`EventType=103, Flags=0` (Vehicle assigned) — mais cf. FAQ #1 : pas de `Vehicle.id` à ce moment, donc `StationNumber=null`|
|
||||
|`Retrieving`|(selon le mode group) `EventType=104, Flags=0` ou rien|
|
||||
|`Retrieved`|(selon le mode group) `EventType=106, Flags=0` (Load confirmed) — c'est ici que le `Vehicle.id` arrive|
|
||||
|`Storing`|`EventType=108, Flags=0` (Unload permission) si group, sinon avancement standard|
|
||||
|`Stored` / `Finished`|`EventType=110, Flags=0` (Unload confirmed)|
|
||||
|`Cancelled`|`EventType=255, Flags=0`|
|
||||
|`Aborted`|`Flags=2003` ou `2004` selon contexte (cf. FAQ #2 : à enrichir via `GET /api/vehicles/{id}` pour récupérer `errors[]`)|
|
||||
|
||||
#### 8.4.5 Avantages du pattern
|
||||
|
||||
✅ **CstAGV livré tel quel, Gateway AGV Mecalux non modifiée**. L'intégration iGO ne touche à aucun code EasyWMS — toute la spécificité iGO est encapsulée dans le composant côté flotte.
|
||||
|
||||
✅ **RFT fallback préservé**, notifications préservées, recherche de relocation préservée — toute la machinerie AGV continue à fonctionner.
|
||||
|
||||
✅ **Découplage temporel** : si iGO est down, EAG s'accumule et sera pompé à la reprise. Si la pompe sortante crashe, EasyWMS n'est pas impacté. Si le webhook receiver est down, iGO retransmet (FAQ #9).
|
||||
|
||||
✅ **Pattern symétrique avec Galileo** : Galileo a son `EasyWMSGateway2015` côté flotte ; iGO aura son équivalent REST/HTTPS — même rôle, protocole différent.
|
||||
|
||||
#### 8.4.6 Points de vigilance
|
||||
|
||||
⚠️ **Pas d'équivalent natif EAG du `final-source` / `final-destination`** : ces endpoints iGO sont consommés en réponse à un statut `RequestSource` / `RequestDestination`. Côté EAG, ils correspondent aux ré-exports `Operation=Update` avec `CanPick=true` / `CanDrop=true` → la pompe sortante doit reconnaître ce pattern et router vers le bon endpoint REST.
|
||||
|
||||
⚠️ **Annulation après `Retrieved`** (FAQ #6) : la pompe sortante doit, à la lecture d'un EAG `Operation=Delete`, vérifier le `status` iGO actuel (`GET /api/transports/{id}`). Si `≥ Retrieved` → ne pas appeler `/cancel` et écrire un Flags d'erreur dans AGE pour notifier le WMS.
|
||||
|
||||
⚠️ **Persistance** : les tables EAG/AGE/AGS persistent dans la base EasyWMS — pas de risque de perte si le composant côté flotte crashe. Le `BatchId` permet de reprendre proprement.
|
||||
|
||||
#### 8.4.7 Comparaison avec les services Gateway côté flotte historiques
|
||||
|
||||
Le **middleware iGO à développer** joue le même rôle que les services Gateway côté flotte que Mecalux a déjà développés pour d'autres protocoles. Comparaison côte à côte :
|
||||
|
||||
|Aspect|`EasyWMSGateway2015` (Galileo TMS)|`EasyWMSGatewayRocla2015` (Rocla AGV)|Pool IIS iGO (à développer)|
|
||||
|---|---|---|---|
|
||||
|Côté logique|Flotte (TCP frames ↔ hardware)|Flotte (TCP frames ↔ AGV Rocla)|Flotte (REST ↔ iGO PACS)|
|
||||
|Forme|Service Windows|Service Windows|**Pool IIS C# .NET 8**|
|
||||
|Mode de communication aval|TCP socket binaire (port 3000)|TCP socket binaire (port 50011)|HTTPS REST (port 7002)|
|
||||
|Pattern d'échange|Long-polling Search/Event/End|Messages q/m/n/s/b|POST + webhook callback|
|
||||
|Format des messages|Frames GALILEO bas niveau|Frames Rocla propriétaires|JSON REST|
|
||||
|Authentification|`TokenUser` dans `MainObject.config`|(intégrée au protocole Rocla)|`X-API-Key`|
|
||||
|Tables/storage côté flotte|(Galileo a son propre stockage)|SQLite locale (`WCSROCLATASK`) pour mapping interne|(BDD partagée Mecalux uniquement)|
|
||||
|Liaison côté Mecalux|(autre architecture)|**Abonnement direct aux workflows** (`Galileo_SearchCreatedEventHandler_PR`, etc.) — héritage EasyB|**Tables `AGV_*`** (architecture moderne)|
|
||||
|Configuration|`MainObject.config`|`Communications.config` + JSON (Stations/Addresses/ContainerTypes/HeightTypes)|`appsettings.json` ASP.NET Core|
|
||||
|Logs|`C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`|`C:\ProgramData\Mecalux\EasyWMS GatewayRocla 2015\Logs\`|Logging ASP.NET (Serilog/log4net selon standard projet)|
|
||||
|Architecture|Monolithique|Monolithique (Gateway Mecalux + middleware fusionnés)|**Découplée** via tables `AGV_*`|
|
||||
|Statut|Existant|Existant (historique)|À développer par Mecalux|
|
||||
|
||||
> 💡 **Architecture moderne vs historique** : le pattern Rocla (`EasyWMSGatewayRocla2015`) **fusionnait** la Gateway Mecalux et le middleware côté flotte en un seul service Windows monolithique qui s'abonnait directement aux workflows EasyWMS et écrivait sa propre base SQLite locale. Le pattern iGO **respecte la séparation moderne** : la Gateway AGV Mecalux (existant côté Mecalux) et la pool IIS C# (côté flotte) communiquent uniquement via les tables `AGV_*`. C'est plus propre, plus testable, et permet de changer le fleet manager sans toucher à la Gateway Mecalux.
|
||||
>
|
||||
> 💡 **Recommandation projet** : ne PAS partir d'un fork de `EasyWMSGatewayRocla2015` (qui est dans l'ancienne architecture monolithique), mais bâtir la pool IIS iGO **from scratch** sur ASP.NET Core .NET 8, avec une dépendance unique vers la base intermédiaire (côté Mecalux) et une dépendance HTTP/REST vers iGO PACS (côté flotte). Cela donne un livrable plus simple, plus testable, et conforme aux standards Mecalux actuels.
|
||||
|
||||
---
|
||||
|
||||
## 9. FAQ STILL — réponses officielles
|
||||
|
||||
> Réponses obtenues de STILL en avril 2026 sur les points clés d'intégration. Ces éléments **ont valeur contractuelle** et sont à intégrer aux workflows EasyWMS adaptés iGO.
|
||||
|
||||
### FAQ #1 — Identifiant véhicule au passage à `Assigned`
|
||||
|
||||
**Q.** Lors du passage en état `Assigned`, le payload webhook contient-il l'identifiant du véhicule (sens iGO → EasyWMS) ?
|
||||
|
||||
**R. STILL.** _Non, l'identifiant du véhicule n'est pas disponible au passage à `Assigned`. L'identifiant du véhicule fait partie du payload à partir du passage à l'état `Retrieved`._
|
||||
|
||||
**Impact EasyWMS.** Côté Gateway iGO : ne pas insérer la ligne AGE `EventType=103` avec un `StationNumber` au passage à `Assigned`. Insérer uniquement `EventType=103, Flags=0, StationNumber=null` (vehicle assigned mais inconnu), puis attendre le passage à `Retrieved` pour insérer `EventType=106` avec le `Vehicle.id` cette fois — ce qui déclenchera correctement `ProcessEvent_TaskAssigned_PR` côté core EasyWMS.
|
||||
|
||||
### FAQ #2 — Erreurs en cas d'`Aborted`
|
||||
|
||||
**Q.** En cas d'`Aborted`, reçoit-on un code ou message d'erreur dans le payload ?
|
||||
|
||||
**R. STILL.** _Non, nous recevons uniquement un POST avec l'état._
|
||||
|
||||
**Impact EasyWMS.** Le mapping vers les codes EasyWMS 2003 (extraction error) / 2004 (putaway error) / 2700 (wrong container) n'est **pas dérivable** du callback iGO seul. Côté Gateway iGO, à réception d'un `Aborted` :
|
||||
|
||||
- soit faire un `GET /api/vehicles/{id}` complémentaire pour récupérer `errors[].errorCode` / `errorLabel` du véhicule, et **traduire** dans `Flags` de la ligne AGE ;
|
||||
- soit insérer un `Flags` générique (à définir, par ex. `2003`) et laisser une notification AGV « Aborted — investigation nécessaire » se déclencher.
|
||||
|
||||
### FAQ #3 — Timestamp des événements
|
||||
|
||||
**Q.** Les événements webhook contiennent-ils un horodatage (timestamp) ?
|
||||
|
||||
**R. STILL.** _Non._
|
||||
|
||||
**Impact EasyWMS.** Le Gateway iGO **doit horodater à la réception** (`DateTime.UtcNow` au moment du POST entrant) avant l'insertion en table `AgeMessages` (champ `CreationDate`). Sinon perte d'information pour le LMS / les KPI / l'audit.
|
||||
|
||||
### FAQ #4 — Statut `New`
|
||||
|
||||
**Q.** Le statut `New` : quand apparaît-il et quelle est la différence avec `Requested` ?
|
||||
|
||||
**R. STILL.** _Le statut `New` est un statut interne qui n'existe qu'un instant. Vous pouvez considérer que le premier statut est `Requested`._
|
||||
|
||||
**Impact EasyWMS.** Pas de gestion à prévoir pour `New`. Le mapping commence directement à `Requested` (= phase EasyWMS 100 / `AgvStatus.Sent`).
|
||||
|
||||
### FAQ #5 — Création préalable des palettes (`Load`)
|
||||
|
||||
**Q.** Faut-il créer les palettes dans iGO (`POST /api/loads`) avant de créer un transport, ou peut-on inclure les infos palette directement dans la création du transport ?
|
||||
|
||||
**R. STILL.** _Ce n'est pas nécessaire. Ni même souhaitable. Cela augmenterait la complexité de votre côté. Le seul cas d'usage que nous connaissons pour l'utilisation des `Loads`, ce serait dans le cas où le système qui reçoit les palettes est différent de celui qui crée le transport._
|
||||
|
||||
**Impact EasyWMS.** Le Gateway iGO **ne doit PAS** appeler `POST /api/loads` en amont du transport. Toutes les informations utiles de la palette (`loadHostId` = `PalletId`, dimensions, customMetaData reprenant `HasTopper`, `PalletType`, `PalletSide` etc.) sont passées **directement dans l'objet `load`** du payload `POST /api/transports`. Cela simplifie le Gateway et évite un point de défaillance supplémentaire.
|
||||
|
||||
### FAQ #6 — Annulation après chargement
|
||||
|
||||
**Q.** Peut-on annuler un transport après que l'AGV a déjà pris la palette (état `Retrieved`) ?
|
||||
|
||||
**R. STILL.** _Non._
|
||||
|
||||
**Impact EasyWMS.** Pas de modification du workflow EasyWMS `AgvTask_SetCancelledTask_PR` lui-même — il continue à écrire une ligne EAG `Operation=Delete` comme d'habitude. **C'est le Gateway iGO** qui, à la lecture de cette ligne, doit :
|
||||
|
||||
```text
|
||||
Status iGO courant du transport ?
|
||||
├ Requested / Pending / Assigned / Retrieving
|
||||
│ → POST /api/transports/{id}/cancel ✅
|
||||
│ → Insère AGE EventType=255 quand iGO confirme l'annulation
|
||||
│
|
||||
├ Retrieved / Storing / Stored
|
||||
│ → ❌ Cancel impossible côté iGO (limite STILL)
|
||||
│ → Le Gateway répond NotifyError dans AGE (Flags spécifique)
|
||||
│ → Le module AGV core notifie l'utilisateur via le notification group AGV
|
||||
│ → Workflow alternatif côté process (attendre Finished + tâche retour, ou RFT)
|
||||
│
|
||||
└ Cancelled / Aborted / Finished → no-op (déjà terminal)
|
||||
```
|
||||
|
||||
Cette logique est **interne au Gateway iGO** et n'impacte pas le custom EasyWMS.
|
||||
|
||||
### FAQ #7 — Cas d'usage du `suspended`
|
||||
|
||||
**Q.** Le champ `suspended` : quel est son cas d'usage typique ?
|
||||
|
||||
**R. STILL.** _Cela pourrait être utile si besoin de créer le transport avant que la palette ne soit disponible. Dans notre cas, je ne vois pas à quoi cela pourrait servir._
|
||||
|
||||
**Impact EasyWMS.** Champ à **mettre à `false`** par défaut dans tous les `POST /api/transports`. Pas de cas d'usage immédiat dans le mapping standard EasyWMS — pourrait éventuellement servir pour de la pré-réservation dans des scénarios spéciaux (e-commerce wave preparation, etc.) mais hors scope du custom AGV générique.
|
||||
|
||||
### FAQ #8 — Authentification
|
||||
|
||||
**Q.** Authentification : faut-il utiliser `X-API-Key` ou `Bearer token` ?
|
||||
|
||||
**R. STILL.** _`X-API-Key`._
|
||||
|
||||
**Impact EasyWMS.** Le Gateway iGO envoie systématiquement le header :
|
||||
|
||||
```http
|
||||
X-API-Key: <clé fournie par STILL>
|
||||
```
|
||||
|
||||
Le `Authorization: Bearer <token>` mentionné dans certaines parties de la doc PACS est à **ignorer**. La clé est stockée chiffrée dans la config locale du Gateway (analogie : `PasswordEncrypt.exe` côté `EasyWMSGateway2015`).
|
||||
|
||||
### FAQ #9 — Politique de retry des webhooks
|
||||
|
||||
**Q.** En cas d'indisponibilité de notre serveur webhook, iGO retente-t-il l'envoi des événements ? Si oui, selon quelle politique ?
|
||||
|
||||
**R. STILL.** _iGO retente l'envoi mais nous ne savons pas à quelle fréquence. À tester._
|
||||
|
||||
**Impact EasyWMS.** Le Listener du Gateway iGO **doit être idempotent** : si iGO renvoie le même event 2 fois, ne pas insérer deux lignes dans AGE. Idempotency-key suggérée :
|
||||
|
||||
- `transport.id + transport.status` pour les events de transport ;
|
||||
- `vehicle.id + vehicle.status` pour les events véhicule (sans timestamp natif — cf. FAQ #3).
|
||||
|
||||
À implémenter via une table de déduplication interne au Gateway (cache rolling de quelques minutes), ou un index unique sur (`OrderExtId`, `Phase`) côté `AgeMessages`.
|
||||
|
||||
⚠️ **Action de test à mener** : pendant la phase d'intégration, simuler un Gateway iGO en panne pendant 30 s / 1 min / 5 min et observer le comportement réel d'iGO (nombre de retries, intervalles, abandon).
|
||||
|
||||
### FAQ #10 — Persistance après redémarrage iGO
|
||||
|
||||
**Q.** Les données de transport survivent-elles à un redémarrage iGO, ou sont-elles uniquement en mémoire vive ?
|
||||
|
||||
**R. STILL.** _Oui, les données survivent à un redémarrage du système._
|
||||
|
||||
**Impact EasyWMS.**
|
||||
|
||||
- Bonne nouvelle : pas besoin de re-pousser tous les transports en cours après un reboot iGO.
|
||||
- Cependant : les **subscriptions webhook** étaient marquées « _all transports that are still in the memory of E'tricc_ » dans la doc PACS § 2.2.1. Donc à clarifier : les **abonnements** survivent-ils aussi ? Si non, le Gateway doit ré-appeler `POST /api/transports/subscription` au redémarrage.
|
||||
- Recommandation : au boot du **Gateway iGO**, **toujours** :
|
||||
1. Appeler `GET /api/system` pour voir si la subscription existe.
|
||||
2. La (re)créer si absente.
|
||||
3. Faire un `GET /api/transports` pour réconcilier — comparer l'état iGO avec les transports en cours côté tables EAG/AGE et générer les lignes AGE manquantes si nécessaire.
|
||||
|
||||
### FAQ #11 — Communication directe ou via iGo Flow
|
||||
|
||||
**Q.** Communique-t-on directement avec l'API PACS ou via iGo Flow ?
|
||||
|
||||
**R. STILL.** _Directement avec l'API PACS._
|
||||
|
||||
**Impact EasyWMS.** Pas de couche d'orchestration intermédiaire « iGo Flow » à intégrer. Le Gateway iGO appelle directement `https://[IP]:7002/api/...` en HTTPS. Architecture simplifiée :
|
||||
|
||||
```text
|
||||
EAG/AGE/AGS ──▶ Gateway iGO ──HTTPS REST──▶ PACS Host API ──▶ iGo / E'tricc ──▶ AGV
|
||||
▲
|
||||
│
|
||||
(pas d'iGo Flow intermédiaire)
|
||||
```
|
||||
|
||||
### Synthèse FAQ — points-clés à intégrer dans le Gateway iGO
|
||||
|
||||
|#|Règle dérivée|
|
||||
|---|---|
|
||||
|1|N'insérer le `StationNumber` (= Vehicle.id) dans AGE qu'à partir de `Retrieved` (pas dès `Assigned`)|
|
||||
|2|Pour les `Aborted`, enrichir via `GET /api/vehicles/{id}` (errors[]) avant d'insérer la ligne AGE|
|
||||
|3|Horodater (`CreationDate`) chaque insertion AGE à la **réception** du callback|
|
||||
|4|Ignorer `New`|
|
||||
|5|**Ne PAS** appeler `POST /api/loads` en amont — passer les infos palette dans le transport|
|
||||
|6|À la lecture d'un EAG `Operation=Delete`, vérifier le `status` iGO courant : refuser si ≥ `Retrieved` et générer un Flags d'erreur dans AGE|
|
||||
|7|`suspended = false` par défaut dans `POST /transports`|
|
||||
|8|Header `X-API-Key` (jamais `Bearer`)|
|
||||
|9|Listener **idempotent** (transport.id + status comme clé de déduplication)|
|
||||
|10|À chaque boot du Gateway : vérifier subscriptions + réconcilier transports via `GET /transports`|
|
||||
|11|Pas de couche iGo Flow — appel direct port 7002|
|
||||
|
||||
---
|
||||
|
||||
## Annexes
|
||||
|
||||
### A. Glossaire rapide
|
||||
|
||||
|Sigle|Signification|
|
||||
|---|---|
|
||||
|**iGO easy**|Fleet manager AGV STILL (KION Group) — variante simple|
|
||||
|**PACS**|Productized Automated Concept Solutions — offre KION large couvrant iGO et au-delà|
|
||||
|**E'tricc**|Moteur interne du fleet manager (apparaît dans la doc PACS)|
|
||||
|**MyMA**|Suite logicielle KION : Vue3 + .NET8 + Postgres — héberge iGO côté admin|
|
||||
|**EXV CB iGo**|Modèle physique — gerbeur électrique automatisé STILL|
|
||||
|**TLS 1.2**|Niveau de chiffrement requis sur le port 7002|
|
||||
|**X-API-Key**|Authentification API officielle (FAQ #8)|
|
||||
|**iGo Flow**|Couche d'orchestration STILL — **non utilisée** dans l'intégration directe (FAQ #11)|
|
||||
|
||||
### B. Pointeurs sources
|
||||
|
||||
|Document|Section utile|
|
||||
|---|---|
|
||||
|`2510_PACS-2.3-Host-Interface-Technical-Specifications_en-US--STILL-.pdf`|Toute l'API REST (chap. 1-8)|
|
||||
|`iGo easy 2.3 - Host Interface Specifications.pdf`|Identique à PACS — confirmant que iGO easy = produit dérivé du même moteur|
|
||||
|`IT requirements R1 20250929.pdf`|Stack, ports, hardware|
|
||||
|`Technical specification EXV CB iGo.pdf`|Datasheet véhicule|
|
||||
|`Limagrain-LWM_Std_Interface_Compliance.xlsx`|Matrice de compliance projet — **à exploiter manuellement** (binaire non lu)|
|
||||
|
||||
### C. Cross-référence avec le module AGV EasyWMS
|
||||
|
||||
Pour le détail du module AGV EasyWMS qui sert de point de comparaison ici, voir le document compagnon `CR_ModuleAGV.md` dans le dossier `CstAGV/`.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Catalogue TK
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000653381660)
|
||||
> Dernière mise à jour : 10/09/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
## Nomenclature des Miniloads
|
||||
|
||||
**Lecture du code machine :**
|
||||
|
||||
- **ML** = Miniload
|
||||
- **B** = Bicolonne (si pas de B → simple colonne)
|
||||
- **EPSF** = Extracteur Pelle Simple Fond
|
||||
- **EPDF** = Extracteur Pelle Double Fond
|
||||
- **ECDF** = Extracteur Courroie Double Fond
|
||||
|
||||
> Les extracteurs **Pelle** n'ont qu'une seule charge. Les extracteurs **Courroie** en ont 2.
|
||||
|
||||
Il faut ensuite regarder le modèle de ML sur l'installation via le layout — les tables d'entrées/sorties seront adaptées en fonction du modèle.
|
||||
|
||||
> ℹ️ La page Confluence contient des schémas visuels des différents types de machines (ML, TK, APS). Se référer à Confluence pour les illustrations.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Changer l'adresse du WMS dans GALILEO
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552)
|
||||
> Dernière mise à jour : voir Confluence
|
||||
|
||||
---
|
||||
|
||||
> ℹ️ Cette page ne contient pas encore de contenu textuel sur Confluence (uniquement des captures d'écran non récupérables via API).
|
||||
>
|
||||
> Se référer directement à : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552)
|
||||
@@ -0,0 +1,33 @@
|
||||
# Codes de station
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001209683969)
|
||||
> Dernière mise à jour : 06/08/2025 (v1)
|
||||
|
||||
---
|
||||
|
||||
Tableau de correspondance des codes de station entre les versions française, espagnole et anglaise.
|
||||
|
||||
| Type | Code FR | Description FR | Code ES | Code EN | Description EN |
|
||||
|------|---------|---------------|---------|---------|---------------|
|
||||
| 0 | MAG | Magasin | ALM | AIS | Aisle |
|
||||
| 1 | ML / TK | Miniload / Transstockeur | TRASLO | STC | Stacker crane |
|
||||
| 2 | PK | Poste de picking | PK | PK | Picking station |
|
||||
| 3 | PIE | Poste d'identification d'entrées | PIE | EIP | Entry identification post |
|
||||
| 4 | PS | Poste de sortie | PS | SC | Shipping conveyor |
|
||||
| 5 | REAC | Poste de reconditionnement | REAC | REAC | Reconditioning station |
|
||||
| 7 | REJ | Poste de rejet | RECH | REJ | Rejection post |
|
||||
| 9 | TE | Table d'entrée au magasin | ME | IC | Input conveyor |
|
||||
| 10 | TS | Table de sortie du magasin | MS | OC | Output conveyor |
|
||||
| 11 | MU | Table de recherche d'emplacement | MU | MU | Location conveyor |
|
||||
| 13 | EMP | Empileur | APL | STK | Stacker |
|
||||
| 14 | NAV | Navette | LANZ | SHU | Shuttle |
|
||||
| 16 | TP | Table de préparation | MP | MP | Picking preparation station |
|
||||
| 18 | PKE | Poste d'entrée au PK | PKE | PKE | Picking entry post |
|
||||
| 20 | ET | Station de transit | ET | TS | Transit station |
|
||||
| 21 | CME | Poste de contrôle de table d'entrée | CME | ICS | Input control station |
|
||||
| 42 | RET | Poste de rétention de conteneurs | RET | RET | Container retention post |
|
||||
| 53 | PCS | Poste de contrôle de séquençage | PCS | SCP | Sequencing control point |
|
||||
| 54 | PB | Buffer de proximité | PB | PB | Proximity buffer |
|
||||
| 55 | ECB | Buffer de conteneurs vides | ECB | ECB | Empty container buffer |
|
||||
| 58 | ETQ | Étiqueteuse | ETQ | ETQ | Labeller |
|
||||
| 62 | LIFT | Élévateur | LIFT | LIFT | Lift |
|
||||
@@ -0,0 +1,115 @@
|
||||
# Communication Easy / Galileo
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001154797573)
|
||||
> Dernière mise à jour : 17/02/2026 (v8)
|
||||
|
||||
---
|
||||
|
||||
## Principe général
|
||||
|
||||
GALILEO n'a pas de vision prédictive. EasyWMS fait tout le travail d'intelligence. Les communications **partent toujours de GALILEO** — EasyWMS répond aux demandes et enregistre les états.
|
||||
|
||||
**3 types de messages + 2 types d'updates d'état.**
|
||||
|
||||
Les stations sont identifiées par un **couple type/numéro unique** dans les trames de communication.
|
||||
|
||||
- Types de stations : [Control_Communications_Interface_EN_GB.pdf](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf)
|
||||
- Structure des trames : [EasyWMSGateway_ControlInterface_EN.pdf](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf)
|
||||
|
||||
---
|
||||
|
||||
## La recherche d'ordre (log ⇒ Search)
|
||||
|
||||
GALILEO demande ses mouvements à exécuter à EasyWMS.
|
||||
|
||||
- Mouvements **"En attente"** : pas encore transmis à GALILEO
|
||||
- Mouvements **"En cours"** : transmis, conteneur en **Mov**
|
||||
|
||||
### 1. GALILEO envoie une demande d'ordre à la Gateway
|
||||
|
||||
Quand la machine est disponible (après fin d'ordre ou sans ordre), elle génère une demande d'ordre.
|
||||
|
||||
**Capacité de station :** nombre de trackings simultanés gérables.
|
||||
- **Exception PK et PS** : capacité = nombre max de conteneurs sur la station + en mouvement vers elle
|
||||
|
||||
**Différence capacité station vs capacité route :**
|
||||
- Capacité physique station PK : 1 bac (sur le convoyeur)
|
||||
- Capacité de la route vers PK : 4 bacs (en transit sur les convoyeurs intermédiaires)
|
||||
- Capacité de la station PK (au sens EasyWMS) : 15 bacs (physique + transit + tous les mouvements dont la tâche a PK comme destination)
|
||||
|
||||
### 2. GALILEO interroge Easy sur les mouvements à effectuer
|
||||
|
||||
Workflow principal : **`Galileo_SearchCreatedEventHandler_PR`**
|
||||
|
||||
> ⚠️ GALILEO peut envoyer plusieurs dizaines de Search par seconde. Il est **fortement déconseillé** d'activer les instances de workflows sur ces events sans précautions (limiter au process, temps de trace très court).
|
||||
|
||||
Le process est réorienté selon le type de station reçu.
|
||||
|
||||
### 3. Easy transmet les mouvements à GALILEO via la Gateway
|
||||
|
||||
Commandes appelées : `GalileoMovTrackingCreateCommand` (éviter `GalileoMovTrackingCreateChangingTargetCommand`).
|
||||
|
||||
Effets :
|
||||
- Envoi de l'ordre à la Gateway (traduit en trame pour GALILEO)
|
||||
- Le mouvement passe de **"Généré"** à **"En cours"**
|
||||
- Le conteneur est déplacé sur l'emplacement virtuel **Mov**
|
||||
|
||||
---
|
||||
|
||||
## La fin d'ordre (log ⇒ End0)
|
||||
|
||||
Signale que le mouvement est terminé. Le mouvement suivant est généré si le conteneur n'a pas encore atteint la destination finale.
|
||||
|
||||
### Codes d'erreur End
|
||||
|
||||
| Code | Signification | Conséquence |
|
||||
|------|--------------|-------------|
|
||||
| `0` | Mouvement terminé | Lance le mouvement suivant |
|
||||
| `1` | Erreur de dépose | Masque d'erreur + relocalisation/rejet |
|
||||
| `2` | Erreur d'extraction | Masque d'erreur + relocalisation/rejet |
|
||||
| `4` | Ordre incohérent | Problème de configuration WMS/GALILEO |
|
||||
| `7` | Erreur gabarit | Relocalisation/rejet |
|
||||
|
||||
Workflow de traitement : **`Galileo_EndCreatedEventHandler_PR`**
|
||||
|
||||
### Cas EndErrorCode=4
|
||||
|
||||
Configuration incohérente entre WMS et GALILEO.
|
||||
|
||||
**Causes possibles :**
|
||||
- L'emplacement n'existe pas pour GALILEO, n'accepte pas le type/hauteur du support, coordonnées X/Y hors limites
|
||||
- Mouvements impossibles (bacs qui doivent se croiser)
|
||||
- Attention : la gestion des coordonnées diffère selon le côté de la table d'entrée par rapport à l'allée
|
||||
|
||||
**Résolution :** vérifier les données envoyées à GALILEO dans les logs, puis comparer la configuration des stations entre les deux systèmes.
|
||||
|
||||
---
|
||||
|
||||
## L'update de station (log ⇒ Update station)
|
||||
|
||||
Envoyée toutes les **1-3 secondes** ou au changement de statut/chargement.
|
||||
|
||||
| Paramètre | Signification |
|
||||
|-----------|---------------|
|
||||
| StationType | Type de la station |
|
||||
| StationNumber | Numéro de la station |
|
||||
| Status | `0` = Indisponible (défaut, manuel, sécurité), `1` = Disponible |
|
||||
| Loaded | `0` = Occupée (chargée), `1` = Disponible |
|
||||
| Capacity | Nombre max de conteneurs |
|
||||
| CurrentCount | Nombre de trackings GALILEO sur la station |
|
||||
| Aisle | Numéro d'allée |
|
||||
|
||||
---
|
||||
|
||||
## L'update de route (log ⇒ Update route)
|
||||
|
||||
Envoyée toutes les **1-3 secondes** ou au changement. Pilotée par la disponibilité électromécanique et la place disponible.
|
||||
|
||||
| Paramètre | Signification |
|
||||
|-----------|---------------|
|
||||
| StationTypeSource | Type station d'origine |
|
||||
| StationNumberSource | Numéro station d'origine |
|
||||
| StationTypeDestination | Type station destination |
|
||||
| StationNumberDestination | Numéro station destination |
|
||||
| Status | `0` = Pas de communication, `1` = Disponible, `2` = Défaut électromécanique, `3` = Pleine |
|
||||
| CurrentCount | Nombre de trackings GALILEO entre ces stations |
|
||||
@@ -0,0 +1,76 @@
|
||||
# Communication WMS - GALILEO
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001208930341)
|
||||
> Dernière mise à jour : 07/08/2025 (v7)
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Une installation robotique communique avec le WMS via le service Windows **"EasyWMS Gateway"** installé sur le serveur WMS.
|
||||
|
||||
---
|
||||
|
||||
## Tâches et mouvements
|
||||
|
||||
Pour chaque déplacement de conteneur, le WMS envoie un **ordre de transfert** (tâche) à GALILEO.
|
||||
|
||||
- **Tâche** = ordre de transfert de bout en bout
|
||||
- **Mouvement** = déplacement d'une station à la suivante (plusieurs mouvements par tâche)
|
||||
|
||||
**Statuts des tâches :**
|
||||
|
||||
| Statut | Description |
|
||||
|--------|-------------|
|
||||
| En attente | Pas encore transmise à GALILEO, aucun tracking |
|
||||
| Générée | Prochain mouvement généré mais non transmis |
|
||||
| En cours | Tracking récupéré par GALILEO, conteneur en **Mov** |
|
||||
| Terminée | Conteneur arrivé à destination |
|
||||
| Annulée | Annulée avant d'atteindre la destination |
|
||||
|
||||
---
|
||||
|
||||
## 3 types de communication
|
||||
|
||||
### Events
|
||||
|
||||
GALILEO envoie un Event principalement lors du passage au PIE ou à la confirmation d'un picking.
|
||||
|
||||
**Event PIE contient :**
|
||||
- Code du bac
|
||||
- Poids
|
||||
- Dimensions
|
||||
- Type de support (P800, P1000…)
|
||||
- Code Erreur : `65536` = pas d'erreur
|
||||
|
||||
Workflow WMS appelé : **`Galileo_PIEEventHandler_PR`**
|
||||
|
||||
Pour activer les instances sur les Events PIE : activer le process `NomPIE_NomEntrepot_GalileoPIE` dans l'ApplicationService.
|
||||
|
||||
### Search
|
||||
|
||||
Deux cas de déclenchement :
|
||||
1. GALILEO demande la station suivante pour le support qu'il vient de recevoir
|
||||
2. Un TK/Miniload fait des recherches en boucle (en "recherche d'ordre" quand il n'a rien à faire)
|
||||
|
||||
**Contenu d'un Search :**
|
||||
- Numéro de tracking
|
||||
- Numéro du support
|
||||
- Identifiants de la station (Type + Numéro)
|
||||
|
||||
### End
|
||||
|
||||
Envoyé quand GALILEO termine un ordre (bac arrivé à la destination du mouvement — pas de la tâche).
|
||||
|
||||
---
|
||||
|
||||
## Cas pratique — bac arrivant au PIE
|
||||
|
||||
1. PIE génère un **Event** (lecture code barres + gabarit) puis un **Search**
|
||||
2. WMS envoie un mouvement → support passe en **Mov**
|
||||
3. Bac arrive à la station suivante → GALILEO envoie un **End**
|
||||
4. Si convoyeur → nouveau **Search** ; si table d'entrée TK → c'est le TK qui fait les Search en boucle
|
||||
5. Si poste de sortie → support sort de l'installation
|
||||
6. Si poste de picking → **Search** après confirmation du picking via un Event
|
||||
|
||||
> Tous ces échanges sont visibles dans les logs de la Gateway : voir [Comprendre les logs de la Gateway](https://easywmsfrance.atlassian.net/wiki/x/AoDSoLoC)
|
||||
@@ -0,0 +1,81 @@
|
||||
# Comprendre les logs de la Gateway
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000585322498)
|
||||
> Dernière mise à jour : 06/08/2025 (v10)
|
||||
|
||||
---
|
||||
|
||||
Emplacement des logs : `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`
|
||||
|
||||
---
|
||||
|
||||
## Update des stations
|
||||
|
||||
Toutes les secondes, GALILEO renvoie au WMS l'état de l'ensemble des stations.
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| **StationType** | Type de station configuré dans le WMS |
|
||||
| **StationNumber** | Numéro de station configuré dans le WMS |
|
||||
| **Status** | `1` = Prêt, `0` = Erreur |
|
||||
| **Loaded** | `1` = Libre, `0` = Chargé |
|
||||
| **Capacity** | Nombre de supports max sur la station |
|
||||
| **CurrentCount** | Nombre de trackings en cours sur la station |
|
||||
| **Aisle** | Numéro d'allée associé à la station |
|
||||
|
||||
> Le couple **StationType + StationNumber** est unique → permet d'identifier précisément la station.
|
||||
|
||||
---
|
||||
|
||||
## Update des routes
|
||||
|
||||
GALILEO transmet l'état de certaines routes (point entre 2 stations).
|
||||
|
||||
| Champ | Description |
|
||||
|-------|-------------|
|
||||
| StationTypeSource | Type de la station d'origine |
|
||||
| StationNumberSource | Numéro de la station d'origine |
|
||||
| StationTypeDestination | Type de la station de destination |
|
||||
| StationNumberDestination | Numéro de la station de destination |
|
||||
| **Status** | `1` = libre, `3` = pleine |
|
||||
|
||||
---
|
||||
|
||||
## Event
|
||||
|
||||
Exemple d'un event reçu par le PIE : contient le code barres lu, le poids, les dimensions, les types de support et hauteur.
|
||||
|
||||
---
|
||||
|
||||
## Search
|
||||
|
||||
Exemple d'un Search fait par un TK : la station demande son prochain ordre au WMS.
|
||||
|
||||
---
|
||||
|
||||
## End
|
||||
|
||||
Exemple d'un End sur une table de sortie TK : confirmation que le bac est arrivé à destination.
|
||||
|
||||
**Pour rechercher ce qu'il s'est passé sur une palette dans klogg :**
|
||||
1. `DataInfo.+_CodeSupport_` → données reçues au PIE
|
||||
2. `Movement=_NuméroDeTâche_` → ce qu'il s'est passé ensuite
|
||||
|
||||
---
|
||||
|
||||
## Gestion des erreurs
|
||||
|
||||
### Ordre incohérent (EndErrorCode=4)
|
||||
|
||||
Quand GALILEO ne comprend pas un ordre → renvoie **EndErrorCode=4**.
|
||||
|
||||
Signifie généralement un problème de configuration entre WMS et GALILEO.
|
||||
|
||||
**Cas d'erreur possibles :**
|
||||
- Configuration différente des 2 côtés : emplacement inexistant pour Galileo, n'accepte pas le type/hauteur du support, coordonnées hors limites
|
||||
- Vérifier les données envoyées à GALILEO dans les logs
|
||||
|
||||
**Vérifier la configuration côté GALILEO :**
|
||||
1. Ouvrir le programme GALILEO dans `c:\NomDuClient\Programme` → double-cliquer sur le fichier `.mgp`
|
||||
2. Comparer la configuration des stations entre GALILEO et EasyS
|
||||
3. Utiliser la requête de récupération des stations WMS (voir [Plan de tests des stations](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000584536089))
|
||||
@@ -0,0 +1,139 @@
|
||||
# Configuration EasyS (Robotique)
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000286838807)
|
||||
> Dernière mise à jour : 12/01/2026 (v20)
|
||||
|
||||
---
|
||||
|
||||
## Environnement de démo
|
||||
|
||||
Un miniload avec chemin de convoyage est disponible sur la VM **ALL** du serveur **LYOITSW02** :
|
||||
- IP : `10.58.10.75`
|
||||
- Identifiants : `mecalux / mecalux`
|
||||
- Warehouse : `WRH_MIXTE`
|
||||
|
||||
---
|
||||
|
||||
## Configuration des supports et emplacements
|
||||
|
||||
Les emplacements et stations doivent être configurés avec :
|
||||
- **DeleteEmptyContainers** = `Not Delete`
|
||||
- Exception : les postes de picking peuvent être en mode `Delete` ou `Ask` si l'opérateur retire les bacs vides
|
||||
- **Mode de stockage** = `Only Containers`
|
||||
|
||||
### Configuration des racks
|
||||
|
||||
Les emplacements dans le miniload doivent être associés à un **rack type** avec les dimensions précises du plan d'exécution. Chaque type de rack doit indiquer quel type de support peut y être stocké.
|
||||
|
||||
### Configuration des PLC Types
|
||||
|
||||
Au passage au PIE, un contrôle gabarit est fait. GALILEO retourne :
|
||||
- **PLC Container Type** (en fonction de la largeur)
|
||||
- **PLC Height Type** (en fonction de la hauteur)
|
||||
|
||||
**Procédure :**
|
||||
1. Ouvrir le menu **PLC Types**
|
||||
2. Définir les différentes hauteurs de bacs
|
||||
3. Associer chaque type de support à un PLC Container Type
|
||||
|
||||
### Configuration des emplacements
|
||||
|
||||
Pour simuler un TK : ajouter une **allée automatique**.
|
||||
|
||||
Le lien allée automatique ↔ rack s'effectue comme pour une allée manuelle. Ensuite :
|
||||
1. Sélectionner le rack et l'associer à la station miniload/TK
|
||||
2. Double-cliquer sur le rack pour configurer les emplacements
|
||||
3. Associer chaque emplacement à son **rack type**
|
||||
|
||||
---
|
||||
|
||||
## Les différentes stations
|
||||
|
||||
| Type de station | Rôle |
|
||||
|----------------|------|
|
||||
| **Automatic Aisle** | Transstockeur ou Miniload |
|
||||
| **PIE** | Identification des supports (lecture étiquette + pesée) |
|
||||
| **Picking (PK)** | Poste de picking sur convoyeur |
|
||||
| **PKE** | Contrôle l'entrée vers un PK (si plein → recirculation) |
|
||||
| **Inbound Table (ME)** | Convoyeur d'entrée vers TK/Miniload |
|
||||
| **Outbound Table (MS)** | Convoyeur de sortie d'un TK/Miniload |
|
||||
| **CME** | Contrôle l'entrée vers TK/Miniload (si plein → recirculation) |
|
||||
| **Outbound Post** | Convoyeur de sortie de l'installation (le support peut être prélevé par un cariste) |
|
||||
| **MP** | Table de préparation (dépôt du stock client après prélèvement) |
|
||||
| **Transporter** | Convoyeur sans fonction particulière |
|
||||
|
||||
> Les éléments d'automatisation se trouvent dans la catégorie **Automatic elements** d'EasyS.
|
||||
|
||||
---
|
||||
|
||||
## Configuration des zones de rangement (rack double profondeur)
|
||||
|
||||
**Cas #1** (le plus souvent chez Mecalux) — adapté aux supports **mono-référence** (plusieurs supports avec le même article dans le TK) : zones de rotation séparées par face avant/arrière.
|
||||
|
||||
**Cas #2** — mieux adapté aux supports **multi-référence** (jamais d'article rangé dans plusieurs supports en même temps) : réduit les relocalisations pendant le picking sans défragmentation d'avance.
|
||||
|
||||
---
|
||||
|
||||
## La configuration des routes
|
||||
|
||||
Dans la robotique, la notion de routes est très présente. Sur chaque station convoyeur, on définit vers quelle autre station le support peut aller.
|
||||
|
||||
Une tâche `PIE → Miniload` peut générer 4 mouvements intermédiaires. Le WMS crée **une seule tâche** mais avec **N mouvements**.
|
||||
|
||||
Pour qu'un mouvement puisse être généré, une route doit exister dans EasyS entre la station d'origine et la station de destination.
|
||||
|
||||
> Si le WMS ne trouve pas de chemin, une tâche de rejet est créée vers la station de rejet.
|
||||
|
||||
L'ensemble des routes configurées est visible dans **Menu → Contrôle → Itinéraires entre les stations**.
|
||||
|
||||
### Types de routes
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| **Galileo** | Mouvement nécessitant des appels au service Galileo pour communiquer avec les convoyeurs |
|
||||
| **Manual** | Mouvement nécessitant une action de l'opérateur suite à une tâche WMS |
|
||||
| **Virtual** | Mouvement automatique et virtuel du stock (ex. sortie vers zone consolidation) |
|
||||
|
||||
---
|
||||
|
||||
## Configuration des convoyeurs
|
||||
|
||||
### Tables d'entrée (TE) et de sortie (TS) du TK
|
||||
|
||||
Peuvent contenir plusieurs supports simultanément. Configuration :
|
||||
1. Dimensions physiques suffisantes pour accueillir les supports
|
||||
2. Disposition des supports en **Positions** (côte à côte) et **Stack** (l'un derrière l'autre)
|
||||
3. **Logical X** = 991 (sauf tables dans le rack qui prennent les coordonnées de l'emplacement remplacé)
|
||||
|
||||
### Tables multidirectionnelles (LTM)
|
||||
|
||||
Configurer les **routing options** en mettant `1` pour chaque convoyeur depuis lequel un bac peut arriver.
|
||||
|
||||
---
|
||||
|
||||
## Configuration du picking
|
||||
|
||||
### Poste de picking
|
||||
|
||||
1. Ajouter un convoyeur avec le rôle **Picking**
|
||||
2. Créer une **Workstation** pour interagir avec le poste depuis SmartUI
|
||||
3. Définir les routes : d'où peut arriver le stock et où il peut aller en partant du PK
|
||||
|
||||
### Tables de préparation
|
||||
|
||||
- Route type **Manuel** : de la table de picking vers les tables de préparation
|
||||
- Route type **Galileo** : des tables de préparation vers la table de sortie
|
||||
- Route type **Virtual** : vers la zone de consolidation (simulation automatique)
|
||||
|
||||
---
|
||||
|
||||
## Configuration du rejet
|
||||
|
||||
La route de rejet permet au WMS de rediriger les supports sans route valide.
|
||||
|
||||
Configurer des routes de type **GALILEO** depuis les principales stations vers la station **REJECT**, puis une route **VIRTUAL** vers la zone au sol pour déplacer automatiquement les supports perdus.
|
||||
|
||||
> À la différence des routes classiques, les routes de rejet (en rouge) donnent la **destination de la tâche de rejet** (pas du mouvement).
|
||||
|
||||
Il est possible de rejeter vers différentes destinations en fonction de la raison du rejet (`IdentError`) :
|
||||
- Liste des IdentErrors EasyS : [https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md)
|
||||
@@ -0,0 +1,30 @@
|
||||
# Configuration SmartUI (Robotique)
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000286674947)
|
||||
> Dernière mise à jour : 14/05/2024 (v7)
|
||||
|
||||
---
|
||||
|
||||
## Configuration des tables de préparation
|
||||
|
||||
Une table de préparation est associée à un poste de picking. Une fois le picking validé, le stock est déplacé du bac vers la table de préparation choisie.
|
||||
|
||||
**Mode d'assignation :**
|
||||
- **Automatique** : le WMS assigne la prochaine commande à la table automatiquement
|
||||
- **Manuel** : aller dans **Menu → Contrôle → Assignation des postes de picking** pour définir sur quelle table de préparation associer la commande
|
||||
|
||||
> ⚠️ En mode manuel, les tâches ne se génèrent pas tant que l'ordre de sortie n'est pas assigné à une table.
|
||||
|
||||
Pour changer le mode : **Menu → Contrôle → Postes de travail** → sélectionner la ou les tables de préparation → **"Modifier le mode d'assignation"**.
|
||||
|
||||
> ⚠️ La table de préparation doit avoir une route vers le quai d'expédition de la commande, sinon les tâches ne se génèreront pas.
|
||||
|
||||
---
|
||||
|
||||
## Configuration des tables de picking
|
||||
|
||||
Pour définir le **nombre maximum de commandes** pouvant être traitées simultanément par une table de picking :
|
||||
|
||||
**Menu → Contrôle → Postes de travail** → sélectionner la station de picking → modifier la valeur.
|
||||
|
||||
> Ce nombre doit être **égal au nombre de tables de préparation** associées à la table de picking.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Configuration d'une clé SSH pour MSSCODE et Sourcetree
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001191137289/Configuration+d%27une+cl%C3%A9+SSH+pour+MSSCODE+et+Sourcetree)
|
||||
> Dernière mise à jour : 28/01/2026 (v2)
|
||||
|
||||
---
|
||||
|
||||
## 1. Génération d'une clé SSH
|
||||
|
||||
### Prérequis
|
||||
|
||||
S'assurer que **Git est installé** sur l'ordinateur, puis ouvrir **Git Bash**.
|
||||
|
||||
### Étapes
|
||||
|
||||
1. Exécuter la commande suivante pour générer une clé SSH :
|
||||
|
||||
```shell
|
||||
ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
2. À la question suivante, appuyer sur **Entrée** pour accepter le chemin par défaut :
|
||||
|
||||
```
|
||||
Enter file in which to save the key (/c/Users/VOUS/.ssh/id_ed25519):
|
||||
```
|
||||
|
||||
3. Saisir un mot de passe pour sécuriser la clé (fortement recommandé) :
|
||||
|
||||
```
|
||||
Enter passphrase (empty for no passphrase): [Tapez un mot de passe]
|
||||
Enter same passphrase again: [Répétez le même mot de passe]
|
||||
```
|
||||
|
||||
> ⚠️ Le mot de passe défini est **unique** et **non modifiable**. En cas d'oubli, il faudra générer une nouvelle paire de clés.
|
||||
|
||||
---
|
||||
|
||||
## 2. Ajout de la clé SSH sur MSSCODE
|
||||
|
||||
1. Se connecter à **MSSCODE** et accéder à la gestion des clés SSH
|
||||
2. Cliquer sur **"Ajouter une clé"**
|
||||
3. Donner un nom à la clé (ex : `Auth`)
|
||||
4. Copier-coller le **contenu complet** du fichier `.pub` généré. Ce fichier se trouve par défaut dans :
|
||||
|
||||
```
|
||||
C:\Users\VOUS\.ssh\id_ed25519.pub
|
||||
```
|
||||
|
||||
5. Une fois la clé ajoutée, MSSCODE demandera de **vérifier la clé** via une signature SSH renforcée
|
||||
|
||||
> ⚠️ **Ne pas copier** la commande d'exemple affichée dans cette documentation — le **jeton de vérification change** à chaque fois.
|
||||
> Utiliser la commande fournie **par MSSCODE**, en y ajoutant le chemin vers votre clé privée entre apostrophes `'`.
|
||||
|
||||
### Exemple de commande de vérification :
|
||||
|
||||
```shell
|
||||
echo -n 'votre_jeton_unique' | ssh-keygen -Y sign -n gitea -f 'C:\Users\VOUS\.ssh\id_ed25519'
|
||||
```
|
||||
|
||||
Après avoir saisi le mot de passe de la clé SSH, une **signature** sera générée. La copier dans l'encart **"Signature SSH renforcée"** sur MSSCODE, puis cliquer sur **"Vérifier"**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Configuration de la clé dans Sourcetree
|
||||
|
||||
1. Ouvrir **Sourcetree**
|
||||
2. Aller dans le menu **Tools** → **Options**
|
||||
3. Dans l'onglet **General**, section **SSH Client Configuration** :
|
||||
- Sélectionner **`OpenSSH`** comme client SSH
|
||||
- Cliquer sur le bouton **`[...]`** pour sélectionner votre fichier de **clé privée** (ex : `id_ed25519`)
|
||||
4. Sourcetree demandera de saisir le **mot de passe** de la clé SSH — le saisir et valider
|
||||
|
||||
---
|
||||
|
||||
## ✅ Résultat
|
||||
|
||||
Sourcetree pourra désormais accéder à MSSCODE **sans redemander le mot de passe MSSCODE** (plus de verrou de session). Cependant, **le mot de passe de la clé SSH sera requis à chaque ouverture** de Sourcetree.
|
||||
|
||||
> 🔒 Il est possible de générer une clé SSH sans mot de passe, mais cela est fortement **déconseillé** pour des raisons de sécurité.
|
||||
|
||||
---
|
||||
|
||||
> ⚠️ **Important** : lorsqu'on utilise une clé SSH pour s'authentifier, il faut cloner les dépôts Git via le **lien SSH** (et non HTTPS) — sinon Sourcetree continuera à demander les identifiants MSSCODE.
|
||||
@@ -0,0 +1,38 @@
|
||||
# Convoyeur terminologie
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000346607617)
|
||||
> Dernière mise à jour : 14/05/2024 (v3)
|
||||
|
||||
---
|
||||
|
||||
## Nom des convoyeurs
|
||||
|
||||
### LRA — Convoyeur à rouleaux d'accumulation
|
||||
|
||||
Capacité : **1 bac**. Le tracking passe de LRA en LRA à chaque fois que le bac change de LRA. Les bacs peuvent être **arrêtés** sur une LRA.
|
||||
|
||||
### LRC — Convoyeur à rouleaux continu
|
||||
|
||||
Les bacs avancent tant que le capteur de fin ne détecte pas le bac. Capacité : **plusieurs bacs**. En général, perte de tracking lorsqu'un bac passe sur ce type de convoyeur.
|
||||
|
||||
### LRAB — Convoyeur à rouleaux d'accumulation avec balance
|
||||
|
||||
### LTM — Convoyeur mixte
|
||||
|
||||
Changement de direction à 90°.
|
||||
|
||||
### LRD (D = Déviation) — Convoyeur à rouleaux obliques de sortie
|
||||
|
||||
### LRI (I = Insertion) — Convoyeur à rouleaux obliques à induction (entrée)
|
||||
|
||||
### LBC — Convoyeur à bande
|
||||
|
||||
Les bacs **perdent leur tracking** sur ce type de convoyeur.
|
||||
|
||||
### LRL — Rouleau libre (pas de moteur)
|
||||
|
||||
Convoyeur gravitaire. Aucun tracking n'est associé aux bacs sur ces convoyeurs. En général, un poste de sortie est configuré en amont. Le WMS considère que les bacs sont localisés sur un **buffer**.
|
||||
|
||||
### Passage piéton
|
||||
|
||||
Passage au-dessus de l'installation.
|
||||
@@ -0,0 +1,10 @@
|
||||
# DTR configuration réseau et matériel
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980)
|
||||
> Dernière mise à jour : 09/07/2024 (v2)
|
||||
|
||||
---
|
||||
|
||||
Ce document (**DTR — Document Technique de Référence**) permet de définir les éléments techniques (matériels, adresses IP, services…) nécessaires pour une installation automatisée, avec les responsabilités entre Mecalux et le client.
|
||||
|
||||
> ℹ️ Le document DTR est disponible sous forme de tableau sur [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980). Se référer à Confluence pour accéder au modèle complet.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Déploiement d'une VM sur un commit spécifique
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000230707201/D%C3%A9ploiement+d%27une+VM+sur+un+commit+sp%C3%A9cifique)
|
||||
> Dernière mise à jour : 09/06/2023 (v3)
|
||||
|
||||
---
|
||||
|
||||
Dans plusieurs situations, il est utile de pouvoir déployer un commit spécifique au lieu de la dernière version de la branche `develop`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Mettre à jour le répertoire git en local
|
||||
|
||||
Lancer **Sourcetree**, importer votre projet et réaliser un **"Fetch"** en veillant bien à cocher **"Fetch all tags"**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Identifier un commit et le taguer
|
||||
|
||||
> ⚠️ L'identification du commit peut être délicate. N'hésitez pas à demander un avis extérieur si vous n'êtes pas sûr.
|
||||
|
||||
Une fois le commit cible identifié :
|
||||
|
||||
1. Faire un **clic droit** sur le commit → sélectionner **"Tag"**
|
||||
2. Nommer le tag en utilisant le **préfixe Jira** du projet suivi d'un numéro de version
|
||||
|
||||
**Convention de nommage :**
|
||||
|
||||
```
|
||||
<PREFIXE_JIRA>-V<NUMERO>
|
||||
```
|
||||
|
||||
Exemple pour le projet Spengler (préfixe `SPEN`) :
|
||||
|
||||
```
|
||||
SPEN-V1
|
||||
SPEN-V2
|
||||
...
|
||||
```
|
||||
|
||||
3. **Pousser le tag** sur le répertoire distant.
|
||||
|
||||
---
|
||||
|
||||
## 3. Créer une branche
|
||||
|
||||
Sur le commit précédemment tagué :
|
||||
|
||||
1. Faire un **clic droit** → sélectionner **"Branch"**
|
||||
2. Nommer la branche
|
||||
3. **Pousser la branche** sur le répertoire distant
|
||||
|
||||
---
|
||||
|
||||
## 4. Déployer
|
||||
|
||||
Une fois la branche poussée sur le répertoire distant, déployer classiquement la VM en **référençant la nouvelle branche** au lieu de `develop` :
|
||||
|
||||
```powershell
|
||||
.\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche
|
||||
```
|
||||
@@ -0,0 +1,145 @@
|
||||
# Déploiement d'une application existante
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089575437/D%C3%A9ploiement+d%27une+application+existante)
|
||||
> Dernière mise à jour : 04/07/2024 (v20)
|
||||
|
||||
---
|
||||
|
||||
### 1 - Vérifier le fichier "env.secrets.yaml" du Deploy
|
||||
|
||||
Vérifier les informations concernant la base de données utilisée sur le projet.
|
||||
|
||||
**Pour Oracle :**
|
||||
|
||||
| Paramètre | Valeur par défaut |
|
||||
|-----------|-------------------|
|
||||
| `Engine` | `Oracle` |
|
||||
| `Server` | `localhost/orcl` |
|
||||
| `Password` (des différentes bases) | `robmec` |
|
||||
|
||||
**Pour PostgreSQL :**
|
||||
|
||||
| Paramètre | Valeur par défaut |
|
||||
|-----------|-------------------|
|
||||
| `Engine` | `PostgreSQL` |
|
||||
| `Server` | `localhost` |
|
||||
| `Password` (des différentes bases) | `robmec` |
|
||||
|
||||
---
|
||||
|
||||
### 2 - Déploiement complet
|
||||
|
||||
Ouvrir **PowerShell en administrateur** dans le dossier `Deploy` de la VM.
|
||||
|
||||
> Pour se déplacer dans le dossier Deploy depuis PowerShell : `cd C:\deploy`
|
||||
|
||||
Par défaut la commande utilise la branche **Master** du projet Git. Pour déployer une branche spécifique, ajouter son nom après le nom du projet.
|
||||
|
||||
```powershell
|
||||
# Déploiement sur la branche Master (par défaut)
|
||||
.\deploy_repository.ps1 NomDuProjetGit
|
||||
|
||||
# Déploiement sur une branche spécifique
|
||||
.\deploy_repository.ps1 NomDuProjetGit Branche
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```powershell
|
||||
.\deploy_repository.ps1 1707_FRANCE_MA_PIECES_AUTOS_BRETAGNE develop
|
||||
```
|
||||
|
||||
> Plus de détails sur l'exécution du script : [Documentation Mecalux](https://msscc.mecalux.com/documentation/ExternalProcedures/master/EN/ProfessionalServices/TaskWorkBreakDownAndVerification/TaskWorkBreakdownAndVerification.md#md-developmentenvironmentarchitecture)
|
||||
|
||||
> ℹ️ D'après l'Espagne, il devrait être possible de déployer n'importe quelle version depuis la **21.1.19.2**. Si ce n'est pas le cas, ouvrir un ticket.
|
||||
|
||||
> En cas d'erreur : consulter la page [Installation machine virtuelle de développement](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/2786690269319) au paragraphe **"Deploy 1"**.
|
||||
|
||||
> ✅ Sans erreur, vous pouvez **sauter les étapes 3, 4, 5 et 6**.
|
||||
> ⚠️ L'**étape 7 est obligatoire** dans tous les cas.
|
||||
|
||||
---
|
||||
|
||||
### 3 - Deploy 1 *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans le dossier `Deploy` de la VM et exécuter :
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1
|
||||
```
|
||||
|
||||
Choisir **"1. Complete"**.
|
||||
|
||||
> En cas d'erreur : consulter la page [Installation machine virtuelle de développement](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/2786690269319) au paragraphe **"Deploy 1"**.
|
||||
|
||||
---
|
||||
|
||||
### 4 - Intégrer la configuration d'entrepôt *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans le dossier `Deploy` de la VM et exécuter :
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1
|
||||
```
|
||||
|
||||
Choisir **"2. Load"**.
|
||||
|
||||
Cela transférera :
|
||||
- La configuration entrepôt depuis **`C:\deploy\Config`**
|
||||
- Les paramètres exportés via uGNA depuis **`C:\deploy\Data`**
|
||||
|
||||
> Il est également possible d'utiliser **EasyS** pour charger le fichier de config via un *Transfert Data* vers la VM.
|
||||
|
||||
---
|
||||
|
||||
### 5 - Assignation de l'utilisateur à l'entrepôt *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans **`C:\deploy`** et exécuter :
|
||||
|
||||
```powershell
|
||||
.\Commands\commands.ps1
|
||||
```
|
||||
|
||||
Il est aussi possible de faire l'assignation via le WMS : dans **SmartUI**, aller dans **"Organisation"** → **"Utilisateurs"**, sélectionner l'utilisateur (par défaut `mecalux`) et l'éditer pour ajouter les sites autorisés.
|
||||
|
||||
---
|
||||
|
||||
### 6 - Faire l'import de l'application custom *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Suivre la documentation : [Gestion de la custom application — Import](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673775/Gestion+de+la+custom+application#2---Import-de-l%27application-custom)
|
||||
|
||||
---
|
||||
|
||||
### 7 - Désactiver les instances stockées sur la base de données
|
||||
|
||||
> ⚠️ **Cette étape est obligatoire.** Sans cette modification, les instances ne fonctionneront pas.
|
||||
|
||||
Dans le fichier **`Tenants.xml`** situé dans `C:\inetpub\wwwroot\ApplicationService`, remplacer la ligne :
|
||||
|
||||
```xml
|
||||
<processStore name="TENANT ProcessStore" providerName="Oracle.ManagedDataAccess.Client" … />
|
||||
```
|
||||
|
||||
par :
|
||||
|
||||
```xml
|
||||
<processStore name="TENANT ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>
|
||||
```
|
||||
|
||||
Puis effectuer un redémarrage de l'application (`iisreset` ou recyclage du pool de l'ApplicationService) — voir : [Restart pool + iisreset](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000244731905).
|
||||
|
||||
#### Astuce Notepad++ (remplacement automatique multi-tenant)
|
||||
|
||||
Utiliser l'outil **"Replace"** de Notepad++ (`Ctrl+H`) en activant le mode **Regular expression** :
|
||||
|
||||
**Recherche :**
|
||||
```
|
||||
(<processStore name=")(.*)(ProcessStore.*$)
|
||||
```
|
||||
|
||||
**Remplacement :**
|
||||
```
|
||||
<processStore name="\2ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>
|
||||
```
|
||||
|
||||
Cela remplacera la ligne directement avec le bon nom de Tenant.
|
||||
@@ -0,0 +1,73 @@
|
||||
# Déployer l'application en test
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000145084516/D%C3%A9ployer+l%27application+en+test)
|
||||
> Dernière mise à jour : 20/12/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
Afin que les développements puissent être testés par les chefs de projet, il faut importer l'application custom sur la VM du serveur. En fonction de la taille du projet, les livraisons s'effectueront **par lot** ou **à la fin des développements**.
|
||||
|
||||
Une **étiquette (tag)** devra être créée sur le commit de la branche `develop` souhaité. Cela permet au chef de projet, en cas de présentation client, d'être certain que l'application déployée ne contient pas de bugs introduits par des commits postérieurs à ses derniers tests.
|
||||
|
||||
**Convention de nommage du tag :** `<TRIGRAMME_PROJET>-V<NUMERO>`
|
||||
|
||||
Exemple : `LMD-V1`
|
||||
|
||||
---
|
||||
|
||||
## 1 - Création du TAG
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git switch develop
|
||||
git pull
|
||||
git tag <Tag Name>
|
||||
git push --tags
|
||||
git checkout <Tag Name>
|
||||
```
|
||||
|
||||
**SourceTree :**
|
||||
1. Se positionner sur la branche **`develop`** et faire un **"Pull"**
|
||||
2. Cliquer sur **"Tag"**
|
||||
3. Dans **"Tag Name"**, indiquer le nom du tag
|
||||
4. Choisir le commit précis ou prendre la dernière version de `develop`
|
||||
5. Cocher **"Push tag"** pour le créer sur la branche distante
|
||||
6. Une fois le tag créé, **double-cliquer dessus** dans la liste des tags pour s'y positionner
|
||||
|
||||
---
|
||||
|
||||
## 2 - Remettre la VM de test sur le point de contrôle Deploy0
|
||||
|
||||
Appliquer le point de contrôle **"Deploy 0"** sur la VM de test avant le déploiement.
|
||||
|
||||
---
|
||||
|
||||
## 3 - Effectuer le déploiement de l'application existante
|
||||
|
||||
Suivre la procédure : [Déploiement d'une application existante](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089575437)
|
||||
|
||||
---
|
||||
|
||||
## 4 - Si besoin : réinstallation du GNA
|
||||
|
||||
Suivre la procédure : [Installation Services et Licence WMS — Réinstallation](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673800/Installation+Services+et+Licence+WMS#R%C3%A9installation)
|
||||
|
||||
---
|
||||
|
||||
## 5 - Installer le printer service et la licence
|
||||
|
||||
Suivre la procédure : [Installation Services et Licence WMS](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673800)
|
||||
|
||||
---
|
||||
|
||||
## 6 - Valider la VM
|
||||
|
||||
Suivre la procédure : [Valider sa machine virtuelle](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089444441)
|
||||
|
||||
---
|
||||
|
||||
## 7 - Mettre à jour l'état des tâches Jira
|
||||
|
||||
Passer toutes les tâches en statut **"Attente déploiement pour test"** vers **"Prêt à tester"**.
|
||||
|
||||
> ⚠️ Lors du passage en **"Prêt à tester"**, il est **obligatoire** d'indiquer l'étiquette (tag) correspondant à celui créé sur Git.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Documents utiles (Robotique)
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001458327558)
|
||||
> Dernière mise à jour : 12/01/2026 (v2)
|
||||
|
||||
---
|
||||
|
||||
## Document de référence principal
|
||||
|
||||
Tous les types de stations, types d'événements GALILEO, liste des flags PIE, etc. :
|
||||
|
||||
[Control_Communications_Interface_EN_GB.pdf](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf)
|
||||
|
||||
---
|
||||
|
||||
## Document technique Gateway (structure des trames)
|
||||
|
||||
Plus technique — utile en cas de problème de traduction des trames :
|
||||
|
||||
[EasyWMSGateway_ControlInterface_EN.pdf](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf)
|
||||
|
||||
---
|
||||
|
||||
## Documentation des stations (particularités)
|
||||
|
||||
Certaines stations ont des particularités spécifiques :
|
||||
|
||||
[Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md)
|
||||
+93
File diff suppressed because one or more lines are too long
@@ -0,0 +1,12 @@
|
||||
# Erreurs / Défauts GALILEO
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001172623365)
|
||||
> Dernière mise à jour : 09/07/2025 (v2)
|
||||
|
||||
---
|
||||
|
||||
| Code défaut | Nom du défaut | Raisons possibles |
|
||||
|-------------|---------------|-------------------|
|
||||
| **1116** | Défaut : Tâche incorrecte CU1 | • Emplacement bloqué dans GALILEO mais pas dans EasyWMS<br>• Emplacement existant dans EasyWMS mais pas dans GALILEO<br>• Le même emplacement a un type de bac autorisé différent dans EasyWMS et GALILEO<br>• EasyWMS demande à GALILEO de déposer un bac sur le rack gauche alors qu'il est sur la fourche droite du miniload (et vice versa) |
|
||||
| **1201** | Défaut : Variateur X | — |
|
||||
| **1291** | Carte SM302 du variateur non référencée *(warning)* | — |
|
||||
@@ -0,0 +1,45 @@
|
||||
# Export des données via uGNA
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000145018888/Export+des+donn%C3%A9es+via+uGNA)
|
||||
> Dernière mise à jour : 18/10/2023 (v5)
|
||||
|
||||
---
|
||||
|
||||
## Exporter les données/configurations du WMS
|
||||
|
||||
> ⚠️ Si vous exportez des données depuis une VM qui n'est pas à jour par rapport au Git, vous pouvez exporter des données qui auraient pu être supprimées.
|
||||
|
||||
À faire à chaque fois qu'une nouvelle configuration, transporteur, paramètre, etc. est ajouté(e).
|
||||
|
||||
Ouvrir une **invite de commande** (hors PowerShell) **en administrateur** et exécuter :
|
||||
|
||||
```
|
||||
"C:\Program Files (x86)\Mecalux\uGNA\uGNAConsole.exe" -Z:abc,account,accounttype,adjustreason,agency,alias,carrierselectionconfiguration,company,containerlocktype,countprofiles,cuttingprofile,deliveriescarrier,divtype,hazzardclass,kit,locationlocktype,logisticprofile,outboundclass,outboundordercancelconfiguration,owner,inboundclass,packagingstages,parameter,pickingstationconfig,printerstationconfig,product,productfamily,productlocation,productype,putawayprofile,putawayrestriction,putawaystrategy,receptionprofile,replenishmentstrategy,shippingprofile,ShippingProfileAssignmentStrategy,shiptemplate,stockassignstrategy,stockassignstrategyV2,stockclassificationbyzone,stockstatus,suppliertype,supplier,transactiontype,uom
|
||||
```
|
||||
|
||||
Récupérer les fichiers XML générés dans :
|
||||
|
||||
```
|
||||
C:\Program Files (x86)\Mecalux\uGNA\Export
|
||||
```
|
||||
|
||||
Et les ajouter sur votre branche Git du projet dans le dossier **`..\test`**.
|
||||
|
||||
> ⚠️ Ne pas oublier de **commit et push** le répertoire Git.
|
||||
|
||||
---
|
||||
|
||||
## Erreur possible : droits insuffisants
|
||||
|
||||
Si une erreur de droits d'écriture apparaît sur le dossier cible :
|
||||
|
||||
1. Faire **clic droit** sur le dossier **`C:\Program Files (x86)\Mecalux\uGNA`** → **"Propriétés"**
|
||||
2. Aller dans l'onglet **"Sécurité"**
|
||||
3. Cliquer sur votre utilisateur → **"Modifier"**
|
||||
4. Dans la colonne **"Autoriser"**, cocher **"Contrôle total"**
|
||||
5. Cliquer sur **"Appliquer"** puis **"OK"**
|
||||
6. Relancer la commande d'export
|
||||
|
||||
---
|
||||
|
||||
> Plus de détails sur les commandes uGNA (notamment pour la liste des entités exportables dans les exports spécifiques) : [uGNA](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/25788478)
|
||||
File diff suppressed because one or more lines are too long
BIN
Binary file not shown.
@@ -0,0 +1,9 @@
|
||||
### Liste des programmes
|
||||
- A - Tournesol - Sacs - Complet
|
||||
- B - Tournesol - Sacs - Réduit
|
||||
- C -Tournesol - Big Bag - Complet
|
||||
- D - Tournesol - Big Bag - Réduit
|
||||
- E - Mais&Ble - Sacs - Complet
|
||||
- F -Mais&Ble - Sacs - Réduit
|
||||
- G -Mais&Ble - Big Bag - Complet
|
||||
- H - Mais&Ble - Big Bag - Réduit
|
||||
@@ -0,0 +1,76 @@
|
||||
# Gestion de la custom application
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673775/Gestion+de+la+custom+application)
|
||||
> Dernière mise à jour : 20/12/2022 (v12)
|
||||
|
||||
---
|
||||
|
||||
> ⚠️ Il est important de rappeler que vous pouvez être plusieurs à travailler sur un même projet sur des VM différentes. Une **gestion rigoureuse de la CustomApp** et une bonne communication sur l'avancement sont indispensables.
|
||||
|
||||
Pour rester à jour :
|
||||
- **Exporter** la CustomApp à chaque fois que vous finissez une tâche
|
||||
- **Réimporter** celle de la branche `develop` après merge de votre branche dedans
|
||||
|
||||
Si vous **rejoignez un projet en cours**, importer la CustomApp existante est la **première chose à faire**.
|
||||
|
||||
> ⛔ Une mauvaise manipulation ici peut entraîner la **perte de vos développements** — procéder avec soin.
|
||||
|
||||
---
|
||||
|
||||
## 1 - Création de l'application custom
|
||||
|
||||
Si vous êtes le premier à travailler sur le projet, créer une nouvelle application custom.
|
||||
|
||||
**Option A — Partir d'une application existante du Toolkit**
|
||||
|
||||
Si vous devez intégrer des modifications déjà disponibles dans le projet [**FRANCE_OPERATIONS_TOOLS**](https://msscode.mecalux.com/Proyectos_SW/FRANCE_OPERATIONS_TOOLS.git) (ex. modifications habituelles du module transporteur) :
|
||||
|
||||
1. Cloner le projet `FRANCE_OPERATIONS_TOOLS`
|
||||
2. Réaliser l'import (cf. section 2) depuis le chemin :
|
||||
```
|
||||
..\FRANCE_OPERATIONS_TOOLS\<Ma modif voulue>
|
||||
```
|
||||
Exemple : `..\FRANCE_OPERATIONS_TOOLS\Module transporteur`
|
||||
|
||||
**Option B — Créer une nouvelle application vierge**
|
||||
|
||||
Dans EasyBuilder, faire **clic droit sur "Application"** → **"New application"**
|
||||
|
||||
Saisir le nom de l'application et définir les dépendances (en général : `EasyWMS`).
|
||||
|
||||
Après avoir créé votre application custom, faire un **1er export sur la branche `develop`** du projet Git (cf. section 3).
|
||||
|
||||
---
|
||||
|
||||
## 2 - Import de l'application custom
|
||||
|
||||
> ⚠️ **Avant d'importer**, il faut d'abord **supprimer** la custom app existante dans votre Builder.
|
||||
|
||||
1. Clic droit sur l'application custom → **"Delete application"**
|
||||
|
||||
2. Clic droit sur **"Applications"** → **"Import and save application from text"**
|
||||
|
||||
3. Sélectionner le chemin d'accès dans votre projet Git :
|
||||
```
|
||||
..\source\NomApplication
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3 - Export de l'application custom
|
||||
|
||||
> ⚠️ **Avant d'exporter**, il faut d'abord **vider** le dossier de destination dans votre projet Git :
|
||||
> ```
|
||||
> ..\source\NomApplication
|
||||
> ```
|
||||
|
||||
> ⚠️ Bien vérifier d'être sur la **branche de votre tâche** avant d'exporter.
|
||||
|
||||
> ⛔ Lors de l'export, **aucun élément actuellement en "Check-out" n'est sauvegardé ni exporté**.
|
||||
|
||||
1. Clic droit sur l'application custom → **"Export application to text"**
|
||||
|
||||
2. Sélectionner le chemin d'accès dans votre projet Git :
|
||||
```
|
||||
..\source\NomApplication
|
||||
```
|
||||
@@ -0,0 +1,98 @@
|
||||
# Gestion du GIT
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000400216098/Gestion+du+GIT)
|
||||
> Dernière mise à jour : 27/02/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
## 1. Phase de Développement Initial
|
||||
|
||||
### a. Création des branches de fonctionnalité (`feature`) ou de correction
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **Dev** | Utiliser Git Flow dans Sourcetree |
|
||||
| 2 | **Dev** | Faire un **"Start New Feature"** au début de la tâche |
|
||||
| 3 | **Dev** | Utiliser le **même nom de branche que le "tag"** de la tâche Jira |
|
||||
| 4 | **Dev** | Corriger les retours (revue de code et test fonctionnel) dans une **nouvelle "feature"** avec le même nom |
|
||||
| 5 | **Dev** | Terminer les tâches avec la commande **"finish feature"** avec l'option **"rebase"** |
|
||||
|
||||
---
|
||||
|
||||
## 2. Avant la mise en service
|
||||
|
||||
### a. Merge de la branche `develop` dans `master`
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **CdP** | Merger la branche `develop` dans `master` |
|
||||
| 2 | **CdP** | **Supprimer la branche `develop`** (évite qu'au retour on ait une branche develop plus du tout à jour) |
|
||||
|
||||
---
|
||||
|
||||
## 3. Après la mise en service (pendant l'hypercare et avant le passage en TLM)
|
||||
|
||||
### a. Retour de mise en service
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **CdP** | Mettre à jour la branche `master` (récupérer les éventuels développements de la mise en service) |
|
||||
| 2 | **Dev Principal** | Créer une nouvelle branche `develop` à partir de `master` s'il y a des développements à réaliser |
|
||||
|
||||
### b. Pendant l'hypercare
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **Dev Principal** | Réaliser les développements "hypercare" sur la `develop` |
|
||||
| 2 | **CdP** | Livrer la production depuis la branche `develop` *(toujours livrer quand tous les développements sont terminés)* |
|
||||
| 3 | **CdP** | Merger `develop` dans `master` — si possible aussi merger `master` dans `develop` pour avoir les deux branches au même niveau |
|
||||
|
||||
### c. Avant le passage en TLM
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **CdP** | Merger `develop` dans `master` (par sécurité) |
|
||||
| 2 | **CdP** | Supprimer la branche `develop` après validation |
|
||||
|
||||
> ⛔ **L'équipe support refusera le passage en TLM si le dépôt Git du projet contient encore une branche `develop`.**
|
||||
|
||||
---
|
||||
|
||||
## 4. Pendant la TLM et la TMA
|
||||
|
||||
### a. Branches de `hotfix` pour l'équipe de Support
|
||||
|
||||
**Cas de modifications longues/conséquentes ou testées sur intégration d'abord :**
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **Support** | Créer des branches de `hotfix` à partir de `master` |
|
||||
| 2 | **Support** | Merger dans `master` à la livraison |
|
||||
| 3 | **Support** | Prévenir l'équipe TMA qu'une livraison a eu lieu *(pour mise à jour des branches `release` en cours)* |
|
||||
|
||||
**Cas de modifications directes en prod :**
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **Support** | Exporter la production dans `master` |
|
||||
| 2 | **Support** | Prévenir l'équipe TMA qu'une livraison a eu lieu |
|
||||
|
||||
### b. Branches de `release` pour l'équipe de TMA
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|--------|--------|
|
||||
| 1 | **TMA** | Créer une nouvelle branche de `release` pour chaque offre complémentaire prévue |
|
||||
| 2 | **TMA** | Les développeurs tirent des branches de `feature` depuis `release` pour chaque tâche Jira de l'offre |
|
||||
| 3 | **TMA** | Merger `master` dans `release` à chaque annonce de livraison en production par le support |
|
||||
| 4 | **TMA** | Intégrer les branches de `feature` dans `release` sur demande du chef d'équipe, après test et validation finale |
|
||||
| 5 | **TMA** | Merger `master` dans `release` et effectuer une passe de tests généraux avant livraison de l'offre |
|
||||
| 6 | **TMA** | Merger `release` dans `master` après livraison de l'offre |
|
||||
| 7 | **TMA** | Prévenir l'équipe Support qu'une livraison a eu lieu *(pour mise à jour des branches `hotfix` en cours)* |
|
||||
|
||||
---
|
||||
|
||||
## 5. Visibilité et Communication
|
||||
|
||||
### a. Communication entre les équipes
|
||||
|
||||
> ⚠️ Il est très important de bien **communiquer sur les livraisons** effectuées, tant entre les équipes de développement et les chefs de projet, qu'entre les équipes TMA et Support, afin de maintenir un Git à jour.
|
||||
@@ -0,0 +1,170 @@
|
||||
# Gestion des versions du projet avec GIT
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089968867/Gestion+des+versions+du+projet+avec+GIT)
|
||||
> Dernière mise à jour : 22/08/2025 (v27)
|
||||
|
||||
---
|
||||
|
||||
La gestion est expliquée en parallèle via l'**invite de commande** et le logiciel **[SourceTree](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088854571)** (configuré en anglais).
|
||||
|
||||
Ressources utiles :
|
||||
- [Équivalences git ↔ git flow](https://gist.github.com/JamesMGreene/cdd0ac49f90c987e45ac)
|
||||
- [Git flow cheat sheet](http://danielkummer.github.io/git-flow-cheatsheet/)
|
||||
|
||||
---
|
||||
|
||||
## 1 - Initialiser le projet en local
|
||||
|
||||
### Clone
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
cd <emplacement souhaité>
|
||||
git clone <url>
|
||||
```
|
||||
|
||||
**SourceTree :** Utiliser le bouton "Clone" et renseigner l'URL du repo.
|
||||
|
||||
> L'URL du repo GIT se trouve dans l'interface de gestion du projet (bouton "Clone" ou "Code" selon la plateforme).
|
||||
|
||||
### Initialiser Git Flow
|
||||
|
||||
Git Flow est une extension de Git qui impose un workflow structuré et uniformise la gestion des branches.
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git flow init -d \
|
||||
--feature feature/ \
|
||||
--bugfix bugfix/ \
|
||||
--release release/ \
|
||||
--hotfix hotfix/ \
|
||||
--support support/ \
|
||||
-t ''
|
||||
git push --set-upstream origin develop
|
||||
```
|
||||
|
||||
**SourceTree :** Cliquer sur l'icône Git Flow → ne rien modifier dans la fenêtre de configuration → cliquer sur **OK**.
|
||||
|
||||
---
|
||||
|
||||
## 2 - Création d'une nouvelle feature/branche
|
||||
|
||||
Vérifier d'abord qu'il n'y a pas de commit à récupérer :
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git pull
|
||||
```
|
||||
|
||||
**SourceTree :** Cliquer sur le bouton **"Pull"**.
|
||||
|
||||
Créer la nouvelle feature pour la tâche :
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git flow feature start <nom de la feature>
|
||||
# Ex : git flow feature start PD-49
|
||||
```
|
||||
|
||||
**SourceTree :** Cliquer sur l'icône Git Flow → "Start New Feature" → saisir le nom.
|
||||
|
||||
Déployer la VM depuis la nouvelle branche en repartant du point de contrôle **"DEPLOY 0"** :
|
||||
- [Déploiement d'une application existante](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089575437)
|
||||
- [Appliquer un point de contrôle](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088985657/Point+de+contr%C3%B4le+-+VM#Appliquer-un-point-de-contr%C3%B4le-%3A)
|
||||
|
||||
> Si une pop-up de connexion apparaît sur SmartUI : [procédure dédiée](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544)
|
||||
|
||||
Vous êtes prêt à commencer vos développements. ✅
|
||||
|
||||
---
|
||||
|
||||
## 3 - Commit de vos modifications
|
||||
|
||||
Avant de committer, exporter toutes les modifications réalisées :
|
||||
|
||||
1. **Exporter l'application custom** depuis votre branche de développement → [Gestion de la custom application — Export](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673775/Gestion+de+la+custom+application#3---Export-de-l%E2%80%99application-custom)
|
||||
2. **Si des paramètres/configurations WMS ont été modifiés** : faire un export des datas → [Export des données via uGNA](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000145018888)
|
||||
3. **Si des fichiers BOO du GNA ont été modifiés** : exécuter la sauvegarde → [Sauvegarder la configuration sur le GIT](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673800/Installation+Services+et+Licence+WMS#Sauvegarder-la-configuration-sur-le-GIT)
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
# Ajouter tous les fichiers modifiés
|
||||
git add .
|
||||
# Ou un fichier spécifique
|
||||
git add <Nom du fichier>
|
||||
|
||||
# Committer avec un message explicite
|
||||
git commit -m "<Message expliquant vos modifications>"
|
||||
|
||||
# Pousser sur la remote
|
||||
git push
|
||||
```
|
||||
|
||||
**SourceTree :**
|
||||
1. Cliquer sur **"Commit"** (haut à gauche)
|
||||
2. Ajouter tous les fichiers via **"Stage all"**, ou fichier par fichier via drag & drop ou sélection + "Stage selected"
|
||||
3. Écrire le message de commit
|
||||
4. Cliquer sur **"Commit"**
|
||||
5. Pour push simultané : cocher l'option **"Push changes immediately"**
|
||||
|
||||
> ℹ️ Les fichiers générés par l'export de l'application custom sont séparés en plusieurs fichiers pour un même élément (workflow, source C#, DESIGN…). Bien prendre **tous les fichiers** portant le nom de l'élément modifié.
|
||||
|
||||
> ⚠️ **Règle absolue** : commit et push ses développements **tous les soirs avant de quitter les bureaux** afin d'éviter toute perte de données (perte/vol/casse du PC).
|
||||
|
||||
---
|
||||
|
||||
## 4 - Fin de la tâche de développement
|
||||
|
||||
Une fois les développements testés et validés, "clôturer" la branche de développement.
|
||||
|
||||
### Mettre à niveau la branche "develop"
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git switch develop
|
||||
git pull
|
||||
```
|
||||
|
||||
**SourceTree :** Double-cliquer sur la branche `develop` pour la sélectionner, puis cliquer sur **"Pull"**.
|
||||
|
||||
### Clôturer la feature
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git flow feature finish -r <Nom feature>
|
||||
git push
|
||||
# Ex : git flow feature finish -r PD-49
|
||||
```
|
||||
|
||||
**SourceTree :**
|
||||
1. Cliquer sur l'icône Git Flow → sélectionner la feature à clôturer
|
||||
2. ✅ Bien cocher **"Rebase on development Branch"**
|
||||
3. Valider, puis cliquer sur **"Push"**
|
||||
|
||||
### Gérer les conflits
|
||||
|
||||
Si des conflits apparaissent lors du rebase :
|
||||
|
||||
1. Ouvrir le ou les fichiers en conflit avec votre éditeur préféré (Visual Studio Code recommandé) et résoudre les conflits
|
||||
|
||||
**Git (CLI) :**
|
||||
```bash
|
||||
git add <nom du fichier en conflit>
|
||||
git rebase --continue
|
||||
# Répéter pour tous les commits jusqu'à la fin du rebase
|
||||
# Puis recommencer la clôture de la feature
|
||||
```
|
||||
|
||||
**SourceTree :**
|
||||
1. **Ne pas faire de commit** — seulement "stage" les fichiers résolus
|
||||
2. Cliquer sur **"Continue Rebase"**
|
||||
3. Répéter pour tous les commits de la branche `develop`
|
||||
4. Recommencer la clôture de la feature **sans cocher "Rebase"** cette fois
|
||||
|
||||
### Mettre à jour l'état de la tâche Jira
|
||||
|
||||
Passer le ticket à **"Revue de code"**.
|
||||
|
||||
---
|
||||
|
||||
> Plus de détails sur les commandes Git : [Formation Git — Invite de commandes](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/219995865278/Formation+Git#Utilisation-via-invite-de-commandes)
|
||||
@@ -0,0 +1,104 @@
|
||||
# Installation Services et Licence WMS
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673800/Installation+Services+et+Licence+WMS)
|
||||
> Dernière mise à jour : 15/04/2025 (v19)
|
||||
|
||||
---
|
||||
|
||||
# Service GNA
|
||||
|
||||
## Sauvegarder la configuration sur le GIT
|
||||
|
||||
Ajouter le script ci-dessous dans le dossier **`InstallApplications`**.
|
||||
|
||||
Le dossier `InstallApplications` correspond au dossier dézippé lors de l'installation du GNA (en manuel). Avec l'installation en automatique, le dossier se situe ici :
|
||||
|
||||
```
|
||||
C:\deploy\Prof.Serv.Deploy\InstallApplications
|
||||
```
|
||||
|
||||
Ouvrir PowerShell dans ce dossier et exécuter :
|
||||
|
||||
```powershell
|
||||
.\GNAGetDataForGit.ps1
|
||||
```
|
||||
|
||||
> ⚠️ Le script exporte les fichiers nécessaires à l'installation du GNA. Les XSD sont composés à l'installation à partir des fichiers du dossier `XSD_Source` de votre GNA.
|
||||
> **Ne pas copier directement le XML du dossier `XSD`** de votre GNA — il serait pris comme "source" et recomposé avec les XSD_Source des autres applications, entraînant des duplications de lignes.
|
||||
|
||||
**Exemple** : le fichier `SOF02` (`C:\ProgramData\Mecalux\GnaService2015\XSD\SOF02.xsd`) peut être composé de :
|
||||
|
||||
| Module | Chemin source |
|
||||
|--------|--------------|
|
||||
| EasyWMS | `XSD_Source\EasyWMS\Definitions\SOF02.xsd` |
|
||||
| Deliveries | `XSD_Source\Deliveries\Extensions\EasyWMS\SOF02\ShippingOrderFinalizationType\SOF02.xsd` |
|
||||
| VAS | `XSD_Source\ValueAddedService\Extensions\EasyWMS\SOF02\LineType\SOF02.xsd` |
|
||||
|
||||
> ⚠️ Avec les nouvelles versions des scripts d'installation (GNA installé lors du deploy depuis le repository), le GNA n'est plus installé au même endroit qu'auparavant. Le script peut planter car il ne trouve pas les dossiers GNA.
|
||||
|
||||
**Solution** : modifier les chemins dans le fichier **`responses.xml`** du dossier `InstallApplications` :
|
||||
|
||||
```xml
|
||||
<!-- Ancien chemin -->
|
||||
<XSDPath>C:\ProgramData\Mecalux\GnaService2015\XSD</XSDPath>
|
||||
<commsPath>C:\ProgramData\Mecalux\GnaService2015\standard_comms\Scripts2015</commsPath>
|
||||
|
||||
<!-- Nouveau chemin -->
|
||||
<XSDPath>C:\Program Files\Mecalux\GnaService2015\XSD</XSDPath>
|
||||
<commsPath>C:\Program Files\Mecalux\GnaService2015\standard_comms\Scripts2015</commsPath>
|
||||
```
|
||||
|
||||
Récupérer le dossier GNA créé et l'ajouter au GIT dans : **`\services\GNA`**
|
||||
|
||||
> ℹ️ Cette action est à réaliser à chaque fois qu'un script BOO est modifié.
|
||||
|
||||
---
|
||||
|
||||
## Réinstallation d'un GNA
|
||||
|
||||
Si le GNA a déjà été installé sur une VM :
|
||||
|
||||
1. Récupérer le fichier **`InstallApplication.zip`** [à télécharger ici](https://msscc.mecalux.com/documentation/documentation/master/EN/docs_downloads/services/gna.md) et le dézipper sur la VM
|
||||
2. Récupérer le dossier **`\deploy\services\GNA`** du GIT et le copier dans le dossier dézippé ci-dessus
|
||||
3. Remplacer le fichier **`responses.xml`** par celui du dossier GNA et vérifier que l'URL de l'application `FromGIT` pointe sur le bon fichier
|
||||
4. Créer un fichier **`GNA.zip`** contenant les dossiers suivants :
|
||||
- `Config`
|
||||
- `Scripts`
|
||||
- `TaskDefinitions`
|
||||
- `XSD`
|
||||
5. Exécuter **en administrateur** le script **`DeployCommsApps.ps1`** en choisissant l'option **"complete"**
|
||||
|
||||
> En cas d'erreur : [Installation GNA — Exécution de l'installation](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/57475732/Installation+GNA#Ex%C3%A9cution-de-l%E2%80%99installation)
|
||||
|
||||
---
|
||||
|
||||
# Installer le service Label Printer
|
||||
|
||||
Suivre la documentation : [Printer service et imprimante PDF : Installation et configuration](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/5538376)
|
||||
|
||||
---
|
||||
|
||||
# Installer une licence WMS
|
||||
|
||||
Pour que la machine virtuelle fonctionne pendant plus de 7 jours, il faut demander une licence.
|
||||
|
||||
### 1 - Demande de licence
|
||||
|
||||
Faire une demande aux **chefs d'équipes** ou au **directeur technique** (en dernier recours) en leur fournissant la licence actuelle du projet, récupérable depuis :
|
||||
|
||||
```
|
||||
https://<VotreVM>/EasySTS/License
|
||||
```
|
||||
|
||||
Via le bouton **"Export"** en bas de page.
|
||||
|
||||
> Si personne n'est disponible, faire une demande au support espagnol via la [documentation dédiée](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/25690458).
|
||||
|
||||
### 2 - Import de la licence
|
||||
|
||||
Une fois la licence reçue :
|
||||
|
||||
1. Se connecter à **`https://<VotreVM>/EasySTS/License`**
|
||||
2. L'ajouter dans **"Submit license"**
|
||||
|
||||
La date de validité est alors mise à jour dans EasySTS.
|
||||
@@ -0,0 +1,168 @@
|
||||
# Installation de la VM sur Hyper-V
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088756300/Installation+de+la+VM+sur+Hyper-V)
|
||||
> Dernière mise à jour : 02/12/2025 (v30)
|
||||
|
||||
---
|
||||
|
||||
# Création de la VM
|
||||
|
||||
### 1 - Récupérer la base de la VM
|
||||
|
||||
Ouvrir l'adresse **`\\lyoitsw02\TEMPLATE\`** dans un explorateur de fichier et récupérer le dossier **`TEMPLATE_INTEGRATION_[DB]`** (**`[DB]`** correspond à la base de donnée qui se trouvera en production).
|
||||
|
||||
> À savoir : si c'est une VM en mode **SAAS** la BDD sera **POSTGRES**, sinon **ORACLE** en mode **On-Premise**.
|
||||
|
||||
Copier le dossier en local sur le serveur, par exemple dans : **`D:\Hyper-V\DEV`**
|
||||
|
||||
---
|
||||
|
||||
### 2 - Créer une nouvelle machine virtuelle
|
||||
|
||||
Dans Hyper-V, aller dans **"Action"** → **"Nouveau"** → **"Ordinateur virtuel"**
|
||||
|
||||
---
|
||||
|
||||
### 3 - Saisir le nom de la VM
|
||||
|
||||
Pour éviter les interconnexions entre VM, la convention de nommage est :
|
||||
|
||||
```
|
||||
DEV-<PRENOM>
|
||||
```
|
||||
|
||||
Ex : `DEV-NICO`
|
||||
|
||||
---
|
||||
|
||||
### 4 - Choisir l'option "Génération 2"
|
||||
|
||||
Cette option permet de disposer de toutes les fonctionnalités de la VM.
|
||||
|
||||
---
|
||||
|
||||
### 5 - Augmenter la RAM à 4 Go (4096 Mo) et activer la mémoire dynamique
|
||||
|
||||
---
|
||||
|
||||
### 6 - Définir la connexion "InternoNAT"
|
||||
|
||||
La connexion **"InternoNAT"** permet d'accéder au contenu de la VM et de charger le builder en dehors de celle-ci.
|
||||
|
||||
> ⚠️ Pour le **serveur**, la connexion est **"VMs"** et non "InternoNAT".
|
||||
|
||||
---
|
||||
|
||||
### 7 - Utiliser une image de disque dur existante
|
||||
|
||||
Sélectionner l'utilisation d'un disque dur existant et saisir le chemin d'accès au fichier **`win10ent.vhdx`** situé dans le dossier récupéré sur le serveur (cf. étape 1).
|
||||
|
||||
---
|
||||
|
||||
### 8 - Terminer la création de la VM
|
||||
|
||||
Vérifier que toutes les informations sont correctes puis finaliser la création.
|
||||
|
||||
---
|
||||
|
||||
# Configuration de la VM
|
||||
|
||||
> ⚠️ Ne pas faire le paramétrage NAT si c'est une VM d'intégration.
|
||||
|
||||
## A faire sur Hyper-V
|
||||
|
||||
### 1 - Ouvrir les paramètres de la VM
|
||||
|
||||
Clic droit sur votre VM → **"Paramètres"**
|
||||
|
||||
---
|
||||
|
||||
### 2 - Définir la mémoire dynamique maximale
|
||||
|
||||
Afin d'éviter qu'Hyper-V alloue plus de RAM que votre ordinateur ne peut supporter, limiter la RAM maximale de la mémoire dynamique à **6 Go (6144 Mo)**.
|
||||
|
||||
---
|
||||
|
||||
### 3 - Augmenter le nombre de processeurs à 4
|
||||
|
||||
---
|
||||
|
||||
### 4 - Activer les points de contrôle
|
||||
|
||||
Cela permettra de créer un point de contrôle après la configuration initiale, vous permettant d'y revenir entre chaque changement de projet.
|
||||
|
||||
---
|
||||
|
||||
## A faire sur la VM
|
||||
|
||||
Après avoir effectué les actions précédentes, démarrer la VM si elle ne l'est pas :
|
||||
Clic droit sur votre VM → **"Démarrer"**
|
||||
|
||||
Pour s'y connecter :
|
||||
Clic droit sur votre VM → **"Se connecter…"**
|
||||
|
||||
> ⚠️ **Attention** : le paramètre ci-dessous doit bien être **désactivé**, que ce soit sur la connexion RDP ou la connexion à la VM depuis Hyper-V.
|
||||
|
||||
---
|
||||
|
||||
### 5 - Configuration du commutateur Interne
|
||||
|
||||
> ⚠️ **À faire seulement sur une VM locale. Ne pas faire sur un déploiement de VM sur serveur — passer directement à l'étape 6.**
|
||||
|
||||
1. Exécuter **`NCPA.CPL`** via l'outil d'exécution Windows (`Windows + R`)
|
||||
2. Ouvrir les propriétés du réseau Ethernet présent
|
||||
3. Double-cliquer sur le protocole **IPv4**
|
||||
4. Saisir les paramètres réseau suivants :
|
||||
- **IP** : `10.255.255.2`
|
||||
- **Masque** : `255.255.255.0`
|
||||
- **Passerelle** : `10.255.255.1`
|
||||
5. Cliquer sur **"Advanced"**, aller dans l'onglet **DNS** et saisir les 4 serveurs DNS suivants :
|
||||
- `192.168.0.102`
|
||||
- `192.168.0.104`
|
||||
- `192.168.0.56`
|
||||
- `192.168.66.250`
|
||||
6. Ajouter le suffixe DNS : **`mecalux.com`**
|
||||
7. Valider avec **OK**
|
||||
|
||||
> Pour savoir comment accéder à votre VM : [Routage vers les VM](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000160452644/Routage+vers+les+VM#Acc%C3%A8s-en-local-%3A)
|
||||
|
||||
---
|
||||
|
||||
### 6 - Changer le nom de la VM dans les paramètres Windows
|
||||
|
||||
1. Se connecter à la VM (clic droit → "Se connecter" ou double-clic)
|
||||
2. Ouvrir les **Paramètres Windows**
|
||||
3. Aller dans **"System"**
|
||||
4. Dans le volet de gauche, cliquer sur **"About"** (en bas)
|
||||
5. Cliquer sur **"Rename this PC"**
|
||||
6. Saisir le nom de la VM
|
||||
|
||||
> ⚠️ **Avant de redémarrer**, remplacer le `hostName` par le nouveau nom du PC virtuel dans les fichiers de configuration Oracle :
|
||||
> - **`tnsnames.ora`**
|
||||
> - **`listener.ora`**
|
||||
>
|
||||
> Situés dans :
|
||||
> - `C:\Mecalux\Motor\oracle\product\12.2.0\dbhome_1\network\admin`
|
||||
> - ou `C:\Mecalux\Motor\oracle\Product\19.17.0.0\dbhome_1\network\admin` *(template Oracle 19)*
|
||||
>
|
||||
> *(Remplacer `localhost` par le nouveau nom du PC)*
|
||||
|
||||
> ⚠️ **Attention** : pour les templates Oracle (12 ou 19), le nom du PC virtuel est **limité à 15 caractères**.
|
||||
|
||||
7. **Redémarrer la VM**
|
||||
|
||||
Avant de créer votre premier point de contrôle, il peut être utile d'installer vos logiciels personnels (ex. Sublime Text) ainsi que **Git** s'il n'est pas déjà présent sur le template.
|
||||
|
||||
Pour vérifier si Git est installé, ouvrir un `cmd` et taper :
|
||||
|
||||
```bash
|
||||
git --version
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7 - Faire un point de contrôle de la VM
|
||||
|
||||
Créer un point de contrôle **"Deploy 0"** — cela vous permettra d'appliquer ce point de contrôle pour effectuer le **deploy1** d'un nouveau projet.
|
||||
|
||||
> Voir : [Point de contrôle](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088985657)
|
||||
@@ -0,0 +1,213 @@
|
||||
# LIM-62 — #LOT1.1 [RECEPTION] Gestion camions
|
||||
|
||||
| Champ | Valeur |
|
||||
|---|---|
|
||||
| **Clé** | [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) |
|
||||
| **Projet** | LIMAGRAIN - DEV |
|
||||
| **Type** | Tâche |
|
||||
| **Statut** | En cours de test client (pré-production) |
|
||||
| **Priorité** | Medium |
|
||||
| **Rapporteur** | Arthur Ria |
|
||||
| **Assigné** | Arthur Ria |
|
||||
| **Epic** | LIM-1 |
|
||||
| **Créé le** | 18/02/2026 |
|
||||
| **Mis à jour** | 13/04/2026 |
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
### Arrivée et déclaration du camion
|
||||
|
||||
Ce flux concerne l'arrivée physique d'un camion sur le site et son orientation vers un quai de déchargement. Il est commun à tous les types de réception.
|
||||
|
||||
Il existe un emplacement fictif **PARKING**, plusieurs quais et plusieurs poumons de réception (parfois appelés "image de quai").
|
||||
|
||||
### Résumé
|
||||
|
||||
Un camion contient plusieurs OE.
|
||||
|
||||
Un responsable crée la réception associée au camion dans la vue **"Ordre d'entrée > Réception"**. Il saisit la plaque d'immatriculation et la destination ("PARKING" ou un quai d'expédition). Ensuite, il choisit les OE concernés. L'affichage plaque + quai permet de guider le chauffeur.
|
||||
|
||||
> **Note** : Chaque OE est flag via un CstAtt.
|
||||
|
||||
Le gestionnaire verra tous les réceptions et pourra filtrer par plaque et/ou quai assigné.
|
||||
|
||||
### Flux détaillé
|
||||
|
||||
#### Étape 1 : Annonce du camion à l'arrivée
|
||||
|
||||
**Annonce manuelle par un agent de quai :**
|
||||
|
||||
Le camion arrive sur site et s'annonce auprès d'un agent de quai. L'agent accède à la vue **"Ordre d'entrée > Réceptions"** dans SmartUI. Il crée une nouvelle réception d'ordres d'entrée en saisissant :
|
||||
- la plaque d'immatriculation du véhicule
|
||||
- la destination : par défaut **"PARKING"** (quai fictif d'attente) ou directement un quai réel si disponible
|
||||
- les OE concernés
|
||||
|
||||
#### Étape 2 : Assignation du quai
|
||||
|
||||
L'agent de quai consulte les disponibilités des quais et images de quai via un graphique dans la vue des Réceptions (à droite de la grille). Il sélectionne les réceptions dans la vue et associe un quai réel au camion (ou modifie le quai si "PARKING" est déjà appliqué).
|
||||
|
||||
**Règles d'assignation :**
|
||||
|
||||
- Le quai et l'image de quai sont réservés dès la sélection → il est quand même possible de réutiliser un combo quai/image de quai s'il y a de la place (gestion manuelle)
|
||||
- Blocage si flux différent (ex : expédition)
|
||||
- Si aucun quai n'est disponible → l'opérateur attend une libération ou choisit PARKING
|
||||
- ~~Un quai peut être déjà occupé mais non plein, dans ce cas, via calcul de la place restante, on peut l'attribuer~~
|
||||
- Modification possible à posteriori si les contraintes d'exploitation l'exigent
|
||||
|
||||
> Pour l'expédition, vérifier si l'image de quai a des supports associés à un OS.
|
||||
|
||||
#### Étape 3 : Information au chauffeur
|
||||
|
||||
Un écran d'affichage situé sur le parking montre la plaque d'immatriculation et le numéro de quai assigné. Le chauffeur peut ainsi se diriger vers le bon quai. Sera fait via une WS.
|
||||
|
||||
---
|
||||
|
||||
## Développement
|
||||
|
||||
### 1. Saisie plaque (Document)
|
||||
|
||||
Dans la vue **Réceptions > Réception**, si on clique sur "Nouvelle réception du préavis de réception", que l'on sélectionne ses OE et que l'on fait suivant, renommer **Document** par **"Camion"** (à faire globalement dans le WMS pour les réceptions). Ici sera saisie la plaque du camion.
|
||||
|
||||
Il faut empêcher l'utilisateur de créer une réception avec des ordres d'entrées de **classe différente**. Si c'est le cas, bloquer la création de la réception avec un message d'erreur :
|
||||
|
||||
> *"Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes"*
|
||||
|
||||
### 2. Résumé occupation
|
||||
|
||||
Dans l'espace à droite d'information globales, ajouter un tableau qui liste les quais. Pour chaque quai, afficher les combo réceptions/plaques associés ainsi que les combo tournées/plaques et OS/plaques.
|
||||
|
||||
Exemple :
|
||||
|
||||
| **QUAI** | **Réceptions / Camion** |
|
||||
|---|---|
|
||||
| PARKING | [18-02-26_001 - ES-116-NA] ; [18-02-26-002 - GS-920-XJ] |
|
||||
| QUAI_01 | |
|
||||
| QUAI_02 | [18-02-26_006 - DJ-100-XD] |
|
||||
| QUAI_03 | |
|
||||
| QUAI_04 | [18-02-26_012 - AR-096-IA] |
|
||||
| etc.. | |
|
||||
|
||||
### 3. Affichage chauffeur
|
||||
|
||||
Voir [LIM-63](https://easywmsfrance.atlassian.net/browse/LIM-63)
|
||||
|
||||
---
|
||||
|
||||
## Cas de tests
|
||||
|
||||
### 1. Création de réception — Saisie plaque / OE
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|---|---|---|---|---|---|---|
|
||||
| C1-01 | OE de classes différentes sélectionnés | OE avec classes de préavis différentes existent | Sélectionner des OE de classes mixtes et faire Suivant | Blocage avec message : "Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes" | | |
|
||||
| C1-02 | OE de classes identiques — création OK | OE avec la même classe | Sélectionner des OE de même classe et faire Suivant | Passage à l'étape suivante, réception créée | | |
|
||||
| C1-03 | Un seul OE sélectionné (cas limite bas) | N/A | Sélectionner 1 seul OE | Création autorisée, pas de contrôle de classe bloquant | | |
|
||||
| C1-04 | Le champ "Document" est bien renommé "Camion" | N/A | Ouvrir le formulaire de nouvelle réception | Le libellé affiché est "Camion" et non "Document" | | |
|
||||
|
||||
### 2. Assignation de quai
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|---|---|---|---|---|---|---|
|
||||
| ~~A1-01~~ | ~~Quai avec flux expédition — blocage~~ | ~~Un quai est occupé par un flux expédition (supports liés à un OS)~~ | ~~Tenter d'assigner ce quai à une réception~~ | ~~Blocage, le quai n'est pas assignable~~ | | |
|
||||
| ~~A1-02~~ | ~~Quai PARKING assigné par défaut~~ | ~~N/A~~ | ~~Créer une réception sans choisir de quai réel~~ | ~~La destination est "PARKING" par défaut~~ | | |
|
||||
| A1-03 | Modification du quai après assignation initiale | Réception déjà assignée à PARKING | Modifier pour assigner un quai réel | La modification est acceptée, le nouveau quai est reflété | | |
|
||||
| A1-04 | Réassignation d'un combo quai/image de quai partiellement occupé | Quai avec de la place restante | Assigner une nouvelle réception sur ce même quai | Assignation autorisée (gestion manuelle de la place) | | |
|
||||
| ~~A1-05~~ | ~~Deux réceptions assignées simultanément au même quai plein~~ | ~~Quai/image de quai déjà plein~~ | ~~Tenter d'assigner une deuxième réception~~ | ~~Comportement défini : est-ce bloqué ou simple avertissement ? À clarifier~~ | | |
|
||||
|
||||
### 3. Tableau de résumé d'occupation des quais
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|---|---|---|---|---|---|---|
|
||||
| T1-01 | Un quai sans réception associée | Quai vide | Ouvrir la vue Réceptions | Le quai apparaît dans le tableau avec la colonne "Réceptions / Camion" vide | | |
|
||||
| T1-02 | Un quai avec plusieurs réceptions/camions | Quai avec 2 réceptions distinctes | Ouvrir la vue | Les deux paires réception/plaque sont affichées sur la même ligne, séparées par ";" | | |
|
||||
| T1-03 | PARKING avec plusieurs camions en attente | 3 camions sur PARKING | Ouvrir la vue | Les 3 paires sont affichées sur la ligne PARKING | | |
|
||||
| T1-04 | Une réception dont le quai est modifié après coup | Réception initialement sur PARKING, déplacée sur QUAI_01 | Modifier le quai | Le tableau se met à jour : la réception disparaît de PARKING et apparaît sur QUAI_01 | | |
|
||||
| T1-05 | Tableau affiché quand aucune réception n'existe | Base vide | Ouvrir la vue | Tous les quais apparaissent avec des colonnes vides, pas d'erreur d'affichage | | |
|
||||
| T1-06 | Un quai avec réceptions + tournées ~~+ OS~~ | | Ouvrir la vue | Afficher tous les combos quai/plaque sur le bon quai | | |
|
||||
|
||||
---
|
||||
|
||||
## Commentaires
|
||||
|
||||
### 💬 Vincent Charvet — 04/03/2026
|
||||
|
||||
**Revue fonctionnelle**
|
||||
|
||||
**Empêcher l'assignation de différentes classes de préavis de réception** — Condition sur le `ViewAssistCreateReceptionOE` et exception levée si au moins un des `InboundClassCode` des ordres sélectionnés est différent du premier sélectionné (toujours au moins 1 élément sélectionné à ce stade).
|
||||
|
||||
**Résumé d'occupation** — Créer une nouvelle entité avec le code du quai et une chaîne de caractère contenant les Réception/Tournées/OS associés, ajouter un `viewDetailPanel` dans la vue `ReceptionVList` avec cette entité.
|
||||
|
||||
---
|
||||
|
||||
### 💬 Justine Beutin — 04/03/2026
|
||||
|
||||
Corrections suite au point du 04/03 avec Vincent et Michaël.
|
||||
|
||||
---
|
||||
|
||||
### 💬 Vincent Charvet — 05/03/2026
|
||||
|
||||
#### Technical implementation
|
||||
|
||||
**Entities :**
|
||||
- `CST_DockStationsWorkloadForView` : Entity created to display informations about dock workload in both `ReceptionVList` and `VAssistReceptionAssignDock` views
|
||||
|
||||
**Queries :**
|
||||
- `CST_DockStationsWorkload_ForView` : Query for entity `CST_DockStationsWorkloadForView`
|
||||
|
||||
**Views :**
|
||||
- `ReceptionVList` : Add ViewDetailPanel with workload for each dock (associated receptions and routes)
|
||||
- `VAssistCreateReceptionOE` : Add an exception in Commands expression codes steps 2 and 3 raised when inbound orders with different classes are selected
|
||||
- `VAssistReceptionAssignDock` : Change entity in step 1 from `Station` to `CST_DockStationsWorkloadForView` and show workload
|
||||
|
||||
**Resources :**
|
||||
- `CST_Reception_MultiClassError`
|
||||
- FR : Impossible de créer une réception avec des ordres d'entrée ayant des classes de préavis de réception différentes
|
||||
- EN : Can't create reception with inbound orders with different inbound order class
|
||||
- `ViewField_VAssistantCreateReceptionOE_Truck`
|
||||
- FR : `#KEY#[Prop_Reception_Document, PARAMS[]]`
|
||||
- EN : `#KEY#[Prop_Reception_Document, PARAMS[]]`
|
||||
- `Reception_DockWorkload_Panel_Title`
|
||||
- FR : Occupation des quais
|
||||
- EN : Docks workload
|
||||
- `Prop_Reception_Document`
|
||||
- FR : Camion
|
||||
- EN : Truck
|
||||
- `Prop_Station_Workload`
|
||||
- FR : Assignations / Camions
|
||||
- EN : Assignations / Trucks
|
||||
|
||||
**Git :** [`1d2acc3e6e`](https://msscode.mecalux.com/Proyectos_SW/EASYWMS_11351_LIMAGRAIN/commit/1d2acc3e6efef09df3e2a760574e35afd30ca166)
|
||||
|
||||
---
|
||||
|
||||
### 💬 Nicolas Chabanis — 06/03/2026
|
||||
|
||||
**Revue de code non valide**
|
||||
|
||||
**Ressources :**
|
||||
- `Prop_Station_Workload`, `Reception_DockWorkload_Panel_Title`, `ViewField_VAssistantCreateReceptionOE_Truck` : Les ressources custom doivent être préfixées par `CST_`
|
||||
|
||||
**Views :**
|
||||
- `VAssistCreateReceptionOE`
|
||||
- Dans l'expression code du step 3, il manque le commentaire `//Custom end`
|
||||
- Question à poser au CDP quant à la pertinence de rendre obligatoire le camion car sans l'affichage perd son intérêt et éviter le risque d'oubli
|
||||
- `ReceptionVList`
|
||||
- Mettre la propriété `Column Span = 2` sur le ViewDetailPanel `CST_Docks_Workload`, afin qu'il prenne toute la largeur
|
||||
- Le titre demandé pour la deuxième colonne est **"Réceptions / Camions"**
|
||||
|
||||
---
|
||||
|
||||
### 💬 Vincent Charvet — 09/03/2026
|
||||
|
||||
Plaque non obligatoire à priori, pourra être renseigné après création de la réception.
|
||||
|
||||
Ajout des mêmes conditions sur les différentes classes d'ordres pour la création de réception depuis la vue des ordres d'entrées.
|
||||
|
||||
---
|
||||
|
||||
### 💬 Nicolas Chabanis — 09/03/2026
|
||||
|
||||
**Revue de code validée** ✅
|
||||
@@ -0,0 +1,224 @@
|
||||
# Export Jira — LIMAGRAIN DEV : LIM-63, LIM-64, LIM-65
|
||||
|
||||
> Projet : **LIMAGRAIN - DEV**
|
||||
> Lot : **#LOT1.1**
|
||||
> Statut : **En cours de test client (pré-production)**
|
||||
> Assigné : Arthur Ria
|
||||
> Exporté le : 2026-05-06
|
||||
|
||||
---
|
||||
|
||||
## LIM-63 — #LOT1.1 [RECEPTION + EXPEDITION] Affichage chauffeurs
|
||||
|
||||
**Lien :** https://easywmsfrance.atlassian.net/browse/LIM-63
|
||||
|
||||
### Contexte
|
||||
|
||||
Dans [LIM-62](https://easywmsfrance.atlassian.net/browse/LIM-62) et LIM-XXX, on associe les réceptions et ordres de sortie à des quais en indiquant un camion (sa plaque).
|
||||
|
||||
Le client souhaite afficher ces informations directement en dehors de l'entrepôt, près des quais extérieurs, pour indiquer aux chauffeurs où ils doivent attendre / se garer.
|
||||
|
||||
### Développement
|
||||
|
||||
Faire une WS qui affiche uniquement les quais avec des réceptions/ordres de sortie associés. Afficher les plaques (Document).
|
||||
|
||||
Prévoir la place pour afficher **6 quais + le parking** sans devoir scroller.
|
||||
|
||||
Documentation de référence pour créer ce dialogue :
|
||||
https://msscc.mecalux.com/documentation/Development/master/ES/map_working_easybuilder/user_manual/dialogs/index.md
|
||||
|
||||
### Commentaires
|
||||
|
||||
_Aucun commentaire sur ce ticket._
|
||||
|
||||
---
|
||||
|
||||
## LIM-64 — #LOT1.1 [RECEPTION] TRF - Déclaration image de quai
|
||||
|
||||
**Lien :** https://easywmsfrance.atlassian.net/browse/LIM-64
|
||||
|
||||
### Contexte
|
||||
|
||||
Les camions de réception sont déchargés manuellement par un cariste sur une image de quai (poumon de réception).
|
||||
|
||||
**Règle de déchargement physique** : Le cariste doit décharger en commençant par l'emplacement le plus éloigné du quai en suivant un ordre précis. Cela permet d'identifier précisément les emplacements occupés pour les AGV.
|
||||
|
||||
Ensuite, via son TRF, l'opérateur va associer la réception à la bonne image de quai puis faire sa pré-déclaration : nombre de palettes, présence de big-bag, etc.
|
||||
|
||||
Une fois terminé, les AGV viendront récupérer les palettes pour les apporter sur les postes de travail ou directement dans le TK selon la classe des ordres d'entrées de la réception.
|
||||
|
||||
### Développement
|
||||
|
||||
> **PRODUCTION** : Écran 1, écran 3, écran 4, écran 5, écran 7
|
||||
> **AUTRES** : Écran 1, écran 2, écran 3, écran 4, écran 5, écran 6, écran 7
|
||||
|
||||
Créer un nouveau menu TRF dans **Réceptions > Image de quai**.
|
||||
|
||||
#### Écran 1 — Type de réception
|
||||
|
||||
Choix parmi cette liste :
|
||||
- Production
|
||||
- Autres (fournisseur, inter-site, retours, etc.)
|
||||
- Pile de palette
|
||||
|
||||
Échappe : retour menu.
|
||||
|
||||
#### Écran 2 — Sélection de la réception
|
||||
|
||||
À afficher seulement si choix du type de réception = **Autres**.
|
||||
|
||||
L'opérateur choisit la réception qu'il souhaite faire.
|
||||
|
||||
Échap : retour écran 1.
|
||||
|
||||
#### Écran 3 — Nombre de palettes
|
||||
|
||||
Prompt : « Nombre de palettes de la réception »
|
||||
|
||||
Prompt d'un nombre entre 1 et 26 inclus.
|
||||
|
||||
Vérification à validation :
|
||||
- que le chiffre est valide
|
||||
- que la somme des supports déjà présents sur le poumon ainsi que le nombre validé <= 26
|
||||
|
||||
Si non validation : message d'erreur explicatif clair avec bouton Ok pour recommencer l'écran 3.
|
||||
|
||||
Échappe : retour écran 2.
|
||||
|
||||
#### Écran 4 — Choix image de quai
|
||||
|
||||
Dans le WF, lister tous les poumons liés aux quais (réception + expédition).
|
||||
De cette liste, enlever tous ceux qui ont des supports clients (liés à des ordres de sortie) ou qui ont des tâches de shipping en destination.
|
||||
Enlever également ceux dont le nombre de supports == capacité (poumon plein).
|
||||
|
||||
Prompt : « Choix de l'image de quai » avec un bouton Liste (qui liste les poumons filtrés).
|
||||
|
||||
Au moment du choix du poumon parmi ceux de la liste ou si l'opérateur saisit/scanne, vérifier si le poumon est disponible en refaisant les mêmes checks que précédemment. À refaire même s'il choisit dans la liste — entre l'affichage de la liste filtrée et le choix de l'opérateur, la réalité a pu changer.
|
||||
|
||||
Échappe : retour écran 3.
|
||||
|
||||
#### Écran 5 — Sous-emplacement de départ
|
||||
|
||||
Prompt : « Sous-emplacement de la première palette de la réception »
|
||||
|
||||
Prompt d'un nombre.
|
||||
|
||||
Vérification à validation :
|
||||
- que le chiffre est valide
|
||||
- que l'emplacement de départ ainsi que tous ceux qui suivent pour atteindre le nombre de palettes précédemment indiqué soient vides
|
||||
|
||||
Si non validation : message d'erreur explicatif clair avec bouton Ok pour recommencer l'écran 4.
|
||||
|
||||
> Exemple : si j'ai déjà des palettes d'une autre réception (rouge) et que j'en déclare 5 nouvelles, je ne peux pas indiquer des positions 3 ; 4 ; 23 ; 24 ; 25 ; 26.
|
||||
|
||||
Échappe : retour écran 4.
|
||||
|
||||
#### Écran 6 — Présence de big-bags
|
||||
|
||||
Uniquement si l'opérateur a choisi le type de réception **Autre**.
|
||||
|
||||
Prompt : « Présence d'un big-bag parmi les palettes de la réception ? »
|
||||
|
||||
Boutons **OUI / NON**. Conserver l'information.
|
||||
|
||||
Échappe : retour écran 4.
|
||||
|
||||
#### Écran 7 — Validation
|
||||
|
||||
Afficher un écran de récapitulatif :
|
||||
|
||||
- Image de quai : XXX
|
||||
- Type de réception : XXX
|
||||
- Nombre de palettes : XXX
|
||||
- Sous-emplacement de départ : XXX
|
||||
- Présence de big-bags : oui / non
|
||||
|
||||
Avec un bouton **VALIDER**.
|
||||
|
||||
Échappe : retour écran 5.
|
||||
|
||||
Si validation :
|
||||
- Créer informatiquement les palettes en les répartissant sur les sous-emplacements à partir du premier indiqué par l'opérateur. Les palettes sont vides et de type `PALETTE_US`. Leur séquence ne doit pas être la séquence classique mais une séquence de **18 caractères qui commence par 8**. Ex : `800000000000000001`, `800000000000000002`, etc. (Séquence décrite dans [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14))
|
||||
- Uniquement si l'opérateur a choisi le type de réception **Autre** → impression d'une étiquette pour chaque palette déclarée avec le rapport décrit dans [LIM-65](https://easywmsfrance.atlassian.net/browse/LIM-65)
|
||||
- Retour écran 2.
|
||||
|
||||
### Cas de tests
|
||||
|
||||
#### Écran 2 — Sélection de la réception
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E2-01 | Affichage de l'écran | Type de réception sélectionné = Autre | Sélection d'une réception | Affichage du choix de la réception | | |
|
||||
|
||||
#### Écran 3 — Nombre de palettes
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E3-01 | Somme palettes saisie = exactement 26 | | Saisir 26 | Validation OK, passage à l'écran 4 | | |
|
||||
| E3-02 | Somme palettes saisie = 27 | | Saisir 27 | Rejet avec message d'erreur mentionnant le dépassement de capacité | | |
|
||||
|
||||
#### Écran 4 — Choix image de quai
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E4-01 | Poumon plein | Poumon plein avant l'affichage de la liste | | Le poumon n'apparait pas dans la liste | | |
|
||||
| E4-02 | Sélection d'un poumon plein | Poumon plein avant l'affichage de la liste | Saisir le code du poumon plein | Message d'erreur indiquant que le poumon sélectionné n'est pas valide | | |
|
||||
| E4-03 | Poumon devenu plein entre l'affichage de la liste et la sélection | Poumon visible dans la liste au moment de l'affichage, puis rempli par un autre utilisateur avant confirmation | Sélectionner ce poumon depuis la liste | Rejet avec message d'erreur, le check se refait au moment du choix | | |
|
||||
| E4-04 | Poumon ayant reçu un support client entre l'affichage et la sélection | Poumon visible dans la liste, un ordre de sortie lui est associé entretemps | Sélectionner ce poumon depuis la liste | Rejet avec message d'erreur | | |
|
||||
| E4-05 | Poumon dont le nombre de supports est exactement égal à la capacité | Poumon plein | Ouvrir la liste | Le poumon est absent de la liste | | |
|
||||
| E4-06 | Poumon qui ne contient pas assez d'emplacements libres consécutifs sur les positions suivant le conteneur sur la plus grande position | Poumon de capacité 26, palette déclarée sur l'emplacement 20. Nombre de palettes sélectionné = 7 | Ouvrir la liste | Le poumon est absent de la liste | | |
|
||||
|
||||
#### Écran 5 — Sous-emplacement de départ
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E5-01 | Séquence valide qui se termine pile au dernier sous-emplacement | Poumon de capacité 26, 3 palettes déclarées | Saisir 24 (→ 24, 25, 26) | Validation OK | | |
|
||||
| E5-02 | Séquence qui dépasse le dernier sous-emplacement d'un | Poumon de capacité 26, 3 palettes déclarées | Saisir 25 (→ 25, 26, 27 inexistant) | Rejet avec message d'erreur | | |
|
||||
| E5-03 | Séquence avec un seul emplacement occupé au milieu | Palettes rouges uniquement en position 5, 5 palettes déclarées | Saisir 3 (→ 3, 4, **5**, 6, 7) | Rejet car l'emplacement 5 est occupé, même s'il n'est pas le premier de la séquence | | |
|
||||
| E5-04 | Sous-emplacement de départ libre mais dernier emplacement de la séquence occupé | Palette rouge en position 8, 5 palettes déclarées | Saisir 4 (→ 4, 5, 6, 7, **8**) | Rejet car l'emplacement 8 est occupé | | |
|
||||
| E5-05 | Sous-emplacement de départ occupé, le reste de la séquence est libre | Palette rouge uniquement en position 3, 5 palettes déclarées | Saisir 3 | Rejet dès le premier emplacement | | |
|
||||
|
||||
#### Écran 6 — Sélection BigBag
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E6-01 | Affichage de l'écran | Type de réception sélectionné = Autre | | Affichage du choix de la présence de big-bag | | |
|
||||
|
||||
#### Écran 7 — Validation & création
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
|----|-------------|---------------|---------|-----------------|----------------|----------------|
|
||||
| E7-01 | Les palettes sont créées sur les bons sous-emplacements et pas sur les suivants | 3 palettes, départ emplacement 5 | Valider | Palettes créées exactement sur 5, 6, 7 — emplacement 8 reste vide | | |
|
||||
| E7-02 | Les séquences générées commencent bien par 8 et font exactement 18 caractères | N/A | Valider avec n palettes | Toutes les séquences font 18 caractères et commencent par 8 | | |
|
||||
| E7-04 | Type Production : aucune impression | Type = Production | Valider | Aucune impression d'étiquette déclenchée | | |
|
||||
| E7-05 | Nombre d'étiquettes imprimées = exactement le nombre de palettes déclarées | Type = Autre, 4 palettes déclarées | Valider | 4 étiquettes imprimées, ni plus ni moins | | |
|
||||
| E7-06 | Poumon/position de départ devenu indisponible | Poumon ou position de départ devenu indisponible après sélection | Valider | Message d'erreur indiquant la raison | | |
|
||||
| E7-07 | Réception sélectionnée supprimée | Réception sélectionnée est supprimée | Valider | Message d'erreur indiquant la raison | | |
|
||||
|
||||
### Commentaires
|
||||
|
||||
_Aucun commentaire sur ce ticket._
|
||||
|
||||
---
|
||||
|
||||
## LIM-65 — #LOT1.1 [RECEPTION] Etiquette support image de quai
|
||||
|
||||
**Lien :** https://easywmsfrance.atlassian.net/browse/LIM-65
|
||||
|
||||
### Contexte
|
||||
|
||||
Dans [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64), on imprime une étiquette support pour chaque palette en provenance d'une réception qui n'est pas de type **PRODUCTION**.
|
||||
|
||||
### Modèle — Format A5 — Paysage
|
||||
|
||||
Champs à afficher sur l'étiquette :
|
||||
|
||||
- **CODE** : code du support
|
||||
- **RECEPTION** : code de la réception
|
||||
- **DATE** : date d'impression
|
||||
- **EMPL.** : sous-emplacement du poumon
|
||||
- **QR Code** : code du support
|
||||
|
||||
### Commentaires
|
||||
|
||||
_Aucun commentaire sur ce ticket._
|
||||
@@ -0,0 +1,132 @@
|
||||
# LIM-66 — #LOT1.3 [ENTREE/SORTIE] Passage PIE
|
||||
|
||||
**Projet :** LIMAGRAIN - DEV
|
||||
**Statut :** En revue de code
|
||||
**Lien Jira :** https://easywmsfrance.atlassian.net/browse/LIM-66
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
Le passage au PIE est commun à tous les flux de réception et s'applique à tous les supports qui entrent dans l'installation automatisée : palettes sources de picking, échantillonnage, etc. Ce point de contrôle automatique vérifie l'identité et la conformité de la palette avant son stockage dans l'ASRS.
|
||||
|
||||
| Contrôle | Critère de validation |
|
||||
| --- | --- |
|
||||
| Étiquette RFID | Connue (détectable) |
|
||||
| Hauteur | ≤ 1900 mm |
|
||||
| Largeur | ≤ 1100 mm |
|
||||
| Longueur | ≤ 1300 mm |
|
||||
| Poids | ≤ 1250 kg |
|
||||
| État palette bois | Correct (les lames du TK ne doivent pas toucher le bois et ne pas manquer de skis de palette) |
|
||||
|
||||
Selon le flux, il y aura des customs différents à déclencher au passage PIE d'un support. Liste :
|
||||
|
||||
1. Mise à jour du poids support/stock
|
||||
2. Détection écart de poids et application d'un verrou de support
|
||||
3. Suppression de la palette virtuelle
|
||||
|
||||
---
|
||||
|
||||
## Développement
|
||||
|
||||
### 1. Pesée [ENTREE/SORTIE]
|
||||
|
||||
Au moment où la palette passe au PIE, elle sera pesée. La valeur est remontée au WMS.
|
||||
|
||||
Il faut ensuite récupérer le poids des lignes de stocks :
|
||||
|
||||
```
|
||||
Poids lignes de stock = Poids total mesuré − Poids théorique support (PALETTE_US)
|
||||
```
|
||||
|
||||
Le poids calculé est réparti au prorata entre les différentes lignes de stock.
|
||||
Calcul du ratio de chaque ligne :
|
||||
|
||||
```
|
||||
Ratio = Poids théorique de la ligne / Poids théorique total de toutes les lignes
|
||||
```
|
||||
|
||||
(Utilisation des informations de poids des conversions des articles.)
|
||||
|
||||
Poids réel de chaque ligne :
|
||||
|
||||
```
|
||||
Poids réel de la ligne = Poids lignes de stock × Ratio
|
||||
```
|
||||
|
||||
Cette information est stockée dans le champ **"Poids réel"** de la ligne de stock.
|
||||
|
||||
---
|
||||
|
||||
### 2. Détection écarts [ENTREE / SORTIE]
|
||||
|
||||
**Condition de blocage palette mono-référence** : Si l'écart de poids correspond à un écart d'une ligne de stock (article manquant ou en trop → écart ≥ poids unitaire de l'article) : blocage via verrou de support et alerte générée.
|
||||
|
||||
> **Note** : Le poids du chapitre 1 est quand même appliqué et recalculé, même en cas de blocage.
|
||||
|
||||
**Condition de blocage palette multi-références**
|
||||
|
||||
- Utilisation du **plus petit poids unitaire** comme seuil d'alerte
|
||||
- Si écart > poids du plus petit article → blocage + alerte
|
||||
- **Blocage via verrou sur le SUPPORT** (pas sur le stock)
|
||||
|
||||
Le verrou à utiliser est par défaut **"HORS TOLERANCE"** et **"ECART RETOUR"** uniquement dans le cas d'un retour client.
|
||||
|
||||
- Si le verrou est **"HORS TOLERANCE"** : la palette rentre quand même dans l'ASRS (le verrou le permettra).
|
||||
- Si le verrou est **"ECART RETOUR"** : il faut refuser la palette et l'envoyer en rejet (destination gérée en standard via EasyS).
|
||||
|
||||
Le Custom attribute 1 de la ligne de stock contient le poids unitaire de l'article mis à jour avec la pesée précédente. S'il a une valeur, c'est ce poids qui doit être utilisé dans les calculs.
|
||||
|
||||
---
|
||||
|
||||
### 3. Mise à jour du poids de la ligne de stock
|
||||
|
||||
Le custom attribute 1 de chaque ligne de stock doit être mis à jour avec le poids unitaire mesuré :
|
||||
|
||||
```
|
||||
Poids unitaire mesuré = Poids réel de la ligne / Quantité de la ligne
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cas de tests
|
||||
|
||||
### 1. Pesée au PIE
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 1 | Pesée nominale — palette mono-référence | Palette avec 1 ligne de stock connue, poids théorique support PALETTE_US renseigné, poids unitaire article renseigné dans la conversion | La palette passe au PIE, le capteur remonte un poids total mesuré | Le WMS calcule : Poids lignes de stock = Poids mesuré − Poids PALETTE_US. Le poids réel de la ligne = poids lignes de stock × 1 (ratio = 100%). Le champ "Poids réel" de la ligne de stock est mis à jour. | | |
|
||||
| 2 | Pesée nominale — palette multi-références | Palette avec N lignes de stock de référence différentes, poids théoriques renseignés dans les conversions articles | La palette passe au PIE avec un poids total mesuré | Le ratio de chaque ligne est calculé : Ratio = Poids théorique ligne / Poids théorique total. Le poids réel de chaque ligne = Poids lignes de stock × Ratio. La somme des poids réels des lignes = Poids lignes de stock. Chaque champ "Poids réel" est mis à jour. | | |
|
||||
| 3 | Poids du support correctement déduit | Support PALETTE_US avec poids théorique = X kg renseigné dans le WMS | Palette passe au PIE, poids total mesuré = Y kg | Le poids utilisé pour le calcul des lignes de stock = Y − X. Le poids de la palette bois n'est pas compté dans le stock. | | |
|
||||
| 4 | Pesée appliquée même en cas de blocage | Palette avec écart de poids déclenchant un verrou | Palette passe au PIE avec écart de poids | Le poids réel est quand même calculé et stocké dans les lignes de stock, malgré l'application du verrou. | | |
|
||||
|
||||
---
|
||||
|
||||
### 2. Détection d'écart de poids — Palette mono-référence
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 5 | Pas d'écart — pas de blocage | Palette mono-référence, poids mesuré dans la tolérance (écart < poids d'1 unité) | Palette passe au PIE | Aucun verrou posé sur le support. Aucune notification générée. Palette rentre dans l'ASRS normalement. | | |
|
||||
| 6 | Écart = 1 unité manquante — blocage HORS TOLERANCE (flux standard) | Palette mono-référence, flux non retour client. Écart de poids = poids d'une ligne de stock (article manquant détecté) | Palette passe au PIE avec écart | Verrou "HORS TOLERANCE" posé sur le support. Notification SmartUI générée. La palette rentre quand même dans l'ASRS. | | |
|
||||
| 7 | Écart = 1 unité en trop — blocage HORS TOLERANCE (flux standard) | Palette mono-référence, flux non retour client. Écart de poids = poids d'une ligne de stock en excédent | Palette passe au PIE avec excédent de poids | Verrou "HORS TOLERANCE" posé sur le support. Notification SmartUI générée. La palette rentre dans l'ASRS. | | |
|
||||
| 8 | Écart détecté — blocage ECART RETOUR (flux retour client) | Palette mono-référence, flux retour client (InboundType = 1). Écart de poids = poids d'une ligne de stock | Palette passe au PIE avec écart | Verrou "ECART RETOUR" posé sur le support. La palette est **refusée et envoyée en rejet** (destination gérée par EasyS). Notification SmartUI dédiée au rejet générée. | | |
|
||||
|
||||
---
|
||||
|
||||
### 3. Détection d'écart de poids — Palette multi-références
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 9 | Écart < poids unitaire min — pas de blocage | Palette multi-références. Poids unitaire le plus petit = P_min. Écart de poids < P_min | Palette passe au PIE | Aucun verrou. Aucune notification. Palette rentre dans l'ASRS. | | |
|
||||
| 10 | Écart = poids unitaire min — blocage HORS TOLERANCE (flux standard) | Palette multi-références, flux non retour client. Écart de poids ≥ poids unitaire le plus petit parmi tous les articles | Palette passe au PIE avec écart | Verrou "HORS TOLERANCE" posé sur le support. Notification SmartUI générée. Palette rentre dans l'ASRS. | | |
|
||||
| 11 | Écart > poids unitaire min — blocage HORS TOLERANCE (flux standard) | Palette multi-références, flux non retour client. Écart > P_min | Palette passe au PIE | Verrou "HORS TOLERANCE" posé sur le support. Notification SmartUI générée. Palette rentre dans l'ASRS. | | |
|
||||
| 12 | Écart ≥ poids unitaire min — blocage ECART RETOUR (flux retour client) | Palette multi-références, flux retour client. Écart ≥ P_min | Palette passe au PIE avec écart | Verrou "ECART RETOUR" posé sur le support. Palette refusée et envoyée en rejet. Notification SmartUI dédiée au rejet générée. | | |
|
||||
|
||||
---
|
||||
|
||||
### 4. Comportement du verrou et de la palette après PIE
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 13 | Verrou HORS TOLERANCE — palette autorisée en ASRS | Support avec verrou "HORS TOLERANCE" posé au PIE | Palette orientée vers l'ASRS après passage PIE | La palette entre dans l'ASRS malgré le verrou. Le verrou reste actif sur le support. | | |
|
||||
| 14 | Verrou ECART RETOUR — palette refusée | Support avec verrou "ECART RETOUR" posé au PIE | Palette arrive en fin de convoyeur PIE | La palette est rejetée. Destination de rejet gérée par EasyS. Aucun stockage dans l'ASRS. | | |
|
||||
@@ -0,0 +1,209 @@
|
||||
# LIM-67 — #LOT1.3 [RECEPTION] Postes de travail - Flux fournisseurs/intersites
|
||||
|
||||
**Projet :** LIMAGRAIN - DEV
|
||||
**Statut :** En attente CDP
|
||||
**Assigné à :** Arthur Ria
|
||||
**Lien Jira :** https://easywmsfrance.atlassian.net/browse/LIM-67
|
||||
|
||||
---
|
||||
|
||||
## Contexte — Réception fournisseurs
|
||||
|
||||
Contrairement aux réceptions en provenance de la production, les réceptions externes (fournisseurs) et transferts intersites (autres sites Limagrain) suivent le même flux. Les palettes doivent passer par un poste de travail pour identification et déclaration avant d'aller vers l'ASRS (contrairement à la production qui passe directement de l'image de quai au PIE de l'ASRS).
|
||||
|
||||
**Résumé du process complet**
|
||||
|
||||
1. Déclaration sur l'image de quai
|
||||
2. Déplacement AGV → Poste de travail
|
||||
3. **Traitement au poste de travail** ← *Objet de cette tâche*
|
||||
4. Déplacement AGV → Table d'entrée (+ filmage si demandé)
|
||||
5. Passage PIE
|
||||
6. Stockage ou rejet
|
||||
7. Clôture de la réception
|
||||
8. Libération quai / image de quai
|
||||
|
||||
Les opérateurs travaillent sur postes de travail constitués de 3 tables. Les AGV amènent automatiquement les palettes des images de quai au fur et à mesure sur les bonnes tables.
|
||||
|
||||
Les opérateurs utilisent le mode **Tâches automatiques** sur PC.
|
||||
|
||||
Si la palette reçue est **multi-référence** : l'opérateur crée une palette vide sur une table de préparation disponible, effectue le tri de marchandise, et chaque palette résultante = une seule référence.
|
||||
|
||||
---
|
||||
|
||||
## Développement
|
||||
|
||||
### 1. Sélection de la réception
|
||||
|
||||
Le code de réception est récupéré automatiquement en scannant le conteneur présent sur le poste de picking, grâce au `CustomAttribute8`.
|
||||
|
||||
Rajouter le nom du fournisseur en plus du code pour afficher : **"Fournisseur: CODE - NOM"**.
|
||||
Le faire sur **tous les écrans** du process.
|
||||
|
||||
---
|
||||
|
||||
### 2. Confirmation de création (BIG-BAG)
|
||||
|
||||
Si le conteneur scanné est un conteneur virtuel de réception, un écran de confirmation pour créer le nouveau support "réel" est affiché.
|
||||
|
||||
Sur l'écran de paramétrage du support, rajouter :
|
||||
- Une ligne indiquant que BIG BAG n'est pas sélectionné : **"BIG BAG : NON"**
|
||||
- Un bouton **"BIG BAG ON"**
|
||||
|
||||
Comportement :
|
||||
- Clic sur **"BIG BAG ON"** → ligne passe à **"BIG BAG : OUI"**, bouton bascule en **"BIG BAG OFF"**
|
||||
- Dans les deux cas, stocker `true`/`false` dans le **CstAtt02** du support
|
||||
|
||||
Impression d'une **étiquette RFID** avec le code support dès la confirmation de création du conteneur. (Voir LIM-68)
|
||||
|
||||
---
|
||||
|
||||
### 3. Écran "menu principal"
|
||||
|
||||
Création d'un écran avec choix d'actions possibles :
|
||||
|
||||
- Ajouter stock
|
||||
- Nouveau support
|
||||
- Changer de support
|
||||
- Imprimer étiquette
|
||||
- Terminer
|
||||
|
||||
Sur cet écran est toujours affiché à droite les informations du support actuellement sélectionné.
|
||||
Après chaque action complétée, on retourne sur cet écran.
|
||||
|
||||
---
|
||||
|
||||
### A — Ajouter stock
|
||||
|
||||
Écrans standard : sélection article, lot, quantité.
|
||||
|
||||
Afficher la **quantité attendue + [UdM]** sur l'écran du prompt de quantité article (ne pas pré-remplir le prompt).
|
||||
|
||||
Garder l'écran standard affichant le statut de stock, mais masquer les boutons de modification de statut.
|
||||
|
||||
Skipper les écrans de fin de date de statut et de commentaire.
|
||||
|
||||
Pour l'**anoxie** : set le `CstAtt03` du support à `true`. Cela indique qu'à terme cette palette devra être anoxiée.
|
||||
|
||||
---
|
||||
|
||||
### B — Nouveau support
|
||||
|
||||
Scan de l'emplacement où créer le support, puis confirmation de création (étape 2).
|
||||
Le nouveau conteneur devient le conteneur actuellement sélectionné.
|
||||
|
||||
---
|
||||
|
||||
### C — Changer de support
|
||||
|
||||
Scan du code support à définir comme conteneur actuellement sélectionné.
|
||||
|
||||
---
|
||||
|
||||
### D — Imprimer étiquette
|
||||
|
||||
Permet la réimpression de l'étiquette support RFID.
|
||||
|
||||
---
|
||||
|
||||
### E — Terminer
|
||||
|
||||
**Vérification fermeture réception :**
|
||||
Si le conteneur actuel est le dernier correspondant à cette réception (Nombre de conteneurs virtuels avec `CstAtt8` = codeRecep + nombre conteneurs avec `CstAtt8` = codeRecep & `CstAtt10` = `true`), proposer la fermeture de la réception avec uniquement l'option confirmer.
|
||||
|
||||
**Sélection du programme de filmage :**
|
||||
Ajouter un dialogue qui demande le programme de filmage en choisissant parmi une liste :
|
||||
|
||||
```
|
||||
0. Pas de filmage
|
||||
1. Programme 1
|
||||
2. Programme 2
|
||||
3. Programme 3
|
||||
4. …
|
||||
```
|
||||
|
||||
Cette liste provient d'un paramètre nommé **"FILMAGES"** dont la valeur par défaut est :
|
||||
|
||||
```
|
||||
0;Pas de filmage|A;Programme 1|B;Programme 2|C;Programme 3
|
||||
```
|
||||
|
||||
Stocker la valeur choisie (`0`, `A`, `B`, `C`…) dans le **CstAtt05** du support.
|
||||
|
||||
Après validation du programme de filmage, une tâche est générée pour évacuer le conteneur du poste de travail.
|
||||
|
||||
---
|
||||
|
||||
## Cas de tests
|
||||
|
||||
> ⚠️ Les cas de tests ci-dessous sont **barrés dans le ticket d'origine** (non applicables / à compléter ultérieurement). Ils sont conservés ici à titre de référence.
|
||||
|
||||
### 1. Sélection de la réception — Affichage fournisseur
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~1~~ | ~~Affichage CODE - NOM fournisseur sur l'écran de sélection~~ | ~~OE fournisseur existant avec code et nom renseignés~~ | ~~Arriver sur l'écran de sélection de la réception~~ | ~~Le fournisseur s'affiche sous la forme "Fournisseur: CODE - NOM"~~ | | |
|
||||
| ~~2~~ | ~~Affichage CODE - NOM sur tous les écrans du process~~ | ~~OE fournisseur avec code et nom renseignés~~ | ~~Dérouler le process complet jusqu'à la fin~~ | ~~Le libellé "Fournisseur: CODE - NOM" est présent sur chaque écran du workflow~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 2. Big Bag
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~5~~ | ~~État initial Big Bag = NON~~ | ~~Support en cours de paramétrage, CstAtt02 non valorisé~~ | ~~Arriver sur l'écran de paramétrage du support~~ | ~~La ligne affiche "BIG BAG : NON" et le bouton "BIG BAG ON" est visible~~ | | |
|
||||
| ~~6~~ | ~~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~~ | | |
|
||||
| ~~7~~ | ~~Désactivation Big Bag après activation~~ | ~~Big Bag activé (OUI), bouton "BIG BAG OFF" affiché~~ | ~~Cliquer sur "BIG BAG OFF"~~ | ~~La ligne repasse à "BIG BAG : NON", CstAtt02 = false~~ | | |
|
||||
| ~~8~~ | ~~Toggle multiple (ON → OFF → ON)~~ | ~~Écran de paramétrage affiché~~ | ~~Cliquer ON, puis OFF, puis ON~~ | ~~À chaque toggle l'état et le CstAtt02 sont cohérents. Pas de dérive~~ | | |
|
||||
| ~~9~~ | ~~CstAtt02 persisté après validation du support~~ | ~~Big Bag activé sur un support~~ | ~~Valider le support et terminer le process~~ | ~~CstAtt02 = true est bien enregistré sur le support dans la base WMS~~ | | |
|
||||
| ~~10~~ | ~~Big Bag désactivé : CstAtt02 = false enregistré~~ | ~~Process complet sans activer le Big Bag~~ | ~~Terminer le process sans toucher au Big Bag~~ | ~~CstAtt02 = false est bien enregistré sur le support (pas null, pas vide)~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 3. Affichage de la quantité
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~11~~ | ~~Quantité attendue + UdM affichée~~ | ~~Ligne de stock avec quantité attendue et UdM renseignées~~ | ~~Arriver sur l'écran du prompt de quantité article~~ | ~~La quantité attendue et l'UdM sont affichées (ex : "Attendu : 75 [SAC]"). Le champ de saisie est vide~~ | | |
|
||||
| ~~12~~ | ~~Prompt non pré-rempli~~ | ~~Ligne de stock avec quantité attendue = 75~~ | ~~Arriver sur l'écran de saisie quantité~~ | ~~Le champ de saisie est vide, l'opérateur doit saisir manuellement~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 4. Statut de stock
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~15~~ | ~~Boutons de modification masqués~~ | ~~Flux fournisseur, écran statut de stock affiché~~ | ~~Arriver sur l'écran du statut de stock~~ | ~~Les boutons de changement de statut sont masqués. Le statut est visible mais non modifiable~~ | | |
|
||||
| ~~16~~ | ~~Écran date de fin de statut skippé~~ | ~~Flux fournisseur~~ | ~~Valider l'écran du statut de stock~~ | ~~L'écran de saisie de date de fin de statut n'apparaît pas~~ | | |
|
||||
| ~~17~~ | ~~Écran commentaire statut skippé~~ | ~~Flux fournisseur~~ | ~~Valider l'écran du statut de stock~~ | ~~L'écran de saisie de commentaire n'apparaît pas~~ | | |
|
||||
| ~~18~~ | ~~Statut affiché correspond bien au stock~~ | ~~Stock avec statut "SAC SALE"~~ | ~~Arriver sur l'écran du statut~~ | ~~Le statut affiché correspond bien à celui du stock en base~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 5. Anoxie
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~19~~ | ~~CstAtt03 = true après validation~~ | ~~Support traité via flux fournisseur~~ | ~~Compléter le process de réception au poste~~ | ~~CstAtt03 du support = true en base WMS~~ | | |
|
||||
| ~~20~~ | ~~CstAtt03 non écrasé en cas de re-passage~~ | ~~Support ayant déjà CstAtt03 = true~~ | ~~Re-processer le support~~ | ~~CstAtt03 reste à true, pas réinitialisé à false~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 6. Filmage
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~21~~ | ~~Dialogue de filmage affiché après le prompt code support~~ | ~~Paramètre FILMAGES renseigné avec les 4 valeurs par défaut~~ | ~~Valider l'écran du prompt code support~~ | ~~Le dialogue de sélection du programme de filmage s'affiche immédiatement~~ | | |
|
||||
| ~~22~~ | ~~Liste filmage issue du paramètre FILMAGES~~ | ~~Paramètre FILMAGES = "0;Pas de filmage\|1;Programme 1\|2;Programme 2\|3;Programme 3"~~ | ~~Arriver sur le dialogue de filmage~~ | ~~La liste affiche exactement les 4 options dans le bon ordre~~ | | |
|
||||
| ~~23~~ | ~~Sélection "Pas de filmage" → CstAtt05 = 0~~ | ~~Process en cours~~ | ~~Sélectionner "Pas de filmage"~~ | ~~CstAtt05 du support = 0 en base~~ | | |
|
||||
| ~~24~~ | ~~Sélection "Programme 2" → CstAtt05 = 2~~ | ~~Process en cours~~ | ~~Sélectionner "Programme 2"~~ | ~~CstAtt05 du support = 2 en base~~ | | |
|
||||
| ~~25~~ | ~~Paramètre FILMAGES modifié (valeur custom)~~ | ~~Paramètre FILMAGES = "0;Aucun\|1;Standard\|5;Renforcé"~~ | ~~Arriver sur le dialogue de filmage~~ | ~~La liste affiche les 3 options custom, pas les valeurs par défaut~~ | | |
|
||||
| ~~26~~ | ~~Paramètre FILMAGES vide ou absent~~ | ~~Paramètre FILMAGES non configuré dans le WMS~~ | ~~Arriver sur le dialogue de filmage~~ | ~~Message d'erreur explicite — pas de crash — CstAtt mis à 0~~ | | |
|
||||
| ~~27~~ | ~~Paramètre FILMAGES avec une seule option~~ | ~~Paramètre FILMAGES = "0;Pas de filmage"~~ | ~~Arriver sur le dialogue de filmage~~ | ~~La liste s'affiche avec la seule option disponible, sélectionnable normalement~~ | | |
|
||||
|
||||
---
|
||||
|
||||
### 7. Étiquette RFID (déclenchement)
|
||||
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| ~~28~~ | ~~Impression auto après l'écran de filmage~~ | ~~Process fournisseur, imprimante disponible~~ | ~~Valider le choix de filmage~~ | ~~L'étiquette RFID (LIM-68) s'imprime automatiquement sans action supplémentaire~~ | | |
|
||||
@@ -0,0 +1,89 @@
|
||||
# LIM-68 — #LOT1.3 [RECEPTION/EXPEDITION] Étiquette support RFID - Monoréférence
|
||||
|
||||
**Projet :** LIMAGRAIN - DEV
|
||||
**Statut :** Attente déploiement pour test
|
||||
**Assigné à :** Arthur Ria
|
||||
**Lien Jira :** https://easywmsfrance.atlassian.net/browse/LIM-68
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
Rapport souhaité par le client pour ses HU (supports) dans le flux de réception fournisseur/intersite.
|
||||
|
||||
---
|
||||
|
||||
## Format A5 — Contenu de l'étiquette
|
||||
|
||||
**Champs à afficher :**
|
||||
|
||||
| N° | Champ | Source |
|
||||
| --- | --- | --- |
|
||||
| — | Quantity | Quantité + UdM |
|
||||
| 1 | Code support | 6 derniers chiffres **en gras** |
|
||||
| 2 | Code-barres | Code 128 du code support en GS1 |
|
||||
| 3 | Code support (avec préfixe) | Code support avec `(00)` devant |
|
||||
| 4 | Specie | `ITM.CstAtt01` |
|
||||
| 5 | Commercial treatment | `ITM.Family.Description` |
|
||||
| 6 | Variety print on bag | Laisser tel quel |
|
||||
| 7 | — | `ITM.CstAtt03` |
|
||||
| 8 | Official Batch | Premier Alias de l'article |
|
||||
| 9 | Internal Batch | `ITM.Code` |
|
||||
| 10 | Code GTIN | `ITM.CstAtt05` |
|
||||
| 11 | Date | Enlever le libellé et ne rien mettre (date non connue de l'ERP) |
|
||||
| 12 | QR GS1 | Voir détail ci-dessous |
|
||||
|
||||
---
|
||||
|
||||
## QR Code GS1
|
||||
|
||||
Contenu du QR Code GS1 :
|
||||
|
||||
| Identifiant | Contenu |
|
||||
| --- | --- |
|
||||
| `00` | Numéro HU (code support) |
|
||||
| `01` | Code GTIN (`ITM.CstAtt05`) |
|
||||
| `10` | Numéro de lot officiel (premier Alias de l'article) |
|
||||
| `21` | Lot SAP (`ITM.Code`) |
|
||||
| `37` | Quantité |
|
||||
|
||||
> ~~`11` : date de production~~ (supprimé)
|
||||
|
||||
---
|
||||
|
||||
## Encodage RFID (ZPL)
|
||||
|
||||
Pour encoder une étiquette RFID avec ZPL, on combine des commandes d'impression (texte, codes-barres) avec des commandes d'encodage de la puce RFID.
|
||||
|
||||
### Structure de base
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
; --- Encodage RFID ---
|
||||
^RFW,H^FD<données>^FS
|
||||
|
||||
; --- Contenu imprimé ---
|
||||
^FO50,50^ADN,36,20^FD<texte affiché>^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
### Exemple concret
|
||||
|
||||
```zpl
|
||||
^XA
|
||||
^MMT
|
||||
^RS8,,,1
|
||||
^RFW,A,0,5,3^FDSupport123456789012^FS
|
||||
^FO30,20^A0N,30,25^FDRapport de support^FS
|
||||
^XZ
|
||||
```
|
||||
|
||||
### Explication des commandes ZPL
|
||||
|
||||
| Commande | Rôle |
|
||||
| --- | --- |
|
||||
| `^XA` / `^XZ` | Début et fin du bloc ZPL |
|
||||
| `^MMT` | Active le mode RFID sur l'imprimante |
|
||||
| `^RS8,,,1` | Timeout RFID à 8, 1 retry en cas d'échec d'encodage |
|
||||
| `^RFW,A,0,5,3` | Écriture RFID en ASCII, depuis le bloc 0, sur 5 blocs (20 octets), en banque User (3) |
|
||||
| `^FDSupport123456789012^FS` | Donnée à encoder (18 caractères) |
|
||||
@@ -0,0 +1,180 @@
|
||||
# Contexte
|
||||
|
||||
Les postes de travail (PK) sont polyvalents et peuvent être utilisés pour différents flux : réception, picking, regroupement, échantillonnage, re certification. Le manager doit pouvoir configurer quels modes sont autorisés sur chaque PK et dans quel ordre de priorité. L'opérateur, de son côté, choisit le mode actif parmi ceux autorisés.
|
||||
|
||||
Cette configuration est utilisée par le job de création de tâches [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) pour savoir si un PK est éligible à recevoir des tâches d'un flux donné, et dans quel ordre de priorité traiter les différents flux.
|
||||
|
||||
> **Note** : L'ancien mode "Esclave" (3 ou 6 tables) est **abandonné** (cf [https://easywmsfrance.atlassian.net/wiki/spaces/LIM/pages/3001524813854/R+ception+V4#4.-Gestion-des-modes-de-postes-de-travail](https://easywmsfrance.atlassian.net/wiki/spaces/LIM/pages/3001524813854/R+ception+V4#4.-Gestion-des-modes-de-postes-de-travail) ). Il est remplacé par un simple message d'avertissement lorsqu'un opérateur ouvre un poste dont le voisin est déjà actif. Les opérateurs étant physiquement à ~2 mètres l'un de l'autre, ils peuvent se coordonner verbalement. Les AGV ont des capteurs de sécurité et demandent l'autorisation de dépose.
|
||||
|
||||
### Modes de travail possibles
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Mode|Correspondance EasyWMS|
|
||||
|Picking|Picking|
|
||||
|Réception|Réception|
|
||||
|Regroupement|Consolidation|
|
||||
|Échantillonnage|Inventaire|
|
||||
|Re certification|Picking|
|
||||
|
||||
---
|
||||
|
||||
# Développement
|
||||
|
||||
### 1. Configuration par le manager (vAssist SmartUI)
|
||||
|
||||
Dans la vue des postes de travail, ajouter un **bouton d'action "Choix modes de travail"** à la sélection d’un ou plusieurs PK.
|
||||
|
||||
Ce bouton ouvre une **vassist** qui permet de :
|
||||
|
||||
- **Cocher/décocher les modes autorisés** parmi : Picking, Réception, Regroupement, Échantillonnage, Re certification
|
||||
|
||||
- **Définir la priorité** de chaque mode coché via un champ numérique (séquence)
|
||||
|
||||
|
||||
**Validation à la soumission de la vassist :**
|
||||
|
||||
- Chaque mode coché doit avoir une priorité renseignée
|
||||
|
||||
- ~~Les priorités doivent former une~~ **~~séquence continue~~** ~~à partir de 1 (ex : 1, 2, 3)~~
|
||||
|
||||
- **~~Pas de doublon~~** ~~de priorité~~
|
||||
|
||||
- **~~Pas de vide~~** ~~dans la séquence (ex : 1, 3 sans 2 est interdit)~~
|
||||
|
||||
- Un mode non coché ne doit pas avoir de priorité
|
||||
|
||||
- Au moins un mode doit être coché (si on veut bloquer le PK, on utilise le bouton standard dédié)
|
||||
|
||||
|
||||
Si la validation échoue → message d'erreur explicatif et la vassist reste ouverte.
|
||||
|
||||
**Stockage** : La configuration est enregistrée dans un **paramètre SmartUI dédié par PK**. Format proposé :
|
||||
|
||||
`MODES_PK01 = "RECEPTION;1|PICKING;2|CONSOLIDATION;3" MODES_PK02 = "RECEPTION;1"`
|
||||
|
||||
Chaque entrée : MODE;PRIORITÉ séparés par |.
|
||||
|
||||
### 2. Ouverture du poste par l'opérateur (SmartUI)
|
||||
|
||||
L'opérateur accède à **Poste de travail > Station de picking** (nom par défaut dans SmartUI).
|
||||
|
||||
L'interface affiche :
|
||||
|
||||
- ~~Un bouton par mode de travail autorisé par le manager pour ce PK. Les boutons sont visibles uniquement si le mode est autorisé dans la configuration du manager (paramètre MODES_PKxx). Si un mode n'est pas autorisé → le bouton n'apparaît pas.~~
|
||||
|
||||
- **Un bouton "Fermer le poste"** toujours visible
|
||||
|
||||
|
||||
Lorsque l'opérateur clique par **défaut sur tâche automatique et le WMS choisit le bon process en fonction de la palette qui arrive ou est déjà sur son PK**
|
||||
|
||||
~~Ou il peut manuellement cliquer sur un bouton de mode :~~
|
||||
|
||||
1. **~~Vérification poste adjacent~~** ~~(voir section 3)~~
|
||||
|
||||
2. ~~Le PK est activé dans le mode choisi (bouton WF Action)~~
|
||||
|
||||
3. ~~L'opérateur peut~~ **~~changer de mode à la volée~~** ~~sans fermer le poste d'abord — il clique sur un autre bouton de mode~~
|
||||
|
||||
|
||||
### 3. Avertissement poste adjacent
|
||||
|
||||
À chaque ouverture ~~ou changement de mode d'un PK~~, vérifier si le **poste adjacent** est déjà ouvert (en mode actif).
|
||||
|
||||
**Si le poste adjacent est actif** → afficher un message d'avertissement (aussi en mode tâche automatique) :
|
||||
|
||||
> "Attention, le poste [CODE_PK_ADJACENT] est déjà ouvert. Voulez-vous quand même ouvrir ?"
|
||||
|
||||
- Bouton **Confirmer** : le PK s'ouvre normalement
|
||||
|
||||
- Bouton **Annuler** : le PK reste inactif
|
||||
|
||||
|
||||
**Pas de blocage technique** — c'est uniquement informatif.
|
||||
|
||||
Le mapping des postes adjacents est défini via le paramètre PK_ADJACENT.
|
||||
|
||||
### 4. Fermeture du poste
|
||||
|
||||
Le bouton **"Fermer le poste"** est toujours visible, quel que soit le mode actif.
|
||||
|
||||
Au clic :
|
||||
|
||||
- Le PK est remis en mode **inactif** (aucun mode actif)
|
||||
|
||||
- Le PK redevient éligible pour une nouvelle assignation par le job [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) (sous réserve qu'il n'ait plus de tâches actives)
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Paramètres
|
||||
|
||||
| | | | |
|
||||
|---|---|---|---|
|
||||
|Paramètre|Description|Valeur par défaut|Exemple|
|
||||
|MODES_PKxx|Modes autorisés + priorité pour le PK xx (un paramètre par PK, renseigné via la vassist)|_(vide)_|RECEPTION;1\|PICKING;2|
|
||||
|PK_ADJACENT|Paires de postes adjacents|_(vide)_|PK01;PK02\|PK03;PK04|
|
||||
|
||||
---
|
||||
|
||||
# Cas de tests
|
||||
|
||||
### 1. Vassist manager — Configuration des modes
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|1|Bouton "Choix modes de travail" visible|Vue des postes de travail, PK01 sélectionné|Ouvrir la vue|Le bouton d'action "Choix modes de travail" est visible|||
|
||||
|2|Vassist s'ouvre et affiche les 5 modes|PK01 sans configuration préalable|Cliquer sur "Choix modes de travail"|La vassist s'ouvre avec les 5 modes (Picking, Réception, Regroupement, Échantillonnage, Re certification), tous décochés, champs priorité vides|||
|
||||
|3|Configuration nominale — 2 modes avec priorités valides|Vassist ouverte|Cocher Réception (prio 1), Picking (prio 2), valider|Validation OK, paramètre MODES_PK01 enregistré = RECEPTION;1\|PICKING;2|||
|
||||
|4|Configuration nominale — 1 seul mode|Vassist ouverte|Cocher Réception (prio 1) uniquement, valider|Validation OK|||
|
||||
|5|Configuration nominale — 5 modes|Vassist ouverte|Cocher les 5 modes avec priorités 1 à 5, valider|Validation OK|||
|
||||
|~~6~~|~~Erreur — doublon de priorité~~|~~Vassist ouverte~~|~~Cocher Réception (prio 1), Picking (prio 1), valider~~|~~Message d'erreur : doublon de priorité. Vassist reste ouverte~~|||
|
||||
|~~7~~|~~Erreur — vide dans la séquence~~|~~Vassist ouverte~~|~~Cocher Réception (prio 1), Picking (prio 3), valider~~|~~Message d'erreur : séquence non continue (manque la priorité 2). Vassist reste ouverte~~|||
|
||||
|8|Erreur — mode coché sans priorité|Vassist ouverte|Cocher Réception sans renseigner la priorité, valider|Message d'erreur : priorité manquante. Vassist reste ouverte|||
|
||||
|9|Erreur — aucun mode coché|Vassist ouverte|Ne rien cocher, valider|Message d'erreur : au moins un mode requis. Vassist reste ouverte|||
|
||||
|~~10~~|~~Erreur — priorité sur un mode non coché~~|~~Vassist ouverte~~|~~Décocher Réception mais laisser la priorité renseignée, valider~~|~~Message d'erreur ou la priorité est ignorée/nettoyée automatiquement~~|||
|
||||
|~~11~~|~~Modification d'une config existante~~|~~PK01 déjà configuré avec Réception;1 et Picking;2~~|~~Ouvrir la vassist~~|~~Les modes Réception et Picking sont pré-cochés avec les bonnes priorités. Les autres modes sont décochés~~|||
|
||||
|12|Suppression d'un mode existant|PK01 configuré Réception;1, Picking;2|Décocher Picking, mettre Réception prio 1, valider|Paramètre mis à jour : seule Réception;1 est enregistré|||
|
||||
|
||||
---
|
||||
|
||||
### 2. Ouverture du poste par l'opérateur
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|13|~~Boutons de modes visibles selon config manager~~|~~PK01 configuré Réception + Picking~~|~~Arriver sur l'écran du PK01~~|~~2 boutons visibles : "Réception" et "Picking" + bouton "Fermer le poste". Pas de bouton pour les modes non autorisés~~|||
|
||||
|14|~~Aucun mode configuré → aucun bouton de mode~~|~~PK01 sans configuration (MODES_PK01 vide)~~|~~Arriver sur l'écran du PK01~~|~~Aucun bouton de mode visible. Seul le bouton "Fermer le poste" est affiché~~|||
|
||||
|15|~~Un seul mode configuré → un seul bouton~~|~~PK01 configuré Réception uniquement~~|~~Arriver sur l'écran du PK01~~|~~1 bouton "Réception" + bouton "Fermer le poste"~~|||
|
||||
|16|~~Ouverture en mode Réception~~|~~PK01 configuré avec Réception autorisé, poste inactif~~|~~Cliquer sur "Réception"~~|~~Le PK est activé en mode Réception~~|||
|
||||
|17|~~Changement de mode à la volée~~|~~PK01 actif en mode Réception, Picking autorisé~~|~~Cliquer sur "Picking" sans fermer le poste~~|~~Le PK passe en mode Picking directement~~|||
|
||||
|18|~~Changement de mode à la volée — vérif avertissement~~|~~PK01 actif en mode Réception, poste adjacent PK02 actif~~|~~Cliquer sur "Picking"~~|~~Le message d'avertissement sur le poste adjacent s'affiche avant le changement de mode~~|||
|
||||
|
||||
---
|
||||
|
||||
### 3. Avertissement poste adjacent
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|19|Poste adjacent inactif → pas d'avertissement|PK01 et PK02 adjacents (PK_ADJACENT), PK02 inactif|Ouvrir PK01 ~~en mode Réception~~|Le PK01 s'ouvre directement, pas d'avertissement|||
|
||||
|20|Poste adjacent actif → avertissement affiché|PK01 et PK02 adjacents, PK02 déjà actif en mode Picking|Ouvrir PK01 ~~en mode Réception~~|Message : "Attention, le poste PK02 est déjà ouvert. Voulez-vous quand même ouvrir ?" avec boutons Confirmer / Annuler|||
|
||||
|21|Avertissement — confirmer|Avertissement affiché|Cliquer "Confirmer"|Le PK01 s'ouvre normalement ~~en mode Réception~~|||
|
||||
|22|Avertissement — annuler|Avertissement affiché|Cliquer "Annuler"|Le PK01 reste inactif|||
|
||||
|23|Pas de poste adjacent configuré → pas d'avertissement|PK05 n'a pas de poste adjacent dans PK_ADJACENT|Ouvrir PK05|Pas d'avertissement, ouverture directe|||
|
||||
|24|Poste adjacent fermé entre temps → pas d'avertissement|PK02 était actif, fermé juste avant l'ouverture de PK01|Ouvrir PK01|Pas d'avertissement (vérification en temps réel)|||
|
||||
|
||||
---
|
||||
|
||||
### 4. Fermeture du poste
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|25|Bouton "Fermer le poste" toujours visible|PK actif en mode Réception|Vérifier l'interface|Le bouton "Fermer le poste" est visible|||
|
||||
|26|Fermeture du poste|PK01 actif en mode Réception|Cliquer "Fermer le poste"|Le PK01 passe en mode inactif. Plus aucun mode actif|||
|
||||
|~~27~~|~~PK fermé redevient éligible pour le job~~ [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)|~~PK01 fermé, aucune tâche active le ciblant~~|~~Exécution du job~~ [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)|~~PK01 n'est pas éligible car il n'a pas de mode actif (le job vérifie que le mode actif inclut "réception")~~|||
|
||||
|28|~~Fermeture puis réouverture~~|~~PK01 fermé~~|~~Cliquer sur un bouton de mode (ex : Picking)~~|~~Le PK01 se réouvre en mode Picking normalement~~|||
|
||||
|
||||
Je n’ai pas eu le temps de faire les cas de tests pour l’usage du bouton “Tâches automatiques”. Mais c’est assez trivial
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
# Contexte
|
||||
|
||||
Il faut mettre en place un job global qui sera le chef d’orchestre des tâches de mouvement à destination des postes de travail (PK).
|
||||
Ces tâches peuvent avoir différentes origines. IL faut donc créer un JOB avec une “entête” qui analyse l’ensemble des supports concernés et qui, selon leur emplacement d’origine et d’autres caractéristiques, va choisir la destination.
|
||||
Il faut donc plusieurs sous-worklow à cey unique job selon les cas.
|
||||
L’idée de faire un seul et unique job et d'éviter d’avoir plusieurs “mini-jobs” qui se font concurrence.
|
||||
|
||||
# Développement
|
||||
|
||||
A reprendre par @Michael Chaudier , l’entête doit checker tous les PK qui sont en attente de tâche, vérifier leurs modes autorisés et la séquence de priorité de chaque mode pour rentrer dans le sous-WF nécessaire.
|
||||
|
||||
Le rôle du job est de définir quels sont les postes de picking éligibles, c’est-à-dire les postes qui n’ont rien d’assigné (réception, commande, inventaire, consolidation…)
|
||||
|
||||
Pour qu’un poste soit éligible à être assigné à une nouvelle action, il doit remplir les conditions suivantes :
|
||||
|
||||
- Aucun ordre de sortie n’est assigné au PK
|
||||
|
||||
- Aucune tâche existe en direction de ce poste
|
||||
|
||||
- Aucune palette ne se trouve sur un des sous-emplacements PK
|
||||
|
||||
- Le poste est ouvert
|
||||
|
||||
|
||||
Les postes de picking autorisent ou non la présence de big-bags, définit dans le paramètre PK_BIGBAG. Les ordres contenant des supports avec big-bags sont interdits sur les poste qui ne les autorisent pas, et prioritaires (en respectant le séquençage des process en première priorité) sur les postes qui les autorisent.
|
||||
|
||||
Si le PK rempli ces conditions, alors le WMS pourra essayer de lui envoyer des palettes. Pour chaque poste éligible, le WMS récupérera le paramètre MODES_PKX (X étant le numéro du poste) pour savoir ce qu’il a le droit de faire et la priorité de chaque process.
|
||||
|
||||
Une fois l’information récupérée, le WMS exécutera chaque sous Workflow énoncé ci-dessous en respectant l’ordre indiqué dans le paramètre. Chaque sous workflow devra retourné une information au WF principal pour lui indiquer s’il a assigné quelque chose au PK ou non. Si c’est le cas, le job passe au PK suivant, si ce n’est pas le cas alors le job passe au process suivant indiqué dans le paramètre.
|
||||
|
||||
- [https://easywmsfrance.atlassian.net/browse/LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74)
|
||||
|
||||
- [https://easywmsfrance.atlassian.net/browse/LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75)
|
||||
|
||||
|
||||
| | | | | | |
|
||||
| --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | -------------- |
|
||||
| Description | Préconditions | Actions | Résultat attendu | Validation Dév. | Validation CDP |
|
||||
| Le poste de picking est fermé | | | Le job ignore ce poste pour assigner un process | | |
|
||||
| Le poste de picking a un ordre de sortie assigné (Voir écran Menu > Contrôle > Affectation des postes de prélèvements) | | | Le job ignore ce poste pour assigner un process | | |
|
||||
| Le poste de picking est ouvert et n’a pas d’ordre de sortie assigné. Une tâche de mouvement a pour destination le PK | | | Le job ignore ce poste pour assigner un process | | |
|
||||
| Le poste de picking PK01 rempli toutes les conditions d'éligibilité, le paramètre MODES_PK01 n’existe pas | | | Le job ignore ce poste pour assigner un process | | |
|
||||
| Le poste de picking PK01 rempli toutes les conditions, le paramètre MODES_PK01 existe et est vide | | | Le job ignore ce poste pour assigner un process | | |
|
||||
| Le poste de picking PK01 rempli toutes les conditions d'éligibilité, le paramètre MODES_PK01 contient la valeur "RECEPTION;1\|PICKING;2\|CONSOLIDATION;3" | Il y a 4 palettes de réception ([https://easywmsfrance.atlassian.net/browse/LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)) sur une zone de réception sans tâche. Toutes les palettes appartiennent à la même réception | | Le subWF [https://easywmsfrance.atlassian.net/browse/LIM-75](https://easywmsfrance.atlassian.net/browse/LIM-75) génère une tâche de mouvement pour les 4 palettes et renvoie l’information indiquant que des tâches ont été générées.<br><br>Le job n’essaye pas d’assigner un autre process. | Tâches non générés car hors scope ici, mais le process est bien suivi | |
|
||||
| Le poste de picking PK01 rempli toutes les conditions d'éligibilité, le paramètre MODES_PK01 contient la valeur "RECEPTION;1\|PICKING;2\|CONSOLIDATION;3" | Il y a 2 palettes en réception et une commande en attente d’assignation d’un poste de picking | | La réception étant prioritaire le WMS génère les tâches pour les 2 palettes en réception. | Tâches non générés car hors scope ici, mais le process est bien suivi | |
|
||||
| Les 2 palettes ont été réceptionnées sur le poste de picking et envoyées vers l’ASRS. | | | Le WMS assigne l’ordre de sortie au poste PK01 | Hors scope | |
|
||||
+136
@@ -0,0 +1,136 @@
|
||||
# Contexte
|
||||
|
||||
Dans le flux de réception production, les palettes arrivent de la production (ou de l'ancien magasin) et vont **directement dans l'ASRS** sans passer par un poste de travail. Elles sont déchargées par un cariste sur une image de quai puis déclarées via le TRF en type "Production".
|
||||
|
||||
Ce job périodique crée les tâches de déplacement AGV depuis les images de quai vers le buffer d'entrée production (qui alimente le PIE de l'ASRS). Ce buffer a une route virtuelle vers une table d’entrée du convoyeur.
|
||||
|
||||
> **Note** : Ce job ne concerne **que** les réceptions de type Production (supports avec CstAtt04 = "ASN"). Les réceptions fournisseur/intersite/retour client sont gérées par [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
|
||||
|
||||
Le passage du statut "en attente" à "créé" est géré par le WMS standard (Task_GenerateMovementJob_PR). Le module AGV process et GNA qui "l'écoute" (LIM-XXX) envoie ensuite les tâches à la flotte iGo qui gère la file d'attente des AGV.
|
||||
|
||||
Résumé du process complet de réception production :
|
||||
|
||||
1. Déclaration sur l'image de quai : [https://easywmsfrance.atlassian.net/browse/LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)
|
||||
|
||||
2. **[Déplacement AGV → Entrée production] ← cette tâche**
|
||||
|
||||
3. Passage PIE (suppression support virtuel + création palette ASN) : [https://easywmsfrance.atlassian.net/browse/LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66)
|
||||
|
||||
4. Stockage ou rejet
|
||||
|
||||
5. Libération quai / image de quai
|
||||
|
||||
|
||||
**Redirection si PIE saturé** : Gérée en standard par le système de routes et distances configuré dans EasyS (route principale distance 1, routes secondaires distance 2). On ferme le PIE de prod → le WMS redirige automatiquement vers les autres entrées disponibles. Ce job envoie toujours vers la même destination ; c'est le WMS qui reroute si nécessaire.
|
||||
|
||||
A vérifier si faisable avec plusieurs poumons, plusieurs PIE et si la config EasyS actuelle est prête pour ce mode dégradé.
|
||||
|
||||
---
|
||||
|
||||
# Développement
|
||||
|
||||
### 1. Configuration du job
|
||||
|
||||
Job périodique. Fréquence : **toutes les 30 secondes.**
|
||||
|
||||
### 2. Logique principale
|
||||
|
||||
`POUR CHAQUE support fictif sur une image de quai : │ ├─ 2.1 ÉLIGIBILITÉ DU SUPPORT │ ├─ Séquence commence par 8000* (support fictif) ? │ ├─ CstAtt04 = "ASN" (support de production) ? │ ├─ CstAtt06 est vide (pas encore traité par ce job) ? │ ├─ Aucune tâche active ciblant ce support ? │ │ Statuts actifs = Bloqué, Créé, En attente, │ │ En attente d'annulation, En cours │ │ Statuts historiques (ignorés) = Annulé, Terminé │ └─ Si l'une des conditions NON → passer au support suivant │ ├─ 2.2 MARQUAGE DU SUPPORT │ └─ Setter CstAtt06 = valeur du paramètre DESTINATION_PRODUCTION │ (ex : "ENTREE_PRODUCTION") │ └─ 2.3 CRÉATION DE LA TÂCHE ├─ Origine : sous-emplacement de l'image de quai ├─ Destination : buffer d'entrée production (paramètre DESTINATION_PRODUCTION) └─ Statut initial : "en attente"`
|
||||
|
||||
### 3. Détails des étapes
|
||||
|
||||
#### 2.1 Éligibilité du support
|
||||
|
||||
Le job parcourt tous les supports positionnés sur des images de quai.
|
||||
|
||||
Un support est éligible si **toutes** les conditions suivantes sont réunies :
|
||||
|
||||
- **Séquence 800*** : Le support est un support fictif créé lors de la déclaration image de quai ([LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64))
|
||||
|
||||
- **CstAtt04 = "ASN"** : Le support est de type production
|
||||
|
||||
- **Aucune tâche active** : Le support n'est l'objet d'aucune tâche dans un statut actif
|
||||
|
||||
|
||||
La double vérification CstAtt06 + absence de tâche active est une sécurité supplémentaire pour éviter toute création de tâche en doublon.
|
||||
|
||||
#### Le WMS devra appliquer la stratégie de rangement configurée pour envoyer la palette vers la MU d’entrée à l’est ou à l’ouest (Est par défaut)
|
||||
|
||||
Le WMS gère ensuite le passage "en attente" → "créé" au fil de l'eau, et le module AGV envoie les tâches à la flotte iGo.
|
||||
|
||||
---
|
||||
|
||||
## Paramètres
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Paramètre|Description|Valeur par défaut|
|
||||
|DESTINATION_PRODUCTION|Code du buffer d'entrée production (destination des tâches AGV)|ENTREE_PRODUCTION|
|
||||
|
||||
---
|
||||
|
||||
# Cas de tests
|
||||
|
||||
### 1. Éligibilité du support
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|1|Support éligible — toutes conditions OK|Support séquence 800*, CstAtt04 = "ASN", CstAtt06 vide, aucune tâche active|Exécution du job|Une tâche est créée pour ce support|||
|
||||
|2|Support non ASN → ignoré|Support séquence 800*, CstAtt04 ≠ "ASN" (fournisseur), CstAtt06 vide|Exécution du job|Aucune tâche créée (support géré par [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70))|||
|
||||
|3|Support déjà marqué (CstAtt06 renseigné) → ignoré|Support ASN, CstAtt06 = "ENTREE_PRODUCTION"|Exécution du job|Aucune tâche créée (déjà traité)|Plus utilisé||
|
||||
|4|Support avec tâche active "En attente" → ignoré|Support ASN, CstAtt06 vide, 1 tâche en statut "En attente"|Exécution du job|Aucune tâche créée (sécurité doublon via tâche active)|||
|
||||
|5|Support avec tâche active "Créé" → ignoré|Support ASN, CstAtt06 vide, 1 tâche en statut "Créé"|Exécution du job|Aucune tâche créée|||
|
||||
|6|Support avec tâche active "En cours" → ignoré|Support ASN, CstAtt06 vide, 1 tâche en statut "En cours"|Exécution du job|Aucune tâche créée|||
|
||||
|7|Support avec tâche active "Bloqué" → ignoré|Support ASN, CstAtt06 vide, 1 tâche en statut "Bloqué"|Exécution du job|Aucune tâche créée|||
|
||||
|8|Support avec tâche active "En attente d'annulation" → ignoré|Support ASN, CstAtt06 vide, 1 tâche en statut "En attente d'annulation"|Exécution du job|Aucune tâche créée|||
|
||||
|9|Support avec tâche "Terminé" uniquement → éligible|Support ASN, CstAtt06 vide, tâches uniquement en statut "Terminé"|Exécution du job|Une tâche est créée (tâches terminées = historique)|||
|
||||
|10|Support avec tâche "Annulé" uniquement → éligible|Support ASN, CstAtt06 vide, tâches uniquement en statut "Annulé"|Exécution du job|Une tâche est créée (tâches annulées = historique)|||
|
||||
|11|Support non fictif (séquence ≠ 800*) → ignoré|Support réel sur image de quai, CstAtt04 = "ASN"|Exécution du job|Aucune tâche créée|||
|
||||
|12|Aucun support éligible|Aucun support ASN avec CstAtt06 vide sur les images de quai|Exécution du job|Le job ne fait rien, pas d'erreur|||
|
||||
|
||||
---
|
||||
|
||||
### 2. Marquage du support (CstAtt06)
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|13|CstAtt06 mis à jour avec la destination|Support éligible, paramètre DESTINATION_PRODUCTION = "ENTREE_PRODUCTION"|Exécution du job|CstAtt06 du support = "ENTREE_PRODUCTION"|Plus utilisé||
|
||||
|14|Marquage de tous les supports éligibles|5 supports ASN éligibles sur une image de quai|Exécution du job|Les 5 supports ont CstAtt06 = "ENTREE_PRODUCTION"|Plus utilisé||
|
||||
|15|Supports non ASN non impactés|3 supports ASN + 4 supports fournisseur sur la même image de quai|Exécution du job|Seuls les 3 supports ASN ont leur CstAtt06 mis à jour|Plus utilisé||
|
||||
|
||||
---
|
||||
|
||||
### 3. Création des tâches
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|16|1 tâche par support éligible|8 supports ASN éligibles|Exécution du job|8 tâches créées, ni plus ni moins|||
|
||||
|17|Statut initial = "En attente"|Support ASN éligible|Exécution du job|Tâche créée en statut "En attente"|Une d’entre elle passe “en cours” car route virtuelle||
|
||||
|18|Origine = sous-emplacement image de quai|Support sur sous-emplacement 3 de l'image de quai|Exécution du job|La tâche a pour origine le sous-emplacement 3|||
|
||||
|19|Destination = paramètre DESTINATION_PRODUCTION|Paramètre = "ENTREE_PRODUCTION"|Exécution du job|La destination de la tâche est "ENTREE_PRODUCTION"|Plus utilisé, le choix est fait via les stratégies de rangement||
|
||||
|20|Destination mise à jour si paramètre modifié|Paramètre changé de "ENTREE_PRODUCTION" à "ENTREE_PROD_2"|Exécution du job avec nouveau support|La tâche pointe vers "ENTREE_PROD_2"|Plus utilisé||
|
||||
|
||||
---
|
||||
|
||||
### 4. Double sécurité anti-doublon
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|21|CstAtt06 renseigné mais tâche annulée → pas de recréation|Support ASN, CstAtt06 = "ENTREE_PRODUCTION", tâche existante en "Annulé"|Exécution du job|Aucune tâche créée (bloqué par CstAtt06 déjà renseigné, même si la tâche est en historique)|Plus utilisé||
|
||||
|22|CstAtt06 vide mais tâche active → pas de recréation|Support ASN, CstAtt06 vide (cas anormal), 1 tâche en "En cours"|Exécution du job|Aucune tâche créée (bloqué par la tâche active, même si CstAtt06 est vide)|Plus utilisé||
|
||||
|23|Les deux conditions vides → tâche créée|Support ASN, CstAtt06 vide, aucune tâche active|Exécution du job|Une tâche est créée et CstAtt06 est renseigné|Plus utilisé||
|
||||
|
||||
---
|
||||
|
||||
### 5. Exécutions successives du job
|
||||
|
||||
| | | | | | | |
|
||||
| --- | --------------------------------------------- | --------------------------------------------------------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | --- |
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| 24 | Nouveaux supports traités au prochain cycle | 3 supports ASN traités au cycle précédent, 2 nouveaux supports ASN déclarés | Exécution du job | Seuls les 2 nouveaux supports génèrent des tâches | | |
|
||||
| 25 | Pas de doublon sur exécution consécutive | 5 supports ASN traités au cycle précédent, aucun nouveau support | Exécution du job | Aucune tâche créée, pas d'erreur | | |
|
||||
| 26 | Mix ASN et fournisseur sur même image de quai | 3 supports ASN + 4 supports fournisseur (CstAtt04 ≠ "ASN") | Exécution du job | Seuls les 3 supports ASN génèrent des tâches. Les 4 supports fournisseur sont ignorés (gérés par [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)) | | |
|
||||
@@ -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 | | |
|
||||
+324
@@ -0,0 +1,324 @@
|
||||
**Note sur les CstAtt** : deux CstAtt01 coexistent dans cette tâche mais sur des entités différentes — CstAtt01 de l'OE (hors tolérance) et CstAtt01 de la réception (réception retour entièrement rangée). Ils sont toujours qualifiés explicitement pour éviter toute confusion.
|
||||
|
||||
---
|
||||
|
||||
# Contexte
|
||||
|
||||
Une fois les palettes traitées au poste de travail ([LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72)), il faut :
|
||||
|
||||
- **Clôturer la réception** et informer l'ERP via un message **REF**
|
||||
|
||||
- **Clôturer les OE (ordres d'entrée) associés** et envoyer le message **ROF** correspondant
|
||||
|
||||
- Afficher dans la vue des OE les OE en écart pour permettre aux gestionnaires de les clôturer manuellement
|
||||
|
||||
|
||||
**Relation réception ↔ OE** : une **réception peut servir plusieurs OE**, mais **un OE est servi par une seule réception**. Si la réception associée à un OE est incomplète, l'OE ne sera pas complété par une future réception — SAP gère le reliquat via une nouvelle livraison.
|
||||
|
||||
Cette tâche concerne les flux **fournisseur/intersite** et **retour client**. La réception production (ASN) n'est pas concernée (pas de clôture manuelle).
|
||||
|
||||
Résumé du process complet :
|
||||
|
||||
1. Déclaration sur l'image de quai : [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)
|
||||
|
||||
2. Déplacement AGV → Poste de travail : [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
|
||||
|
||||
3. Traitement au poste de travail : [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72)
|
||||
|
||||
4. **Clôture de la réception** (auto si toutes les palettes sont arrivées et validées, manuelle sinon) ← _cette tâche_
|
||||
|
||||
- Pour les réceptions **retour**, l'émission du REF est différée jusqu'au rangement ASRS complet (§1.2).
|
||||
|
||||
5. **Clôture des OE associés** (auto si dans la tolérance, manuelle sinon) ← _cette tâche_
|
||||
|
||||
6. Déplacement AGV → Table d'entrée (+ filmage)
|
||||
|
||||
7. Passage PIE : [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66)
|
||||
|
||||
8. Stockage ASRS ou rejet
|
||||
|
||||
9. **Émission du REF / ROF** ← _cette tâche_
|
||||
|
||||
- Fournisseur / intersite : REF émis à la clôture de la réception (étape 4), ROF émis à la clôture de chaque OE (étape 5).
|
||||
|
||||
- Retour client : REF (et donc clôture effective de la réception) émis une fois tous les supports rangés en ASRS (après étape 8).
|
||||
|
||||
|
||||
> **Réglage** : IsSingleReceipt = true — le WMS ne gère pas de reliquats automatiques. Si réception incomplète, c'est SAP qui crée une nouvelle livraison (donc nouvel OE) si nécessaire.
|
||||
|
||||
> **Réglage** : AutoCloseReception = true — le WMS clôture automatiquement la réception quand toutes les palettes sont arrivées et validées (condition custom en §1.1). Pour les retours, l'émission du REF reste conditionnée au rangement ASRS complet (§1.2).
|
||||
|
||||
> **Réglage** : AutoCloseInboundOrder = true — à la clôture de la réception, chaque OE complété à 100% ou dans la tolérance est automatiquement clôturé (ROF envoyé) et auto-archivé (donc absent de la vue des OE). Les OE en écart (hors tolérance) restent ouverts et visibles dans la vue (§2) Ils ne doivent pas se fermer automatiquement (voir ci-dessous).
|
||||
|
||||
---
|
||||
|
||||
# Développement
|
||||
|
||||
## 1. Clôture de la réception
|
||||
|
||||
### 1.1 Déclenchement
|
||||
|
||||
**Principe** : la réception est complètement « livrée » au WMS quand toutes les palettes fictives issues de l'image de quai ont été traitées au PK (devenant des palettes réelles), et qu'aucune palette n'est plus en cours de traitement au PK.
|
||||
|
||||
**Rappel sur les deux CstAtt utilisés pour ce check** :
|
||||
|
||||
| | | | |
|
||||
|---|---|---|---|
|
||||
|CstAtt|Entité|Pose / dépose|Scope (tâche)|
|
||||
|CstAtt08|Palette fictive (issue de l'image de quai)|Set avec la valeur du code de réception à la création de la palette fictive. Supprimé avec la palette fictive quand elle est traitée au PK.|Géré en amont — posé par [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64), consommé par [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72).|
|
||||
|CstAtt10|Palette réelle au PK|Set à true pendant le process de réception sur la palette en cours de traitement. Mis à vide à l’évacuation de la palette.|Géré en amont par [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72). **Consommé ici** pour le déclenchement de l'auto-close.|
|
||||
|
||||
**Condition de déclenchement de l'auto-close** (et de visibilité du bouton « Fermer réception ») :
|
||||
|
||||
L'auto-close de la réception se déclenche — et le bouton « Fermer réception » n'est visible — que si les deux conditions suivantes sont simultanément remplies :
|
||||
|
||||
- **Aucune palette fictive** ayant CstAtt08 = <code de la réception en cours> n'est présente _(plus de palettes à venir de l'image de quai)_,
|
||||
|
||||
- **ET**
|
||||
|
||||
- **Si Workstation : une seule palette (<=1) réelle au PK** a CstAtt10 = true _(plus d’autres palettes en cours de traitement)_.
|
||||
|
||||
- **Si Vue Réception** : **aucune palette réelle au PK** n'a CstAtt10 = true _(plus de palette en cours de traitement)_.
|
||||
|
||||
|
||||
Ces deux conditions garantissent que toutes les palettes sont arrivées et entièrement validées avant que la réception puisse se clôturer.
|
||||
|
||||
Si au moins une ligne est hors tolérance, afficher un message d'avertissement à l'opérateur au moment de la fermeture : _« La réception a été clôturée mais les quantités reçues sont hors tolérance, voir avec le manager pour réguler les quantités attendues puis fermer l'ordre d'entrée »_.
|
||||
|
||||
### 1.2 Cas spécifique des retours clients — REF conditionné au rangement complet
|
||||
|
||||
**Contexte métier** : pour les retours clients, le REF influe sur la facturation SAP. Il ne doit donc être envoyé que lorsque **tous les supports de la réception sont rangés dans l'ASRS** (et ont donc passé l'ensemble des contrôles, notamment PIE).
|
||||
|
||||
Pour les autres types de réception (fournisseur / intersite), le REF est émis de façon standard à la clôture de la réception, quelle que soit la position des supports (voir §1.4 pour la gestion du champ _Zone de stockage_ dans ce cas).
|
||||
|
||||
#### 1.2.1 Pose du CstAtt11 sur les supports (WMS)
|
||||
|
||||
À chaque fin de tâche de rangement dans l'ASRS :
|
||||
|
||||
- Vérifier si le support provient d'une réception de type **retour**.
|
||||
|
||||
- Si oui → CstAtt11 du support à true.
|
||||
|
||||
- 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 (cf. §1.2.3).
|
||||
|
||||
#### 1.2.2 Affichage — statut « Clôture en cours »
|
||||
|
||||
Dans la vue des réceptions, le statut visuel d'une réception retour est piloté par CstAtt01 de la réception (posé par Reception_Close_PR_V2, cf. §1.3) :
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|CstAtt01 de la réception|État|Affichage|
|
||||
|null / vide|Retour 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é : le flag reste vide et l'affichage suit le comportement standard.
|
||||
|
||||
#### 1.2.3 Cas rare — palette déjà sortie de l'ASRS avant clôture du REF
|
||||
|
||||
_Exemple_ : réception retour de 15 palettes. Au moment où la 13e entre dans l'ASRS, la 1ère (entrée plus tôt) en est déjà ressortie (picking).
|
||||
|
||||
Le CstAtt11 du support n'est jamais remis à false après la pose initiale. Le flag persiste donc même si le support ressort de l'ASRS. Quand la 15e palette sera rangée, tous les supports de la réception auront CstAtt11 = true et la clôture se fera normalement.
|
||||
|
||||
Par ailleurs, si la palette est expédiée (fermeture de l'ordre de sortie), elle ne sera plus dans le pool évalué par Reception_Close_PR_V2 — la condition reste satisfaisable.
|
||||
|
||||
### 1.3 Adaptation de Reception_Close_PR_V2 (WMS)
|
||||
|
||||
Le workflow standard de clôture de réception est modifié pour couvrir deux comportements custom : la condition spécifique aux retours (A) et la gestion des écarts par ligne article (B). Ces deux comportements s'exécutent à la clôture de la réception et concernent l'ensemble des flux (hors précisions sur A, propres aux retours).
|
||||
|
||||
#### 1.3.1 Partie A — Condition de clôture pour les retours
|
||||
|
||||
- **Si la réception n'est pas de type retour** → comportement standard (clôture immédiate, génération de la transaction REF).
|
||||
|
||||
- **Si la réception est de type retour** :
|
||||
|
||||
- Vérifier que **tous les supports** de la réception ont CstAtt11 = true.
|
||||
|
||||
- **Oui** → set CstAtt01 de la réception = false, fermer la réception, générer la transaction REF.
|
||||
|
||||
- **Non** → ne pas fermer, set CstAtt01 de la réception = true, la réception reste dans l'état « Clôture en cours » (§1.2.2). Le WF sera rejoué à chaque event _task finished_ sur un support de la réception, jusqu'à satisfaction de la condition.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
#### 1.3.2 Partie B — Pose du CstAtt01 de l'OE pour les lignes hors tolérance
|
||||
|
||||
Rappel des notions :
|
||||
|
||||
- **Quantité reçue** (réelle, déclarée au PK)
|
||||
|
||||
- **Quantité attendue** (théorique, issue du ROR)
|
||||
|
||||
- **Tolérance** (% de dépassement autorisé, par ligne, issue du ROR. Si non indiquée dans le ROR, indiquée via le profil de réception de l'article)
|
||||
|
||||
|
||||
Dans le standard la tolérance n'est utilisée que pour l'excès ; dans notre cas elle sera aussi utilisée pour vérifier une quantité reçue inférieure à celle attendue.
|
||||
|
||||
**Algorithme** — à la clôture effective de la réception (après validation de la condition A si applicable), pour chaque **ligne article hors tolérance** (en plus ou en moins) :
|
||||
|
||||
1. Chercher le **premier OE** (FirstOrDefault) parmi les OE associés à la réception qui contient ce combo code article/lot.
|
||||
|
||||
- Le client a validé qu'en pratique un combo code article/lot n'est jamais partagé entre plusieurs OE d'une même réception — le FirstOrDefault est donc déterministe dans les faits.
|
||||
|
||||
2. Poser CstAtt01 = true sur cet OE.
|
||||
|
||||
|
||||
Les OE ainsi flaggés ne se clôturent pas automatiquement (leur ROF est bloqué, **il faut modifier le WF de clôture des OE pour ce cas**) et s'affichent en rouge (§2). Les OE en écart **dans la tolérance** ne sont pas flaggés.
|
||||
|
||||
**REF** : le REF est envoyé normalement avec les quantités réelles reçues (ce qui inclut les excès sur les lignes déjà attendues). Le cas d'un code article totalement inattendu (ligne supplémentaire dans le REF) n'est autorisé que pour les retours et est géré par le standard — hors scope de cette tâche.
|
||||
|
||||
> **Note** : l'autorisation de la réception physique d'une marchandise en excès par rapport à la tolérance est traitée côté PK — cf. [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72).
|
||||
|
||||
### 1.4 Contenu du REF (custom)
|
||||
|
||||
Il faut mettre en place les customisations suivantes :
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément custom à rajouter (nom balise à ta guise)|Détail|
|
||||
|Zone de stockage|Info récupérée depuis le code emplacement du support|
|
||||
|
||||
Un seul REF est envoyé par réception (pas de REF progressif, car IsSingleReceipt = true).
|
||||
|
||||
**Valeur de la zone de stockage** :
|
||||
|
||||
- Réceptions **fournisseur / intersite** : si un support se trouve hors de l'ASRS au moment de l'envoi du REF, on envoie "NON RANGEE".
|
||||
|
||||
- Réceptions **retour client** : ce cas ne peut pas se produire puisque le REF n'est émis qu'une fois tous les supports rangés (cf. §1.2). La valeur sera toujours une zone réelle (même si hors ASRS).
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2. Clôture des ordres d'entrée (OE)
|
||||
|
||||
### 2.1 Principe général
|
||||
|
||||
À la clôture de la réception, le WMS impute les quantités reçues sur les OE associés (un OE étant servi par une seule réception). Le flag CstAtt01 de l'OE a déjà été posé par Reception_Close_PR_V2 pour les OE concernés par une ligne hors tolérance (cf. §1.3.2). Le comportement dépend ensuite du résultat pour chaque OE :
|
||||
|
||||
| | | | |
|
||||
|---|---|---|---|
|
||||
|Situation de l'OE|Clôture OE|ROF|Affichage dans la vue des OE|
|
||||
|Reçu = attendu (pas d'écart)|Auto-close (AutoCloseInboundOrder = true)|Envoi (auto)|Auto-archivé → **absent de la vue**|
|
||||
|Écart dans la tolérance (incomplet ou excès léger)|**Custom :** auto-close|Envoi (auto)|Auto-archivé → **absent de la vue**|
|
||||
|Écart hors tolérance (CstAtt01 de l'OE = true)|Manuelle par un profil non-opérateur|Envoyé manuellement|**Rouge** — bouton « Clôturer l'OE » visible uniquement aux non-opérateurs|
|
||||
|
||||
> **Règle d'affichage résumée** : un OE présent dans la vue est forcément « non terminé » — soit sa réception n'est pas encore arrivée / en cours, soit sa réception est terminée avec écart. On distingue les trois cas à l'œil par la couleur.
|
||||
|
||||
### 2.2 Diagramme décisionnel
|
||||
|
||||
`Clôture de la réception │ ▼ Pour chaque OE associé : écart détecté ? │ ┌────┴─────────┐ ▼ ▼ NON OUI │ │ │ │ ▼ │ Écart dans la tolérance ? │ │ │ ┌─────┴─────┐ │ ▼ ▼ │ OUI NON (hors tolérance) │ │ │ │ │ ▼ │ │ CstAtt01 de l'OE = true │ │ (posé par Reception_Close_PR_V2, §1.3.2) │ │ REF envoyé (avec quantités réelles) │ │ ROF BLOQUÉ │ │ OE affiché en ROUGE │ │ Bouton "Clôturer l'OE" visible │ │ uniquement aux non-opérateurs │ │ (admin, manager, chef d'équipe) │ │ │ │ │ ▼ │ │ Manager régularise dans SAP │ │ (envoi éventuel d'un nouveau ROR) │ │ puis clôture manuellement l'OE │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ Clôture Auto ROF envoyé à SAP ROF envoyé auto-archivé`
|
||||
|
||||
|
||||
### 2.3 Visibilité et accessibilité du bouton « Clôturer l'OE »
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|État OE|Affichage OE|Bouton « Clôturer l'OE »|
|
||||
|Sans écart (auto-clôturé)|Standard - Auto-archivé, absent de la vue|**Standard** : accessible à tous les profils (opérateurs inclus)|
|
||||
|Écart dans la tolérance|Standard - Auto-archivé, absent de la vue|**Standard** : accessible à tous les profils (opérateurs inclus)|
|
||||
|Écart hors tolérance (CstAtt01 de l'OE = true)|Rouge|**Visible uniquement pour les profils non-opérateurs** (admin, manager, chef d'équipe). Masqué pour les opérateurs standards.|
|
||||
|
||||
---
|
||||
|
||||
## 3. LOC — Impact sur le message de localisation (développement hors scope)
|
||||
|
||||
> **Note** : Le développement du LOC custom est une tâche dédiée : [LIM-76](https://easywmsfrance.atlassian.net/browse/LIM-76). Cette section décrit le besoin pour information et cohérence.
|
||||
|
||||
Le LOC est un message envoyé à SAP **toutes les 5 minutes** sur delta (palettes créées/déplacées/supprimées). Il contient les quantités et la localisation de chaque support.
|
||||
|
||||
**Custom nécessaire (tâche dédiée)** : le LOC ne doit pas prendre en compte les palettes liées à une réception non fermée. Cela est standard dans la génération du WSC (qu'on va forker pour faire le LOC).
|
||||
|
||||
Cela garantit que le WMS ne communique à SAP que les supports qu'il connaît déjà (via un REF préalable). Ainsi :
|
||||
|
||||
- Si un article est géré en KG et qu'un écart de poids est constaté au PIE ([LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66)), la quantité réelle est mise à jour dans le stock WMS.
|
||||
|
||||
- Le LOC suivant (après l'envoi du REF) transmettra naturellement la bonne quantité à SAP, sans besoin de STV spécifique.
|
||||
|
||||
- SAP constatera l'écart en comparant les quantités du LOC avec celles du REF.
|
||||
|
||||
|
||||
> **Note** : les notifications d'écart de poids au PIE et de rejet sont déjà gérées par [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66). La présente tâche (LIM-73) ne génère plus de notifications.
|
||||
|
||||
---
|
||||
|
||||
## 4. Récapitulatif des CstAtt utilisés par cette tâche
|
||||
|
||||
À reporter / mettre à jour dans [LIM-14](https://easywmsfrance.atlassian.net/browse/LIM-14) (Custom Attributes, Séquences, Jobs et Paramètres WMS).
|
||||
|
||||
| | | | | |
|
||||
|---|---|---|---|---|
|
||||
|CstAtt|Entité|Type|Portée|Rôle|
|
||||
|CstAtt08|Palette fictive|String|Posé par [LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64), consommé ici|Code de la réception liée à la palette fictive — utilisé pour détecter l'absence de palettes fictives restantes avant auto-close (§1.1)|
|
||||
|CstAtt10|Palette réelle au PK|Booléen|Posé/déposé par [LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67) / [LIM-72](https://easywmsfrance.atlassian.net/browse/LIM-72), consommé ici|true pendant le traitement d'une palette au PK — utilisé pour détecter qu'aucune palette n'est en cours avant auto-close (§1.1)|
|
||||
|CstAtt11|Support (palette réelle)|Booléen|**Introduit par cette tâche**|true quand le support issu d'une réception retour a fini son rangement en ASRS — utilisé par Reception_Close_PR_V2 pour conditionner la clôture de la réception et l'émission du REF (§1.2, §1.3.1)|
|
||||
|CstAtt01|Réception (type retour uniquement)|Booléen|**Introduit par cette tâche**|Réception retour entièrement rangée en ASRS — posé à true par Reception_Close_PR_V2 au moment de la tentative de clôture non effective. Pilote l'affichage « Clôture en cours » tant qu'il est à true (§1.2.2, §1.3.1)|
|
||||
|CstAtt01|OE (ordre d'entrée)|Booléen|**Introduit par cette tâche**|OE en écart hors tolérance — posé par Reception_Close_PR_V2 à la clôture de la réception (§1.3.2). Bloque la clôture auto de l'OE et pilote l'affichage rouge + la visibilité restreinte du bouton « Clôturer l'OE » (§2)|
|
||||
|
||||
---
|
||||
|
||||
# Cas de tests
|
||||
|
||||
# Cas de tests — LIM-73
|
||||
|
||||
_À compléter au fil des tests. Colonnes Dév / CDP laissées vides pour mise en couleur après exécution._
|
||||
|
||||
---
|
||||
|
||||
## 1. Clôture de la réception — Déclenchement (fournisseur / intersite)
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|1|Auto-close — toutes les palettes arrivées et validées (vue Réception)|Réception fournisseur. Plus aucune palette fictive avec CstAtt08 = <code>. Aucune palette au PK avec CstAtt10 = true|Déclenchement auto-close depuis la vue Réception|Réception clôturée, REF envoyé immédiatement|||
|
||||
|2|Auto-close depuis Workstation — dernière palette en cours de validation|Réception fournisseur. Plus aucune palette fictive avec CstAtt08 = <code>. Exactement 1 palette au PK avec CstAtt10 = true (la dernière en cours)|Déclenchement auto-close depuis la Workstation|Réception clôturée, REF envoyé (condition Workstation : CstAtt10 ≤ 1)|||
|
||||
|3|Pas d'auto-close depuis vue Réception — palette encore en cours au PK|Réception fournisseur. 1 palette au PK avec CstAtt10 = true|Tentative d'auto-close depuis la vue Réception|Auto-close non déclenché. Bouton « Fermer réception » masqué|||
|
||||
|4|Pas d'auto-close — palettes fictives restantes (les deux points d'entrée)|Réception fournisseur. 2 palettes fictives avec CstAtt08 = <code> encore présentes|Tentative d'auto-close (vue Réception et Workstation)|Auto-close non déclenché dans les deux cas. Bouton « Fermer réception » masqué|||
|
||||
|5|Pas d'auto-close depuis Workstation — plus d'une palette en cours|Réception fournisseur. 2 palettes au PK avec CstAtt10 = true|Tentative d'auto-close depuis la Workstation|Auto-close non déclenché. Bouton masqué (condition Workstation : CstAtt10 ≤ 1 non respectée)|||
|
||||
|6|Avertissement opérateur à la fermeture si ligne hors tolérance|Réception prête à clôturer, 1 ligne article hors tolérance|Clôture de la réception|Message d'avertissement affiché à l'opérateur : « La réception a été clôturée mais les quantités reçues sont hors tolérance, voir avec le manager pour réguler les quantités attendues puis fermer l'ordre d'entrée »|||
|
||||
|
||||
## 2. Clôture de la réception — Contenu du REF
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|7|Zone de stockage présente pour chaque support|Réception fournisseur, 3 palettes stockées en TK1, TK2, TK3|Clôture et envoi du REF|Le REF contient pour chaque support sa zone de stockage (récupérée depuis le code emplacement)|||
|
||||
|8|Zone de stockage = "NON RANGEE" pour palettes hors ASRS (non-retour)|Réception fournisseur, 3/5 palettes rangées en ASRS, 2 encore en transit au moment de la clôture|Auto-close et envoi du REF|REF envoyé immédiatement. Pour les 2 palettes non rangées : zone de stockage = "NON RANGEE"|||
|
||||
|9|REF unique par réception (pas de REF progressif)|Réception avec plusieurs palettes rangées à des moments différents|Clôture de la réception|Un seul REF émis, contenant l'ensemble des supports|||
|
||||
|
||||
## 3. Clôture de la réception — Cas retour client (REF conditionné au rangement)
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|10|Retour, tous supports rangés ASRS|Réception retour, CstAtt11 = true sur tous les supports, conditions §1.1 OK|Auto-close|Réception fermée, REF envoyé. CstAtt01 de la réception set à false à la clôture effective (quel que soit le chemin)|||
|
||||
|11|Retour, supports pas tous rangés — passage en « Clôture en cours »|Réception retour, conditions §1.1 OK, mais 3/5 supports seulement rangés en ASRS|Tentative de clôture (auto ou manuelle)|Réception non fermée. CstAtt01 de la réception = true. Statut affiché « Clôture en cours », ligne en jaune. Pas de REF|||
|
||||
|12|Affichage standard avant tentative de clôture|Réception retour en cours de traitement, aucune tentative de clôture encore déclenchée|Ouvrir la vue des réceptions|CstAtt01 de la réception vide. Affichage standard (pas de jaune)|||
|
||||
|13|Déblocage auto dès que le dernier support est rangé|Suite du test 11. Dernier support entre en ASRS → CstAtt11 = true|Event _task finished_|Reception_Close_PR_V2 rejoué, condition satisfaite. Réception fermée, REF envoyé. CstAtt01 de la réception remis à false (plus de jaune dans la vue)|||
|
||||
|14|Cas rare — palette sortie avant clôture du REF|Retour 15 palettes, la 1ère déjà ressortie (picking) quand la 15e est rangée|Dernière palette rangée|CstAtt11 resté à true sur la palette sortie. Condition §1.3.1 satisfaite. Clôture et REF OK|||
|
||||
|15|Palette refusée au PIE non supprimée — clôture impossible|Retour 5 palettes, 4 rangées en ASRS (CstAtt11 = true), 1 refusée au PIE mais non retirée du WMS|Tentative de clôture|Clôture ne se fait jamais tant que la palette refusée est présente. Réception reste « Clôture en cours »|||
|
||||
|16|Palette refusée au PIE supprimée — clôture débloquée|Suite du test 15, le client supprime la palette refusée du WMS|Event _task finished_ ou rejeu du WF|Tous les supports restants ont CstAtt11 = true. Clôture et REF OK|||
|
||||
|
||||
## 4. Clôture des OE — Sans écart et écart dans la tolérance
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|17|Auto-close OE — réception parfaite|Réception avec plusieurs OE, toutes quantités reçues = attendues|Clôture de la réception|Tous les OE auto-clôturés (AutoCloseInboundOrder), ROF envoyé pour chacun, OE auto-archivés (absents de la vue)|||
|
||||
|18|Auto-close OE — écart dans la tolérance (en moins)|OE avec article A : attendu 100, reçu 95, tolérance 10%|Clôture de la réception|CstAtt01 de l'OE reste vide. OE auto-clôturé (custom : auto-close dans la tolérance). ROF envoyé. OE auto-archivé|||
|
||||
|19|Auto-close OE — écart dans la tolérance (en plus)|OE avec article A : attendu 100, reçu 108, tolérance 10%|Clôture de la réception|CstAtt01 de l'OE reste vide. OE auto-clôturé. ROF envoyé avec quantité réelle (108). OE auto-archivé|||
|
||||
|20|Plusieurs OE sur une même réception — comportement mixte|Réception avec 3 OE : OE1 parfait, OE2 dans la tolérance, OE3 hors tolérance|Clôture de la réception|OE1 et OE2 auto-clôturés et archivés. OE3 : CstAtt01 = true, reste visible en rouge (cf. §5)|||
|
||||
|
||||
## 5. Clôture des OE — Écart hors tolérance (rouge)
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|21|OE hors tolérance — CstAtt01 de l'OE = true, affichage rouge|OE avec article A : attendu 100, reçu 150, tolérance 10%|Clôture réception|CstAtt01 de l'OE = true (posé par Reception_Close_PR_V2). REF envoyé avec quantité réelle (150). ROF bloqué (WF de clôture OE modifié). OE affiché en rouge dans la vue|||
|
||||
|22|OE hors tolérance — WF clôture OE bloque bien l'auto-close|OE avec CstAtt01 de l'OE = true suite à une réception clôturée|Passage du job d'auto-close OE|L'OE n'est pas auto-clôturé. Reste ouvert et visible|||
|
||||
|23|Sélection de l'OE à flagger via combo article/lot _(cas théorique)_|Réception avec 2 OE contenant un même combo article A + lot L1 (cas non prévu en production)|Clôture réception, ligne (article A, lot L1) hors tolérance|CstAtt01 de l'OE = true posé sur le **premier OE** trouvé (FirstOrDefault) ayant ce combo|||
|
||||
|24|Recherche par combo article/lot — distinction sur le lot|Réception avec 2 OE : OE1 contient (article A, lot L1), OE2 contient (article A, lot L2). Seul le lot L1 est hors tolérance|Clôture réception|CstAtt01 de l'OE = true posé sur OE1 uniquement. OE2 non impacté|||
|
||||
|25|Bouton « Clôturer l'OE » visible pour non-opérateur|CstAtt01 de l'OE = true, user = chef d'équipe / manager / admin|Ouverture vue des OE|Bouton « Clôturer l'OE » visible|||
|
||||
|26|Bouton « Clôturer l'OE » masqué pour opérateur standard|CstAtt01 de l'OE = true, user = opérateur standard|Ouverture vue des OE|Bouton « Clôturer l'OE » masqué|||
|
||||
|27|Manager clôture manuellement OE hors tolérance|CstAtt01 de l'OE = true, manager connecté. Régularisation SAP effectuée en amont|Clic sur « Clôturer l'OE »|OE clôturé, ROF envoyé|||
|
||||
+154
@@ -0,0 +1,154 @@
|
||||
Ce job fait partie d’un job principal décrit ici : [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
|
||||
|
||||
# Contexte
|
||||
|
||||
Dans le flux de réception fournisseur/intersite/retour client, les palettes sont déchargées par un cariste sur une image de quai puis déclarées via le TRF. Elles doivent ensuite être acheminées par AGV vers un poste de travail (PK) pour y être traitées.
|
||||
|
||||
Ce job périodique est le mécanisme central qui orchestre l'envoi des palettes depuis les images de quai vers les postes de travail. Il est responsable de :
|
||||
|
||||
- Identifier les PK disponibles dont le mode actif est "réception"
|
||||
|
||||
- Trouver les réceptions en attente de traitement (supports fictifs sur image de quai, non encore assignés à un PK)
|
||||
|
||||
- Assigner une réception complète à un PK
|
||||
|
||||
- Créer les tâches de déplacement (statut "en attente") pour chaque support
|
||||
|
||||
|
||||
Le passage du statut "en attente" à "généré" est géré par le WMS standard (Task_GenerateMovementJob_PR). Le module AGV process et GNA qui "l'écoute" (LIM-XXX) envoie ensuite les tâches à la flotte iGo qui gère la file d'attente des AGV.
|
||||
|
||||
> **Note** : Ce job ne concerne **pas** les réceptions de type Production. Celles-ci sont envoyées directement vers le PIE de l'ASRS via des supports virtuels, sans passer par un poste de travail.
|
||||
|
||||
Résumé du process complet de réception fournisseur/intersite/retour :
|
||||
|
||||
1. Déclaration sur l'image de quai : [https://easywmsfrance.atlassian.net/browse/LIM-64](https://easywmsfrance.atlassian.net/browse/LIM-64)
|
||||
|
||||
2. **[Déplacement AGV → Poste de travail] ← cette tâche**
|
||||
|
||||
3. Traitement au poste de travail : [https://easywmsfrance.atlassian.net/browse/LIM-67](https://easywmsfrance.atlassian.net/browse/LIM-67)
|
||||
|
||||
4. Déplacement AGV → Table d'entrée (+ filmage si demandé)
|
||||
|
||||
5. Passage PIE : [https://easywmsfrance.atlassian.net/browse/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
|
||||
|
||||
La partie 2.1 ELIGIBILITÉ DU PK est à faire à l’entête du JOB, donc dans : [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
|
||||
|
||||
### 1. Logique principale
|
||||
|
||||
Pas besoin de vérification du CstAtt04, les conteneurs virtuels de production n’ont pas de réception associée
|
||||
|
||||
`POUR CHAQUE PK (poste de travail) ├─ 1.1 RECHERCHE D'UNE RÉCEPTION À ASSIGNER │ ├─ Filtrer les réceptions ayant des supports fictifs (séquence 8000*) │ │ sur une image de quai dont le CstAtt06 est vide (pas de PK assigné) │ │ et CstAtt04 ≠ "ASN" (exclusion production) │ ├─ Filtre big-bag : si CstAtt01 du support = true (big-bag potentiel) │ │ → le PK doit figurer dans le paramètre PK_BIGBAG │ ├─ Trier par date de création de la réception (FIFO) │ └─ Prendre la PREMIÈRE réception éligible │ ├─ 1.2 ASSIGNATION DU PK │ └─ Setter CstAtt06 = code du PK sur TOUS les supports de cette réception │ └─ 1.3 CRÉATION DES TÂCHES ├─ Pour CHAQUE support fictif de la réception : │ créer 1 tâche : sous-emplacement image de quai → PK (station) ├─ Statut initial : "en attente" └─ Toutes les palettes d'une réception → même PK, en une seule passe`
|
||||
|
||||
### 3. Détails des étapes
|
||||
|
||||
#### 1.1 Recherche d'une réception
|
||||
|
||||
Le job cherche parmi toutes les réceptions non-production celles qui ont des supports fictifs (identifiés par leur séquence commençant par 8000) positionnés sur une image de quai, dont le **CstAtt06 est vide** (pas encore assignés à un PK) ~~et dont le~~ **~~CstAtt04 ne vaut pas "ASN"~~**~~.~~
|
||||
|
||||
**Filtre big-bag** : Si les supports de la réception ont le CstAtt01 = true (présence de big-bag déclarée lors de la déclaration image de quai), alors le PK doit figurer dans la liste du paramètre PK_BIGBAG. Si aucun PK compatible big-bag n'est libre, la réception attend.
|
||||
|
||||
**Ordre de priorité** : Ordres contenant des big-bags si le poste l’autorise puis FIFO sur la date de création de la réception. La réception la plus ancienne est servie en premier.
|
||||
|
||||
#### 2.3 Assignation du PK
|
||||
|
||||
Une fois la réception trouvée, le **CstAtt06** de **tous les supports fictifs** de cette réception est mis à jour avec le code du PK assigné. Ce CstAtt sert également à identifier le poste d'origine en cas de notification de rejet au PIE.
|
||||
|
||||
#### 2.4 Création des tâches
|
||||
|
||||
Pour chaque support fictif de la réception sur l'image de quai, une tâche de déplacement est créée :
|
||||
|
||||
- **Origine** : sous-emplacement de l'image de quai où se trouve le support
|
||||
|
||||
- **Destination** : PK (station). Le WMS choisira automatiquement le sous-emplacement (TP) de destination au moment de la génération du mouvement : [https://easywmsfrance.atlassian.net/browse/LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60).
|
||||
|
||||
- **Statut** : "en attente"
|
||||
|
||||
|
||||
Toutes les palettes d'une même réception sont créées vers le **même PK** en une seule passe du job. Le WMS gère ensuite le passage "en attente" → "généré" à la volée selon la capacité en temps réel du PK, et le module AGV les envoie à la flotte iGo.
|
||||
|
||||
Le paramètre PK_BIGBAG renseigne les postes de picking autorisant les big bags.
|
||||
|
||||
Les supports ayant le CstAtt1 à 1 ne pourront aller que vers postes qui seront renseignés dans ce paramètres.
|
||||
|
||||
Les supports ayant le CstAtt1 à 1 seront également prioritaires sur ces postes là.
|
||||
|
||||
---
|
||||
|
||||
## Paramètres
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Paramètre|Description|Valeur par défaut|
|
||||
|PK_BIGBAG|Liste des PK compatibles big-bag (séparés par ;)|_(vide)_|
|
||||
|
||||
---
|
||||
|
||||
# Cas de tests
|
||||
|
||||
### 2. Recherche et sélection de la réception
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|13|Réception FIFO — la plus ancienne est prise|2 réceptions en attente (R1 créée à 10h, R2 créée à 11h), 1 PK libre|Exécution du job|R1 est assignée au PK (date de création la plus ancienne)|||
|
||||
|14|Réception déjà assignée ignorée|R1 avec CstAtt06 renseigné (PK déjà assigné), R2 avec CstAtt06 vide|Exécution du job|R1 est ignorée, R2 est assignée|||
|
||||
|15|~~Réception production ignorée (CstAtt04 = ASN)~~|~~R1 avec supports ayant CstAtt04 = "ASN" (production), R2 fournisseur avec supports fictifs (CstAtt04 ≠ "ASN")~~|~~Exécution du job~~|~~R1 est ignorée grâce au filtre CstAtt04, R2 est assignée~~|Pas de réception crée pour la production||
|
||||
|16|Aucune réception en attente|Aucun support fictif avec CstAtt06 vide sur une image de quai|Exécution du job|Le job ne fait rien, pas d'erreur|||
|
||||
|
||||
---
|
||||
|
||||
### 3. Filtre big-bag
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|17|Réception big-bag vers PK compatible|Réception avec CstAtt01=true, PK01 dans PK_BIGBAG, PK01 libre|Exécution du job|La réception est assignée à PK01|||
|
||||
|18|Réception big-bag, PK compatible occupé, PK non compatible libre|Réception avec CstAtt01=true, PK01 (compatible) occupé, PK02 (non compatible) libre|Exécution du job|La réception n'est PAS assignée à PK02. Elle attend que PK01 se libère|||
|
||||
|19|Réception big-bag, aucun PK compatible configuré|Réception avec CstAtt01=true, paramètre PK_BIGBAG vide|Exécution du job|La réception n'est assignée à aucun PK. Elle reste en attente|||
|
||||
|20|Réception sans big-bag vers PK quelconque|Réception avec CstAtt01=false, PK02 (non compatible big-bag) libre|Exécution du job|La réception est assignée à PK02 normalement|||
|
||||
|21|Réception sans big-bag, seul PK compatible big-bag est libre|Réception avec CstAtt01=false, PK01 (compatible big-bag) libre, PK02 occupé|Exécution du job|La réception est assignée à PK01 (un PK big-bag peut aussi traiter des réceptions normales)|||
|
||||
|
||||
---
|
||||
|
||||
### 4. Assignation du PK (CstAtt06)
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|22|CstAtt06 renseigné sur tous les supports|Réception avec 5 supports fictifs, PK03 libre|Exécution du job|Les 5 supports ont CstAtt06 = "POSTE03" en base|||
|
||||
|23|Supports d'autres réceptions non impactés|R1 (3 supports) et R2 (4 supports) sur la même image de quai, 1 PK libre|Exécution du job|Seuls les 3 supports de R1 ont leur CstAtt06 mis à jour. Les 4 supports de R2 gardent CstAtt06 vide|||
|
||||
|
||||
---
|
||||
|
||||
### 5. Création des tâches
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|ID|Description|Préconditions|Actions|Résultat attendu|Dév|CDP|
|
||||
|24|Nombre de tâches = nombre de supports|Réception avec 8 supports fictifs sur image de quai, PK libre|Exécution du job|8 tâches créées, ni plus ni moins|||
|
||||
|25|Statut initial des tâches = "En attente"|Réception assignée à un PK|Exécution du job|Toutes les tâches créées sont en statut "En attente"|||
|
||||
|26|Origine = sous-emplacement image de quai|Support fictif sur sous-emplacement 5 de l'image de quai|Exécution du job|La tâche a pour origine le sous-emplacement 5 de l'image de quai|||
|
||||
|27|Destination = PK (station)|PK03 assigné|Exécution du job|La destination de la tâche est PK03 (station). Le sous-emplacement (TP) n'est pas précisé — géré par le WMS au moment de la génération du mouvement [https://easywmsfrance.atlassian.net/browse/LIM-60](https://easywmsfrance.atlassian.net/browse/LIM-60)|||
|
||||
|28|Toutes les tâches vont vers le même PK|Réception avec 6 supports, PK02 assigné|Exécution du job|Les 6 tâches ont toutes PK02 comme destination|||
|
||||
|29|Tâches créées même si le PK n'a que 3 TP|Réception avec 10 supports, PK avec 3 TP|Exécution du job|10 tâches créées en "En attente". Le WMS passera progressivement les tâches en "Créé" selon la capacité disponible du PK en temps réel|||
|
||||
|
||||
---
|
||||
|
||||
### 6. Exécutions successives du job
|
||||
|
||||
| | | | | | | |
|
||||
| --- | -------------------------------- | ------------------------------------------- | ---------------- | -------------------------------------------------- | --- | --- |
|
||||
| ID | Description | Préconditions | Actions | Résultat attendu | Dév | CDP |
|
||||
| 30 | Même réception pas re-traitée | R1 déjà assignée (CstAtt06 renseigné) | Exécution du job | R1 est ignorée, pas de doublon de tâches | | |
|
||||
| 31 | Job sans effet si rien à traiter | Aucune réception en attente, aucun PK libre | Exécution du job | Job s'exécute sans erreur, aucune action effectuée | | |
|
||||
+3
@@ -0,0 +1,3 @@
|
||||
Ce job fait partie d’un job principal décrit ici : [https://easywmsfrance.atlassian.net/browse/LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70)
|
||||
|
||||
Tâche à écrire
|
||||
@@ -0,0 +1,769 @@
|
||||
## Résumé
|
||||
|
||||
Message custom **LOC** envoyé toutes les 5 minutes de EasyWMS vers SAP, contenant le delta des mouvements de HU (supports) sur la période. Ce message remplace les messages custom PCK et MOVE de l'AF (supprimés) et devient le **seul canal** de notification des mouvements de stock vers SAP (les STV et STC seront désactivés).
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
Limagrain (SAP) ne souhaite pas recevoir les STV standards (en delta +/-) car jugés non fiables en cas de perte de message. Le LOC transmet des **quantités absolues** que SAP prend pour argent comptant et compare à ses propres données.
|
||||
|
||||
Le LOC est un **fork fonctionnel du WSC** (image de stock complète) adapté pour ne remonter que le delta des 5 dernières minutes, et formaté selon un JSON spécifique attendu par SAP.
|
||||
|
||||
---
|
||||
|
||||
## Architecture technique
|
||||
|
||||
### Chaîne de traitement
|
||||
|
||||
Job (toutes les 5 min) → Workflow → Transaction custom (ex. LOC.SEND) → GNA → Requêtes WMS + Formatage JSON → POST API SAP
|
||||
|
||||
### Côté WMS
|
||||
|
||||
1. **Créer un Job** déclenché toutes les 5 minutes.
|
||||
|
||||
2. Ce job appelle un **Workflow custom** dont le seul rôle est de **créer une transaction custom** (ex. LOC.SEND).
|
||||
|
||||
3. Le Workflow et la transaction ne portent aucune logique métier côté WMS — toute la logique est dans le GNA.
|
||||
|
||||
|
||||
### Côté GNA
|
||||
|
||||
1. **Créer un nouveau script BOO** pour le message LOC.
|
||||
|
||||
2. Le GNA détecte la transaction custom LOC.SEND.
|
||||
|
||||
3. À réception de cette transaction, le script BOO :
|
||||
|
||||
- Collecte toutes les transactions WMS pertinentes sur le delta de temps (cf. §Transactions sources)
|
||||
|
||||
- Agrège les données par HU et détermine le code ACTION pour chaque mouvement
|
||||
|
||||
- Construit le JSON au format attendu par SAP (cf. §Format JSON)
|
||||
|
||||
- Effectue un **appel POST** vers l'API SAP (endpoint unique déjà en place sur git/develop)
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Paramètres d'import
|
||||
|
||||
| | | | |
|
||||
|---|---|---|---|
|
||||
|Réf.|Champ|Type|Description|
|
||||
|1|IV_LGNUM|CHAR 4|Numéro d'entrepôt (valeur fixe : "WF02") provenant de la config EasyS|
|
||||
|2|IV_TREATMENT_ID|CHAR 24|Horodatage de génération du LOC|
|
||||
|
||||
---
|
||||
|
||||
## Table IT_CREATE (1:n) — Champs
|
||||
|
||||
| | | | |
|
||||
|---|---|---|---|
|
||||
|Réf.|Champ|Type|Description|
|
||||
|1|MATNR|CHAR 40|Code produit SAP — vide si action B|
|
||||
|2|BATCHID|CHAR 10|Code lot SAP — vide si action B|
|
||||
|3|ACTION|CHAR 1|Code action : B, U, R, S, T, C, P|
|
||||
|4|ANFME|NUM 13.3|Quantité (absolue ou transférée selon action) — vide si action B ou U/R|
|
||||
|5|ALTME|CHAR 3|Unité de mesure (Ex : BAG, KG) — vide si action B|
|
||||
|6|VLPLA|CHAR 18|Zone de stockage origine|
|
||||
|7|NLPLA|CHAR 18|Zone de stockage destination|
|
||||
|8|VLENR|CHAR 20|Code HU (palette) source (SSCC)|
|
||||
|9|NLENR|CHAR 20|Code HU (palette) destination (SSCC)|
|
||||
|10|REASON|CHAR 4|Code raison scrap — uniquement pour action S (ZSC1 = scrapping normal)|
|
||||
|11|VBELN|—|Code livraison sortante SAP — uniquement pour action P|
|
||||
|12|POSNR|—|Ligne de livraison sortante SAP — uniquement pour action P|
|
||||
|
||||
---
|
||||
|
||||
## Codes ACTION
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Code|Signification|Déclencheur|
|
||||
|**B**|Déplacement bin-to-bin|Déplacement de HU d'une zone à une autre|
|
||||
|**U**|Set to Unrestricted (déblocage)|Déblocage statut B6|
|
||||
|**R**|Set to Restricted (blocage)|Blocage statut B6|
|
||||
|**S**|Scrap quantity (suppression)|Suppression de stock / support|
|
||||
|**T**|Transfert inter-HU|Transfert de quantité entre deux HU|
|
||||
|**C**|Correction de poids|Ajustement de quantité (valeur absolue)|
|
||||
|**P**|Assignation client|Palette positionnée sur image de quai|
|
||||
|
||||
---
|
||||
|
||||
## Transactions WMS sources
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Transaction WMS|Action LOC|Données à récupérer|
|
||||
|CON.MOVE|**B** (déplacement)|ContainerCode, zone de stockage origine, zone de stockage destination|
|
||||
|CON.LOCATE|**B** (déplacement)|Idem|
|
||||
|STK.MOVE|**B** ou **T**|ContainerCode source et destination. Si ContainerTo ≠ ContainerCode → ACTION=T avec quantité transférée|
|
||||
|STK.ADJ|**C** (correction)|ContainerCode, quantité absolue actuelle sur la HU après ajustement, UdM|
|
||||
|CST.STK|**U** ou **R**|ContainerCode, nouveau statut (B6 uniquement hors retour)|
|
||||
|STK.PICKING|**T** (transfert)|Container source, container destination (palette fille), quantité transférée|
|
||||
|CON.DELETE|**S** (suppression)|ContainerCode, quantité supprimée|
|
||||
|
||||
Vérifier si d'autres transactions sont utiles pour le LOC.
|
||||
|
||||
### Données stock/container à récupérer pour chaque ligne LOC
|
||||
|
||||
Pour chaque HU identifiée dans les transactions du delta, récupérer :
|
||||
|
||||
- **Code produit SAP** : attribut logistique LotCode du stock
|
||||
|
||||
- **Code lot SAP** : ItemCode du stock (= code article WMS)
|
||||
|
||||
- **Quantité** : quantité actuelle de la ligne de stock (UdM de base WMS = unité alternative SAP)
|
||||
|
||||
- **UdM** : BAG ou KG
|
||||
|
||||
- **Zone de stockage** : zone WMS du container (origine et destination)
|
||||
|
||||
- **Code support** : ContainerCode (SSCC)
|
||||
|
||||
- **Code livraison sortante** : ShippingOrderCode si action P
|
||||
|
||||
|
||||
### Filtre d'exclusion
|
||||
|
||||
**Exclure les palettes liées à une réception non fermée** (= dont le REF n'a pas encore été envoyé). Seules les HU déjà connues de SAP via un REF préalable doivent apparaître dans le LOC.
|
||||
|
||||
---
|
||||
|
||||
## Format JSON de sortie
|
||||
|
||||
`{ "IV_LGNUM": "WF02", "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_OU_VIDE>", "VBELN": "<CODE_LIVRAISON_OU_VIDE>", "POSNR": "<LIGNE_LIVRAISON_OU_VIDE>" } ] }`
|
||||
|
||||
---
|
||||
|
||||
## Règles de remplissage par action
|
||||
|
||||
| | | | | | | |
|
||||
|---|---|---|---|---|---|---|
|
||||
|Champ|B (déplacement)|U/R (statut)|S (suppression)|T (transfert)|C (correction)|P (assignation client)|
|
||||
|MATNR|Vide|Code produit SAP|Code produit SAP|Code produit SAP|Code produit SAP|Vide|
|
||||
|BATCHID|Vide|Lot SAP|Lot SAP|Lot SAP|Lot SAP|Vide|
|
||||
|ACTION|B|U ou R|S|T|C|P|
|
||||
|ANFME|Vide|Vide|Qté supprimée|Qté transférée|Qté absolue comptée|Vide|
|
||||
|ALTME|Vide|UdM|UdM|UdM|UdM|Vide|
|
||||
|VLPLA|Zone origine|Zone actuelle|Zone actuelle|Zone HU source|Zone actuelle|Vide|
|
||||
|NLPLA|Zone destination|Vide|Vide|Zone HU destination|Vide|Image de quai|
|
||||
|VLENR|Code HU|Code HU|Code HU|Code HU source|Code HU|Code HU|
|
||||
|NLENR|Vide|Vide|Vide|Code HU destination|Vide|Vide|
|
||||
|REASON|Vide|Vide|ZSC1|Vide|Vide|Vide|
|
||||
|VBELN|Vide|Vide|Vide|Vide|Vide|Code livraison sortante|
|
||||
|POSNR|Vide|Vide|Vide|Vide|Vide|Ligne de livraison|
|
||||
|
||||
---
|
||||
|
||||
## Règles métier
|
||||
|
||||
### Déplacement (ACTION=B)
|
||||
|
||||
Déplacement de HU d'une zone à une autre. **Pas de quantité, pas de code article, pas de lot** — seuls les champs zone et support sont renseignés. Le contenu de la HU n'est pas rediscuté.
|
||||
|
||||
### Blocage/Déblocage (ACTION=R/U)
|
||||
|
||||
Hors flux retour, le seul statut autorisé est le **B6** (blocage logistique). Le LOC envoie R pour bloquer, U pour débloquer.
|
||||
|
||||
### Suppression/Scrap (ACTION=S)
|
||||
|
||||
REASON est renseigné **uniquement** pour cette action. Valeur : ZSC1 (scrapping normal).
|
||||
|
||||
### Transfert inter-HU (ACTION=T)
|
||||
|
||||
Source et destination **doivent être dans la même ligne** (VLENR + NLENR). ANFME = quantité transférée (pas le solde restant). Si le transfert passe par une étape intermédiaire (table de travail), transmettre chaque étape séparément avec un emplacement matérialisé.
|
||||
|
||||
**Cas picking :** 5 tâches alimentant la même palette fille = 5 lignes ACTION=T dans le même LOC, dans l'ordre chronologique.
|
||||
|
||||
**Création de palette au picking :** Si le SSCC en NLENR est inconnu de SAP, SAP crée automatiquement la HU (type palette standard). Le LOC ne crée que la structure palette — le stock est transféré depuis une palette source connue.
|
||||
|
||||
### Correction de quantité (ACTION=C)
|
||||
|
||||
Quantité **absolue** comptée/validée (pas un écart). SAP calcule le delta. REASON n'est pas renseigné.
|
||||
|
||||
### Assignation client (ACTION=P)
|
||||
|
||||
Déclencheur : palette physiquement positionnée sur l'**image de quai** (pas l'assignation logique). Les champs obligatoires sont :
|
||||
|
||||
- ACTION = P
|
||||
|
||||
- VLENR = Code HU
|
||||
|
||||
- NLPLA = Image de quai de la HU
|
||||
|
||||
- VBELN = Code livraison sortante SAP (= SorCode côté WMS)
|
||||
|
||||
- POSNR = Ligne de livraison sortante SAP (= ligne d'OS associée à l'article)
|
||||
|
||||
|
||||
Les champs MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON sont **vides** pour cette action.
|
||||
|
||||
---
|
||||
|
||||
## Horodatage
|
||||
|
||||
IV_TREATMENT_ID = horodatage du moment de **génération du LOC** (pas l'heure de chaque transaction individuelle). Toutes les lignes d'un même LOC partagent le même horodatage. Format limité à 24 caractères (CHAR 24).
|
||||
**Format** : YYYYMMDD
|
||||
|
||||
## Ordre des lignes
|
||||
|
||||
Les lignes dans IT_CREATE doivent être dans l'**ordre chronologique** des transactions WMS. SAP traite les lignes dans l'ordre du fichier.
|
||||
|
||||
---
|
||||
|
||||
## Désactivation STV et STC
|
||||
|
||||
### STV
|
||||
|
||||
Désactiver le post-processing des transactions STK.ADJ → plus de génération de message STV. Le LOC couvre ce besoin via ACTION=C.
|
||||
|
||||
**Vérifications préalables obligatoires :**
|
||||
|
||||
- Lister toutes les transactions qui génèrent un STV et confirmer que le LOC couvre chaque cas
|
||||
|
||||
- Vérifier que le middleware GNA n'a pas d'autre dépendance au STV
|
||||
|
||||
|
||||
### STC
|
||||
|
||||
Désactiver le post-processing des transactions CST.STK → plus de génération de message STC. Le LOC couvre le B6 via ACTION=R/U.
|
||||
|
||||
**Mêmes vérifications à effectuer que pour le STV.**
|
||||
|
||||
Documenter les résultats de cette analyse dans un commentaire de la tâche avant de procéder à la désactivation.
|
||||
|
||||
---
|
||||
|
||||
## Zones de stockage (VLPLA/NLPLA)
|
||||
|
||||
Les zones de stockage WMS doivent être découpées/créées pour correspondre au besoin du LOC :
|
||||
|
||||
Une table de correspondance est nécessaire car les codes zone WMS ne correspondent pas directement aux codes emplacement SAP. Cette table sera réalisée via un paramètre (ex : [TK_5_A:TK_5][TK_5_B:TK_5]).
|
||||
|
||||
Zones attendues par SAP :
|
||||
|
||||
- ASRS1 : correspond au TK1 (compartiment anoxie)
|
||||
|
||||
- ASRS2 : correspond au TK2 (compartiment du milieu)
|
||||
|
||||
- ASRS3 : correspond à la zone accessible du TK3 uniquement (grand compartiment)
|
||||
|
||||
- ASRS4 : correspond à la zone accessible du TK4 uniquement (grand compartiment)
|
||||
|
||||
- ASRS34 : correspond à la zone accessible des deux TK3 et TK4 (grand compartiment)
|
||||
|
||||
- PICKING : si présent sur un PK/TP
|
||||
|
||||
- QUAI : si présent sur un emplacement d’image de quai ou sur le quai
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Contraintes de longueur
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Champ|Type|Longueur max|
|
||||
|IV_LGNUM|CHAR|4|
|
||||
|IV_TREATMENT_ID|CHAR|24|
|
||||
|MATNR|CHAR|40|
|
||||
|BATCHID|CHAR|10|
|
||||
|ACTION|CHAR|1|
|
||||
|ANFME|NUM|13.3 (13 entiers, 3 décimales)|
|
||||
|ALTME|CHAR|3|
|
||||
|VLPLA|CHAR|18|
|
||||
|NLPLA|CHAR|18|
|
||||
|VLENR|CHAR|20|
|
||||
|NLENR|CHAR|20|
|
||||
|REASON|CHAR|4|
|
||||
|
||||
---
|
||||
|
||||
## Critères d'acceptation
|
||||
|
||||
1. Un job WMS tourne toutes les 5 minutes et crée une transaction custom LOC.SEND.
|
||||
|
||||
2. Le GNA détecte cette transaction et génère un JSON LOC conforme au format spécifié.
|
||||
|
||||
3. Le JSON est envoyé en POST à l'endpoint SAP.
|
||||
|
||||
4. Les 7 codes ACTION (B, U, R, S, T, C, P) sont correctement générés selon le type de transaction WMS source.
|
||||
|
||||
5. **ACTION=B** : les champs ANFME, ALTME, MATNR, BATCHID, NLENR, REASON, VBELN, POSNR sont vides. Seuls VLPLA, NLPLA et VLENR sont renseignés.
|
||||
|
||||
6. **ACTION=U/R** : MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés. ANFME, NLPLA, NLENR, REASON, VBELN, POSNR vides.
|
||||
|
||||
7. **ACTION=S** : REASON = ZSC1. MATNR, BATCHID, ANFME, ALTME, VLPLA, VLENR renseignés. NLPLA, NLENR, VBELN, POSNR vides.
|
||||
|
||||
8. **ACTION=T** : VLENR et NLENR renseignés dans la même ligne. ANFME = quantité transférée (pas un solde). MATNR, BATCHID, ALTME, VLPLA, NLPLA renseignés. REASON, VBELN, POSNR vides.
|
||||
|
||||
9. **ACTION=C** : ANFME = quantité absolue (pas un delta). MATNR, BATCHID, ALTME, VLPLA, VLENR renseignés. NLPLA, NLENR, REASON, VBELN, POSNR vides.
|
||||
|
||||
10. **ACTION=P** : VLENR, NLPLA (image de quai), VBELN (livraison sortante), POSNR (ligne de livraison) renseignés. MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON vides.
|
||||
|
||||
11. Les palettes liées à une réception non fermée (pas de REF envoyé) sont exclues du LOC.
|
||||
|
||||
12. Les lignes dans IT_CREATE sont dans l'**ordre chronologique** des transactions WMS.
|
||||
|
||||
13. IV_TREATMENT_ID = horodatage de génération du LOC (CHAR 24).
|
||||
|
||||
14. Si aucune transaction pertinente sur le delta → pas d'envoi de LOC.
|
||||
|
||||
15. Tous les champs respectent les contraintes de longueur (MATNR ≤ 40, BATCHID ≤ 10, VLENR/NLENR ≤ 20, VLPLA/NLPLA ≤ 18, REASON ≤ 4, ANFME = NUM 13.3).
|
||||
|
||||
16. STV et STC désactivés après validation de l'analyse d'impact.
|
||||
|
||||
17. Cas picking : N tâches alimentant la même palette fille = N lignes ACTION=T dans le même LOC, dans l'ordre chronologique.
|
||||
|
||||
18. Si le SSCC en NLENR est inconnu de SAP lors d'un ACTION=T, SAP crée automatiquement la HU — le LOC ne doit pas bloquer.
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Cas de tests
|
||||
|
||||
## 1. Architecture & Job
|
||||
|
||||
### CT-01 — Déclenchement du job toutes les 5 minutes
|
||||
|
||||
**CA :** 1 **Préconditions :** Job LOC activé, WMS et GNA opérationnels. **Étapes :**
|
||||
|
||||
1. Observer le job LOC pendant 15 minutes.
|
||||
|
||||
2. Vérifier la création de transactions LOC.SEND dans le WMS.
|
||||
|
||||
|
||||
**Résultat attendu :** 3 transactions LOC.SEND créées à ~5 min d'intervalle.
|
||||
|
||||
---
|
||||
|
||||
### CT-02 — Le GNA détecte la transaction LOC.SEND et génère le JSON
|
||||
|
||||
**CA :** 2, 3 **Préconditions :** Au moins une transaction WMS pertinente existe sur le delta. **Étapes :**
|
||||
|
||||
1. Provoquer un mouvement de HU (ex. CON.MOVE).
|
||||
|
||||
2. Attendre le prochain cycle du job LOC.
|
||||
|
||||
3. Vérifier les logs du GNA.
|
||||
|
||||
|
||||
**Résultat attendu :** Le GNA détecte LOC.SEND, génère un JSON conforme et effectue un POST vers l'endpoint SAP. La réponse HTTP est 200.
|
||||
|
||||
---
|
||||
|
||||
### CT-03 — Aucune transaction sur le delta → pas d'envoi
|
||||
|
||||
**CA :** 14 **Préconditions :** Aucun mouvement WMS sur les 5 dernières minutes. **Étapes :**
|
||||
|
||||
1. Attendre le prochain cycle du job LOC.
|
||||
|
||||
2. Vérifier les logs du GNA.
|
||||
|
||||
|
||||
**Résultat attendu :** Aucun appel POST n'est effectué vers SAP. Le GNA logge l'absence de transactions.
|
||||
|
||||
---
|
||||
|
||||
## 2. ACTION=B — Déplacement bin-to-bin
|
||||
|
||||
### CT-10 — Déplacement via CON.MOVE
|
||||
|
||||
**CA :** 4, 5 **Préconditions :** HU HU-001 en zone TK_1, connue de SAP (REF envoyé). **Étapes :**
|
||||
|
||||
1. Exécuter un CON.MOVE de HU-001 de TK_1 vers TK_3.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
3. Inspecter le JSON envoyé.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "B", "VLPLA": "TK_1", "NLPLA": "TK_3", "VLENR": "HU-001", "MATNR": "", "BATCHID": "", "ANFME": "", "ALTME": "", "NLENR": "", "REASON": "", "VBELN": "", "POSNR": "" }`
|
||||
|
||||
---
|
||||
|
||||
### CT-11 — Déplacement via CON.LOCATE
|
||||
|
||||
**CA :** 4, 5 **Préconditions :** HU HU-002 en zone PK_01, connue de SAP. **Étapes :**
|
||||
|
||||
1. Exécuter un CON.LOCATE de HU-002 vers QUAI_03.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Ligne ACTION=B identique en structure à CT-10, avec VLPLA=PK_01, NLPLA=QUAI_03, VLENR=HU-002. Tous les autres champs vides.
|
||||
|
||||
---
|
||||
|
||||
### CT-12 — Déplacement via STK.MOVE sans changement de HU
|
||||
|
||||
**CA :** 4, 5 **Préconditions :** HU HU-003 contenant du stock, ContainerTo = ContainerCode (même HU). **Étapes :**
|
||||
|
||||
1. Exécuter un STK.MOVE où ContainerTo = ContainerCode et la zone change.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Ligne ACTION=B (pas T). MATNR, BATCHID, ANFME, ALTME vides. Zones origine/destination renseignées.
|
||||
|
||||
---
|
||||
|
||||
## 3. ACTION=U/R — Blocage / Déblocage
|
||||
|
||||
### CT-20 — Blocage d'une HU (ACTION=R)
|
||||
|
||||
**CA :** 4, 6 **Préconditions :** HU HU-010 en zone TK_2, statut libre, connue de SAP. **Étapes :**
|
||||
|
||||
1. Exécuter un CST.STK passant HU-010 en statut B6.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "R", "MATNR": "<code_produit>", "BATCHID": "<lot>", "ALTME": "<udm>", "VLPLA": "TK_2", "VLENR": "HU-010", "ANFME": "", "NLPLA": "", "NLENR": "", "REASON": "", "VBELN": "", "POSNR": "" }`
|
||||
|
||||
---
|
||||
|
||||
### CT-21 — Déblocage d'une HU (ACTION=U)
|
||||
|
||||
**CA :** 4, 6 **Préconditions :** HU HU-010 en zone TK_2, statut B6, connue de SAP. **Étapes :**
|
||||
|
||||
1. Exécuter un CST.STK retirant le statut B6 de HU-010.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Idem CT-20 mais ACTION=U.
|
||||
|
||||
---
|
||||
|
||||
### CT-22 — Changement de statut hors B6 (hors retour) → pas de ligne LOC
|
||||
|
||||
**CA :** 6 **Préconditions :** HU HU-011, changement de statut autre que B6 (ex. F2, F9). **Étapes :**
|
||||
|
||||
1. Exécuter un CST.STK avec un statut retour.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Aucune ligne générée dans le LOC pour cette transaction.
|
||||
|
||||
---
|
||||
|
||||
## 4. ACTION=S — Suppression / Scrap
|
||||
|
||||
### CT-30 — Suppression d'un container (CON.DELETE)
|
||||
|
||||
**CA :** 4, 7 **Préconditions :** HU HU-020 en zone TK_4, contenant 150.000 BAG de produit MAT-A, lot LOT-1, connue de SAP. **Étapes :**
|
||||
|
||||
1. Exécuter un CON.DELETE sur HU-020.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "S", "MATNR": "MAT-A", "BATCHID": "LOT-1", "ANFME": "150.000", "ALTME": "BAG", "VLPLA": "TK_4", "VLENR": "HU-020", "REASON": "ZSC1", "NLPLA": "", "NLENR": "", "VBELN": "", "POSNR": "" }`
|
||||
|
||||
---
|
||||
|
||||
### CT-31 — REASON toujours ZSC1 pour action S
|
||||
|
||||
**CA :** 7 **Préconditions :** Plusieurs suppressions via CON.DELETE. **Étapes :**
|
||||
|
||||
1. Supprimer 2 containers différents.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Chaque ligne ACTION=S a REASON=ZSC1. Pas d'autre valeur.
|
||||
|
||||
---
|
||||
|
||||
## 5. ACTION=T — Transfert inter-HU
|
||||
|
||||
### CT-40 — Transfert via STK.MOVE avec changement de HU
|
||||
|
||||
**CA :** 4, 8 **Préconditions :** HU HU-030 (source) en zone TK_1, HU HU-031 (destination) en zone PK_02. Transfert de 50.000 KG de produit MAT-B, lot LOT-2. **Étapes :**
|
||||
|
||||
1. Exécuter un STK.MOVE avec ContainerTo ≠ ContainerCode.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "T", "MATNR": "MAT-B", "BATCHID": "LOT-2", "ANFME": "50.000", "ALTME": "KG", "VLPLA": "TK_1", "NLPLA": "PK_02", "VLENR": "HU-030", "NLENR": "HU-031", "REASON": "", "VBELN": "", "POSNR": "" }`
|
||||
|
||||
---
|
||||
|
||||
### CT-41 — Transfert via STK.PICKING
|
||||
|
||||
**CA :** 4, 8 **Préconditions :** HU source HU-040, palette fille HU-041. Picking de 20.000 BAG de MAT-C, lot LOT-3. **Étapes :**
|
||||
|
||||
1. Exécuter un STK.PICKING.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Ligne ACTION=T avec VLENR=HU-040, NLENR=HU-041, ANFME=20.000 (quantité transférée, pas le solde restant).
|
||||
|
||||
---
|
||||
|
||||
### CT-42 — Picking multiple : N tâches → N lignes ACTION=T
|
||||
|
||||
**CA :** 17 **Préconditions :** 3 tâches de picking alimentant la même palette fille HU-050 depuis 3 HU sources différentes. **Étapes :**
|
||||
|
||||
1. Exécuter les 3 pickings dans l'ordre : HU-051 → HU-050, HU-052 → HU-050, HU-053 → HU-050.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** 3 lignes ACTION=T dans IT_CREATE, dans l'ordre chronologique des pickings. Chaque ligne a NLENR=HU-050 et un VLENR différent.
|
||||
|
||||
---
|
||||
|
||||
### CT-43 — Transfert vers SSCC inconnu de SAP
|
||||
|
||||
**CA :** 18 **Préconditions :** Palette fille HU-060 nouvellement créée (SSCC inexistant côté SAP). **Étapes :**
|
||||
|
||||
1. Exécuter un picking vers HU-060.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** La ligne ACTION=T est générée normalement avec NLENR=HU-060. Le LOC ne bloque pas. SAP crée automatiquement la HU à réception.
|
||||
|
||||
---
|
||||
|
||||
### CT-44 — Transfert via étape intermédiaire (table de travail)
|
||||
|
||||
**CA :** 8 **Préconditions :** Transfert de HU-070 vers HU-071 passant par une table de travail TW_01. **Étapes :**
|
||||
|
||||
1. Exécuter les mouvements : HU-070 → TW_01, puis TW_01 → HU-071.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** 2 lignes distinctes dans le LOC, chacune avec un emplacement matérialisé (pas de fusion en une seule ligne).
|
||||
|
||||
---
|
||||
|
||||
## 6. ACTION=C — Correction de quantité
|
||||
|
||||
### CT-50 — Ajustement de stock via STK.ADJ
|
||||
|
||||
**CA :** 4, 9 **Préconditions :** HU HU-080 en zone TK_5, stock actuel 100.000 BAG de MAT-D, lot LOT-4. Ajustement à 95.000 BAG. **Étapes :**
|
||||
|
||||
1. Exécuter un STK.ADJ sur HU-080.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "C", "MATNR": "MAT-D", "BATCHID": "LOT-4", "ANFME": "95.000", "ALTME": "BAG", "VLPLA": "TK_5", "VLENR": "HU-080", "NLPLA": "", "NLENR": "", "REASON": "", "VBELN": "", "POSNR": "" }`
|
||||
|
||||
ANFME = quantité absolue après ajustement (95.000), pas le delta (-5.000).
|
||||
|
||||
---
|
||||
|
||||
### CT-51 — REASON vide pour action C
|
||||
|
||||
**CA :** 9 **Préconditions :** Ajustement de stock. **Étapes :** Idem CT-50.
|
||||
|
||||
**Résultat attendu :** Le champ REASON est vide (pas de code raison pour les corrections).
|
||||
|
||||
---
|
||||
|
||||
## 7. ACTION=P — Assignation client
|
||||
|
||||
### CT-60 — Palette positionnée sur image de quai
|
||||
|
||||
**CA :** 4, 10 **Préconditions :** HU HU-090 assignée à la livraison VBELN-001, ligne 010. Image de quai QUAI_07. **Étapes :**
|
||||
|
||||
1. Positionner physiquement HU-090 sur l'image de quai QUAI_07.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :**
|
||||
|
||||
`{ "ACTION": "P", "VLENR": "HU-090", "NLPLA": "QUAI_07", "VBELN": "VBELN-001", "POSNR": "010", "MATNR": "", "BATCHID": "", "ANFME": "", "ALTME": "", "VLPLA": "", "NLENR": "", "REASON": "" }`
|
||||
|
||||
---
|
||||
|
||||
### CT-61 — ACTION=P : champs MATNR, BATCHID, ANFME, ALTME, VLPLA, NLENR, REASON vides
|
||||
|
||||
**CA :** 10 **Préconditions :** Idem CT-60.
|
||||
|
||||
**Résultat attendu :** Vérifier explicitement que les 7 champs ci-dessus sont vides dans la ligne P.
|
||||
|
||||
---
|
||||
|
||||
## 8. Filtre d'exclusion
|
||||
|
||||
### CT-70 — HU liée à une réception non fermée exclue du LOC
|
||||
|
||||
**CA :** 11 **Préconditions :** HU HU-100 vient d'être réceptionnée, le REF n'a **pas** encore été envoyé à SAP. Un mouvement CON.MOVE est effectué sur HU-100. **Étapes :**
|
||||
|
||||
1. Déplacer HU-100.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Aucune ligne pour HU-100 dans le LOC.
|
||||
|
||||
---
|
||||
|
||||
### CT-71 — HU liée à une réception fermée (REF envoyé) incluse dans le LOC
|
||||
|
||||
**CA :** 11 **Préconditions :** HU HU-101 réceptionnée, REF envoyé et confirmé par SAP. Un mouvement est effectué sur HU-101. **Étapes :**
|
||||
|
||||
1. Déplacer HU-101.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** La ligne apparaît dans le LOC.
|
||||
|
||||
---
|
||||
|
||||
## 9. Ordre chronologique & Horodatage
|
||||
|
||||
### CT-80 — Lignes dans l'ordre chronologique
|
||||
|
||||
**CA :** 12 **Préconditions :** 3 transactions WMS effectuées dans l'ordre : CON.MOVE (t1), STK.ADJ (t2), STK.PICKING (t3). **Étapes :**
|
||||
|
||||
1. Exécuter les 3 transactions.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
3. Inspecter l'ordre des lignes dans IT_CREATE.
|
||||
|
||||
|
||||
**Résultat attendu :** Les lignes apparaissent dans l'ordre t1 → t2 → t3 (ACTION=B, puis C, puis T).
|
||||
|
||||
---
|
||||
|
||||
### CT-81 — IV_TREATMENT_ID = horodatage de génération
|
||||
|
||||
**CA :** 13 **Préconditions :** Transactions effectuées à des heures différentes sur le delta. **Étapes :**
|
||||
|
||||
1. Inspecter IV_TREATMENT_ID dans le JSON.
|
||||
|
||||
|
||||
**Résultat attendu :** IV_TREATMENT_ID correspond à l'heure de génération du LOC (pas l'heure d'une transaction individuelle). Toutes les lignes partagent le même horodatage. Longueur ≤ 24 caractères.
|
||||
|
||||
---
|
||||
|
||||
## 10. Contraintes de longueur
|
||||
|
||||
### CT-90 — Respect des longueurs max MII
|
||||
|
||||
**CA :** 15 **Préconditions :** Données de test avec des valeurs aux limites de longueur. **Étapes :**
|
||||
|
||||
1. Créer des données avec : MATNR de 40 caractères, BATCHID de 10 caractères, VLENR/NLENR de 20 caractères, VLPLA/NLPLA de 18 caractères.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Le JSON est généré sans troncature ni erreur. Les valeurs respectent les longueurs max.
|
||||
|
||||
---
|
||||
|
||||
### CT-91 — ANFME au format NUM 13.3
|
||||
|
||||
**CA :** 15 **Préconditions :** Quantité avec décimales (ex. 12345.678). **Étapes :**
|
||||
|
||||
1. Ajuster un stock à une quantité avec 3 décimales.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** ANFME formaté en NUM 13.3 (max 13 chiffres entiers, 3 décimales).
|
||||
|
||||
---
|
||||
|
||||
## 11. Désactivation STV / STC
|
||||
|
||||
### CT-100 — Plus de STV après désactivation
|
||||
|
||||
**CA :** 16 **Préconditions :** STV désactivé (post-processing STK.ADJ supprimé). **Étapes :**
|
||||
|
||||
1. Exécuter un STK.ADJ.
|
||||
|
||||
2. Vérifier qu'aucun message STV n'est généré.
|
||||
|
||||
3. Vérifier que le LOC contient bien une ligne ACTION=C.
|
||||
|
||||
|
||||
**Résultat attendu :** Pas de STV. Le LOC couvre le mouvement via ACTION=C.
|
||||
|
||||
---
|
||||
|
||||
### CT-101 — Plus de STC après désactivation
|
||||
|
||||
**CA :** 16 **Préconditions :** STC désactivé (post-processing CST.STK supprimé). **Étapes :**
|
||||
|
||||
1. Exécuter un CST.STK (blocage B6).
|
||||
|
||||
2. Vérifier qu'aucun message STC n'est généré.
|
||||
|
||||
3. Vérifier que le LOC contient bien une ligne ACTION=R.
|
||||
|
||||
|
||||
**Résultat attendu :** Pas de STC. Le LOC couvre le mouvement via ACTION=R.
|
||||
|
||||
---
|
||||
|
||||
## 12. Cas combinés / Scénarios de bout en bout
|
||||
|
||||
### CT-110 — LOC avec plusieurs actions dans le même delta
|
||||
|
||||
**CA :** 4, 12 **Préconditions :** Sur le même delta de 5 minutes, effectuer : un déplacement (B), un blocage (R), un picking (T), une correction (C). **Étapes :**
|
||||
|
||||
1. Exécuter les 4 opérations.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** Le JSON contient 4 lignes dans IT_CREATE, une par action, dans l'ordre chronologique. Chaque ligne respecte ses règles de remplissage propres.
|
||||
|
||||
---
|
||||
|
||||
### CT-111 — IV_LGNUM toujours "WF02"
|
||||
|
||||
**CA :** 2 **Préconditions :** Valeur configurée dans EasyS. **Étapes :**
|
||||
|
||||
1. Inspecter plusieurs JSON LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** IV_LGNUM = "WF02" dans tous les cas.
|
||||
|
||||
---
|
||||
|
||||
### CT-112 — HU multi-lignes de stock (point en attente #2)
|
||||
|
||||
**CA :** — **Préconditions :** HU contenant 2 lignes de stock (2 articles/lots différents). **Étapes :**
|
||||
|
||||
1. Effectuer un mouvement sur cette HU.
|
||||
|
||||
2. Attendre le cycle LOC.
|
||||
|
||||
|
||||
**Résultat attendu :** plusieurs entrées dans IT_CREATE
|
||||
|
||||
---
|
||||
|
||||
## Points en attente
|
||||
|
||||
| | | | |
|
||||
| --- | ----------------------------------------------------------------------------------------------------------------------- | ------------- | ---------- |
|
||||
| # | Point | En attente de | Impact dev |
|
||||
| 3 | Cas palette déposée sur image de quai → chargée → OS fermé → LOF/SOF envoyé avant le LOC (LOC ne mentionnera pas la HU) | Limagrain | Non |
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
## Contexte
|
||||
|
||||
Les postes de picking sont configurés en assignation manuelle et ce sera ce job qui assignera le poste de picking à une commande.
|
||||
|
||||
## Développement
|
||||
|
||||
Le poste de picking pourra être assigné à une commande s’il respecte les critères suivants :
|
||||
|
||||
- Le poste de picking autorise la préparation de commande
|
||||
|
||||
- Le poste de picking n’a pas de commande assignée
|
||||
|
||||
- Le poste de picking est vide
|
||||
|
||||
- Le poste de picking n’a aucune tâche en direction de celui-ci.
|
||||
|
||||
|
||||
### Choix de la commande
|
||||
|
||||
**Commandes Messagerie**
|
||||
|
||||
Les commandes Messagerie (classe de commande) sont prioritaires sur les autres commandes car elle sont expédiées le jour même.
|
||||
|
||||
Une fois un poste de picking choisi pour une commande Messagerie, toutes les commandes Messagerie du même transporteur devront être assignées au même poste de picking.
|
||||
|
||||
Pour cela, on créera un paramètre par transporteur : PK_TRANSPORTEUR_MESSAGERIE.
|
||||
|
||||
Lorsqu’une commande Messagerie est assigné au PK, on enregistre le nom du PK dans le paramètre. Si ce paramètre contient une valeur, 2 choix possibles :
|
||||
|
||||
- La valeur correspond au poste de picking qu’on analyse, on assigne la prochaine commande Messagerie du même transporteur
|
||||
|
||||
- La valeur correspond à un autre poste de picking : On ignore toutes les commandes de classe Messagerie de ce transporteur pour trouver une commande à assigner.
|
||||
|
||||
|
||||
Si le paramètre contient le nom du PK, on ne pourra assigner QUE des commande Messagerie associées au transporteur du paramètre. Si le WMS ne parvient pas à assigner une commande alors on vide le paramètre.
|
||||
|
||||
**Autres commandes**
|
||||
|
||||
Utiliser le processus standard pour assigner une nouvelle commande à une table de préparation et un poste de picking.
|
||||
|
||||
Vérifier que l’on prépare bien les commandes d’une même tournée en respectant le numéro d’arrêt, on prépare les commandes le plus petit numéro d’arrêt en premier.
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
## Développement
|
||||
|
||||
Toutes les tâches de picking devront être réalisées sur les postes de picking qui sont des tables élévatrices. Limagrain souhaite qu’un certain ordre soit priorisé pour les tâches de picking.
|
||||
|
||||
Les tâches de picking négatifs seront faite en premier et seulement une palette pourra être amenée à la fois pour ce process là. La table de dépose sera toujours celle du centre dans ce cas.
|
||||
|
||||
A chaque tâche de picking négatif, un nouveau code SSCC et une étiquette RFID devra être imprimée pour la palette où on aura déposer l’excédent de stock
|
||||
|
||||
Le WMS pourra envoyer une palette de picking négatif et une palette de picking normal en même temps vers le poste de picking. (Pour compléter la palette où aura été prélever le stock en picking négatif).
|
||||
|
||||
Les tâches de picking classiques pourront être ensuite réalisées et cette fois on pourra amener 2 palettes en même temps au poste de picking. Les tables de dépose seront toujours les 2 sur les côtés dans ce cas là.
|
||||
|
||||
Le nombre de palettes de prélèvement ne pourra jamais excéder 2 au poste de picking
|
||||
|
||||
### Cas d’exemple
|
||||
|
||||
10 tâches à réaliser, 3 en picking négatif, 7 en picking classique.
|
||||
|
||||
Le WMS envoie 2 palettes vers le poste de PK, une pour le picking négatif, une pour le picking classique.
|
||||
|
||||
Les autres palettes peuvent être sortie de l’installation et être déposées sur les zone d’attente s’il y a de la place disponible. Le WMS privilégie alors les palettes de picking négatif à sortir.
|
||||
|
||||
2 palettes sont au PK. L’opérateur réalise le picking négatif, on imprime une étiquette palette avec RFID pour ranger la nouvelle palette où aura été déposé l’excédent de stock.
|
||||
|
||||
L’opérateur réalise la tâche de picking classique en déposant le stock sur la palette du milieu. La palette n’est pas pleine. Le WMS apporte une nouvelle palette pour un picking classique.
|
||||
|
||||
L’opérateur déclare la palette client pleine, le WMS apporte la seconde palette où réaliser le picking négatif. Si le picking classique précédent n’est pas fini (tâche partiellement réalisée) le WMS n’apporte pas de nouvelle palette pour le picking classique. Sinon le WMS apporte une seconde palette vers le poste de picking.
|
||||
|
||||
10 tâches générées :
|
||||
|
||||
1 picking négatif vers PK
|
||||
|
||||
1 picking classique vers PK
|
||||
|
||||
8 tâches vers les zones d’attente.
|
||||
|
||||
# Notes et brouillons concernant le cadencement (PS > PK)
|
||||
|
||||
A chaque palette qui arrive au PS, le PS doit vérifier s’il n’existe pas d’autres tâches de cet OS avec une séquence plus faible :
|
||||
|
||||
- si oui > palette envoyée au buffer ES_X
|
||||
|
||||
- si non > palette envoyée au PK
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
# Séquençage TK → PS — Notes de conception
|
||||
|
||||
## Contexte
|
||||
|
||||
Process de séquençage des tâches de picking (TK) vers les postes de sortie (PS), déclenché sur les événements du cycle de vie des ordres de sortie (OS).
|
||||
|
||||
---
|
||||
|
||||
## Historique des solutions envisagées
|
||||
|
||||
### Solution 1 — Process isolé sur finalisation des tâches d'OS
|
||||
|
||||
**Principe :**
|
||||
|
||||
1. Process déclenché à la finalisation de la création des tâches d'un OS
|
||||
|
||||
2. Séquençage des tâches via OS.Line.CstAtt
|
||||
|
||||
3. OS marqué comme traité via OS.CstAtt = true
|
||||
|
||||
|
||||
**Problème :** Pas assez dynamique en cas de recréation de tâches suite à des imprévus dans le WMS.
|
||||
|
||||
---
|
||||
|
||||
### Solution 2 — Calcul dans le workflow stacker_crane
|
||||
|
||||
**Principe :** Intégrer le tri directement dans le WF Galileo_StackerCraneSearch_PR / StackerCrane_SortTasks_PR, avec recalcul complet du pool de tâches à chaque exécution. Supprime le besoin de OS.Line.CstAtt et OS.CstAtt
|
||||
|
||||
**Problème :** Wallah c’est compliqué
|
||||
|
||||
`.Where(t=>t.CustomAttribute <= t.OutboundOrder.SelectMany(o=>o.Tasks).Where(ot.ProcessType == XXX)).OrderBy(ot=>ot.CustomAttribute).FirstOrDefault()))`
|
||||
|
||||
---
|
||||
|
||||
### Solution 3 — Solution 1 transformée en job
|
||||
|
||||
**Principe :** Reprendre le process de la solution 1 sous forme de job planifié, en excluant les tâches de picking en cours.
|
||||
|
||||
**Problème :** Pas assez réactif par rapport à la cadence de recherche d'ordre des TK.
|
||||
|
||||
---
|
||||
|
||||
### Solution 4 — Process événementiel (retenu)
|
||||
|
||||
**Principe :** Reprendre la solution 1 et la déclencher sur deux événements :
|
||||
|
||||
- TaskCreatedEvent
|
||||
|
||||
- Vérifier que la tâche est de type picking et que l'OS associé est au statut Released
|
||||
|
||||
- Si oui :
|
||||
|
||||
1. Passer OS.CstAtt = false pour bloquer la prise en charge par stacker_crane
|
||||
|
||||
2. Récupérer l'ensemble des tâches de l'OS
|
||||
|
||||
3. Filtrer sur les tâches en attente (exclure les tâches en cours)
|
||||
|
||||
4. Appliquer l'algorithme de séquençage (cf. section suivante)
|
||||
|
||||
5. Repasser OS.CstAtt = true
|
||||
|
||||
- OutboundOrderReleasedEvent
|
||||
|
||||
- Passer OS.CstAtt = false pour bloquer la prise en charge par stacker_crane
|
||||
|
||||
- Peut arriver si OS arrêté puis relancé
|
||||
|
||||
- Appliquer directement l'algorithme de séquençage sur les tâches
|
||||
|
||||
- Passer OS.CstAtt = true
|
||||
|
||||
|
||||
**Avantages :**
|
||||
|
||||
- Plus simple à développer
|
||||
|
||||
- Isolée et découplée
|
||||
|
||||
- Flexible et réactive
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Algorithme de séquençage (TK → PS)
|
||||
|
||||
- Si la table TP est vide → priorité à la tâche de picking négatif (1 palette)
|
||||
|
||||
- Vérification de la capacité PK/BUFFER _(déjà custom_ [https://easywmsfrance.atlassian.net/browse/LIM-61](https://easywmsfrance.atlassian.net/browse/LIM-61) _— à modifier)_ :
|
||||
|
||||
- Prendre en compte les palettes sources ayant des tâches de picking pour plusieurs PK
|
||||
_(ex. : une palette peut enchaîner PK1 → ES_5 → PK2)_
|
||||
|
||||
- Paramètre MAX_NB_BUFFER_PK : nombre de buffers disponibles par PK — **valeur par défaut : 3**
|
||||
+2
@@ -0,0 +1,2 @@
|
||||
Comme vu ensemble le 2 avril, il faut mettre en place ces stratégies.
|
||||
Tâche ouverte pour suivre le sujet et documenter/rebondir si besoin
|
||||
+234
@@ -0,0 +1,234 @@
|
||||
### Génération des tâches
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Type de palette|Action|
|
||||
|Palettes complètes / picking terminées|Tâche de défragmentation (reloc) vers zone de stockage d'expédition dans l'ASRS. Ne se déclenche que si toutes les palettes clientes sont “terminées” donc que les palettes de picking sont retournées dans l’ASRS et qu’aucun quai n’est associé à l’OS. (**CUSTOM**)|
|
||||
|Palettes picking|Aucune tâche tant qu'un poste de travail n'est pas assigné|
|
||||
|
||||
_En standard, si je choisis “Expédition uniquement”, les palettes de picking ne sont pas reloc et donc l’ordonnancement par stop est faux”._
|
||||
_Si je choisis “Picking et expédition”, il va reloc toutes les palettes concernées dont celles qui ont besoin d'être pickées. Problème : quand il faudra faire le picking, on va ressortir ces palettes et casser l’ordonnancement._
|
||||
|
||||
_Pour pouvoir faire du picking sur une palette, un quai doit être associé à l’OS._
|
||||
|
||||
_Custom : attendre que toutes les palettes de picking soient pickées et rangées dans l’ASRS dans le job qui check les relocs pour ordonnancer par stop. Le job peut lancer la reloc lorsque toutes les palettes considérées comme des palette d’expédition._
|
||||
|
||||
reprendre paramétrage [https://easywmsfrance.atlassian.net/browse/LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85)
|
||||
|
||||
## 1. Contexte
|
||||
|
||||
La défragmentation client standard propose trois modes d'assignation (Picking Only, Shipping Only, Picking & Shipping).
|
||||
|
||||
Aucun ne répond au besoin Limagrain :
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|Mode standard|Comportement|Problème pour Limagrain|
|
||||
|**Shipping Only**|Défragmentation uniquement les palettes complètes.|Les palettes de picking ne sont pas repositionnées → l'ordonnancement par n° de STOP dans le canal est faux.|
|
||||
|**Picking & Shipping**|Défrag toutes les palettes (y compris celles à picker).|La défragmentation se lance sur toutes les palettes, même celles devant sortir plus tard pour picking, cassant l'ordonnancement dans le canal.|
|
||||
|**Picking Only**|Non applicable au besoin.||
|
||||
|
||||
**Contrainte métier :** le stock doit être rangé dans le canal d'expédition **ASRS** dans l'ordre inverse des STOP de la tournée associée, de façon à ce que les palettes sortent du canal dans le bon ordre lors du chargement camion.
|
||||
|
||||
## 2. Objectif du custom
|
||||
|
||||
Déclencher la défragmentation client d'un tournée **uniquement lorsque toutes ses palettes de tous ses OS sont prêtes à partir vers l'image de quai**, c'est-à-dire :
|
||||
|
||||
- Les palettes complètes sont dans l'ASRS ;
|
||||
|
||||
- Les palettes ayant nécessité un picking sont revenues dans l'ASRS après prélèvement (palettes de picking retournées) ;
|
||||
|
||||
- **Aucun quai n'est encore associé à la tournée** (sinon le flux shipping standard avec ordonnancement par stop prend le relais et envoie directement vers l'image de quai).
|
||||
|
||||
|
||||
La condition « toutes les palettes terminées » s'évalue **au niveau de la tournée** (RUT)
|
||||
|
||||
## 3. Développement
|
||||
|
||||
### 3.1 Mécanisme
|
||||
|
||||
- **Utiliser le job de défragmentation client standard** avec une stratégie en mode Shipping et type d'ordre Tournée.
|
||||
|
||||
- Ajouter un **filtre custom au niveau de la sélection des candidats** qui exclut de l'éligibilité toute tournée dont au moins une palette (d'au moins un OS) n'est pas encore prête dans l'ASRS.
|
||||
|
||||
|
||||
### 3.2 Règle d'éligibilité
|
||||
|
||||
`Pour chaque RUT candidat à la défrag shipping (en standard, exclut les RUT avec quai assigné)): POUR CHAQUE OS du RUT : SI l'OS a des lignes picking → EXCLURE le RUT SI au moins une palette complète assignée n'est pas dans l'ASRS → EXCLURE le RUT SI aucune exclusion → ÉLIGIBLE SINON → reste candidat pour le prochain passage du job`
|
||||
|
||||
> **Point clé :** l'éligibilité est « tout-ou-rien » au niveau tournée. Tant qu'un seul OS du RUT n'a pas toutes ses palettes prêtes, aucune défrag n'est lancée pour le RUT.
|
||||
|
||||
### 3.3 Paramétrage
|
||||
|
||||
- MAX_DEFRAG_ATTEMPT : qui de ce paramètre ?
|
||||
_À chaque passage du job, le WMS essaie de trouver un emplacement valide dans la zone de destination. Si aucune location valide n'est trouvée (zone pleine, règles de putaway qui ne matchent pas, etc.), le compteur de tentatives pour ce support est incrémenté. Une fois MAX_DEFRAG_ATTEMPT atteint (5 par défaut) , ce support spécifique est retiré de la liste des candidats défrag. Il ne bougera plus, même si la location se libère plus tard. Il plafonne uniquement le nombre de retentatives par palette quand le WMS n'arrive pas à lui trouver une destination. dans notre tâche custom defrag, le compteur ne s'incrémente que si le WMS a cherché un empl de destination et n'en a pas trouvé. Si notre filtre custom exclut la tournée avant même de chercher une destination (parce qu'un OS n'a pas ses palettes prêtes), alors aucune tentative n'est décomptée pour les supports concernés. Le compteur reste à 0._
|
||||
Potentiellement, ce paramètre n’est utilisé que pour la defrag de rotation → à vérifier lors du développement.
|
||||
|
||||
|
||||
## 4. Cas de test
|
||||
|
||||
### Légende
|
||||
|
||||
- **PC** = palette complète (pas de picking nécessaire)
|
||||
|
||||
- **PP** = palette de picking (palette mère qui part au PK)
|
||||
|
||||
- **PF** = palette fille (sortie du picking, retour ASRS)
|
||||
|
||||
- **OS** = ordre de sortie (SOR), **RUT** = tournée
|
||||
|
||||
- **Éligible défrag** = le job custom doit inclure le RUT dans le lot à défragmenter
|
||||
|
||||
- **Non éligible** = le RUT doit être exclu à ce cycle
|
||||
|
||||
|
||||
#### CT-01 — RUT mono-OS avec uniquement des palettes complètes
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT libéré avec 1 SOR, 3 PC assignées, toutes dans l'ASRS, aucun quai assigné au RUT.|
|
||||
|**Action**|Passage du job défrag shipping.|
|
||||
|**Résultat attendu**|RUT éligible. 3 tâches de defrag générées vers la zone d'expédition ASRS. Tri par sequence respecté.|
|
||||
|
||||
#### CT-02 — RUT mono-OS avec uniquement du picking (toutes PF revenues)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT libéré avec 1 SOR, 2 PP parties au PK, 2 PF générées et revenues à l'ASRS, aucun quai assigné.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|RUT éligible. 2 tâches de defrag générées pour les PF.|
|
||||
|
||||
#### CT-03 — RUT mono-OS mixte (PC + picking terminé)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT libéré avec 1 SOR : 2 PC dans l'ASRS + 1 PP pickée → PF revenue à l'ASRS, aucun quai assigné.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|RUT éligible. 3 tâches de defrag générées (2 PC + 1 PF).|
|
||||
|
||||
#### CT-04 — RUT multi-OS, ordonnancement STOP respecté
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 3 SOR (STOP 1, 2, 3), chaque SOR a 2 PC, toutes revenues à l'ASRS, aucun quai assigné.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|6 tâches de defrag générées. Les palettes du STOP 3 entrent dans le canal en premier, STOP 1 en dernier (ordre inverse de sortie). Vérification via l'ordre de stockage du canal.|
|
||||
|
||||
#### CT-05 — RUT multi-OS, tous prêts simultanément
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 3 SOR : SOR1 = 2 PC, SOR2 = picking terminé (1 PF revenue), SOR3 = mixte (1 PC + 1 PF revenue). Toutes les palettes dans l'ASRS, aucun quai assigné.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|RUT éligible en un seul passage. 5 tâches de defrag générées, séquence STOP respectée.|
|
||||
|
||||
### 4.2 Cas limites
|
||||
|
||||
#### CT-06 — Un seul OS du RUT a une PP partie, PF pas encore revenue
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 2 SOR. SOR1 = 2 PC dans l'ASRS (prêt). SOR2 = 1 PP a quitté l'ASRS vers le PK, PF pas encore retournée. Aucun quai assigné.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**RUT NON éligible** (un OS bloque tout le RUT). Aucune tâche de défrag générée. Le RUT reste candidat pour le prochain passage.|
|
||||
|
||||
#### CT-07 — PF d'un OS encore sur AGV (en mouvement vers ASRS)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT multi-OS, toutes les palettes OK sauf une PF en transit sur AGV ou en Mov.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**RUT NON éligible** tant que la PF n'est pas physiquement stockée dans un emplacement ASRS. Éligible dès que le rangement est confirmé. (palette dans une emplacement du subwarehouse du magasin auto)|
|
||||
|
||||
#### CT-08 — Quai déjà assigné à la tournée
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT libéré, toutes palettes prêtes dans l'ASRS, **quai assigné** à la tournée.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu (standard)**|**RUT NON éligible pour le custom défrag.** Le flux shipping standard (avec defrag pour organiser par stop) prend le relais : les palettes partent directement vers l'image de quai dans le bon ordre.|
|
||||
|
||||
#### CT-9 — Picking partiel sur un OS (certaines lignes OK, d'autres en attente)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 1 SOR ayant 3 lignes picking : 2 PF revenues à l'ASRS, 1 PP toujours au PK.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**RUT NON éligible** (on attend la totalité des palettes de l'OS, donc de la tournée). Aucune tâche partielle.|
|
||||
|
||||
### 4.3 Cas dégradés
|
||||
|
||||
#### CT-11 — AGV HS pendant retour PF → ASRS
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|PF bloquée sur le PK ou en buffer suite à panne AGV. Les autres OS du RUT sont prêts.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**RUT NON éligible** tant que la PF n'est pas dans l'ASRS. Après remise en route et rangement, RUT redevient éligible au cycle suivant.|
|
||||
|
||||
#### CT-12 — Support sous révision
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|PP déplacée vers buffer litige, stock réassigné sur une autre palette (nouvelle PP').|
|
||||
|**Action**|Passage du job après que la nouvelle PP' ait été pickée et la PF' rangée à l'ASRS.|
|
||||
|**Résultat attendu**|RUT éligible dès que toutes les palettes (y compris les réassignations) sont dans l'ASRS. La palette en litige est ignorée.|
|
||||
|
||||
#### CT-13 — Rupture de stock sur un OS de la tournée (ATTENTE RETOUR CLIENT)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 2 SOR. SOR1 prêt, SOR2 avec 1 ligne en rupture.|
|
||||
|**Action**|Passage du job de défrag client|
|
||||
|**Résultat attendu**|**À trancher — voir point ouvert #1 ci-dessous.** Option A : RUT reste non éligible tant que rupture non résolue (blocage tournée) et on attend un nouveau SOR sans les lignes concernées ? Option B : RUT éligible pour les palettes disponibles, défrag lancée sur ce qui est présent.|
|
||||
|
||||
#### CT-14 — Modification de quantité en cours de picking (bouton « Problème »)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|Opérateur réduit la quantité pickée via le bouton Problème, workflow OnStockAdjust recalcule.|
|
||||
|**Action**|Passage du job après recalcul.|
|
||||
|**Résultat attendu**|- Si stock restant suffisant : PF revient à l'ASRS normalement, RUT éligible dès que tous les autres OS sont prêts. - Si réassignation nécessaire : RUT non éligible tant que la nouvelle PP' n'a pas été pickée et la PF' rangée.|
|
||||
|
||||
#### CT-15 — RUT libéré mais jamais de PP partie (cas figé)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT libéré depuis longtemps, aucune tâche de picking générée (ex : pas de PK disponible).|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**À trancher.** Par défaut RUT reste non éligible (picking pas encore déclenché ≠ palettes prêtes). Ne doit pas disqualifier par MAX_DEFRAG_ATTEMPT.|
|
||||
|
||||
#### CT-16 — Ajout d'un SOR à une tournée déjà éligible
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT initialement prêt (toutes palettes ASRS). Avant le passage du job, un nouveau SOR est ajouté au RUT avec des lignes picking non encore traitées.|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|**RUT redevient NON éligible** (le nouveau SOR n'a pas ses palettes prêtes). Éligible quand le nouveau SOR sera terminé à son tour.|
|
||||
|
||||
## 5. Points ouverts à arbitrer
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
|#|Sujet|Impact|
|
||||
|1|Comportement en cas de rupture de stock sur un OS de la tournée (CT-13). <br>@Justine Beutin check avec le clien|Définit si la défrag se lance sur les palettes disponibles ou bloque toute la tournée.|
|
||||
|2|Paramètre MAX_DEFRAG_ATTEMPT impacte la défrag client ou que la défrag par rotation ?|Si double impact, analyser quelle valeur lui mettre pour que le custom fonctionne.|
|
||||
|
||||
## 6. Rangement d’une tournée dans un canal VS un stop par canal
|
||||
|
||||
Dans cette tâche on a décidé qu’on attendait que toute la tournée soit prête pour la défrag dans un canal par numéro de stop (ou plusieurs canaux) et non de défrag chaque OS de la tournée sur un canal dédié.
|
||||
+258
@@ -0,0 +1,258 @@
|
||||
**Règle générale** : on n’envoie aucune palette sur l’image de quai tant que le picking n’est pas terminé (et que les palettes sont revenues à l’ASRS). Elles n’ont pas forcément besoin d’avoir été défragmentées ; si elles ont uniquement été rangées, via de la reloc, le WMS pourra quand même sortir les palettes dans le bon ordre des numéros de stop.
|
||||
1er custom imaginé : bloquer la génération des tâches de shipping tant que tout le picking n’a pas été fait (et empêcher la defrag si quai assigné)
|
||||
-> en réalité : pas de defrag si quai assigné, et pas besoin d’empêcher le shipping de cette manière, il suffit d’empêcher d’envoyer une palette qu n’a pas le bon numéro de stop dans la commande.
|
||||
Exemple du csutom à faire dans cette tâche
|
||||
J’ai déjà mes 3 premieres palettes de shipping dans l’ordre : le TK envoie les 3 premiers stop et envoie la palette de picking en parallèle au pk, dès qu’elle revient, il l’envoi, pui senvoie le reste de palettes de shipping etc.
|
||||
|
||||
Si un quai est déjà associé à l’OS lorsqu’il est lancé, **custom :** la palette de picking au PK ne pas pas aller à l’image de quai et doit rentrer à l’ASRS → standard finalement (à tester) le WF qui génère la tache de shipping depuis la Tp regarde si ya un quai assigné, si oui, cherche une route, si pas de route, créer une tâche de rangement (start rangement support client).
|
||||
Lors du rangement, le crossdock est OFF donc la palette se range bien (et ne repart pas direct du convoyeur au quai)
|
||||
|
||||
# 0. Résumé
|
||||
|
||||
La tâche gère le cas où un quai est déjà assigné à une tournée (RUT) et qu'il faut envoyer les palettes vers l'image de quai dans l'ordre inverse des STOP, y compris quand du picking est encore en cours.
|
||||
|
||||
Approche retenue : on laisse le standard générer les tâches de shipping au fil de l'eau (pas de blocage custom à la génération, c'est trop intrusif), et on **override partiellement le WF de tri du stacker crane** pour qu'il analyse la séquence STOP au niveau de **tous les TK** de la tournée (vs. un seul TK en standard) — pattern déjà éprouvé sur le projet Bardinet. Conséquence : une palette d'un STOP inférieur ne sort que si tous les STOP supérieurs sont déjà partis ; si une palette d'un STOP supérieur est encore au PK, les STOP inférieurs attendent en cascade.
|
||||
|
||||
Côté retour de picking : la palette client revient **systématiquement** dans l'ASRS (jamais de cross-dock direct vers l'image de quai), via une tâche de rangement générée par le standard quand aucune route vers le quai n'est disponible et avec crossdock OFF — à confirmer en recette, sinon custom de secours.
|
||||
|
||||
|
||||
|
||||
> **Références :**
|
||||
>
|
||||
> - Confluence : [Expédition](https://easywmsfrance.atlassian.net/wiki/spaces/LIM/pages/3001432145921/Exp+dition) — §4 Génération des tâches, §7 Cadencement des tâches
|
||||
>
|
||||
> - Tâche liéé : [LIM-87: #LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné #ATTENTE_CLIENT (CT-13)Attente déploiement pour test](https://easywmsfrance.atlassian.net/browse/LIM-87) (défrag custom quand quai **non** assigné — cas complémentaire)
|
||||
>
|
||||
> - Ressource : projet **Bardinet** — custom d'analyse de séquence multi-TK au niveau stacker crane
|
||||
>
|
||||
|
||||
---
|
||||
|
||||
## 1. Contexte
|
||||
|
||||
Cas de figure : **le quai est déjà assigné au RUT** quand la tournée est libérée (ou assigné avant la fin du picking, ou après).
|
||||
|
||||
Dans ce cas, LIM-87 (défrag custom) ne s'applique pas : c'est le flux shipping standard qui prend le relais pour envoyer les palettes vers l'image de quai. Il faut néanmoins respecter la **règle métier d'ordonnancement par n° de STOP** (ordre inverse : STOP max → STOP 1) pour que les palettes soient posées sur l'image de quai dans le bon ordre de chargement camion.
|
||||
|
||||
Le picking peut encore être en cours sur certaines lignes. On ne veut pas :
|
||||
|
||||
- Qu'une palette complète du STOP 1 parte vers l'image de quai alors que des palettes des STOP supérieurs ne sont pas encore prêtes (cela casse l'ordre de chargement) ;
|
||||
|
||||
- Qu'une palette fille (PF) sortant du PK aille en cross-dock direct vers l'image de quai si son STOP n'est pas encore « éligible ».
|
||||
|
||||
|
||||
### Ce qu'il ne faut pas faire (approche initiale abandonnée)
|
||||
|
||||
> Custom imaginé au départ : bloquer la génération des tâches de shipping tant que tout le picking n'est pas terminé.
|
||||
|
||||
Trop restrictif — on ne profiterait pas du temps pendant lequel les palettes complètes pourraient déjà être pré-positionnées sur l'image de quai dans l'ordre. Bloquer la génération de tâche n’est pas non plus simple. Il y a plein de process qui le font, et parfois ce ne sont pas des jobs ; donc si on les bloque ; les tâches se régénèrent jamais.
|
||||
|
||||
### Ce qu'on veut faire
|
||||
|
||||
Générer toutes les tâches de shipping **pour les palettes déjà prêtes** dès que le quai est assigné. Laisser le stacker crane (via son WF de tri) choisir **dans quel ordre** les exécuter en fonction des STOP et de la disponibilité physique des palettes des STOP supérieurs.
|
||||
|
||||
## 2. Objectif du custom
|
||||
|
||||
### 2.1 Comportement attendu
|
||||
|
||||
1. **Génération des tâches shipping** : standard. Dès que le quai est assigné, toutes les palettes prêtes (complètes dans l'ASRS + palettes filles revenues de picking) ont leur tâche de shipping générée. Une palette non encore pickée n'a pas de tâche — sa tâche sera créée au moment où elle rentrera dans un TK après picking.
|
||||
|
||||
2. **Ordonnancement d'exécution (stacker crane)** : le WF de tri des tâches applique la règle STOP max → STOP 1 avec blocage si un STOP supérieur a des palettes manquantes. Règle détaillée :
|
||||
|
||||
- Si toutes les palettes du STOP N+1 (et au-delà) sont déjà sorties de l'ASRS → les palettes du STOP N deviennent éligibles.
|
||||
|
||||
- Si un STOP supérieur a encore des palettes non prêtes (picking en cours) → on **bloque** les STOP inférieurs en attente.
|
||||
|
||||
- Dès qu'une palette manquante devient prête (PF rangée dans un TK) → sa tâche de shipping est créée et le stacker crane reprend le déroulé dans l'ordre.
|
||||
|
||||
3. **Retour palette fille du PK avec quai assigné** : la PF doit **retourner dans l'ASRS** et ne pas cross-docker vers l'image de quai. Ce comportement serait **standard** et repose sur le WF qui génère la tâche shipping depuis la TP du PK : s'il y a un quai assigné mais pas de route disponible vers l'image de quai , il crée une tâche de rangement avec les stratégies de rangement de support client. Crossdock OFF pour que la palette rentre bien dans l'ASRS. **À confirmer en recette.**
|
||||
|
||||
|
||||
### 2.2 Ce qui reste standard
|
||||
|
||||
- Génération des tâches de shipping.
|
||||
|
||||
- Mécanique de routage TP PK → ASRS même si palette demandée sur une image de quai (pas de crossdock).
|
||||
|
||||
- Le principe « le stacker crane force la sortie dans l'ordre strict des STOP pour les palettes prêtes ».
|
||||
|
||||
- Si pendant le picking l’opérateur déclare un problème sur un stock (statut de stock empêchant la prépa de commande) et que le stock reassign :
|
||||
|
||||
- ne trouve pas d’autres palettes, alors les palettes suivantes prêtes du STOP sont envoyées. Si un autre stock est retrouvé plus tard, le séquençage ne sera pas respecté mais le chargement camion devrait faire garde-fou.
|
||||
|
||||
- trouve une autre palette dispo, elle récupère le séquençage en cours et tout rentre dans l’ordre
|
||||
|
||||
|
||||
### 2.3 Ce qui est custom
|
||||
|
||||
- **Le tri du stacker crane doit considérer les palettes sur tous les TK** (pas uniquement celles dans un TK unique comme en standard). Custom déjà réalisé sur le projet Bardinet — à reprendre comme pattern.
|
||||
|
||||
|
||||
## 3. Solution retenue
|
||||
|
||||
### 3.1 Mécanisme
|
||||
|
||||
- **Override partiel** du WF de tri du stacker crane : insérer un filtre custom à l'endroit du tri, sur le même modèle que Bardinet.
|
||||
|
||||
- Le filtre analyse la séquence STOP **au niveau de tous les TK** (vision globale de la tournée) au lieu de se limiter à un seul TK comme le fait le standard.
|
||||
|
||||
- Pas de génération custom : on laisse le standard créer les tâches de shipping au fur et à mesure que les palettes deviennent prêtes.
|
||||
|
||||
|
||||
### 3.3 Points à valider en recette
|
||||
|
||||
- [ ] Vérifier en POC que le standard crée bien une tâche de rangement quand il n'y a pas de route vers l'image de quai. Sinon → prévoir un custom de secours.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. Cas de test
|
||||
|
||||
### Légende
|
||||
|
||||
- **PC** = palette complète (pas de picking nécessaire)
|
||||
|
||||
- **PP** = palette de picking (palette mère qui part au PK)
|
||||
|
||||
- **PF** = palette fille (sortie du picking, retour ASRS)
|
||||
|
||||
- **RUT** = tournée, **STOP** = numéro d'arrêt dans la tournée (ordre de livraison)
|
||||
|
||||
- **Éligible** = le WF de tri autorise la sortie de la palette du TK vers l'image de quai
|
||||
|
||||
- **Non éligible** = la tâche reste en attente, le stacker crane ne la prend pas
|
||||
|
||||
|
||||
### 4.1 Cas nominaux
|
||||
|
||||
#### CT-01 — RUT mono-STOP, toutes palettes prêtes
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 1 SOR, STOP 1, 3 PC assignées dans l'ASRS, quai assigné.|
|
||||
|**Action**|Libération du RUT.|
|
||||
|**Résultat attendu**|3 tâches de shipping générées. Les 3 palettes partent vers l'image de quai (pas de contrainte d'ordre inter-STOP).|
|
||||
|
||||
#### CT-02 — RUT multi-STOP sans picking, toutes palettes prêtes
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 3 SOR (STOP 1, 2, 3), chaque SOR a 2 PC dans l'ASRS, quai assigné.|
|
||||
|**Action**|Libération du RUT.|
|
||||
|**Résultat attendu**|6 tâches de shipping générées en une fois. Le stacker crane exécute d'abord les 2 palettes du STOP 3, puis les 2 du STOP 2, puis les 2 du STOP 1.|
|
||||
|
||||
#### CT-03 — RUT multi-STOP avec picking terminé avant libération
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 3 SOR, picking réalisé avant la libération, toutes PF revenues à l'ASRS, quai assigné.|
|
||||
|**Action**|Libération du RUT.|
|
||||
|**Résultat attendu**|Identique à CT-02. Le fait que certaines palettes soient des PF n'a aucune incidence — elles sont dans l'ASRS, le tri par STOP s'applique.|
|
||||
|
||||
### 4.2 Cas limites (coeur du custom)
|
||||
|
||||
#### CT-04 — Palette du STOP max encore en picking à la libération
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 3 SOR. STOP 3 = 1 PP au PK, PF pas revenue. STOP 2 et STOP 1 = toutes palettes dans l'ASRS. Quai assigné.|
|
||||
|**Action**|Libération du RUT, passage du job stacker crane.|
|
||||
|**Résultat attendu**|Les tâches de shipping pour les palettes des STOP 1 et 2 sont générées mais **non exécutées**. Pas de tâche pour la PF du STOP 3 (pas encore dans l'ASRS). Aucune palette ne part vers l'image de quai.|
|
||||
|
||||
#### CT-05 — PF du STOP max revient à l'ASRS, déblocage progressif
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|Suite du CT-04. La PF du STOP 3 revient du PK, est rangée dans un TK de l'ASRS.|
|
||||
|**Action**|Passage du job stacker crane.|
|
||||
|**Résultat attendu**|1. Tâche de shipping générée pour la PF du STOP 3.<br> <br>2. Elle devient éligible en premier (plus aucun STOP supérieur).<br> <br>3. Part vers l'image de quai.<br> <br>4. Puis les palettes du STOP 2 deviennent éligibles et partent.<br> <br>5. Puis celles du STOP 1.|
|
||||
|
||||
#### CT-06 — Palette de STOP intermédiaire en picking, blocage en cascade
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec 5 SOR (STOP 1 à 5). STOP 5 et 4 = toutes palettes ASRS. STOP 3 = 1 PP au PK. STOP 2 et 1 = toutes palettes ASRS. Quai assigné.|
|
||||
|**Action**|Libération du RUT.|
|
||||
|**Résultat attendu**|Les palettes du STOP 5 partent. Les palettes du STOP 4 partent. Les palettes du STOP 2 et STOP 1 sont **bloquées** (le STOP 3 n'est pas sorti). La PF du STOP 3 reviendra → rangement ASRS → tâche shipping générée → STOP 3 part → STOP 2 part → STOP 1 part.|
|
||||
|
||||
#### CT-07 — Plusieurs palettes sur un même STOP dont certaines en picking
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec STOP 3 contenant 4 palettes : 3 PC dans l'ASRS, 1 PP au PK (PF pas revenue). STOP 2 et 1 prêts. Quai assigné.|
|
||||
|**Action**|Libération du RUT, passage du job.|
|
||||
|**Résultat attendu**|Les 3 PC du STOP 3 partent vers l'image de quai. La 4e palette (PF attendue) n'a pas encore de tâche. **Les STOP 2 et 1 restent bloqués** tant que la 4e palette du STOP 3 n'est pas sortie. À son retour PK → ASRS → tâche shipping → sortie → puis STOP 2 débloqué.|
|
||||
|
||||
### 4.3 Retour PF du PK vers l'ASRS
|
||||
|
||||
#### CT-08 — PF revient du PK : rangement ASRS systématique
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec quai assigné, une PF arrive à la TP de sortie du PK. STOP de la PF quelconque (éligible ou non — sans importance).|
|
||||
|**Action**|WF de génération de tâche depuis la TP s'exécute.|
|
||||
|**Résultat attendu**|Tâche de rangement créée. Crossdock OFF. La PF rentre dans l'ASRS et est rangée dans un TK. **Aucun cross-dock direct vers l'image de quai depuis le PK, quel que soit le STOP.**|
|
||||
|
||||
### 4.4 Multi-tournées
|
||||
|
||||
#### CT-09 — Deux RUT en parallèle, quais distincts
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT A sur quai 1, RUT B sur quai 2. Chacun a plusieurs STOP avec palettes dans l'ASRS.|
|
||||
|**Action**|Libération simultanée des deux RUT.|
|
||||
|**Résultat attendu**|Chaque RUT est ordonnancé indépendamment. Pas de fuite de tri entre RUT A et RUT B. Les palettes de A partent vers quai 1 dans l'ordre des STOP de A ; idem pour B vers quai 2.|
|
||||
|
||||
#### CT-11 — Deux RUT, un seul quai libre (standard)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT A avec quai assigné, RUT B en attente (pas de quai libre).|
|
||||
|**Action**|Passage du job.|
|
||||
|**Résultat attendu**|RUT A traité normalement par le tri custom. RUT B reste hors périmètre du custom (pas de quai → relève de LIM-87 pour la défrag). **Vérifier** qu'il n'y a pas d'interférence entre les deux mécanismes.|
|
||||
|
||||
#### CT-12 — Ajout d'un SOR à une tournée en cours
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT en cours d'exécution, STOP 3 déjà parti, STOP 2 en cours. Un nouveau SOR est ajouté au RUT avec STOP 1 et des lignes picking.|
|
||||
|**Action**|Passage du job stacker crane après ajout.|
|
||||
|**Résultat attendu**|Les nouvelles palettes s'insèrent dans l'ordre STOP (ici STOP 1). Elles attendent la fin du STOP 2. Si le nouveau SOR nécessite du picking, les PF reviendront à l'ASRS (CT-08) puis seront éligibles une fois STOP 2 fini.|
|
||||
|
||||
#### CT-13 — Bascule de quai en cours de tournée
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec quai 1 assigné, certaines palettes déjà à l'image de quai 1. L'exploitation rebascule le RUT sur quai 2 (cas blocage/incident).|
|
||||
|**Action**|Passage du job après bascule.|
|
||||
|**Résultat attendu**|**À définir en recette.** Attendu : les tâches de shipping restantes sont regénérées vers l'image de quai 2. Les palettes déjà à l'image de quai 1 sont à traiter manuellement (hors périmètre custom). Le tri par STOP continue de s'appliquer pour les palettes restantes dans l'ASRS.|
|
||||
|
||||
### 4.4 Problème de stock au picking
|
||||
|
||||
#### CT-14 — Stock reassign ne trouve rien
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Élément|Valeur|
|
||||
|**Préconditions**|RUT avec quai 1 assigné, un SOR avec 3 STOP. STOP 3 déjà sur l’image de quai, une PP STOP 2 au PK. L’opérateur déclare un problème et la PP n’est plus assignée à la commande. Le stock reassign échoue à trouver un autre stock et la tâche de picking disparaît.|
|
||||
|**Résultat attendu**|La palette est ignorée par stacker_crane et on reprend l’ordre des stops.|
|
||||
|
||||
#### CT-15 — Stock reassign trouve une nouvelle palette
|
||||
|
||||
| | |
|
||||
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Élément | Valeur |
|
||||
| **Préconditions** | RUT avec quai 1 assigné, un SOR avec 3 STOP. STOP 3 déjà sur l’image de quai, une PP STOP 2 au PK. L’opérateur déclare un problème et la PP n’est plus assignée à la commande. Le stock reassign trouve une nouvelle palette dans l’ASRS et l’envoie au PK. |
|
||||
| **Résultat attendu** | La nouvelle palette récupère le stop de la palette remplacée et le séquençage n’est pas impacté. |
|
||||
+91
@@ -0,0 +1,91 @@
|
||||
# Tâche Jira — Intégration GNA LIMAGRAIN → SAP-CPI
|
||||
|
||||
## Contexte
|
||||
|
||||
Dans le cadre du projet Limagrain, le middleware GNA doit envoyer les messages WMS vers SAP via la plateforme SAP-CPI (middleware cloud). Une implémentation de référence existe chez un autre client (AD) mais communique avec un ERP SAPAIG via une API REST classique (OAuth password grant). L'intégration Limagrain est différente : elle cible SAP-CPI avec un endpoint unique et une authentification OAuth 2.0 client_credentials.
|
||||
|
||||
## Développement
|
||||
|
||||
### Périmètre fonctionnel
|
||||
|
||||
Le script CommonExportWebApi.boo doit :
|
||||
|
||||
1. **Authentification OAuth 2.0 client_credentials** — Obtenir un token bearer auprès du serveur SAP (/oauth/token) via POST avec client_id et client_secret. Le token doit être mis en cache sur disque (fichier JSON) avec gestion de l'expiration (marge de 60s).
|
||||
|
||||
2. **Envoi des messages WMS → SAP** — Pour chaque message WMS exporté, envoyer une requête POST vers l'endpoint unique SAP-CPI /http/ATHInboundMessage avec un body JSON structuré : {"MessageType": "<type>", "MessageSAP": "<code>", "data": <messages>}. Le MessageType permet au iFlow CPI de router le message. Le champ MessageSAP est déterminé par une table de correspondance entre le préfixe du MessageType WMS (3 premiers caractères) et le code SAP-CPI :
|
||||
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
|Code CPI|Équivalent WMS|
|
||||
|ATH214|Check flux retour (bacth)|
|
||||
|ATH215|ROF ou REF type == retour|
|
||||
|ATH217|REF type == supplier|
|
||||
|ATH201|LOC|
|
||||
|ATH202|LOF|
|
||||
|
||||
3. ATH217 — LOC ATH201 — LOF ATH202 —
|
||||
|
||||
Pour les messages REF, le MessageSAP dépend du type de préavis de réception (InboundOrder) lié. Le type est récupéré par le REF01Observer via une requête LINQ et transmis dans le champ RecCustomAttributes.CstAtt20 du message XML. Le script CommonExportWebApi.boo lit ce champ dans le payload JSON pour déterminer le MessageSAP.
|
||||
|
||||
Si un type de message n'a pas de correspondance, un warning est logué et le champ MessageSAP n'est pas inclus dans le body.
|
||||
|
||||
4. **Retry avec backoff exponentiel** — En cas d'échec HTTP (hors 401), réessayer avec un backoff exponentiel (2s, 4s, 8s, 16s). Un 401 doit provoquer un échec immédiat (token invalide).
|
||||
|
||||
5. **Logging détaillé** — Chaque étape (connexion, récupération token, envoi message) doit être loguée avec les détails de la requête et de la réponse. Le body JSON doit être logué en format indenté pour faciliter le debug. Le token ne doit jamais être logué.
|
||||
|
||||
|
||||
### Configuration requise (CommonAppSettings.config)
|
||||
|
||||
Six clés CPI_* à ajouter dans la section appSettings :
|
||||
|
||||
- **CPI_AUTH_URL** — URL du serveur d'authentification SAP OAuth
|
||||
|
||||
- **CPI_CLIENT_ID** — Identifiant OAuth
|
||||
|
||||
- **CPI_CLIENT_SECRET** — Secret OAuth (en clair dans le config)
|
||||
|
||||
- **CPI_ENDPOINT_URL** — Endpoint unique SAP-CPI
|
||||
|
||||
- **CPI_TOKEN_PATH** — Chemin du fichier cache token sur disque
|
||||
|
||||
- **CPI_TIMEOUT** — Timeout HTTP en secondes (auth + messages)
|
||||
|
||||
|
||||
5. **Détermination conditionnelle du MessageSAP pour REF** — Le type de préavis de réception (Supplier/Return) doit être récupéré dans le REF01Observer via une requête LINQ sur Context.RecLineInboundOrderLines → Context.InboundOrders, puis transmis dans le champ RecCustomAttributes.CstAtt20 du message REF01. Dans CommonExportWebApi.boo, le champ CstAtt20 est lu dans le payload JSON pour mapper REF → ATH215 (Supplier) ou ATH217 (Return).
|
||||
|
||||
|
||||
### Fichiers impactés
|
||||
|
||||
- Scripts2015/CommonExportWebApi.boo — Script principal d'export WMS → SAP-CPI
|
||||
|
||||
- Scripts2015/EasyWMS/XML/REF01/REF01Observer.boo — Ajout de la requête InboundOrderType et écriture dans CstAtt20
|
||||
|
||||
- Configuration/LIMAGRAI2512/CommonAppSettings.config — Ajout des 6 clés CPI_*
|
||||
|
||||
|
||||
### Cas de test
|
||||
|
||||
- [ ] Le GNA compile sans erreur
|
||||
|
||||
- [ ] L'authentification OAuth client_credentials fonctionne (HTTP 200)
|
||||
|
||||
- [ ] Le token est mis en cache sur disque et réutilisé tant qu'il est valide
|
||||
|
||||
- [ ] Les messages WMS sont envoyés en POST vers l'endpoint CPI avec le bon format JSON
|
||||
|
||||
- [ ] Le champ MessageSAP est présent dans le body JSON avec la bonne valeur (ATH215/ATH217/ATH201/ATH202 selon le type)
|
||||
|
||||
- [ ] Pour un REF de type Supplier, MessageSAP = ATH215
|
||||
|
||||
- [ ] Pour un REF de type Return, MessageSAP = ATH217
|
||||
|
||||
- [ ] Le champ CstAtt20 est renseigné dans le message REF01 par le REF01Observer
|
||||
|
||||
- [ ] Un warning est logué si le MessageType n'a pas de correspondance dans la table
|
||||
|
||||
- [ ] Le retry avec backoff fonctionne (hors 401)
|
||||
|
||||
- [ ] Les logs sont détaillés et lisibles (JSON indenté, token masqué)
|
||||
|
||||
- [ ] Un 401 provoque un échec immédiat sans retry
|
||||
@@ -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 |
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
share_link: https://share.note.sx/dxugiu3d#W1d5Ql4/dMtitMNhKtYgNc42AODqQYfrAZRU5sOPdUQ
|
||||
share_updated: 2026-02-06T09:49:41+01:00
|
||||
---
|
||||
|
||||
|
||||
# Limagrain
|
||||
|
||||
| Nom | Mail | Poste |
|
||||
| --------------------- | ----------------------------------- | ----------------------------------------------- |
|
||||
| Antoine MARTIN | antoine.martin@limagrain.com | Assistant CDP IT |
|
||||
| Xavier SUAREZ | xavier.suarez@limagrain.com | Nouveau CDP IT |
|
||||
| Emilie BERNARD | emilie.bernard@limagrain.com | Ancienne CDP IT |
|
||||
| Jean-Baptiste ROUVET | jean-baptiste.rouvet@limagrain.com | CDP OT |
|
||||
| Thierry CHANNEBOUX | thierry.channeboux@limagrain.com | CPG |
|
||||
| Nicolas SANCHEZ | nicolas.sanchez@limagrain.com | Expert IT |
|
||||
| Alexandre COUTURIER | alexandre.couturier@limagrain.com | |
|
||||
| Leila CHAJJAOUI | leila.chajjaoui@limagrain.com | Experte IT (équipe Nicolas SANCHEZ) |
|
||||
| Maxime TOURRETTE | maxime.tourrette@limagrain.com | Developpeur IT Expert |
|
||||
| Anne-Marie LARIVAILLE | anne-marie.larivaille@limagrain.com | Experte processus métier logistique |
|
||||
| David BONNAVENTURE | david.bonnaventure@limagrain.com | Responsable entrepôt (équipe Olivier SERINDAT) |
|
||||
| Olivier SERINDAT | olivier.serindat@limagrain.com | Responsable logistique |
|
||||
#### Phase de test
|
||||
![[Pasted image 20260413111131.png]]
|
||||
### Externes
|
||||
|
||||
| Nom | Mail | Poste |
|
||||
| ------------ | ------------------------------ | ------------------------------ |
|
||||
| Brice FOLIO | ext-brice.folio@limagrain.com | |
|
||||
| Cyril MALLET | ext-cyril.mallet@limagrain.com | Responsable Infra (gestion VM) |
|
||||
## Delaware (Middleware SAP)
|
||||
|
||||
| Nom | Mail | Poste |
|
||||
| ----------------- | ------------------------------ | --------------------- |
|
||||
| David RITTELMEYER | david.rittelmeyer@delaware.pro | Ancien chef de projet |
|
||||
|
||||
# Still
|
||||
|
||||
| Nom | Mail | Poste |
|
||||
| --------------- | ------------------------------ | ------------------------------- |
|
||||
| Yann RODRIGUES | Yann.RODRIGUES@still.fr | Ingénieur commercial |
|
||||
| | broumegoux@ceres-solutions.com | Responsable chantier (Batiment) |
|
||||
| Vincent DOITEAU | vincent.doiteau@kiongroup.com | Expert technique AGV |
|
||||
slim.benothman@harington.eu
|
||||
# Mecalux
|
||||
|
||||
| Nom | Poste |
|
||||
| -------------------------- | ------------------------------------------------------------- |
|
||||
| Justine BEUTIN | DP WMS |
|
||||
| Mallaury MELGAR | CPG |
|
||||
| Théo LE PAIH | CPG |
|
||||
| Abdallah BOUALLAG | **???** |
|
||||
| Hedi ABDELKRIM | Resp. Automatisme |
|
||||
| Robert Bryan BRAVO BALSECA | Technique - ROB - Espagne |
|
||||
| Gilles MAILLET | Dir. ROB |
|
||||
| Thierry AMEIL | Resp. Opérations chantier - ROB |
|
||||
| Adrian EGUZQUIZA | Référent technique WMS |
|
||||
| Antoine CREPIN MAILLET | Commercial grand compte - ROB |
|
||||
| Sefi FRANCO | Resp. ADV |
|
||||
| Franck MICHEL | Dir. Commerce + SAV - ROB |
|
||||
| Vincent DAMIEN | Resp. Electrique - ROB |
|
||||
| Yoan WINNYKAMEN | Resp. Design & Solution - ROB |
|
||||
| Henri DAHAN | Resp. IT - ROB |
|
||||
| Benjamin ANDRIEU | Resp. Pôle Technique - ROB |
|
||||
| Albert FORES | Engineering Manager (Espagne) |
|
||||
| Jordi CHILLON | Electrical Designer Engineer in Robotic Departament (Espagne) |
|
||||
| Saloua Cherif | Nouvelle recrue IT pole automatisme |
|
||||
| Slim Ben Othman | Référent technique service hurington Mecalux - Autom |
|
||||
| Arthur RIA | Chef de project technique EasyWMS |
|
||||
|
||||
+431
@@ -0,0 +1,431 @@
|
||||
## Choix de la table du PK pour chaque palette arrivant au PS
|
||||
|
||||
> **Version 1.0** — 27 avril 2026
|
||||
>
|
||||
> Ce document décrit l'algorithme exécuté par le WMS lorsqu'une palette source arrive au **PS (poste de sortie)** et que celui-ci demande au WMS **sur quelle table du PK** la poser.
|
||||
>
|
||||
> **Ce qui est hors périmètre** : l'ordre de sortie des palettes du TK, le tri par espèce/TC/quantité/poids, l'écriture des `Line.CstAtt` et `OS.CstAtt`. Tout cela est géré par un autre process (déclenché sur `TaskCreatedEvent` / `OutboundOrderReleasedEvent`). Ici, les palettes arrivent **déjà triées** au PS.
|
||||
|
||||
---
|
||||
|
||||
## 0. Rappel du contexte physique
|
||||
|
||||
Chaque PK dispose de **3 tables** soumises à une contrainte d'adjacence stricte :
|
||||
|
||||
```
|
||||
TABLE_GAUCHE ←→ TABLE_CENTRE ←→ TABLE_DROITE
|
||||
✅ adjacentes ✅ adjacentes
|
||||
|
||||
TABLE_GAUCHE ←————————————————→ TABLE_DROITE
|
||||
❌ INTERDIT
|
||||
```
|
||||
|
||||
**Règles de mouvement :**
|
||||
|
||||
- Le stock est **toujours sur une palette**, jamais directement posé sur la table.
|
||||
- L'opérateur peut déplacer du **stock** (sacs, colis) d'une palette à une autre **uniquement entre deux tables adjacentes**.
|
||||
- Il est **interdit de déplacer une palette d'une table à une autre**. Seul l'AGV peut déplacer une palette (arrivée, évacuation, recentrage).
|
||||
- **TABLE_CENTRE** est le pivot : c'est la seule table adjacente aux deux autres.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 1. Déclenchement
|
||||
|
||||
L'algorithme est appelé **à chaque fois qu'une palette arrive physiquement au PS**. Le PS interroge le WMS qui retourne une réponse parmi :
|
||||
|
||||
- **TABLE_GAUCHE**, **TABLE_CENTRE** ou **TABLE_DROITE** → la palette est envoyée sur cette table.
|
||||
- **Buffer ESx** → aucune table n'est disponible, la palette est redirigée vers un emplacement buffer.
|
||||
- **Attente** → ni table ni buffer disponible, la palette reste au PS.
|
||||
|
||||
---
|
||||
|
||||
## 2. Entrées de l'algorithme
|
||||
|
||||
| Donnée | Source |
|
||||
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
|
||||
| **Tâche courante** : palette source, article, quantité, type de picking (NÉGATIF / DIRECT), `Line.CstAtt` (numéro de séquence) | Tâche associée à la palette |
|
||||
| **État des 3 tables du PK cible** : VIDE, PALETTE_FILLE_ACTIVE, PALETTE_FILLE_EN_ATTENTE, PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE, EN_ATTENTE_EVACUATION | État temps réel du PK |
|
||||
| **Tâches suivantes de l'OS** (triées par `Line.CstAtt` croissant) | OS en base |
|
||||
| **Buffers ES disponibles** : parmi ES1–ES16, ceux qui ne sont ni occupés ni ciblés par une tâche en cours | État temps réel des buffers |
|
||||
| **Nombre de buffers déjà affectés à ce PK** vs `MAX_PRELOAD_PAR_PK` (défaut : 3) | Compteur par PK |
|
||||
| **Traitement commercial (TC)** de l'article et flag `CONTROLE_TRAITEMENT_COMMERCIAL` | Fiche article / paramètre WMS |
|
||||
|
||||
---
|
||||
|
||||
## 3. Décision de niveau 1 : table du PK ou buffer ?
|
||||
|
||||
```
|
||||
FONCTION décider_destination(palette, PK) :
|
||||
|
||||
table_cible ← choisir_table(palette, PK) // voir §4
|
||||
|
||||
SI table_cible ≠ NULL :
|
||||
RETOURNER table_cible
|
||||
|
||||
// Aucune table disponible → tenter un buffer
|
||||
SI nb_buffers_affectés(PK) < MAX_PRELOAD_PAR_PK :
|
||||
buffer ← premier ES libre (pas de palette, pas de tâche en vol)
|
||||
SI buffer existe :
|
||||
RETOURNER buffer
|
||||
|
||||
// Ni table ni buffer disponible
|
||||
RETOURNER ATTENTE
|
||||
// La palette reste au PS, le WMS réessaiera
|
||||
// dès qu'une place se libère (table ou buffer)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Décision de niveau 2 : choix de la table
|
||||
|
||||
Le choix dépend du **type de picking** de la tâche associée à la palette.
|
||||
|
||||
### 4.1. Cas PICKING_NÉGATIF
|
||||
|
||||
|
||||
En picking négatif, la palette source arrive sur une table, l'opérateur retire l'excédent sur une palette posée sur une **table adjacente**, puis échange d'étiquettes : la palette source devient la palette fille.
|
||||
|
||||
La palette a besoin de **2 tables** : une pour elle, une adjacente libre pour l'excédent.
|
||||
|
||||
```
|
||||
FONCTION choisir_table_picking_négatif(PK) :
|
||||
|
||||
// ─── Priorité 1 : centre + un côté libre ───
|
||||
// La palette source va au centre (pivot), l'excédent ira sur un côté.
|
||||
// Maximise la flexibilité : le centre est adjacent aux deux côtés.
|
||||
|
||||
SI TABLE_CENTRE == VIDE ET TABLE_GAUCHE == VIDE :
|
||||
RETOURNER TABLE_CENTRE
|
||||
|
||||
SI TABLE_CENTRE == VIDE ET TABLE_DROITE == VIDE :
|
||||
RETOURNER TABLE_CENTRE
|
||||
|
||||
// ─── Priorité 2 : côté + centre libre ───
|
||||
// Moins optimal (la palette source n'est pas au pivot)
|
||||
// mais fonctionnel si le centre est libre pour l'excédent.
|
||||
|
||||
SI TABLE_GAUCHE == VIDE ET TABLE_CENTRE == VIDE :
|
||||
RETOURNER TABLE_GAUCHE
|
||||
|
||||
SI TABLE_DROITE == VIDE ET TABLE_CENTRE == VIDE :
|
||||
RETOURNER TABLE_DROITE
|
||||
|
||||
// ─── Priorité 3 : centre libre + un côté libérable ───
|
||||
|
||||
SI TABLE_CENTRE == VIDE ET TABLE_GAUCHE est libérable :
|
||||
évacuer(TABLE_GAUCHE)
|
||||
RETOURNER TABLE_CENTRE
|
||||
|
||||
SI TABLE_CENTRE == VIDE ET TABLE_DROITE est libérable :
|
||||
évacuer(TABLE_DROITE)
|
||||
RETOURNER TABLE_CENTRE
|
||||
|
||||
// ─── Priorité 4 : un côté libre + centre libérable ───
|
||||
|
||||
SI TABLE_GAUCHE == VIDE ET TABLE_CENTRE est libérable :
|
||||
évacuer(TABLE_CENTRE)
|
||||
RETOURNER TABLE_GAUCHE
|
||||
|
||||
SI TABLE_DROITE == VIDE ET TABLE_CENTRE est libérable :
|
||||
évacuer(TABLE_CENTRE)
|
||||
RETOURNER TABLE_DROITE
|
||||
|
||||
// ─── Dernier recours : évacuation forcée ───
|
||||
évacuer_table_prioritaire(PK) // cf. §6
|
||||
RETOURNER choisir_table_picking_négatif(PK) // rappel récursif
|
||||
```
|
||||
### 4.2. Cas PICKING_DIRECT
|
||||
|
||||
En picking direct, la palette source doit être posée sur une table **adjacente à la palette fille active**. Le choix se fait donc en fonction de l'emplacement de la palette fille.
|
||||
|
||||
```
|
||||
FONCTION choisir_table_picking_direct(tâche, PK) :
|
||||
|
||||
// ─── Étape 1 : localiser la palette fille compatible ───
|
||||
table_fille ← localiser_palette_fille(tâche, PK) // cf. §4.3
|
||||
|
||||
SI table_fille == NULL :
|
||||
// Pas encore de palette fille → il faudra en créer une.
|
||||
// On anticipe son emplacement pour choisir la table source.
|
||||
table_fille ← choisir_table_pour_nouvelle_palette_fille(PK) // cf. §4.4
|
||||
|
||||
// ─── Étape 2 : choisir une table adjacente pour la palette source ───
|
||||
tables_adj ← tables_adjacentes(table_fille)
|
||||
// TABLE_GAUCHE → [TABLE_CENTRE]
|
||||
// TABLE_CENTRE → [TABLE_GAUCHE, TABLE_DROITE]
|
||||
// TABLE_DROITE → [TABLE_CENTRE]
|
||||
|
||||
// Prio A : la palette source est déjà sur une adjacente
|
||||
// (cas multi-tâches pour le même OS depuis la même palette)
|
||||
POUR chaque t DANS tables_adj :
|
||||
SI t contient tâche.PALETTE_SOURCE :
|
||||
RETOURNER t
|
||||
|
||||
// Prio B : adjacente VIDE
|
||||
// Si 2 adjacentes libres (PF au centre) → appliquer ping-pong (cf. §5)
|
||||
adjacentes_vides ← [t POUR t DANS tables_adj SI t == VIDE]
|
||||
SI len(adjacentes_vides) == 2 :
|
||||
RETOURNER choisir_côté_ping_pong(PK)
|
||||
SI len(adjacentes_vides) == 1 :
|
||||
RETOURNER adjacentes_vides[0]
|
||||
|
||||
// Prio C : adjacente en cours d'évacuation (AGV en route, bientôt libre)
|
||||
POUR chaque t DANS tables_adj :
|
||||
SI t == EN_ATTENTE_EVACUATION :
|
||||
RETOURNER t
|
||||
|
||||
// Prio D : forcer l'évacuation d'une adjacente
|
||||
t_à_libérer ← choisir_table_à_évacuer(tables_adj) // cf. §6
|
||||
évacuer(t_à_libérer)
|
||||
RETOURNER t_à_libérer
|
||||
```
|
||||
|
||||
### 4.3. Localisation de la palette fille compatible
|
||||
|
||||
```
|
||||
FONCTION localiser_palette_fille(tâche, PK) :
|
||||
|
||||
// Chercher d'abord parmi les PF actives
|
||||
POUR chaque table DANS [TABLE_GAUCHE, TABLE_CENTRE, TABLE_DROITE] :
|
||||
SI table.état == PALETTE_FILLE_ACTIVE :
|
||||
SI CONTROLE_TRAITEMENT_COMMERCIAL == false :
|
||||
RETOURNER table
|
||||
SINON SI table.palette.TC == tâche.article.TC :
|
||||
RETOURNER table
|
||||
|
||||
// Puis parmi les PF en attente (sera réactivée par l'exécution)
|
||||
POUR chaque table DANS [TABLE_GAUCHE, TABLE_CENTRE, TABLE_DROITE] :
|
||||
SI table.état == PALETTE_FILLE_EN_ATTENTE :
|
||||
SI CONTROLE_TRAITEMENT_COMMERCIAL == false
|
||||
OU table.palette.TC == tâche.article.TC :
|
||||
RETOURNER table
|
||||
|
||||
RETOURNER NULL // aucune palette fille compatible
|
||||
```
|
||||
|
||||
### 4.4. Choix de la table pour une nouvelle palette fille
|
||||
|
||||
```
|
||||
FONCTION choisir_table_pour_nouvelle_palette_fille(PK) :
|
||||
|
||||
// TABLE_CENTRE = pivot, adjacente aux 2 côtés → maximise la flexibilité
|
||||
SI TABLE_CENTRE == VIDE :
|
||||
RETOURNER TABLE_CENTRE
|
||||
|
||||
SI TABLE_GAUCHE == VIDE :
|
||||
RETOURNER TABLE_GAUCHE
|
||||
|
||||
SI TABLE_DROITE == VIDE :
|
||||
RETOURNER TABLE_DROITE
|
||||
|
||||
// Aucune table vide → forcer une évacuation
|
||||
évacuer_table_prioritaire(PK) // cf. §6
|
||||
RETOURNER choisir_table_pour_nouvelle_palette_fille(PK) // rappel récursif
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Optimisation ping-pong
|
||||
|
||||
Le ping-pong est l'optimisation principale pour le débit. Il n'est possible que lorsque la **palette fille est au centre** : les palettes sources alternent alors entre TABLE_GAUCHE et TABLE_DROITE, de sorte que la palette suivante est déjà en place quand l'opérateur termine.
|
||||
|
||||
```
|
||||
FONCTION choisir_côté_ping_pong(PK) :
|
||||
|
||||
// Identifier le côté actuellement occupé par une palette source
|
||||
SI TABLE_GAUCHE.état ∈ {PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE} :
|
||||
RETOURNER TABLE_DROITE // envoyer du côté opposé
|
||||
|
||||
SI TABLE_DROITE.état ∈ {PALETTE_SOURCE_EN_PICKING, PALETTE_SOURCE_EN_ATTENTE} :
|
||||
RETOURNER TABLE_GAUCHE // envoyer du côté opposé
|
||||
|
||||
// Aucun côté occupé → choix arbitraire
|
||||
RETOURNER TABLE_GAUCHE
|
||||
```
|
||||
|
||||
**Recentrage** : si la palette fille est sur un côté (issue d'un picking négatif), le ping-pong est impossible. Si le nombre de PICKING_DIRECT restants ≥ `SEUIL_RECENTRAGE_PF` (défaut : 3), le WMS peut déclencher un mouvement AGV pour recentrer la PF sur TABLE_CENTRE.
|
||||
|
||||
---
|
||||
|
||||
## 6. Évacuation des tables — Priorité
|
||||
|
||||
Lorsque aucune table n'est libre et qu'il faut en libérer une :
|
||||
|
||||
```
|
||||
FONCTION évacuer_table_prioritaire(PK) :
|
||||
|
||||
// 1. Palette vide → retrait manuel instantané (pas d'AGV)
|
||||
POUR chaque table :
|
||||
SI table contient palette VIDE :
|
||||
Opérateur retire manuellement → table = VIDE
|
||||
RETOURNER table
|
||||
|
||||
// 2. Table déjà en attente d'évacuation → AGV en route, attendre
|
||||
POUR chaque table :
|
||||
SI table.état == EN_ATTENTE_EVACUATION :
|
||||
Attendre fin du mouvement AGV
|
||||
RETOURNER table
|
||||
|
||||
// 3. Palette source en attente, non réutilisée par la prochaine tâche
|
||||
POUR chaque table :
|
||||
SI table.état == PALETTE_SOURCE_EN_ATTENTE
|
||||
ET table.palette ∉ prochaines_tâches_de_l_OS :
|
||||
Commander AGV : table → buffer ES ou ASRS
|
||||
RETOURNER table
|
||||
|
||||
// 4. Palette fille en attente → évacuer vers image de quai
|
||||
POUR chaque table :
|
||||
SI table.état == PALETTE_FILLE_EN_ATTENTE :
|
||||
Commander AGV : table → image de quai
|
||||
RETOURNER table
|
||||
|
||||
// 5. Palette source en attente (même si réutilisée) → buffer ES
|
||||
POUR chaque table :
|
||||
SI table.état == PALETTE_SOURCE_EN_ATTENTE :
|
||||
Commander AGV : table → buffer ES
|
||||
RETOURNER table
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Gestion des sorties buffer → PK
|
||||
|
||||
Quand une table se libère au PK, le WMS choisit parmi les palettes en buffer affectées à ce PK.
|
||||
|
||||
```
|
||||
FONCTION choisir_palette_buffer_vers_PK(PK, table_libérée) :
|
||||
|
||||
palettes_en_buffer ← toutes les palettes en ES affectées à ce PK
|
||||
|
||||
SI palettes_en_buffer est vide :
|
||||
RETOURNER NULL // rien en buffer
|
||||
|
||||
// Trier par Line.CstAtt croissant (plus petit = plus prioritaire)
|
||||
palettes_triées ← trier(palettes_en_buffer, par Line.CstAtt ASC)
|
||||
|
||||
// Prendre la palette avec la plus petite séquence
|
||||
// qui est compatible avec la table libérée
|
||||
POUR chaque palette DANS palettes_triées :
|
||||
SI compatible(palette, table_libérée, PK) :
|
||||
Commander AGV : buffer → table_libérée
|
||||
RETOURNER palette
|
||||
|
||||
RETOURNER NULL // attendre qu'une table compatible se libère
|
||||
```
|
||||
|
||||
**Règle critique** : l'ordre de sortie des buffers est dicté par `Line.CstAtt`, **pas** par l'ordre d'arrivée physique en buffer.
|
||||
|
||||
---
|
||||
|
||||
## 8. Palettes multi-commandes
|
||||
|
||||
Une palette source peut être assignée à plusieurs OS.
|
||||
|
||||
```
|
||||
Après picking de la commande en cours :
|
||||
SI palette a encore des tâches pour d'autres OS :
|
||||
→ Marquer palette = MULTI_COMMANDE
|
||||
→ Commander AGV : table → buffer ES libre
|
||||
→ La palette reste en buffer jusqu'au lancement de l'OS suivant
|
||||
|
||||
Calcul de capacité buffer :
|
||||
Une palette multi-commande au PK ou en mouvement compte
|
||||
comme une place buffer occupée dans le calcul de MAX_PRELOAD_PAR_PK.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Priorité d'accès aux buffers entre PK
|
||||
|
||||
Lorsque les buffers ES sont saturés :
|
||||
|
||||
```
|
||||
Priorité définie par la séquence du mode "Picking" dans MODES_PKxx (LIM-69).
|
||||
|
||||
Séquence 1 = priorité la plus haute.
|
||||
|
||||
Exemple :
|
||||
PK01 : PICKING;1 → priorité haute
|
||||
PK03 : PICKING;2 → priorité moyenne
|
||||
PK05 : PICKING;3 → priorité basse
|
||||
|
||||
Quand un buffer se libère :
|
||||
→ Affecté en priorité au PK avec la séquence la plus basse
|
||||
parmi ceux qui ont des palettes en attente.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. Paramètres WMS utilisés
|
||||
|
||||
|Paramètre|Description|Défaut|
|
||||
|---|---|---|
|
||||
|`MAX_PRELOAD_PAR_PK`|Nombre max de palettes pré-chargées en buffer ES par PK|3|
|
||||
|`SEUIL_RECENTRAGE_PF`|Nombre min de PICKING_DIRECT restants pour recentrer la PF au centre|3|
|
||||
|`CONTROLE_TRAITEMENT_COMMERCIAL`|Séparer ou non les articles par TC sur les palettes filles|`true`|
|
||||
|`MODES_PKxx`|Modes autorisés + priorité par PK (LIM-69)|—|
|
||||
|`PK_BIGBAG`|Autorise ou non les big-bags par PK (LIM-70)|—|
|
||||
|
||||
---
|
||||
|
||||
## 11. Diagramme de flux synthétique
|
||||
|
||||
```
|
||||
Palette arrive au PS (poste de sortie)
|
||||
Le PS demande au WMS : "sur quelle table ?"
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ Type de picking ? │
|
||||
└───┬────────────┬────┘
|
||||
│ │
|
||||
NÉGATIF DIRECT
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────┐ ┌──────────────────────────┐
|
||||
│ 2 tables │ │ Localiser palette fille │
|
||||
│ nécessaires: │ │ compatible (TC) │
|
||||
│ palette + │ │ │
|
||||
│ adjacente │ │ Si aucune → anticiper │
|
||||
│ pour excéd. │ │ position nouvelle PF │
|
||||
└──────┬───────┘ └─────────────┬────────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────┐ ┌──────────────────────────┐
|
||||
│ Prio 1: centre│ │ Choisir table adjacente │
|
||||
│ + côté │ │ à la PF : │
|
||||
│ │ │ - déjà occupée par PS ? │
|
||||
│ Prio 2: │ │ - VIDE ? (ping-pong) │
|
||||
│ côté + │ │ - en évacuation ? │
|
||||
│ centre │ │ - forcer évacuation │
|
||||
│ │ │ │
|
||||
│ Prio 3: │ └─────────────┬────────────┘
|
||||
│ évacuation │ │
|
||||
└──────┬───────┘ │
|
||||
│ │
|
||||
└────────┬───────────────┘
|
||||
│
|
||||
▼
|
||||
Table trouvée ?
|
||||
┌────┴────┐
|
||||
OUI NON
|
||||
│ │
|
||||
▼ ▼
|
||||
Palette → Buffer dispo
|
||||
table PK (< MAX_PRELOAD) ?
|
||||
┌────┴────┐
|
||||
OUI NON
|
||||
│ │
|
||||
▼ ▼
|
||||
Palette → Palette reste
|
||||
buffer ESx au PS (attente)
|
||||
|
||||
|
||||
═══════════════════════════════════════════
|
||||
|
||||
Quand une table se libère au PK :
|
||||
→ Chercher en buffer la palette avec
|
||||
le plus petit Line.CstAtt pour ce PK
|
||||
→ Commander AGV : buffer → table
|
||||
```
|
||||
+425
@@ -0,0 +1,425 @@
|
||||
# LIM-84 — Algorithme de séquençage des palettes (TK → PS)
|
||||
|
||||
## Ordonnancement des tâches de picking avant sortie de l'ASRS
|
||||
|
||||
> **Version 1.1** — 11 mai 2026
|
||||
>
|
||||
> Ce document décrit l'algorithme de séquençage qui définit **dans quel ordre** les palettes sources doivent sortir de l'ASRS (TK) à destination du poste de sortie (PS). Il s'exécute **en amont** de l'algorithme de placement PS → table PK [[Logique combinatoire picking - PS vers PK - V1.0]].
|
||||
>
|
||||
> Le résultat de cet algorithme est l'écriture des numéros de séquence `Line.CstAtt` sur chaque tâche de picking, et le positionnement de `OS.CstAtt = true` pour autoriser le stacker_crane à consommer les tâches.
|
||||
|
||||
### Changelog V1.1 (11/05/2026)
|
||||
|
||||
Modifications issues de la réunion Arthur + Justine (MECALUX) — Olivier (LIMAGRAIN), croisées avec l'AF et le DevOps #64854.
|
||||
|
||||
- **Hiérarchie des règles** : nouvel ordre de priorité validé (§3). La complétude palette et l'anti-split de lignes de stock sont désormais des contraintes amont prioritaires sur les règles de tri.
|
||||
- **Picking négatif** : ajout d'une condition cumulative de poids ≥ 7 kg (§3.1 + §6.3).
|
||||
- **Traitement commercial** : critère de regroupement par TC **supprimé** (`CONTROLE_TRAITEMENT_COMMERCIAL = false`). Le critère 3 de la V1.0 est retiré du tri.
|
||||
- **Calcul de remplissage** : méthode pro rata Bag/pal validée, remplace la logique DevOps "Bag/pal max" (§3 — contrainte amont C1).
|
||||
- **Poids max palette** : 1 250 kg (l'AF fait foi, corrige les 1 200 kg du DevOps).
|
||||
- **Règles confirmées** : mélange d'espèces OK, pas de gerbage, hauteur max 1,90 m, séparateurs inter-lots hors WMS.
|
||||
|
||||
---
|
||||
|
||||
## 0. Glossaire rapide
|
||||
|
||||
|Terme|Définition|
|
||||
|---|---|
|
||||
|**TK**|Transtockeur / sortie ASRS (origine physique de la palette)|
|
||||
|**PS**|Poste de sortie (point d'arrivée de la palette, avant placement sur table PK)|
|
||||
|**OS**|Ordre de sortie (commande)|
|
||||
|**OS.CstAtt**|Flag booléen sur l'OS. `false` = séquences non calculées, stacker_crane ignore. `true` = séquences prêtes, stacker_crane peut consommer.|
|
||||
|**Line.CstAtt**|Numéro de séquence (entier) sur chaque tâche de picking. Définit l'ordre de sortie ASRS. Plusieurs tâches peuvent partager la même valeur (ex-aequo).|
|
||||
|~~**TC**~~|~~Traitement commercial — attribut article.~~ **Supprimé V1.1** : `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt ne fait pas de bio. Paramètre réactivable si besoin futur.|
|
||||
|**Bag/pal**|Nombre de sacs par palette pour un lot donné. Sert au calcul de remplissage pro rata.|
|
||||
|
||||
---
|
||||
|
||||
## 1. Déclenchement
|
||||
|
||||
L'algorithme est déclenché sur **deux événements** :
|
||||
|
||||
### 1.1. `TaskCreatedEvent`
|
||||
|
||||
Une nouvelle tâche de picking vient d'être créée (par le MINI JOB Picking LIM-75, ou suite à une réassignation de stock).
|
||||
|
||||
```
|
||||
SI événement.type == TaskCreatedEvent :
|
||||
SI tâche.type == PICKING ET tâche.OS.statut == Released :
|
||||
traiter_séquençage(tâche.OS)
|
||||
```
|
||||
|
||||
### 1.2. `OutboundOrderReleasedEvent`
|
||||
|
||||
Un OS passe au statut Released (première mise en service, ou relance après un arrêt).
|
||||
|
||||
```
|
||||
SI événement.type == OutboundOrderReleasedEvent :
|
||||
traiter_séquençage(OS)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Process principal
|
||||
|
||||
```
|
||||
FONCTION traiter_séquençage(OS) :
|
||||
|
||||
// ─── Étape 1 : verrouiller l'OS ───
|
||||
OS.CstAtt ← false
|
||||
|
||||
// ─── Étape 2 : récupérer les tâches ───
|
||||
toutes_tâches ← récupérer_tâches_picking(OS)
|
||||
|
||||
// ─── Étape 3 : filtrer ───
|
||||
tâches_à_séquencer ← [t POUR t DANS toutes_tâches SI t.statut == EN_ATTENTE]
|
||||
|
||||
SI tâches_à_séquencer est vide :
|
||||
OS.CstAtt ← true
|
||||
RETOURNER
|
||||
|
||||
// ─── Étape 4 : trier ───
|
||||
tâches_triées ← trier_tâches(tâches_à_séquencer) // cf. §3
|
||||
|
||||
// ─── Étape 5 : écrire les séquences ───
|
||||
écrire_séquences(tâches_triées) // cf. §4
|
||||
|
||||
// ─── Étape 6 : libérer l'OS ───
|
||||
OS.CstAtt ← true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Contraintes amont et règles de tri
|
||||
|
||||
> **V1.1** — La hiérarchie ci-dessous remplace toute hiérarchie antérieure. Elle distingue les **contraintes amont** (appliquées avant/pendant la constitution des palettes filles) et les **règles de tri** (appliquées au séquençage des tâches de picking).
|
||||
|
||||
### Contraintes amont (constitution des palettes filles)
|
||||
|
||||
Ces contraintes orientent le regroupement des lignes sur les palettes filles **avant** que l'algorithme de tri ne séquence les sorties ASRS. Elles ne sont pas des critères de tri à proprement parler, mais l'algorithme de séquençage doit les respecter : l'ordre de sortie doit être compatible avec la constitution de palettes conformes à ces règles.
|
||||
|
||||
#### C1. Palettes les plus complètes possible
|
||||
|
||||
Objectif premier — optimisation transport. Seuil de remplissage ~95% (marge de sécurité).
|
||||
|
||||
**Calcul : pro rata Bag/pal.** Chaque sac consomme `1/Bag_pal` de son lot. Le calcul est additif et gère nativement des lots avec des Bag/pal différents sur une même palette.
|
||||
|
||||
```
|
||||
Exemple :
|
||||
16 sacs d'un lot Bag/pal 20 + 7 sacs d'un lot Bag/pal 50
|
||||
= 16/20 + 7/50
|
||||
= 0,80 + 0,14
|
||||
= 94%
|
||||
```
|
||||
|
||||
Regrouper les lots de même Bag/pal sur une même palette fille facilite la complétude.
|
||||
|
||||
> _Note : cette méthode remplace la logique DevOps #64854 de "prendre le Bag/pal max entre lots" (V1.0 implicite). Le pro rata est plus précis et ne nécessite pas de Bag/pal de référence unique._
|
||||
|
||||
#### C2. Ne pas splitter les lignes de stock
|
||||
|
||||
Éviter de répartir les sacs d'une même ligne de stock sur plusieurs palettes. **Cette contrainte est prioritaire sur les règles de tri** : si respecter "Maïs first" implique de splitter une ligne, on regroupe la ligne complète quitte à décaler le maïs.
|
||||
|
||||
#### Autres contraintes palette
|
||||
|
||||
|Contrainte|Valeur|Source|
|
||||
|---|---|---|
|
||||
|Poids max palette|**1 250 kg**|AF (corrige 1 200 kg du DevOps)|
|
||||
|Hauteur max palette|1,90 m|AF — rejet au PIE si dépassement|
|
||||
|Gerbage|Interdit|—|
|
||||
|Mélange d'espèces|Autorisé sur une même palette fille|—|
|
||||
|Différenciation de marque|Aucune dans une même expédition|—|
|
||||
|Séparateurs (intercalaires) entre lots|Règle opérateur, hors WMS|—|
|
||||
|
||||
### Règles de tri (séquençage des sorties ASRS)
|
||||
|
||||
Les tâches de picking d'un même OS sont triées selon les critères suivants, **par ordre de priorité décroissante** :
|
||||
|
||||
#### 3.1. Critère 1 — Picking négatif en premier
|
||||
|
||||
Les tâches de type PICKING_NÉGATIF passent **avant** les tâches de type PICKING_DIRECT.
|
||||
|
||||
Le picking négatif est **prioritaire sur toutes les règles de tri suivantes**, y compris Maïs first : si une tâche négatif concerne du tournesol, elle passe avant une tâche maïs classique.
|
||||
|
||||
> **V1.1** — Condition cumulative ajoutée pour la détermination NÉGATIF/DIRECT (cf. §6.3) : pourcentage quantité > seuil fiche article (défaut 55%) **ET** poids unitaire sac ≥ 7 kg. En dessous de 7 kg, pas de picking négatif (raison : instabilité palette si gros sacs ramenés sur petits sacs).
|
||||
|
||||
```
|
||||
tri_1(tâche) → 0 si PICKING_NÉGATIF, 1 si PICKING_DIRECT
|
||||
```
|
||||
|
||||
#### 3.2. Critère 2 — Espèce Maïs en premier
|
||||
|
||||
Les tâches portant sur l'espèce **Maïs** passent avant les autres espèces (si la commande contient du maïs).
|
||||
|
||||
Raison : le maïs est lourd/stable, il constitue la base de la palette fille.
|
||||
|
||||
```
|
||||
tri_2(tâche) → 0 si espèce == MAÏS, 1 sinon
|
||||
```
|
||||
|
||||
#### ~~3.3. Critère 3 — Regroupement par traitement commercial (TC)~~ **SUPPRIMÉ V1.1**
|
||||
|
||||
> `CONTROLE_TRAITEMENT_COMMERCIAL = false`. L'entrepôt ne fait pas de bio. Réactivable si besoin futur.
|
||||
|
||||
#### 3.3. Critère 3 — Espèce avec la plus grande quantité totale dans la commande
|
||||
|
||||
_(anciennement critère 4 en V1.0)_
|
||||
|
||||
Les tâches sont regroupées par espèce, et l'espèce ayant la **plus grande quantité totale de sacs** dans l'OS passe en premier.
|
||||
|
||||
Raison : commencer par l'espèce la plus volumineuse permet de constituer rapidement la base de la palette fille.
|
||||
|
||||
```
|
||||
tri_3(tâche) → -quantité_totale_espèce(tâche.espèce, OS)
|
||||
// négatif pour tri décroissant
|
||||
```
|
||||
|
||||
#### 3.4. Critère 4 — Article/lot le plus lourd en base
|
||||
|
||||
_(anciennement critère 5 en V1.0)_
|
||||
|
||||
À espèce égale, les tâches portant sur les articles/lots **les plus lourds** passent en premier.
|
||||
|
||||
Corollaire : les semences essais, très légères, se retrouvent naturellement en haut de palette.
|
||||
|
||||
```
|
||||
tri_4(tâche) → -tâche.article.poids
|
||||
// négatif pour tri décroissant
|
||||
```
|
||||
|
||||
#### 3.5. Critère 5 — Regroupement par palette source
|
||||
|
||||
_(anciennement critère 6 en V1.0)_
|
||||
|
||||
Toutes les tâches portant sur la **même palette source** sont consécutives.
|
||||
|
||||
Raison : l'opérateur enchaîne toutes les tâches d'une palette source avant de la libérer.
|
||||
|
||||
```
|
||||
tri_5(tâche) → tâche.PALETTE_SOURCE.identifiant
|
||||
```
|
||||
|
||||
### Récapitulatif du tri multi-critères (V1.1)
|
||||
|
||||
```
|
||||
FONCTION trier_tâches(tâches) :
|
||||
|
||||
RETOURNER tâches.trier_par(
|
||||
(1) type_picking ASC // NÉGATIF (0) avant DIRECT (1)
|
||||
(2) espèce_maïs ASC // MAÏS (0) avant autres (1)
|
||||
(3) quantité_espèce DESC // espèce la + volumineuse en premier
|
||||
(4) poids_article DESC // article le + lourd en premier
|
||||
(5) palette_source // regroupement par palette source
|
||||
)
|
||||
|
||||
// Note V1.1 : le critère TC (V1.0 §3.3) est supprimé.
|
||||
// La contrainte anti-split lignes de stock (C2) est gérée
|
||||
// en amont lors de la constitution des palettes filles,
|
||||
// pas dans ce tri.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Écriture des séquences (`Line.CstAtt`)
|
||||
|
||||
Une fois les tâches triées, on attribue un numéro de séquence à chacune.
|
||||
|
||||
### 4.1. Règle des ex-aequo
|
||||
|
||||
Quand deux tâches consécutives dans le tri sont **interchangeables** (l'ordre entre elles n'a aucun impact fonctionnel), elles reçoivent le **même numéro de séquence**. Cela laisse de la flexibilité au stacker_crane pour optimiser son débit.
|
||||
|
||||
### 4.2. Critères d'interchangeabilité
|
||||
|
||||
Deux tâches A et B sont interchangeables si :
|
||||
|
||||
- Elles portent sur la **même palette source**, **OU**
|
||||
- Elles portent sur des **palettes sources différentes** mais tous les critères de tri sont identiques : même type de picking, même espèce, même quantité espèce, même poids article. Rien ne les départage fonctionnellement.
|
||||
|
||||
> _Note V1.1 : le TC n'entre plus dans les critères d'interchangeabilité._
|
||||
|
||||
### 4.3. Algorithme d'écriture
|
||||
|
||||
```
|
||||
FONCTION écrire_séquences(tâches_triées) :
|
||||
|
||||
séquence_actuelle ← max(Line.CstAtt des tâches en cours) + 1
|
||||
SI aucune tâche en cours :
|
||||
séquence_actuelle ← 1
|
||||
|
||||
POUR i DE 0 À len(tâches_triées) - 1 :
|
||||
|
||||
tâche ← tâches_triées[i]
|
||||
tâche.Line.CstAtt ← séquence_actuelle
|
||||
|
||||
SI i < len(tâches_triées) - 1 :
|
||||
tâche_suivante ← tâches_triées[i + 1]
|
||||
|
||||
SI interchangeables(tâche, tâche_suivante) :
|
||||
CONTINUER
|
||||
SINON :
|
||||
séquence_actuelle ← séquence_actuelle + 1
|
||||
```
|
||||
|
||||
### 4.4. Exemple
|
||||
|
||||
```
|
||||
Commande avec 5 tâches, après tri :
|
||||
|
||||
Tâche 1 : Palette A, Maïs, 500kg → séq 1
|
||||
Tâche 2 : Palette B, Maïs, 500kg → séq 1 (interchangeable avec 1)
|
||||
Tâche 3 : Palette C, Maïs, 500kg → séq 1 (interchangeable)
|
||||
Tâche 4 : Palette D, Blé, 300kg → séq 2 (espèce différente)
|
||||
Tâche 5 : Palette E, Blé, 300kg → séq 2 (interchangeable avec 4)
|
||||
|
||||
Résultat Line.CstAtt : [1, 1, 1, 2, 2]
|
||||
|
||||
Le stacker_crane peut sortir les palettes A, B, C dans n'importe quel ordre,
|
||||
puis D ou E dans n'importe quel ordre.
|
||||
```
|
||||
|
||||
> _Note V1.1 : l'exemple V1.0 avec TC différent (tâche 6) est retiré car le critère TC est désactivé._
|
||||
|
||||
---
|
||||
|
||||
## 5. Comportement du stacker_crane après séquençage
|
||||
|
||||
Ce n'est pas le périmètre de cet algorithme, mais pour mémoire :
|
||||
|
||||
```
|
||||
Le stacker_crane :
|
||||
- IGNORE les tâches dont OS.CstAtt == false
|
||||
- Consomme les tâches dont OS.CstAtt == true
|
||||
- Respecte l'ordre croissant des Line.CstAtt
|
||||
- Entre tâches à séquence égale : libre d'optimiser (proximité ASRS, charge TK)
|
||||
- Crée les tâches de mouvement TK → PS
|
||||
```
|
||||
|
||||
Les palettes arrivent ensuite au PS, où l'algorithme de placement (document dédié) décide sur quelle table du PK les poser.
|
||||
|
||||
---
|
||||
|
||||
## 6. Cas particuliers
|
||||
|
||||
### 6.1. Recalcul suite à une nouvelle tâche (réassignation de stock)
|
||||
|
||||
Si une tâche est créée après que l'OS a déjà été séquencé, le `TaskCreatedEvent` déclenche un recalcul :
|
||||
|
||||
```
|
||||
1. OS.CstAtt ← false
|
||||
2. Filtrer : tâches EN_ATTENTE uniquement
|
||||
3. Re-trier et réécrire les Line.CstAtt
|
||||
(en commençant après le dernier numéro des tâches en cours)
|
||||
4. OS.CstAtt ← true
|
||||
```
|
||||
|
||||
### 6.2. Relance d'un OS arrêté
|
||||
|
||||
Si un OS est arrêté puis relancé (`OutboundOrderReleasedEvent`), le même process s'applique. Les tâches déjà en cours conservent leur séquence, les tâches en attente sont re-séquencées.
|
||||
|
||||
### 6.3. Picking négatif et détermination du type
|
||||
|
||||
Le type de picking (NÉGATIF ou DIRECT) est déterminé **par tâche** au moment de la création des tâches par le MINI JOB Picking (LIM-75), selon la règle :
|
||||
|
||||
```
|
||||
SI quantité_à_prélever > seuil_article × quantité_palette_source
|
||||
ET article unique dans la palette source
|
||||
ET pas d'attribut logistique à capturer
|
||||
ET poids_unitaire_sac ≥ 7 kg // ← AJOUT V1.1
|
||||
ALORS → PICKING_NÉGATIF
|
||||
SINON → PICKING_DIRECT
|
||||
```
|
||||
|
||||
> **V1.1** — La condition de poids ≥ 7 kg est ajoutée comme condition **cumulative** (ET). En dessous de 7 kg, pas de picking négatif même si le % dépasse le seuil. Raison : instabilité palette (gros sacs ramenés sur petits sacs).
|
||||
|
||||
Le seuil % reste paramétrable par fiche article (champ "Complete quantity percent excess for negative picking", défaut : 55%).
|
||||
|
||||
La détermination négatif/direct se fait **en amont** (MINI JOB Picking, LIM-75), avant l'algorithme de séquençage. L'algorithme de séquençage lit ce type mais ne le calcule pas.
|
||||
|
||||
---
|
||||
|
||||
## 7. Paramètres WMS utilisés
|
||||
|
||||
|Paramètre|Description|Défaut|Statut V1.1|
|
||||
|---|---|---|---|
|
||||
|`CONTROLE_TRAITEMENT_COMMERCIAL`|Active le regroupement par TC dans le tri|~~`true`~~|**`false`** — désactivé|
|
||||
|Seuil picking négatif|Par fiche article ("Complete quantity percent excess for negative picking")|55%|Inchangé|
|
||||
|Poids min picking négatif|Poids unitaire sac minimum pour autoriser le picking négatif|**7 kg**|**NOUVEAU V1.1**|
|
||||
|Seuil remplissage palette|Taux cible de remplissage palette fille|**~95%**|**NOUVEAU V1.1**|
|
||||
|Poids max palette|Poids maximum d'une palette fille|**1 250 kg**|Corrigé (était 1 200 kg dans DevOps)|
|
||||
|
||||
---
|
||||
|
||||
## 8. Diagramme de flux
|
||||
|
||||
```
|
||||
TaskCreatedEvent OutboundOrderReleasedEvent
|
||||
(nouvelle tâche picking) (OS passe en Released)
|
||||
│ │
|
||||
▼ │
|
||||
Tâche type PICKING │
|
||||
ET OS statut Released ? │
|
||||
│ │
|
||||
OUI │
|
||||
│ │
|
||||
└──────────┬────────────────────┘
|
||||
│
|
||||
▼
|
||||
OS.CstAtt ← false
|
||||
(stacker_crane bloqué)
|
||||
│
|
||||
▼
|
||||
Récupérer tâches de l'OS
|
||||
│
|
||||
▼
|
||||
Filtrer : tâches EN_ATTENTE uniquement
|
||||
(tâches en cours = intouchables)
|
||||
│
|
||||
▼
|
||||
┌────────────────────────────┐
|
||||
│ TRIER │
|
||||
│ │
|
||||
│ 1. Picking négatif first │
|
||||
│ 2. Espèce Maïs first │
|
||||
│ 3. Espèce + volumineuse │
|
||||
│ 4. Article + lourd │
|
||||
│ 5. Regrouper par palette │
|
||||
│ source │
|
||||
└────────────┬───────────────┘
|
||||
│
|
||||
▼
|
||||
Écrire Line.CstAtt
|
||||
(ex-aequo si interchangeables)
|
||||
│
|
||||
▼
|
||||
OS.CstAtt ← true
|
||||
(stacker_crane libéré)
|
||||
│
|
||||
▼
|
||||
Stacker_crane consomme
|
||||
par Line.CstAtt croissant
|
||||
→ crée mouvements TK → PS
|
||||
│
|
||||
▼
|
||||
Palette arrive au PS
|
||||
→ algo de placement PS → PK
|
||||
(autre document)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Points non traités (hors scope)
|
||||
|
||||
- Affichage opérateur au PK (combien de sacs ajouter, possibilité de dévier de la consigne) — à traiter une fois les fondations posées.
|
||||
- Picking négatif < 7 kg en option (avantage opérationnel sans obligation) — nécessite discussion élargie.
|
||||
- Messagerie carton (moins prioritaire que prépa classique, navette du lendemain, zone angle Est) — en attente de précisions.
|
||||
- Verrou réception → recomptage avant picking (mentionné dans l'AF uniquement, non reconfirmé).
|
||||
|
||||
---
|
||||
|
||||
## 10. Sources de référence
|
||||
|
||||
Par ordre de fiabilité décroissante :
|
||||
|
||||
1. **Réunion 11/05/2026 + mails** — fait foi sur tous les points traités
|
||||
2. **AF (Analyse Fonctionnelle)** — référence principale pour les points non abordés en réunion
|
||||
3. **DevOps #64854** — le plus ancien, peut contenir des règles passées à la trappe mais utile pour vérification croisée
|
||||
@@ -0,0 +1,12 @@
|
||||
# Organisation d'un projet Robotique
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874)
|
||||
> Dernière mise à jour : 25/03/2024 (v1)
|
||||
|
||||
---
|
||||
|
||||
Les projets avec installation mécanisée (miniload, TK, convoyeur…) nécessitent l'intervention de différents acteurs au sein de Mecalux : chef de chantier, chef de projet IT, responsable électricité…
|
||||
|
||||
Tous ces acteurs sont pilotés par un **Responsable de projet** qui coordonne les intervenants, s'assure de la bonne tenue des plannings et garantit que tous ont le bon niveau d'information.
|
||||
|
||||
> ℹ️ La page Confluence contient un schéma d'organisation type d'un projet Robotique (diagramme des acteurs et responsabilités). Se référer à Confluence pour l'illustration.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Plan de tests des stations
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000584536089)
|
||||
> Dernière mise à jour : 25/07/2024 (v7)
|
||||
|
||||
---
|
||||
|
||||
Afin de s'assurer que le WMS et GALILEO ont une configuration équivalente et que tous les mouvements définis dans l'AF sont possibles, il est nécessaire de **synchroniser les 2 logiciels** sur les noms et types de stations ainsi que les routes possibles.
|
||||
|
||||
---
|
||||
|
||||
## Types de support et type de hauteur
|
||||
|
||||
Tout support devant être inséré dans un transstockeur doit passer par un **PIE**, qui calibre le support.
|
||||
|
||||
Galileo envoie au WMS :
|
||||
- Code barres lu
|
||||
- **Type de support** (PLC Container Type)
|
||||
- **Type de hauteur du support** (PLC Height Type)
|
||||
|
||||
Ces types sont définis dans EasyS via le menu **PLC Types**.
|
||||
|
||||
> ⚠️ Pour les miniloads, le type de bac et la hauteur du bac sont souvent liés. Si GALILEO lit `PLCHeightType = 1`, le `PLCType` doit aussi être `1`. Le préciser dans le document d'interface.
|
||||
|
||||
---
|
||||
|
||||
## Récupération des stations dans le WMS
|
||||
|
||||
Query LINQ à exécuter sur la **writing** :
|
||||
|
||||
```csharp
|
||||
Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo")
|
||||
.Select(sr => new {
|
||||
StationType = sr.StationTo.Type,
|
||||
StationNumber = sr.StationTo.Number,
|
||||
StationCode = sr.StationTo.Code,
|
||||
StationTypeName = sr.StationTo.Type.ToString(),
|
||||
X = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
|
||||
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.X : 0,
|
||||
Y = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
|
||||
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Y : 0,
|
||||
StationSide = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
|
||||
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0,
|
||||
AisleNumber = sr.StationTo.AisleNumber
|
||||
})
|
||||
// ... (union avec StationFrom, voir page Confluence pour requête complète)
|
||||
.OrderBy(sr => sr.StationType)
|
||||
.ThenBy(sr => sr.StationNumber)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Définition des routes pleines
|
||||
|
||||
GALILEO doit remonter l'état des routes entre 2 stations. Les routes suivantes doivent pouvoir être remontées comme **pleines** :
|
||||
|
||||
| Type de station d'origine | Type de station d'arrivée |
|
||||
|--------------------------|--------------------------|
|
||||
| CME | TE |
|
||||
| PKE | PK |
|
||||
| ET | PS |
|
||||
@@ -0,0 +1,13 @@
|
||||
# Planning Installation Miniload
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477)
|
||||
> Dernière mise à jour : 12/07/2024 (v2)
|
||||
|
||||
---
|
||||
|
||||
Cette page contient deux plannings de référence pour une installation Miniload :
|
||||
|
||||
1. **Planning global d'une installation Miniload** — vue d'ensemble de toutes les phases du projet
|
||||
2. **Planning d'une installation Miniload — partie IT ROB** — phases spécifiques à l'équipe IT Robotique
|
||||
|
||||
> ℹ️ Les deux plannings sont des fichiers images disponibles sur [Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Se référer à Confluence pour consulter les Gantt détaillés.
|
||||
@@ -0,0 +1,316 @@
|
||||
# Premier déploiement
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088396042/Premier+d%C3%A9ploiement)
|
||||
> Dernière mise à jour : 07/08/2025 (v39)
|
||||
|
||||
---
|
||||
|
||||
### 1 - Vérifier le fichier "DeployConfig.yaml"
|
||||
|
||||
Aller dans le dossier **`build`** du répertoire GIT du projet. Vous devez y trouver un fichier `DeployConfig.yaml`, sinon le télécharger et l'y placer.
|
||||
|
||||
**Vérifier les champs suivants :**
|
||||
|
||||
- **TenantName / TenantCode** — nom et code de l'application souhaitée :
|
||||
|
||||
```yaml
|
||||
TenantName: MonNomProjet
|
||||
TenantCode: MonCodeProjet
|
||||
```
|
||||
|
||||
- **DBEngine** — moteur de base de données (doit correspondre à celui défini dans `env.secrets.yaml` situé dans `C:\deploy` de la VM) :
|
||||
|
||||
```yaml
|
||||
DBEngine: Oracle # SQLServer, MySQL, Oracle, PostgreSQL
|
||||
```
|
||||
|
||||
- **MAPSeed** — dernière version WMS [disponible ici](https://msscc.mecalux.com/documentation/documentation/master/EN/ReleaseNotes.md) :
|
||||
|
||||
```yaml
|
||||
MAPSeed: 22.9.19.1 # Any version published on mapdeploy.mecalux.com
|
||||
```
|
||||
|
||||
- **License** — doit être défini à `ENTERPRISE` :
|
||||
|
||||
```yaml
|
||||
License: ENTERPRISE # PRO, ADVANCE, ENTERPRISE
|
||||
```
|
||||
|
||||
- **Warehouse** — chemin d'accès au fichier de configuration de l'entrepôt (normalement dans `layout_config`) :
|
||||
|
||||
```yaml
|
||||
Warehouse: layout_config/MAPAB_layout.cfg2014 # [OPTIONAL] Relative path to the layout file
|
||||
```
|
||||
|
||||
- **Data** — chemin d'accès aux fichiers de configuration du WMS (normalement dans `test`) :
|
||||
|
||||
```yaml
|
||||
Data: test # [OPTIONAL] Relative path to the folder that has the data for uGNA
|
||||
```
|
||||
|
||||
- **StandardApplications** — applications souhaitées selon l'analyse fonctionnelle (reprendre les entrées `Use="Yes"` de la balise `<ExtraApps>` du fichier `responses.xml`) :
|
||||
|
||||
```yaml
|
||||
StandardApplications: # The applications to install, listed with the same names as in the responses.xml
|
||||
- SmartUI
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>Exemple de responses.xml correspondant</summary>
|
||||
|
||||
```xml
|
||||
<ExtraApps>
|
||||
<Item Use="Yes" Name="SmartUI" ... />
|
||||
<Item Use="No" Name="AccountDirective" ... />
|
||||
<Item Use="No" Name="Billing" ... />
|
||||
<Item Use="No" Name="CashAndCarry" ... />
|
||||
<Item Use="No" Name="Dashboard" ... />
|
||||
<Item Use="No" Name="Deliveries" ... />
|
||||
<Item Use="No" Name="Ecommerce" ... />
|
||||
<Item Use="No" Name="ExternalDevices" ... />
|
||||
<Item Use="No" Name="GalileoFaults" ... />
|
||||
<Item Use="No" Name="LaborManagement" ... />
|
||||
<Item Use="No" Name="Manufacturing" ... />
|
||||
<Item Use="No" Name="OwnerExtensions" ... />
|
||||
<Item Use="No" Name="PalletShuttle" ... />
|
||||
<Item Use="No" Name="Sage200c" ... />
|
||||
<Item Use="No" Name="Slotting" ... />
|
||||
<Item Use="No" Name="TPLPortal" ... />
|
||||
<Item Use="No" Name="ValueAddedService" ... />
|
||||
<Item Use="No" Name="YardManagement" ... />
|
||||
</ExtraApps>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- **Customs** — laisser vide pour l'instant (sera renseigné à l'étape 10) :
|
||||
|
||||
```yaml
|
||||
Customs: # [OPTIONAL] Relative path to the custom applications exported as text
|
||||
```
|
||||
|
||||
- **EnaledModules** — liste de tous les modules à activer (reprendre la balise `<Modules>` du `responses.xml`, **sauf `EasyWMS`** qui est inclus de base) :
|
||||
|
||||
> ⚠️ **Problème connu sur les versions 24.xx.xx.xx** : l'action *"Importing apps with AD..."* peut durer très longtemps et être suivie d'une erreur `System.Management.Automation.RuntimeException`. Dans ce cas, ajouter `ToggleService` à la liste.
|
||||
|
||||
```yaml
|
||||
EnabledModules:
|
||||
- SmartUI
|
||||
- AccountDirective
|
||||
- Billing
|
||||
- CashAndCarry
|
||||
- Dashboard
|
||||
- Deliveries
|
||||
- Ecommerce
|
||||
- GalileoFaults
|
||||
- LaborManagement
|
||||
- Manufacturing
|
||||
- MarketPlace
|
||||
- OwnerExtensions
|
||||
- PalletShuttle
|
||||
- Sage200c
|
||||
- SageX3
|
||||
- Slotting
|
||||
- TPLPortal
|
||||
- ValueAddedService
|
||||
- YardManagement
|
||||
- EDSService
|
||||
- ExternalDevices
|
||||
- GalileoDesigner
|
||||
- Gateway
|
||||
- GNA
|
||||
- PrinterService
|
||||
- PTLService
|
||||
- PalletShuttleService
|
||||
- VoicePicking
|
||||
- ToggleService # Needed in version >24.XX.XX.XX
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>Exemple de responses.xml correspondant</summary>
|
||||
|
||||
```xml
|
||||
<Modules>
|
||||
<Module Name="EasyWMS" LicenseLevel="ENTERPRISE" />
|
||||
<Module Name="SmartUI" LicenseLevel="ENABLED" />
|
||||
<Module Name="AccountDirective" LicenseLevel="ENABLED" />
|
||||
<Module Name="Billing" LicenseLevel="ENABLED" />
|
||||
<Module Name="CashAndCarry" LicenseLevel="ENABLED" />
|
||||
<Module Name="Dashboard" LicenseLevel="ENABLED" />
|
||||
<Module Name="Deliveries" LicenseLevel="ENABLED" />
|
||||
<Module Name="Ecommerce" LicenseLevel="ENABLED" />
|
||||
<Module Name="GalileoFaults" LicenseLevel="ENABLED" />
|
||||
<Module Name="LaborManagement" LicenseLevel="ENABLED" />
|
||||
<Module Name="Manufacturing" LicenseLevel="ENABLED" />
|
||||
<Module Name="MarketPlace" LicenseLevel="ENABLED" />
|
||||
<Module Name="OwnerExtensions" LicenseLevel="ENABLED" />
|
||||
<Module Name="PalletShuttle" LicenseLevel="ENABLED" />
|
||||
<Module Name="Sage200c" LicenseLevel="ENABLED" />
|
||||
<Module Name="SageX3" LicenseLevel="ENABLED" />
|
||||
<Module Name="Slotting" LicenseLevel="ENABLED" />
|
||||
<Module Name="TPLPortal" LicenseLevel="ENABLED" />
|
||||
<Module Name="ValueAddedService" LicenseLevel="ENABLED" />
|
||||
<Module Name="YardManagement" LicenseLevel="ENABLED" />
|
||||
<Module Name="EDSService" LicenseLevel="ENABLED" />
|
||||
<Module Name="ExternalDevices" LicenseLevel="ENABLED" />
|
||||
<Module Name="GalileoDesigner" LicenseLevel="ENABLED" />
|
||||
<Module Name="Gateway" LicenseLevel="ENABLED" />
|
||||
<Module Name="GNA" LicenseLevel="ENABLED" />
|
||||
<Module Name="PrinterService" LicenseLevel="ENABLED" />
|
||||
<Module Name="PTLService" LicenseLevel="ENABLED" />
|
||||
<Module Name="PalletShuttleService" LicenseLevel="ENABLED" />
|
||||
<Module Name="VoicePicking" LicenseLevel="ENABLED" />
|
||||
</Modules>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- **Users** — laisser vide pour ne garder que l'utilisateur `mecalux` par défaut, ou définir des utilisateurs supplémentaires :
|
||||
|
||||
```yaml
|
||||
Users: # [OPTIONAL] "mecalux" user can be overwritten
|
||||
- UserName:
|
||||
Password: UserPassword
|
||||
Groups: SuperAdmin,Administrators,Managers,Operators
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2 - Déplacer le fichier de config entrepôt
|
||||
|
||||
Placer le fichier de configuration de l'entrepôt EasyS dans le dossier **`layout_config`** du répertoire GIT du projet.
|
||||
|
||||
> ⚠️ Ne pas oublier de **commit et push** le répertoire Git.
|
||||
|
||||
---
|
||||
|
||||
### 3 - Vérifier le fichier "env.secrets.yaml" du dossier Deploy (sur la VM)
|
||||
|
||||
Vérifier les informations concernant la base de données utilisée sur le projet :
|
||||
|
||||
| Paramètre | Valeur par défaut |
|
||||
|-----------|-------------------|
|
||||
| `Engine` | `Oracle` |
|
||||
| `Server` | `localhost/orcl` |
|
||||
| `Password` (des différentes bases) | `robmec` |
|
||||
|
||||
---
|
||||
|
||||
### 4 - Déploiement complet
|
||||
|
||||
Ouvrir **PowerShell en administrateur** dans le dossier `Deploy` de la VM et exécuter :
|
||||
|
||||
```powershell
|
||||
# Déploiement sur la branche Master (par défaut)
|
||||
.\deploy_repository.ps1 NomDuProjetGit
|
||||
|
||||
# Déploiement sur une branche spécifique
|
||||
.\deploy_repository.ps1 NomDuProjetGit Branche
|
||||
```
|
||||
|
||||
Exemple pour le projet `Ma_Pieces_Autos_Bretagne` :
|
||||
|
||||
```powershell
|
||||
.\deploy_repository.ps1 1707_FRANCE_MA_PIECES_AUTOS_BRETAGNE
|
||||
```
|
||||
|
||||
> Plus de détails sur l'exécution du script : [Documentation Mecalux](https://mssdoc.mecalux.com/en_US/my_documentation/doc/ExternalProcedures/master/ProfessionalServices/TaskWorkBreakDownAndVerification/TaskWorkBreakdownAndVerification.md#md-deployscriptfordevelopmentenvironments)
|
||||
|
||||
**Cas d'erreurs classiques :**
|
||||
|
||||
- **VM non connectée à internet** : lancer Internet Explorer pour se connecter à Zscaler.
|
||||
- ⚠️ VPN **désactivé** si vous êtes au bureau. VPN **actif** en télétravail.
|
||||
- **Git non installé** sur la VM : [https://git-scm.com/download/win](https://git-scm.com/download/win)
|
||||
- Autres erreurs : consulter la page [Installation machine virtuelle de développement](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/2786690269319) au paragraphe **"Deploy 1"**.
|
||||
|
||||
> ✅ Sans erreur, vous pouvez **sauter les étapes 5, 6 et 7**.
|
||||
|
||||
---
|
||||
|
||||
### 5 - Deploy 1 *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans le dossier `Deploy` de la VM et exécuter :
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1
|
||||
```
|
||||
|
||||
Choisir **"1. Complete"**.
|
||||
|
||||
> En cas d'erreur : consulter la page [Installation machine virtuelle de développement](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/2786690269319) au paragraphe **"Deploy 1"**.
|
||||
|
||||
---
|
||||
|
||||
### 6 - Intégrer la configuration d'entrepôt *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans le dossier `Deploy` de la VM et exécuter :
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1
|
||||
```
|
||||
|
||||
Choisir **"2. Load"**.
|
||||
|
||||
Cela transfèrera :
|
||||
- La configuration entrepôt depuis **`C:\deploy\Config`**
|
||||
- Les paramètres exportés via uGNA depuis **`C:\deploy\Data`**
|
||||
|
||||
> Il est également possible d'utiliser **EasyS** pour charger le fichier de config via un *Transfert Data* vers la VM.
|
||||
|
||||
---
|
||||
|
||||
### 7 - Assignation de l'utilisateur à l'entrepôt *(anciens scripts de deploy uniquement)*
|
||||
|
||||
Ouvrir PowerShell en administrateur dans **`C:\deploy`** et exécuter :
|
||||
|
||||
```powershell
|
||||
.\Commands\commands.ps1
|
||||
```
|
||||
|
||||
Il est aussi possible de faire l'assignation via le WMS : dans **SmartUI**, aller dans **"Organisation"** → **"Utilisateurs"**, sélectionner l'utilisateur (par défaut `mecalux`) et l'éditer pour ajouter les sites autorisés.
|
||||
|
||||
---
|
||||
|
||||
### 8 - Désactiver les instances stockées sur la base de données
|
||||
|
||||
Dans le fichier **`Tenants.xml`** situé dans `C:\inetpub\wwwroot\ApplicationService`, remplacer la ligne :
|
||||
|
||||
```xml
|
||||
<processStore name="TENANT ProcessStore" providerName="Oracle.ManagedDataAccess.Client" … />
|
||||
```
|
||||
|
||||
par :
|
||||
|
||||
```xml
|
||||
<processStore name="TENANT ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>
|
||||
```
|
||||
|
||||
Puis effectuer un redémarrage de l'application (`iisreset` ou recyclage du pool de l'ApplicationService).
|
||||
|
||||
> ⚠️ Sans cette modification, les instances ne fonctionneront pas.
|
||||
|
||||
---
|
||||
|
||||
### 9 - Créer l'application custom
|
||||
|
||||
Procéder à la création de l'application custom avec l'export sur le GIT.
|
||||
|
||||
> Voir : [Gestion de la custom application — Création](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000089673775/Gestion+de+la+custom+application#1---Cr%C3%A9ation-de-l%E2%80%99application-custom)
|
||||
|
||||
---
|
||||
|
||||
### 10 - Mettre à jour le fichier "DeployConfig.yaml"
|
||||
|
||||
Ajouter le chemin de l'application custom dans le fichier **`DeployConfig.yaml`** (dossier `build` du projet GIT) :
|
||||
|
||||
```yaml
|
||||
Customs: # [OPTIONAL] Relative path to the custom applications exported as text
|
||||
- NomApplication: chemin/du/dossier/GIT/de/lapplication
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```yaml
|
||||
Customs:
|
||||
- CustomApplication: source/CustomApplication
|
||||
```
|
||||
@@ -0,0 +1,131 @@
|
||||
# Présentation GALILEO
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000580866089)
|
||||
> Dernière mise à jour : 23/07/2024 (v2)
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
GALILEO est le système automatisme (TMS) qui pilote physiquement les convoyeurs, transstockeurs et autres machines. EasyWMS fait le travail d'intelligence — GALILEO ne fait que demander des ordres et les exécuter.
|
||||
|
||||
---
|
||||
|
||||
## Stations
|
||||
|
||||
Les stations sont des emplacements physiques (convoyeurs, navettes, transstockeurs…) ou virtuels qui permettent à GALILEO d'informer EasyWMS de la position d'un conteneur. Elles sont codifiées via un **type** et un **numéro** (couple unique).
|
||||
|
||||
**Stations couramment utilisées :**
|
||||
|
||||
| Station | Type | Numéro |
|
||||
|---------|------|--------|
|
||||
| MAG (Magasin) | 0 | N° du MAG |
|
||||
| TK (Transstockeur/Miniload) | 1 | N° du TK |
|
||||
| PK (Poste de Picking) | 2 | N° du PK |
|
||||
| PIE (Poste Identification Entrée) | 3 | N° du PIE |
|
||||
| PS (Poste de Sortie) | 4 | N° du PS |
|
||||
| REJ (Poste de Rejet) | 7 | N° du RECH |
|
||||
| ME / TE (Table d'entrée) | 9 | N° de la ME |
|
||||
| MS / TS (Table de sortie) | 10 | N° de la MS |
|
||||
| PKE (Contrôle entrée vers PK) | 20 | N° de la ETPK |
|
||||
| CME (Contrôle entrée vers ME) | 21 | N° de la CME |
|
||||
|
||||
L'état des stations est consultable dans **EasyWMS → Contrôle → Stations** (status, chargé, capacité).
|
||||
|
||||
**Fonction GALILEO de mise à jour d'état de station :**
|
||||
```
|
||||
SetStationStatus(Type, Numéro, Status, Présence, Capacité, Occupation, Allée)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Routes
|
||||
|
||||
Une route est une "trajectoire simple" entre deux stations, dont l'état doit être actualisé par GALILEO pour permettre au WMS de décider de dévier ou non un conteneur.
|
||||
|
||||
**Routes à actualiser obligatoirement :**
|
||||
- `PKExx → PKxx`
|
||||
- `CMExx → TExx`
|
||||
- Parfois : `ETPSxx → PSxx` pour l'ordonnancement des sorties
|
||||
|
||||
**États de route :**
|
||||
- `1` = En service
|
||||
- `3` = Plein et en service
|
||||
|
||||
**Fonction GALILEO de mise à jour d'état de route :**
|
||||
```
|
||||
SetRouteStatus(TypeOrigine, NuméroOrigine, TypeDestination, NuméroDestination, Etat)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ordres (3 types de communication)
|
||||
|
||||
### Event
|
||||
Déclaration de présence d'un bac à un point précis. Utilisé principalement par le **PIE** (lecture étiquette + infos gabarit) et le **TK** (annonce de présence).
|
||||
|
||||
**Deux process pour le PIE :**
|
||||
1. **Nouveau conteneur** : GALILEO lit l'étiquette et envoie type/hauteur → EasyWMS contrôle la conformité
|
||||
2. **Conteneur connu renvoyé** : EasyWMS envoie un mouvement vers PIE → GALILEO contrôle que les types correspondent, sans lire l'étiquette
|
||||
|
||||
**Champs du signal PIE :**
|
||||
- Signaux : `65536` = conteneur OK (codification bit à bit des contrôles gabarit)
|
||||
- Type de conteneur : codifié à partir de 1
|
||||
- Type de hauteur : codifié à partir de 1
|
||||
- Type d'évènement : code selon l'événement (rejet = type 9)
|
||||
|
||||
### Recherche d'ordre (Search)
|
||||
GALILEO demande à EasyWMS le prochain mouvement à réaliser. Le WMS répond avec les informations de la station de destination.
|
||||
|
||||
Champs importants :
|
||||
- **Capacité** : pour PK et PS = nombre max de conteneurs sur la station OU en mouvement vers elle
|
||||
- **État** : `83` (S = Servicio) pour convoyeurs, `70` (F = Fallo) ou `69` (E = Error) pour TK
|
||||
- **X actuel / Y actuel** : pour TK uniquement (position actuelle pour optimiser l'ordre)
|
||||
|
||||
### Fin d'ordre (End)
|
||||
Signale à EasyWMS que le mouvement est terminé. Le mouvement passe à l'étape suivante.
|
||||
|
||||
**Codes d'erreur End :**
|
||||
| Code | Signification | Conséquence |
|
||||
|------|--------------|-------------|
|
||||
| `0` | Mouvement terminé | Génère le mouvement suivant |
|
||||
| `1` | Erreur de dépose | Masque d'erreur + relocalisation/rejet |
|
||||
| `2` | Erreur d'extraction | Masque d'erreur + relocalisation/rejet |
|
||||
| `4` | Ordre incohérent | Problème de configuration WMS/GALILEO |
|
||||
| `7` | Erreur gabarit | Relocalisation/rejet |
|
||||
|
||||
---
|
||||
|
||||
## Concept de machine séquentielle
|
||||
|
||||
Toute machine fonctionne par **étapes consécutives** (grafcet) avec des transitions entre états. La séquence d'un convoyeur normal :
|
||||
|
||||
1. Repos → prêt à recevoir
|
||||
2. Demande de sortie du convoyeur amont
|
||||
3. Vérification des conditions (pas de présence, pas de tracking…)
|
||||
4. Copie du tracking + transfert physique + communication WMS si station
|
||||
5. Libération du convoyeur amont
|
||||
6. Demande de sortie au convoyeur aval
|
||||
7. Retour à l'étape initiale
|
||||
|
||||
---
|
||||
|
||||
## Visualisation et Tracking
|
||||
|
||||
**Identifiants par défaut :** `mecalux / robmec`
|
||||
|
||||
La visualisation (SCADA) affiche en temps réel mouvements, défauts et état de l'installation.
|
||||
|
||||
**Éditeur de Tracking** (double-clic sur une machine) :
|
||||
- **Afficher le tracking** : informations de l'ordre en exécution
|
||||
- **Finir Ordre** : informer EasyWMS qu'une palette est arrivée à destination
|
||||
- **État de la machine** : informations communiquées par GALILEO à EasyWMS
|
||||
|
||||
**Accès avancé (après mot de passe via l'icône cadenas) :**
|
||||
- **Variables** : état des variables en temps réel, modification des mémoires booléennes
|
||||
- **Graphe** : état actuel de la machine (étape en cours)
|
||||
|
||||
**Boutons d'édition :**
|
||||
- **Modifier** : modifier le Tracking (origine, destination, hauteur, type…) → activer "Éditer" d'abord
|
||||
- **Éliminer** : supprimer le Tracking de la machine
|
||||
- **Reset** : remettre à une étape précise du Graphe automatique
|
||||
@@ -0,0 +1,50 @@
|
||||
# Présentation méthode de développement
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000083316739)
|
||||
> Dernière mise à jour : 29/12/2023 (v8)
|
||||
|
||||
---
|
||||
|
||||
## 🏆 Objectifs
|
||||
|
||||
1. Réduire les temps de compilation
|
||||
2. Distinction entre ce qui est en production, ce qui est à livrer et ce qui est en cours de développement
|
||||
|
||||
---
|
||||
|
||||
## ℹ️ Informations
|
||||
|
||||
1. La branche **master** du contrôle de version contiendra toujours les tâches testées et validées.
|
||||
2. La branche **développement** du contrôle de version sera la base de toutes les branches de développements.
|
||||
|
||||
---
|
||||
|
||||
## 💻 Phase de développements
|
||||
|
||||
1. Chaque développeur aura sa machine de développement sur son PC et une branche GIT issue de la branche de développement.
|
||||
2. Après chaque merge ou rebase, ils redéploieront la custom app depuis leur branche de développement.
|
||||
3. Pour le manuel de reten, nous mettrons en place un fichier en markdown afin de faciliter les merges.
|
||||
À la fin des développements, les données de ce fichier seront copier/coller dans le manuel de reten au format DOC.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Phase de tests
|
||||
|
||||
1. Lorsqu'une partie des développements ou tous les développements sont terminés, la custom application sera déployée sur une machine qui se trouvera sur le serveur de test.
|
||||
2. Ceci permettra aux testeurs de tester sans avoir à monter la machine sur leur PC.
|
||||
3. Les développeurs pourront corriger les bugs trouvés lors des différents tests directement sur le serveur de test.
|
||||
**OU** *(point à valider)*
|
||||
En cas de bugs trouvés, le développeur corrige sur sa machine de développement et redéploie sur le serveur de test.
|
||||
|
||||
---
|
||||
|
||||
## 🏁 Post-production
|
||||
|
||||
1. La branche **master** contiendra toujours l'état actuel de la production afin de pouvoir redéployer à tout moment sans perte de données.
|
||||
2. Si développement il y a, une branche **post production** sera créée et sera mergée seulement avant mise en production pour éviter d'écraser les modifications de master.
|
||||
|
||||
---
|
||||
|
||||
## 📼 Vidéo de présentation (Obsolète)
|
||||
|
||||
[Disponible ici](https://mecaluxgroup-my.sharepoint.com/personal/thomas_chaillou_mecalux_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fthomas%5Fchaillou%5Fmecalux%5Fcom%2FDocuments%2FRecordings%2FPr%C3%A9sentation%20nouvelle%20m%C3%A9thode%20de%20d%C3%A9veloppement%2D20221013%5F100730%2DEnregistrement%20de%20la%20r%C3%A9union%2Emp4&ga=1)
|
||||
+146
@@ -0,0 +1,146 @@
|
||||
|
||||
**Sources croisées :**
|
||||
|
||||
- **DevOps #64854** (le plus ancien)
|
||||
- **AF — Analyse Fonctionnelle §6.4.8** (intermédiaire)
|
||||
- **Réunion du 11/05/2026** (le plus récent, fait foi)
|
||||
|
||||
---
|
||||
|
||||
## 1. Contradictions identifiées
|
||||
|
||||
### 1.1 Traitement commercial — séparation traité / non traité
|
||||
|
||||
|Source|Position|
|
||||
|---|---|
|
||||
|**DevOps**|« Isoler les non traités (bio ou pas), identification via le code traitement — **A CREUSER** »|
|
||||
|**AF**|« Pas de mélange entre articles avec un traitement et sans sur une même palette fille. La préparation devra donc se faire en deux temps. »|
|
||||
|**Réunion**|**Règle supprimée.** `CONTROLE_TRAITEMENT_COMMERCIAL` = `false`. Pas de bio sur cet entrepôt, pas de raison de maintenir la contrainte.|
|
||||
|
||||
→ **Contradiction directe.** Le DevOps posait la question, l'AF l'avait tranchée en séparation stricte, la réunion l'a invalidée. **La réunion fait foi.**
|
||||
|
||||
### 1.2 Seuil de déclenchement du picking négatif
|
||||
|
||||
|Source|Condition|
|
||||
|---|---|
|
||||
|**DevOps**|« Possibilité de picking négatif — la palette mère sera expédiée » (pas de seuil explicite)|
|
||||
|**AF**|Quantité à prélever > **50%** de la palette → picking négatif|
|
||||
|**Réunion**|Picking négatif si poids sac ≥ **7 kg** (le seuil 50% reste en paramétrage fiche article, défaut 55%, mais la condition de poids est ajoutée)|
|
||||
|
||||
→ **Confirmé : les deux conditions sont cumulatives (ET).** Le picking négatif ne se déclenche que si le % dépasse le seuil fiche article (défaut 55%) **ET** que le poids unitaire du sac ≥ 7 kg. Si l'une des deux conditions n'est pas remplie, pas de picking négatif.
|
||||
|
||||
### 1.3 Poids max palette
|
||||
|
||||
|Source|Limite|
|
||||
|---|---|
|
||||
|**DevOps**|**1200 kg** de semence|
|
||||
|**AF**|**1250 kg** sinon rejet au PIE|
|
||||
|
||||
→ **Tranché : 1250 kg (AF fait foi).** Le DevOps indiquait 1200 kg, l'AF corrige à 1250 kg avec rejet au PIE en cas de dépassement. L'AF étant plus récente, c'est la valeur retenue.
|
||||
|
||||
### 1.4 Priorité picking négatif vs Maïs first
|
||||
|
||||
|Source|Ordre|
|
||||
|---|---|
|
||||
|**DevOps**|Pas de hiérarchie explicite entre les deux|
|
||||
|**AF**|Maïs first apparaît en règle 1 du tri, picking négatif est une contrainte séparée — pas de priorité relative claire|
|
||||
|**Réunion**|**Picking négatif prioritaire sur Maïs first.** Confirmé explicitement par Olivier.|
|
||||
|
||||
→ **Clarification apportée par la réunion**, mais contredit l'impression de l'AF qui positionne Maïs first en tête des règles de tri sans mention du picking négatif comme prioritaire.
|
||||
|
||||
---
|
||||
|
||||
## 2. Règles présentes dans le DevOps / AF mais absentes ou non confirmées en réunion
|
||||
|
||||
### 2.1 Semences essais en dernier (haut de palette) — ✅ Résolu
|
||||
|
||||
- **DevOps** : « Les semences essais sont disposées au-dessus (en dernier sur la palette) »
|
||||
- **AF** : Non mentionné
|
||||
|
||||
→ **Couvert par la règle existante « article le plus lourd en base ».** Les semences essais sont très légères, donc naturellement placées en haut de palette par le tri par masse. Pas de règle dédiée nécessaire — à confirmer le 18/05 que le principe de la masse suffit.
|
||||
|
||||
### 2.2 Prioriser les lots avec le même Bag/pal sur une même palette — ✅ Retenu
|
||||
|
||||
- **DevOps** : « Prioriser les lots qui ont le même bagpal sur une même palette »
|
||||
|
||||
→ **Règle conservée.** Utilisée dans le workflow de constitution de palettes complètes au picking (règle 1 : palettes les plus complètes possible). Regrouper les lots de même Bag/pal facilite le calcul de remplissage et maximise la complétude.
|
||||
|
||||
### 2.3 Pas de différenciation de marque — ✅ Confirmé
|
||||
|
||||
- **DevOps** : « On ne fait pas de différenciation de marque dans une même expédition »
|
||||
|
||||
→ **Règle maintenue.** Pas de séparation par marque.
|
||||
|
||||
### 2.4 Calcul du Bag/pal max entre lots différents — ✅ Résolu
|
||||
|
||||
- **DevOps** : « Vérifier le bagpal min et max des lots de la palette pour déterminer le nombre maximum de sacs dans la limite des 1200 kg. Si bagpal 50 et 75, on prend le bagpal de 75. »
|
||||
- **AF** : Calcul équivalent palette mentionné (1/Bagpal) mais pas la logique min/max entre lots différents
|
||||
|
||||
→ **Compensé par le pro rata.** Le calcul de remplissage en pro rata Bag/pal (chaque sac = 1/Bagpal de son lot) gère nativement les lots avec des Bag/pal différents sans avoir besoin de choisir un Bag/pal de référence unique. Pas de point ouvert.
|
||||
|
||||
**Explication détaillée avec exemple :**
|
||||
|
||||
Le Bag/pal (Bags per pallet), c'est le nombre de sacs qui tiennent sur une palette complète pour un lot donné. Il dépend de la taille des sacs, du poids, de la configuration de palettisation — donc il varie d'un lot à l'autre. Un lot de gros sacs de maïs peut avoir un Bag/pal de 20, un lot de petits sacs de tournesol un Bag/pal de 75.
|
||||
|
||||
Le problème qu'on a au picking, c'est qu'on constitue des palettes filles qui mélangent potentiellement des sacs de lots différents, avec des Bag/pal différents. Il faut savoir à quel point la palette fille est "remplie" pour décider si on peut encore y ajouter des sacs ou si elle est complète.
|
||||
|
||||
Le pro rata résout ça simplement : chaque sac qu'on pose sur la palette fille "consomme" une fraction de palette égale à 1/Bag/pal de son propre lot. Exemple concret : tu as une palette fille vide et tu y mets 15 sacs d'un lot avec Bag/pal = 20, puis 10 sacs d'un lot avec Bag/pal = 75. Le remplissage calculé est (15/20) + (10/75) = 0,75 + 0,133 = 0,883, soit ~88%. Il reste ~12% de place, on peut encore chercher des sacs compatibles pour s'approcher du seuil de 95%.
|
||||
|
||||
L'avantage par rapport à l'ancienne logique du DevOps (qui disait "si Bag/pal 50 et 75, on prend le 75") c'est qu'on n'a pas besoin de choisir un Bag/pal de référence unique pour toute la palette. Chaque sac porte son propre ratio, le calcul est additif et fonctionne quel que soit le nombre de lots mélangés.
|
||||
|
||||
---
|
||||
|
||||
## 3. Points cohérents entre les 3 sources
|
||||
|
||||
|Règle|DevOps|AF|Réunion|
|
||||
|---|---|---|---|
|
||||
|Mélange espèces autorisé sur une palette|✅|✅ (implicite)|✅|
|
||||
|Maïs en priorité|✅|✅|✅ (rang 2, après picking négatif)|
|
||||
|Espèce avec le plus de quantité ensuite|✅|✅|✅ (rang 3)|
|
||||
|Article le plus lourd en base|✅|✅|✅ (rang 4)|
|
||||
|Pas de gerbage|✅|✅|— (non abordé, mais pas contesté)|
|
||||
|Hauteur max 1,90 m|✅|✅|— (non abordé, mais pas contesté)|
|
||||
|Équivalent palette via Bag/pal|—|✅|✅|
|
||||
|Palettes complètes = pas de passage au PK|✅|✅ (implicite)|—|
|
||||
|
||||
---
|
||||
|
||||
## 4. Synthèse — Tous les points sont résolus
|
||||
|
||||
**Plus de point ouvert.** L'ensemble des contradictions et ambiguïtés entre les 3 sources a été traité.
|
||||
|
||||
### Points résolus
|
||||
|
||||
|Sujet|Résolution|
|
||||
|---|---|
|
||||
|Traitement commercial|Règle supprimée (`CONTROLE_TRAITEMENT_COMMERCIAL` = `false`)|
|
||||
|Picking négatif — seuil|Deux conditions cumulatives : % seuil fiche article (défaut 55%) **ET** poids sac ≥ 7 kg|
|
||||
|Poids max palette|**1250 kg** (AF fait foi, rejet au PIE si dépassement)|
|
||||
|Picking négatif vs Maïs first|Picking négatif prioritaire (confirmé par Olivier)|
|
||||
|Semences essais en haut de palette|Couvert par la règle du plus lourd en base (semences essais = légères → naturellement en haut)|
|
||||
|Priorisation lots même Bag/pal|Retenu, utilisé dans le WF palettes complètes|
|
||||
|Pas de différenciation de marque|Confirmé|
|
||||
|Calcul Bag/pal multi-lots|Compensé par le pro rata (chaque sac = 1/Bagpal de son lot)|
|
||||
## 5. Règles finales
|
||||
|
||||
|
||||
**1. Palettes les plus complètes possible**
|
||||
|
||||
- Objectif principal : maximiser le remplissage des palettes filles pour optimiser le coût de transport. On vise ~95% de remplissage (marge de sécurité pour absorber un sac un peu plus volumineux que prévu).
|
||||
- Le calcul de remplissage se fait en pro rata Bag/pal : chaque sac = 1/Bagpal de son lot, ce qui gère nativement les lots avec des Bag/pal différents sur une même palette.
|
||||
- On priorise le regroupement de lots ayant le même Bag/pal sur une même palette (facilite la complétude).
|
||||
- Éviter au maximum de splitter une ligne de stock sur plusieurs palettes, même si ça implique de casser l'ordre des règles de tri suivantes (ex : mettre du tournesol avant du maïs pour garder une ligne complète).
|
||||
|
||||
**2. Picking négatif (si applicable)**
|
||||
|
||||
- Deux conditions cumulatives (ET) : le % de quantité à prélever dépasse le seuil fiche article (défaut 55%) **et** le poids unitaire du sac ≥ 7 kg.
|
||||
- Si l'une des deux conditions n'est pas remplie, pas de picking négatif → picking direct classique.
|
||||
- Le picking négatif est prioritaire sur toutes les règles de tri ci-dessous, y compris Maïs first. Si une tâche de picking négatif concerne du tournesol, elle passe avant une tâche maïs classique.
|
||||
|
||||
|
||||
**3. Règles de tri (appliquées dans l'ordre, au sein du pool de tâches restantes)**
|
||||
|
||||
- **3.1 Maïs first** : si la commande contient du maïs, c'est la première espèce prélevée.
|
||||
- **3.2 Espèce la plus importante** : une fois le maïs traité, on prend l'espèce qui a le plus de quantité (en nombre de sacs) dans la commande.
|
||||
- **3.3 Article/lot le plus lourd en base de palette** : en cas d'ex-aequo entre espèces, on met le plus lourd en premier pour la stabilité. Corollaire : les semences essais (très légères) se retrouvent naturellement en haut de palette.
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
# Retirer la pop-up de connexion
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544/Retirer+la+pop-up+de+connexion)
|
||||
> Dernière mise à jour : 20/12/2022 (v1)
|
||||
|
||||
---
|
||||
|
||||
> ℹ️ Cette page ne contient pas encore de contenu sur Confluence.
|
||||
@@ -0,0 +1,112 @@
|
||||
# Revue - Code
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000399822888/Revue+-+Code)
|
||||
> Dernière mise à jour : 08/01/2026 (v10)
|
||||
|
||||
---
|
||||
|
||||
## 1 - Check-liste des éléments
|
||||
|
||||
Lien MSS des check-listes à valider pour la revue de code : [Revue Mecalux Espagne](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/code_review/index.md)
|
||||
|
||||
### 1.1 OutboundLines
|
||||
|
||||
> ⚠️ Attention sur le point suivant concernant les requêtes sur la **writing** :
|
||||
|
||||
Lorsque vous faites une requête pour récupérer les lignes d'un ordre de sortie, il est très important d'utiliser la propriété **`OutboundLines`** et non **`OutboundOrderLines`**, sinon lorsque vous avez une ligne annulée dans la commande, vous aurez cette erreur dans les logs :
|
||||
|
||||
```
|
||||
Le nombre de ligne d'ordre d'expédition ne peut pas être négatif
|
||||
```
|
||||
|
||||
### 1.2 Kit sans assemblage ? OutboundOrderOutboundOrderLineDetails
|
||||
|
||||
Si le projet utilise les **kits sans assemblage**, faire attention à l'utilisation entre `OutboundOrderOutboundOrderLineDetails` et `OutboundLines` :
|
||||
|
||||
- Dans `OutboundOrderOutboundOrderLineDetails` → vous trouverez **tous les composants**
|
||||
- Dans `OutboundLines` → vous trouverez **uniquement le kit lui-même**
|
||||
|
||||
### 1.3 OutboundLine.ProductConversion
|
||||
|
||||
> ⚠️ Attention sur le point suivant concernant les requêtes sur la **writing** :
|
||||
|
||||
Dans les lignes des ordres de sortie, l'attribut **`ProductConversion`** peut être `null`.
|
||||
|
||||
*(Dans le cas où la commande demande un support spécifique, on aura le code support renseigné mais pas l'article, et donc pas sa conversion.)*
|
||||
|
||||
---
|
||||
|
||||
## 2 - Identification des customs
|
||||
|
||||
### 2.1 - Bloc de code / requête
|
||||
|
||||
Ajouter des commentaires permettant de délimiter le code modifié lorsqu'il se retrouve mélangé avec du code standard :
|
||||
|
||||
```csharp
|
||||
potentiel code standard
|
||||
|
||||
//StartCustom
|
||||
Code custom
|
||||
//EndCustom
|
||||
|
||||
potentiel code standard
|
||||
```
|
||||
|
||||
### 2.2 - Identification des éléments custom
|
||||
|
||||
Chaque nouvel élément ou élément modifié doit être identifié par le préfixe **`CST_`**, en se posant les questions suivantes :
|
||||
|
||||
| Question | Règle |
|
||||
|----------|-------|
|
||||
| **Est-ce que l'élément est visible par le client ?** | Pas d'ajout de préfixe (ex : les paramètres SmartUI ne prennent pas le préfixe) |
|
||||
| **Est-ce que j'ai la possibilité de modifier le nom de l'élément ?** | Un workflow non en mode "full edition" ne permet pas de modifier le nom des éléments |
|
||||
| **Est-ce qu'il s'agit de l'élément de plus "haut niveau" ?** | Tous les éléments d'un workflow custom ne prendront pas le préfixe — seul le **workflow** sera identifié. Inversement, dans un workflow standard, **tous** les éléments ajoutés/modifiés prennent le préfixe |
|
||||
|
||||
> ⚠️ **N'oubliez pas !**
|
||||
> - Un dialogue est modifié même si on ne fait que changer l'implémentation de l'activité
|
||||
> - Les **transitions** doivent aussi être identifiées
|
||||
|
||||
> ⚠️ Lorsqu'un workflow passe de "partial overriden" à "overriden" avec le mode "full edition", on perd l'identification de couleur des activités/transitions modifiées. Il faut alors préfixer **toutes** les activités modifiées par `CST_` (ouvrir le workflow dans sa version précédente en parallèle pour ne rien oublier).
|
||||
|
||||
---
|
||||
|
||||
## 3 - Nommage des éléments
|
||||
|
||||
Nomenclature générale de référence : [Nomenclature Espagne](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/nomenclature/index.md)
|
||||
|
||||
Règles complémentaires :
|
||||
|
||||
- Les ressources des **viewfields** d'une vue prennent 2 préfixes suivis du code du viewfield
|
||||
- Ex : viewfield `OutboundOrderStatus` de la vue `OutboundOrderVList` → `ViewField_OutboundOrderVList_OutboundOrderStatus`
|
||||
- Les **paramètres SmartUI** sont plus parlants s'ils sont préfixés du process qu'ils impactent, en majuscules
|
||||
- Ex : `EXPEDITION_ALLOWED_CONTAINER`
|
||||
- Les **attributs** d'un workflow commencent par une **minuscule**, les **paramètres formels** par une **majuscule**
|
||||
- Toutefois, ne pas oublier le préfixe `CST_` devant les attributs dans un workflow standard
|
||||
- Les **paramètres d'un dialogue** commencent par une majuscule
|
||||
- Les **paramètres d'une requête** commencent par une minuscule
|
||||
|
||||
---
|
||||
|
||||
## 4 - Utilisation du "code en dur"
|
||||
|
||||
- Dans les workflows, éviter au maximum le code en dur
|
||||
- Notamment, les actions "Enter" et "Escape" après un dialogue devraient être testées avec les variables :
|
||||
- `ProcessContext.EnterAction`
|
||||
- `ProcessContext.EscapeAction`
|
||||
|
||||
---
|
||||
|
||||
## 5 - Null reference
|
||||
|
||||
Attention à l'utilisation de code pouvant induire des `NullReferenceException`, particulièrement la méthode `FirstOrDefault()` qui doit être sécurisée :
|
||||
|
||||
```csharp
|
||||
// ❌ Dangereux - peut lever une exception si aucun ordre de sortie n'existe
|
||||
Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines
|
||||
|
||||
// ✅ Sécurisé
|
||||
var order = Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode);
|
||||
if (order != null) { ... }
|
||||
```
|
||||
|
||||
Documentation Espagne sur la gestion des null reference : [Lien MSS](https://msscc.mecalux.com/documentation/Development/master/ES/map_application_development/null_management_best_practices/index.md)
|
||||
@@ -0,0 +1,30 @@
|
||||
# Revue - Documentation
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000400642074/Revue+-+Documentation)
|
||||
> Dernière mise à jour : 04/03/2024 (v3)
|
||||
|
||||
---
|
||||
|
||||
## 1 - Jira
|
||||
|
||||
Vérifier que les éléments modifiés sont bien décrits et que les modifications sont explicites dans les commentaires de la tâche.
|
||||
|
||||
---
|
||||
|
||||
## 2 - Git
|
||||
|
||||
Vérifier la présence des éléments modifiés dans la branche GIT concernée (cf. [Gestion du GIT](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000400216098)).
|
||||
|
||||
Il peut être utile de vérifier l'**historique des commits** GIT du développeur pour s'assurer qu'il n'a pas inclus des modifications sur des éléments hors périmètre de sa tâche. Ce cas peut survenir si le dev a été réalisé avec une application custom qui n'était pas au même "niveau" que la branche sur laquelle elle est exportée *(ce qui arrive si on crée sa branche après avoir importé la custom app dans le Builder alors que des commits ont eu lieu entre temps)*.
|
||||
|
||||
---
|
||||
|
||||
## 3 - Reten
|
||||
|
||||
Vérifier que la description de la tâche est bien présente dans le reten avec l'intégralité des éléments modifiés.
|
||||
|
||||
| Cas | Localisation dans le reten |
|
||||
|-----|---------------------------|
|
||||
| Le custom **modifie le comportement d'un process** | Décrit parmi les chapitres de process (Entries, Exits, Picking, etc.) avec une description **fonctionnelle**, **technique** et les **éléments custom** |
|
||||
| Le custom **ne modifie pas le comportement d'un process** | Présent dans les tableaux d'éléments custom en fin de reten, avec une description de la modification |
|
||||
| Des **custom attributes** ont été utilisés | Listés dans la partie **"1.2 General custom elements"** du reten, et idéalement aussi dans la tâche Jira liée au custom quand il s'agit d'un process custom |
|
||||
@@ -0,0 +1,21 @@
|
||||
# Revue - Fonctionnel
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000400642064/Revue+-+Fonctionnel)
|
||||
> Dernière mise à jour : 27/02/2024 (v2)
|
||||
|
||||
---
|
||||
|
||||
## 1 - Cas de test
|
||||
|
||||
Effectuer tous les cas de test fonctionnel décrits dans la tâche Jira s'ils sont présents, sinon effectuer les cas standard d'utilisation du custom.
|
||||
|
||||
---
|
||||
|
||||
## 2 - Tester "Échap" sur les dialogues
|
||||
|
||||
Tester l'option **Échap** sur les dialogues en se posant la question suivante :
|
||||
|
||||
Est-ce que l'opérateur veut :
|
||||
- Revenir à l'écran précédent ?
|
||||
- Passer à la suite du process ?
|
||||
- Ne rien faire ?
|
||||
@@ -0,0 +1,84 @@
|
||||
# Routage vers les VM
|
||||
|
||||
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000160452644/Routage+vers+les+VM)
|
||||
> Dernière mise à jour : 11/08/2023 (v7)
|
||||
|
||||
---
|
||||
|
||||
## Routage
|
||||
|
||||
Lors de la configuration du commutateur Interne, un **NAT** (Network Address Translation) a été mis en place. Il permet de router les requêtes réseau reçues sur certains ports du PC vers la VM sur d'autres ports.
|
||||
|
||||
### Tableau de correspondance des ports
|
||||
|
||||
| Service | Port interne à la VM | Port externe (PC local) n°1 | Port externe (PC local) n°2 |
|
||||
|---------|---------------------|----------------------------|----------------------------|
|
||||
| HTTP | 80 | 8080 | 8008 |
|
||||
| HTTPS | 443 | 4430 | 4431 |
|
||||
| Connexion bureau à distance | 3389 | 33890 | 33891 |
|
||||
| Oracle | 1521 | 15210 | 15211 |
|
||||
| SMB | 445 | 4450 | 4451 |
|
||||
|
||||
> **Culture Geek :**
|
||||
> - `Get-NetAdapter` : affiche tous les adaptateurs réseau
|
||||
> - `Get-NetNatStaticMapping` : affiche les routes statiques pour la conversion des ports entre local et VM
|
||||
>
|
||||
> Toute requête TCP reçue sur le PC sur le port **8080** sera redirigée vers l'adresse **10.255.255.2** sur le port **80** — ceci afin de ne pas bloquer l'utilisation de ces ports sur le PC local.
|
||||
|
||||
---
|
||||
|
||||
## Accès en local
|
||||
|
||||
La VM est accessible via **`localhost`** en précisant le port cible.
|
||||
|
||||
Exemples :
|
||||
|
||||
| Accès | URL |
|
||||
|-------|-----|
|
||||
| EasyBuilder en HTTPS | `localhost:4430` |
|
||||
| SmartUI via DNS (sans port) | `https://<nom_vm>/smartui/` |
|
||||
|
||||
---
|
||||
|
||||
## Accès depuis un autre PC
|
||||
|
||||
Impossible d'utiliser `localhost` ou le DNS depuis un autre poste. Il faut utiliser l'**adresse IP du PC hôte** suivie du port ciblé.
|
||||
|
||||
### 1 - Connaître son IP
|
||||
|
||||
**Option A — Via les paramètres Windows :**
|
||||
1. Clic droit sur l'icône réseau dans la barre des tâches
|
||||
2. Cliquer sur **"Ouvrir les paramètres réseau et Internet"**
|
||||
3. Cliquer sur **"Propriétés"** de votre réseau Ethernet
|
||||
4. Récupérer l'**adresse IPv4**
|
||||
|
||||
**Option B — Via PowerShell :**
|
||||
```powershell
|
||||
ipconfig
|
||||
```
|
||||
Récupérer l'adresse IPv4 de votre adaptateur Ethernet.
|
||||
|
||||
### 2 - Accéder à la VM
|
||||
|
||||
| Accès | URL exemple |
|
||||
|-------|-------------|
|
||||
| EasyBuilder en HTTPS | `192.168.164.214:4430` |
|
||||
| EasyS (HTTPS) | `192.168.164.214:4430` |
|
||||
| SmartUI (Web) | `192.168.164.214:4430/smartui` |
|
||||
| Bureau à distance (RDP) | `192.168.164.214:33890` |
|
||||
|
||||
---
|
||||
|
||||
## Utilisation avec le VPN
|
||||
|
||||
> Note de l'Espagne : "Si vous appartenez à une délégation en Europe (sauf Gijón), vous devez vous connecter via les passerelles suivantes : **Europe 4** et **Europe** uniquement via SSL."
|
||||
|
||||
| Passerelle | Adresse | Port |
|
||||
|-----------|---------|------|
|
||||
| Europe | `vpn-europa@mecalux.com` | 4443 |
|
||||
| Europe 4 | `vpn-europa4@mecalux.com` | 443 |
|
||||
|
||||
> Si la connexion échoue toujours, vérifier si **ZAPP** ou **Zscaler APP** est installé sur la machine physique.
|
||||
> Si c'est le cas : **désinstaller et redémarrer**.
|
||||
>
|
||||
> Si le problème persiste, envoyer un e-mail à [it@mecalux.com](mailto:it@mecalux.com) avec l'objet : **`No Hyper-V NAT connectivity`**
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user