Pourquoi l'EDI est-il toujours utilisé et comment y faire face?

En un mot, de l'Inertie. Le développement de l'EDI par le comité entre les divers de lentreprise et des organisations ayant des objectifs a été un cauchemar (c'est triste à dire que j'ai été là-bas).

En leur demandant d'abandonner ces avec encore une autre série de comités acceptant l'API de service web normes va prendre encore plus de temps, comment voulez-vous vendre l'idée de remplacer un format électronique avec un autre, à une non-conseil technique? Ce possible busness avantage donne-t-il. À l'origine, les avantages de l'échange électronique ont été clair, mais de remplacer l'un avec l'autre ne l'est pas. Nous parlons vraiment de grandes entreprises d'ici.

Parce qu'il est formellement établi la Norme (en fait, une très grande et ensemble complet de normes). Et c'est l'un des avantages revendiqués d'une norme, vous n'aurez pas besoin de changer quoi que ce soit pour un long moment.

Et de la changer, il faut un accord entre deux ou plusieurs (souvent des milliers et des milliers d'autres) des partenaires commerciaux (y compris peut-être l'ensemble de vos concurrents) d'accord.

Formats EDI ont beaucoup plus de signal-à-bruit (parce qu'ils ont été conçus en arrière quand cela a été considéré comme important.) Quelqu'un qui connaît et comprend EDI regarder vos XML et de dire "Où est le boeuf (de données)?"

Très peu de développeurs d'écrire leurs propres analyseurs. Il y a beaucoup de bons mappeurs (et de nombreux legs et les applications d'entreprise viennent avec eux intégrée). Donc il y a beaucoup de relief à votre disposition pour votre douleur (y compris au moins une Open Source application sur SourceForge).

Un peu d'informations pour tous les intéressés. L'EDI est essentiellement une conception par le comité de format d'échange de données qui non seulement définir les règles de mise en forme des données (comme XML), mais aussi afin de définir chaque document qui pourrait peut-être jamais être envoyés entre les 2 sociétés. Donc, pour un morceau de données qui peuvent être échangées entre les entreprises, ils sont venus avec une définition exacte de ce qui était censé être dans chacun de ces documents. Bien sûr, personne ne pouvait prévoir chaque morceau de données que 2 compagnies souhaitez échanger. Donc, vous vous retrouvez avec des entreprises à l'aide de champs qui ont été définis pour 1 chose, être utilisé pour un autre morceau de l'information.

Ce que vous avez fini avec, est extrêmement compliquée format de données, dans lequel beaucoup de personnes qui l'utilisent ne suivent pas les normes, parce qu'ils ont besoin d'envoyer des informations personnalisées, dont la norme ne tient pas compte. Donc en fin de compte, vous devez toujours en parler à chaque entreprise que vous souhaitez traiter, et de trouver toutes les petites particularités de leur mise en œuvre, juste que vous auriez à faire si vous êtes allé à quelqu'un avec un custom XML de l'interface. Sauf que dans le cas de l'EDI, le format est difficile à analyser et encore plus difficile de bien écrire, de sorte que vous finissez par faire tout un tas de travail juste pour envoyer un document, lorsque vous faites le même genre de penser à avoir un XML personnalisé solution aurait entraîné de nombreuses fois moins de problèmes.

À mon humble avis il y a plusieurs problèmes avec EDIFACT.

1. Il n'est pas facile à analyser ou de générer un modèle d'Objet. Ce n'est probablement pas un gros problème plus comme il y a maintenant un bon système de autour de que de le faire pour vous, par exemple, smooks.org
2. Il n'est pas facile à lire. Vous vous habituez à mais le XML est beaucoup plus facile à lire
3. De Validation n'est pas facile (de la comparer à la validation XML)
4. Il y a beaucoup trop de versions différentes et de saveurs, D95B, D96B, D00A, D00B etc.
5. Mais je pense que le plus gros problème est que tout le monde est en utilisant les normes différemment. Ils utilisent le même "format", mais les champs sont définis différemment. Nous utilisons EDIFACT d'envoyer et de recevoir des messages de Terminaux à Conteneurs et ils ont tous de légères différences. Ils auraient par exemple, utilisent tous un D95B CODECO, mais pour certains terminaux d'un certain segment est obligatoire pour un autre, c'est en option ou même pas le droit d'être là. Ensuite, vous avez les segments qui sont utilisés le même mais le contenu est différent.

