***

Avant-propos

La logistique dans l'analyse détaillée des achats - historique :

Dans la phase initiale de l'analyse détaillée des Achats, le secteur import/export n'a pas été pris en compte. Lors du `User Committee' du 7 février 1991, nous nous sommes donc efforcés de démontrer que la logistique ne devait en aucun cas être considérée séparément car, avec les achats, elle supporte tous les aspects du cycle commercial global du CERN c'est à dire à partir du moment où un utilisateur soumet une demande d'achat, jusquà la distribution interne de la marchandise et ultérieurement, le cas échéant, jusqu'à la vente ou le transfert du matériel

La figure ci-dessous illustre le rôle de la logistique ( case `expédition et transport') dans ce cycle commercial.

Figure 1 : le cycle commercial du CERN

Après accord du comité des utilisateurs des Achats, il a donc été décidé d'élargir le `scope' du projet et d'y inclure le secteur import/export. Le rapport final daté du 22 mars 1991 contient donc l'analyse détaillée des achats et de la logistique.

Choix du logiciel :

Suite à cette phase d'analyse, il a été procédé au choix du logiciel qui, en définitive, s'est porté sur Siriac. Ce produit n'intégrait cependant pas la fonctionalité de la logistique et le calendrier très serré d'implémentation ne permettait pas d'effectuer les développements nécessaires à cette intégration.

En conséquence, Siriac a été mis en service pour les services achats, réception et factures et la logistique est ainsi restée déconnectée du cycle commercial. On ne sait donc toujours pas ce qui se passe entre le moment ou le fournisseur reçoit la commande du CERN et le moment où la marchandise est livrée à la réception, les informations correspondantes n'étant pas prises en compte dans le système actuel.

Situation présente :

