Andreas Korthaus: Fortsetzung: EDIFACT

Beitrag lesen

Hallo!

Beim Schreiben dieses Beitrages wurde wohl gerade der Thread archiviert, das habe ich nach ca. 1/2 Stunde dann auch mal gemerkt ;-) Also muß ich leider hier posten.

nach den Gesetzen welcher Nation? Willkommen im Zeitalter der Globalisierung ... ;-)

Bei mir geht es um die anbindung ein einen doer mehrere nationale Lieferanten.

Das, was diese Seite definiert, ist nicht Edifact, sondern eine Anwendung davon. Genau wie XHTML eine Anwendung von XML ist. Nimm den Link aus meinem vorherigen Posting - das ist auch eine Anwendung von Edifact, nur eben mit einer anderen "DTD". Edifact beschreibt nur, wie man die "tags" notiert - nicht, was sie bedeuten.

Und wie wird das "normalerweise" praktisch umgesetzt? Wird das immer einem Partner vom anderen diktiert? Dann wäre es eine sinnlose Erfindung! Es _soll_ ja gerade standardisieren.

Außerdem weiß ich das einige Firmen das einsetzen.
Klar - wir ja auch.

Und wie? Habt Ihr mit allen Partnern eigene Protokolle und einen Parser mit künstlicher Intelligenz?

Mit "Branche" hat das gar nichts zu tun, sondern mit "Anwendungszweck".

Aber es guibt doch spezielle branchenspezifische Standardisierungs-Gremien, so wie eclass.de für die Industrie, oder sinfos.de, das hat doch bestimmt auch Auswirkungen auf EDI, oder?

Ich meine, daß sehr viele verschiedene Firmen mit sehr vielen unterschiedlichen Methoden arbeiten. Wenn Du einen _Standard_ setzen willst, brauchst Du entweder die Obermenge über alle diese Methoden in Deinem Datenmodell, oder die Macht, viele bzw. alle Firmen dazu zu bringen, auf eigene, liebgewordene und in deren Software bzw. Arbeitsmethodik eingebrannte Features zu verzichten, um sich Deinem Standard unterzuordnen. Für diesen Verzicht mußt Du ihnen dann massive Gegenleistungen bieten können.

Also sowas wie die oben beschriebenen Projekte, oder? Ließe sich das problem denn mit XML lösen? Denn es müßte ja wenigstens einheitliche DTDs verwendet werden, oder?

Wenn sich ein Betrieb an Deine Norm halten will, dann kann sie nicht einfach eine Zahlungsform ablehnen, nur weil ihre Software das nicht unterstützt. Das ist in Deinem Fall _sehr_ viel kritischer, als wenn ein Browser eine Seite falsch anzeigt, weil er den Standard nicht korrekt oder nur teilweise unterstützt.

Aber es scheint ja zu funktionieren. Außerdem würde ich das sowieso nicht für alle Geschäftsprozesse verwenden, sondern für Bereiche die sich besonders eignen, wie eben die Beschaffung von C-Gütern.

Ob Du einen Standard für Zahlungsverkehr auf Edifact oder auf XML basieren lassen willst, das ist zunächst einmal relativ unwichtig, solange Du die semantische Seite des Problems betrachtest.

Was bringt mir XML wenn die gegenseite das nicht unterstützt? Obwohl, man könnte sich ja auch einen netten konnverter schreiben, oder das hierfür vorgesehene PERL-Mdoul verwenden ;-)

Gibt es Informationen, die Du darstellen können mußt, die aber von etablierten, auf Edifact basierenden Standards nicht abgedeckt werden?

nein.

Gibt es inhaltliche Defizite in den bestehenden Standards?

nein.

Gibt es einen Bedarf, den Standard durch einen neuen, mächtigeren Standard abzulösen, basierend auf dem neue Anwendungen möglich wären?

nein, höchtens später mal eien XML-VErsion wenn man so mit mehr PArtnern kommunizieren kann. Bei mir ist es weniger ein semantisches Problem, eher ein praktisches, und das man nichtz die Markt-Macht besitzt den PArtnern eigene Standards aufzwingen zu können, sondern es soll möglichst auf die Standards der Geschäftspartner(Lieferanten) eingegeangen werden, da das System ja gerade erst geschrieben wird bin  ich da flexibel und will halt Schnittstellen zu möglichst vielen Lieferanten ermöglichen.

Wenn Du dies mit "ja" beantworten kannst, dann baue einen neuen Standard - und lasse den dann auf XML basieren, wenn Dir danach ist (denn das kostet zwar viel mehr Speicherplatz, ist aber viel besser human readable - und Komprimierung läßt sich auf einer niedrigeren Kommunikationsebene implementieren). Denn der Anpassungsaufwand bestehender Anwendungen ist im Bereich der Semantik viel höher als im Bereich der Syntax ... der Parser, welcher Edifact nach "Semantik" übersetzt, ist relativ einfach durch einen XML-Parser abzulösen, aber einer Anwendung beizubringen, ihre internen Datenmodelle an neue Anforderungen anzupassen, das kann sehr viel schlimmer sein.

Das verstehe ich durchaus, aber wie gesagt ist es die Vorgabe auf bestehende Standards der Lieferanten einzugehen, und dies möglichst flexibel zu implementieren. Die Semantik ist bei einfachen Bestellungen nicht so wild.

Viele Grüße
Andreas