IMPORT/EXPORT

Réunion du 02.11.2000

COMPTE RENDU

C'était la première réunion organisée avec ce service depuis plusieurs années. Jusqu'à présent, l'application, mis à part quelques développements ponctuels était restée figée. Etant donné la migration de Siriac vers la version Web, il parait dorénavant souhaitable d'organiser des rencontres régulières, au moins mensuelles pour faire le point sur l'état d'avancement des développements demandés, évoquer les problèmes éventuels et préparer la migration.

Afin de permettre à chacun de prendre connaissance à tout moment de la situation, nous avons choisi de publier les comptes rendus, les détails sur les développements demandés et tous les points spécifiques concernant l'application import/export sur le site Web http://ais.cern.ch/apps/impexp/welcome.html. En accédant à cette adresse Web, vous pourrez donc prendre connaissance de toutes les informations concernant l'import/export.

Au cours de la réunion du 2 novembre, nous avons abordé les différents problèmes rencontrés par l'import export notamment lors du traitement des demandes d'expédition ou de transport créées dans EDH. D'autre part, certaines réglementations ayant évolué, et suite à des demandes émanant d'intervenants extérieurs, nous avons été amenés à envisager un certain nombre de modifications dans l'édition des documents. Nous avons tenté ci-après de structurer ces différents points en essayant d'être exhaustifs par rapport à la discussion.

De nombreuses erreurs sont constatées dans le choix du site d'arrivée de la marchandise. Cette information ne pouvant être changée dans l'application car ele détermine la classe du mouvement, il est actuellement nécessaire de supprimer l'enregistrement et de demander à l'utilisateur de créer une nouvelle demande avec le bon site.
Plusieurs solutions doivent être envisagées (à débattre) :
-améliorer le heLp EDH pour permettre à l'utilisateur de choisir le site de manière plus judicieuse
-paramétrer une classe de mouvement (et de commande logistique associée) spécifique pour les demandes de transport. L'avantage est d'isoler ces demandes des arrivages 'classiques', d'utiliser le même numéro pour le mouvement et la commande logistique, et ce numéro peut être identique à la demande EDH d'où une meilleur transparence pour l'utilisateur et un suivi facilité. En outre, la classe étant unique quel que soit le site et le site étant modifiable, l'utilisateur n'aura plus à annuler sa demande et à en recréer une nouvelle. Il suffira, en cas d'erreur, de modifier le site dans SIRIAC.

1.2 : Feedback EDH en cas d'annulation d'une demande :

Les utilisateurs se plaignent de ne pas être informés dans EDH lorsqu'un enregistrement est supprimé dans Siriac (voir par exemple Remedy no 29295).
Le mécanisme du feedback Siriac-> EDH doit être revu dans son ensemble : mécanisme d'alimentation, à quelle étape doit on informer EDH, etc..

1.3 : Informations relatives au colisage dans les demandes de transport :

Les utilisateurs omettent de renseigner le colisage lors de la création d'une demande de transport dans EDH. Le résultat est que, fautes d'informations suffisantes, leur demande ne peut ensuite être traitée par l'import/export. (Par ex. demande AM 26513.
Dans EDH, la zone colisage doit être rendue obligatoire en cas de demande de transport. Les champs : nombre de colis, nature des colis, poids brut et dimensions (longueur x largeur x hauteur) doivent être renseignés. Le help correspondant doit insister sur l'importance de remplir ces champs.

1.4 : Création intempestive d'adresses occasionnelles :

Lorsqu'ils créent une demande dans EDH, les utilisateurs ont tendance à saisir une adresse occasionnelle plutôt que de rechercher une adresse existante qui, dans la plupart des cas, est présente. Le résultat est d'alourdir la base en multipliant les 'doublons'.
Le help EDH devrait insister sur la nécessité de consulter la base des adresses avant de créer une nouvelle occurrence souvent superflue.

1.5 : Nom du destinataire tronqué dans certaines adresses occasionnelles :

Certaines adresses occasionnelles créées dans EDH, arrivent avec le nom du destinataire tronqué dans Siriac : voir par exemple l'adresse no 6125 pour le tiers EDH-99 (document EDH 810508) : le nom du destinataire est 'Prof. C. C' alors que le nom correct aurait du être 'Prof. C. Cosmelli'.
Voir également adresse no 6196 EDH-99 document 819697.
Vérifier le programme de transfert EDH : dans Siriac, le nom du destinataire peut avoir jusqu'à 60 caractères. D'où vient cette limitation?

1.6: Format des fenêtres texte:

Dans Siriac, le programme d'édition des documents import/export implique une limitation de la longueur des textes relatifs aux articles à 37 caractères, et à 60 caractères pour les textes généraux. Les fenêtre de texte présentes dans EDH ne comprenant pas les mêmes contraintes, des coupures 'sauvages' surviennent sur les textes rendant leur compréhension difficile et occasionnant la perte de certaines informations. (exemple : document EDH no 816306.
Serait-il possible d'ajuster les fenêtre de saisie des textes dans EDH pour qu'elles respectent les contraintes de Siriac?

1.7 : Texte relatif au feed-back EDH:

