Mois : juin 2019

Les fichiers EDI sont la base de vos échanges commerciaux. En amont ou en aval de la plateforme EDI, l’envoi de fichiers est le principe de base de l’Échange de Données Informatisé. La dématérialisation de vos données est un moyen très efficace pour simplifier vos tâches administratives.

Des fichiers plats tout simples aux fichiers structurés normés, il existe une multitude de formats électroniques pour échanger vos documents commerciaux. Faisons le tour des principaux d’entre eux.

Fichiers EDI, les formats simples : les fichiers plats

Qu’est-ce qu’un fichier plat?

Les fichiers plats (de l’anglais flat file) représentent le format le plus universel des fichiers EDI pour échanger des données.

Ce type de fichier EDI contient plusieurs enregistrements. Les lignes d’entête sont dédiées aux informations du document entier. Les lignes de détail au détail du document commercial, comme les lignes des factures ou des commandes.

La définition du caractère de fin de ligne est différente selon les systèmes d’exploitation Unix ou Windows.

Conseil : pour la bonne reconnaissance des fichiers entre des systèmes d’exploitation différents, pensez à effectuer une conversion lors du transfert du fichier.

Les fichiers plats variables

On parle de fichier plat à taille variable (ffv) lorsque les données sont séparées les unes des autres par un caractère particulier comme le point-virgule, la ligne verticale (|) ou la tabulation. Le format CSV en est l’exemple le plus connu.

Le document de spécification d’un fichier plat à taille variable décrit chaque type de ligne, avec la séquence des champs de données, leur type numérique (ou alphanumérique) ainsi qu’avec le contenu.

Conseil : attention à ne pas confondre fichier de type CSV et tableur Excel (.xls). Ce dernier est un format propriétaire qui n’est pas un fichier plat. Il est difficilement interprétable par une plateforme EDI.

Le fichier plat fixe

Lorsque chaque champ a un nombre de caractères prédéterminé, il n’est pas nécessaire de séparer les données par un caractère séparateur. On parle alors de fichier plat fixe (ou pf). C’est le cas d’un des deux formats possibles des iDocs du progiciel SAP.

Un fichier plat fixe doit être accompagné d’une description complète contenant la position, la longueur, le type (numérique ou alphanumérique) ainsi que le contenu de chaque champ de données.

Conseil : veillez à ne pas utiliser le caractère séparateur dans les données d’un fichier plat à taille variable. Par exemple une virgule placée dans un champ adresse serait interprétée comme un séparateur et décalerait toute la lecture du fichier.

L’intérêt des fichiers plats est leur facilité d’importation ou d’exportation, mais ils sont aussi souvent de petite taille, et allègent les volumes des transactions informatisées. On les utilise surtout à l’entrée ou à la sortie du système d’information.

Les fichiers d’interfaces des logiciels ERP comme SAP, CEGID ou SAGE sont des fichiers plats.

Les fichiers EDI structurés normés

Un des formats qui vient à l’esprit lorsque l’on parle de flux EDI est l’XML : les données sont présentées à l’aide de balises et de règles que l’on peut personnaliser.

Les balises XML structurent de manière hiérarchisée les données d’un fichier.

.Le XML est relativement simple et mais aussi extensible et configurable afin que n’importe quel type de données puisse être décrit. Certaines organisations ont proposées des standards :

Factur-X est un nouveau standard de facture électronique basé sur un fichier PDF lisible attaché à un fichier sous format XML.

Conseil : prenez garde à la taille des fichiers XML, qui peut rapidement être beaucoup plus importante qu’un fichier EDI comparable. 

Mais comment ne pas évoquer les normes EDI lorsque l’on parle d’échanges électroniques ?

Les différentes normes et standards EDI

En effet, ces normes EDI permettent d’échanger des documents dans un langage commun standardisé et assurent ainsi l’interopérabilité.

Un document EDI contient des éléments de données et des codes descriptifs écrits sous formes de segments. Le tout est groupé dans des enveloppes. L’ensemble est mis en forme selon des règles de syntaxe et de vocabulaire de la norme EDI choisie.

Les normes EDI ont été conçues pour bien prendre en compte les besoins de chaque branche d’activité.

La norme UN/EDIFACT

La norme UN/EDIFACT est largement utilisée en Europe et couvre une large gamme de messages standardisés pour l’échange de documents commerciaux dans de nombreux secteurs comme le retail ou l’industrie.

L’EANCOM est un sous ensemble de l’EDIFACT et GS1 est l’organisme de standardisation.

Les messages EDIFACT les plus utilisés sont l’ORDERS (commande), DESADV (avis d’expédition) et l’INVOIC (la facture).

Quant est-il de l’ANSI?

