Comment trouver la solution EDI appropriée
Qu’est-ce que l’EDI et l’API ?
Qu’est-ce qu’un type de document ou un protocole de transport ?
Qu’est-ce que le routage et pourquoi faut-il convertir certains documents ?
+ 33 (0)4 11 93 26 66
Comment trouver la solution EDI qui convient
Dans le monde des affaires moderne, l’échange efficace de messages avec les partenaires commerciaux est crucial pour le succès de toute entreprise. C’est pourquoi la demande de solutions fiables et individuelles en matière d’échange de données électroniques est en constante augmentation. Dans cet article, nous voulons rafraîchir les bases de l’EDI, entrer dans le détail des processus EDI connexes et montrer les potentiels d’une interface API. Cela vous aidera à identifier et à définir les avantages pour vos processus. Notre équipe internationale de spécialistes vous soutient avec nos solutions commerciales intelligentes à chaque étape de votre voyage pour devenir un champion numérique !
Définition de l’EDI
EDI (= Electronic Data Interchange) décrit l’échange électronique de documents commerciaux (par exemple, des commandes, des bons de livraison, des factures, etc.) sur la base de normes internationales de structure et de format. Les processus d’échange de données électroniques permettent d’échanger efficacement des données et de les traiter à l’intérieur ou à l’extérieur de l’entreprise. La norme du document ainsi que le protocole utilisé pour la transmission sont déterminants pour la transmission de différents types de messages. Par rapport aux documents papier classiques, les documents électroniques peuvent également aider votre entreprise à réaliser des économies importantes. Les transactions commerciales peuvent non seulement être traitées plus rapidement, mais aussi de manière plus fiable et avec un minimum d’intervention humaine. Cliquez ici pour en savoir plus sur les bases de l’EDI dans notre guide.
Types de documents EDI
Un type de document EDI décrit la spécification individuelle d’un certain format de fichier concernant la structure et le contenu d’un document EDI (par exemple, une facture, une commande). Les différents formats EDI (par exemple UN/EDIFACT, TRADACOMS, ANSI X.12, VDA, UBL) prennent en compte les exigences des différents groupes de parties prenantes concernant les propriétés d’un document EDI. Des normes de document uniformes garantissent que les systèmes de l’expéditeur et du destinataire peuvent interpréter correctement les informations échangées. Cliquez ici pour en savoir plus sur les types de documents EDI et les protocoles de transport dans notre guide.
Protocoles de transport EDI
Les protocoles de transport sont responsables de la transmission de divers types de documents. En utilisant différents protocoles EDI (par exemple AS2, AS4, OFTP, OFT2, HTTP/HTTPS), un message EDI est non seulement transmis mais aussi crypté. Un type de protocole peut être interprété comme une sorte de langage par lequel différents systèmes informatiques communiquent entre eux.
Définition de l’API
Le terme API (= Application Programming Interface) décrit une sorte d’interface directe pour la programmation d’applications. Une API offre à d’autres programmes la possibilité de se connecter directement à un système afin d’échanger des informations entre les applications et d’autres parties du programme, de manière standardisée et structurée. Cliquez ici pour lire notre guide afin d’en savoir plus sur le fonctionnement des API et leur potentiel pour votre entreprise.
Connaissez-vous déjà notre livre blanc sur l’EDI?
Routage à l‘aide de l’exemple de l’IDoc
En général, la transmission correcte des messages EDI d’un expéditeur au destinataire respectif est appelée routage. Pour le routage des messages EDI, les formats de documents doivent répondre à certaines exigences en matière de structure, de format et de contenu.
Par exemple, l’IDoc sert de format d’échange central pour l’importation et l’exportation de documents commerciaux vers et depuis un système SAP. Les documents IDoc peuvent être échangés entre les systèmes SAP via une interface définie dans le système SAP. Deux variantes sont disponibles à cet effet. Soit via une variante basée sur le texte, soit sous la forme d’une représentation XML. Une fois que le document IDoc a été exporté, il peut être utilisé en interne dans l’entreprise ou transféré en externe à des partenaires commerciaux.
Toutefois, si tous les partenaires commerciaux n’utilisent pas SAP, le transfert transparent du document IDoc n’est pas toujours possible. Si un partenaire commercial utilise un autre système ERP, une conversion du document EDI est inévitable. Si le partenaire commercial utilise un système SAP, des versions différentes du document peuvent également empêcher le transfert des données. Un document IDoc exporté contient également toutes les données d’utilisation du type de document correspondant et comprend donc également des informations internes à SAP telles que les fonctions du partenaire, le statut de traitement, les unités de mesure internes ou d’autres informations. Cependant, ces informations ne sont pas toujours adaptées à un processus EDI complet avec des partenaires externes. En général, ce ne sont pas toutes les informations qui sont censées être transmises aux parties externes, mais surtout celles qui sont pertinentes pour ces partenaires commerciaux.
Conversion à l‘aide de l’exemple de l’IDoc
Les convertisseurs EDI sont des solutions informatiques spécifiques qui sont utilisées pour exporter des documents commerciaux, par exemple au format IDoc, à partir d’un système SAP, puis les convertir dans un format EDI indépendant de la plate-forme (par exemple EDIFACT) qui peut être livré au fournisseur de services EDI du partenaire commercial. Les données EDIFACT reçues sont ensuite converties par le fournisseur de services EDI du partenaire commercial dans le format d’importation du système ERP cible afin qu’elles puissent être importées sans erreur. Ce transfert peut également avoir lieu dans l’autre sens à tout moment.
Solution EDI locale
Solution EDI en cloud
Dans le cas d’un convertisseur EDI local, il y a une connexion à un logiciel de convertisseur local responsable du routage, du mappage, de l’ajout de signatures, de l’établissement de connexions système et du contrôle des messages. Les convertisseurs EDI locaux peuvent établir une connexion directe avec les partenaires qui ne disposent pas de leur propre connexion EDI. En interne, ils nécessitent toutefois un niveau de service et de maintenance relativement élevé. Les connexions externes à des réseaux tels que PEPPOL ne peuvent généralement pas être établies immédiatement. Cela nécessite une certification en tant que point d’accès PEPPOL qualifié. INPOSIA est un point d’accès PEPPOL et est donc autorisé à connecter ses clients au réseau PEPPOL.
Les solutions EDI basées sur le cloud sont une bonne option pour les entreprises qui ne disposent pas de ressources internes suffisantes ou qui souhaitent économiser des capacités. Avec des processus internes grandement simplifiés, une solution basée sur le cloud est une option rentable. Le WebEDI permet également de connecter des fournisseurs qui ne disposent pas eux-mêmes de fonctionnalités EDI. Des réseaux tiers tels que PEPPOL peuvent également être connectés. L’EDI basé sur le cloud permet d’externaliser l’acheminement et le mappage des messages à un fournisseur EDI. Ce fournisseur prend en charge l’échange de messages avec vos partenaires commerciaux – soit directement, si le partenaire dispose de capacités EDI internes, soit via le fournisseur du partenaire.
Pour en savoir plus sur les API, consultez notre livre blanc sur la gestion des API
EDI via API
Outre les protocoles de transport courants (AS2, OFTP2, SFTP/FTPS), l’EDI peut également être mis en œuvre via une API. Certains protocoles tels que SFTP ou FTPS ne fournissent pas de preuve que le destinataire a effectivement reçu le fichier envoyé. Il est donc difficile de retracer un échange de messages particulier, notamment en cas d’erreur. Des types de protocoles comme AS2 ou AS4 permettent de surmonter cette limitation. Cependant, aucun de ces protocoles n’offre une traçabilité complète du processus. Par exemple, pendant l’envoi d’un message, seul l’état de livraison du message peut être suivi jusqu’au réseau suivant, mais pas au-delà. Dans le système ERP, un message sortant indique seulement que le message a été reçu par le fournisseur de services EDI. Même en utilisant des protocoles modernes tels que AS2 ou AS4, il n’est pas possible de savoir si le message a effectivement été reçu par le destinataire.
La différence entre les connexions API et les protocoles ou interfaces de transport traditionnels est que l’échange de données entre les systèmes ERP ou entre un système ERP et un prestataire de services EDI a lieu directement via une interface intégrée, l’API. Les métadonnées telles que les informations sur l’état de livraison d’un message ne sont donc pas perdues. Ces données peuvent être visualisées et récupérées automatiquement en temps réel dans l’interface utilisateur de votre système ERP. Cela augmente considérablement la performance de vos processus B2B et minimise le risque d’erreurs.
Les utilisateurs peuvent facilement identifier et corriger rapidement les erreurs, puisque les informations sur les transferts EDI sont disponibles en temps réel via l’API. Par exemple, ils peuvent vérifier si une commande importante a été transférée avec succès à l’un de leurs fournisseurs ou si elle n’a pas pu être transmise en raison d’une erreur. Cela vous donne l’occasion de revérifier la commande, d’apporter toute correction nécessaire ou de redéclencher la commande.
Vous êtes intéressé par notre solution EDI et vous avez d’autres questions ?
Prenez contact avec nos experts EDI. Nous nous ferons un plaisir de vous aider. Par téléphone, par courriel ou en personne dans vos locaux !
Andreas Milz
Spécialiste EDI INPOSIA