Arthur Ria
489 lines
20 KiB
Markdown
489 lines
20 KiB
Markdown
---
|
|
title: "Flux expédition — Processus complet"
|
|
tags: [outbound, expédition, défragmentation, étiquetage, chargement, recertification, messagerie, litiges, AGV]
|
|
status: draft
|
|
standard_ref: concepts/shipping.md
|
|
jira_refs: []
|
|
confluence_refs: ["Expédition - LIMAGRAIN - DEV"]
|
|
sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Expédition - LIMAGRAIN - DEV - Confluence.md"]
|
|
last_updated: 2026-05-13
|
|
author: Arthur
|
|
---
|
|
|
|
# Flux expédition — Processus complet
|
|
|
|
> **Résumé** : processus d'expédition de bout en bout en 12 étapes, de la
|
|
> réception de l'OS jusqu'à la libération du quai, incluant les flux
|
|
> spécifiques (re-certification, messagerie carton, consommation OF, litiges).
|
|
|
|
> **Standard EasyWMS** : → voir [Shipping](../../concepts/shipping.md)
|
|
> Ce qui suit documente les **spécificités Limagrain** par rapport au standard.
|
|
|
|
## Contexte projet
|
|
|
|
Le processus d'expédition est composé de 12 étapes. Les palettes passent
|
|
par une zone de défragmentation client dans l'ASRS avant d'être sorties
|
|
vers les poumons. Un custom clé gère l'ordonnancement : la défragmentation
|
|
ne se déclenche que quand toutes les palettes de picking sont terminées.
|
|
|
|
## Processus global
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
SOR["1. Réception SOR/RUT"] --> LIB["2. Libération auto/manuelle"]
|
|
LIB --> ASSIGN["3. Assignation stock"]
|
|
ASSIGN --> GEN["4. Génération tâches"]
|
|
GEN -->|Picking requis| PK["5. Assignation poste travail"]
|
|
GEN -->|Palettes complètes| DEFRAG["CUSTOM: Défrag → zone client"]
|
|
PK --> PICK["6. Préparation au poste"]
|
|
PICK --> CADENCE["7. Cadencement tâches"]
|
|
CADENCE --> POUMON["8. Assignation poumon/quai"]
|
|
DEFRAG --> POUMON
|
|
POUMON --> SORT["9. Déplacement + étiquetage auto"]
|
|
SORT --> AGV["AGV → dépose poumon"]
|
|
AGV --> CHARG["10. Chargement camion"]
|
|
CHARG --> SOF["11. Clôture → SOF + LOF"]
|
|
SOF --> LIBRE["12. Libération quai/poumon"]
|
|
```
|
|
|
|
## Étapes détaillées
|
|
|
|
### 1. Réception de l'ordre de sortie
|
|
|
|
L'ERP envoie une commande d'expédition vers EasyWMS : un **SOR** (commande
|
|
de sortie) ou un **RUT** (image camion pouvant contenir plusieurs SOR
|
|
ordonnancés par n° de STOP). Voir [Ordres de sortie](shipping-orders.md).
|
|
|
|
### 2. Libération de l'ordre de sortie
|
|
|
|
| Mode | Description |
|
|
|------|-------------|
|
|
| Automatique | Date/heure de libération définie dans le SOR/RUT (mode principal). Par défaut `PlannedShippingDate - 48h`. |
|
|
| Manuelle | Depuis l'écran des ordres de sortie dans EasyWMS |
|
|
|
|
### 3. Assignation du stock
|
|
|
|
Voir [Ordres de sortie — Assignation](shipping-orders.md#assignation-de-stock)
|
|
pour les stratégies détaillées (FIFO 24h, économie de mouvement, pas de
|
|
FEFO, max palettes complètes).
|
|
|
|
### 4. Génération des tâches
|
|
|
|
| Type de palette | Action |
|
|
|-----------------|--------|
|
|
| Palettes complètes / picking terminées | [CUSTOM] Tâche de défragmentation (reloc) vers zone d'expédition ASRS. Ne se déclenche que si **toutes** les palettes clientes sont « terminées » et qu'aucun quai n'est associé à l'OS. Voir [Défragmentation custom](../02-stockage/defragmentation.md#custom-défrag-client-par-tournée--quai-non-assigné-lim-87). |
|
|
| Palettes picking | Aucune tâche tant qu'un poste de travail n'est pas assigné |
|
|
|
|
> **Règle générale** : on n'envoie aucune palette sur l'image de quai tant
|
|
> que le picking n'est pas terminé (et que les palettes sont revenues à
|
|
> l'ASRS) — sauf si le stop précédent est fini.
|
|
>
|
|
> **Deux customs complémentaires** gèrent l'ordonnancement par STOP :
|
|
> quai non assigné → [Défragmentation custom](../02-stockage/defragmentation.md),
|
|
> quai assigné → [Séquençage shipping par STOP](sequencage-shipping-stop.md).
|
|
|
|
> **Note** : l'information du passage en conteneur client est disponible
|
|
> dans le LOC envoyé périodiquement à SAP.
|
|
|
|
### 5. Assignation du poste de travail
|
|
|
|
Assignation **automatique** depuis EasyWMS. Modes possibles par poste :
|
|
Picking, Réception, Regroupement, Échantillonnage, Recertification, Tous.
|
|
|
|
**Contrainte** : seuls les postes **P5 et P6** (équipés palan) peuvent
|
|
être assignés pour les processus comportant au moins une palette Big-Bag.
|
|
|
|
**Priorité** : WS PK picking rob en priorité, et si trop limité, utiliser
|
|
le **process RF** comme fallback (plus robuste pour picking négatif,
|
|
multi-tables, etc.). Le process de réception est déjà plugué au mode
|
|
Automatic tasks de la WS (custom) → même mode pour le picking.
|
|
|
|
Voir [Stations picking](../03-picking/stations-picking.md).
|
|
|
|
### 6. Préparation au poste de travail
|
|
|
|
#### Arrivée des palettes (toujours un poste 3 TP)
|
|
|
|
- Première palette au **centre** si picking négatif proposé, sinon sur un côté
|
|
- Si une palette est sur un côté et qu'on propose du picking négatif →
|
|
prévenir l'opérateur de déplacer la palette au centre
|
|
- La palette client revient **toujours** au centre
|
|
- Pas de prépa sur 6 TP en simultané
|
|
|
|
#### Ordonnancement des prélèvements
|
|
|
|
1. **Espèce Maïs** toujours en premier (pas la variété)
|
|
2. Puis espèce avec la **plus grande quantité** dans la commande
|
|
3. Si égalité : **article/lot le plus lourd** en base de palette
|
|
|
|
**Mapping Espèce → stack (gerbabilité)** : maïs = stack 0 (le plus
|
|
lourd/stable, en base). [CUSTOM] Gestion en async sur l'ITM pour calculer
|
|
la gerbabilité automatiquement à la création de l'article. Tri via
|
|
workflow `StackerCrane_SortTasks_PR`.
|
|
|
|
#### Règles de picking
|
|
|
|
| Règle | Détail |
|
|
|-------|--------|
|
|
| Picking négatif | **Deux conditions cumulatives** (réu. 11/05/2026) : seuil fiche article (défaut **55%**, pas 50%) ET poids unitaire sac **≥ 7 kg**. Si l'une des deux n'est pas remplie → picking direct classique. Voir [Picking combinatoire](../03-picking/picking-combinatoire.md#custom-règle-du-picking-négatif). |
|
|
| ~~Traitement commercial~~ | ~~Articles avec/sans traitement sur palettes filles séparées~~ — **SUPPRIMÉ** (réu. 11/05/2026, `CONTROLE_TRAITEMENT_COMMERCIAL = false`). L'entrepôt ne fait pas de bio. |
|
|
| Verrou « HORS TOLERANCE » | Si présent → recomptage avant picking. Si stock restant suffisant après inventaire → assignation maintenue. Sinon → réassignation ailleurs + retrait verrou. |
|
|
|
|
#### Algorithme de répartition des palettes sur les TP
|
|
|
|
[CUSTOM] Logique combinatoire complète gérant : picking négatif et
|
|
enchaînements, ordonnancement par espèce, terminer une palette pleine
|
|
avant d'en entamer une autre, cadencement des buffers, pas de mélange
|
|
traitement commercial, contrainte opérateur (pas de déplacement de sacs
|
|
d'une table à l'autre — sacs lourds).
|
|
|
|
**Table du milieu** : toujours occupée soit par une palette de picking
|
|
négatif, soit par une palette vide de dépôt. Palette vide remise
|
|
manuellement sur pile quand vidée.
|
|
|
|
#### Étiquetage au picking
|
|
|
|
**Palettes MII et multi-lots** : 1 étiquette HU RFID pour la palette
|
|
physique (HU mère) + 1 étiquette HU sans RFID par ligne de stock
|
|
(HU fille / intercalaire). Impression auto à chaque nouvelle palette
|
|
(RFID) et à chaque article (intercalaire).
|
|
|
|
**Autres palettes** : 1 étiquette HU RFID uniquement. Basé sur la
|
|
classe de commande.
|
|
|
|
#### Message MOV
|
|
|
|
~~À chaque déplacement de stock durant le picking, un message MOV est
|
|
envoyé à SAP.~~ **ANNULÉ** — vu en réunion client, jugé inutile.
|
|
|
|
#### Filmage
|
|
|
|
Avant chaque évacuation, l'opérateur choisit le programme de filmage
|
|
(CstData transmis à Galileo). Possibilité de choisir « pas de filmage ».
|
|
|
|
**Programmes de filmage disponibles** :
|
|
|
|
| Code | Espèce | Contenant | Mode |
|
|
|------|--------|-----------|------|
|
|
| A | Tournesol | Sacs | Complet |
|
|
| B | Tournesol | Sacs | Réduit |
|
|
| C | Tournesol | Big Bag | Complet |
|
|
| D | Tournesol | Big Bag | Réduit |
|
|
| E | Maïs & Blé | Sacs | Complet |
|
|
| F | Maïs & Blé | Sacs | Réduit |
|
|
| G | Maïs & Blé | Big Bag | Complet |
|
|
| H | Maïs & Blé | Big Bag | Réduit |
|
|
|
|
Voir [Picking combinatoire](../03-picking/picking-combinatoire.md) pour
|
|
les détails du processus de préparation.
|
|
|
|
### 7. Cadencement des tâches
|
|
|
|
Séquence pour une commande « classique » :
|
|
|
|
1. Lancement de la commande (quelques heures/jours avant la prépa réelle)
|
|
2. Les tâches de shipping **ne se déclenchent pas** tant que le poumon/quai
|
|
n'est pas assigné
|
|
3. Les palettes deviennent « client » → information dans le LOC
|
|
4. Si la commande n'a pas de poumon assigné, ou si TK dispo (tâche prio
|
|
très basse), l'ASRS déplace les palettes de shipping vers une **zone
|
|
tampon** du magasin proche des sorties (via défrag en tâche de fond)
|
|
5. Si un PK est dispo, les tâches de picking se génèrent → palettes
|
|
vont aux PK
|
|
6. À chaque palette pickée et terminée :
|
|
- Selon classe de commande → retour TK ou non
|
|
- Si retour ASRS : tâche AGV (PK → Entrée TK)
|
|
- Si messagerie : tâche vers le poumon d'expédition choisi manuellement
|
|
- Si aucun poumon choisi → prompt
|
|
7. La palette de picking **re-rentre dans le TK directement au bon
|
|
endroit** (zone client) avec si possible canal dédié à la route. Pas
|
|
de stockage temporaire puis défrag la nuit.
|
|
8. Assignation du poumon → génération des tâches de shipping
|
|
|
|
### 8. Assignation quai / poumon
|
|
|
|
**Par défaut** : un quai « QUAI_TEMPORAIRE » est assigné, accessible par
|
|
toutes les images de quai. Simplement assigner un poumon pour lancer la
|
|
livraison.
|
|
|
|
**À la libération** : le stock va jusqu'à l'image de quai (poumon exp).
|
|
Le vrai quai est précisé ultérieurement (affichage chauffeur). Association
|
|
commande ↔ quai pour le chargement, camion ↔ quai dans une vue dédiée.
|
|
|
|
**Dès qu'un poumon est assigné** : les tâches de mouvement vers ce poumon
|
|
sont générées, même si aucun quai n'est encore assigné.
|
|
|
|
Voir [Quais et poumons](consolidation-chargement.md).
|
|
|
|
### 9. Déplacement et étiquetage automatique
|
|
|
|
Palettes sortent de la zone défrag → poste de sortie ASRS.
|
|
|
|
**Étiqueteuse automatique** : deux étiqueteuses au niveau des 2 postes de
|
|
sortie TK.
|
|
|
|
Voir la section [Étiqueteuse automatique](#étiqueteuse-automatique)
|
|
ci-dessous pour le fonctionnement détaillé.
|
|
|
|
Ordonnancement des palettes sur le poumon par **n° STOP** (ordre de
|
|
livraison). Les AGV déposent en respectant l'ordre des arrêts.
|
|
|
|
### 10. Chargement camion
|
|
|
|
Le chargement camion est créé par le RUT.
|
|
|
|
1. Vérification que la palette a été étiquetée automatiquement. Si échec :
|
|
impression manuelle via imprimante sur les quais.
|
|
2. Scan de l'étiquette pour confirmer la prise en charge
|
|
3. Dépose de la palette dans le camion
|
|
4. Palette suivante jusqu'à fin de chargement
|
|
|
|
**Fermeture auto** si chargement complet : possibilité de lancer un
|
|
CloseCommand sur l'OS pour expédier ce qui est chargé.
|
|
|
|
### 11. Clôture de l'ordre de sortie
|
|
|
|
- **Automatique** lorsque tous les conteneurs sont chargés
|
|
- Messages **SOF + LOF** envoyés vers SAP
|
|
|
|
Dans un SOF, les lignes sans quantité expédiée **n'apparaissent pas**
|
|
(pas de ligne à 0).
|
|
|
|
Si un premier chargement est clôturé partiellement → vérifier si un
|
|
deuxième chargement est recréé automatiquement pour le reliquat.
|
|
|
|
> ⚠️ À paramétrer et tester : comportement du reliquat chargement
|
|
> camion, notamment avec fichier RUT.
|
|
|
|
- Le LOF représente l'image exacte du camion (palettes physiquement
|
|
chargées)
|
|
- Si une commande est expédiée sur 2 camions → 2 LOF distincts
|
|
- X SOF par commande si expédition partielle
|
|
|
|
### 12. Libération quai / image de quai
|
|
|
|
| Élément | Mode de libération |
|
|
|---------|-------------------|
|
|
| Image de quai | **Automatique** — dernière palette chargée |
|
|
| Quai | **Manuel** — départ du camion |
|
|
|
|
## Étiqueteuse automatique
|
|
|
|
### Principe
|
|
|
|
Deux étiqueteuses au niveau des deux postes de sortie TK, pouvant imprimer
|
|
une ou plusieurs étiquettes selon le processus.
|
|
|
|
### Étiquetage au picking (étiqueteuse auto)
|
|
|
|
100% des palettes passant par le picking sont étiquetées (étiquette
|
|
d'expédition) directement au PK. Un `CstAtt` est positionné à `true` sur
|
|
la palette pour indiquer qu'elle a déjà été étiquetée.
|
|
|
|
### Comportement à la sortie TK
|
|
|
|
L'étiqueteuse **n'imprime pas** si :
|
|
|
|
- `CstAtt` = `true` (palette déjà étiquetée au picking)
|
|
- OU hauteur palette trop faible (PLC height type = 1)
|
|
|
|
L'étiqueteuse **imprime** si :
|
|
|
|
- `CstAtt` = `false` ET PLC height type ≠ 1
|
|
- Si impression réussie → `CstAtt` passe à `true`
|
|
- Si impression échouée → `CstAtt` passe à `error`
|
|
|
|
### Mode dégradé — Chargement camion
|
|
|
|
Si l'opérateur scanne une palette sans étiquette (`CstAtt` = `false` ou
|
|
`error`, PLC height type ≠ 1) au chargement camion → impression
|
|
automatique sur une imprimante proche du quai.
|
|
|
|
### Communication Galileo
|
|
|
|
On envoie un **custom data** à Galileo (pas de changement de
|
|
destination/route). Galileo, en recevant le custom data avec le bon
|
|
tracking de palette, arrête les rouleaux et lance l'impression. Un seul
|
|
chemin — l'arrêt est piloté par le custom data.
|
|
|
|
### Multi-étiquettes (2 étiquettes)
|
|
|
|
2 rapports différents → **2 docs de 1 page** (= 2 demandes d'impression
|
|
simultanées). L'étiqueteuse articulée colle à 2 endroits différents sur
|
|
la palette (positions à définir avec Théo).
|
|
|
|
### Gestion des pannes
|
|
|
|
- Imprimante en échec → erreur envoyée à Galileo → Galileo met en
|
|
**défaut la ET (station)** correspondante
|
|
- Si une des deux étiqueteuses est HS → Galileo reroute automatiquement
|
|
vers l'autre poste de sortie
|
|
- [CUSTOM Galileo] Communication HS imprimante → mise en défaut ET à
|
|
documenter dans le document TMS
|
|
|
|
## Flux spécifiques
|
|
|
|
### Re-certification
|
|
|
|
La re-certification consiste à ré-étiqueter une palette existante pour
|
|
lui donner une nouvelle identité (nouvelle HU) sans déplacer physiquement
|
|
le stock. C'est une **sortie administrative** suivie d'une **réception
|
|
administrative**.
|
|
|
|
**Pré-requis** : le PK doit être passé en **mode recertif** (par le
|
|
manager), ce qui bloque le PK pour les autres types de tâches.
|
|
|
|
**Flux détaillé :**
|
|
|
|
1. L'ERP envoie un SOR de type « Recertification »
|
|
2. Le WMS crée une tâche vers QUAI_RECERTIF. La route passe par le PK
|
|
(seul chemin possible)
|
|
3. L'AGV amène la palette au PK assigné
|
|
4. [CUSTOM] **Event à l'arrivée sur le PK** : on stocke le code du PK
|
|
(ex: PK02) dans un CstAtt de la palette
|
|
5. **Route virtuelle** : la palette est déplacée informatiquement du PK
|
|
vers QUAI_RECERTIF
|
|
6. [CUSTOM] **Event sur le déplacement vers QUAI_RECERTIF** — 3 actions :
|
|
- Récupération du CstAtt (code PK d'origine)
|
|
- Fermeture de la commande → expédition du stock → génération du SOF
|
|
- Création d'une **palette vide** sur le PK d'origine (pour maintenir
|
|
la capacité correcte et empêcher le WMS d'envoyer de nouvelles
|
|
palettes sur un PK physiquement occupé)
|
|
7. L'ERP reçoit le SOF → mise à jour avec son MII en interne
|
|
8. L'opérateur recertifie physiquement la palette, ré-étiquette (hors WMS)
|
|
9. L'ERP renvoie un **ASN** avec la nouvelle identité palette
|
|
10. [CUSTOM] L'opérateur scanne la palette recertifiée au PK → le WMS
|
|
propose de choisir la table (prompt position PK). La palette passe
|
|
de ASN au bon emplacement PK. La **palette vide est supprimée**
|
|
automatiquement.
|
|
11. L'opérateur appuie sur « Ranger support » → AGV vient la chercher →
|
|
passage au PIE de réception (standard)
|
|
|
|
> ⚠️ **Risque** : si l'ASN n'est pas encore arrivé au moment du scan →
|
|
> erreur, réessayer plus tard.
|
|
|
|
> ⚠️ **3 mini-customs identifiés** : event de stockage CstAtt + event
|
|
> de fermeture/création palette vide + suppression palette vide au scan ASN.
|
|
|
|
### Messagerie carton
|
|
|
|
**Solution recommandée** : **Pick and Pack** (module transporteur). Plus
|
|
simple, pas de colisage séparé, impression étiquette directe. **Nécessite
|
|
le module transporteur.** Plan B : fusion des lignes comme alternative.
|
|
|
|
**Sans module transporteur** : custom le picking PK avec un mode
|
|
« messagerie carton » :
|
|
|
|
1. Commandes descendues dans un RUT de type « Messagerie carton » (classe
|
|
d'expédition)
|
|
2. Tous les OS préparés en simultané sur un seul poste de travail
|
|
3. Tri par transporteur (l'opérateur ne peut déposer que sur une seule
|
|
palette). Via modèle d'expédition à créer avec le client.
|
|
4. Impression étiquette colis à la première tâche de picking
|
|
(SOR.Code, SOR.Account, SOR.Delivery, SSCC colis 128)
|
|
5. Consolidation sur palette unique
|
|
6. Prélèvement dans un carton (support identifié) puis sur palette
|
|
7. Indicateur à l'opérateur quand un carton ne recevra plus de stock →
|
|
fermer le carton
|
|
8. Bouton « Palette pleine » sur la WS :
|
|
- Impression SSCC
|
|
- Collage par l'opérateur
|
|
- Prompt du code
|
|
- Remontage des supports « colis » sur la palette
|
|
9. Fermeture auto aussi possible si palette n'attend plus de stock
|
|
10. AGV récupère la palette vers le quai
|
|
|
|
**Assignation poumon** : [CUSTOM] à l'import du SOR, vérification combo
|
|
shipping class code + transporteur → si OK, poumon associé automatiquement.
|
|
L'idée retenue est de **ne pas** utiliser d'image de quai classique (sinon
|
|
perte de 25 places) mais un **emplacement au sol par transporteur**
|
|
(ex: emplacement « Colissimo », « Chronopost »).
|
|
|
|
> ⚠️ Custom à prévoir pour que la fermeture fonctionne dans le cas d'un
|
|
> support non client possédant des supports clients.
|
|
|
|
### Consommation OF hors recertification
|
|
|
|
**Prérequis** :
|
|
|
|
- `AllowAssignStockExcess` à `true` dans la SOR.Line
|
|
- Modèle d'expédition avec une stratégie d'assignation de stock
|
|
- [CUSTOM] Stratégie d'assignation excluant les supports multi-lignes
|
|
(= mono-ref uniquement). Combiné avec AllowAssignStockExcess → shipping
|
|
sans picking.
|
|
- Stock assigné directement déposé sur l'image de quai
|
|
- Pas de passage par un poste de travail
|
|
|
|
Pour les SOR de classe Production, les ruptures de stock ne bloquent pas
|
|
l'expédition. Le client utilise `isCritical` / `isRequired` au niveau
|
|
SOR.Line si besoin.
|
|
|
|
### Gestion des litiges (sac endommagé)
|
|
|
|
1. La palette arrive au PK
|
|
2. Problème constaté par l'opérateur sur un stock à picker :
|
|
- Bouton « Problème » → « Modif quantité »
|
|
- S'il reste du stock dispo : assignation maintenue (workflow
|
|
`OnStockAdjust` recalcule uniquement si nécessaire)
|
|
- Si plus assez de stock → réassignation ailleurs
|
|
3. Autre problème — le support n'est pas ok (90% du stock a un problème) :
|
|
- **Verrou de support** interdisant le picking (bouton « mettre sous
|
|
révision » en standard, à configurer)
|
|
- Tâche créée pour que l'AGV dépose la palette sur un **emplacement
|
|
au sol buffer litige** (à valider avec le client)
|
|
4. Retour au flux classique
|
|
|
|
## Modes opératoires
|
|
|
|
Tous les process doivent être pensés en **3 modes** :
|
|
|
|
| Mode | Description |
|
|
|------|-------------|
|
|
| Full AGV | Fonctionnement nominal |
|
|
| Mixte | AGV + caristes (cas probable en montée en charge) |
|
|
| Full TRF (caristes) | Mode dégradé sans AGV |
|
|
|
|
Le module AGV standard permet la finalisation manuelle (simulation AGV).
|
|
4 TRF disponibles sur site. Réunion dédiée à planifier pour les modes
|
|
dégradés.
|
|
|
|
## Points d'attention
|
|
|
|
⚠️ L'ordonnancement des palettes sur le poumon respecte le n° STOP.
|
|
|
|
⚠️ Le custom de défragmentation est le développement clé : il attend que
|
|
toutes les palettes de picking soient terminées avant de lancer les relocs.
|
|
|
|
⚠️ La clôture est automatique pour les OS complets mais **manuelle** en
|
|
cas d'expédition partielle.
|
|
|
|
⚠️ Le message MOV est **annulé** (décision réunion client).
|
|
|
|
⚠️ Les 3 modes opératoires (Full AGV / Mixte / Full TRF) doivent être
|
|
documentés pour chaque process.
|
|
|
|
## Questions ouvertes
|
|
|
|
- [ ] Ordonnancement des palettes dans le canal du poumon d'expé du
|
|
magasin automatique — géré par le WMS ou naturellement via l'ordre
|
|
de stockage ? (@Nicolas)
|
|
- [ ] Fermeture auto OS si chargement complet — standard ou custom ?
|
|
(@Nicolas)
|
|
- [ ] Comportement du reliquat chargement camion avec fichier RUT —
|
|
à paramétrer et tester (@Fabien)
|
|
- [ ] Positions des 2 étiquettes articulées sur la palette (@Théo)
|
|
- [ ] Custom Galileo : communication HS imprimante → mise en défaut ET
|
|
— à documenter dans le TMS (@Théo)
|
|
- [ ] Combien de commandes messagerie en parallèle sur un poste ? (@Justine)
|
|
- [ ] Emplacement au sol buffer litige — localisation exacte (@Théo)
|
|
- [ ] Emplacement au sol messagerie carton par transporteur (@Théo)
|
|
- [ ] Réunion technique avec Still pour valider le problème de dépose
|
|
AGV sur image de quai (@Théo)
|
|
|
|
## Historique des modifications
|
|
|
|
| Date | Auteur | Modification |
|
|
|------|--------|--------------|
|
|
| 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
|
|
| 2026-05-05 | Arthur | Réécriture complète depuis ateliers DEV expédition |
|
|
| 2026-05-13 | Arthur | Correction seuil picking négatif 50% → 55% + poids ≥ 7 kg, suppression règle traitement commercial | |