Donc, pour résumer: C'est une douleur dans le cou.

Legacy Support

Edifact est l'une des meilleures normes quand il s'agit de l'échange de documents.
La plupart des problèmes viennent de tradingpartners envoi non normalisé des documents.

Oui c'est un peu bizarre format c'est long et fastidieux à travailler avec si vous ne connaissez pas les tenants et les aboutissants mais qui va pour XML.

Vous voulez vraiment en XML Edifact? Regarder le ballonnement, difficile à lire, les normes XML peppol (pan-européennes sur les marchés publics en ligne) est de travailler.

Oui, il fonctionne bien et dandy, si vous n'avez pas toutes les erreurs dans les systèmes, dépannage edifacts est donc beaucoup plus facile une fois que vous vous habituez à le format de dépannage UBL documents.

Vous dites que vous avez de 0,00 $à utiliser sur le projet?
Vous devriez vraiment regarder dans la quantité de travail manuel effectué dans votre entreprise et les économies inhérentes à l'EDI peut offrir de l'analyse coûts-avantages peut être puissant à portée de main.

Une solution, même s'il va vous coûter, est d'aller à une société comme la ADXqui dispose d'outils que vous pouvez utiliser pour convertir des formats EDI de plus agréable formats CSV. Selon le volume et le type de transactions que vous faites, cela peut être à la fois abordable et beaucoup moins stressant. J'ai utilisé leurs produits dans le passé, alors qu'ils sont un peu de travail à mettre en place, ils ne travaux devis bien, et sont très stables. En raison de l'histoire de l'EDI, vous pouvez probablement trouver des centaines d'autres entreprises qui offrent des services similaires.

Une autre raison est que des messages tels que afin. les factures, notes de crédit, etc il ya beaucoup de valeur financière dans les transactions et ils ont besoin d'être sécurisé, mais peut-être plus important encore, ils ont besoin d'avoir de fin à fin de validation et de vérification ainsi que la non répudiation.

Par exemple, je vous envoie un ordre de 1/2 millions d'Euros de marchandises, - vous m'envoyer les marchandises, puis j'ai "perdre" de l'ordre de l'information et de vous dire que je ne suis pas payer. La combinaison de ces normes et de les VANS font de cette quasi impossible ou au moins avec autant d'une piste de vérification que les problèmes pourraient être suivis. C'est pourquoi le "Oh laissez utilisation de xml et de l'internet au lieu de EDIFACT et les VANS" ont tendance à échouer. Comme quelqu'un l'els répondu, de l'Inertie, mais il est une force d'inertie fondée dans une étable, efficace, fiable, sécurisée et bien compris le système.

De le faire sur le bon marché n'est pas toujours une option.

Si c'est une consolation quand j'ai d'abord mis en œuvre EDI en 87 il n'y avait pratiquement pas de logiciel autour et j'ai donc eu l'Interbridge tables et écrit mon propre parseur pour le royaume-UNI, TRADACOMS standard à l'aide de Cognos, logiciel sur et HP Mini, et il a bien fonctionné. En supposant que vous êtes en négociation avec d'autres partenaires EDI le coût vient probablement au point d'avoir besoin d'utiliser un VAN.

J'ai eu à utiliser l'EDI ainsi et je suis d'accord. Nous avons utilisé BizTalk mapper qui a bien fonctionné. De nombreux systèmes sont construits sur l'EDI(bien avant XML).