IMPORT/EXPORT

Réunion du 18.12.2000

COMPTE RENDU

Le but principal de cette réunion était, d'une part, de faire le point des problèmes liés au traitement des demandes saisies dans EDH et, d'autre part, de définir une stratégie pour encourager les utilisateurs à ne plus saisir de demandes manuellement (sous forme papier).

Pour accédier à la présentation , cliquer ici : présentation edh_impexp.

Vous trouverez ci-après les différents points exposés et le bilan de la discussion.

Le choix inapproprié du site (de départ ou d'arrivée) étant une cause importante de problèmes pour le service import/export, il a été décidé, pour limiter au maximum les erreurs, d'intégrer dans le formulaire de saisie EDH la règle suivante :
-Si le pays (de départ ou destination) est la suisse, le site sera Meyrin
-Si le pays est la France, le site sera Prévessin
-Si le pays fait partie de la communauté européenne , le site sera Prévessin
-Pour les autres cas, le site sera 'Meyrin'

Si l'utilisateur veut forcer un site ne satisfaisant pas à cette règle, un Warning s'affichera sur l'écran.

2-Lignes de texte:

2.1 - Situation : Les textes liés aux demandes sont saisis dans EDH par blocs de 2000 caractères. Dans Siriac, ils doivent être intégrés sous forme de lignes de 60 caractères (textes généraux) ou de 38 caractères (textes liés à l'article), pour répondre aux contraintes de la base de données (taille des champs) et aux contraintes d'édition des formulaires import/export. Cette situation occasionne des coupures 'sauvages' au milieu d'un mot, les carriage return ne sont pas transférés (donc le formattage disparait) et le résultat sur les documents générés dans l'application n'est pas aisément exploitable ni 'esthétique' dans le cadre de documents officiels de l'organisation.

2.2 Solutions envisagées : Il n'existe pas dans EDH de solution miracle : pas de délimitation possible de la largeur maximale de la ligne (police de caractère liée au navigateur). En outre, ces contraintes de découpage très spécifiques à l'application ne peuvent être prises en compte dans EDH qui est un système générique pour toutes sortes de documents.
La solution doit donc être trouvée dans le cadre d'une redéfinition de l'interface EDH/SIRIAC. Toutefois, étant donné la complexité et le temps nécessaire à une telle étude, certaines améliorations peuvent être apportées dans un premier temps :
-indiquer à coté de l'intitulé du champ le nombre maximum de caractères autorisés avant coupure
-transférer les 'carriage return' pour respecter le formatage du demandeur
-lors du découpage des blocs en lignes, essayer de couper sur un blanc au lieu de couper sur un mot
-transfert du texte lié au feedback interne EDH dans un code spécifique (TE)
-transfert des instructions de transport dans un code spécifique (TI) et en suppirmante l'intitulé 'Instructions de transport :', ce qui autorisera des lignes de 60 caractères

2.3 Problèmes résiduels :
- James va vérifier le problème des lignes vides transférées dans Siriac pour les instructions d'enlèvement (code texte IE)

3- Adresses EDH-99 :

-Pour éviter la multiplication des adresses occasionnelles, Reinoud propose d'installer dans EDH une fonctionnalité permettant de vérifier à partir des données saisies par le demandeur (nom du destinataire/expéditeur, ville, pays) si une ou plusieurs adresses n'existent pas déjà dans la base et les proposer à l'utilisateur. Ceci permettrait de limiter fortement les nouvelles occurrences.
S'il n'y a pas d'améliorations sensibles, James propose de carrément empêcher la création de nouvelles adresses. En cas d'absolue nécessité, l'utilisateur devrait contacter le service import/export qui ferait le nécessaire.

-Le bug relatif au nom du destinataire qui apparaissait tronqué est maintenant réglé. Aucun nouveau cas n'a été signalé

4- Feedback EDH :

L'alimentation du feed-back EDH fait partie des points à aborder lors des prochaines séances de travail sur la migration de Siriac sur la version Web. Toutefois, pour l'import/export, la seule lacune dans ce feed-back est d'avertir l'utilisateur quand une demande est supprimée. Dans la transaction permettant de supprimer un mouvement (MSUP), nous allons rajouter le code permettant de renseigner la table correspondante (SIRED) après chaque suppression de mouvement. Pour une suppression manuelle sans passer par la transaction MSUP (escape + d dans GXEBS), il faudra rajouter un database trigger pour renseigner Sired.

5- Unité de prix - Montant total :

Le bug qui avait été signalé dans EDH (valorisation erronnée des lignes lors du transfert) a été corrigé et il n'existe plus maintenant d'exemples d'erreurs similaires.

6. Colisage :

Les informations relatives au colisage étant indispensables dans le cas des demandes de transport, il a été convenu de rendre la zône correspondante obligatoire dans le formulaire EDH, et ceci uniquement pour cette catégorie de demandes.

7- Demande de transport :

Pour faciliter la traçabilité de ces demandes et leur traitement dans l'application import/export, il a été décidé :
-de créer une nouvelle classe de commandes et de mouvements : TR , numérotation manuelle -> référence du mouvement et référence de la commande logistique associée seront identiques à la référence EDH
-classe unique quel que soit le site : donc possibilité de changer ce site manuellement (en veillant à convertir les montants suivant la devise)
-ces demandes de transport ne feront plus interférence avec les arrivages internationaux

Une synchronisation est nécessaire entre EDH et CIS pour l'implémentation de cette nouvelle fonctionnalité

8- Demandes papier :

En raison de la masse encore importante de demandes saisies manuellement, une stratégie plus directive s'impose si on veut arriver à des résultats concrets. Les statistiques présentées ont mis en relief les principaux utilisateurs récalcitrants et les divisions concernées.
Une réunion sera organisée courant janvier entre les différentrs protagonistes : EDH team, import.export,AS-CIS et utilisateurs ciblés. Au cours de la discussion, ces derniers devront fournir les arguments justifiant leur utilisation actuelle du formulaire papier au lieu des moyens électroniques mis à leur disposition. Nous serons là pour contrer ces arguments et leur proposer une approche plus constructive qui pourrait s'achever par un atelier EDH et une proposition de formation.

De son coté, le service import va sensibiliser les utilisateurs concernés à partir du mois de janvier en les avertissant que les demandes papier ne seront plus acceptées qu'à titre exceptionnel et que leur traitement donnera lieu à une facturation du coût administratif de ressaisie.

9-Autre point abordés:

2.1 : Montant total - Montant total/lignes:

Le problème de la différence entre le montant total (niveau global) et le montant global niveau des lignes est lié à l'unité de prix. Si l'unité de prix = 1, ces deux montants seront identiques. Dans le cas contraire, le prix unitaire est recalculé lors de la valorisation de la commande et le résultat de ce calcul donne une différence liée aux problèmes d'arrondis.
Pour solutionner le problème, il faut modifier la ligne concernée : changer l'unité de prix en 1 et recalculer le prix unitaire.
Ce problème est interne à l'application et ne concerne pas EDH.

2.2 : Mode de transport :

Le service import export souhaite que les demandeurs puissent entrer le mode de transport souhaité pour une demande. Ce champ doit être facultatif et son contenu n'aura qu'une valeur informative, le service import/export se réservant la possibilité de modifier le mode de transport si nécessaire.
Action à entreprendre par James pour donner aux utilisateurs accès à ce champ.

2.3: Dimensions :

Il semble que l'ordre standard : longeur, largeur, hauteur ne soit pas respecté par les demandeurs dans EDH. Ce problème sera vérifié sur la base des exemples transmis par Alistair.

2.4 - Modiication du site :

La transaction MDEP qui change le site pour une expédition ne convertit pas la valeur d'assurance. Le programme est donc à vérifier pour que ce bug soit corrigé.

2.5: Expéditions sans référence à la commande d'achat:

Le service import/export déplore que de plus en plus d'expéditions ne font plus référence à la commande d'achat correspondante (réparations, matière première pour usinage, etc..). Ceci occasionne des problèmes pour l'identification du matériel par le fournisseur et, lors du retour, la réception des marchandises ne peut pas retrouver la commande concernée.

Ce champ n'est plus obligatoire dans EDH mais les utilisateurs doivent être sensibilisés à l'impact occasionné pour les différents services concernés. Si ce champ est connu, il doit obligatoirement être renseigné.

2.6: Problèmes répétitifs :

Un certain nombre de problèmes récurrents sont constatés dans la saisie des demandes électroniques. Ces problèmes sont dus à une mauvaise utilisation du logiciel (mauvaise compréhension des différentes zones et de leur impact, etc....) , nécessitent une correction des données saisies et sont un facteur de perte de temps important.
Pour les solutionner, il est demandé au service import/export de répertorier la nature des différents problèmes et d'identifier les utilisateurs concernés. Une réunion sera ensuite organisée avec ces personnes pour rafraichir leur connaissance du logiciel de manière à améliorer la qualité des données saisies. Seront présents les différents acteurs : EDH team, import/export, AS-CIS et utilisateurs.

2.7: Description article:

Lorsque le demandeur utilsie un code activité, la description générique est proposée par défaut. Mais cette description n'est pas utilisable pour les documents douaniers et d'accompagnement qui requièrent la description commerciale de la marchandise, c'est à dire une description plus précise et spécifique. Il faut attirer l'attention des utilisateurs de manière à ce qu'ils respectent cette exigence.