Gestion Electronique et Sécurisation du Fret International Multimodal ENVIRONNEMENT & IMPLEMENTATION DES FORMULAIRES PME CHARGEURS/ TRANSPORTEURS Date du fichier 10/03/2008 Nom du fichier implémentation formulaires PME chargeurs transporteurs Version du Fichier 1 Nom du responsable JP GRASSIEN Liste de distribution : Nom Prénom Nom Prénom Anne SANDRETTO Dominique VANKEMMEL Olivier VERHAEGHE Partenaire Partenaire TLF ADMISSION CRCI Historique des versions : Nom Responsable Partenaire N Version Date JP GRASSIEN C.R.C.I MS3.1 10/03/2008 GESFIM
SOMMAIRE 1. Objectifs... 4 2. Les messages EDIMOBILE associés à des formulaires électroniques... 6 2.1 Les messages à échanger... 6 2.2 L Ordre de transport (IFCSUM)... 6 2.3 L Ordre de mission (IFTMIN)... 6 2.4 Le compte Rendu de Mission (ITFMAN)... 7 2.5 Le Compte Rendu d Exécution d Ordre de Transport (IFCSUM)... 8 2.6 Le signalement d un incident en cours de mission (IFTSTA)... 8 3. Les formulaires de gestion du transport... 9 3.1 Des formulaires différents pour des messages similaires... 9 3.2 Les formulaires du donneur d ordres... 9 3.3 Les formulaires du transporteur... 9 3.4 Le formulaire de l expéditeur... 10 3.5 Le formulaire du destinataire... 10 4. Concepts de la solution... 14 4.1 Un formulaire indépendant de tous services Web... 14 4.2 Concepts Techniques... 14 4.3 Complémentarité des outil développés par GESFIM B... 15 4.3.1 Le moteur d interface léger... 15 4.3.2 Le gestionnaire de rendez vous : l Agenda... 15 5. Fonctions communes aux formulaires... 16 6. Utilisation des formulaires... 17 6.1 Un environnement dédié... 17 6.2 Une ergonomie classique... 18 6.2.1 Messages en attente... 18 6.2.2 Affichage d un message en réception... 19 6.2.3 Validation de la saisie et enregistrement... 19 6.2.4 Envoi du message... 19 7. La génération des formulaires... 21 7.1 Schéma XML de référence... 22 Page 2/2
7.2 Propriétés des champs... 22 7.2.1 Les propriétés graphiques... 22 7.2.2 Les propriétés sémantiques... 22 7.3 Tables de codes, valeurs de références, valeurs déduites... 22 7.4 Règles de calcul associées à des champs facteurs ou résultats... 23 7.5 Fond d écran et le fonds d impression... 23 8. Le paramétrage de l environnement utilisateur... 24 8.1.1 Environnement d exécution... 24 8.1.2 Sécurisation des données... 24 8.1.3 Moteur d envoi/réception... 25 9. Modalités de réalisation... 26 9.1 Respect des concepts... 26 9.2 Jeux de tests... 26 9.3 Essais en charge... 27 9.4 Les annexes... 27 Page 3/3
1. Objectifs Les objectifs de ce document sont : Premièrement de définir les formulaires électroniques légers qui seront proposés aux donneurs d ordres, aux transporteurs, expéditeurs et destinataires leur permettant de générer et de recevoir des messages normalisés couramment utilisés dans leurs relations opérationnelles et utilisables dans un environnement open/source, ou une base Microsoft Ces formulaires permettent d afficher ou de générer les messages normalisés : d ordre de transport, d ordre de mission, de statut de la demande et de prise de rendez vous, comptes rendus d exécution de mission et d ordre de transport, le signalement d incident en cours d exécution de la mission. Ils peuvent être associés aux autres logiciels libres développés dans le projet GESFIM B : le moteur de tâches et de traduction de messages transport, le gestionnaire de prise de rendez vous. Ils peuvent être utilisés indépendamment de ces autres logiciels pour recevoir et échanger des messages normalisés en direct entre plusieurs partenaires. Page 4/4
Deuxièmement de décrire le concept et les fonctionnalités d un environnement d exécution de ces formulaires qui soit utilisable après mise en place d une application libre. Troisièmement de décrire les fonctions d un générateur de formulaires s appuyant sur des schémas de messages XML correspondant aux messages normalisés utilisés. Page 5/5
2. Les messages EDIMOBILE associés à des formulaires électroniques 2.1 Les messages à échanger La norme EDIMOBILE a défini un ensemble de six messages parmi lesquels quatre sont utilisables pour résoudre le problème de l optimisation des missions et leur constatation formelle. Ce sont : L ordre de Transport (contenu détaillé par lots ou positions), avec des informations intéressant aussi le destinataire. Il est l'équivalent du contrat de transport. L ordre de Mission, développant le détail des tâches d exploitation qui composent la mission à réaliser et permettant notamment de confirmer les rendez vous expéditeur et destinataire, Le compte rendu de mission. Le compte rendu d exécution d ordre de transport. Le signalement d un incident en cours d exécution de la mission. Ces messages ont des significations différentes selon que l on est expéditeur ou destinataire de la marchandise, un ordre de mission sera équivalent à un préavis d enlèvement ou à un préavis d expédition, et sera confirmé pour fixer une heure de rendez vous. 2.2 L Ordre de transport (IFCSUM) L ordre de transport est une commande de transport, spécifiquement référencée, comprenant les éléments nécessaires et suffisant à l exécution de l acte commercial qu est un contrat de transport. Il est découpé techniquement en lots ou N de positions susceptibles de le composer. Cet Ordre de transport multiple qui permet d établir un contrat de transport pour plusieurs expéditions est le message IFCSUM. A l origine et hors du champ de l application, il est transmis par l expéditeur au commissionnaire de transport qui demande ou réserve des prestations de transport ou d'organisation de transport pour plusieurs expéditions sous certaines conditions, puis au transporteur qui assure ou organise le transport. Il permet à ce dernier d avoir les informations lui permettant d établir une ou plusieurs missions concernant les expéditions pour lesquelles la prestation est demandée. Il remontera au donneur d ordre après exécution avec des observations.. 2.3 L Ordre de mission (IFTMIN) L Ordre de mission est une série d instructions pour une des expéditions rattachées à un ordre de transport, envoyées à un conducteur et justifiées par l ensemble des caractéristiques d une mission susceptible d être remplie par le couple conducteur - véhicule moteur constitué à un instant T, jusqu à ce qu il soit dissocié. Page 6/6
Plusieurs missions peuvent être confiées pendant la durée du «couplage» conducteur véhicule moteur, donc, a fortiori, plusieurs tâches successives comme le brouettage de conteneurs ou des norias de véhicules. Pour simplifier le concept des missions telles qu elles sont définies dans la norme EDIMOBILE, nous ne retiendrons comme mission, que l avis d enlèvement de la marchandise chez l expéditeur, correspondant à un rendez-vous et à l avis de livraison chez le destinataire. Chacune de ces missions peut faire l objet d une demande de rendez-vous, ou être organisée globalement dès la réception de l ordre de transport. Le message EDIFACT retenu pour décrire les ordres de missions est le IFTMIN. IFTMIN est un message utilisé en suite de l ordre de transport (IFCSUM) pour régler les instructions concernant les services d acheminement ou de transport relative à une expédition dans des conditions convenues, avec le transporteur qui organise les services d'acheminement et/ou de transport. A l origine l ordre de transport est émis par le donneur d'ordre vers le vendeur de transport sous la forme IFTMIN pour ordonner le transport de colis, afin qu'ils soient enlevés et livrés à un ou plusieurs points de livraison. Les unités d'expédition peuvent être identifiés par un numéro unique. Parmi les données principales contenues dans le message : - Les dates de livraison / enlèvement / expédition.-). - Le poids total, le nombre total de colis et le volume total. - Les conditions de livraison. - L'expéditeur et le lieu de livraison. - Les documents devant accompagner la livraison. - Le type et le nombre d'unités d'expédition.- Les conditions de manutention (par exemple, l'indication que les marchandises transportées sont des denrées alimentaires). - La température de transport.- L'identification des articles (codes) contenus dans les unités d'expédition.- Les dimensions des unités d'expédition. - Les informations sur les marquages des unités. - L'identification des équipements (containers, palettes, etc.) utilisés pour transporter les unités. - Les informations sur les marchandises dangereuses. - La description des équipements (container, palettes, etc.) utilisés pour transporter les marchandises. 2.4 Le compte Rendu de Mission (ITFMAN) Le compte rendu de mission est le résultat de l exécution d une mission constaté par le chauffeur qui a réalisé la mission. Il est facultatif et ne dépend que de l instruction initiale d exiger un Page 7/7
compte rendu par le transporteur, qui a été indiqué dans le message d ordre de transport IFCSUM. Ce compte rendu peut être élaboré ensuite d un message SMS très synthétique de la part du chauffeur, en faisant référence à l ordre de mission. Il appartient au transporteur de décider la communication de ce compte rendu au donneur d ordres, ou à l expéditeur ou au destinataire. Le message retenu pour le compte rendu est le IFTMAN est émis par le transporteur par l intermédiaire du chauffer qui assure les prestations d'acheminement et/ou de transport à l'intervenant spécifié dans le contrat (par exemple l'expéditeur) et qui donne des informations détaillées sur l'arrivée d'une expédition. Le message peut aussi être utilisé pour donner une information de preuve de livraison. 2.5 Le Compte Rendu d Exécution d Ordre de Transport (IFCSUM) Le compte rendu de d exécution de l ordre de transport est généré par le transporteur lorsque tous les comptes rendus de missions ont été enregistrés ou lorsque qu il le décide à défaut de les traiter. Il est renvoyé au donneur d ordres ou à l expéditeur et au destinataire selon les spécifications de l ordre de transport. Le message IFCSUM utilisé pour établir l ordre de transport est utilisé pour retourner l information permettant de prouver que les toutes les missions ont été accomplies. 2.6 Le signalement d un incident en cours de mission (IFTSTA) Le signalement d un incident est renvoyé en cours de transport lorsque, par exemple, l enlèvement de la marchandise ne peut avoir lieu du fait de l indisponibilité de la marchandise, où d un incident de parcours qui bouleverse la prévision de livraison. Il est renvoyé au transporteur par le chauffeur afin que celui-ci convienne des nouvelles missions à réaliser après avoir réalisé les échanges nécessaires à leur confirmation par l expéditeur et le destinataire selon les spécifications de l ordre de transport. Le message IFTSTA parait adapté car il permet «d'échanger des informations concernant le statut des mouvements physiques des expéditions ou des marchandises à tout point de la chaîne de transport (Quel que soit le lieu et l'heure). Le message peut être envoyé suite à une ou des demandes d'informations concernant la ou les expéditions, sur une base prédéfinie (à une heure précise), suite à un ou des événements prédéterminés, suite à un événement exceptionnel comme défini par les partenaires». Page 8/8
3. Les formulaires de gestion du transport 3.1 Des formulaires différents pour des messages similaires Les formulaires de gestion du transport sont différents selon que l on se trouve être : Le donneur d ordre du transport qui rédige un ordre de transport complet pouvant être décomposé en plusieurs missions par le transporteur. Le transporteur qui organise les missions, contrôle leur exécution et rend compte de l exécution de l ordre de transport, Le chauffeur routier dont on allègera au maximum le message pour être traduit sous forme de SMS sur un téléphone portable, L expéditeur de la marchandise, après avoir reçu le préavis d enlèvement d un ordre de transport, doit confirmer la date et heure de rendez-vous d enlèvement de la marchandise. Le destinataire de la marchandise après avoir reçu le préavis de livraison d un ordre de transport, doit confirmer la date et heure de rendez-vous de réception de la marchandise. Chaque formulaire est dédié à un des acteurs et génère un message EDI identique ou différent des autres formulaires. 3.2 Les formulaires du donneur d ordres Les formulaires du donneur d ordres sont : - le formulaire d ordre de transport sur lequel il va décrire l ensemble des informations permettant au transporteur d organiser les missions, pour générer un message IFCSUM - le formulaire de compte rendu d ordre de transport qui va afficher les données du message IFCSUM pour rendre compte notamment des horaires de réalisation des missions et des observations relevées. 3.3 Les formulaires du transporteur On considère que le transporteur dispose d un P.C ou équivalent pouvant recevoir des mails et des messages EDI et les traiter, ce sont les outils de traduction et d automatisation de tâches et une solution de traitement de listes fournie par le projet. Les formulaires du transporteur sont : - le formulaire d ordre de transport sur lequel il va recevoir l ensemble des informations lui permettant de décomposer et d enregistrer les missions, Page 9/9
- le formulaire d ordre de mission pour générer des messages IFTMIN qui seront envoyés à l expéditeur et au destinataire pour confirmation de rendez vous. Le même formulaire permet de constater la réalisation de la mission et également le signalement d un incident en cours de mission. - Le formulaire de préavis d enlèvement/réception qui permet d afficher les messages d avis d expédition confirmés ou infirmés par l expéditeur, ou par le destinataire. 3.4 Le formulaire de l expéditeur Le formulaire de l expéditeur est un préavis d enlèvement de marchandises qui correspond à une mission déterminée par le transporteur, correspondant au message IFTMIN, sur lequel il doit confirmer ou modifier la date et l heure de l enlèvement des marchandises et éventuellement apporter des précisions. 3.5 Le formulaire du destinataire Le formulaire du destinataire est un préavis de livraison de la marchandise qui correspond à une mission déterminée par le transporteur, correspondant au message IFTMIN, sur lequel il doit confirmer ou modifier la date et l heure de l enlèvement des marchandises et éventuellement apporter des précisions. Page 10/10
Page 11/11
Page 12/12
Page 13/13
4. Concepts de la solution 4.1 Un formulaire indépendant de tous services Web Dans un environnement de systèmes d informations multiples et totalement hétérogènes, les acteurs du transport sont souvent assujettis aux services Web de leur donneur d ordre principal ou à ceux de l acteur dominant de la chaîne de transport (Expéditeur ou Destinataire) les obligeant à s adapter à de multiples ergonomies, procédures et suivis de formes diverses sans pouvoir toujours récupérer les données utiles à leur gestion propre. Parmi les outils développés par le projet GESFIM B, dont le but est de pouvoir s adapter facilement à une multiplicité de partenaires et en priorité à ceux qui utiliseront la norme EDIMOBILE, les formulaires électroniques indépendants permettent d afficher et de rédiger les messages courants. Dédié à de petites architecture de système de traitement, le but est le développement d un outil extrêmement léger, téléchargeable, facile à installer et utilisable sans formation. Ces formulaires électroniques, fondés sur la technologie XML, doivent pouvoir assumer : - la transformation des données saisies en messages normalisés selon les schémas standards incluant notamment l usage des codes, - l exécution des tâches de contrôles et de calcul - l enregistrement des données selon des formats flat-file, - l impression des formulaires à l identique. L usage d une messagerie internet doit permettre de recevoir et d envoyer des messages de EDI normalisés. Cependant que la complémentarité avec les autres outils développés par GESFIM B (moteur d envoi/réception et moteurs de tâches et de traduction, base de données de prise de rendez vous) est parfaitement réalisée. 4.2 Concepts Techniques Les formulaires électroniques doivent pouvoir être téléchargé comme une application exécutable dans un environnement quelconque du monde Microsoft Windows 98, 2000, NT4, XP, Vista, ou dans un environnement Java MV, avec une procédure d installation minimale. Page 14/14
Les formulaires sont conçus sur la base des guides d implémentation fournis par la norme EDIMOBILE et des schémas XML correspondants (IFCSUM, IFTMIN, IFTMAN, IFTSTA). Ils contiennent les fonctions de vérification syntaxique et de cohérence des données. Ainsi que des fonctions de calculs (comparaison de dates, totalisation de lignes, de poids, etc ) Ils intègrent les codes standards (ex LOCODE) et les formats standards. Ils permettent l accumulation des données propres au client après la première saisie (adresses, code internes). Ils comportent une fonction de validation et d envoi. Ils autorisent l enregistrement des données en fichier plat et l impression au modèle. 4.3 Complémentarité des outil développés par GESFIM B Les formulaires électroniques sont suffisants à l échange des messages du transport routier entree les partenaires. Cependant ils sont compatibles et complémentaires des autres outils développés par GESFIM B qui sont : 4.3.1 Le moteur d interface léger Le moteur d interface léger peut recevoir des messages EDI normalisés et les transformer dans des formats propriétaires et les insérer dans des bases de données existantes. Il possède d autres fonctions qui peuvent rendre compatibles des applications anciennes ou distinctes. Il peut donc être destinataire des messages EDI entrants ou produits par des formulaires électroniques installés chez les partenaires et sur le site même de l entreprise. 4.3.2 Le gestionnaire de rendez vous : l Agenda Le gestionnaire de rendez vous est un logiciel libre ou un service Web externe d agenda qui permet à chaque entreprise : - d enregistrer les ordres de transport, les ordres de mission ou les avis d expédition ou avis de réception, - d organiser les missions en fonction des contraintes propres de chaque acteur, - d enregistrer les comptes rendus d exécution des missions et d apurer les ordres de transports. - d associer la copie numérique des documents de transport aux propriétés des ordres de transport, de mission et aux comptes rendus d exécution. Le gestionnaire de rendez-vous peut donc, via le moteur d interface léger, constituer le système de gestion des données affichables ou générées par les formulaires. Page 15/15
5. Fonctions communes aux formulaires Les fonctions commune des formulaires électroniques permettent : - une saisie intelligente des champs de données assistée par des tables de codes, des tables alternées codes et libellés, des valeurs déduites de deux dimensions et des contrôles syntaxiques (numérique, intervalles de valeurs, valeurs acceptées, ) - des contrôles de cohérences entre valeurs de champs en nombre limités, - des calculs intégrés sur des valeurs de champs facteurs, - une fenêtre d aide sur les champs, - un fond d écran guide acquis par scannérisation, - L impression avec grille d impression associée, - L enregistrement d un fichier plat csv contenant tous les champs en séquence même vides, - L affichage de message d erreur sur les champs et après validation pour contrôle et calcul, - La génération du message EDI XML selon un schéma associé. Page 16/16
6. Utilisation des formulaires L utilisation des formulaires doit être la plus conforme à celle des applications courantes, mais afin de simplifier l utilisation au maximum des fonctions habituellement gérées par la messagerie et l environnement utilisateur seront intégrées. 6.1 Un environnement dédié L application de gestion des formulaires démarre avec un raccourci sur le bureau, sans qu il soit nécessaire d ouvrir la messagerie du poste de travail. Il est possible de protéger l application par le filtrage d un mot de passe et d un profil associés. Page 17/17
Au démarrage l application va automatiquement sélectionner par l objet ou par le nom générique les messages contenu dans la boite email dédiée au poste de travail pour les ranger dans un répertoire dédié à l application. 6.2 Une ergonomie classique L environnement de l application présente les fonctions et éventuellement les sous fonctions suivantes : 6.2.1 Messages en attente Cette fonction affiche une liste des messages transports reçus avec les propriétés suivantes : expéditeur, objet, type de message, N du message, Page 18/18
Date d envoi/réception. Texte associé. Un simple clic sur le message ouvre le formulaire correspondant. 6.2.2 Affichage d un message en réception Un message en réception comporte un type de message dans le segment UNT qui est interprété pour appeler le formulaire correspondant, par exemple IFCSUM appelle le formulaire d ordre de transport. La pièce jointe éventuellement au message peut être enregistrée séparément selon la méthode classique du clic droit donnant le choix du répertoire d enregistrement. 6.2.3 Validation de la saisie et enregistrement La validation de la saisie et l enregistrement se font par un bouton «O.K» placé sur le cadre d affichage du formulaire. L invalidation est commandée par un bouton «annuler». Ces commandes permettent d exécuter l enregistrement du message dans un répertoire prédéfini à l envoi ou à la réception. 6.2.4 Envoi du message L envoi du message est commandé par une fonction qui affiche la liste des destinataires à sélectionner et la Page 19/19
confirmation de l envoi. A ce stade une pièce jointe peut-être attachée à l envoi qui sera associée à la pièce constituant le message lui même. La fonction d envoi de message comporte : un module de cryptage/décryptage optionnel, un module de compression/décompression de données, un module de transfert et de commande de la messagerie selon le type de messagerie ou selon le protocole adopté. Page 20/20
7. La génération des formulaires. La génération des formulaires est une procédure assistée d un éditeur spécifique permettant : - de constituer le schéma XML de référence du message EDI généré par le formulaire, - de définir les propriétés d affichage, d enchaînement et de contrôle syntaxique des champs, - de définir les tables de codes associés, les valeurs de référence des champs, les valeurs déduites d un ou plusieurs champs, - de définir les règles de calcul associées à des champs facteurs ou résultats, - d intégrer le fond d écran et le fonds d impression. Processus de génération de formulaire et des règles de calculs associées Page 21/21
7.1 Schéma XML de référence Les guides d implémentation des messages IFCSUM, IFTMIN, IFTMAN et IFTSTA sont les souches des schémas XML qui vont contenir les propriétés des champs nécessaires à l affichage, au contrôle des données saisies et à l impression des fonds de documents. 7.2 Propriétés des champs 7.2.1 Les propriétés graphiques Les propriétés graphiques permettent de : - positionner les champs à l écran et à l impression, - définir le graphisme du cadre de saisie, - utiliser les polices de caractères, - protéger la saisie intempestive, - désigner les champs précédent et suivant. 7.2.2 Les propriétés sémantiques - Les propriétés sémantiques des champs sont : - Le type (caractère ou numérique), - La longueur du champ, le nombre de décimale, le mode d arrondi, - Les valeurs limites, les valeurs admises, - La table de code associée, - La règle de cohérence associée, - La règle de calcul associée. Ces propriétés sont les paramètres des fonctions mises en œuvre au chargement, au traitement ou à l impression des formulaires.. 7.3 Tables de codes, valeurs de références, valeurs déduites Les tables de codes sont définies séparément et sont chargées avec des commandes spécifiques à partir de fichier de format csv pour être recomposées sous une forme XML. Page 22/22
Les valeurs de référence sont indiquées dans le schéma du message initial et reconduites en propriétés du formulaire. Elles sont comparées aux valeurs saisies, soit pour contrôle et rejet éventuel, soit pour être complétées (ex : recherche sur une partie de la chaîne de caractère). Les valeurs déduites résultent d une consultation de table avec la valeur d une champ pour affecter des valeurs associées à d autres champs visibles ou cachés. 7.4 Règles de calcul associées à des champs facteurs ou résultats Une règle de calcul peut être exécutée lors du passage sur un champ et utiliser les valeurs d autres champs. Il est possible d utiliser des tables non associées à des champs dans ces règles. Les erreurs d exécution doivent générer des messages mais le formulaire et les données saisies doivent être conservées. 7.5 Fond d écran et le fond d impression Le fond d écran est une image scannée à une résolution suffisamment légère pour permettre l agrandissement à 150% tout en maintenant la position relative des champs. Le fonds d impression est d une résolution suffisante pour assurer une lisibilité correcte des mentions équivalentes à une police de taille 8 en times new roman. Page 23/23
8. Le paramétrage de l environnement utilisateur L installation de l environnement d affichage et de traitement des messages doit pouvoir être paramétrée selon la volonté de l utilisateur. Il peut s agir de paramètres par défauts ou de paramètres précisés lors de l installation. 8.1.1 Environnement d exécution L environnement d exécution est celui du poste de travail de l utilisateur disposant d une messagerie dédiée. Le répertoire d archivage des messages et les modules d exécution seront enregistrés par défaut sous la racine. Il sera cependant possible à l utilisateur de modifier ces implantations par rapport aux possibilités d utilisation des ressources du réseau mis à la disposition de l utilisateur (serveur distant, disques local ou partage de ressources). 8.1.2 Sécurisation des données Un module de sécurisation des données peut être fourni lors du paramétrage de l environnement utilisateur. Il comporte les fonctions suivantes : sauvegarde cyclique vers un répertoire de destination interne ou externe, apurement automatique des messages anciens sur un critère chronologique ou de validation. Page 24/24
restauration de messages anciens, affichage d historique des messages reçus ou envoyés entre deux dates, par origine ou destinataire, par type de message. 8.1.3 Moteur d envoi/réception Le moteur d envoi réception assure la correspondance avec les fonctions de la messagerie électronique dédiée au poste de travail ou à l application. Il comporte les modules de cryptage, de compression et de contrôle des envois. La pièce jointe associée n est pas modifiée pour être envoyée, seul le message EDI est traité pour être sécurisé. Les détails du moteur d envoi/réception sont décrites dans le document LIV2 MS3 MI_CRCI B12.1 Définition d'un moteur d'interface PME chargeur-transporteur Page 25/25
9. Modalités de réalisation 9.1 Respect des concepts La réalisation de l environnement d exécution des formulaires électroniques nécessite de la part des réalisateurs de bien intégrer les concepts qui en font l originalité : indépendance des sites et des applications externes, compatibilité minimale avec l environnement du poste de travail, respect des normes et référentiels UN/EDIFACT. Ergonomie et facilité d utilisation sans formation préalable, Portabilité maximale, Paramétrage réduit au minimum spécifique à l entreprise. Interopérabilité avec les outils GESFIM B et avec les systèmes de gestion de données existants. Le générateur de formulaires, s adresse à des noninformaticiens, spécialistes de la norme UN/EDIFACT et des organisations du transport. 9.2 Jeux de tests Les messages de tests sont fournis au format EDI UN/EDIFACT natif et en XML, ils sont représentatifs des cas Page 26/26
les plus courants d organisation d opérations de transport et correspondent aux scénarios décrits. 9.3 Essais en charge Les essais auront lieu sur des matériels équipés de systèmes d exploitation différents (Windows 98, Windows 2000, XP, Vista) dotés d un système de messagerie fourni par le commanditaire. 9.4 Les annexes Sont fournis en annexe : les modèles de formulaires d ordre de transport, d ordre de mission, de compte-rendu d exécution de mission et d apurement de l ordre de transport. Les guides d implémentation correspondant incluant les tables de codes. Les diagrammes d échanges et de traitement sont décrits dans le document LIV2 MS3 SD_EDI CRCI B11.1 scénarios détaillés EDI routier Page 27/27