Que votre entreprise assure l´intégration d´un progiciel concédé sous licence ou d´un système interne personnalisé, il est toujours plus sage d´analyser les données au point de destination final. Si, par exemple, la première transaction prévue est la commande entrante, l´équipe EDI commence par analyser les exigences du système de traitement des commandes. Pour cette partie du projet, l´équipe doit inclure la personne la plus qualifiée au niveau de cette application.

Pour procéder à l´analyse des données, l´équipe EDI compare la structure des données au point de destination final avec la structure des données d´origine. Un système de traitement des commandes interne peut avoir des informations d´en-tête et des informations de détail. Les principaux groupes d´information dans la commande d´origine au format X12 sont l´en-tête, les détails et la fin du message. Une facture entrante au format X12 est composée de grands groupes d´information similaires : en-tête, détails et fin de message. La facture peut néanmoins provenir d´un système de comptes clients qui intègre en-tête de livraison, détails de livraison, en-tête de commande, détails de commande et un fichier principal client.

Lorsque les structures ont été comparées, l´analyse progresse vers chaque champ requis au point de destination final. La plupart des champs qui sont requis par la plupart des systèmes de traitement des commandes sont présents dans la plupart des commandes au format X12 même si les noms de champs sont différents.  Si un champ requis semble manquer, il peut éventuellement être mis à disposition en créant un fichier de référence croisée. Par exemple, le numéro de client n´est en général pas envoyé (ou même connu) par le client. Il peut éventuellement être intégré dans une référence croisée classée par identifiant d´expéditeur EDI.

Lorsque chaque champ a été trouvé, les contenu et format destinataires doivent être soigneusement comparés à ceux d´origine. Le champ du système de traitement de commandes interne pour le service du client peut être un code à 4 positions numériques. Le numéro de service est un exemple de clé secondaire exigeant une attention particulière. D´autres exemples incluent : numéro de magasin, identifiant de fournisseur de services, code transporteur, nom, code produit, etc. Curieusement, les clés primaires exigent en général moins d´attention étant donné que les services MIS ont appris à honorer les clés primaires de leurs partenaires commerciaux. Voici quelques exemples de clés primaires :

• Commande client
• Numéro PRO
• Numéro de facture
• Numéro de connaissement
• Numéro de réclamation

Si des codes existent pour l´ensemble du secteur d´activité, ils faciliteront considérablement l´utilisation de l´EDI. Si une application n´utilise que très peu un code touchant l´ensemble du secteur, la phase de développement EDI est peut-être le bon moment pour adopter entièrement ce code.  Un exemple d´adoption restreinte est un numéro de la DEA (Drug Enforcement Agency) utilisé par un fabricant pharmaceutique comme référence croisée client. La création d´une référence croisée est un processus continu, lourd et source d´erreurs. Il peut être perçu à tort comme une responsabilité de l´équipe EDI et peut être une activité très exigeante et de haut niveau lorsque toute imperfection stoppe une commande pharmaceutique ou un remboursement. Une bonne pratique de l´industrie pharmaceutique est d´utiliser le numéro de la DEA comme numéro client. D´autres exemples de numéros touchant l´ensemble du secteur incluent Dun and Bradstreet (DUNS), le Standard Carrier Alpha Code (SCAC), le Health Industry Number (HIN), l´UPC (Universal Product Code ou code universel des produits) et le National Drug Code (NDC).

Le mapping, définition par rapport au logiciel EDI

Lorsque la partie du mapping consistant en l´analyse des données est complète, le fichier « map » est défini par rapport au logiciel de traduction EDI. Sauf si un progiciel EDI à « prix budget » a été concédé sous licence (pour une mise en œuvre rapide), le progiciel permettra au coordinateur EDI de définir le fichier map. Le fichier map peut être comparé à une définition de base de données.  Lorsque le coordinateur EDI procède au mapping, le logiciel EDI stocke le fichier map, en général sous forme tabulaire. Plus tard, lorsqu´une transaction atteint la partie traduction du progiciel EDI, il utilise le fichier map pour déterminer la destination de chaque champ entrant et s´il est nécessaire de reformater.

Les « mappers » plus conviviaux ont tendance à être moins robustes. Les développeurs de logiciels veulent que les mappers soient en mesure d´être utilisés par des coordinateurs EDI orientés vers l´utilisateur. Et pourtant, les développeurs veulent également que les mappers soient en mesure de faire le tout possible pour éviter les interfaces personnalisées.

Développement d´interfaces personnalisées

Les interfaces EDI exigent une logique qui dépasse les capacités des mappers EDI les plus robustes. La structure assez complexe des bases de données des comptes clients requiert éventuellement une sélection ou un programme de prétraitement. Ce programme pourrait créer des informations d´en-tête, de détail et de fin sortantes par exemple, une structure de nature similaire à celle du format X12.

La logique qui convertit certains champs peut être regardée avec méfiance. Par exemple, est-il sage de supprimer le préfixe DUNS d´un numéro de magasin WALMART ? Est-il sage d´extraire la taille d´un vêtement des positions 7 à 12 du code produit intelligent du fabricant ? La conversion d´un champ peut parfois s´avérer nécessaire. Ces conversions peuvent être réalisées dans un programme de pré- ou post-traitement ou dans une sortie utilisateur exécutable par le programme EDI. Un exemple est la conversion d´une date du format siècle, mois, année, jour au format YYMMDD de X12.

Il faudrait également regarder avec méfiance les modifications personnalisées en fonction du partenaire commercial. Par exemple, ce n´est pas la responsabilité d´une interface ou d´un traducteur EDI sortant d´éviter les frais de transport de JCPenney. Le rejet de ces frais par Penney attire rapidement l´attention du coordinateur EDI mais devrait être examiné plus en amont. Si un entrepôt charge des frais de manière incorrecte, le logiciel d´entrepôt doit faire l´objet de modifications supplémentaires.

Imprimer cette page