Le feed-back EDH est transféré dans SIRIAC avec le code texte 'T' et s'imprime en même temps que les autres textes destinés à la logistique ou à usage général. Cela rend pour les personnes de l'import/export la lecture des lignes de texte un peu laborieuse et a pour effet d'occulter certaines lignes de texte importantes notamment en ce qui concerne les instructions de transport. (voir exemple document EDH 816306 et output demande d'expédition Siriac; voir aussi Remedy no 28878)
Voir s'il est possible de transférer le texte relatif au feedback EDH avec un code texte spécifique de manière à l'isoler des autres textes et ne pas l'imprimer sur les documents import/export.

1.8 : Unité de prix - Montant total :

Il semble qu'il y ait encore des problèmes avec l'unité de prix, le prix unitaire et le calcul du prix total au niveau des lignes des demandes d'expédition ou de transport. (exemple document EDH no 824777)
Vérifier si le bug constaté a bien été solutionné et tester quelques cas spécifiques.

2-Demandes de modifications dans les éditions import/export:

2.1 : Ordre de transport:

-Editer le code postal du destinataire (information indispensable au transporteur)
-Editer le colisage détaillé, car il est nécessaire au transporteur pour organiser l'enlèvement
-Possibilité de disposer de deux lignes pour les instructions de transport (dans l'écran des intervenants, intervenant TR) et éditer ces informations
(Vérifier fonctionnalité actuelle : en principe, on édite le contenu diu champ infsxint jusqu'au point virgule)
-Editer une version papier de l'ordre de transport à conserver dans le dossier par la logistique en cas de litige avec le transporteur
Utilité à confirmer car cela va contribuer à la multiplication des documents générés
-Vérifier si la date de départ effective apparait sur le document

2.2 : Etude de transport :

-Editer le code postal du destinataire (information indispensable au transporteur)

2.3 : Envoi de l'avis d'expédition par E-Mail:

-Possibilité de générer un courrier électronique à la place d'un document papier pour l avis d'expédition
Problème actuellement avec SQR : le caractère arobas @ n'est pas reconnu par ce langage. Voir avec inférence solution alternative

2.4: Registre journalier des arrivages :

-Deux informations supplémentaires sont souhaitées : la référence du document de transit , le type du document (T1,T2, 11.51) et la référemce de l'EUR.1 le cas échéant
Layout du rapport à modifier : raccourcir la largeur de certaines colonnes pour permettre l'affichage de toutes les données requises sur une seule ligne.

2.5: Identification des arrivages relatifs à des retour d'expéditions temporaires :

-Pour éviter des recherches souvent laborieuses et permettre de faciliter l'identification d'arrivages concernant des retours d'expéditions temporaires, il est impératif que l'expéditeur mentionne sur les document d'accompagnement la référence initiale de l'expédition
Pour informer les entreprises concernées, il est nécessaire de prévoir l'édition d'un texte spécifique sur les documents relatifs aux expéditions temporaires : par exemple : la réf de cette expédition EP 999999 doit impérativement mentionnéee sur les documents relatifs au retour de la marchandise.

2.6: Edition de l'information relative à la personne (attention de) chez le destinataire:

-Actuellement, cette information n'est éditée que si elle est est saisie dans l'écran des intervenants. Mais elle peut aussi exister au niveau du tiers.
Le problème pourrait être réglé comme suit : on fait un sélect dans la table des intervenants (sxint) et si le select ne ramène rien, on va chercher l'information correspondante dans la table des adresses tiers (oetia).

3-Divers:

3.1 : Liste des utilisateurs demandes manuelles:

Dans le but d'encourager une utilisation plus massive de la demande d'expédition dans EDH, la logistique souhaite obtenir la liste des utilisateurs les plus fréquents continuant à produire des demandes papier. Cette liste permettrait de les identifier, afin de pouvoir ensuite les contacter et tenter de les convaincre d'utiliser des moyens plus modernes et moins pénalisants de remplir leurs demandes.

3.2 : Outils de consultation:

Il manque dans l'application import/export un outil de consultation permettant de retrouver un dossier à partir de critères variés.
Analyse à effectuer, éventuellement prévoir une vue.

3.3 : Outils statistiques:

En vue d'analyser par exemple la répartition des expéditions/arrivages par pays, ville de destination, mode de transport, un outil doit être développé permettant, à partir de données extraites de l'application, de trier les éléments recherchés selon un certain nombre de critères, de déterminer la répartition en pourcentage selon les mêmes critères, etc....
Analyse à effectuer, procéder à des tests d'extraction et traiter les données sélectionnées

3.4 : Vente du LEP:

Prévoir, parallèllement au mail envoyé aux personnes concernées, la mise en place d'un mécanisme (sonore?) pour avertir qu'un camion vient de terminer le chargement et que les dossier doit être intégré dans Siriac et les documents douaniers générés. Ceci permettrait d'éviter tout retard dans le traitement.

3.5 : Génération des commandes de transport:

Dans le cadre de la migration de Siriac sur la version Web, il convient de rediscuter avec les dífférents services concernés, notamment le bureau des factures de l'opportunité de générer des commandes pour toutes les expéditions impliquant une refacturation au CERN des frais de transport. Cette fonctionnalité existe mais n'a pour l'instant jamais été activée

3.6 : Demande d'exonération de TVA:

Il y a quelques années, l'informatisation de ce document avait été envisagée et un certain nombre de développements avaient déjà été effectués. Ce problème revient à l'ordre du jour.
Inventorier les développements déjà effectués, voir faisabilité d'une impression recto/verso (condition sine qua non de l'acceptation par la douane de la version informatisée de ce document).

.