Le standard ANSI ASC X12, lui, est essentiellement utilisé aux Etats-Unis et Canada.

En ANSI X12, on retrouve le message 850 pour les bons de commande, le message 856 pour les bons de livraison et le message 810 pour les factures électroniques.

A propos du standard ODETTE

Par ailleurs, le standard ODETTE (messages DELINS, CALDEL, AVIEXP ou INVOIC) avait été développés pour améliorer les échanges entre partenaires du secteur automobile. En Europe il a été progressivement remplacé par la norme UN/EDIFACT (messages DELFOR, DELJIT, DESADV ou INVOIC).

Dans l’industrie automobile européenne, l’organisation ODETTE et les associations nationales (GALIA, VDA, ODETTE SWEDEN, …) proposent des recommandations EDI s’appuyant sur les standards ou la norme UN/EDIFACT.

• Le message de livraison en flux tendus DELJIT, équivalent au message ODETTE CALDEL et 830 en ANSI X12.
• Le message de prévision de livraison DELFOR, équivalent au message ODETTE DELINS et 862 en ANSI X12.

GALIA, l’organisme de normalisation du secteur automobile.

Parmi les normes EDI, il y a aussi le SWIFT (secteur bancaire), le TRADACOMS (spécifique Royaume-Uni) et le VDA (format standard particulier à l’industrie automobile allemande).

Fichiers plats, XML, EDI… vous savez, à présent, tout sur les différents types de fichiers possibles pour échanger des informations électroniquement. C’est pratique, aussi bien pour l’automatisation de vos factures (dématérialisation de factures), la traçabilité des documents envoyés par voie électronique, et pour la gestion de votre flux de données.

Reste à déterminer le format adéquat en entrée et en sortie de la solution EDI, en fonction de la technologie que vous utilisez mais aussi des usages de votre secteur d’activité.

Depuis plus de 30 ans Tenor accompagne ses clients et partenaires dans la mise en place de fichiers EDI. Dans la même thématique, découvrez aussi cet excellent article sur la piste d’audit fiable en dématérialisation de factures. Vous pouvez aussi consulter cette page sur les services EDI proposés par Tenor. De même, et pour répondre à toutes vos questions n’hésitez pas à contacter nos experts.

L’EDI en service web est idéal pour faire communiquer des applications entre elles. Bien souvent, en tant que développeur web, on se pose la question d’utiliser des flux EDI standards ou bien des services web dédiés. Les deux approches se complètent bien. Ce petit tour d’horizon va vous aider à y voir plus clair afin d’effectuer le meilleur choix. Vous aurez également l’occasion de visualiser comment les implémenter concrètement pour votre site web, et générer, de cette manière, une meilleure expérience pour vos clients.

Qu’est-ce qu’une API et un service web ?

Qu’est-ce qu’une API?

Une API (Application Programming Interface) est une interface par laquelle un logiciel offre des services à d’autres logiciels. Elle permet l’appel de fonctions internes à une application pour qu’un programme puisse interagir et échanger avec un autre.

Lorsque cette action implique l’envoi de données par un réseau, les services web entrent en jeu.

Tous les services web sont des API mais toutes les API ne sont pas des services web.

Qu’est-ce qu’un service Web?

Un web service, ou service web en français, est un programme informatique qui permet la communication et l’échange de données entre des applications distantes, à travers Internet.

Ainsi les applications peuvent dialoguer et appeler des fonctions à distance, indépendamment des plateformes et des langages sur lesquels elles reposent.

Ce type de communication se base sur le principe standard des demandes et des réponses. Il s’effectue avec des messages au format XML principalement. HTTP est le protocole de communication le plus souvent utilisé.

Les services web peuvent être de trois types : SOAP (Simple Object Access Protocol), REST (Representational State Transfer) ou XML-RPC.

Astuce : l’utilisation du protocole http permet de s’affranchir des réseaux spécialisés payants.

Quand utiliser votre EDI en service web ?

L’EDI demeure le moyen le plus robuste et fiable pour échanger des données en masse entre des systèmes d’information différents. Avec les standards, on bénéficie d’un large choix de documents commerciaux déjà définis, en particulier dans les processus Order-to-cash, Purchase-to-pay et tout au long du cycle de la Supply Chain.

Pour les entreprises travaillant avec plusieurs prestataires logistiques, le déploiement des standards EDI évite le développement d’autant de services web que de portails distants.

En fonction de votre système d’information et des volumes d’échanges

Toutefois, en fonction des volumes de données et de la disparité des systèmes impliqués, votre architecture idéale fera sans doute appel à l’Échange de Données Informatisé complété par des services web.

