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

màj wiki avec retour MES lot-5 AD

Browse Source
This commit is contained in:
Arthur Ria
2026-05-20 09:41:27 +02:00
commit 23eb3f3c84
4106 changed files with 469381 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/operations/agv-installation.md
+417
View File
@@ -0,0 +1,417 @@
---
title: "AGV Module — Installation Guide"
type: operation
sources:
- sources/archives/Documentation Module AGV.md
- sources/archives/Présentation Module AGV.md
related:
- modules/agv.md
- concepts/stations.md
last_compiled: "2026-05-15"
---
# AGV Module — Installation Guide
## Overview
This guide covers the end-to-end installation of the AGV module for Easy WMS. The module relies on a PostgreSQL intermediary database, an ODBC driver, an Oracle DBLink (dg4odbc), the Gateway AGV Windows service, and the AGV application package deployed into Easy WMS. For the functional description of the module, see [AGV — Automated Guided Vehicles](../modules/agv.md).
## Prerequisites
| Element | Requirement |
|---------|-------------|
| Easy WMS binaries | Version **18.10.22154.1** minimum |
| PostgreSQL | Version >= 14 (note: PostgreSQL 18+ defaults to port 5433) |
| PostgreSQL ODBC driver | **psqlodbc x64** |
| Oracle | Know the exact `ORACLE_HOME` path on the VM |
| Oracle permissions | The `db_read` user must be able to create database links |
| Firewall | PostgreSQL port open (5432 default, 5433 if PostgreSQL 18+) |
To find the Oracle version and `ORACLE_HOME` path:
```
dir C:\Mecalux\Motor\oracle\Product\
```
> Throughout this guide, `[ORACLE_HOME]` refers to the full path, e.g. `C:\Mecalux\Motor\oracle\Product\19.27.0.0\dbhome_1`. **Always replace** `[ORACLE_HOME]` **with your actual path** - leaving the placeholder is a frequent cause of failure.
## Step 1 — Install PostgreSQL
Download PostgreSQL >= 14 from the official EDB site and install with default options. Note the listening port - this is critical: PostgreSQL <= 17 uses port **5432**, while **PostgreSQL 18+ defaults to port 5433**.
### Create the AGV user and database
In PgAdmin4, create a login role `mecaluxAGV` (password: `mecaluxAGV` or per your convention, with login privilege), then create a database named `AGV` owned by `mecaluxAGV`.
### Allow external connections
Edit `C:\Program Files\PostgreSQL\[version]\data\pg_hba.conf` and add:
```
# Allow all IPv4 connections (dev environment only)
host all all 0.0.0.0/0 md5
# Alternative: filter by IP range
host all all 192.168.0.0/16 md5
```
### Open the firewall port
```powershell
netsh advfirewall firewall add rule name="PostgreSQL AGV" dir=in action=allow protocol=tcp localport=5432
```
Adjust the port number if using PostgreSQL 18+ (5433).
## Step 2 — Install the PostgreSQL ODBC driver
> The download link in the official MSS documentation is dead. Go to the PostgreSQL ODBC releases page and download the latest `psqlodbc_x64.msi` (not the wrapper setup.exe).
Install the MSI with default options.
## Step 3 — Configure the System DSN (64-bit ODBC)
Open **ODBC Data Sources (64-bit)** (`C:\Windows\System32\odbcad32.exe`), go to the **System DSN** tab (not User DSN), click **Add**, and select the **PostgreSQL Unicode(x64)** driver.
| Field | Value |
|-------|-------|
| Data Source | `PostgreSQL35W` |
| Database | `AGV` |
| Server | `localhost` (or PostgreSQL server IP) |
| Port | `5432` (or `5433` if PostgreSQL 18+) |
| User Name | `mecaluxAGV` |
| Password | `mecaluxAGV` |
In the **Datasource** tab, **uncheck "Bools as Char"**. Click **Test** to verify the connection.
> **Critical — DSN name case**: the name `PostgreSQL35W` (capital P and W) is used verbatim in **5 different Oracle configuration files**. The case must be **absolutely consistent** across all files. Using `POSTGRESQL35W` (all caps) or `postgresql35w` (all lowercase) will cause a silent dg4odbc failure. See the Troubleshooting section for details.
## Step 4 — Install and start the Gateway AGV
### 4.1 — Verify the configuration file
The config file is located at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. The XML file must contain exactly **one** `<AGVConfig>` section. If it contains two (e.g., for two stations), the provider will not initialize and the service will crash with `Migration DataBase Provider No Initialized`.
Verify that the connection string points to the correct PostgreSQL database:
```xml
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="AGVConfig"
type="Mecalux.ITSW.AGVGateway.Config.ConfigSettings,
Mecalux.ITSW.AGVGateway.Config" />
</configSections>
<AGVConfig
connectionString="Host=localhost;user id=mecaluxAGV;password=mecaluxAGV;
database=AGV;MaxPoolSize=1000"
inputCycleDelay="1000"
outputCycleDelay="1000"
timeoutCommand="6000"
providerName="Npgsql"
stationType="65"
stationNumber="1"
warehouseNumber="20000"
commitLimit="100"
hoursToExecute="24"
daysToSave="5">
</AGVConfig>
</configuration>
```
> If using **PostgreSQL 18+** (port 5433), add the port explicitly: `Host=localhost;Port=5433;user id=mecaluxAGV;...`
### 4.2 — First startup (table creation)
Start the Gateway AGV service (`services.msc` > EasyWMS GatewayAGV). Check the log at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\Logs\AllLog.log` for successful migration lines:
```
[Info] [Migration] [Apply] End applying migration: Migration0
[Info] [Migration] [Apply] End applying migration: AgvMigration3
```
If these lines appear, the tables were created successfully. Errors after these lines are normal (the Gateway tries to communicate with the fleet manager which is not yet connected). **Stop the service** after verification.
### 4.3 — Verify created tables
In PgAdmin4, under the AGV database > Schemas > public > Tables, there should be 7 tables: `agv_age`, `agv_ags`, `agv_eag`, `agv_inputqueue`, `agv_maintenance`, `agv_outputqueue`, `std_migrationinfo`. And 6 sequences: `agv_age_id_seq`, `agv_ags_id_seq`, `agv_eag_id_seq`, `agv_inputqueue_id_seq`, `agv_maintenance_id_seq`, `agv_outputqueue_id_seq`.
### 4.4 — Execute PostgreSQL scripts
Open the Query Tool in PgAdmin4 on the AGV database and execute:
**Script 1 — Notification function** (publishes an event on every row change):
```sql
CREATE FUNCTION public."NotifyOnDataChange"()
RETURNS trigger LANGUAGE 'plpgsql'
AS $BODY$
DECLARE
data JSON;
notification JSON;
BEGIN
IF (TG_OP = 'DELETE') THEN
data = row_to_json(OLD);
ELSE
data = row_to_json(NEW);
END IF;
notification = json_build_object(
'table', TG_TABLE_NAME,
'action', TG_OP,
'data', data);
PERFORM pg_notify('datachange', notification::TEXT);
RETURN NEW;
END
$BODY$;
```
**Script 2 — Trigger on the inputqueue table**:
```sql
CREATE TRIGGER "OnDataChange"
AFTER INSERT ON public.agv_inputqueue
FOR EACH ROW
EXECUTE PROCEDURE public."NotifyOnDataChange"();
```
## Step 5 — Configure the external PostgreSQL user
This user will be used by the Oracle DBLink to access the AGV tables from the WMS.
### 5.1 — Create the user
In PgAdmin4: create a login role `externalAGV` with a password and login privilege.
### 5.2 — Grant CONNECT on the database
In the AGV database properties > Security tab, add `externalAGV` with the **CONNECT** privilege.
### 5.3 — Grant permissions on tables and sequences
**Quick option (dev environment)**:
```sql
GRANT ALL ON ALL TABLES IN SCHEMA public TO "externalAGV";
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO "externalAGV";
```
**Restrictive option (production)** - minimum required permissions:
```sql
-- Tables
GRANT SELECT, INSERT, UPDATE ON agv_inputqueue TO "externalAGV";
GRANT SELECT, INSERT, UPDATE ON agv_ags TO "externalAGV";
GRANT SELECT, INSERT, UPDATE ON agv_age TO "externalAGV";
GRANT SELECT, UPDATE ON agv_outputqueue TO "externalAGV";
GRANT SELECT ON agv_eag TO "externalAGV";
-- Sequences
GRANT ALL ON agv_age_id_seq TO "externalAGV";
GRANT ALL ON agv_ags_id_seq TO "externalAGV";
GRANT ALL ON agv_inputqueue_id_seq TO "externalAGV";
```
## Step 6 — Configure the Oracle DBLink to PostgreSQL
This is the most delicate step. Oracle uses the **dg4odbc** component (Database Gateway for ODBC) to connect to PostgreSQL via the ODBC DSN created in Step 3. The configuration touches 3 Oracle files and requires a Listener restart.
### 6.1 — Edit tnsnames.ora
File: `[ORACLE_HOME]\network\admin\tnsnames.ora`
Add the following entry **at the end of the file**. The identifier `PostgreSQL35W` **must start at column 1** (no leading space or tab), otherwise Oracle will not recognize it as a valid TNS entry:
```
PostgreSQL35W =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
(CONNECT_DATA=(SID=PostgreSQL35W))
(HS=OK)
)
```
Leave a blank line between the previous entry and this one. `(HS=OK)` is mandatory - it tells Oracle this is a Heterogeneous Service (connection to a non-Oracle system).
> **Common error**: if the identifier is indented (space or tab before `PostgreSQL35W =`), Oracle returns `ORA-12154: TNS:could not resolve the connect identifier specified`. This is a subtle trap because the rest of the file works fine with indentation.
### 6.2 — Edit listener.ora
File: `[ORACLE_HOME]\network\admin\listener.ora`
Add a `SID_DESC` block in the existing `SID_LIST_LISTENER` section:
```
(SID_DESC =
(SID_NAME = PostgreSQL35W)
(ORACLE_HOME = C:\Mecalux\Motor\oracle\Product\19.27.0.0\dbhome_1)
(PROGRAM = dg4odbc)
)
```
> **Critical**: the `ORACLE_HOME` path in this block must be the **real, complete path** of your Oracle installation. Never leave a placeholder like `[VERSION]` - this causes `TNS-12518` / `ORA-28545` errors. The listener starts without error and the SID appears in `lsnrctl status`, making the problem hard to diagnose. **Verify** that the `ORACLE_HOME` in the PostgreSQL35W block is **identical** to the other `SID_DESC` blocks in the file.
### 6.3 — Create initPostgreSQL35W.ora
Go to `[ORACLE_HOME]\hs\admin\`, duplicate the file `initdg4odbc.ora`, rename the copy to `initPostgreSQL35W.ora` (name must match the SID_NAME exactly, case-sensitive), and replace all content with:
```
HS_FDS_CONNECT_INFO = PostgreSQL35W
HS_FDS_TRACE_LEVEL = 0
```
Do not leave the template lines from the original file. For debugging, temporarily set `HS_FDS_TRACE_LEVEL = 4` for detailed dg4odbc traces. Reset to 0 after diagnosis.
### 6.4 — Restart the Oracle Listener
```
lsnrctl stop
lsnrctl start
```
Verify that the SID `PostgreSQL35W` appears in the service list:
```
lsnrctl status
```
Expected output: `Service "PostgreSQL35W" has 1 instance(s). Instance "PostgreSQL35W", status UNKNOWN, has 1 handler(s) for this service...` The UNKNOWN status is normal for a Heterogeneous Service - the process is launched on demand.
### 6.5 — Grant CREATE DATABASE LINK to db_read
Connect as **sysdba** and grant:
```sql
GRANT CREATE DATABASE LINK TO db_read;
```
> The target user is **db_read** (the Easy WMS read model schema). The database link and synonyms must be owned by db_read. Do not create the link under SYS - it will not be visible from db_read.
### 6.6 — Create the Database Link
Connect as **db_read** (not sysdba):
```sql
CREATE DATABASE LINK AGV
CONNECT TO "externalAGV" IDENTIFIED BY "mecalux"
USING 'PostgreSQL35W';
```
> **Double quotes** around the user and password are **mandatory**. Oracle converts identifiers to uppercase by default, but PostgreSQL is case-sensitive. Without quotes, Oracle sends `EXTERNALAGV` instead of `externalAGV` and authentication fails.
### 6.7 — Test the DBLink
```sql
SELECT * FROM "agv_inputqueue"@AGV;
```
If the query returns `no rows selected`, the link works. The tables are simply empty at this stage.
### 6.8 — Create Oracle synonyms
Still connected as **db_read**:
```sql
CREATE SYNONYM agv_age FOR "agv_age"@AGV;
CREATE SYNONYM agv_ags FOR "agv_ags"@AGV;
CREATE SYNONYM agv_eag FOR "agv_eag"@AGV;
CREATE SYNONYM agv_inputqueue FOR "agv_inputqueue"@AGV;
CREATE SYNONYM agv_outputqueue FOR "agv_outputqueue"@AGV;
```
> Table names in double quotes are lowercase because PostgreSQL stores identifiers in lowercase by default.
Verify all synonyms: `SELECT * FROM agv_inputqueue;` (repeat for each). All queries must pass without error (`no rows selected` is expected).
## Step 7 — Install the AGV module in Easy WMS
### 7.1 — Modify response.xml
Add the AGV entries in the deployment `response.xml`:
```xml
<ExtraApps>
<Item Use="Yes" Name="AGV"
Url="http://[host]/packages/Mecalux.ITSW.AGV.Application.zip"
PackageUrl="http://[host]/packages/AGV.zip" />
</ExtraApps>
<Modules>
<Module Name="AGV" LicenseLevel="ENABLED" />
</Modules>
```
### 7.2 — Run the deploy
Execute the deploy using **option 16 — Install application**.
### 7.3 — Restart the Gateway AGV
After the deploy completes, restart the Gateway AGV service in `services.msc`.
## Troubleshooting
### DSN name case: PostgreSQL35W
The most frequent cause of failure. The DSN name must be **identical** (case-sensitive) across all 6 locations:
| File / Location | Expected value |
|-----------------|----------------|
| ODBC System DSN (data source name) | `PostgreSQL35W` |
| tnsnames.ora (TNS entry name + SID) | `PostgreSQL35W` |
| listener.ora (SID_NAME) | `PostgreSQL35W` |
| initPostgreSQL35W.ora (filename) | `initPostgreSQL35W.ora` |
| initPostgreSQL35W.ora (content) | `HS_FDS_CONNECT_INFO = PostgreSQL35W` |
| CREATE DATABASE LINK ... USING '...' | `'PostgreSQL35W'` |
### Indentation in tnsnames.ora
The TNS entry identifier (e.g., `PostgreSQL35W =`) must start at **column 1**, with no leading space or tab. Accidental indentation causes `ORA-12154: TNS:could not resolve the connect identifier specified`.
### Placeholder in listener.ora
The `ORACLE_HOME` in the PostgreSQL35W `SID_DESC` must be the **real path**. Leaving a placeholder like `[VERSION]` causes `TNS-12518` / `ORA-28545`. The listener starts without error and the SID appears in `lsnrctl status`, which makes the problem difficult to spot. Verify with: `dir C:\Mecalux\Motor\oracle\Product\`
### PostgreSQL 18+ port
PostgreSQL 18 defaults to port **5433** instead of 5432. Update **two locations**: the ODBC System DSN (Step 3) and the Gateway AGV connection string (Step 4).
### Double AGVConfig section
The Gateway XML config must contain exactly **one** `<AGVConfig>` section. Two sections (even with different `stationNumber` values) cause: `System.ArgumentNullException: Migration DataBase Provider No Initialized`.
### Double quotes in Oracle commands
Oracle converts identifiers to uppercase; PostgreSQL stores them in lowercase. When creating the database link and synonyms, PostgreSQL table names must be in double quotes (`"agv_inputqueue"`), and PostgreSQL credentials must also be in double quotes (`"externalAGV"`, `"mecalux"`).
### Database link and synonyms must be created under db_read
The database link and synonyms must be created while connected as **db_read**, not SYS. A link created under SYS is not visible from db_read, and the AGV monitoring views in the WMS use the read model schema.
### dg4odbc trace for diagnosis
If the DBLink fails (`ORA-28545`, `ORA-12154`, etc.), enable tracing in `[ORACLE_HOME]\hs\admin\initPostgreSQL35W.ora`:
```
HS_FDS_TRACE_LEVEL = 4
```
Restart the listener, retry the query, then look for the trace file in `[ORACLE_HOME]\hs\admin\` or the Oracle diagnostic directory. **Reset to 0 after diagnosis.** If no trace file is created, dg4odbc is not launching at all - the problem is in listener.ora (incorrect ORACLE_HOME or listener not restarted).
### Standalone ODBC connectivity test
To isolate an ODBC connection problem (bypassing Oracle/dg4odbc):
```powershell
$conn = New-Object System.Data.Odbc.OdbcConnection
$conn.ConnectionString = "DSN=PostgreSQL35W;Uid=externalAGV;Pwd=mecalux;"
$conn.Open()
$conn.State # Should display "Open"
$conn.Close()
```
If this test passes but the Oracle DBLink fails, the problem is in the dg4odbc configuration (Oracle files), not the ODBC connection itself.
## Related
- [AGV — Automated Guided Vehicles](../modules/agv.md) — Functional documentation: architecture, protocol, monitoring, errors
- [Stations](../concepts/stations.md) — Station types including AGV (type 65), equipment groups, routes
wiki/operations/code-review-process.md
+190
View File
@@ -0,0 +1,190 @@
---
title: "Code Review Process (Code, Functional, Documentation)"
type: operation
sources:
- sources/archives/Revue_Code.md
- sources/archives/Revue_Fonctionnel.md
- sources/archives/Revue_Documentation.md
related:
- operations/git-workflow.md
- operations/git-branch-lifecycle.md
- operations/custom-application-management.md
- operations/development-methodology.md
last_compiled: "2026-04-17"
---
# Code Review Process (Code, Functional, Documentation)
## Overview
Procédure interne Mecalux EasyWMS France pour la **revue d'une tâche de développement custom** avant intégration sur `develop`. La revue se fait sur **trois axes** complémentaires, généralement par des reviewers distincts (parfois cumulés) :
1. **Revue Code** — qualité technique, conventions de nommage, identification du custom (`CST_`), gestion des `null`, erreurs classiques sur le modèle Outbound/Kit
2. **Revue Fonctionnel** — exécution des cas de test Jira, comportement des touches `Enter` / `Échap` sur les dialogues
3. **Revue Documentation** — Jira commentée, présence des éléments dans la branche Git, mise à jour du **reten** (manuel de retention en Markdown — cf. [development-methodology](development-methodology.md))
Sources : Confluence EasyWMS France — *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024).
> Référentiel global Mecalux Espagne : [code review checklist](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/code_review/index.md), [nomenclature](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/nomenclature/index.md), [null management best practices](https://msscc.mecalux.com/documentation/Development/master/ES/map_application_development/null_management_best_practices/index.md).
---
## 1. Revue Code
### 1.1 Pièges sur les requêtes Outbound
**`OutboundLines` vs `OutboundOrderLines`** :
> ⚠️ Sur les requêtes en **writing**, utiliser **`OutboundLines`** (pas `OutboundOrderLines`).
Avec `OutboundOrderLines`, dès qu'une ligne d'ordre de sortie est annulée, on obtient dans les logs :
```
Le nombre de ligne d'ordre d'expédition ne peut pas être négatif
```
### 1.2 Kits sans assemblage : `OutboundOrderOutboundOrderLineDetails`
Si le projet utilise les **kits sans assemblage** (cf. [kits](../concepts/kits.md)) :
| Propriété | Contenu |
|---|---|
| `OutboundOrderOutboundOrderLineDetails` | **Tous les composants** du kit |
| `OutboundLines` | **Uniquement le kit lui-même** |
### 1.3 `OutboundLine.ProductConversion` peut être `null`
> ⚠️ Sur les requêtes en **writing**, l'attribut `ProductConversion` d'une ligne d'ordre de sortie peut être `null`.
Cas : la commande demande un **support spécifique** sans article — on a alors le **code support renseigné mais pas l'article**, donc pas de conversion produit.
### 1.4 Identification du custom dans le code
**Délimiter les blocs de code custom** ajoutés au milieu de code standard :
```csharp
potentiel code standard
//StartCustom
Code custom
//EndCustom
potentiel code standard
```
### 1.5 Préfixe `CST_` sur les éléments custom
Chaque nouvel élément ou élément modifié doit être **préfixé `CST_`**. Trois questions à se poser :
| Question | Règle |
|---|---|
| L'élément est-il **visible par le client** ? | **Pas de préfixe** (ex : les paramètres SmartUI ne prennent pas `CST_`) |
| Peut-on **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 l'élément de **plus haut niveau** ? | Dans un **workflow custom**, seul le **workflow** porte le préfixe ; ses sous-éléments ne le portent pas. Inversement dans un **workflow standard**, **tous** les éléments ajoutés/modifiés prennent le préfixe |
> ⚠️ **À ne pas oublier :**
> - Un **dialogue est modifié** même si on ne change que l'**implémentation de l'activité**
> - Les **transitions** doivent aussi être identifiées
>
> ⚠️ Lors du passage d'un workflow de **"partial overriden" → "overriden" (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).
### 1.6 Nommage des éléments
| Type d'élément | Règle de nommage |
|---|---|
| **ViewField** d'une vue | 2 préfixes + code du viewfield → `ViewField_<Vue>_<Champ>` (ex : `ViewField_OutboundOrderVList_OutboundOrderStatus`) |
| **Paramètres SmartUI** | Préfixer du process impacté, en MAJUSCULES (ex : `EXPEDITION_ALLOWED_CONTAINER`) |
| **Attributs d'un workflow** | Commencent par une **minuscule** (ne pas oublier `CST_` dans un workflow standard) |
| **Paramètres formels d'un workflow** | Commencent par une **majuscule** |
| **Paramètres d'un dialogue** | Commencent par une **majuscule** |
| **Paramètres d'une requête** | Commencent par une **minuscule** |
### 1.7 Pas de "code en dur" dans les workflows
Éviter les constantes en dur. En particulier, les actions **"Enter"** et **"Escape"** après un dialogue doivent utiliser :
| Variable | Usage |
|---|---|
| `ProcessContext.EnterAction` | Tester l'appui sur `Entrée` |
| `ProcessContext.EscapeAction` | Tester l'appui sur `Échap` |
### 1.8 Gestion des `NullReferenceException`
Particulièrement : **`FirstOrDefault()`** doit être sécurisé.
```csharp
// ❌ Dangereux — exception si aucun ordre n'existe
Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines
// ✅ Sécurisé
var order = Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode);
if (order != null) { ... }
```
---
## 2. Revue Fonctionnelle
### 2.1 Exécution des cas de test
Exécuter **tous les cas de test fonctionnel** décrits dans la tâche Jira. À défaut, exécuter les **cas standard d'utilisation du custom**.
### 2.2 Tester `Échap` sur les dialogues
Pour chaque dialogue ajouté ou modifié, tester le comportement de la touche **`Échap`** en se posant la question :
> Que veut faire l'opérateur en pressant Échap ?
> - **Revenir à l'écran précédent** ?
> - **Passer à la suite du process** ?
> - **Ne rien faire** ?
Le comportement par défaut peut ne pas être celui attendu fonctionnellement → bien tester explicitement.
> Lié à la règle **1.7** ci-dessus : `ProcessContext.EscapeAction` doit être utilisé pour intercepter `Échap` proprement.
---
## 3. Revue Documentation
### 3.1 Jira
Vérifier que **les éléments modifiés** sont décrits et que les modifications sont **explicites dans les commentaires** de la tâche.
### 3.2 Git
Vérifier la **présence des éléments modifiés** dans la branche Git concernée (cf. [git-branch-lifecycle](git-branch-lifecycle.md)).
> Vérification utile : l'**historique des commits** Git du développeur pour s'assurer qu'il n'a **pas inclus de modifications hors périmètre** de sa tâche. Ce cas survient quand le dev a été réalisé **avec une custom app qui n'était pas au même "niveau"** que la branche sur laquelle il l'exporte (typiquement : création de la branche **après** import de la custom app dans le Builder, alors que d'autres commits ont eu lieu entre temps).
>
> Cf. [custom-application-management](custom-application-management.md) — règles d'import/export pour éviter ce cas.
### 3.3 Reten
Vérifier que la description de la tâche est **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 dans les **chapitres de process** (Entries, Exits, Picking, etc.) avec **description fonctionnelle, technique et é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 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 |
> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#manuel-de-reten)).
---
## Common errors (revue détecte)
- **Erreur "Le nombre de ligne d'ordre d'expédition ne peut pas être négatif"** dans les logs → utilisation de `OutboundOrderLines` au lieu de `OutboundLines` sur une requête writing
- **NullReferenceException** sur des chaînages `.FirstOrDefault(...).Property` → assigner d'abord à une variable + tester `null`
- **Workflow "overriden" sans préfixe `CST_`** sur les activités modifiées → relire le workflow précédent en parallèle pour identifier toutes les modifs
- **Élément hors périmètre de la tâche dans le commit** → custom app importée à un niveau différent de la branche ; ré-importer après pull/rebase
- **Reten non mis à jour** → bloquant pour la revue documentation (le projet ne pourra pas être maintenu post-MEP sans le reten)
- **`Échap` sur dialogue produit un comportement involontaire** → manquait un test fonctionnel `ProcessContext.EscapeAction`
## Related
- [Git Workflow (Git Flow)](git-workflow.md) — workflow Git Flow où s'insèrent les revues (avant `Finish Feature`)
- [Git Branch Lifecycle](git-branch-lifecycle.md) — la revue est faite avant l'intégration dans `develop` (phase 1)
- [Custom Application Management](custom-application-management.md) — règles d'import/export pour éviter les modifs hors périmètre
- [Development Methodology](development-methodology.md) — vue d'ensemble (reten, branches, custom apps)
- [Kits](../concepts/kits.md) — utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage)
wiki/operations/configuration-guide.md
+566
View File
@@ -0,0 +1,566 @@
---
title: "Configuration Guide"
type: operation
sources:
- configurations/reception_configuration01.md
- configurations/tense_flow_configuration01.md
- configurations/crossdocking/crossdocking_configuration01.md
- configurations/counts/count_configuration01.md
- configurations/picking/picking_PTL_configuration.md
- configurations/replenishments/picking_location.md
- configurations/replenishments/intermediate_stations.md
- configurations/replenishments/dynamic_replenishment_maxnumlots.md
- configurations/multi_carrier_shipping/multi_carrier_shipping_configuration01.md
- configurations/supply_chain_event_management/supply_chain_event_management_configuration01.md
- wiki/concepts/parameters.md
- wiki/concepts/putaway.md
- wiki/concepts/replenishment.md
- wiki/concepts/reception.md
- wiki/concepts/count.md
- wiki/concepts/crossdocking.md
- wiki/architecture/overview.md
related:
- concepts/parameters.md
- concepts/stations.md
- concepts/warehouse-designer.md
- concepts/putaway.md
- concepts/replenishment.md
- architecture/overview.md
- architecture/security.md
last_compiled: "2026-04-10"
---
# Configuration Guide
Deployment and setup guide for Easy WMS. Organized in dependency order: complete earlier sections before later ones. For parameter details, see [Parameters](../concepts/parameters.md). For troubleshooting, see [Troubleshooting](troubleshooting.md).
---
## 0. Pre-Deployment Checklist
Before configuring Easy WMS, verify the infrastructure:
| Item | Requirement |
|------|-------------|
| **IIS version** | IIS 10+ on Windows Server 2019 or later |
| **Application pools** | Main pool + Background Jobs pool + Integration pool — all configured as .NET CLR v4 |
| **Database** | Oracle 19c+ or PostgreSQL 13+ |
| **Environment variable** | `ASPNETCORE_ENVIRONMENT = Production` (not Development) |
| **WIFI** | 802.11n/ac coverage in all RF terminal work areas; separate VLAN for WMS traffic |
| **Label printers** | Zebra or equivalent configured per network port |
| **EasyS** | Layout configuration tool installed and validated before WMS go-live |
---
## 1. Warehouse Layout (EasyS)
All physical warehouse configuration is done in **EasyS** (the visual layout configurator), not in the WMS UI. Changes made in EasyS are deployed to the WMS as a "transfer" that must be validated.
### 1.1 Warehouse and Zone Setup
1. Create the **warehouse** entity with type (manual / automatic / mixed).
2. Define **sub-warehouses** if needed (physical separation or different logistics rules).
3. Create **storage zones** — group aisles by temperature, hazard class, or ABC zone.
4. Create **working zones** — assign equipment types with permission per process (reception, putaway, picking, replenishment, count).
### 1.2 Location Types
Configure location type properties:
- **Storage mode**: Container, loose stock, or both.
- **Storage logics** (12 flags): Allow picking, allow shipping, allow replenishment source/target, allow count, is crossdocking, etc.
- **Capacity**: Max weight, max containers, max height.
- **FIFO/LIFO**: Applied per location or location type.
Key location types to configure:
| Type | Use | Notes |
|------|-----|-------|
| Conventional (rack) | Standard pallet storage | Most common type |
| APS / APSFIFO | 3D automated shuttle | Requires APS3D module |
| Compact channel | Pallet Shuttle, mobile racking | Deep-lane storage |
| Dynamic | Flow rack | Separate FIFO entry/exit lanes |
| Buffer | Stage/transit locations | For ET stations |
| Dock | Inbound/outbound docking | Required for yard management |
| Picking dedicated (PDL) | First-level picking shelf | "Allow replenishment target" must be enabled |
### 1.3 Station Configuration
For each process, at least one station of the appropriate type is required:
| Station Type | Code | Required For |
|--------------|------|--------------|
| Dock | 34 | Inbound/outbound vehicle docking |
| Stage | 33 | Pre/post-dock staging |
| PIE | — | Automatic inbound sorter |
| PK conveyor | 2 | Picking/reception workstation |
| ALM | — | Storage station |
| ME/MU/MS | — | Multi-exit/multi-unit/multi-stock conveyors |
| ET (Transit) | — | Intermediate replenishment station |
| Consolidation | 17 | Order consolidation |
| Decision | 63 | Routing decision point |
| Workzone | 64 | Manual picking zone |
| PS charge | 66 (PSCharge) | Pallet Shuttle charging |
**Route configuration:** Every station pair that needs to exchange containers/stock requires an explicit route. Define: Origin → Destination → Transport type → Process → Task type.
### 1.4 Equipment Types and Instances
1. Create **equipment types** (forklift, hand truck, conveyor, AGV, etc.).
2. Assign process permissions per work zone.
3. Create **equipment instances** and assign to types.
4. Configure **container type compatibility** per equipment type.
5. For PTL: assign PTL controller to each PTL-equipped equipment.
---
## 2. Master Data Configuration
### 2.1 Container Types (LPN Types)
Defined in EasyS. Key attributes:
- Dimensions (L × W × H in mm), empty weight, max weight.
- Stackability, collapse distance (for width calculations).
- Division types (for automatic warehouse only).
### 2.2 Items
1. Create items in WMS UI or via **ITM ERP message**.
2. Assign mandatory profiles:
- **Reception profile** — required before any receipt can be created.
- **Shipping profile** — required before any shipping order line can be assigned.
- **Putaway profile** — optional; if absent, default warehouse strategy is used.
- **Count profile** — required for ABC-driven cycle counts.
3. Configure logistic attributes (lot, expiry, serial number, quality, etc.) per item or item type.
4. Set UoM and conversions; define base UoM clearly.
5. For cutting stock items: assign cutting profile with min/max quantities, cutting tolerance, and label configuration.
### 2.3 Suppliers, Carriers, Owners, Accounts
- Suppliers: required before receipt orders can be created.
- Carriers: required before shipping orders with carrier assignment are processed. Extended carrier attributes required for Multi-Carrier module.
- Owners / Accounts: required when Owner Extensions module is active (mandatory for 3PL billing and 3PL portal).
---
## 3. Reception Configuration
### 3.1 Core Parameters
| Parameter | Default | Effect |
|-----------|---------|--------|
| `ALLOW_CREATE_RECEPTION` | — | Allow WMS to create a receipt without a pre-existing order |
| `AutoCloseReception` | — | Auto-close receipt when all lines are fulfilled |
| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | — | Block ASN reception if referenced receipt order is missing |
| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | — | Minimum remaining shelf life required at reception |
| `LPN_CHECK_CODE_GS1LABEL` | — | Validate LPN code against GS1 SSCC format |
| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | — | Prevent LPN code reuse (vs station codes, locations, aliases) |
### 3.2 PIE Station (Automatic Inbound)
Configure rejection handling — all PIE error types must have an explicit rejection route:
| Error Type | Destination |
|------------|-------------|
| Dimensional error | Rejection station |
| Weight error | Rejection station |
| Unknown container | Reconditioning station |
| ASN mismatch | Reconditioning station |
If receiving without RFT (containers enter PIE directly):
1. Configure a pre-PIE conveyor as a **Picking** station.
2. Assign a workstation (PC) to this conveyor.
3. Create route: PK → PIE → Inbound conveyor (or location table).
### 3.3 Dock Reception (Manual Warehouse)
- Each dock requires a stage for pre-docking buffers.
- Configure `Dock work mode`: Manual (operator decides putaway timing) or Automatic.
- Printer assigned to dock for LPN label printing.
### 3.4 Returns Reception
- Configure `RECEPTION_RETURN_ALLOW_AUTOSELECTION` to allow automatic item identification on returns.
- `RETURN_ALLOW_AUTOSELECTION` (eCommerce variant) governs eCommerce return flows.
---
## 4. Putaway Configuration
### 4.1 Strategy Sequence
Putaway strategies execute in order. The recommended sequence for most deployments:
1. **Assigned location** (PDL / item-assigned location) — highest priority.
2. **Channel filling** (compact, APS) — fill partially-occupied channels first.
3. **Storage zone by ABC** — A-class items near pick face; C-class items at depth.
4. **Crossdocking zone** (if applicable) — for items with `Enable crossdocking` active.
5. **Default zone** — catch-all for any remaining containers.
Key strategy attributes:
| Attribute | Description |
|-----------|-------------|
| Is crossdocking | Route eligible stock directly to XD locations |
| Loose stock | Place individual stock lines, not the container |
| Aisle balance | Distribute containers evenly across aisles |
| Relocation % | Maximum fill % before aisle stops accepting new containers |
### 4.2 Restrictions
Configure restrictions to prevent mixing incompatible items in the same location/aisle/zone:
- "Do not locate in same zone" — e.g., hazardous + non-hazardous.
- "Do not locate in same aisle" — e.g., temperature classes.
- "Do not fit on higher heights" — for fragile items.
- "Do not putaway adjacent" — for certain chemical incompatibilities.
### 4.3 PDL Creation (Picking Dedicated Locations)
PDLs are configured per item per location. Required settings:
- **Maximum stock level** — triggers top-off replenishment.
- **Minimum stock level** — triggers stockout replenishment.
- **Replenishment mode** — Container or Stock.
- **Enable automatic replenishment** — must be explicitly checked.
- **Delete when empty** — enable for seasonal items only.
For locations with drawers/boxes (small parts): use partition labels with pre-generated coordinates. Enable `RF_PICKING_CONFIRM_LOCATION` to require location scan at picking.
### 4.4 Intermediate Station Replenishment
When PDLs and stock source are in physically separate zones that cannot be directly routed:
1. Create ET (transit) stations between the zones with Buffer-type locations.
2. Enable "Container" storage mode at intermediate stations.
3. Configure equipment of type that allows replenishment tasks for each zone.
4. Create RF routes: source zone equipment → ET station; PDL zone equipment → ET station.
5. Even for loose stock replenishment: containers must be used when transiting through ET stations.
---
## 5. Picking Configuration
### 5.1 Core Picking Parameters
| Parameter | Default | Effect |
|-----------|---------|--------|
| `RF_PICKING_CONFIRM_LOCATION` | — | Require location scan before picking |
| `MAX_CONTAINER_WEIGHT` | — | Client container weight limit |
| `PICK_AND_PASS_ENABLED` | — | Enable Pick & Pass mode |
| `VOICE_ENABLED` | — | Enable voice-guided picking |
| `CUTTING_PRINTER` | — | Printer for cutting stock labels |
### 5.2 PTL Configuration (Pick To Light / Put To Light)
1. Install and configure the **PTL Service** (separate Windows service).
2. Create a warehouse station of type **Pick To Light** with a looped route (to itself).
3. For Put To Light: assign separate equipment group; create routes to both the main warehouse station and the PTL station (transport type: Pick To Light).
4. Assign PTL controller to each PTL-equipped equipment in EasyS.
5. For each extra location on the equipment: configure storage mode (stock or container, never both).
6. Container equipment extra locations: max containers = 1 per location; configure container type compatibility.
### 5.3 Workstation (PK) Configuration
- Assign a PC workstation to the PK conveyor station.
- Configure working mode: "All Modes", "Picking Only", or "Consolidation Only".
- For consolidation tasks: must be "All Modes" or "Consolidation Only".
- For PTL: ensure PTL service is running and controller assignments are correct.
### 5.4 Wave and Group Shipping Templates
- Create **shipping templates** in `Configuration > Shipping templates`.
- Templates define which orders are batched together (by carrier, priority, route, etc.).
- For grouped picking (wave): ensure all orders in the group share compatible container type requirements.
---
## 6. Replenishment Configuration
### 6.1 Strategy Types and Use Cases
| Strategy | Trigger | Best Used When |
|----------|---------|----------------|
| Top-off | PDL stock < maximum | Constant high-velocity picking |
| Stockout | PDL stock = 0 | Lower-frequency items |
| Shipping demand | Open outbound order has no PDL stock | On-demand preparation |
| Sub-warehouse | Sub-WH stock below min | Multi-zone warehouse separation |
### 6.2 Dynamic Replenishment
The `TryToReplenishProductLocations` background job runs automatically. Configure:
- Job schedule (recommended: every 5–15 minutes).
- `MAX_NUM_LOTS_REPLENISHMENT` — maximum lot lines per replenishment container (prevents mixing).
### 6.3 Replenishment from Picking Locations
Used for locations with boxes/drawers (small parts):
1. Assign minimum and maximum stock levels per PDL.
2. Enable `Stockout` strategy.
3. Place stock in a nearby storage location for FEFO/FIFO compliance.
4. If FIFO/FEFO required: configure the PDL's source location to "take from height" — the system maintains the FEFO sequence during replenishment.
---
## 7. Count Configuration
### 7.1 Location Prerequisites
For a location to be countable:
1. `Allow count` = True on the location in EasyS.
2. Count aisle defined for the location.
3. Equipment type must have count permission for the location's work zone.
4. Location not locked with a lock type that blocks counting.
5. Containers/stock not locked with types that block counting.
### 7.2 Lock Types for Count
Configure per lock type (in `Masters > Lock Types`):
- **Location lock types**: "Allow count" flag.
- **Container lock types**: "Allow count" flag.
- **Stock statuses**: "Allow count" flag.
### 7.3 Cycle Count Setup
1. Create a **count schedule**: item ABC class, warehouse zones, and frequency (how many items per iteration).
2. Create **count iterations** from the schedule: each iteration covers a subset of the total item population.
3. Generate **count order** from iteration: produces location or item count tasks.
4. Cycle count orders are **non-re-releasable** once canceled — create new orders if needed.
### 7.4 Double Validation
Enable per item (count profile) when count discrepancies require manager approval:
1. Activate `DOUBLE_VALIDATION_ACTIVE` or configure per item profile.
2. Count discrepancies enter "Pending Adjustment" state.
3. Manager validates or cancels from `Warehouse > Stock adjustments`.
4. COF ERP message sent only after all pending adjustments are resolved.
---
## 8. Crossdocking Configuration
Three mandatory configuration elements:
### Step 1 — Enable crossdocking on items
`Inventory > Items > item > "Enable crossdocking"` attribute = True.
### Step 2 — Configure crossdocking locations
In EasyS: activate **"Is crossdocking location"** on target locations.
### Step 3 — Create crossdocking putaway strategies
- Create strategies with **"Crossdocking"** attribute enabled.
- For placing loose stock (partial container): also enable **"Loose stock"** attribute.
- For placing whole containers: use a strategy with "Crossdocking" only (no "Loose stock").
- Strategies must be **enabled** (active) to be used.
**Reception requirement:** Crossdocking to warehouse requires receipt on an **equipment** (via RFT), not directly at a stage.
**Coverage check logic:** Before ordering crossdocking, WMS checks whether existing crossdocking locations already have sufficient stock to cover the open outbound line quantity. If yes, no crossdocking is ordered.
---
## 9. Quality Control Configuration
### 9.1 Stock Status Setup
1. Create stock statuses in `Masters > Lock Types > Stock Statuses`.
2. Per status, configure allowed/blocked operations (allow picking, allow shipping, allow replenishment, allow count, allow adjustment).
3. Set automatic unlock duration (days) for time-based unlocks.
### 9.2 Automatic Unlock Job
- Job: `Delete_StockStatusJob_PR`
- Recommended schedule: every 15 minutes.
- Ensure job is active in `Configuration > Jobs`.
### 9.3 Receiving Status at Reception
Configure per item reception profile:
- **Receiving status**: applied automatically at receipt (e.g., "Under inspection").
- **User status**: manually applied post-receipt (e.g., "Quarantine").
- STC message to ERP is sent at reception close (not at status application).
---
## 10. ERP Integration Configuration
### 10.1 Message Configuration
For each ERP message type to be processed, configure:
- **Message direction**: inbound (ERP→WMS) or outbound (WMS→ERP).
- **Processing mode**: synchronous or asynchronous.
- **Queue**: dedicated queue per message family is recommended.
Key message pairs to configure at go-live:
| ERP → WMS | WMS → ERP |
|-----------|-----------|
| ROR (receipt orders) | ROC (order status) |
| ASN (pre-notifications) | ROF (fulfilled) |
| SOR (shipping orders) | SOC (order status) |
| ITM (items) | SOF (fulfilled) |
| STR (stock lock) | STV (stock change) |
### 10.2 Integration Application Pool
- Separate IIS pool from main application.
- Monitor for stops — ERP messages queue if integration pool is down.
- Log location: check both IIS logs and WMS application logs.
### 10.3 API Keys
- Generate API keys per integration consumer (ERP, MCP server, external tools).
- Keys are regenerated in integration configuration.
- Use HTTPS for all API communication.
---
## 11. Module-Specific Configuration
### 11.1 Multi-Carrier Shipping
1. Create **extended carrier** records (carrier + Multi-Carrier specific fields: tracking files directory, manifest report, dock confirmation mode).
2. Configure **packaging stations** with source/destination routes.
3. Set up carrier tracking file archives directory on the server.
4. Configure **auto-selection rules** if automatic carrier assignment is needed.
5. For TNT: configure `Load manifest report` in extended carrier setup.
### 11.2 Supply Chain Event Management (SCEM)
Setup sequence:
1. Create **transports** (`Notifications > Configuration > Transports`): e-mail server, SMS gateway, or web endpoint.
2. Create **notification profiles** per user: transport + schedule (days/hours).
3. Create **filters** if needed (to limit alarms to specific conditions).
4. Subscribe users to relevant **notification events** (SCEM admin or user self-service).
Key events to subscribe for go-live monitoring:
| Event | Severity | When to Subscribe |
|-------|----------|--------------------|
| `Notification_GNAImportError` | Error | Always — ERP message parsing failures |
| AGV error codes (1001–2503) | Error | If AGV module active |
| PS fault/tilt | Error | If Pallet Shuttle module active |
| Stock failure on outbound order | Warning | Always — operational visibility |
### 11.3 Yard Management
Initial configuration sequence (10 steps):
1. Configure **commodities** (product categories for dock compatibility).
2. Configure **vehicle types**.
3. Create **carriers** with yard-specific fields.
4. Create **parking lots** (external waiting area zones).
5. Create **checkpoints** (physical security gates with attributes: weight control, advance/delay tolerance).
6. Create **docks** with compatibility rules (commodity × vehicle type).
7. Configure **work order types** (receipts and loads linkable to appointments).
8. Set up **ERP/TMS integration** (if external TMS sends appointments).
9. Configure **advance/delay windows** per yard or carrier.
10. Configure **auxiliary appointment types** for maintenance, cleaning, etc.
### 11.4 Labor Management (LMS)
1. Configure one **labor management profile per warehouse** (LMS is per-warehouse).
2. Define **processes** and their activities (maps to WMS task/process types).
3. Configure **equipment speeds** per equipment type (m/min for horizontal, m/min for vertical).
4. Set **warehouse layout dimensions** (aisle lengths, rack heights) used for target time calculations.
5. Choose **behavior mode** per process (no tolerance / allowed tolerance / fixed / flexible / ultra-flexible).
6. Enable RFT countdown display if desired.
### 11.5 3PL Billing
Prerequisites: **Owner Extensions** module must be configured first.
1. Assign owners to all receipt orders, shipping orders, and stock.
2. Create **billing contracts** per owner.
3. Within each contract, create **rules** (standard or custom).
4. Create **billing planners** (schedule: daily, weekly, monthly).
5. Configure **pre-validation workflow** if approval required before invoice generation.
### 11.6 AGV
1. Configure AGV equipment instances and types in EasyS.
2. Define AGV routes to all storage locations the AGVs will service.
3. Configure **load types**: 0 = Container, 1 = Pallet Shuttle.
4. Set up error notification subscriptions (AGV group) for operations staff.
5. Configure **RFT fallback mode** for manual operation during AGV downtime.
### 11.7 Slotting
1. Run initial **rotation analysis** (historical or current mode) to establish baseline ABC classification.
2. Review **golden zone** recommendations.
3. Configure **slotting profit formula** parameters (move cost, stay cost, daily rotation thresholds).
4. Enable **continuous slotting** background job for ongoing optimization.
5. Execute recommendations via **Slotting desk** (admin accepts/rejects suggested moves).
---
## 12. Security Configuration
### 12.1 Role Hierarchy Setup
Create roles from most to least permissive; assign permissions explicitly per role:
| Role | Primary Permissions |
|------|-------------------|
| SuperAdmin | Full system access; create roles |
| Administrator | Configure warehouse, masters, parameters |
| Manager | Approve adjustments, supervise operations |
| Operator | Execute WMS processes (reception, picking, shipping) |
| RF Operator | RFT-only access; assigned station roles |
| 3PL Client | Owner-filtered read access (requires Owner Extensions) |
| SCEM Admin | Notification subscription management |
### 12.2 Station Roles
Assign station roles to users/roles:
- Role determines which station types the user can log into from the RFT.
- Station role is checked at RFT login — rejected if not assigned.
### 12.3 Owner Isolation (3PL)
1. Enable **Owner Extensions** module.
2. Assign an owner to each user account intended for 3PL clients.
3. All master data created by the owner user is automatically prefixed with owner code.
4. Configure **3PL Portal** access per owner (read-only views: stock, orders, KPIs).
---
## 13. Parameter Reference Summary
Key parameters to review at each deployment. Full documentation in [Parameters](../concepts/parameters.md).
### Reception
- `ALLOW_CREATE_RECEPTION` — allow blind receipts
- `AutoCloseReception` — auto-close on completion
- `LPN_CHECK_CODE_GS1LABEL` — enforce GS1 SSCC format
- `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` — shelf life check at receipt
### Picking
- `RF_PICKING_CONFIRM_LOCATION` — enforce location scan
- `PICK_AND_PASS_ENABLED` — enable Pick & Pass mode
- `VOICE_ENABLED` — enable voice picking
### Replenishment
- `MAX_NUM_LOTS_REPLENISHMENT` — lot mixing limit per container
- TryToReplenishProductLocations job schedule
### Defragmentation
- `MAX_DEFRAG_TASKS` — max concurrent defragmentation tasks
- `MAX_OPTIMIZATION_DEFRAG_CHANNEL` — max channels optimized per run
- `MAX_DEFRAG_ATTEMPT` — retries before skipping a container
### AGV / Pallet Shuttle
- `PS_MAX_MINUTES_BATTERY_FULL_LOAD` = 300 (max battery life under load)
- `PS_MIN_MINUTES_BATTERY_LOAD` = 90 (minimum before return to charge)
### Multi-Carrier
- `MC_TRACKING_ARCHIVES_PATH` — carrier tracking files directory
- `MC_DEFAULT_CARRIER` — fallback carrier if auto-selection fails
---
## Related
- [Parameters](../concepts/parameters.md) — Complete parameter reference with all values
- [Troubleshooting](troubleshooting.md) — Error resolution guide
- [Stations & Routes](../concepts/stations.md) — Full station type reference
- [Warehouse Designer](../concepts/warehouse-designer.md) — EasyS-based layout configuration
- [Putaway](../concepts/putaway.md) — Strategy pipeline and configuration details
- [Replenishment](../concepts/replenishment.md) — PDL and strategy configuration details
- [System Architecture](../architecture/overview.md) — IIS, pools, and background jobs
- [Security](../architecture/security.md) — Roles, authentication, and permissions
wiki/operations/custom-application-management.md
+134
View File
@@ -0,0 +1,134 @@
---
title: "Custom Application Management"
type: operation
sources:
- sources/archives/Gestion_custom_application.md
related:
- architecture/application-dictionary.md
- operations/development-methodology.md
- operations/first-deployment.md
- operations/deployment-existing-app.md
- operations/git-workflow.md
- operations/code-review-process.md
last_compiled: "2026-04-17"
---
# Custom Application Management
## Overview
Procédure de **gestion de la custom application** EasyWMS (extension AD projet) via **EasyBuilder** : création, import et export. La custom app contient l'ensemble des éléments AD spécifiques au projet (Commands, Queries, Entities, Workflows, Dialogs…) compilés au-dessus du core EasyWMS et des modules standards activés dans le `DeployConfig.yaml`.
> ⚠️ Plusieurs développeurs peuvent travailler sur un même projet depuis des VM différentes. Une **gestion rigoureuse de la CustomApp** et une **bonne communication** sur l'avancement sont indispensables pour éviter les écrasements.
Règles de base :
- **Exporter** la CustomApp **à chaque fin de tâche** (après tests locaux)
- **Réimporter** la CustomApp de `develop` **après merge** de votre branche dans `develop`
- Si vous **rejoignez un projet en cours** → l'**import** de 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.
Source : Confluence EasyWMS France — *Gestion de la custom application* (v12, 20/12/2022).
## <a id="creation"></a>1. Création de l'application custom
À n'exécuter qu'**une seule fois par projet** (le premier développeur). Les autres devs font un **Import** (cf. section 2).
### Option A — Partir d'une app existante du Toolkit
Si le projet réutilise des modifications déjà packagées dans le dépôt [**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** en local
2. Réaliser l'import (cf. section 2) depuis :
```
..\FRANCE_OPERATIONS_TOOLS\<Ma modif voulue>
```
Exemple : `..\FRANCE_OPERATIONS_TOOLS\Module transporteur`
### Option B — Créer une application vierge
Dans **EasyBuilder** :
1. **Clic droit sur "Application"** → **"New application"**
2. Saisir le nom de l'application
3. Définir les dépendances (en général : **`EasyWMS`**)
### Premier export
Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt GIT (cf. section 3) pour initialiser `..\source\NomApplication` et permettre aux autres devs d'importer.
## <a id="import"></a>2. Import de l'application custom
> ⚠️ **Avant d'importer**, il faut d'abord **supprimer** la CustomApp existante dans votre Builder local.
### Procédure d'import
1. Dans EasyBuilder : clic droit sur l'application custom existante → **"Delete application"**
2. Clic droit sur **"Applications"** → **"Import and save application from text"**
3. Sélectionner le chemin dans votre dépôt GIT :
```
..\source\NomApplication
```
### Quand importer
| Situation | Import ? |
|-----------|----------|
| Vous rejoignez un projet en cours | **Oui** (première action) |
| Vous venez de merger votre branche dans `develop` | **Oui** (réimporter le `develop` à jour) |
| Un collègue a poussé une modif majeure sur `develop` | **Oui** après `git pull` |
| Vous démarrez la journée sur votre branche perso | **Non** — travailler sur votre export local |
## <a id="export"></a>3. Export de l'application custom
### Pré-requis
> ⚠️ **Avant l'export**, **vider** le dossier de destination dans le dépôt GIT :
> ```
> ..\source\NomApplication
> ```
> Sinon, des anciens fichiers orphelins peuvent rester et polluer le diff.
> ⚠️ Bien vérifier d'être sur **la branche de votre tâche** avant d'exporter.
> ⛔ **Aucun élément en "Check-out" n'est sauvegardé ni exporté.** Tous les Check-in doivent être effectués avant l'export.
### Procédure d'export
1. Dans EasyBuilder : clic droit sur l'application custom → **"Export application to text"**
2. Sélectionner le chemin :
```
..\source\NomApplication
```
### Suites logiques
- **Commit + push** sur la branche de votre tâche — cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications)
- Les fichiers exportés peuvent être **séparés en plusieurs** pour un même élément AD (workflow, source C#, DESIGN…). Bien prendre **tous** les fichiers portant le nom de l'élément modifié.
## Règles de coexistence multi-développeurs
| Situation | Action |
|-----------|--------|
| Plusieurs devs sur le projet | Chacun sur sa **branche GIT personnelle** (cf. [development-methodology](development-methodology.md)) |
| Éviter les écrasements | **Export systématique** en fin de tâche + **import** après merge dans `develop` |
| Éléments en Check-out | À **Check-in avant export** — sinon perte silencieuse |
| Structure commune (toolkit) | Utiliser **FRANCE_OPERATIONS_TOOLS** en option A de création |
## Common errors
- **Perte de développements après import** → la CustomApp locale contenait des changements non exportés. **Toujours exporter avant de supprimer/importer.**
- **Diff GIT pollué par d'anciens fichiers** → dossier de destination non vidé avant export. Vider `..\source\NomApplication` avant chaque export.
- **Élément absent du dépôt après export** → élément laissé en **Check-out** dans EasyBuilder. Les Check-out sont silencieusement ignorés à l'export.
- **Import échoue avec des erreurs de dépendances** → `EasyWMS` (ou autre module requis) non listé comme dépendance lors de la création. Re-créer la custom app avec les bonnes dépendances.
- **Conflits récurrents sur la CustomApp** → deux devs poussent en parallèle sur `develop`. Respecter le workflow : branche perso → rebase avant merge → export/import séquentiel (cf. [git-workflow](git-workflow.md) + [development-methodology](development-methodology.md)).
- **Fichiers partiels commités** → un même élément est sérialisé en plusieurs fichiers (workflow, C#, DESIGN). Bien stager **tous les fichiers** avant commit.
## Related
- [Application Dictionary](../architecture/application-dictionary.md) — contenu packagé dans la custom app (Commands, Queries, Entities, Views, Dialogs, Events, Workflows)
- [Development Methodology](development-methodology.md) — stratégie de branches et cadre dans lequel s'inscrit la gestion de la custom app
- [First Deployment](first-deployment.md) — création initiale de la custom app (étape 9) et référencement dans `DeployConfig.yaml` (étape 10)
- [Deploy Existing Application](deployment-existing-app.md) — import custom app lors d'un redéploiement (étape 6 si anciens scripts)
- [Git Workflow](git-workflow.md) — rythme commit/push et gestion des branches
wiki/operations/deploy-test-application.md
+126
View File
@@ -0,0 +1,126 @@
---
title: "Deploy Test Application (Tag → Test VM)"
type: operation
sources:
- sources/archives/Deployer_application_en_test.md
related:
- operations/git-branch-lifecycle.md
- operations/git-workflow.md
- operations/deployment-existing-app.md
- operations/deployment-specific-commit.md
- operations/gna-services-license.md
- operations/vm-installation.md
- operations/vm-network-routing.md
last_compiled: "2026-04-17"
---
# Deploy Test Application (Tag → Test VM)
## Overview
Procédure interne Mecalux EasyWMS France pour **livrer un lot de développements aux chefs de projet pour test**, sur la **VM de test** (distincte de la VM de dev de chaque développeur). Le déploiement en test peut être fait :
- **Par lot** (livraison intermédiaire, plusieurs features groupées)
- **À la fin des développements** (livraison complète avant MEP)
…selon la taille du projet.
Le pivot de la procédure est la **création d'un tag Git** sur le commit `develop` choisi : cela garantit que la version déployée et testée par le CdP est **figée**, indépendamment de tout commit ultérieur sur `develop` (potentiellement en cours de dev / non testé).
Source : Confluence EasyWMS France — *Déployer l'application en test* (v1, 20/12/2022).
## Convention de nommage des tags
```
<TRIGRAMME_PROJET>-V<NUMERO>
```
Exemple : `LMD-V1`, `LMD-V2`, `SPEN-V3`.
> Cette convention est **identique** à celle utilisée pour [deployment-specific-commit](deployment-specific-commit.md) (déploiement sur un commit figé d'une VM de dev). La nuance : ici on travaille sur la **VM de test partagée** par les chefs de projet ; là-bas on figeait un commit sur sa propre VM de dev.
## Procédure (7 étapes)
### 1. Création du tag sur `develop`
**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`** → faire un **"Pull"**
2. Cliquer sur **"Tag"**
3. **"Tag Name"** : nom du tag (`<TRIGRAMME>-V<N>`)
4. Choisir le commit précis ou prendre la dernière version de `develop`
5. **Cocher "Push tag"** pour le créer aussi sur la branche distante
6. Une fois le tag créé : **double-clic sur le tag** dans la liste pour s'y positionner
### 2. Remettre la VM de test sur le checkpoint **"Deploy 0"**
Appliquer le point de contrôle Hyper-V **"Deploy 0"** sur la VM de test **avant** le déploiement.
> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) — c'est l'état "VM prête à recevoir un déploiement, vide de tout projet".
### 3. Déploiement de l'application existante
Suivre la procédure complète : [deployment-existing-app](deployment-existing-app.md).
> Pour déployer **par tag** plutôt que par branche : utiliser `deploy_repository.ps1 <Projet> <NomDuTag>` (le script accepte un tag comme deuxième argument, comme une branche).
### 4. Réinstallation du GNA (si besoin)
Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license — Réinstallation](gna-services-license.md#réinstallation-du-gna).
### 5. Installer le **printer service** et la **licence**
Suivre la procédure : [gna-services-license](gna-services-license.md) (sections Printer Service et Licence WMS).
### 6. Valider la VM
Procédure de validation post-déploiement : [vm-installation — Validation](vm-installation.md#validation-de-la-vm).
> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP — utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste.
### 7. Mise à jour des tâches Jira
Pour **toutes les tâches** dont les développements sont inclus dans le tag :
| Action | Détail |
|---|---|
| Transition statut | **"Attente déploiement pour test" → "Prêt à tester"** |
| **Champ tag (obligatoire)** | Renseigner l'**étiquette Git** créée à l'étape 1 (ex : `LMD-V1`) |
> ⚠️ Le tag est **obligatoire** lors du passage en "Prêt à tester". Sans tag, le CdP ne peut pas vérifier la version testée et le test n'est pas reproductible.
## Pourquoi un tag (et pas un déploiement direct de `develop`) ?
| Risque sans tag | Conséquence |
|---|---|
| Commit `develop` ultérieur non testé | Bug introduit après les tests CdP est inclus si on déploie `develop` au moment de la présentation client |
| Pas de version stable de référence | Impossible de revenir précisément à la version testée pour debug |
| Présentation client risquée | Le CdP ne sait pas exactement ce qui tourne sur la VM de test |
Le tag fige le commit → la livraison est **reproductible** et **garantie sans bug postérieur**.
## Common errors
- **CdP voit un bug introduit après ses tests** → la VM de test a été redéployée sur `develop` (HEAD) et non sur le tag. Toujours déployer le tag explicite.
- **Jira "Prêt à tester" sans tag renseigné** → tâche bloquée pour le CdP. Renseigner le tag obligatoirement à la transition.
- **VM de test pas remise sur "Deploy 0"** → résidus du déploiement précédent (custom app, données) peuvent fausser les tests. Toujours appliquer le checkpoint avant un nouveau déploiement.
- **Printer service / licence oubliés** → CdP ne peut pas tester l'impression d'étiquettes ni les fonctionnalités payantes. Étapes 4-5 sont des étapes à part entière, pas des "si besoin".
- **Tag créé sans le pousser** → seul le développeur voit le tag, le CdP ne peut pas le retrouver. Toujours `git push --tags` ou cocher "Push tag" dans SourceTree.
## Related
- [Git Branch Lifecycle](git-branch-lifecycle.md) — phase "développement initial", quand cette procédure s'applique
- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git détaillées (CLI / SourceTree)
- [Deploy Existing Application](deployment-existing-app.md) — procédure de redéploiement réutilisée à l'étape 3
- [Deploy Specific Commit](deployment-specific-commit.md) — procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici)
- [GNA, Services & License](gna-services-license.md) — étapes 4 (réinstallation GNA) et 5 (printer + licence)
- [VM Installation & Validation](vm-installation.md) — checkpoint "Deploy 0" et validation post-déploiement
- [VM Network Routing](vm-network-routing.md) — accès distant à la VM de test depuis le PC du CdP
wiki/operations/deployment-existing-app.md
+156
View File
@@ -0,0 +1,156 @@
---
title: "Deploy Existing Application"
type: operation
sources:
- sources/archives/Deploiement_application_existante.md
related:
- operations/vm-installation.md
- operations/first-deployment.md
- operations/deployment-specific-commit.md
- operations/custom-application-management.md
- operations/git-workflow.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# Deploy Existing Application
## Overview
Procédure de **redéploiement** d'un projet EasyWMS déjà initialisé sur une VM. À utiliser quand :
- Un nouveau développeur rejoint un projet en cours et doit préparer sa VM
- Un développeur applique un point de contrôle "Deploy 0" pour repartir d'une VM propre avant de travailler sur une autre branche
- Une mise à jour importante a été poussée sur le GIT et doit être redéployée
- On bascule d'une branche à une autre (ex : `master` → `develop` → branche de feature)
Elle **ne couvre pas le premier déploiement** d'un projet neuf (cf. [first-deployment](first-deployment.md)), ni le déploiement d'un commit figé (cf. [deployment-specific-commit](deployment-specific-commit.md)).
Source : Confluence EasyWMS France — *Déploiement d'une application existante* (v20, 04/07/2024).
## Étape 1 — Vérifier `env.secrets.yaml`
Dans **`C:\deploy\env.secrets.yaml`** sur la VM, vérifier les paramètres BDD :
**Oracle :**
| Paramètre | Valeur par défaut |
|-----------|-------------------|
| `Engine` | `Oracle` |
| `Server` | `localhost/orcl` |
| `Password` (toutes BDD) | `robmec` |
**PostgreSQL :**
| Paramètre | Valeur par défaut |
|-----------|-------------------|
| `Engine` | `PostgreSQL` |
| `Server` | `localhost` |
| `Password` (toutes BDD) | `robmec` |
## Étape 2 — Déploiement complet
Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM (`cd C:\deploy`).
Par défaut le script cible la branche **Master** du GIT. Pour une autre branche, l'ajouter en 2ᵉ argument :
```powershell
# Déploiement sur Master (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
```
> ℹ️ D'après l'équipe Espagne, il devrait être possible de déployer **n'importe quelle version depuis la 21.1.19.2** via ce script. En cas d'échec : ouvrir un ticket support.
> En cas d'erreur : voir Confluence *Installation machine virtuelle de développement*, paragraphe "Deploy 1".
> ✅ Si **aucune erreur** : sauter étapes 3, 4, 5, 6. L'**étape 7 reste obligatoire** quoi qu'il arrive.
## Étapes 3–6 (anciens scripts `deploy.ps1`)
À exécuter uniquement si le projet repose encore sur les anciens scripts (pas `deploy_repository.ps1`).
### 3 — Deploy 1 (Complete)
```powershell
.\deploy.ps1 # choisir "1. Complete"
```
### 4 — Intégrer la config entrepôt (Load)
```powershell
.\deploy.ps1 # choisir "2. Load"
```
Charge :
- Config entrepôt depuis `C:\deploy\Config`
- Paramètres uGNA depuis `C:\deploy\Data`
> Alternative : **EasyS → Transfert Data** vers la VM.
### 5 — Assignation utilisateur
```powershell
.\Commands\commands.ps1
```
Ou via **SmartUI → Organisation → Utilisateurs** → éditer `mecalux` → ajouter les sites autorisés.
### 6 — Import de l'application custom
Voir [custom-application-management — Import](custom-application-management.md#import).
## Étape 7 — Désactiver les instances en BDD (OBLIGATOIRE)
> ⚠️ Sans cette étape, **les instances ne fonctionneront pas** — cette modification est requise à **chaque redéploiement** (le fichier `Tenants.xml` est régénéré).
Dans **`C:\inetpub\wwwroot\ApplicationService\Tenants.xml`**, remplacer :
```xml
<processStore name="TENANT ProcessStore" providerName="Oracle.ManagedDataAccess.Client" … />
```
par :
```xml
<processStore name="TENANT ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>
```
Puis : `iisreset` ou recyclage du pool **ApplicationService**.
### Astuce Notepad++ (multi-tenant)
`Ctrl+H` en mode **Regular expression** :
- **Recherche** : `(<processStore name=")(.*)(ProcessStore.*$)`
- **Remplacement** : `<processStore name="\2ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>`
## Checklist rapide
1. ✅ `env.secrets.yaml` cohérent avec la BDD template VM
2. ✅ `deploy_repository.ps1 <Projet> [Branche]` lancé en PowerShell admin
3. ✅ `Tenants.xml` → `InMemory` + `iisreset` (toujours)
4. ✅ Custom app importée si "anciens scripts" et que ce n'est pas le nouveau déploiement
## Common errors
- **Instances WMS ne démarrent pas après redéploiement** → étape 7 oubliée. **Obligatoire à chaque déploiement**, même si tout semble OK.
- **Script sort "repo non trouvé"** → VM non connectée à internet (Zscaler), ou nom de projet erroné, ou branche inexistante.
- **Version WMS < 21.1.19.2** → redéploiement peut échouer avec `deploy_repository.ps1`. Ouvrir un ticket ou repartir de zéro via [first-deployment](first-deployment.md).
- **`deploy.ps1` inconnu** → projet migré vers script unifié. Utiliser uniquement `deploy_repository.ps1` et sauter étapes 3–6.
- **Custom app manquante après déploiement** → soit `Customs:` vide dans `DeployConfig.yaml`, soit (anciens scripts) étape 6 oubliée. Cf. [custom-application-management](custom-application-management.md).
## Related
- [VM Installation](vm-installation.md) — pré-requis VM + validation
- [First Deployment](first-deployment.md) — à lire d'abord si le projet n'a jamais été déployé
- [Deploy Specific Commit](deployment-specific-commit.md) — variante pour cibler un commit figé plutôt qu'un HEAD de branche
- [Custom Application Management](custom-application-management.md) — import/export de la custom app
- [Git Workflow](git-workflow.md) — sélection de la branche cible
- [GNA, Services & License](gna-services-license.md) — réinstaller GNA après redéploiement si scripts BOO modifiés
wiki/operations/deployment-specific-commit.md
+101
View File
@@ -0,0 +1,101 @@
---
title: "Deploy Specific Commit"
type: operation
sources:
- sources/archives/Deploiement_VM_commit_specifique.md
related:
- operations/deployment-existing-app.md
- operations/first-deployment.md
- operations/git-workflow.md
last_compiled: "2026-04-17"
---
# Deploy Specific Commit
## Overview
Procédure pour déployer une VM de développement sur un **commit figé** plutôt que sur le HEAD d'une branche. Utile quand :
- On doit **reproduire un bug** signalé sur une version précise
- On souhaite **comparer le comportement** entre deux versions
- On prépare une démo / test de régression qui doit rester stable même si `develop` avance
- On étudie une **hotfix candidate** avant de la merger
Le principe : créer un tag GIT sur le commit cible, créer une branche à partir de ce tag, puis utiliser le mécanisme standard de déploiement par branche (`deploy_repository.ps1 <Projet> <Branche>`).
Source : Confluence EasyWMS France — *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023).
## Prérequis
- Dépôt GIT du projet cloné en local
- **SourceTree** installé (la procédure est décrite via SourceTree ; équivalents CLI possibles mais non décrits côté source)
- Droit de push sur le dépôt distant (création de tag + création de branche)
## 1. Mettre à jour le GIT local
1. Lancer **SourceTree** et importer votre projet
2. Faire un **Fetch** en **cochant "Fetch all tags"** pour récupérer tags et branches du remote
## 2. Identifier et taguer le commit
> ⚠️ L'identification du bon commit peut être délicate (fusions, rebases, cherry-picks). En cas de doute, demander un avis extérieur.
### Créer le tag
1. Clic droit sur le commit cible → **"Tag"**
2. Nommer le tag selon la **convention projet** : préfixe Jira + numéro de version
### Convention de nommage
```
<PREFIXE_JIRA>-V<NUMERO>
```
Exemple pour le projet Spengler (préfixe Jira `SPEN`) :
```
SPEN-V1
SPEN-V2
SPEN-V3
…
```
### Pousser le tag
**Push le tag sur le remote** pour qu'il soit partagé avec l'équipe.
## 3. Créer une branche sur le commit tagué
1. Clic droit sur le commit tagué → **"Branch"**
2. Nommer la branche (par ex. réutiliser le nom du tag ou ajouter un suffixe `-deploy`)
3. **Pousser la branche** sur le remote
## 4. Déployer la VM sur la nouvelle branche
Côté VM, utiliser le script de déploiement standard en référençant la nouvelle branche plutôt que `develop` :
```powershell
.\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche
```
La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7--désactiver-les-instances-en-bdd-obligatoire).
## Règles pratiques
- **Un tag + une branche par version à déployer** — ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche).
- **Nommage `<PREFIXE>-V<N>` incrémental** — facilite la lecture de l'historique et le support côté client.
- **Fetch all tags avant toute opération** — sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible.
- **Pousser tags et branches** — si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable.
## Common errors
- **Tag créé mais non poussé** → le déploiement par branche marche localement mais personne d'autre ne peut reproduire. Toujours push le tag + la branche.
- **Mauvais commit tagué (merge commit)** → on déploie un merge plutôt que le contenu réel. En cas de doute, demander un avis externe comme le rappelle la source.
- **Conflit de nom de tag** (`<PREFIXE>-V3` existe déjà) → incrémenter le numéro ou supprimer l'ancien (risqué si partagé). Privilégier l'incrément.
- **Deploy sur détaché HEAD** → le script attend un nom de branche valide. Toujours créer une branche à partir du tag avant de déployer.
## Related
- [Deploy Existing Application](deployment-existing-app.md) — procédure de déploiement standard (référencée en étape 4)
- [First Deployment](first-deployment.md) — première initialisation d'un projet
- [Git Workflow](git-workflow.md) — stratégie de branches générale
wiki/operations/development-methodology.md
+94
View File
@@ -0,0 +1,94 @@
---
title: "Development Methodology (Custom Apps)"
type: operation
sources:
- sources/archives/Présentation_méthode_de_développement.md
related:
- architecture/overview.md
- architecture/application-dictionary.md
- operations/configuration-guide.md
- operations/git-branch-lifecycle.md
- operations/git-workflow.md
- operations/code-review-process.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# Development Methodology (Custom Apps)
## Overview
Méthode de développement interne Mecalux EasyWMS France pour les **custom applications** (extensions AD déployées au-dessus du core EasyWMS). La méthode régit le cycle de vie des développements custom depuis le poste du développeur jusqu'à la mise en production, via une stratégie de branches GIT dédiée.
Objectifs :
1. **Réduire les temps de compilation** — chaque développeur compile uniquement sa propre branche
2. **Distinguer clairement** trois états : ce qui est **en production**, ce qui est **à livrer** (validé, prêt pour release) et ce qui est **en cours de développement** (non validé)
Référence source : Confluence EasyWMS France — *Présentation méthode de développement* (v8, 29/12/2023).
## Stratégie de branches GIT
| Branche | Rôle | Contenu |
|---------|------|---------|
| `master` | Production | Reflète **exactement l'état actuel en production**. Permet de redéployer à tout moment sans perte. Contient uniquement ce qui a été testé et validé. |
| `développement` | Intégration | Base de toutes les branches de développements individuelles. Reçoit les merges des branches de devs après validation locale. |
| `<branche-dev>` (par développeur) | Développement individuel | Issue de `développement`. Chaque développeur travaille sur sa propre branche sur sa machine locale. |
| `post-production` | Correctifs livrés post-prod | Créée si un développement a lieu après une mise en production. **Mergée uniquement juste avant la mise en production suivante** pour ne pas écraser les modifications de `master`. |
## Phases du cycle de développement
### 1. Phase de développement
1. Chaque développeur dispose de sa propre **machine de développement** sur son PC.
2. Chaque développeur travaille sur une **branche GIT personnelle** issue de la branche `développement`.
3. Après chaque **merge ou rebase**, le développeur redéploie la **custom app** depuis sa branche de développement (compilation locale).
4. **Manuel de reten** : pendant les développements, les notes sont consignées dans un fichier **Markdown** (facilite les merges). À la fin des développements, les données du fichier Markdown sont copiées/collées dans le manuel de reten au format **DOC**.
### 2. Phase de tests
1. Lorsqu'une partie ou la totalité des développements est terminée, la custom application est déployée sur une **machine dédiée hébergée sur le serveur de test**.
2. Les **testeurs** testent depuis ce serveur sans avoir à monter une machine sur leur propre PC.
3. Correction des bugs — **deux options** (point à valider selon le chantier) :
- **Option A** : le développeur corrige **directement sur le serveur de test**.
- **Option B** : le développeur corrige sur sa **machine de développement locale** puis **redéploie sur le serveur de test**.
### 3. Post-production
1. Après mise en production, la branche `master` reflète l'état déployé et sert de filet de sécurité pour un redéploiement éventuel.
2. Si de nouveaux développements sont entamés après la mise en prod, une branche `post-production` est créée.
3. Cette branche `post-production` n'est **mergée qu'au dernier moment**, juste avant la prochaine mise en production, pour éviter d'écraser les modifications présentes sur `master` (hotfixes éventuels, état de production courant).
## Schéma du flux
```
master ──────────────●─────────────────●──── (production courante, intouchable hors release)
│ ▲
│ │ (merge avant MEP)
développement ───●───┼──●───●──●───────●──── (intégration)
│ ▲ │ │ ▲
│ │ │ │ │
branche-dev-A ───●───● │ │ │ (dev individuel → merge ds développement)
branche-dev-B ───────────●──● │
post-production ───────────────● ─── (créée après MEP, mergée juste avant MEP suivante)
```
## Règles pratiques
- **Ne jamais committer directement sur `master`** — toute modification passe par `développement` puis release.
- **Ne jamais merger `post-production` prématurément** — cela écraserait des correctifs présents sur `master`.
- **Redéploiement de la custom app après chaque merge/rebase** pour vérifier que la compilation passe et que l'app démarre.
- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement — la conversion vers DOC n'intervient qu'en fin de chantier.
## Common errors
- **Compilation lente sur toutes les machines** → vérifier que chaque dev est bien sur sa propre branche et ne compile pas l'intégralité de `développement`.
- **Modifications de production écrasées après mise en prod** → cause probable : `post-production` mergée trop tôt. Toujours merger `post-production` **uniquement juste avant** la MEP suivante.
- **Conflits massifs sur le manuel de reten en format DOC** → cause : plusieurs développeurs éditent le DOC en parallèle. Solution : utiliser le fichier Markdown pendant toute la durée du développement, copier/coller vers DOC uniquement à la fin.
- **Bug reproduit uniquement sur le serveur de test** → l'option A (correction directe sur serveur de test) peut masquer le problème. Préférer l'option B (correction locale + redéploiement) pour conserver un historique GIT propre.
## Related
- [System Architecture Overview](../architecture/overview.md) — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
- [Application Dictionary](../architecture/application-dictionary.md) — éléments AD packagés dans la custom app
- [Configuration Guide](configuration-guide.md) — configuration post-déploiement
wiki/operations/first-deployment.md
+301
View File
@@ -0,0 +1,301 @@
---
title: "First Deployment (New Project)"
type: operation
sources:
- sources/archives/Premier_deploiement.md
related:
- operations/vm-installation.md
- operations/deployment-existing-app.md
- operations/custom-application-management.md
- operations/gna-services-license.md
- architecture/overview.md
- concepts/parameters.md
last_compiled: "2026-04-17"
---
# First Deployment (New Project)
## Overview
Procédure de **premier déploiement** d'un projet EasyWMS sur une VM de développement fraîchement préparée (cf. [vm-installation](vm-installation.md)). Déclinaison des étapes à suivre pour initialiser :
- Le fichier de configuration de déploiement **`DeployConfig.yaml`** (choix BDD, version WMS, modules, applications)
- Le dépôt GIT du projet (fichier de layout EasyS, paramètres uGNA)
- Le script de déploiement **`deploy_repository.ps1`** (script unifié qui remplace les anciens `deploy.ps1` + `commands.ps1`)
- La première **custom application** (cf. [custom-application-management](custom-application-management.md))
Cette procédure n'est exécutée qu'**une seule fois par projet**. Pour tous les déploiements ultérieurs (autre dev rejoignant le projet, redéploiement après modif), voir [deployment-existing-app](deployment-existing-app.md).
Source : Confluence EasyWMS France — *Premier déploiement* (v39, 07/08/2025).
## Étape 1 — `DeployConfig.yaml`
Le fichier **`build/DeployConfig.yaml`** du dépôt GIT du projet pilote le déploiement. S'il est absent, le télécharger et l'y placer. Champs critiques à vérifier :
### TenantName / TenantCode
```yaml
TenantName: MonNomProjet
TenantCode: MonCodeProjet
```
### DBEngine
Doit correspondre à l'engine défini dans **`C:\deploy\env.secrets.yaml`** de la VM.
```yaml
DBEngine: Oracle # SQLServer | MySQL | Oracle | PostgreSQL
```
### MAPSeed (version WMS)
Dernière version publiée sur **[mapdeploy.mecalux.com](https://msscc.mecalux.com/documentation/documentation/master/EN/ReleaseNotes.md)** :
```yaml
MAPSeed: 22.9.19.1
```
### License
```yaml
License: ENTERPRISE # PRO | ADVANCE | ENTERPRISE
```
### Warehouse (layout EasyS)
Chemin relatif au fichier de layout (typiquement `layout_config/`) :
```yaml
Warehouse: layout_config/MAPAB_layout.cfg2014
```
### Data (paramètres uGNA)
Chemin relatif aux fichiers de config WMS (typiquement `test/`) :
```yaml
Data: test
```
### StandardApplications
Les applications à installer — reprendre la liste `<ExtraApps>` du `responses.xml` du projet, en ne gardant que celles avec `Use="Yes"` :
```yaml
StandardApplications:
- SmartUI
```
### EnabledModules
Liste complète des modules à activer — reprendre la balise `<Modules>` du `responses.xml`, **sauf `EasyWMS`** (inclus par défaut).
> ⚠️ **Problème connu versions 24.xx.xx.xx** : l'étape *"Importing apps with AD..."* peut durer très longtemps et échouer avec 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 # Requis en version >= 24.xx
```
### Customs (application custom)
Laisser **vide pour ce premier déploiement** — renseigné à l'étape 10.
### Users
Laisser vide pour conserver uniquement l'utilisateur `mecalux` par défaut ; sinon :
```yaml
Users:
- UserName:
Password: UserPassword
Groups: SuperAdmin,Administrators,Managers,Operators
```
## Étape 2 — Déposer le fichier de layout EasyS
Placer le fichier de configuration entrepôt EasyS (ex : `MAPAB_layout.cfg2014`) dans le dossier **`layout_config/`** du dépôt GIT.
> ⚠️ Bien **commit et push** après dépôt — le script de déploiement clone le GIT.
## Étape 3 — Vérifier `env.secrets.yaml` sur la VM
Dans **`C:\deploy\env.secrets.yaml`** de la VM, vérifier que les paramètres BDD correspondent à la BDD de la VM :
| Paramètre | Valeur par défaut |
|-----------|-------------------|
| `Engine` | `Oracle` ou `PostgreSQL` |
| `Server` | `localhost/orcl` (Oracle) / `localhost` (PostgreSQL) |
| `Password` (toutes BDD) | `robmec` |
## Étape 4 — Déploiement complet (script unifié)
Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM :
```powershell
# Sur Master (par défaut)
.\deploy_repository.ps1 NomDuProjetGit
# Sur une branche spécifique
.\deploy_repository.ps1 NomDuProjetGit Branche
```
Exemple :
```powershell
.\deploy_repository.ps1 1707_FRANCE_MA_PIECES_AUTOS_BRETAGNE
```
> D'après l'équipe Espagne, il devrait être possible de déployer n'importe quelle version depuis la **21.1.19.2** via ce script unifié.
### Cas d'erreurs classiques
- **VM non connectée à internet** → lancer Internet Explorer pour s'authentifier à Zscaler (VPN désactivé au bureau, actif en télétravail)
- **Git absent** sur la VM → installer depuis [git-scm.com/download/win](https://git-scm.com/download/win)
- **Autres erreurs** → voir documentation Confluence *Installation machine virtuelle de développement*, paragraphe "Deploy 1"
> ✅ Si aucune erreur : les étapes 5, 6, 7 sont à **sauter**. L'étape 8 (Tenants.xml) reste **obligatoire**.
## Étapes 5–7 (anciens scripts uniquement)
À n'exécuter que si le projet utilise les **anciens scripts** `deploy.ps1` + `commands.ps1` (pas `deploy_repository.ps1`).
### 5 — Deploy 1 (Complete)
```powershell
.\deploy.ps1 # choisir "1. Complete"
```
### 6 — Load (config entrepôt + paramètres uGNA)
```powershell
.\deploy.ps1 # choisir "2. Load"
```
Ce qui est chargé :
- Config entrepôt depuis `C:\deploy\Config`
- Paramètres uGNA depuis `C:\deploy\Data`
> Alternative : charger le layout via **EasyS → Transfert Data** vers la VM.
### 7 — Assignation utilisateur
```powershell
.\Commands\commands.ps1
```
Alternative SmartUI : **Organisation → Utilisateurs** → sélectionner `mecalux` → ajouter les sites autorisés.
## Étape 8 — Désactiver les instances en BDD (OBLIGATOIRE)
> ⚠️ **Sans cette modification, les instances ne fonctionnent pas.**
Dans **`C:\inetpub\wwwroot\ApplicationService\Tenants.xml`**, remplacer :
```xml
<processStore name="TENANT ProcessStore" providerName="Oracle.ManagedDataAccess.Client" … />
```
par :
```xml
<processStore name="TENANT ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>
```
Puis redémarrer l'application : `iisreset` ou recyclage du pool **ApplicationService**.
### Astuce Notepad++ (multi-tenant)
Activer le mode **Regular expression** dans `Replace` (`Ctrl+H`) :
- **Recherche** : `(<processStore name=")(.*)(ProcessStore.*$)`
- **Remplacement** : `<processStore name="\2ProcessStore" providerName="InMemory" connectionString="MaxProcessInfoLogs=20;MaxProcessLogEntries=50"/>`
Chaque occurrence est remplacée en conservant le nom de Tenant.
## Étape 9 — Créer l'application custom
Procéder à la création initiale de la custom app et son premier export sur GIT.
Voir [custom-application-management — Création](custom-application-management.md#creation).
## Étape 10 — Compléter `DeployConfig.yaml` avec le Custom
Une fois la custom app créée et exportée, renseigner la section `Customs` :
```yaml
Customs:
- NomApplication: chemin/du/dossier/GIT/de/lapplication
```
Exemple :
```yaml
Customs:
- CustomApplication: source/CustomApplication
```
Désormais, chaque déploiement ultérieur (`deploy_repository.ps1`) reprendra automatiquement la custom app depuis le GIT.
## Parameters (DeployConfig.yaml)
| Clé | Type | Rôle |
|-----|------|------|
| `TenantName` / `TenantCode` | string | Identifiant du tenant EasyWMS |
| `DBEngine` | enum | `Oracle` / `PostgreSQL` / `SQLServer` / `MySQL` — doit matcher `env.secrets.yaml` |
| `MAPSeed` | string (version) | Version WMS à déployer depuis mapdeploy |
| `License` | enum | `PRO` / `ADVANCE` / `ENTERPRISE` |
| `Warehouse` | path | Chemin relatif layout EasyS (`.cfg2014`) |
| `Data` | path | Chemin relatif dossier uGNA |
| `StandardApplications` | list | Applications à installer (miroir `<ExtraApps Use="Yes">`) |
| `EnabledModules` | list | Modules activés (miroir `<Modules>` sans `EasyWMS`) |
| `Customs` | list | Apps custom à importer (renseigné étape 10) |
| `Users` | list | Users additionnels (sinon `mecalux` seul) |
## Common errors
- **`RuntimeException` pendant "Importing apps with AD..."** sur versions 24.xx.xx.xx → ajouter **`ToggleService`** dans `EnabledModules`.
- **BDD refuse la connexion pendant le deploy** → divergence entre `DBEngine` du `DeployConfig.yaml` et l'engine du template VM. Vérifier `env.secrets.yaml`.
- **Deploy OK mais instances WMS inactives** → étape 8 (Tenants.xml → `InMemory`) **non exécutée**. Étape obligatoire, même si tout semble fonctionner.
- **`License` non accepté** → la VM fonctionne 7 jours ; au-delà, demander une licence projet (cf. [gna-services-license](gna-services-license.md#license)).
- **Script ne trouve pas le projet GIT** → vérifier nom exact du repo (sensible à la casse) et connectivité Zscaler/VPN.
- **Plusieurs devs → différents `TenantName`** → pas un bug en soi, mais perturbe les merges. Convenir d'un `TenantName` unique par projet.
## Related
- [VM Installation](vm-installation.md) — pré-requis : VM Hyper-V créée et validée
- [Deploy Existing Application](deployment-existing-app.md) — déploiements ultérieurs (autres devs, redéploiement, changement de branche)
- [Deploy Specific Commit](deployment-specific-commit.md) — déployer un commit figé plutôt que le HEAD d'une branche
- [Custom Application Management](custom-application-management.md) — étape 9 (création initiale de la custom app)
- [Git Workflow](git-workflow.md) — stratégie de branches pour le projet
- [GNA, Services & License](gna-services-license.md) — installation des services GNA, Printer, License WMS après déploiement
- [System Architecture Overview](../architecture/overview.md) — stack cible (IIS, BDD, services)
- [Parameters](../concepts/parameters.md) — paramètres WMS chargés via uGNA (étape 6)
wiki/operations/galileo-simulation.md
+330
View File
@@ -0,0 +1,330 @@
---
title: "Galileo Simulation & Test Setup (Gateway, EasyS, PIE)"
type: operation
sources:
- sources/archives/Tests_Miniload_Gateway.md
- sources/archives/Configuration_EasyS.md
- sources/archives/Configuration_SmartUI.md
- sources/archives/Plan_tests_stations.md
related:
- architecture/galileo-integration.md
- operations/galileo-troubleshooting.md
- operations/robotics-project-lifecycle.md
- operations/vm-installation.md
- operations/vm-network-routing.md
- concepts/stations.md
- concepts/mechanical-elements.md
- concepts/putaway.md
last_compiled: "2026-04-17"
---
# Galileo Simulation & Test Setup (Gateway, EasyS, PIE)
## Overview
EasyS is the 3D simulation front-end that speaks the same protocol as GALILEO. Running EasyS + EasyWMS Gateway on a dev VM lets you reproduce the full robotic flow (PIE → Miniload → PK → PS) without physical hardware. This page covers Gateway install, EasyS simulation configuration, PIE event injection, pick/shipping test flows, and station/route synchronisation procedures.
Shared demo environment (Mecalux France):
- VM **ALL** on server **LYOITSW02** — IP `10.58.10.75`
- Credentials: `mecalux / mecalux`
- Warehouse: `WRH_MIXTE` (miniload + conveyor path)
See [VM Installation](vm-installation.md) and [VM Network Routing](vm-network-routing.md) for creating a fresh dev VM.
## 1. Install the EasyWMS Gateway
The Gateway is the Windows service that translates between GALILEO/EasyS frames and the EasyWMS API. Install on the same host as EasyWMS.
1. Download: https://msscc.mecalux.com/documentation/documentation/master/EN/docs_downloads/services/gateway.md
2. Run the installer → select **Gateway** → **Install**
3. Install path: `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
### Configure the Gateway
File: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config`
1. Set **tenantCode** = the WMS tenant you want to target
2. Fill the **TokenUser** connection section (not `ClientUser`)
3. Passwords must be encrypted — run `PasswordEncrypt.exe` from `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
4. Start the Windows service **EasyWMSGateway2015**
Logs go to `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` — see [Galileo Troubleshooting](galileo-troubleshooting.md).
## 2. Open port 3000 on the VM
EasyS / GALILEO use TCP port 3000 to reach the Gateway. Open inbound (and outbound for some edge cases).
**PowerShell:**
```powershell
Remove-NetFirewallRule -DisplayName "EasyS Port 3000"
New-NetFirewallRule -DisplayName "EasyS Port 3000" -Direction Inbound -LocalPort 3000 -Protocol TCP -Action Allow -Profile Any -RemoteAddress Any
```
**GUI fallback:** Windows Defender Firewall → New Rule (Inbound + Outbound) → TCP 3000 → Allow.
## 3. EasyS warehouse configuration
Automation elements live in the EasyS category **Automatic elements**.
### 3.1 Location & container settings
For locations and stations that feed an automatic warehouse:
- `DeleteEmptyContainers` = **Not Delete**
- Exception: picking stations (PK) may use `Delete` or `Ask` when operators physically remove empty containers
- Storage mode = **Only Containers**
### 3.2 Rack types
Every miniload location must be bound to a **rack type** with the exact dimensions of the physical rack. Each rack type declares which container type(s) it accepts.
### 3.3 PLC Types (PIE gauge mapping)
At each PIE pass, GALILEO returns:
- **PLC Container Type** — derived from width
- **PLC Height Type** — derived from height
Procedure:
1. EasyS → **PLC Types** menu
2. Define each container height value
3. Bind each container master to its PLC Container Type
> ⚠️ On miniloads, container type and height are usually tied. If GALILEO reads `PLCHeightType = 1`, `PLCType` must also be `1`. Make the coupling explicit in the interface document delivered with the project.
### 3.4 Automatic aisle (TK / Miniload)
To simulate a TK, add an **Automatic Aisle**. The aisle ↔ rack link works like a manual aisle:
1. Pick the rack → link it to the miniload/TK station
2. Double-click the rack to open the location editor
3. Assign each location its rack type
### 3.5 Station types (recap)
| Type | Role |
|------|------|
| Automatic Aisle | Stacker crane / Miniload |
| PIE | Entry identification (label + weigh) |
| Picking (PK) | Picking conveyor |
| PKE | PK entry control — if full, recirculate |
| Inbound Table (ME) | Conveyor into the TK/Miniload |
| Outbound Table (MS) | Conveyor out of the TK/Miniload |
| CME | TK/Miniload entry control — if full, recirculate |
| Outbound Post | Exit conveyor (operator can pick the container up) |
| MP | Preparation table (stock drop after pick) |
| Transporter | Plain conveyor with no special function |
Full catalogue: [Stations & Routes](../concepts/stations.md); translation matrix: [Mechanical Elements](../concepts/mechanical-elements.md).
### 3.6 Double-depth rack storage zones
Two layout patterns for double-depth racks:
- **Case #1** (most common at Mecalux France) — best for **mono-product** supports (several supports share the same item inside the TK). Rotation zones split by front face / rear face.
- **Case #2** — best for **multi-product** supports (a given item never lives in two supports simultaneously). Reduces relocations during picking without pre-emptive defragmentation.
### 3.7 Route configuration
Every movement needs a route in EasyS between origin and destination. A single task `PIE → Miniload` typically generates **4 movements** — the WMS creates one task, but the routing table must allow every hop.
> If no path exists, EasyWMS generates a **reject task** toward the reject station.
Route inventory in EasyWMS: **Menu → Control → Itineraries between stations**.
Route types:
| Type | Description |
|------|-------------|
| Galileo | Requires Gateway calls to move the container physically |
| Manual | Operator action triggered by a WMS task |
| Virtual | Instant virtual stock movement (e.g. output → consolidation zone) |
### 3.8 Entry / outbound tables (TE / TS) on the TK
Multiple containers can sit on a TE/TS at once:
1. Size the table large enough physically
2. Lay out containers in **Positions** (side by side) and **Stack** (one behind the other)
3. **Logical X = 991** — except tables embedded in the rack, which inherit the replaced location's coordinates
### 3.9 Multidirectional tables (LTM)
Set `routing options = 1` for every feeder conveyor allowed to deposit a container.
### 3.10 Picking station configuration
1. Add a conveyor with role **Picking**
2. Create a **Workstation** to drive the station from SmartUI
3. Define routes — where stock can arrive from, where it can leave to
Preparation table (TP/MP) routes:
- **Manual** route from picking table → preparation tables
- **Galileo** route from preparation tables → output table
- **Virtual** route → consolidation zone
### 3.11 Reject configuration
The reject route lets the WMS redirect containers with no valid route.
- Configure **GALILEO** routes from the main stations → REJECT station
- Add a **VIRTUAL** route → floor zone so lost containers are moved off the simulation automatically
- Reject routes render in **red**. Unlike normal routes, the red route gives the **task destination** (not the movement destination).
Different rejection reasons (`IdentError`) can point to different destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
## 4. SmartUI workstation configuration
Companion configuration once the EasyS layout is in place.
### 4.1 Preparation tables (MP/TP)
Each preparation table is linked to a picking station. After picking confirmation, stock moves from the container to the chosen preparation table.
**Assignment mode:**
- **Automatic** — WMS assigns the next order to a table
- **Manual** — operator assigns via **Menu → Control → Picking-station assignment**
> ⚠️ In manual mode, **tasks do not generate until the shipping order is assigned to a table**.
To switch mode: **Menu → Control → Workstations** → select preparation table(s) → **Modify assignment mode**.
> ⚠️ The preparation table must have a route to the shipping dock of the order — otherwise tasks won't generate.
### 4.2 Picking table max-concurrent orders
To cap how many orders a picking table can handle in parallel:
**Menu → Control → Workstations** → select the picking station → update the value.
> The value must **equal the number of preparation tables** associated with the picking station.
## 5. Run EasyS in simulation mode
1. Launch EasyS and load the warehouse configuration
2. Click **Start**
3. Enter the WMS server IP → **Next**
4. Uncheck **Generate simulation report** → click **Simulation 3D**
5. Watch the Gateway log (`AllLog.log`) — lots of lines with no errors = connection OK
## 6. Inject a container at the PIE
1. Double-click the PIE in EasyS
2. Tab **PIE Info** → leftmost button
3. Fill:
- Transport Number: `0`
- Data: container code
- Container Type: corresponding PLC Container Type
- Weight
- Height Type: corresponding PLC Height Type
4. Click **Save** — a pallet/bin visibly moves on the conveyor
> ⚠️ **Valid putaway strategies must exist** — even for empty containers. No valid location ⇒ reject.
### Simulate a read error
Tab **Scripts** on the PIE → **Prepare event** → paste:
```
machine.Flags = "256";
```
Then inject the container. `256` = barcode error (see [GALILEO Integration — PIE flag table](../architecture/galileo-integration.md)).
## 7. Extract a container from the miniload
Three triggers:
- **Demand** the container from the picking workstation
- **Request empty containers** from the picking workstation
- **Launch an order** for preparation
From the SmartUI picking workstation you can request a specific container, empty containers, or a specific item.
### Put the station in manual mode
Double-click the picking station in EasyS → tick **Manual action**. Without this, the container departs automatically and testing is impossible.
### Send the container back to the miniload
1. SmartUI workstation → **Store container**
2. EasyS → double-click the picking station → click **Liberate**
> Once **Manual Action** is ticked, **always** click **Liberate** to release the container. Skipping this step freezes the simulation.
### Client-order flow
On order release, the WMS:
1. Assigns the picking station to the order
2. Creates tasks to extract the container to the PK
Tasks are of type `pickingContainer`. After pick confirmation: **Store container** → **Liberate** to return the container to the miniload.
> Verify preparation-table config **before** launching an order — tasks won't generate if routes to the dock are missing.
## 8. Speed up simulation
Use the speed button in EasyS to accelerate container travel. Useful for stress-testing picking/putaway strategies without waiting.
## 9. Station & route synchronisation procedure
Before going live, confirm WMS and GALILEO agree on stations and routes. Run the audit below during the **Plan de tests des stations** milestone.
### 9.1 Retrieve WMS stations via query
Execute on the **writing** side:
```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 with StationFrom — full query on Confluence
.OrderBy(sr => sr.StationType)
.ThenBy(sr => sr.StationNumber)
```
### 9.2 Routes that must report "full"
GALILEO must be able to push these routes as **status 3 = Full** so the WMS can recirculate:
| Source type | Destination type |
|-------------|------------------|
| CME | TE (ME) |
| PKE | PK |
| ET | PS |
### 9.3 Compare configuration on failure
If `EndErrorCode=4` occurs:
1. Open the GALILEO program in `C:\<NomDuClient>\Programme` → double-click the `.mgp` file
2. Compare the station list side-by-side with the query above
3. Check that every (StationType, StationNumber) pair exists on both sides, with the same aisle, allowed container types and coordinates
4. Confirm PLC Container Type / PLC Height Type coupling matches the document
More diagnostic steps: [Galileo Troubleshooting](galileo-troubleshooting.md).
## Common errors
- **Container injected at PIE but immediately rejected** — no valid putaway strategy covers the (container type, height type) combo, or no route exists to any storage location
- **Tasks don't generate after order launch** — preparation table has no route to the dock, or assignment mode is Manual and the order isn't assigned
- **Station stays loaded indefinitely in EasyS** — Manual Action ticked without running Liberate
- **Gateway starts but no activity** — wrong `tenantCode` or `TokenUser` password; check Gateway log
- **Connection refused from EasyS** — port 3000 not open, or Gateway service not started
## Related
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference
- [Galileo Troubleshooting](galileo-troubleshooting.md) — log patterns, fault codes
- [Robotics Project Lifecycle](robotics-project-lifecycle.md) — where simulation fits in the project plan
- [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md)
- [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md) · [Putaway](../concepts/putaway.md)
wiki/operations/galileo-troubleshooting.md
+154
View File
@@ -0,0 +1,154 @@
---
title: "Galileo Troubleshooting (Logs, Faults, Address Change)"
type: operation
sources:
- sources/archives/Comprendre_logs_Gateway.md
- sources/archives/Erreurs_Defauts_GALILEO.md
- sources/archives/Changer_adresse_WMS_dans_GALILEO.md
related:
- architecture/galileo-integration.md
- operations/galileo-simulation.md
- operations/troubleshooting.md
- concepts/stations.md
- concepts/mechanical-elements.md
- modules/automation-dashboard.md
last_compiled: "2026-04-17"
---
# Galileo Troubleshooting (Logs, Faults, Address Change)
## Overview
How to read Gateway logs, interpret station / route updates, trace a container through a simulation or production run, and resolve the most common GALILEO faults (EndErrorCode=4, 1116 incorrect task, variator faults). Pair this page with [GALILEO Integration](../architecture/galileo-integration.md) for the protocol reference and [Galileo Simulation](galileo-simulation.md) for the bring-up procedure.
## 1. Gateway log — location & structure
`C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`
Every frame exchanged between GALILEO/EasyS and EasyWMS lands here. Recommended viewer: **klogg** (handles 100 MB+ files without lagging).
The log is dominated by three categories of lines:
- Station updates (every 1–3 s per station)
- Route updates (every 1–3 s per route)
- Event / Search / End frames (driven by container movements)
### 1.1 Station update line
Fields carried on each update:
| Field | Description |
|-------|-------------|
| **StationType** | Station type configured in the WMS |
| **StationNumber** | Station number configured in the WMS |
| **Status** | `1` = ready, `0` = error |
| **Loaded** | `1` = free, `0` = loaded |
| **Capacity** | Max containers on the station |
| **CurrentCount** | Trackings currently on the station |
| **Aisle** | Aisle number bound to the station |
> The couple **StationType + StationNumber** is unique — always identify a station by that pair.
### 1.2 Route update line
| Field | Description |
|-------|-------------|
| StationTypeSource / StationNumberSource | Origin station |
| StationTypeDestination / StationNumberDestination | Destination station |
| **Status** | `1` = free, `3` = full |
(Protocol also defines `0` = no comms, `2` = electromechanical fault — see [GALILEO Integration](../architecture/galileo-integration.md).)
### 1.3 Event, Search, End
- **Event** — typically a PIE event with barcode + weight + dimensions + container/height types
- **Search** — a TK or conveyor asking for the next order
- **End** — confirmation the container reached its destination (with an error code)
## 2. Trace a container in klogg
Two search patterns are usually enough to reconstruct a container's history.
1. **What happened at the PIE** (identification data):
```
DataInfo.+_CodeSupport_
```
Replace `_CodeSupport_` with the actual container barcode. Returns all PIE events that read that code.
2. **What happened after** (movement trace):
```
Movement=_NuméroDeTâche_
```
Replace `_NuméroDeTâche_` with the task number. Returns all Search / End / status updates tied to that task.
This two-step pattern answers most "where is container X?" questions without paging through the whole log.
## 3. End error codes — diagnosis
| Code | Meaning | First action |
|------|---------|--------------|
| `0` | Movement complete | None — next movement generated |
| `1` | Deposit error | Inspect the destination location, relocation/reject task expected |
| `2` | Extraction error | Inspect the source location, relocation/reject task expected |
| `4` | Inconsistent order | WMS/GALILEO config mismatch — see section 3.1 |
| `7` | Gauge error | Container fails dimensional check — routed to REAC / RECH |
### 3.1 EndErrorCode = 4 (most frequent)
GALILEO did not understand the order. Root cause is **always** a configuration drift between EasyS/WMS and GALILEO.
**Likely causes:**
- Location does not exist on the GALILEO side
- Location exists on both sides but the allowed **container type / height type** differs
- X/Y coordinates out of range on GALILEO
- Two containers planned to cross paths (impossible movement)
- Coordinate system discrepancy between sides of the entry table vs the aisle
**Resolution — 4 steps:**
1. Grab the frame sent to GALILEO from the Gateway log (Station types, numbers, coordinates, container/height type)
2. Open the GALILEO program: `C:\<NomDuClient>\Programme\<installation>.mgp` (double-click to launch)
3. Compare the station list between GALILEO and EasyS — aisle, allowed types, X/Y — line by line
4. Use the station query shipped with [Galileo Simulation — §9.1](galileo-simulation.md) to dump the WMS-side view
If you change anything on the GALILEO side, also sync the change in EasyS (and vice versa) — the two systems must stay in lock-step.
## 4. GALILEO fault codes
Faults reported on the GALILEO SCADA / Automation Dashboard. See [Automation Dashboard](../modules/automation-dashboard.md) for monitoring; use this table to triage.
| Code | Name | Typical causes |
|------|------|----------------|
| **1116** | Incorrect task CU1 | Location locked on GALILEO but not on EasyWMS (or vice versa); location exists in EasyWMS but not in GALILEO; same location has different allowed container types on each side; WMS asks to deposit on the left rack while the container sits on the right fork of the miniload (and vice versa) |
| **1201** | Variator fault X | — (variator hardware fault on axis X) |
| **1291** | Unreferenced SM302 card on the variator | Warning only |
Fault 1116 is the configuration-drift counterpart of `EndErrorCode=4` at the automation layer — same root cause, different reporting surface.
## 5. Change the WMS address inside GALILEO
When the WMS server IP or DNS changes (migration, VM rename, network reconfig), the GALILEO side must be updated so the PLC can reach the new Gateway.
> ⚠️ The Confluence page for this procedure contains only screenshots (no extractable text). Refer to [Confluence — Changer l'adresse du WMS dans GALILEO](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552) for the step-by-step screen walkthrough.
High-level: update the WMS IP / hostname inside the GALILEO program configuration (the `.mgp` file under `C:\<NomDuClient>\Programme\`) and restart the GALILEO runtime. Then verify the Gateway log picks up the new connection.
## 6. Checklist before escalating
Before opening a ticket or calling Support:
- [ ] Gateway service (`EasyWMSGateway2015`) is **Running**
- [ ] `AllLog.log` shows recent traffic (not frozen, no error spike)
- [ ] Port 3000 is open on the WMS host (inbound + outbound)
- [ ] `tenantCode` and `TokenUser` in `MainObject.config` match the target WMS
- [ ] The specific (StationType, StationNumber) pair exists on both sides with identical parameters
- [ ] Allowed container types + PLC Height Type couple match on both sides
- [ ] No untracked containers stranded on blind conveyors (LBC, LRL — see [Mechanical Elements](../concepts/mechanical-elements.md))
- [ ] Automation Dashboard fault report consulted to correlate with machine-level faults
## Related
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference, workflows, command/event catalogue
- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, station sync query
- [General Troubleshooting Guide](troubleshooting.md)
- [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md)
- [Automation Dashboard](../modules/automation-dashboard.md) — fault reporting UI
wiki/operations/git-branch-lifecycle.md
+157
View File
@@ -0,0 +1,157 @@
---
title: "Git Branch Lifecycle (Project Phases)"
type: operation
sources:
- sources/archives/Gestion_du_GIT.md
related:
- operations/development-methodology.md
- operations/git-workflow.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# Git Branch Lifecycle (Project Phases)
## Overview
Stratégie de gestion **par phase de projet** des branches Git pour les projets EasyWMS France : qui fait quoi, à quel moment, sur quelle branche. Cette page complète :
- [development-methodology](development-methodology.md) — vue d'ensemble (master / développement / post-production)
- [git-workflow](git-workflow.md) — procédure opérationnelle Git Flow (CLI / SourceTree)
…en explicitant les **règles de gouvernance** entre les acteurs (Dev, CdP, Support, TMA) au fil du cycle de vie : **Développement → Mise en service (MEP) → Hypercare → TLM (Tierce Maintenance) → TMA (Tierce Maintenance Applicative)**.
Source : Confluence EasyWMS France — *Gestion du GIT* (v1, 27/02/2024).
## Acteurs
| Acteur | Rôle |
|---|---|
| **Dev** | Développeur custom app (réalise les `feature` Jira) |
| **Dev Principal** | Référent technique du projet (gère la branche `develop` après MEP) |
| **CdP** | Chef de Projet (responsable des merges de mise en service et de la branche `master`) |
| **Support** | Équipe de support post-MEP (`hotfix` urgents) |
| **TMA** | Équipe de Tierce Maintenance Applicative (offres complémentaires sur `release`) |
## 1. Phase de développement initial
### Création des branches `feature` (et de correction)
Outil : **Git Flow dans Sourcetree**.
| # | 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 chaque tâche avec **"Finish Feature"** + option **"Rebase"** |
> Détail technique des commandes (`git flow init -d` / `git flow feature start` / `git flow feature finish -r`) → cf. [git-workflow](git-workflow.md).
> Convention de nommage du tag : `<TRIGRAMME_PROJET>-V<NUMERO>` (ex : `LMD-V1`). Voir aussi [deploy-test-application](deploy-test-application.md) où le tag est créé sur le commit `develop` à livrer en test.
## 2. Avant la mise en service (MEP)
### Merge `develop` → `master`
| # | Acteur | Action |
|---|---|---|
| 1 | CdP | **Merger `develop` dans `master`** |
| 2 | CdP | **Supprimer la branche `develop`** |
> ⚠️ Pourquoi supprimer `develop` ? Pour **éviter qu'au retour** (post-MEP) on retombe sur une branche `develop` plus du tout à jour vis-à-vis de la production. Une nouvelle `develop` sera recréée à partir de `master` si nécessaire (cf. section 3).
## 3. Après la MEP (pendant l'hypercare, 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 faits **pendant** la MEP) |
| 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 `develop` |
| 2 | CdP | **Livrer la production** depuis `develop` *(toujours quand tous les développements sont terminés, jamais en cours)* |
| 3 | CdP | Merger `develop` → `master` ; **si possible aussi merger `master` → `develop`** pour aligner les deux branches |
### c. Avant le passage en TLM
| # | Acteur | Action |
|---|---|---|
| 1 | CdP | Merger `develop` → `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`.** C'est le critère bloquant numéro 1 lors du transfert au Support.
## 4. Pendant la TLM et la TMA
### a. Branches `hotfix` — équipe Support
**Cas 1 — Modifications longues / conséquentes ou testées sur intégration d'abord :**
| # | Acteur | Action |
|---|---|---|
| 1 | Support | Créer une branche `hotfix` à partir de `master` |
| 2 | Support | Merger `hotfix` → `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 2 — Modifications directes en production :**
| # | Acteur | Action |
|---|---|---|
| 1 | Support | **Exporter la production dans `master`** |
| 2 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu |
### b. Branches `release` — équipe TMA
| # | Acteur | Action |
|---|---|---|
| 1 | TMA | Créer une **nouvelle branche `release`** pour chaque offre complémentaire prévue |
| 2 | TMA | Les développeurs tirent des `feature` **depuis `release`** pour chaque tâche Jira de l'offre |
| 3 | TMA | **Merger `master` → `release`** à chaque annonce de livraison Support |
| 4 | TMA | Intégrer les `feature` dans `release` sur demande du chef d'équipe, après test et validation finale |
| 5 | TMA | **Merger `master` → `release`** + passe de tests généraux **avant livraison de l'offre** |
| 6 | TMA | **Merger `release` → `master`** après livraison de l'offre |
| 7 | TMA | **Prévenir l'équipe Support** qu'une livraison a eu lieu *(pour mise à jour des `hotfix` en cours)* |
## 5. Visibilité et communication
> ⚠️ Communication **bidirectionnelle obligatoire** sur les livraisons :
> - Dev ↔ CdP (pendant le projet)
> - **Support ↔ TMA** (pendant TLM/TMA — chaque livraison de l'un impose un re-merge de l'autre)
>
> Une livraison non communiquée provoque des conflits Git lourds + risque de régressions en prod.
## Schéma récapitulatif (cycle de vie d'un projet)
```
Phase Dev MEP Hypercare TLM
develop ─o─o─o──────merge──┐ (delete) ┌─o─o──merge──┐ (delete)
▼ ▼ ▼
master ────────────────o──o──────o─────o─o───────────o──────────►
│
┌──────────┴──────────┐
▼ ▼
hotfix (Support) ─o──────merge──┐ release (TMA) ─o─o─merge
▼ │
master ───────────────────────────────────o─o───o─────────merge─────────o─o
```
## Common errors
- **`develop` toujours présente au passage TLM** → Support refuse le transfert. Le CdP doit merger une dernière fois `develop`→`master` puis supprimer `develop`.
- **TMA livre une `release` sans avoir mergé les `hotfix` Support récents** → conflits massifs en prod ou régressions des correctifs Support. Toujours `master → release` avant livraison.
- **Support fait un hotfix sans prévenir TMA** → la `release` en cours diverge silencieusement. Toute livraison Support **doit** être annoncée à TMA.
- **Branche `develop` recréée par un Dev (et non par le Dev Principal)** → risque de fork involontaire. Seul le Dev Principal recrée `develop` post-MEP, à partir de `master`.
- **Tag de revue/test non créé sur `develop` avant déploiement test** → le CdP ne peut pas figer la version testée. Toujours tag avant [deploy-test-application](deploy-test-application.md).
## Related
- [Development Methodology (Custom Apps)](development-methodology.md) — stratégie haut niveau master/développement/post-production
- [Git Workflow (Git Flow)](git-workflow.md) — commandes Git Flow CLI + SourceTree (le "comment" opérationnel)
- [Deploy Test Application](deploy-test-application.md) — création du tag `<TRIGRAMME>-V<N>` et déploiement de la livraison en test
wiki/operations/git-workflow.md
+227
View File
@@ -0,0 +1,227 @@
---
title: "Git Workflow (Git Flow)"
type: operation
sources:
- sources/archives/Gestion_versions_projet_GIT.md
related:
- operations/development-methodology.md
- operations/git-branch-lifecycle.md
- operations/custom-application-management.md
- operations/deployment-existing-app.md
- operations/deployment-specific-commit.md
- operations/gna-services-license.md
- operations/ssh-keys-setup.md
- operations/ugna-data-export.md
- operations/code-review-process.md
last_compiled: "2026-04-17"
---
# Git Workflow (Git Flow)
## Overview
Workflow **Git Flow** appliqué aux projets EasyWMS France. Git Flow est une extension de Git qui impose un workflow structuré et uniformise la gestion des branches (features / bugfixes / releases / hotfixes / support). Il complète la stratégie de branches décrite dans [development-methodology](development-methodology.md) en donnant la procédure opérationnelle (commandes CLI et SourceTree) :
- Initialiser le dépôt
- Créer / basculer sur une feature
- Committer ses développements (y compris export CustomApp + export uGNA + sauvegarde GNA)
- Clôturer la feature avec rebase sur `develop`
- Gérer les conflits
La gestion est expliquée en parallèle via **invite de commande (CLI)** et **[SourceTree](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088854571)** (configuré en anglais).
Source : Confluence EasyWMS France — *Gestion des versions du projet avec GIT* (v27, 22/08/2025).
### Ressources externes
- [É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
**CLI :**
```bash
cd <emplacement souhaité>
git clone <url>
```
**SourceTree :** bouton "Clone" → renseigner l'URL du repo.
> L'URL du repo GIT se trouve dans l'interface de gestion du projet (bouton "Clone" / "Code" selon la plateforme).
### Initialiser Git Flow
**CLI :**
```bash
git flow init -d \
--feature feature/ \
--bugfix bugfix/ \
--release release/ \
--hotfix hotfix/ \
--support support/ \
-t ''
git push --set-upstream origin develop
```
**SourceTree :** icône Git Flow → **ne rien modifier** dans la fenêtre de configuration → **OK**.
## 2. Créer une nouvelle feature / branche
### Récupérer les derniers commits
**CLI :**
```bash
git pull
```
**SourceTree :** bouton **"Pull"**.
### Démarrer la feature
**CLI :**
```bash
git flow feature start <nom de la feature>
# Ex : git flow feature start PD-49
```
**SourceTree :** icône Git Flow → **"Start New Feature"** → saisir le nom.
### Déployer la VM sur la nouvelle branche
1. Appliquer le point de contrôle **"DEPLOY 0"** sur la VM (cf. [vm-installation](vm-installation.md#7--point-de-contrôle-deploy-0))
2. Déployer la branche : cf. [deployment-existing-app](deployment-existing-app.md)
> Si une pop-up de connexion apparaît sur SmartUI après déploiement : [procédure dédiée Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544)
Vous êtes prêt à commencer vos développements. ✅
## 3. Commit de vos modifications
### Étape préalable — exporter les modifications
Avant tout commit, exporter **tout ce qui a été modifié** :
1. **Custom app** → cf. [custom-application-management — Export](custom-application-management.md#export)
2. **Paramètres / config WMS modifiés** → export datas via **[uGNA](ugna-data-export.md)** (procédure complète avec liste des entités et erreurs droits)
3. **Fichiers BOO du GNA modifiés** → exécuter [`GNAGetDataForGit.ps1`](gna-services-license.md#sauvegarder-la-configuration-sur-le-git)
### Commit + push
**CLI :**
```bash
# Ajouter tout ce qui est modifié
git add .
# Ou fichier par fichier
git add <Nom du fichier>
# Commit avec message explicite
git commit -m "<Message expliquant vos modifications>"
# Push
git push
```
**SourceTree :**
1. **"Commit"** (haut à gauche)
2. **"Stage all"** ou drag & drop / "Stage selected"
3. Écrire le message de commit
4. **"Commit"**
5. Pour push simultané : cocher **"Push changes immediately"**
> ℹ️ Les fichiers générés par l'export de la custom app 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** — évite toute perte (perte/vol/casse du PC).
## 4. Fin de la tâche de développement
Une fois développements **testés et validés**, clôturer la branche.
### 4.1 Mettre à niveau `develop`
**CLI :**
```bash
git switch develop
git pull
```
**SourceTree :** double-clic sur la branche `develop` → **"Pull"**.
### 4.2 Clôturer la feature
**CLI :**
```bash
git flow feature finish -r <Nom feature>
git push
# Ex : git flow feature finish -r PD-49
```
**SourceTree :**
1. Icône Git Flow → sélectionner la feature
2. ✅ Cocher **"Rebase on development Branch"**
3. Valider → **"Push"**
### 4.3 Gérer les conflits
Si le rebase lève des conflits :
1. Ouvrir les fichiers en conflit (**VSCode** recommandé) et les résoudre
**CLI :**
```bash
git add <nom du fichier résolu>
git rebase --continue
# Répéter pour chaque commit jusqu'à la fin du rebase
# Puis recommencer la clôture de la feature
```
**SourceTree :**
1. **Ne pas faire de commit** — uniquement **"stage"** les fichiers résolus
2. **"Continue Rebase"**
3. Répéter pour chaque commit de `develop`
4. Recommencer la clôture de la feature — cette fois **sans cocher "Rebase"**
### 4.4 Mettre à jour Jira
Passer le ticket à **"Revue de code"**.
## Checklist journalière
- [ ] `git pull` en début de journée sur votre branche
- [ ] Commits petits et explicites tout au long de la journée
- [ ] **Avant commit** : export custom app + uGNA + GNA (si concerné)
- [ ] **Soir** : tous les commits poussés sur le remote (**règle absolue**)
- [ ] Avant clôture : `develop` à jour + rebase réussi
## Parameters / Branches Git Flow
| Type | Préfixe | Source | Destination | Objet |
|------|---------|--------|-------------|-------|
| Feature | `feature/` | `develop` | `develop` | Développements courants (ex : `feature/PD-49`) |
| Bugfix | `bugfix/` | `develop` | `develop` | Corrections de bugs sur le développement en cours |
| Release | `release/` | `develop` | `master` + `develop` | Préparation d'une release |
| Hotfix | `hotfix/` | `master` | `master` + `develop` | Correctifs urgents en production |
| Support | `support/` | `master` | — | Maintien d'une version antérieure |
## Common errors
- **Pop-up de connexion SmartUI** après déploiement sur nouvelle branche → procédure dédiée Confluence (pas traité ici).
- **Perte de travail suite à casse PC** → n'a pas respecté la règle du push de fin de journée. Règle **absolue**.
- **Rebase qui répète les mêmes conflits** → normal : `git flow feature finish -r` rejoue chaque commit. Résoudre, stage, `continue`, recommencer.
- **SourceTree re-clôture et re-rebase** → après résolution manuelle des conflits, relancer la finalisation **sans cocher "Rebase"** (c'est l'étape 4.3 → 4.2).
- **Fichiers custom app manquants après commit** → stager **tous** les fichiers (workflow + C# + DESIGN séparés). Faire un `git status` avant commit pour vérifier.
- **Conflits systématiques sur le manuel de reten DOC** → utiliser Markdown pendant le dev, conversion DOC uniquement en fin de chantier (cf. [development-methodology](development-methodology.md)).
- **Push refusé ("non-fast-forward")** → `git pull --rebase` sur votre branche avant de re-push.
## Related
- [Development Methodology](development-methodology.md) — cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod)
- [Git Branch Lifecycle](git-branch-lifecycle.md) — gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA
- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) — clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE
- [Custom Application Management](custom-application-management.md) — export/import systématique avant commit
- [uGNA Data Export](ugna-data-export.md) — export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit)
- [Code Review Process](code-review-process.md) — revue Code/Fonctionnel/Documentation avant `Finish Feature`
- [Deploy Existing Application](deployment-existing-app.md) — déploiement après pull ou changement de branche
- [Deploy Specific Commit](deployment-specific-commit.md) — figer un commit pour démo / debug
- [GNA, Services & License](gna-services-license.md) — sauvegarde GIT des scripts BOO avant commit
wiki/operations/gna-services-license.md
+164
View File
@@ -0,0 +1,164 @@
---
title: "GNA, Services & License Installation"
type: operation
sources:
- sources/archives/Installation_Services_Licence_WMS.md
related:
- architecture/overview.md
- concepts/erp-interface.md
- operations/first-deployment.md
- operations/deployment-existing-app.md
- operations/git-workflow.md
- operations/ugna-data-export.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# GNA, Services & License Installation
## Overview
Procédures d'installation et de gestion des **services adjacents** au WMS sur une VM de développement :
- **GNA** (Generic Notification Applications) — service de messagerie ERP ↔ WMS : sauvegarde GIT des scripts/XSD + réinstallation sur VM
- **Label Printer** — service d'impression d'étiquettes
- **Licence WMS** (EasySTS) — demande / import de la licence projet pour que la VM fonctionne au-delà de 7 jours
Le GNA est le composant qui porte la communication ERP (messages tels que `ROR`, `SOR`, `STV`, `SOF`…) — voir [erp-interface](../concepts/erp-interface.md) pour la sémantique fonctionnelle des messages.
Source : Confluence EasyWMS France — *Installation Services et Licence WMS* (v19, 15/04/2025).
## Service GNA
### Sauvegarder la configuration sur le GIT
À faire **à chaque fois qu'un script BOO est modifié**, pour que les changements soient disponibles aux autres devs après merge + pull.
#### Localisation du dossier `InstallApplications`
- **Installation manuelle** (ancien) → dossier dézippé lors de l'installation du GNA
- **Installation automatique** (nouveau) → **`C:\deploy\Prof.Serv.Deploy\InstallApplications`**
#### Exécution du script
```powershell
cd C:\deploy\Prof.Serv.Deploy\InstallApplications
.\GNAGetDataForGit.ps1
```
Le script **exporte les fichiers nécessaires à l'installation du GNA** (scripts BOO + sources XSD).
> ⚠️ 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 — composition du fichier SOF02
Le fichier final `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` |
#### Chemins GNA selon version des scripts de deploy
> ⚠️ Avec les nouvelles versions des scripts (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 **`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>
```
#### Destination sur le GIT
Récupérer le dossier GNA créé par le script et l'ajouter au GIT dans :
```
\services\GNA
```
Puis commit + push (cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications)).
### Réinstallation d'un GNA
Procédure à suivre si le GNA a déjà été installé sur la VM et doit être réinstallé (ex : changement de version, correction config).
1. Télécharger **`InstallApplication.zip`** depuis [la doc Mecalux](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 du projet et le **copier dans le dossier dézippé**
3. Remplacer **`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 :
```powershell
.\DeployCommsApps.ps1
```
Choisir l'option **"complete"**.
> En cas d'erreur : voir Confluence *Installation GNA — Exécution de l'installation*.
## Service Label Printer
Pour installer le service d'impression d'étiquettes, suivre la documentation dédiée :
**[Printer service et imprimante PDF : Installation et configuration](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/5538376)** (non reproduite ici).
## <a id="license"></a>Licence WMS
Par défaut la VM fonctionne **7 jours**. Au-delà, la licence projet est requise.
### 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
```
Cliquer sur le bouton **"Export"** en bas de page pour en obtenir le fichier.
> Si personne n'est disponible côté France, faire une demande au support espagnol via la [documentation dédiée Confluence](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 mise à jour dans **EasySTS**.
## Règles pratiques
- **GIT commit du dossier `\services\GNA`** à chaque modification de script BOO — sinon les autres devs travaillent sur une version obsolète.
- **Ne jamais pousser le XML composé** de `XSD/` — uniquement les fichiers de `XSD_Source` (sinon duplications).
- **Vérifier les chemins `responses.xml`** si le script d'export plante (nouvelle location `C:\Program Files\...`).
- **Toujours dézipper `InstallApplication.zip` frais** lors d'une réinstallation — ne pas réutiliser un dossier existant qui pourrait mélanger les versions.
- **Licence à renouveler avant expiration** — sinon WMS inutilisable sur la VM.
## Common errors
- **`GNAGetDataForGit.ps1` plante "dossier GNA non trouvé"** → chemins `XSDPath` / `commsPath` pointent vers `C:\ProgramData\...` alors que le GNA a été installé dans `C:\Program Files\...` via le nouveau deploy script. Corriger `responses.xml`.
- **Duplications de lignes dans un XSD composé** → quelqu'un a copié directement le XSD final dans `XSD_Source`, au lieu de partir des sources. Toujours passer par `GNAGetDataForGit.ps1`.
- **Réinstallation GNA qui échoue** → dossier `InstallApplication` mal reconstitué (manque `Config` / `Scripts` / `TaskDefinitions` / `XSD` dans le `GNA.zip`). Reprendre étape 4 de la réinstallation.
- **`responses.xml` pointe vers un mauvais `FromGIT`** → la réinstallation tire une config d'un autre projet. Vérifier l'URL `FromGIT` avant exécution de `DeployCommsApps.ps1`.
- **WMS bloque au bout de 7 jours sur la VM** → licence projet non importée. Faire la demande et utiliser `Submit license` dans `EasySTS/License`.
- **Export licence impossible depuis `EasySTS/License`** → VM plus joignable ou licence déjà expirée côté Easy. Contacter les chefs d'équipe pour repartir d'une licence serveur.
## Related
- [System Architecture Overview](../architecture/overview.md) — architecture IIS / services WMS
- [ERP Interface](../concepts/erp-interface.md) — messages ERP portés par le GNA (ROR/SOR/SOF/STV/etc.)
- [First Deployment](first-deployment.md) — déploiement initial (GNA inclus dans `EnabledModules`)
- [Deploy Existing Application](deployment-existing-app.md) — redéploiement après mise à jour GNA
- [Git Workflow](git-workflow.md) — commit/push du dossier `\services\GNA` après modification de scripts BOO
wiki/operations/robotics-project-lifecycle.md
+149
View File
@@ -0,0 +1,149 @@
---
title: "Robotics Project Lifecycle (DTR, Planning, Tests, Roles)"
type: operation
sources:
- sources/archives/Organisation_projet_Robotique.md
- sources/archives/Planning_Installation_Miniload.md
- sources/archives/DTR_configuration_reseau_materiel.md
- sources/archives/Documents_utiles.md
- sources/archives/Plan_tests_stations.md
related:
- architecture/galileo-integration.md
- operations/galileo-simulation.md
- operations/galileo-troubleshooting.md
- operations/vm-installation.md
- operations/vm-network-routing.md
- operations/first-deployment.md
- concepts/mechanical-elements.md
- concepts/stations.md
last_compiled: "2026-04-17"
---
# Robotics Project Lifecycle (DTR, Planning, Tests, Roles)
## Overview
Robotics projects — installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) — require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live.
## 1. Project organization
A robotics project pulls in multiple Mecalux stakeholders:
- **Chef de chantier** — site supervisor for the mechanical build
- **Chef de projet IT** — IT lead (WMS + automation integration)
- **Responsable électricité** — electrical lead
- **Responsable de projet** — master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time
The **Responsable de projet** is the single point of escalation; without them, gaps between disciplines (e.g. the rack is installed but the DTR has not been validated) lead to slippage.
> The canonical organisational diagram for a robotics project is on [Confluence — Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874).
## 2. DTR — Document Technique de Référence
The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation — hardware, IP addresses, services, accounts — along with the **responsibility split between Mecalux and the client**.
The DTR answers "who provides what and by when":
- WMS server specs and OS
- Network segments (WMS LAN, PLC LAN, wireless for RF terminals)
- IP allocations (WMS, Gateway, GALILEO PLCs, RF terminals, printers, scanners)
- Services (Active Directory, DNS, NTP, SMTP)
- Physical access and ports opened between segments
The DTR template lives on [Confluence — DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira.
## 3. Planning (Miniload installation)
Two reference plannings used on every miniload project:
1. **Global installation planning** — overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live)
2. **IT ROB planning** — the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare)
Both plannings live as Gantt images on [Confluence — Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality.
## 4. Reference documentation
| Document | Purpose | Location |
|----------|---------|----------|
| **Control_Communications_Interface_EN_GB.pdf** | All station types, event types, PIE flags | [MSSCC Automation docs](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) |
| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level — used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) |
| **Stations index** | Station-specific behaviours and quirks | [MSSCC Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) |
Use them as the source of truth when writing the functional spec / interface document with GALILEO.
## 5. Station test milestone
Before the first real container enters the installation, run the **Plan de tests des stations** to confirm that EasyWMS and GALILEO agree on every station, route, container type and height type.
### 5.1 Container type / height type sync
Every support entering a TK must pass through a **PIE** first, which calibrates the support. GALILEO reports to the WMS:
- Barcode read
- **Container Type** (PLC Container Type)
- **Height Type** (PLC Height Type)
Both types are defined in EasyS via the **PLC Types** menu.
> ⚠️ On miniloads, container type and height are usually **coupled**. If GALILEO reads `PLCHeightType = 1`, the `PLCType` must also be `1`. Explicit coupling must be recorded in the interface document and cross-checked on site.
### 5.2 Station audit query
Run on the **writing** database to extract the WMS view of GALILEO stations and their coordinates:
```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 with StationFrom — see full query on Confluence
.OrderBy(sr => sr.StationType)
.ThenBy(sr => sr.StationNumber)
```
Compare the result with the GALILEO program (`C:\<NomDuClient>\Programme\<installation>.mgp`) line by line.
### 5.3 "Full" route checks
GALILEO must be able to push these routes as **status 3 = Full** (otherwise recirculation logic cannot work):
| Source type | Destination type |
|-------------|------------------|
| CME | TE (ME) |
| PKE | PK |
| ET | PS |
Verify during simulation by temporarily saturating each route and confirming the Gateway log shows the `3` status.
## 6. Pre-go-live checklist
Consolidated checklist merging what each phase must deliver:
- [ ] DTR signed by client and Mecalux (hardware, IPs, services provisioned)
- [ ] VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md))
- [ ] EasyWMS deployed (see [First Deployment](first-deployment.md))
- [ ] EasyS layout matches the execution plan (racks, stations, routes, PLC Types)
- [ ] Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open
- [ ] Station test query matches GALILEO `.mgp` station list
- [ ] PLC Container Type / PLC Height Type coupling validated in simulation
- [ ] "Full" route checks passed (CME→TE, PKE→PK, ET→PS)
- [ ] End-to-end flows validated in EasyS (PIE → Miniload → PK → PS)
- [ ] Reject route + floor virtual route configured (no lost container)
- [ ] Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md))
## Related
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference
- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, PIE injection, station sync
- [Galileo Troubleshooting](galileo-troubleshooting.md) — log analysis, faults
- [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md) · [First Deployment](first-deployment.md)
- [Mechanical Elements](../concepts/mechanical-elements.md) · [Stations & Routes](../concepts/stations.md)
wiki/operations/ssh-keys-setup.md
+91
View File
@@ -0,0 +1,91 @@
---
title: "SSH Keys Setup (MSSCODE & Sourcetree)"
type: operation
sources:
- sources/archives/Configuration_cle_SSH_MSSCODE_Sourcetree.md
related:
- operations/git-workflow.md
- operations/git-branch-lifecycle.md
last_compiled: "2026-04-17"
---
# SSH Keys Setup (MSSCODE & Sourcetree)
## Overview
Procédure interne Mecalux EasyWMS France pour générer une **clé SSH ed25519**, l'enregistrer sur **MSSCODE** (le Gitea interne Mecalux) et la connecter à **Sourcetree**. Une fois en place, Sourcetree n'a plus à demander les identifiants MSSCODE à chaque opération Git — seul le mot de passe de la clé SSH est exigé à l'ouverture de Sourcetree.
Source : Confluence EasyWMS France — *Configuration d'une clé SSH pour MSSCODE et Sourcetree* (v2, 28/01/2026).
## 1. Génération de la clé SSH
### Prérequis
**Git installé** sur le poste, puis ouverture de **Git Bash** (pas PowerShell, pas CMD).
### Commande
```shell
ssh-keygen -t ed25519 -C "your_email@example.com"
```
À l'invite **`Enter file in which to save the key`** : appuyer sur **Entrée** (chemin par défaut `/c/Users/<user>/.ssh/id_ed25519`).
À l'invite **`Enter passphrase`** : saisir un **mot de passe fort** (recommandé), puis le confirmer.
> ⚠️ Le mot de passe de la clé est **unique et non modifiable**. En cas d'oubli, il faut **régénérer une nouvelle paire de clés**. Une clé sans mot de passe est techniquement possible mais **fortement déconseillée**.
Deux fichiers sont créés dans `C:\Users\<user>\.ssh\` :
- `id_ed25519` — clé **privée** (à ne jamais partager)
- `id_ed25519.pub` — clé **publique** (à enregistrer sur MSSCODE)
## 2. Enregistrement de la clé sur MSSCODE
1. Se connecter à **MSSCODE** → accéder à la gestion des clés SSH
2. Cliquer sur **"Ajouter une clé"**
3. Donner un nom à la clé (ex : `Auth`)
4. Coller le contenu **complet** du fichier `id_ed25519.pub`
5. MSSCODE déclenche une **vérification de la clé via signature SSH renforcée**
### Vérification renforcée
> ⚠️ **Ne pas copier l'exemple de commande** affiché dans la documentation Confluence : le **jeton de vérification est unique et change à chaque tentative**. Utiliser systématiquement la commande **fournie en direct par MSSCODE**, en y ajoutant le chemin vers la clé privée entre apostrophes simples.
Forme générale :
```shell
echo -n 'votre_jeton_unique' | ssh-keygen -Y sign -n gitea -f 'C:\Users\<user>\.ssh\id_ed25519'
```
Saisir le mot de passe de la clé SSH → la commande imprime une **signature**. Copier celle-ci dans le champ **"Signature SSH renforcée"** de MSSCODE puis cliquer sur **"Vérifier"**.
## 3. Configuration de Sourcetree
1. Ouvrir **Sourcetree** → **Tools** → **Options**
2. Onglet **General** → section **SSH Client Configuration** :
- **SSH Client** : sélectionner **`OpenSSH`**
- **SSH Key** : cliquer sur **`[...]`** et désigner `id_ed25519` (clé **privée**)
3. Sourcetree demande le **mot de passe** de la clé → le saisir et valider
## 4. Cloner via SSH (obligatoire)
> ⚠️ **Important** : avec une clé SSH, il faut cloner les dépôts via le **lien SSH** (et non HTTPS). Sinon Sourcetree continuera à demander les identifiants MSSCODE à chaque opération.
Le lien SSH est exposé sur la page du dépôt MSSCODE (bouton "Code" / "Clone" → onglet **SSH**).
## Comportement attendu
- Sourcetree n'**ouvre plus de prompt MSSCODE** pour clone / fetch / pull / push.
- Le mot de passe **de la clé SSH** est demandé **une fois par session Sourcetree** (à l'ouverture). Sourcetree mémorise ensuite la passphrase pour la durée de vie du process.
## Common errors
- **Sourcetree redemande encore le mot de passe MSSCODE** → le repo a été cloné en HTTPS. Re-cloner via le lien SSH (ou re-pointer le remote `origin` vers l'URL SSH).
- **`Permission denied (publickey)`** → la clé publique n'a pas été enregistrée sur MSSCODE, ou la vérification renforcée n'a pas été validée.
- **Vérification renforcée refuse la signature** → l'utilisateur a copié l'exemple de commande de la doc et non celle générée par MSSCODE (jeton expiré / ne correspond pas à la session). Recharger la page MSSCODE et utiliser la commande fournie.
- **Mot de passe de la clé oublié** → régénérer une paire de clés et refaire la procédure (pas de récupération possible).
## Related
- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git quotidiennes effectuées avec cette clé
- [Git Branch Lifecycle](git-branch-lifecycle.md) — cycle des branches Git par phase de projet
wiki/operations/troubleshooting.md
+566
View File
@@ -0,0 +1,566 @@
---
title: "Troubleshooting Guide"
type: operation
sources:
- wiki/concepts/container.md
- wiki/concepts/location.md
- wiki/concepts/stock.md
- wiki/concepts/task.md
- wiki/concepts/order-inbound.md
- wiki/concepts/order-outbound.md
- wiki/concepts/product-item.md
- wiki/concepts/reception.md
- wiki/concepts/putaway.md
- wiki/concepts/picking.md
- wiki/concepts/shipping.md
- wiki/concepts/replenishment.md
- wiki/concepts/crossdocking.md
- wiki/concepts/count.md
- wiki/concepts/stock-adjustment.md
- wiki/concepts/consolidation.md
- wiki/concepts/defragmentation.md
- wiki/concepts/quality-control.md
- wiki/concepts/manual-movements.md
- wiki/modules/agv.md
- wiki/modules/pallet-shuttle.md
- wiki/modules/multi-carrier.md
- wiki/modules/yard-management.md
- wiki/modules/dom.md
- wiki/architecture/overview.md
- wiki/architecture/security.md
related:
- concepts/parameters.md
- architecture/overview.md
- architecture/security.md
- concepts/erp-interface.md
- concepts/transactions.md
last_compiled: "2026-04-10"
---
# Troubleshooting Guide
Organized by **symptom category**. Each entry: symptom → cause → solution. For parameter references, see [Parameters](../concepts/parameters.md). For ERP message reference, see [ERP Interface](../concepts/erp-interface.md).
---
## 1. Inbound / Reception
### Receipt order not found from RFT
- **Cause:** Order code unknown to WMS or ROR message not yet received from ERP.
- **Solution:** Enable `ALLOW_CREATE_RECEPTION` to allow blind receipt creation; or have ERP resend the ROR message first.
### ASN container rejected at PIE — order doesn't exist
- **Cause:** The receipt order referenced in the ASN message has not yet arrived in WMS.
- **Solution:** If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received and the reserve is formalized later. If active, resolve the absent receipt order first before retrying PIE entry.
### Quantity discrepancy at PIE — container sent to reconditioning
- **Cause:** ASN pre-notified quantity doesn't match the received quantity, and the receipt order does not allow excess.
- **Solution:** Correct the discrepancy at the reconditioning station, then retry induction into the PIE.
### Receipt auto-close does not trigger
- **Cause:** Receipt still has uncommitted lines, or at least one line allows over-receipt.
- **Solution:** Close manually via PC, or verify that `AutoCloseReception` is active and that no lines allow excess reception.
### Receipt order cannot be canceled
- **Cause:** Stock has already been received against the order.
- **Solution:** Use "Close" instead of "Cancel" to finalize the order; cancel only unreceived quantity.
### Unexpected stock received but not accepted (lines auto-creation)
- **Cause:** `Allow lines auto-creation` flag not enabled on the order header.
- **Solution:** Enable the flag on the order, or manually create the missing line before reception begins.
### Over-receive blocked
- **Cause:** `LneTrmExceedPerc` = 0 or not set on the receipt order line.
- **Solution:** Request ERP to update the line with a positive tolerance percentage, or adjust the received quantity to match the ordered quantity.
### ROC / status notification not sent to ERP
- **Cause:** WMS-ERP integration configuration issue, or integration pool stopped.
- **Solution:** Check ERP communication settings, verify the integration application pool is running (IIS), and check message queue for backlog.
### Transfer receipt order has no ASN
- **Cause:** The source warehouse did not close the corresponding Transfer-type shipping order.
- **Solution:** Verify the source warehouse has closed the transfer shipping order — ASN is auto-generated at that point.
### Order stuck in "Receiving" status
- **Cause:** Associated receipts are still open (not yet closed).
- **Solution:** Close or finalize all associated receipts; the order will then advance.
### Multiple stock lines created for same item at receipt close
- **Cause:** Exclusive reserve (ASN container) splits stock into reserved and unreserved portions.
- **Expected behavior:** Each portion has its own reserve linkage. No corrective action needed.
### PIE semi-automatic: container waits indefinitely at station
- **Cause:** Operator has not scanned the label manually after auto-read failure.
- **Solution:** Have the operator scan the label manually at the semi-automatic PIE station.
---
## 2. Putaway
### No valid location found — manual warehouse
- **Cause:** All strategies exhausted; no location meets the combination of criteria + restrictions + rules. Common causes: all eligible zones full, location type mismatch, strategy sequence incomplete.
- **Solution:** Operator must manually select a destination. Review: strategy sequence coverage, restrictions not overly restrictive, no locations marked full or locked.
### No valid location found — automatic warehouse (rejection task generated)
- **Cause:** All aisles at the relocation percentage limit, no route from current station to any candidate, or weight limit exceeded everywhere.
- **Solution:** Container is diverted to rejection station. Review aisle relocation configuration, available routes, and weight constraints.
### Aisle balancing blocks putaway
- **Cause:** Aisle selected by balance formula has no valid locations (full or incompatible). The system does not fall back to a different aisle for that strategy.
- **Solution:** Ensure the next strategy in the sequence has adequate location coverage; or relax aisle balance thresholds.
### Container stuck in equipment (not located)
- **Cause:** Operator ended session without completing the putaway task; container remains associated with equipment.
- **Solution:** Resolve via manual relocation from the equipment management view in SmartUI.
### Picking dedicated location (PDL) not proposed during putaway
- **Cause:** No PDL created for this item, or PDL is for different logistic attributes.
- **Solution:** Create a PDL for the correct item/attribute combination, or adjust the strategy sequence so that strategy 1 (assigned location) covers this item.
### Cutting stock putaway fails validation at RFT
- **Cause:** Operator entered a partial quantity instead of the full stretch quantity.
- **Solution:** Cutting stock requires total-quantity entry. Reject partial entries and re-enter the correct full stretch quantity.
### Putaway location not found for stacked LPN
- **Cause:** Effective width (width + 2 × collapse) of the stack exceeds available location dimensions, or no strategy applies to the stack configuration.
- **Solution:** Use the **Putaway search location trace** report on the LPN (PC required). Review excluded aisles and strategy criteria.
---
## 3. LPN / Container
### LPN not found at expected location
- **Symptom:** Physical LPN present but WMS shows a different location.
- **Cause:** Manual move not recorded, or a system error occurred during a task.
- **Solution:** Use "Location change" (PC) to correct the record without creating a task. If location unknown, use "Send to Lost & Found" and investigate transaction history.
### Cannot unstack base LPN
- **Symptom:** Unstack operation rejected.
- **Cause:** Location has FIFO configuration, or LPN types stacked above the base are incompatible.
- **Solution:** Move the entire stack to a stage first (enable `UNSTACK_ON_STAGE`), or use "Undo all" to break the full hierarchy at once.
### Lock prevents task execution (task canceled after lock applied)
- **Cause:** The lock type disallows picking, replenishment, or movement. Cascade effect automatically cancels in-flight tasks.
- **Solution:** Check lock type configuration. If the reason for the lock is resolved, unlock the LPN and re-process using alternative stock.
### Cannot modify LPN type or division type
- **Cause:** LPN is not empty — still contains stock.
- **Solution:** Pick out or move all stock from the LPN, then change the type.
### ASN LPN cannot be deleted
- **Cause:** LPN is linked to a receipt order (ROR).
- **Solution:** Cancel or disassociate the receipt order first, or use the rejection flow (triggers `CON.CNL.ASN` → `ASK` message to ERP).
### Stock shows in WMS but location is physically empty
- **Cause:** Container moved physically without a system record (no task or manual movement registered).
- **Solution:** Use "Send to Lost & Found" to reconcile; investigate transaction history to find the last known position.
---
## 4. Stock & Inventory
### Stock not visible in the stock view
- **Cause:** Stock is in a virtual location (ASN, Lost_Found, or Mov) or filtered out by active view filters.
- **Solution:** Remove view filters; check virtual locations explicitly.
### Stock in lock not assignable for picking/shipping
- **Cause:** User or receiving status active on the stock prevents shipping.
- **Solution:** Release the lock manually (Quality Control view) or via STR message from ERP; or add the required status to the SOR line.
### Cannot adjust ASN container stock
- **Cause:** Stock is in a pre-notified container not yet received.
- **Solution:** Complete the reception first; adjustments on received stock are then available.
### Cannot adjust client stock
- **Cause:** Stock is prepared for a shipping order inside a client container.
- **Solution:** Un-prepare the stock via Shipping management, then adjust.
### Adjustment fails — reason required
- **Cause:** No adjustment reason selected; none configured for the Adjustment capture process.
- **Solution:** Create reasons in `Masters > Adjustment reasons`; select one before submitting the adjustment.
### Cannot decrease stock below zero
- **Cause:** System prevents negative stock by default.
- **Solution:** Verify stock is actually at the expected location. If the physical stock is missing, run a count on the location.
### STV not sent to ERP after adjustment
- **Cause:** The adjusted stock belongs to an open reception.
- **Solution:** Close the reception first; the STV message is sent at reception close.
### Quantity jumps unexpectedly after a quantity-decrease adjustment
- **Cause:** Other stock lines from the same item were consolidated with this one at some point.
- **Solution:** Separate stock lines if needed; use the "From multiple receptions" selection to target specific lines.
---
## 5. Picking / Order Preparation
### Order line stays incomplete — no stock assigned
- **Cause:** All stock assignment strategies exhausted without finding eligible stock. Typical causes: stock status blocks picking, count task active on the picking location, no PDL configured for item, extraction errors at candidate locations.
- **Solution:** Check stock statuses, cancel any active count tasks on the location, verify PDL configuration, resolve extraction errors.
### Picking task not proposed by system (despite stock assigned)
- **Cause:** The picking location has a lock preventing picking, or the aisle is blocked.
- **Solution:** Resolve the lock or block; or trigger a location reassignment.
### PTL device not illuminating
- **Cause:** PK station not configured for PTL, PTL device/controller disabled, or MP has more than one container when auto-destination is expected.
- **Solution:** Check workstation configuration and PTL device/controller status.
### Grouped picking reverts to individual
- **Cause:** A compatibility condition failed (logistic attribute capture required, or MP has stock from a different order).
- **Solution:** Check PK station configuration and the current MP state.
### Excess over-picking
- **Cause:** Operator picked more than requested; system reduces remaining tasks for the same item by the excess.
- **Solution:** If the order doesn't allow excess, an error is thrown and the operator must undo the excess immediately.
### Cutting stock: wrong length cut
- **Cause:** Cutting stock requires exact-quantity handling.
- **Solution:** Register an incidence, recut to the correct length; re-enter the old stretch into inventory with the corrected quantity.
### Client container full before order complete
- **Cause:** Container capacity exhausted mid-picking.
- **Solution:** Operator uses the "close container" action on the RFT; a new client container is created automatically for remaining tasks.
### Item not appearing in stock assignment
- **Cause:** No shipping profile assigned, or the shipping profile excludes the stock's current status.
- **Solution:** Verify the item's shipping profile; check required/rejected status flags on the SOR line.
### Substitute not used during stock failure
- **Cause:** Substitutes not configured in the shipping profile, or not enabled on the SOR line (`LneTrmAlternative`).
- **Solution:** Check shipping profile substitution mode and enable substitute usage on the order line if needed.
---
## 6. Shipping
### Order stays in "Created" after release attempt
- **Cause:** Stock assignment failed for all lines (no eligible stock). Common causes: stock status blocks picking, locations locked, active count tasks, missing PDL configuration.
- **Solution:** Check stock statuses, resolve location locks, cancel conflicting count tasks, verify PDL setup.
### Tasks generated but no operator picks up
- **Cause:** Tasks assigned to specific equipment that is offline, or operator is logged into the wrong zone/sub-warehouse.
- **Solution:** Check equipment assignment on the order; clear if no specific equipment should be required.
### Route containers loaded in wrong order
- **Cause:** Operator ignored system warnings or route stop numbers are incorrectly configured.
- **Note:** Route stop numbers must be in **reverse delivery sequence** (last stop loaded first) to ensure correct unloading order.
### Consolidation station not receiving containers
- **Cause:** Consolidation station assigned after order release. Only new container movements route to the station post-assignment.
- **Solution:** Assign the consolidation station before order release for all prepared containers to be re-routed.
### Load closed without all containers
- **Cause:** Partial close triggered (intentional or misconfigured).
- **Solution:** ERP receives load-close notification; track missing containers manually or assign them to a new load.
### Order mixing containers rejected
- **Cause:** Two orders cannot mix per the mixing strategy (different customer, incompatible logistic attributes).
- **Solution:** Review mixing strategy criteria; create a separate strategy for these order types if mixing should be allowed.
### PS group not releasing containers to outbound
- **Cause:** PS group not assigned to the order, or all PS stations in the group are locked.
- **Solution:** Assign the PS group to the order or unlock the PS stations.
### SOF not sent after order close
- **Cause:** WMS-ERP integration issue, or order was closed without an active ERP connection.
- **Solution:** Check integration configuration; retry via forced resend if the functionality is available.
### Cannot cancel order — stock already prepared
- **Cause:** Picking tasks have been completed; stock is in a client container.
- **Solution:** Undo preparation (un-prepare from the consolidation or truck loading view) before canceling.
### Excess stock prepared on a line
- **Cause:** Over-allocation due to containerized or indivisible stock.
- **Solution:** Use the "Return excess" operation before closing, or configure `LneQtyAllowExcess = 0` on the order.
---
## 7. Replenishment
### Replenishment task not generated for empty PDL
- **Cause:** "Automatic replenishment" not enabled on the PDL, no stockout strategy active, or no valid source stock found.
- **Solution:** Enable automatic replenishment on the PDL; verify source location availability and stock status.
### PDL not proposed for picking despite having stock
- **Cause:** Stock assignment strategy does not prioritize PDLs, or PDL logistic attributes don't match the shipping order line.
- **Solution:** Check strategy "Prioritize picking dedicated locations" flag and PDL attribute configuration.
### Dynamic PDL created with wrong capacity
- **Cause:** The shipping order was created or canceled between background job runs.
- **Expected behavior:** Capacity is recalculated on the next job run. No manual intervention needed if the job is running correctly.
### Replenishment task generated but not executed
- **Cause:** Replenishment source has a lock, the aisle is blocked, or no route exists between source and PDL.
- **Solution:** Resolve the lock/block; check route configuration.
### Stock mixing conflict at PDL during replenishment
- **Cause:** Different logistic attribute values at the PDL during unload.
- **Note:** System does NOT block the task (to avoid deadlock), but warns the operator. If mixing is undesired, configure the PDL with specific required logistic attributes.
### PDL released unexpectedly
- **Cause:** "Delete when empty" flag is enabled on the PDL.
- **Solution:** Disable "Delete when empty" for year-round items; use only for seasonal items.
### Cutting stock replenishment not triggered
- **Cause:** Pending tasks exist for the reel in the PDL location, which blocks demand-strategy replenishment.
- **Solution:** Wait for current tasks to complete, or add a stockout strategy as well (overrides the task-pending check).
---
## 8. Count / Stock Adjustment
### Count order stuck in "Releasing"
- **Cause:** Automatic warehouse — containers are still moving at release time.
- **Solution:** Wait until all containers have reached a static location, then release the count order.
### Count line shows conflict icon — no stock
- **Cause:** Item count line requested for an item with zero stock in the warehouse.
- **Solution:** Use "Force Close" to finalize the line; review item master to understand the discrepancy.
### Count line shows conflict icon — location not configured for count
- **Cause:** Location does not have the "Allow count" flag enabled in EasyS.
- **Solution:** Fix the location configuration in EasyS, or delete the problematic line.
### COF message not sent to ERP after count close
- **Cause:** Count originated from a COR request and still has pending adjustments (double validation active).
- **Solution:** Validate or cancel all pending adjustments in `Warehouse > Stock adjustments`.
### Cycle count generates uneven task distribution
- **Cause:** Volatile stock levels change mid-iteration (especially with item-based schedules).
- **Expected behavior:** Task distribution adjusts dynamically. Fine-tune schedule parameters if distribution is too uneven.
### Cannot re-release a cycle count after cancel
- **Cause:** By design — cycle count orders are non-re-releasable.
- **Solution:** Create a new manual count for the affected locations.
### No adjustment reasons visible on RFT
- **Cause:** No reasons configured for the "Adjustment" capture process.
- **Solution:** Add reasons in `Masters > Adjustment reasons`.
### Adjustment applies but no STK.ADJ transaction visible
- **Cause:** Double validation is active for this item; adjustment is in "Pending" state.
- **Solution:** A manager must validate or cancel the pending adjustment in `Warehouse > Stock adjustments`.
---
## 9. Quality Control & Locks
### STC message not sent to ERP after quality lock
- **Cause:** Reception associated with the stock is still open.
- **Solution:** Close the reception first; STC is sent at reception close.
### Automatic unlock not happening
- **Cause:** The background job `Delete_StockStatusJob_PR` is disabled or not running.
- **Solution:** Check job status in `Configuration > Jobs`; verify it is scheduled to run every 15 minutes.
### Picking tasks not canceled after quality lock applied
- **Cause:** The stock status (lock type) does not have "blocks picking" configured.
- **Solution:** Check the stock status master configuration for the applied status; enable "blocks picking" if required.
### Cannot unlock stock from RFT
- **Cause:** Operator role lacks access to the "Quality" menu.
- **Solution:** Assign the appropriate station role/menu permission to the operator's profile.
### Cutting stock: partial lock not splitting correctly
- **Cause:** Non-consolidating UoM not configured for the item.
- **Solution:** Verify cutting item configuration; check the UoM consolidation flag.
### STC generated without lock being set
- **Cause:** Reception was already closed at the time of the lock request.
- **Expected behavior:** Open receptions suppress STC; closed receptions trigger STC immediately on lock.
---
## 10. Tasks & Automation
### Task stuck in "Generated" state
- **Cause:** Assigned equipment is offline, or no equipment can access the task's work zone.
- **Solution:** Release the equipment assignment; reassign to available equipment or leave unassigned for any qualified equipment.
### Task created but not assignable
- **Cause:** Equipment type incompatible with the container type specified in the task.
- **Solution:** Assign different equipment; check equipment-container type compatibility configuration.
### Task cannot be manually completed
- **Cause:** Task type is picking, counting, stock replenishment, kit assembly, or consolidation — these must be completed through their respective process screens.
- **Solution:** Complete via the appropriate screen (picking station, count screen, etc.).
### Movement stuck "In Execution"
- **Cause:** Automatic warehouse malfunction or communication failure.
- **Solution:** Use "Movement Release" to reset the movement back to Pending; investigate the automation incident.
### Task canceled — container not found at location
- **Cause:** Operator reported the wrong location at cancellation, or the container was moved without a system record.
- **Solution:** Run a count on the expected location; use Lost & Found if needed.
### Automatic warehouse tasks not generating
- **Cause:** Background job (replenishment/defragmentation planner) not running.
- **Solution:** Check `Control > Jobs` in SmartUI; verify the relevant job is active and its schedule is correct.
---
## 11. AGV & Pallet Shuttle
### AGV notification events — full error code table
| Code | Error |
|------|-------|
| 1001 | Incorrect load station |
| 1002 | Incorrect unload station |
| 1003 | Duplicate transport order |
| 1004 | Invalid operation type |
| 1010 | Unload station modification error (phase 03+) |
| 1011 | Priority modification error (after assignment) |
| 1012 | Inactive transport order |
| 1013 | Null task number |
| 1014 | Inconsistent AGV movement (e.g., unload when not loaded) |
| 2003 | Extraction error at non-storage location |
| 2004 | Putaway error at non-storage location |
| 2005 | Manual cancellation from AGV interface |
| 2500 | Communication error — sending order |
| 2501 | Communication error — priority update |
| 2502 | Communication error — cancellation |
| 2503 | Communication error — destination change |
### AGV extraction error
- **Behavior:** No container found at pickup location.
- Conventional rack / APS: task canceled; location marked with **"Mark for review"** lock type.
- Other storage: task canceled; location marked with **"For AGV"** lock type.
- Non-storage (stage/dock): task NOT canceled; AGV held pending manual action; user notified.
- **Solution:** Physically verify the location; resolve via count or manual relocation; clear the lock after resolution.
### AGV putaway error
- **Behavior:** Destination occupied.
- Conventional rack / APS: WMS searches for a relocation; destination marked with "Mark for review" lock type.
- Other storage: relocation search; destination marked with "For AGV" lock type.
- Non-storage: AGV held pending manual action; user notified.
### Pallet Shuttle fault flag
- **Cause:** Multiple possible causes; details in PS diagnostic log.
- **Solution:** Reset → retry. If flag re-activates: all PS tasks canceled, PS unavailable for new tasks; user notified. Investigate physical PS condition.
### Pallet Shuttle tilt error
- **Cause:** PS is mispositioned in the channel.
- **Solution:** Reset → retry. Same escalation as fault flag if persistent.
### Pallet Shuttle low battery
- **Behavior:** PS completes current tasks → returns to pickup position → disconnects → awaits AGV dispatch to charging station. If no charging station is available: user is notified.
### PS task in process — cannot be canceled
- **Cause:** AGV system is already involved in the movement.
- **Note:** Only tasks in "Pending" state (waiting/pending shipping with CREATE action) can be canceled. Tasks in any other state must complete.
---
## 12. ERP Integration
### ERP messages not processed (queue backlog)
- **Cause:** Integration application pool stopped or message queue backed up.
- **Solution:** Check the Integration IIS pool; restart if stopped. Review integration logs for parsing errors.
### API calls return HTTP 401
- **Cause:** API key expired or invalid.
- **Solution:** Regenerate the API key in the integration configuration.
### ASN reserve not created at receipt
- **Cause:** The expected outbound order did not exist at receipt time and the reserve validity deadline (`ExpectedReserveValidDate`) has passed.
- **Solution:** Check `ExpectedReserveValidDate`; re-create the reserve manually on the outbound order if needed.
### DOM: assignment error on sales order (no node passes orchestration)
- **Cause:** No node passes all 5 orchestration stages (region → carrier → stock → capacity → strategies).
- **Solution:** Check geographic region config, carrier-node assignments, stock availability at nodes, and node workload configuration.
### DOM: geolocation failure
- **Cause:** Delivery address is not geocodable (missing or invalid country/postal code).
- **Solution:** Verify address contains a valid ISO country code and postal code.
### Multi-Carrier: cannot create delivery
- **Cause:** No carrier assigned to the shipping order, and no auto-selection rule matches.
- **Solution:** Assign carrier via SOR message or configure an auto-selection rule.
### Multi-Carrier: tracking number error
- **Cause:** Carrier tracking files missing from server directory.
- **Solution:** Copy carrier-provided tracking files to the configured archives directory.
### Yard Management: cannot assign dock to appointment
- **Cause:** Dock not compatible with the appointment's commodity or vehicle type.
- **Solution:** Check and update dock compatibility configuration.
---
## 13. System / Infrastructure
### IIS application pool stopped
- **Cause:** Background job crash or unhandled exception.
- **Solution:** Check Windows Event Log and application logs; restart the pool after diagnosing the root cause.
### RF terminal cannot connect
- **Cause:** WIFI network issue or IIS binding misconfiguration.
- **Solution:** Verify WIFI connectivity; check IIS site bindings for the RF application.
### "Development environment" error in browser
- **Cause:** `ASPNETCORE_ENVIRONMENT` is set to `Development` on a production server.
- **Solution:** Change the environment variable to `Production` and restart IIS.
### 3PL client sees other owners' data
- **Cause:** Owner Extensions module not configured.
- **Solution:** Enable the Owner Extensions module and assign the correct owner to the 3PL user.
### User cannot access a menu
- **Cause:** Role missing the required menu permission.
- **Solution:** Add the menu item to the user's role in AD configuration.
### RF terminal login rejected
- **Cause:** User has no station role assigned for that station type.
- **Solution:** Assign the appropriate station role to the user.
---
## 14. Master Data & Configuration
### Item cannot be received
- **Cause:** No reception profile assigned to the item.
- **Solution:** Assign a reception profile before creating any receipts for this item.
### Location not offered in putaway
- **Cause:** Location is full, locked for putaway, in the wrong storage zone, or has a type/capacity mismatch.
- **Solution:** Check the full flag, lock types, storage zone configuration, and container type compatibility.
### Cannot change FIFO/LIFO on a location
- **Cause:** Location is not empty.
- **Solution:** Empty the location completely before changing the FIFO/LIFO setting.
### Lock not recalculating reserves
- **Cause:** Lock type has "Allow reserving" enabled.
- **Note:** Only locks with "Allow reserving" **disabled** trigger reserve recalculation.
### Mixing error at reception
- **Cause:** Logistic profile "Allow mixing" set to No for a logistic attribute, and two different values are present in the container.
- **Solution:** Receive items in separate containers, or enable mixing in the logistic profile.
### Days-of-life validation fails at shipping
- **Cause:** Stock end-of-life date < current date + required days specified on the SOR line.
- **Solution:** Ship with other eligible stock, or explicitly allow expired stock on the order if business rules permit.
### Consolidation orders generated but no tasks created
- **Cause:** PK station not in "All Modes" or "Consolidation Only" working mode.
- **Solution:** Update the picking station working mode configuration.
### Defragmentation tasks not generated
- **Cause:** No valid destination location found for any candidate container.
- **Solution:** Check zone configuration in strategies; verify putaway strategies are defined for target zones.
---
## Related
- [Parameters](../concepts/parameters.md) — Full parameter reference; values controlling most behaviors above
- [ERP Interface](../concepts/erp-interface.md) — All ERP message types, fields, and error codes
- [Transactions](../concepts/transactions.md) — Transaction codes for audit trail investigation
- [Security](../architecture/security.md) — Role and permission configuration
- [System Architecture](../architecture/overview.md) — IIS pools, background jobs, infrastructure
- [Quality Control](../concepts/quality-control.md) — Stock status lock/unlock system
- [AGV](../modules/agv.md) — Full AGV error code reference
- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS diagnostics and error handling
wiki/operations/ugna-data-export.md
+89
View File
@@ -0,0 +1,89 @@
---
title: "uGNA Data Export (WMS Configuration → Git)"
type: operation
sources:
- sources/archives/Export_donnees_uGNA.md
related:
- operations/git-workflow.md
- operations/gna-services-license.md
- operations/first-deployment.md
- operations/deployment-existing-app.md
last_compiled: "2026-04-17"
---
# uGNA Data Export (WMS Configuration → Git)
## Overview
Procédure interne Mecalux EasyWMS France pour **exporter la configuration / les données du WMS** (paramètres, profils, master data, etc.) depuis une VM via **uGNA Console**, et les commiter dans le Git du projet (dossier `..\test`).
À exécuter **systématiquement** avant tout commit dès qu'une nouvelle configuration, transporteur, paramètre ou autre master data a été ajouté(e) ou modifié(e) sur la VM. C'est l'une des trois étapes pré-commit (avec l'export custom app et la sauvegarde GNA si BOO modifiés) listées dans [git-workflow](git-workflow.md#étape-préalable--exporter-les-modifications).
Source : Confluence EasyWMS France — *Export des données via uGNA* (v5, 18/10/2023).
## ⚠️ Prérequis : VM à jour
> ⚠️ Si on exporte depuis une VM **qui n'est pas à jour** par rapport au Git, on risque d'exporter des données qui auraient pu être **supprimées** (régression silencieuse). **Pull** + redéploiement de la branche avant tout export.
## Procédure d'export
1. Ouvrir une **Invite de commandes** (CMD, **pas** PowerShell) **en administrateur**
2. 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
```
3. Récupérer les fichiers XML générés dans :
```
C:\Program Files (x86)\Mecalux\uGNA\Export
```
4. Copier ces fichiers dans le dossier **`..\test`** de la branche Git du projet
5. **Commit + push** le dossier `..\test` mis à jour
## Liste des entités exportées
L'option `-Z:` accepte une liste séparée par virgules. La commande standard ci-dessus couvre 41 entités, regroupées ci-dessous par domaine :
| Domaine | Entités |
|---|---|
| Master data — Owners / Accounts | `owner`, `account`, `accounttype`, `company` |
| Master data — Items | `product`, `productfamily`, `productype`, `productlocation`, `alias`, `uom` |
| Master data — Suppliers / Carriers | `supplier`, `suppliertype`, `agency`, `deliveriescarrier`, `carrierselectionconfiguration` |
| Master data — Kits & Hazards | `kit`, `hazzardclass`, `divtype` |
| Profils | `logisticprofile`, `receptionprofile`, `putawayprofile`, `shippingprofile`, `cuttingprofile`, `countprofiles` |
| Stratégies | `putawaystrategy`, `putawayrestriction`, `replenishmentstrategy`, `stockassignstrategy`, `stockassignstrategyV2`, `ShippingProfileAssignmentStrategy`, `stockclassificationbyzone` |
| Classes & ABC | `inboundclass`, `outboundclass`, `abc` |
| Stations & Workstations | `pickingstationconfig`, `printerstationconfig`, `packagingstages`, `shiptemplate` |
| Locks & status | `containerlocktype`, `locationlocktype`, `stockstatus` |
| Configurations diverses | `parameter`, `transactiontype`, `outboundordercancelconfiguration`, `adjustreason` |
> Pour la liste exhaustive des entités exportables (notamment pour des **exports spécifiques**), consulter la doc Confluence dédiée : [uGNA](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/25788478).
## Common errors
### Erreur de droits d'écriture sur le dossier cible
Si l'export échoue avec une erreur d'écriture sur `C:\Program Files (x86)\Mecalux\uGNA\` :
1. **Clic droit** sur le dossier `C:\Program Files (x86)\Mecalux\uGNA` → **"Propriétés"**
2. Onglet **"Sécurité"**
3. Sélectionner votre utilisateur → **"Modifier"**
4. Cocher **"Contrôle total"** dans la colonne **"Autoriser"**
5. **"Appliquer"** puis **"OK"**
6. Relancer la commande d'export
### Autres pièges
- **PowerShell utilisé au lieu de CMD** → la commande peut casser sur les guillemets / l'option `-Z:`. Toujours utiliser **invite CMD en admin**.
- **Données exportées contiennent des entrées supprimées** → la VM n'était pas à jour vs Git. Pull + redéploiement avant export.
- **Oubli du commit/push après export** → l'export reste local. Toujours stager le dossier `..\test` et pousser sur la branche.
## Related
- [Git Workflow (Git Flow)](git-workflow.md) — étape pré-commit "export uGNA"
- [GNA, Services & License](gna-services-license.md) — sauvegarde des fichiers BOO du GNA (`GNAGetDataForGit.ps1`), processus distinct de l'export uGNA
- [First Deployment](first-deployment.md) — l'arborescence `..\test` est consommée à la première installation (`Data: test/`)
- [Deploy Existing Application](deployment-existing-app.md) — les exports uGNA sont rechargés à chaque redéploiement
wiki/operations/vm-installation.md
+170
View File
@@ -0,0 +1,170 @@
---
title: "VM Installation (Hyper-V) & Validation"
type: operation
sources:
- sources/archives/Installation_VM_Hyper-V.md
- sources/archives/Valider_sa_machine_virtuelle.md
related:
- architecture/overview.md
- operations/first-deployment.md
- operations/development-methodology.md
- operations/vm-network-routing.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# VM Installation (Hyper-V) & Validation
## Overview
Procédure interne Mecalux EasyWMS France pour créer et valider une **machine virtuelle de développement** sous Hyper-V. Chaque développeur dispose de sa propre VM locale (ou hébergée sur serveur), préparée à partir d'un template fourni par l'équipe, puis configurée pour être jointe au réseau Mecalux et permettre le déploiement d'un projet.
La VM sert de cible de déploiement pour :
- Le **core EasyWMS** (via script `deploy_repository.ps1`)
- La **configuration entrepôt** (via EasyS / uGNA)
- La **custom application** du projet (via EasyBuilder)
- Les services adjacents (GNA, Printer Service, EasySTS License, SmartUI, etc.)
Sources : Confluence EasyWMS France — *Installation de la VM sur Hyper-V* (v30, 02/12/2025) + *Valider sa machine virtuelle* (v7, 14/02/2023).
## Prérequis
- Accès réseau au partage **`\\lyoitsw02\TEMPLATE\`**
- Rôle **Hyper-V** activé sur le poste (ou serveur Hyper-V disponible)
- Droits administrateur local
## 1. Récupérer le template de VM
1. Ouvrir **`\\lyoitsw02\TEMPLATE\`** dans l'explorateur
2. Copier le dossier **`TEMPLATE_INTEGRATION_[DB]`** en local, par exemple dans **`D:\Hyper-V\DEV`**
Choix de la base de données selon le mode de déploiement cible en production :
| Mode | BDD |
|------|-----|
| SaaS | **PostgreSQL** |
| On-premise | **Oracle** |
## 2. Création de la VM dans Hyper-V
| Étape | Paramètre | Valeur |
|-------|-----------|--------|
| Génération | - | **Génération 2** (toutes fonctionnalités) |
| Nom | Convention | `DEV-<PRENOM>` (ex : `DEV-NICO`) |
| RAM | Initiale | **4 Go (4096 Mo)** avec mémoire dynamique activée |
| Connexion réseau | Poste local | **InternoNAT** |
| Connexion réseau | Serveur | **VMs** |
| Disque dur | Source | **Existant** → `win10ent.vhdx` du dossier template |
La convention `DEV-<PRENOM>` évite les interconnexions non désirées entre VM de différents développeurs.
## 3. Configuration post-création (dans Hyper-V)
> Ne pas faire le paramétrage NAT si c'est une VM d'intégration.
| Paramètre | Valeur | Raison |
|-----------|--------|--------|
| RAM dynamique max | **6 Go (6144 Mo)** | Éviter qu'Hyper-V dépasse la capacité du poste |
| Processeurs | **4** | Performances compilation / WMS |
| Points de contrôle | **Activés** | Snapshot "Deploy 0" après config initiale |
## 4. Configuration réseau (dans la VM locale)
> À faire **uniquement sur VM locale**. Sur VM hébergée sur serveur → passer à l'étape 5.
1. `Windows + R` → `NCPA.CPL`
2. Propriétés du réseau Ethernet → protocole **IPv4**
3. Saisir :
- IP : `10.255.255.2`
- Masque : `255.255.255.0`
- Passerelle : `10.255.255.1`
4. **Advanced → DNS** — saisir les 4 serveurs DNS Mecalux :
- `192.168.0.102`
- `192.168.0.104`
- `192.168.0.56`
- `192.168.66.250`
5. Suffixe DNS : **`mecalux.com`**
## 5. Renommer la VM (Windows)
1. **Paramètres Windows → System → About** (en bas du volet gauche)
2. **"Rename this PC"** — saisir le nom de la VM
> ⚠️ **Avant redémarrage**, mettre à jour les fichiers Oracle suivants (remplacer `localhost` par le nouveau nom) :
> - `tnsnames.ora`
> - `listener.ora`
>
> Localisation selon template :
> - Template Oracle 12 : `C:\Mecalux\Motor\oracle\product\12.2.0\dbhome_1\network\admin`
> - Template Oracle 19 : `C:\Mecalux\Motor\oracle\Product\19.17.0.0\dbhome_1\network\admin`
> ⚠️ Pour les templates Oracle : **nom limité à 15 caractères**.
3. **Redémarrer** la VM
## 6. Installation des logiciels personnels
Avant le premier point de contrôle, installer ce qui est nécessaire :
- **Git** (obligatoire) — vérifier avec `git --version` ; à défaut : [git-scm.com/download/win](https://git-scm.com/download/win)
- Éditeurs personnels (Sublime Text, VSCode, Notepad++…)
- SourceTree si absent du template (voir [git-workflow](git-workflow.md))
## 7. Point de contrôle "Deploy 0"
Créer un point de contrôle **"Deploy 0"** — c'est le snapshot de référence à partir duquel un nouveau projet pourra être déployé (cf. [first-deployment](first-deployment.md)).
Entre deux projets, on applique ce point de contrôle pour repartir d'une VM propre.
## Validation de la VM
Après le premier déploiement d'un projet sur la VM (cf. [first-deployment](first-deployment.md)), vérifier que l'installation est fonctionnelle.
### 1. Vérifier les services et IIS
1. Service Windows **MongoDB** démarré (sinon : démarrer)
2. **IIS Manager** — pour chacune des applications ci-dessous, `Browse` doit ouvrir la page sans erreur :
- **`AD`** (Application Dictionary API)
- **`ApplicationService`**
- **`EasySTS`** (License)
- **`SmartUI`**
- **`SmartUIServices`**
> ℹ️ Si IIS remonte "ne trouve pas `localhost/<service>`", c'est un problème IIS et pas forcément d'installation. Tester dans un navigateur **depuis la VM** sur `localhost/smartui`.
### 2. Accès depuis le PC physique
Si SmartUI fonctionne depuis la VM mais pas depuis le PC hôte :
1. Ouvrir **`C:\inetpub\wwwroot\SmartUI\script\config.js`**
2. Mettre la variable **`defaultURL`** à vide
3. Vérifier que les lignes standards sont bien présentes dans `config.js` (si la page reste bloquée sur le grand "M" de Mecalux)
### 3. Activer consoleRF (si besoin)
Si la connexion à **consoleRF** boucle sur l'input du nom d'utilisateur :
1. Aller sur **`https://<votre_vm>/SmartUIservices/home`**
2. Se connecter avec `mecalux` / `mecalux`
3. **Parameters** → chercher **`EnableLegacyRFMode`**
4. Activer sa **2e checkbox**
5. Sauvegarder (bouton en bas à droite)
## Common errors
- **VM ne démarre pas / Génération 1 choisie par erreur** → recréer la VM en Génération 2. La Génération 2 est requise pour disposer de toutes les fonctionnalités (secure boot, UEFI, disque VHDX).
- **Conflits IP entre VM de devs différents** → respecter la convention `DEV-<PRENOM>` et utiliser **InternoNAT** (pas le switch par défaut). Sur serveur, utiliser la connexion **VMs**.
- **Oracle ne démarre pas après renommage** → `tnsnames.ora` / `listener.ora` non mis à jour avec le nouveau hostname. Vérifier chemin selon version Oracle template.
- **Nom de VM refusé par Oracle** → dépasser 15 caractères sur template Oracle casse les services. Raccourcir le nom Windows.
- **SmartUI inaccessible depuis le PC hôte** → `config.js` → `defaultURL` doit être vide. Sinon SmartUI tente de joindre une URL relative au serveur de template.
- **consoleRF boucle sur le login** → activer `EnableLegacyRFMode` (2e checkbox) dans SmartUIservices/Parameters.
- **`localhost/<service>` introuvable dans IIS** → faux positif classique. Tester `localhost/smartui` dans un navigateur sur la VM avant de conclure.
- **Mémoire dynamique > RAM du poste hôte** → Hyper-V peut saturer l'hôte. Toujours borner la RAM dynamique max à **6 Go**.
## Related
- [System Architecture Overview](../architecture/overview.md) — stack IIS/ASP.NET Core/Oracle/PostgreSQL déployée sur la VM
- [First Deployment](first-deployment.md) — déploiement initial d'un projet sur une VM fraîchement créée
- [Deploy Existing Application](deployment-existing-app.md) — redéploiement sur VM déjà préparée
- [GNA, Services & License](gna-services-license.md) — installation des services adjacents (GNA, Printer, License WMS)
- [Development Methodology](development-methodology.md) — méthode de travail et stratégie de branches autour de la VM
wiki/operations/vm-network-routing.md
+117
View File
@@ -0,0 +1,117 @@
---
title: "VM Network Routing (NAT, Localhost, IP, VPN)"
type: operation
sources:
- sources/archives/Routage_vers_les_VM.md
related:
- operations/vm-installation.md
- operations/deploy-test-application.md
last_compiled: "2026-04-17"
---
# VM Network Routing (NAT, Localhost, IP, VPN)
## Overview
Référence des **règles de routage réseau** entre le PC hôte et la VM EasyWMS de développement (Hyper-V, commutateur **InternoNAT**). Lors de la création de la VM ([vm-installation](vm-installation.md)), un NAT est configuré pour rediriger certains ports du PC hôte vers la VM, afin de **ne pas bloquer les ports applicatifs standards (80/443/3389/1521/445) côté PC**.
Cette page décrit :
- La table de correspondance des ports (interne VM ↔ externe PC)
- Les modes d'accès (localhost depuis la VM, IP depuis un autre poste)
- Les passerelles VPN à utiliser depuis une délégation Europe
Source : Confluence EasyWMS France — *Routage vers les VM* (v7, 11/08/2023).
## 1. Tableau de correspondance NAT
| Service | Port interne VM | Port externe PC n°1 | Port externe PC n°2 |
|---|---|---|---|
| HTTP | 80 | **8080** | 8008 |
| HTTPS | 443 | **4430** | 4431 |
| Connexion bureau à distance (RDP) | 3389 | **33890** | 33891 |
| Oracle | 1521 | **15210** | 15211 |
| SMB | 445 | **4450** | 4451 |
> Toute requête TCP reçue sur le PC hôte sur le port **8080** est redirigée vers **10.255.255.2:80** (l'IP fixe de la VM, cf. [vm-installation](vm-installation.md#configuration-réseau-ipv4)). Le port externe n°2 sert quand on doit faire tourner **deux VMs en parallèle** sur le même hôte.
### Commandes Windows utiles
```powershell
Get-NetAdapter # Liste tous les adaptateurs réseau
Get-NetNatStaticMapping # Affiche les routes statiques NAT (PC ↔ VM)
```
## 2. Accès **depuis la VM** (en local)
Depuis l'intérieur de la VM, on utilise **`localhost`** + port interne, ou directement le **DNS** de la VM (sans port).
| Cible | URL |
|---|---|
| EasyBuilder en HTTPS | `localhost:4430` |
| SmartUI via DNS | `https://<nom_vm>/smartui/` |
> Note : `4430` est le port externe NAT — depuis la VM, accéder via `localhost:443` fonctionne aussi pour HTTPS interne. La doc Confluence donne `localhost:4430` car la VM peut être interrogée via la machine hôte qui résout le NAT.
## 3. Accès **depuis un autre PC**
`localhost` et le **DNS de la VM** ne sont **pas accessibles** depuis un autre poste — il faut utiliser l'**IP du PC hôte** suivie du port externe NAT.
### Récupérer son IP
**Option A — Paramètres Windows :**
1. Clic droit sur l'icône réseau dans la barre des tâches
2. **"Ouvrir les paramètres réseau et Internet"**
3. **"Propriétés"** de l'adaptateur Ethernet
4. Récupérer l'**adresse IPv4**
**Option B — PowerShell :**
```powershell
ipconfig
```
Récupérer l'**IPv4** de l'adaptateur Ethernet.
### Exemples d'accès distants
| Cible | URL exemple (IP `192.168.164.214`) |
|---|---|
| EasyBuilder HTTPS | `192.168.164.214:4430` |
| EasyS HTTPS | `192.168.164.214:4430` |
| SmartUI | `192.168.164.214:4430/smartui` |
| Bureau à distance (RDP) | `192.168.164.214:33890` |
> Pour que SmartUI s'affiche correctement depuis le PC hôte, il faut aussi avoir vidé `defaultURL` dans `SmartUI\script\config.js` (cf. [vm-installation — Validation](vm-installation.md#validation-de-la-vm)).
## 4. Utilisation avec le VPN Mecalux
> Note Espagne : **délégations Europe (sauf Gijón)** → utiliser **Europe 4** ou **Europe** uniquement via SSL.
| Passerelle | Adresse | Port |
|---|---|---|
| Europe | `vpn-europa@mecalux.com` | 4443 |
| Europe 4 | `vpn-europa4@mecalux.com` | 443 |
### Conflits VPN connus
Si la connexion VPN échoue malgré tout, vérifier la présence de **ZAPP** ou **Zscaler APP** sur la machine physique :
1. **Désinstaller** ZAPP / Zscaler APP
2. **Redémarrer** le poste
3. Réessayer la connexion
Si le problème persiste, envoyer un mail à **`it@mecalux.com`** avec l'objet :
```
No Hyper-V NAT connectivity
```
## Common errors
- **SmartUI accessible depuis la VM mais pas depuis le PC hôte** → vérifier `defaultURL` (vide) dans `SmartUI\script\config.js` côté VM (cf. [vm-installation](vm-installation.md#validation-de-la-vm)).
- **EasyBuilder en HTTPS répond `connexion refusée` sur `:4430`** → règle NAT manquante ou commutateur InternoNAT mal sélectionné lors de la création de la VM. Vérifier `Get-NetNatStaticMapping`.
- **Connexion RDP impossible depuis un autre poste** → utiliser le port externe `33890`, pas `3389` (3389 n'est pas redirigé sur le PC hôte).
- **VPN Europe répond mais aucune VM accessible** → ZAPP / Zscaler installé : désinstaller + redémarrer.
- **Pas d'accès aux URL Mecalux et VPN OK** → ouvrir un ticket `No Hyper-V NAT connectivity` à `it@mecalux.com`.
## Related
- [VM Installation (Hyper-V) & Validation](vm-installation.md) — création de la VM, IP fixe `10.255.255.2`, commutateur InternoNAT
- [Deploy Test Application](deploy-test-application.md) — déploiement d'une livraison sur la VM de test (utilise ces accès réseau)