La maintenance des applications informatiques de la logistique continue d'être assurée sur un système séparé. Si une telle situation devait perdurer, il serait indispensable de faire évoluer ces applications pour les rendre compatibles avec la structure de la base de données achats (par ex. format du numéro de commande, notion de classe, sous-numéro, etc..). Cette adaptation nécessaire , notamment dans le cadre de l'application publique EXPED (saisie à distance de la demande d'expédition), impliquerait une profonde remise à jour de la définition de la base de données et la réécriture de la presque totalité des formulaires de saisie, des programmes d'impression des documents logistiques et des programmes statistiques. Est-il raisonnable d'envisager un tel investissement en temps puisque, de toutes façons, l'intégration avec les achats est un objectif retenu dans le planning du projet?

Perspectives :

Scénarios envisageables :

Trois scénarios sont envisageables pour l'intégration de la logistique :

*Option 1 : Achat d'un logiciel spécifique offrant la fonctionnalité souhaitée, et pouvant facilement être interfacé avec Siriac.

*Option 2 : Transfert de l'applicatif actuel de VM/CMS sur UNIX , avec conversion du software et interfaçage avec Siriac.

*Option 3 : Intégration de la fonctionnalité de la logistique dans la structure actuelle de Siriac.

Analyse des solutions envisagées :

L'option 1 suppose de pouvoir trouver sur le marché un logiciel fonctionnant sous Unix/Oracle et couvrant la fonctionnalité actuelle de la logistique. Cette solution risquerait d'être la plus onéreuse car en plus du prix du logiciel proprement dit s'ajouterait le coût de mise en place de l'interface nécessaire avec Siriac .

L'option 2 nécessite la conversion complète du logiciel import/export existant. De plus, étant donné que la Silicon Graphics ne possède pas de compilateur Fortran, tous les programmes d'édition et de statistiques de type Fortsql devraient être réécrits (en C?). En outre, certaines données communes avec les achats (structure des adresses fournisseurs, articles etc..) améneraient à une redéfinition des tables (longueur des colonnes, nouvelles zones, etc.. ). L'impact pour la mise en place de l'interface serait également important. D'autre part, certaines modifications devraient être envisagées dans Siriac avec le risque de créer des transactions ou des traitements spécifiques CERN.

L'option 3 , que nous avons retenue dans le présent document, est basée sur l'intégration des fonctionnalités de la logistique dans la structure actuelle de Siriac Cette solution offrirait l'avantage d'un coût moins élevé (puisque nous utiliserions le progiciel actuel), son implémentation pourrait s'effectuer assez rapidement et les modifications nécessaires pourraient être introduites par Inference dans le package standard qui serait ainsi enrichi de cette fonctionnalité supplémentaire. Nos besoins dans le domaine logistique sont en effet identiques à n'importe quelle entreprise commerciale. De plus, nous n'aurions pas de problème d'interface avec le système existant, ce qui est loin d'être négligeable.

But de ce document :

Dans le présent document , nous allons essayer d'évaluer quel serait l'impact sur Siriac de l'intégration de la logistique en mettant l'accent sur les modifications nécessaires de la base de données et les développements à envisager.

1 - Présentation de l'import/export

1.1 - Les fonctions propres à l'Import/Export

Le service Import/Export est présent sur chaque site du CERN pour permettre l'application de la réglementation douanière propre à chaque pays hôte. Un certain nombre de spécificités existent donc dans chaque secteur pour régir ces particularités. Les fonctions de base sont toutefois identiques :

*Permettre la création, l'approbation et la transmission des demandes d'expédition import et export , en assurer la réception, le contrôle et le traitement

*Gérer et assurer le suivi d'un mouvement en produisant les documents d'importation, d'exportation et de transport nécessaires à la satisfaction d'une étape de ce mouvement et en établissant les documents contractuels nécessaires (par ex. ordre de transport, instructions d'acheminement, passavant permanent...)

*Assister les achats dans le choix des partenaires commerciaux (transporteurs, transitaires....) du mode de transport et des Incoterms les plus appropriés à une commande

*Evaluer et comparer les coûts de transport, déterminer le mode de transport le plus approprié et sélectionner un transporteur pour la prise en charge d'une étape de mouvement

*Permettre le contrôle des factures de transport en identifiant les commandes et/ou les mouvements concernés et en vérifiant que les conditions contractuelles ont bien été respectées par le transporteur.

1.2 - Environnement informatique

1.2.1 - Généralités :

L'environnement informatique des applications import/export est VM/CMS. Le système de gestion de bases de données est Oracle V.6. Les formulaires de saisie correspondent à la version 2,3 de SQL*Forms. L'utilisateur accède à son environnement au moyen de menus écrits en REXX. Tous les programmes d'édition et les programmes statistiques sont du type FORTSQL. Les formulaires spécifique (douane, transport) sont dessinés avec un logiciel Xerox et intégrés dans les programmes Fortsql.

1.2.2 - Les applications :

Elles se divisent en deux domaines distincts :

-L'application centrale contient les programmes de gestion destinés aux utilisateurs professionnels de la logistique

-Les applications périphériques sont destinées aux utilisateurs de base :

*EXPED = saisie à distance des demandes d'expédition et de transport, interrogation des données import/export

*COURRIER = génération automatique des demandes d'expédition pour le courrier CERN

*FACTUR = gestion des factures de transport

Figure 2 : l'environnement informatique des applications import/export

1.2.3 - Les bases de données :

La logistique utilise deux types de bases de données :

-les bases de données de type annuel assurent le stockage, année par

année, des informations relatives aux arrivages et expéditions

-la base de données dictionnaire contient :

*les données de référence de la logistique ( compagnies de

transport, unités commerciales, pays, monnaies, etc...)

*les données à caractère permanent (tarifs de transport,

certificats d'importation, études de transport)

*les tables permettant le stockage temporaire des données EXPED

avant leur transfert dans les tables de la base annuelle en cours

1.3 - Perspectives d'intégration

En fonction de la structure informatique définie ci-dessus, l'intégration de la logistique devrait s'orienter dans les axes suivants :

*SIRIAC pour l'application centrale

*EDH pour les applications périphériques EXPED et COURRIER

*FOUNDATIONS pour les données de référence (base de données

dictionnaire)

L'application FACTUR ne serait plus nécessaire avec l'intégration dans SIRIAC de la logistique

1.4 - Profits et bénéfices liés à l'intégration

L'intégration de la logistique dans Siriac permet d'envisager un certain nombre de profits et bénéfices que nous allons énumérer ci-dessous. Les noms en majuscule se réfèrent aux entités définies dans l'analyse détaillée.

*L'intégration dans Siriac permettra au personnel de l'import/export de disposer on-line des données des achats (commandes, articles, etc..) et des données de Foundations (gestionnaires, bâtiments, fournisseurs...) qu'il doit journellement exploiter. En outre, la notion de fournisseur sera maintenant élargie pour intégrer les transporteurs et transitaires (CAPABILITY particulière)

*Le cycle commercial sera maintenant bouclé. Le lien pourra donc être établi entre les AGREEMENTS des achats et les AGREEMENTS de la logistique (par ex. entre une demande d'expédition et une commande) y compris au niveau des positions de l'AGREEMENT (AGREEMENT ITEM).

*Les informations relatives à la logistique disponibles dans les premières phases du cycle commercial permettront une meilleure collaboration entre les deux services et l'optimisation des choix en matière de conditions de livraison, mode de transport et transporteur dans l'optique d'une réduction globale des coûts de transport et afin d' éviter les problèmes occasionnées par des spécifications inappropriées.

*La gestion d'un MOUVEMENT pourra être assurée dés qu'un DOCUMENT relatif à ce mouvement (ou à une étape de ce mouvement = MOVEMENT STEP), sera réceptionné et non plus seulement à l'étape de l'arrivage.(Pull vs Push strategy). Tous les documents liés au mouvement, qu'ils soient reçus ou produits par le CERN, pourront donc être associés à ce mouvement. Les informations correspondantes seront accessibles aux utilisateurs finaux (via EDH) avec les implications envisageables sur la gestion des projets et le planning. Ces informations pourront également être exploitées par la réception qui n'aura plus à ressaisir les arrivages internationaux et pourra également, le cas échéant , anticiper l'étape de réception détaillée grâce aux informations présentes dans le système.

*Les demandes d'expédition et de transport seront intégrées dans la nouvelle plateforme EDH. Les utilisateurs finaux disposeront donc d'un environnement standard pour toutes leurs demandes internes. Certains AGREEMENTS redondants pourront également être supprimés, par exemple dans le cas des réexpéditions d'articles à partir de commandes. Actuellement, l'utilisateur établit une DAI et une demande d'expédition. Dans le futur, un seul document de retour sera nécessaire (commande ou demande d'expédition).

*Le contrôle et le paiement des factures de transport sera facilité par le fait que le lien sera maintenant établi entre le MOUVEMENT et l'AGREEMENT de transport correspondant (par ex. lien entre une expédition et un ordre de transport).

*Lors du pesage de la marchandise avant expédition, le magasinier mettra directement à jour le mouvement (saisie du colisage, changement étape mouvement) et l'information sera immédiatement exploitable par la logistique.

*La mise à jour des étapes du mouvement et la notification des problèmes éventuels (commentaires liés à l'étape) pourront être faites directement par le service de distribution interne. Le suivi d'un mouvement pourra donc être assuré jusqu'à la livraison interne ou à partir de l'enlèvement chez l'utilisateur.

2 - Résumé de l'analyse détaillée

L'analyse détaillée a énuméré les entités utilisées dans le secteur de la Logistique (Entités = notions clés au sujet desquelles nous devons conserver de l'information). Certaines de ces entités sont communes avec les achats mais nécessitent des attributs supplémentaires. Les autres sont spécifiques à la Logistique. La liste ci-dessous énumère les entités utilisées dans ce secteur. Les définitions complètes se trouvent dans le rapport détaillé du 22 Mars 1991.

Nous allons ensuite illustrer les fonctions principales mises en relief lors de l'analyse détaillée.

2.1 - Liste des principales entités du secteur import/export

En gras, les entités spécifiques de la logistique

2.2 - Concepts clés

Le rôle essentiel de la logistique est, de gérer les mouvements de RESOURCES du CERN vers l'extérieur (fournisseur, institut, client...) ou de l'extérieur vers le CERN, et même éventuellement entre des tiers (matière première livrée par un fournisseur à un autre fournisseur dans le cadre d'une commande). L'adresse externe correspond à l'entité EXTERNAL POSTAL ADDRESS.

L'entité maîtresse dans le secteur logistique est donc le MOUVEMENT. Il est divisé en un certain nombre d'étapes (MOVEMENT STEP) qu'il doit satisfaire. Un arrivage international par exemple comprend l'étape de documentation (documents produits par l'expéditeur), ensuite l'enlèvement à domicile, les formalités d'exportation, le transport principal international, le dédouanement à l'importation, le camionnage à domicile, la réception et la livraison interne. (cf schéma ci-dessous). Certaines étapes sont optionnelles, d'autres sont obligatoires. Leur séquence dépend de l'entité MOVEMENT TYPE qui est supportée par l'entité MOVEMENT STEP USAGE.

Figure 3 : Mouvement et étapes du mouvement

LE MOUVEMENT peut être le résultat d'un ou plusieurs AGREEMENTS (demande d'expédition, commande, accord de prêt, demande de vente, etc..). La relation entre les AGREEMENTS satisfaits par un MOUVEMENT est assurée par l'entité INTERNAL CONSIGNEE/SENDER.

Dans certains cas, ce MOUVEMENT peut être généré par l'expéditeur externe et concerner soit un AGREEMENT (commande, etc..).soit une personne particulière (PERSON) ou INTERNAL ORGANISATION UNIT .

Pour initier les MOUVEMENTS ou satisfaire certaines étapes, la logistique produit ou reçoit des AGREEMENTS qui peuvent être regroupés dans les catégories suivantes :

*AGREEMENTS INTERNES : demande d'expédition

*AGREEMENTS DE TRANSPORT : Ordre de transport, instructions d'acheminement, etc....

*AGREEMENTS DOUANIERS : Certificats d'importation, carnets ATA, passavants permanents, etc...

Les AGREEMENTS de transport correspondent aux MOUVEMENTS pour lesquels la logistique détermine le mode de transport et le transporteur. Ils peuvent être consécutifs à une etude de transport ou se référer à un tarif de transport spécifique.

Dans le cadre de la gestion de ces MOUVEMENTS, la logistique reçoit ou produit toute sorte de documents conservés dans l'entité DOCUMENT REFERENCE qui permettent , soit de compléter les informations relatives au mouvement, (PACKAGES, MOVEMENT ITEMS) soit de faire franchir une étape à ce mouvement (documents de dédouanement...). Le passage d'un MOUVEMENT d'une étape à une autre est donc basé sur :

*la documentation reçue et conservée dans DOCUMENT REFERENCE

*la documentation produite (factures pro-forma, déclaration en douane) également conervée dans DOCUMENT REFERENCE

*Les AGREEMENTS de transport

*Les AGREEMENTS douaniers

Le destinataire ou expéditeur interne d'un MOUVEMENT (entité INTERNAL CONSIGNEE/SENDER , dés qu'il est identifié peut accéder à l'information relative au statut du MOUVEMENT.

2.3 - Diagrammes des fonctions principales

La hiérarchie des fonctions des Achats et de la logistique est présente dans le `DAA Detailed report' du 22 Mars 1991. Nous nous contenterons donc dans le présent chapitre, d'illustrer les fonctions principales de la logistique notamment dans le sens de leur dépendance avec les autres secteurs d'activité et leurs spécificités.

2.3.1 - Definition des Agreements :

Pour initier ou assurer le suivi des MOUVEMENTS la logistique crée certains AGREEMENTS spécifiques ou s'appuie sur les AGREEMENTS des achats (par exemple dans le cas des contrats cadres liés à des mouvements et aux ordres de transport correspondants) , des Ventes ( contrat de vente..), ou d'autres services (Accord de prêt, Assurances, etc..) Les différents types d'AGREEMENTS impliqués et leurs relations sont illustrés dans le schéma ci-dessous.

Figure 4: Définition des Agreements

2.3.2 - Documents et Agreements :

La logistique produit ou reçoit de nombreux documents. dont le contenu a pour but de fournir des informations complémentaires sur un mouvement ou une étape de mouvement (par ex. facture pro-forma, bulletin de livraison, lettre de transport, etc..). Une fois que l'information appropriée a été extraite de ces documents nous ne voulons en garder trâce dans le système qu'à titre de référence, ce qui explique pourquoi nous ne les considérons pas comme des Agreements.

L'idée est de créer un mouvement dés que l'on reçoit un document

relatif à ce mouvement, bien avant les étapes de dédouanement..

Les transporteurs et transitaires devraient être considérés comme Fournisseurs de services de transport car, comme tout fournisseur :

Ils émettent des factures et sont impliqués dans les paiements;

Ills possèdents des conditions commerciales spécifiques;

Ils offrent des services particuliers (cf CAPABILITY) avec des tarifs définis...;

Ils participent à des contrats cadres....

Figure 5 : Documents et agreements

2.3.3 - Agreement et mouvement :

Les documents qui sont la base du mouvement sont liés au mouvement dés que la relation est connue : les utilisateurs ont alors la possibilité d'être informés sur la situation actuelle du mouvement (étape de mouvement et statut). Ils sont tenus informés dés que l'information est disponible et non pas seulement lorsque la marchandise est livrée par le service de livraison interne, c'est à dire dans la dernière étape du mouvement.

Cette information permet de gagner du temps , lors de la réception et du contrôle de la marchandise en disposant par avance des informations nécessaires.

Figure 6: Agreements et mouvements

3 - Implications dans Siriac de cette intégration - Développements nécessaires

Après avoir résumé les conclusions de l'analyse détaillée de la logistique, il nous faut maintenant comparer les résultats obtenus avec la fonctionnalité présente dans Siriac. L'objectif recherché est d'envisager une intégration limitant le plus possible les impacts sur la structure de la base de données et conservant au maximum l'environnement actuel. .

3.1 - Les entités de la logistique et leurs correspondance dans Siriac

Un certain nombre d'entités significatives ont été définies dans le secteur de la logistique. Le tableau ci-dessous définit les concepts correspondants dans Siriac

Nous avons souligné que l'entité maîtresse de la logistique est le MOUVEMENT. Dans Siriac, la structure la plus proche de la notion de mouvement est la saisie des arrivages (table SAREC). La notion de MOVEMENT STEP n'est pas supportée explicitement. Pour le moment, les étapes définies au niveau de la commande distinguent l'arrivage et la réception détaillée. La gestion des arrivages n'intègre pas la notion d'étape. On ne connait un mouvement dans Siriac que dans sa phase ultime.

L'entité DOCUMENT REFERENCE n'est pas supportée actuellement. Etant directement liée au MOUVEMENT, elle devrait trouver sa place au niveau des arrivages/SAREC.

Les AGREEMENTS de la logistique, par contre, peuvent facilement s'intégrer au niveau des commandes, il suffit de créer autant de classes de commande que de types d'agreements logistiques et de définir des étapes spécifiques pour chacun.

3.2 - Les attributs des entités logistiques et leur correspondance dans Siriac

Le tableau ci-dessous définit, pour les entités AGREEMENT et MOVEMENT , les attributs spécifiques de la logistique et les notions correspondantes dans Siriac.

Lignes d'Agreement (Cas de la demande d'expédition) :

*On devrait pouvoir faire le lien entre une ligne de demande d'expédition et

la commande originale

*Lien entre un article et son numéro d'inventaire (zone `no inventaire' à prévoir dans Salca).

3.3 Prototype pour la gestion des mouvements - maquettes des écrans nécessaires

Nous avons pu constater, dans les pages précédentes, que l'intégration des Agreements logistiques dans Siriac aurait un impact limité à l'ajout de quelques zones supplémentaires dans Sacda. Par contre, le mouvement et la gestion des fonctions correspondantes nécessitent un certain nombre de développements pour couvrir la fonctionnalité actuelle de la logistique. Pour illustrer de manière plus concrète cet aspect, nous avons imaginé un prototype dont nous présentons ci-après les différentes maquettes d'écrans.

3.3.1 - Saisie du mouvement

Principe d'utilisation

Cet écran remplace l'écran actuel de GARRC (première page) et permet d'effectuer la saisie d'un mouvement.

Un mouvement est soit créé :

- automatiquement, en relation avec une demande d'expédition issue de EDH; de cette manière, il n'y a pas de nécessité d'incorporer dans SACDA des données supplémentaires pour le mouvement. Par ex., la demande d'expédition porte alors sur un fournisseur (destinataire) générique, et ses coordonnées sont reprises au sein du mouvement.

- manuellement, dans les autres cas.

Zones significatives

*La zone classe permet de saisir la classe du mouvement ( par ex. arrivage ou expédition, national/international/CEE)

*Le depot indique le site d'expédition ou d'arrivage de la marchandise

* RFBSAREC = Référence bulletin de livraison : inutilisée - voir écran 4

*Zone expéditeur/destinataire :

Suivant la classe du mouvement, les zones correspondant à l'expéditeur ou au destinataire seront complétées. Dans le cas d'une expédition, par exemple, l'expéditeur sera proposé par défaut (=CERN), les champs 'gest.' (gestionnaire) et 'adr.' (UFI) seront complétés, la zone 'DESTINATAIRE' sera saisie. Au niveau des adresses, il y aura la possibilité soit d'utiliser un code fournisseur et un code adresse, soit de saisir une adresse non codifiée . En effet, la moitié des expéditions ou arrivages ne sont pas liées à une commande et concernent des instituts ou des destinataires variés.

On pourra créér un nouveau fournisseur le cas échéant (cf option GCDA, enregistrement du fournisseur avant création de la commande)

Un certain nombre de zones ont été rajoutées à l'adresse : Telex, fax et E.Mail. Elles permettent l'envoi des documents par un mode de transmission automatique au moyen du support sélectionné (télex, téléfax ou messagerie électronique). Voir à ce sujet le paragraphe 4.3 : serveur de communication.

Fonctionnalités correspondantes

*Au niveau des commandes attachées au mouvement : on affichera les INCOTERMS.

*A partir d'une commande sélectionnée, possibilité de consulter la commande GCDAC.

3.3.2 - Colisage

Principe d'utilisation

Cet écran permet de saisir les caractéristiques générales du mouvement et le colisage c'est à dire le nombre, la nature et les dimensions des colis qui composent le mouvement.

Zones significatives

*Caractéristiques générales :

-Fragile 0/N : sert à indiquer si la marchandise est fragile

-Emballage 0/N : mentionne si un emballage doit être envisagé

-Matières dangereuses 0/N : précise si le mouvement contient des matières dangereuses et doit donc être soumis à un traitementparticulier (TIS)

-Assurance 0/N : indique si une assurance de transport doit être couverte

*Colisage :

-Nb : Nombre de colis

-Nature : type d'emballage (carton, caisse, vrac, etc..)

paramètre pour contrôler (ex CA pour caisse, CT pour carton, etc.......)

-Poids brut, poids net, dimensions, volume : trivial

*Totaux : Nombre total de colis, poids brut et net total, volume total (additionné par le système)

3.3.3 - Données intervenant

Principe d'utilisation

Cet écran permet d'associer au mouvement tout intervenant jouant un rôle précis dans ce mouvement (ex. transporteur principal, camionneur, assureur, transitaire à destination...). Un rôle donné ne peut être rempli que par un et un seul intervenant. L'expéditeur et le destinataire figurant sur l'écran d'entête jouent implicitement les rôles EX et DE.

Ces rôles seront repris dans le cadre des étapes, si ces dernières impliquent l'envoi d'un document vers un intervenant.

Lorsque l'intervenant est défini dans la base (code fourn. + code adresse), et uniquement dans ce cas, une commande logistique pourra lui être associée (pour facturation ultérieure...).

Sur la base des informations de facturation (devise, unité tarifaire, prix unitaire) et des autres données du mouvement (colisage, incoterms...), on pourra générer automatiquement des "commandes logistiques" dans une classe spécifique (ET pour étude de transport, OT pour ordre de transport, IT pour instructions au transitaire, EM pour demande d'emballage). Elles comporteront une ligne avec le code activité correspondant (PORT, EMBALLAGE, ASSURANCE ), un mode d'achat type SRV facturable ou non en fonction des INCOTERMS, éventuellement engageable en comptabilité. Elles seront envoyées par un enchaînement, et rattachées au mouvement.

Les autres documents n'ayant pas d'impact sur la facturation seront repris dans l'écran 4.

Zones significatives :

*Rôle de l'intervenant : contrôlé par paramètre

*Coordonnées intervenant existant dans la base (cas usuel) ou pas (juste pour le mouvement).

Les zones destinataire et adresse font référence à l'identification d'une personne et sa localisation dans la société. Pour le CERN, on poura indiquer le nr. de gestionnaire et le code UFI. Pour les autres intervenants, on indiquera du texte libre. En outre, le télex et le fax sont modifiables (même si l'intervenant existe dans la base).

*Famille = famille fournisseur

*Catégorie de transport : zone contrôlée par paramètre (ex. mode de transport avion, catégorie fret ou courrier) .

Fonctionnalités correspondantes :

*En fonction du mode de transport, de l'unité de tarification (normalement KG), éventuellement de la catégorie de transport (courrier, fret...) applicable au mode de transport, et du poids brut, il devrait être possible d'obtenir (par esc-v sur la zone "Prix Unit") le code du transporteur et son prix, dans le cadre de la consultation des tarifs informatisés.

*La catégorie de transport sera recopiée dans le type de la ligne de la commande générée.

*En fonction du type d'intervenant , on générera une commande dans la classe suivante :

- transporteur génerique -> étude de transport ET

- transporteur -> ordre de transport OT

- assureur -> demande d'assurance AT

- emballeur -> service d'emballage EM

Ce que nous demandons dans ce troisième écran correspond à une saisie simplifiée et non redondante de commandes, éventuellement sur des adresses libres, et en relation avec un mouvement. Il est vrai que GCDAC pourrait supporter ce genre de besoin, mais cela accroît la complexité pour l'utilisateur, et le risque d'incohérence entre commande et mouvement !

3.3.4 - Référencement des documents liés au mouvement

Principe d'utilisation

Cet écran sert à référencer tous les documents reçus ou produits par l'application dans le cadre d'une étape du mouvement.

*Les documents reçus sont introduits manuellement, avec leur réf, la date de création, le lieu d'émission et la date de réception (par défaut = date du jour) , l'étape du mouvement (éventuellement), le code `R' pour reçu.

*Les documents produits par le système sont générés automatiquement, avec l'étape de génération, le type de génération (P = Télex, Fax, Papier, Electronique...) ; ces documents pourront être reproduits en indiquant O dans la dernière colonne (Cp). Ils sont produits à partir des étapes du mouvement qui déclenchent les traitements correspondants et mettent à jour la table `Document Reference'.

*D'autres documents établis manuellement par la logistique (par ex. CCM) seront saisis manuellement avec le code `M' pour manuel .

*Les documents à produire seront mentionnés à titre indicatif selon la classe du mouvement, le mode de transport, la catégorie dans le mode et l'étape correspondante.

Zones significatives

*Type : type de document - par ex. LDV (lettre de voiture principale), CCM (certificat de circulation de marchandise), LDVI (lettre de voiture interne), FPF (Facture pro-forma), BL (Bordereau de livraison) ... Zone liée à un paramètre permettant le contrôle

*Int = rôle de l'intervenant associé au document produit.

*En bas de l'écran : détails optionnels pour la ligne courante du document.

Fonctionnalités correspondantes

Eventuellement , une table de contrôle pourrait être envisagée en liaison avec les types de documents et pourrait faire la relation entre le type, et le mode de production autorisé en fonction de la classe, du mode de transport et de la catégorie de transport .

3.3.5 - Etapes du mouvement:

Principe d'utilisation

En fonction de la classe du mouvement, un certain nombre d'étapes seront pré-affichées sur cet écran (sans indication de date, commentaire...). Il suffira ensuite à l'utilisateur de compléter les informations (commentaire, int.), et effectuer un commit, pour générer le traitement associé (éventuellement) à l'étape (et donc les documents liés).

Les étapes seront créées soit manuellement, soit par traitement si un traitement est associé.

Une étape permet, le cas échéant, de produire un ou plusieurs documents à destination d'un intervenant (rôle donné).

Zones significatives :

*Int = rôle de l'intervenant, si l'étape implique l'envoi de document.

Nouvelles étapes à prendre en compte :

*Etapes de distribution interne

*Etape enlèvement par transporteur dans le cadre des expéditions au départ du CERN

3.3.6 - Embargo

Principe d'utilisation :

Cet écran permet de générer automatiquement l'étape de décharge d'embargo pour une ou plusieurs commandes appartenant au mouvement et liées à un certificat d'importation.

Zones significatives :

*Dans la zone `No de commande', on entre le numéro de commande lié au mouvement

*La zone `ref cde EM,' sert à référencer la commande logistique liée à l'embargo (commande de classe EM)

*'Ref CI' est la référence du certificat d'importation (document douanier)

*'Solde CI' affiche le montant restant à décharger sur ce certificat d'importation.

*Dans la zone `décharge', on entre la valeur à décharger .

Fonctionnalités correspondantes :

(pour la fonctionnalité de base, se reporter au chapître 3.4.7 pour de plus amples informations)

*Une transaction est à prévoir pour la consultation des décharges d'un CI *Pour la génération du CI voir possibilité de copie de la commande dans une classe particulière)

3.4 - Extension des fonctions Siriac

La mise en place des nouveaux écrans énumérés dans le chapître précédent et les fonctionnalités qu'ils remplissent (pour couvrir les besoins de la logistique), impliquent un certain nombre de développements que nous allons évoquer ci-dessous.

3.4.1- Adresses :

Au niveau des adresses, les options suivantes sont souhaitées :

*possibilité de créer un nouveau fournisseur (transporteur...) au moment de la création de la commande logistique.

*support d'adresses électroniques et télex pour certains transporteurs et instituts : cf. FOUNDATIONS.

3.4.2 - Transmission des documents :

Intégration du FAX (ou TELEX) à l'application informatique - en relation avec une étape d'ENVOI ELECTRONIQUE au fournisseur (pour lequel on dispose d'une adresse fax ou autre E-mail...). Voir à ce sujet le paragraphe 4.3.

3.4.3 - Réception globale :

Un changement de philosophie doit être appliqué dans Siriac : la réception globale n'a plus de sens. En fait, il y aura "réception globale", dès qu'un mouvement est introduit dans le système. GARRC correspond donc maintenant à la création d'un nouveau mouvement. Une connexion directe devra être établie entre GARRC et GCDAC pour rattachement entre le mouvement et le(s) contrat(s) logistique(s) (éventuellement, table de lien à mettre en place au niveau des réceptions).

Les liens entre la commande logistique et le mouvement pourront être établis via l'étape spéciale de "réception système" et la reprise du numéro de réception/mouvement dans la commande `logistique'.

Au niveau de GARRC, on liera donc des commandes pour des raisons différentes :

- étude de transport liée (éventuellement)

- description du contenu du mouvement : ex. CA, demande expéd...

- décharge de certificat d'importation : par ex. classe EM

- ordres de transport éventuels : instructions/télex au transporteur (classe de commande

spéciale TI).

La réception détaillée (GRECRC) ne traitera que les lignes des commandes appartenant à certaines classes.

3.4.4 - Ordre de transport :

Définition : L'ordre de transport est un agreement de transport de la logistique. Son rôle est de confier à un transporteur/transitaire la réalisation d'un mouvement ou d'une étape de mouvement pour des conditions et un prix défini.

But : transfert d'un mouvement vers l'étape "Ordre de transport" avec génération d'un ordre de transport (classe OT à numérotation manuelle) dont le numéro est égal au numéro de mouvement .

Préalable : indiquer au niveau du mouvement le code du transporteur (valeurs particulières : CERN ou DESTinataire) et son code adresse, le type de facturation (KILO, FORFAIT) et les modalités de génération de l'ordre de transport :

- soit ETUDE, pour indiquer que les tarifs seront repris à partir de l'étude de transport associée au mouvement ;

- soit IMPOSE, pour indiquer que le destinataire a organisé le transport avec un transporteur de son choix (voir aussi INCOTERMS) : dans ce cas, le CERN transmet l'ordre au transporteur choisi, mais sans indication de tarif, et l'ordre de transport ne sera pas facturable ;

- soit TARIF (type de facturation = KILO), pour indiquer que les prix sont basés sur les tarifs informatisés (prix en devise et comparaison sur base francs suisses) : on reprend alors le tarif correspondant au transporteur, au poids, au mode de transport et à la destination (Voir Tarifs de transport)

- soit LIBRE, pour indiquer que les prix sont basés sur des tarifs officiels non informatisés (tarif GU, IATA, CFF, POSTE), ou sur des accords généraux - type contrat cadre (marché) - avec un transporteur (ex. Planzer, SERNAM, Balestra) : dans ce cas, les tarifs ne sont pas mentionnés (prix = 1 et mode d'achat "inconnu") et l'ordre de transport sera facturable (en fonction de l' incoterm).

- soit NULL, si le CERN ou le destinataire (acheteur, institut, fournisseur) assurent le rôle de transporteur (transporteur CERN ou DEST) : aucun ordre de transport ne sera créé.

L'ordre de transport pourra faire l'objet d'engagements comptables éventuels (par ex. en fonction de la classe, du montant...)

Informations relatives à la génération de l'ordre de transport :

* au niveau de l'entête :

--- clasacda = normalement OT

--- numsacda = numéro du mouvement ("réception IFR")

--- snusacda = 1

--- fousacda = transporteur associé au mouvement (nouvelle colonne)

--- tiesacda = fousacda

--- tafsacda, etc.. = adresse du transporteur pour le mouvement (nouvelle

colonne)

--- dcdsacda = date du jour

--- drdsacda = date prévue (ou texte libre au niveau du mouvement)

--- drfsacda = date limite d'enlèvement (ou texte libre au niveau du

mouvement)

--- recasacda = numéro du mouvement

--- prtsacda = INCOTERMS (Nouvelle colonne du mouvement)

--- dessacda = destination du port (Nouvelle colonne du mouvement)

--- mdtsacda = mode de transport du mouvement (MDTSAREC)

--- urgsacda = `C'

--- nbcsacda = nombre de colis du mouvement (NBCSAREC)

--- devsacda = devise liée à l'adresse de réception/expédition CERN

(Meyrin = CHF, Prévessin = FRF)

* au niveau de la ligne unique de l'ordre de transport :

1. Informations dépendant du type de facturation :

--- unasalca =

KILO -> KG

FORFAIT -> PC

--- qtcsalca =

KILO -> PDSSAREC

FORFAIT -> 1

--- artsalca =

KILO -> PORT_KG

FORFAIT -> PORT_PC

2. autres informations :

--- pvtsalca = prix hors taxes tarif ou étude de transport ou null (ordre de

transport LIBRE)

--- moasalca = fonction des INCOTERMS du mouvement

ASRV, si l'ordre est facturable ;

NSRV, si l'ordre n'est pas facturable ;

--- cg1salca : la répartition budgétaire est calculée sur la base du prorata des

commandes (non logistiques) liées au mouvement.

NB> Les mêmes principes sont applicables, pour générer un modèle d'étude de transport sur TTYY99, après l'étape de saisie d'un mouvement.

Remarque : Une fois généré, l'ordre de transport sera modifiable, avant son envoi au transporteur (via télex ou autre...).

3.4.5 - Tarif de transport informatisé :

Principe :

La logistique, par une étude statistique, détermine , par pays , les destinations les plus utilisées pour les mouvements de marchandises. ( destination = destination incoterm c'est à dire port, aéroport, ville importante).

En fonction de cette étude une demande de prix est adressée aux transitaires/transporteurs spécialisés dans ces destinations. Les prix demandés sont des prix nets par kilo (par tranche de poids), enlèvement et formalités douanières comprises, de manière à pouvoir les comparer efficacement entre eux.

Les offres sélectionnées sont stockées dans une table Oracle , par mode de transport, option (par ex. par avion, courrier ou fret), destination, et tranche de poids .

Fonctionnement :

Lors de la saisie d'un mouvement, à partir du formulaire de saisie principal, on accède au tableau comparatif des tarifs qui propose, en fonction du poids de l'envoi, de la destination et du mode de transport le transitaire/transporteur le plus avantageux. (voir exemple ci-dessous)

Il est possible ensuite de modifier ce choix, si nécessaire. Dés que le choix est validé, les données correspondantes sont transférées dans le formulaire principal et le coût du transport est calculé automatiquement.

Intégration :

L'intégration de cette fonctionnalité impliquera la création d'une nouvelle table pour le stockage des tarifs de transport. Cette table devra pouvoir être accédée à partir de l'écran 3 (données intervenant) de la saisie des mouvements, en faisant esc + v sur la zone `prix unit'. Le code du transporteur sélectionné et son prix seraient ensuite ramenés. Les informations relatives à la génération de la commande logistique associée devraient également être renseignées.

3.4.6 : Etude de transport :

Lorsque pour une destination déterminée, il n'existe pas de tarif de transport, la logistique a la possibilité de lancer une étude de transport en se basant sur l'historique des mouvements pour (ou en provenance de) la même destination. Le logiciel actuel intègre également l'envoi automatique de télex de demande de prix et de confirmation (via VMTELEX).

Voici quelles seraient dans Siriac les étapes de création d'une étude de transport :

1. Création d'un mouvement (étape initiale : saisie), avec informations générales (poids, nb colis...), et un texte complémentaire (type CO pour colisage) éventuel décrivant la nature détaillée des colis (nbre de colis par type, poids par colis et dimensions). Indication du transporteur = TTYY99.

2. Transfert du mouvement à l'étape "Etude de transport" : à partir de ce moment, les caractéristiques du mouvement ne sont plus modifiables, et une étude de transport est générée (outil spécial) dans une classe ET sur un transporteur générique TTYY99, en relation directe avec le mouvement (nr. de réception).

3. Définition d'une liste de transporteurs (sur base de consultations diverses - historiques...) associée à l'étude de transport.

4. Comme pour AODO, génération de copies de l'étude de transport à destination des transporteurs sélectionnés, et envoi électronique (télex...).

5. Traitement des réponses via GAODO, avec, en plus, la possibilité de mentionner un tarif au kilo.

6. Indication du transporteur sélectionné au niveau du mouvement, et transfert du mouvement à l'étape "Ordre de transport" : à partir de là, un ordre de transport est généré (outil spécial) dans une classe OT, en relation directe avec le mouvement (nr. réception).

3.4.7 : Traitement des certificats d'importation :

Les certificats d'importation sont des Agreements douaniers de la logistique qui concernent des marchandises (dites stratégiques) soumises à des restrictions de destination finale. Voici comment leur traitement pourrait être envisagé dans Siriac. (voir également commentaires sur écran 6 des mouvements)

1. Certificat d'importation = commande de classe spéciale.

2. Lien entre commandes et certificat d'importation, par l'insertion d'un lien de commande au moment de la création du certificat d'importation (services de la logistique) : possible actuellement dans SIRIAC via paramètre AUTSACDA - LCDINS. Une commande n'est liée habituellement qu'à un seul certificat mais plusieurs commanders peuvent ietre liées au même certificat (lien supporté dans SIRIAC).

3. Identification des lignes soumises à embargo : au moment de la création de la commande (ou après - GMDA) colonne nouvelle dans SALCA (ou modes d'achat).

4. Suivi des décharges du certificat d'importation : étape spéciale d'arrivage = décharge embargo (après dédouanement et avant réception détaillée) : transaction spéciale détectant si les commandes recues sont sujettes à embargo ou pas : indication des valeurs déchargées par les services de la logistique. A partir de là, une commande solde du certificat d'importation est générée, pour la valeur résiduelle. La sous-commande originale est "réceptionnée" (montant de la décharge et numéro de réception/mouvement) : passage à une étape spéciale "réception système". A tout moment, il sera possible d'obtenir, pour un certificat d'importation, les multiples décharges et leurs valeurs (avec l'indication automatique "décharge totale, finale ou partielle").

Lors de la saisie d'un mouvement lié à un certificat d'importation, le système proposera la décharge théorique : montant / quantités par ligne. Cette décharge sera modifiable. Si l'on ne désire pas décharger le certificat, il suffira de mentionner `0' dans le champ `décharge'.

3.4.8 : Passavants permanents :

Les passavants permanents sont des agreements douaniers de la logistique concernant du matériel utilisé par un membre du personnel du CERN à son domicile et dans le cadre de ses fonctions (principalement matériel informatique).

Ces documents sont soumis à des renouvellements annuels et seraient donc incorporés dans Siriac dans une classe particulière, chaque renouvellement générant un avenant.

Des consultations spécifiques devraient être mises en place pour afficher la liste des passavants en cours ainsi que leur échéance. Un système d'envoi automatique de courriers électroniques devrait également être incorporé de façon à avertir les utilisateurs que le passavant doit être renouvelé.

3.4.9 - Commandes logistiques et facturation

La facturation du transport se fera maintenant par rattachement des commandes logistiques à la facture (en fonction des INCOTERMS). Il faudrait sans doute prévoir au niveau de la facturation, de récupérer toutes les commandes associées au même mouvement en vue d'une facturation cohérente et afin de permettre une répartition rationnelle entre les différents codes budgéraires impliqués.

3.5 - Production des documents logistiques

L'application informatique import/export produit une trentaine de documents différents (formulaires douaniers, factures pro-forma, bordereaux, étiquettes, etc...) Ces documents , notamment ceux destinés à la douane, ont une présentation rigide, imposée par les administrations concernées (encadrements, gestion de plusieurs polices, logo...).

Actuellement, ces formulaires sont dessinés grâce à un logiciel Xerox et stockés sur le disque dur de l'imprimante locale (Xerox 3700 - Site de Meyrin), ou sur le disque VM contenant les exécutables de l'application (Xerox 4046 - Site de Prévessin). Le programme d'édition de type Fortsql lorsqu'il est exécuté contient les instructions Xerox applicables (appel du formulaire, des polices, etc..).

L'environnement Siriac ne gère pas, pour l'instant, ce genre de spécifications.

4 - Autres implications

4.1 - Intégration d'EXPED et COURRIER dans EDH

4.1.1 - Description :

EXPED et COURRIER sont deux applications publiques de la logistique permettant aux utilisateurs de saisir à distances les demandes d'expédition et de transport. La particularité de l'application COURRIER est de générer automatiquement une série de demandes sur la base d'une table mise à jour par le demandeur (expédition mensuelle du courrier CERN).

4.1.2 - Récupération des données :

Actuellement, une demande d'expédition intègre un Agreement (interne) et un mouvement contrairement à une DAI qui ne gère que des attributs propres à l'agreement. Lors de l'insertion des données provenant de la demande d'expédition dans les tables de transfert , les attributs propres au mouvement devraient être stockés dans une table spécifique. Lors de la récupération des demandes par la logistique, l'Agreement correspondant (classe de commande spécifique) et le mouvement devraient être crées simultanément. Le mouvement serait lié à l'Agreement comme une réception est liée actuellement à une commande. Le lien serait créé automatiquement. Eventuellement, la numérotation devrait être identique

4.1.3 - Autres fonctionnalités :

EXPED , outre la gestion des demandes d'expédition et de transport offre aux utilisateurs une gamme d'outils permettant d'interroger à distance la base de données import/export. Ces fonctionnalités devront être prises en compte lors de l'intégration dans EDH. .

4.2 - Intégration des données de la logistique dans Foundations

4.2.1 - Données de référence :

L'application informatique de l'import export s'appuie sur un certain nombre de tables contenant les données de référence . Certaines d'entre elles ont leur équivalent dans Foundations, d'autres pourraient être gérées au niveau de Siriac par des paramètres (comme c'est le cas actuellement pour les Incoterms, le mode de transport), d'autres enfin existent dans Foundations mais nécessiteraient des attributs supplémentaires. C'est le cas notamment de la table des pays pour laquelle le code numérique Iso devrait être intégré ainsi que la distinction CEE, AELE, Tiers.

4.2.2 - Fournisseurs spécifiques liés à la logistique :

L'intégration de la logistique implique également l'introduction de nouvelles familles de fournisseurs partageant la même `capability' :

*Transitaire = capability transport + douane

*Transporteur = capability transport

*Assureur = capability assurance

*Emballeur = capability emballage

Au niveau des informations générales relatives aux fournisseurs, l'adresse électronique devrait pouvoir être stockée en plus du numéro de télex ou du fax (zone à prévoir).

4.2.3 - Universités - Instituts - Administrations :

Les universités, Instituts devraient également être présents dans la base de Foundations (External Organisation Units). En effet, ils représentent près de 50% du volume des mouvements de la logistique. La codification des adresses les plus utilisées devrait être envisagée (zone adresse électronique à implémenter également).

Les douanes et administrations liées au domaine de la logistique devraient également être intégrées (type de partenariat particulier)

4-3 - Serveur de communication

Dans ses applications informatiques, la logistique s'est efforcé d'automatiser l'aspect communications et transfert d'informations. L'outil VMTelex a été largement utilisé pour l'envoi automatique de télex aux transporteurs ou destinataires des expéditions. Le courrier électronique (EMAIL) est également utilisé pour l'envoi des avis d'expédition aux universités, instituts.

Ces facilités de communication doivent être considérées lors de l'intégration et offrir une gamme plus large de supports incluant également le téléfax. L'aspect EDI devrait également être supporté; de plus en plus de transporteurs, par exemple, proposent à leurs clients cette solution pour faciliter les échanges (transmission des ordres de transport et des données relatives aux envois, réception des détails de consignation, etc..). Dans le domaine de la douane également les choses évoluent et l'on se met de plus en plus à mettre en place des solutions de dédouanement intégré (envoi électronique des déclarations en douane et réception de la confirmation du dédouanement). Certains fichiers transmis à la douane par courrier pourront, dans le futur, être transmis par des moyens électroniques (par ex. déclaration complémentaire globale, site de Prévessin)

L'idée serait donc de disposer d'un serveur de communications pouvant gérer tout type de transmission. Ce serveur (une machine Sun par exemple) remplirait également le rôle d'EDI GATEWAY pour les projets EDI en cours.

L'utilisation de ce serveur serait largement ouverte aux personnels des Achats dont les besoins sont notamment axés sur l'envoi de faxes. Une solution informatique transparente, incluant l'extraction du fichier à envoyer et la gestion automatique de la transmission grâce au serveur de communications, ne pourrait que séduire les utilisateurs potentiels.

5 - Annexes

Annexe 1
Applications import/export - Documentation disponible

Annexe 2
Principaux documents produits par la logistique

Annexe 3
Glossaire des termes utilisés dans le secteur import/export

Type : Ent.. pour entité , term pour terme