Certains donneurs d’ordre ne laissent pas le choix en mettant en place des portails accessibles uniquement via leurs API.

A noter : des ERP comme CEGID ou MS Dynamics disposent nativement d’API pour échanger des données avec des logiciels externes.

Les services web donnent la possibilité d’effectuer des interactions globales. Ils apportent les fonctionnalités d’un portail et l’accès à de nouveaux types de transactions, souvent plus orientées utilisateurs.

Optimisez votre entrepôt (WMS) et votre transport (TMS) en ouvrant votre ERP vers l’extérieur et visualisez ce qui se passe. Vous pouvez consulter toutes les informations en temps réel. 

Les connexions via API se font en temps réel, sans plateforme intermédiaire : la visibilité sur les données est instantanée.

EDI en service web pour gérer les exceptions

Avec l’utilisation d’une API web, vous voudrez peut-être pouvoir gérer des exceptions avec vos clients, ce qu’il est difficile de configurer en EDI. Vous pouvez aussi afficher les informations de suivi d’expédition, rendues accessibles par votre prestataire logistique via son application web. Vous avez même la possibilité de récupérer les données du portail d’un fournisseur pour créer et alimenter des statistiques de niveau de service.

Conseil : l’utilisation des API d’un portail peut nécessiter de faire évoluer ses développements avec le cycle de vie du portail. Renseignez-vous auprès de votre partenaire sur les évolutions prévues à court ou moyen terme.

Exemple d’utilisation avec la plateforme Chorus

Chorus PRO est le portail public de l’Etat sur lequel transiteront progressivement l’ensemble des factures électroniques à destination du service public. Il s’agit là d’un portail mutualisé, pour tous les fournisseurs et toutes les administrations publiques.

L’objectif de l’Etat est de dématérialiser 100% des factures qui lui sont adressées selon un échéancier qui a démarré le premier janvier 2017 et qui s’est achevé le premier janvier 2020.

En EDI classique

En mode EDI classique, les fournisseurs de la sphère publique adressent les factures dématérialisées sous forme de fichiers normalisés, et reçoivent en retour un accusé émis par Chorus.

En web service

Par service web, vous obtenez en sus des informations concernant le suivi de la facture : il est possible de retrouver des factures selon une recherche multicritères, de récupérer la visualisation PDF générée par Chorus Pro et l’historique de traitement.

L’API de Chorus Pro permet une remontée d’informations plus complète vers votre outil de facturation, pour un meilleur suivi par vos utilisateurs. Les entreprises cherchent à apporter davantage de services à leurs clients. Dans ce contexte qui tend vers des écosystèmes informatiques de plus en plus ouverts et interopérables, les services web sont certainement le meilleur moyen de connecter deux applications.

Depuis plus de 30 ans Tenor vous accompagne dans la dématérialisation de vos factures et dans la mise en place de vos EDI en SaaS, en WebEDI ou même OnPremise. Parcourez sur cette page toutes nos solutions EDI. Re-découvrez aussi cet excellent article sur l’automatisation des factures pour Chorus Pro ou encore celui-ci sur le piste d’audit fiable. De même, n’hésitez pas à nous contacter afin de valider la faisabilité de votre projet.

Lancez votre projet d’EDI en service web dès aujourd’hui. Contactez nous:

Le déploiement EDI est un outil majeur de l’évolution de toute entreprise. en effet, vos clients désirent souvent mettre en place des flux EDI ou la dématérialisation des factures. Cela, afin d’échanger des données de manière informatisée. L’objectif est double : répondre à leurs demandes et viser un système EDI performant pour votre entreprise. On vous donne quelques conseils sur comment développer votre stratégie de déploiement EDI, et quels sont les pièges à éviter.

La logique des donneurs d’ordre et fournisseurs dans le déploiement EDI

D’une manière générale, le donneur d’ordre est la personne ou l’entité qui prend l’initiative d’une opération de déploiement EDI.

En EDI (Echange de Données Informatisé), le donneur d’ordre est celui qui commande des produits, du transport, ou de la logistique, à un fournisseur ou à un prestataire. Bref, il s’agit souvent du client.

Bien souvent, le client est en position d’imposer son propre plan de déploiement EDI à ses fournisseurs. De fait, il choisit les messages à échanger et le planning de mise en place.

Pour chaque message, le donneur d’ordre choisit le standard (EDIFACT, VDA, format XML…) et le profil d’utilisation.

En effet, de nombreuses variantes sont possibles pour un même format standard. Il convient donc de préciser les données obligatoires pour les logiciels applicatifs des partenaires, en plus de celles définies par la norme.

Un cahier des charges propre à chaque donneur d’ordre décrit la syntaxe souhaitée. Ce sont les guidelines ou contrats d’interchange.

Conseil : pour toute demande de partenaire commercial, procurez-vous la liste des documents commerciaux concernés, les guidelines correspondantes (avec quelques exemples) ainsi que les protocoles de communication possibles.

Evitez les erreurs classiques lors de votre déploiement EDI

Pour entretenir une bonne relation commerciale, il faut répondre aux demandes des clients. Mais n’oublions pas toute la plus-value que peut gagner votre entreprise avec un système EDI bien construit et efficace, qui permet de lui simplifier la vie. Et si ce déploiement était l’occasion de satisfaire les clients externes et internes à la fois ?

Non au plat de spaghetti

S’il est vrai que pour un même type de message, chaque client demande son propre format EDI (contrat d’interchange), il faut optimiser vos flux d’information entre votre système informatique et la plateforme EDI.

Avant de se lancer dans la mise en place et les tests avec vos partenaires, il est important d’avoir élaboré en interne des fichiers pivots.

Les fichiers pivots sont les fichiers applicatifs intermédiaires intégrés ou exportés par votre logiciel de gestion et dont les données sont converties au format EDI. Ils contiennent l’ensemble des données informatiques nécessaires à votre système de gestion pour un type de transaction.

Dans le cas de l’ERP SAP, les fichiers d’interface existent déjà, ce sont les IDOCS.

On vise un format de fichier pivot par message. Il doit être générique (éviter les particularités clients), complet, et documenté dans des spécifications.

Conseil : utilisez l’ordre du processus Order-to-Cash pour implémenter vos interfaces. Vos bons de livraison et factures électroniques seront plus fiables si les commandes ont été intégrées automatiquement.

Une fois les fichiers d’interface implémentés, un tronc commun existe entre vos systèmes d’information et le traducteur EDI.

Les guidelines de vos clients ne sont plus que des variantes gérées dans le mapping EDI.

Conseil : construisez des formats de fichiers évolutifs, c’est-à-dire offrant la possibilité de rajouter des données sans devoir changer la structure. Ceci évitera les impacts futurs sur les programmes de traduction EDI.

Fixez votre ligne de déploiement

Il est possible que les demandes de vos partenaires commerciaux arrivent simultanément et que vous ne puissiez pas toutes les satisfaire en même temps.

Même en gardant un rythme soutenu, il va falloir prioriser.

Si tous vos pivots ne sont pas encore prêts, optez pour un déploiement par type de messages.  

Par exemple, consacrez-vous à l’implémentation des bons de commande ou des avis d’expédition avec tous les clients intéressés. De cette manière, même partiellement, chaque client avance sur son projet EDI avec vous.

Conseil : en toute logique, un donneur d’ordre cherche à déployer en premier les messages lui apportant le meilleur retour sur investissement. Calculez vos propres gains par message pour comprendre où placer les efforts en premier.

Le choix du déploiement EDI est souvent une contrainte sectorielle

Votre secteur d’activité déterminera si ce type de déploiement est possible ou non.

Dans l’industrie automobile, l’ensemble des messages doivent être opérationnels sur les plateformes d’autotest pour obtenir l’accord de mise en production par le client.

Si tous les pivots de votre système d’information sont opérationnels, un déploiement client par client est possible.

Priorité alors aux échanges commerciaux avec les clients grands comptes. Quitte à utiliser les solutions Web EDI proposées par les autres clients pour commencer à remplacer les documents papier pendant la période de transition.

Une fois tous vos échanges électroniques déployés, ce sera la façon d’interfacer de nouveaux clients.

Conseil : associez votre service commercial, qui pourra se servir de l’argument EDI lors de négociations, ou vous avertir d’une situation tendue à débloquer par le biais de l’EDI.

N’oubliez pas vos fournisseurs

Chaque entreprise est le donneur d’ordre d’un ensemble de fournisseurs. A votre tour, élargissez les bénéfices de votre système EDI en embarquant vos propres fournisseurs.

Conseil : soyez actif dans les groupes de normalisation et gardez le contact avec les équipes B2B de vos partenaires.

Devoir s’interfacer en EDI avec vos clients est une belle opportunité de construire votre propre système d’Echange de Données Informatisé. En parallèle du déploiement, listez vos besoins, de la gestion des commandes à la dématérialisation fiscale. Et gagnez la partie en construisant la plateforme qui apportera toute la plus-value de l’EDI à votre entreprise.

Tenor vous accompagne dans la mise en place de votre EDI fournisseur depuis plus de 30 ans. Découvrez cet excellent article sur l’Onboarding et nos services EDI pour approfondir le sujet. De même, vous pouvez contacter l’un de nos experts pour identifier vos besoins en EDI.

Contactez-nous : +33 481 917999