Modul für EDI/EDIFACT, Alternativen => XML?

[Andreas Korthaus]

Hallo!

Kennt sich jemand mit EDIFACT aus? Kennt da jemand ein gutes PERL-Modul für? Ich habe zwar bei cpan gesucht, finde da auch ein Modul welches EDIFACT nach XML übersetzt, aber das will ich im Augenblick gar nicht. Wenn ich nach 'EDI' suche finde ich 566 Ergebnisse und finde so auf den ersten Blick nicht Vernünftiges. Ich brauche zwar nur einen ganz kleinen Auschnitt aus EDIFACT, nämlich ORDERS (http://www.edifactory.de/edifact/D01A/orders.html), aber ich will doch keinen kompletten Konverter schreiben, aber das ist ja nicht ganz so einfach, es muß ja kommuniziert werde und die Antwort ist vielleicht nicht unbedingt die eine die man erwartet, habe keine Ahnung wie komplex das ganze dann würde, aber schon alleine ORDERS ist schonmal nicht gerade unkomplex. Ein PERL-Modul würde da verlutlich helfen, wobei  auch die Einbindung eines solchen Moduls vermutlich ebenfalls recht komplex ist.
Wie sieht das eigentlich in der Praxis aus, auf welchen Kanälen werden EDIFACT Nachrichten normalerweise verschickt?

Oder mal ein g anz anderer Ansatz - was gibt es heut zu Tage für Alternativen? Man hört ja immer das tollste zu XML, aber einen vergleichbar ausgereiften und international akzeptierten Standard wie EDIFACT habe ich bis heute noch nicht gefunden. Und was bringt mir der tollste Standard wenn die Gegenstelle den nicht unterstützt!

Wo wie schonmal dabei sind, was haltet Ihr von http://www.eclass.de?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Oder mal ein ganz anderer Ansatz - was gibt es heut zu Tage für Alternativen? Man hört ja immer das tollste zu XML, aber einen vergleichbar ausgereiften und international akzeptierten Standard wie EDIFACT habe ich bis heute noch nicht gefunden. Und was bringt mir der tollste Standard wenn die Gegenstelle den nicht unterstützt!

1. Welches Interesse hat "die Gegenstelle" daran, daß Du (und vergleichbare Partner!) ihre Daten verarbeiten kannst?
2. Gibt es andere potentielle "Gegenstellen", die an einem Austausch ihrer Daten mit Dir interessiert sein könnten?

Standards für bestimmte inhaltliche Datenuniversen (so klingt Deine Aufgabenstellung) entstehen dadurch, daß mehrere Firmen es als Problem ansehen, ihre Daten gegenseitig nicht zu verstehen.
Würde Micro$oft es beispielsweise als Problem ansehen, daß ihre Word-Formate in anderen Office-Paketen nicht verarbeitet werden können (oder fremde Formate nicht in Word) und daß andere Firmen deshalb viel weniger Office-Pakete verkaufen können als möglich (weil die Anwender nun mal Dokumente nicht nur erstellen, sondern auch austauschen wollen), dann würde es ein Interesse daran haben, einen gemeinsamen Standard auszuarbeiten ... in manchen Fällen ist die proprietäre Datenstruktur aber nicht das Problem, sondern die Lösung. 8-\

Viele Grüße
      Michael
(Edifact-Geschädigter)

[Andreas Korthaus]

Hi Michael!

1. Welches Interesse hat "die Gegenstelle" daran, daß Du (und vergleichbare Partner!) ihre Daten verarbeiten kannst?

Jede Firma die selbst EDIFACT verwendet wird dieses Interesse haben!

2. Gibt es andere potentielle "Gegenstellen", die an einem Austausch ihrer Daten mit Dir interessiert sein könnten?

Ja. Es geht ja nicht um mich persönlich ;-)

Standards für bestimmte inhaltliche Datenuniversen (so klingt Deine Aufgabenstellung) entstehen dadurch, daß mehrere Firmen es als Problem ansehen, ihre Daten gegenseitig nicht zu verstehen.

Es geht hier vor allem um elektronische Bestellungen und Rechnungen, mir vor allem um die Bestellungen. Gerade größere Lieferanten haben oft eine derartige Schnittstelle, um Prozesskosten zu sparen, denn so wird eine Bestellung nicht per Fax, Brief, email oder Telefon entgegen genommen, welche dann erstmal ausgewertet und in das eigene System von Hand eingegeben werden müßte, sondern das ganze geschieht automatisch und EDIFACT ist ein Standard den die meisten größeren Firmen unterstützen. Der Lieferant wird auf alle Fälle mehr Interesse daran haben, als daran mit mir jetzt mal eine eigene Lösung zu erarbeiten! Mir edifact werden einmal ein paar Daten augetauscht, und ab da funkttioniert es automatisch, ist doch alles wundebar! Nur ist das ganze ganz schön komplex!

(Edifact-Geschädigter)

Was heißt das? Was hast Du damit gemacht und warum hat es Dir Schmerzen zugefügt ? ;-)

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

1. Welches Interesse hat "die Gegenstelle" daran, daß Du (und vergleichbare Partner!) ihre Daten verarbeiten kannst?
   Jede Firma die selbst EDIFACT verwendet wird dieses Interesse haben!

keineswegs. Wer sagt denn, daß Edifact nicht schon für rein interne Zwecke eine bessere Lösung ist als etwas selbst Entwickeltes?

2. Gibt es andere potentielle "Gegenstellen", die an einem Austausch ihrer Daten mit Dir interessiert sein könnten?
   Ja. Es geht ja nicht um mich persönlich ;-)

Aber der Wille für die Zusammenarbeit ist oftmals nicht bei allen Partnern gleich stark ausgeprägt. (Ich erzähle lieber nicht im Detail, was ich da diese Tage wieder erleben durfte ... es gibt Firmen, die _weder_ zur Einrichtung von DNS _noch_ zum Editieren von hosts-Files in der Lage sind ...)

Standards für bestimmte inhaltliche Datenuniversen (so klingt Deine Aufgabenstellung) entstehen dadurch, daß mehrere Firmen es als Problem ansehen, ihre Daten gegenseitig nicht zu verstehen.
Es geht hier vor allem um elektronische Bestellungen und Rechnungen, mir vor allem um die Bestellungen.

Das ist aber ein sehr weites Feld.

Je enger Du dieses Feld eingrenzen kannst, desto mehr Sinn macht der Standard - denn ein Datenformat, das Rechnungen und Bestellungen jeglicher Art (beispielsweise jeglicher denkbarer Zahlungsmodalitäten!) abbilden können soll, würde irre komplex - das könnte niemand mehr verstehen.

Gerade größere Lieferanten haben oft eine derartige Schnittstelle, um Prozesskosten zu sparen,

Genau - und jeder seine eigene.
Denn wollten alle dieselbe Schnittstelle nutzen, dann müßte jeder die Spezialitäten eines jeden anderen Teilnehmers an diesem Standard ertragen. Oder man müßte sich auf eine sinnvolle Teilmenge dieser Obermenge einigen - was für viele Teilnehmer an diesem Standard einen Verzicht gegenüber ihren proprietären Methoden bedeuten würde ... und das reduziert den Willen, sich an den gemeinsamen Standard zu halten, enorm.
Dein Problem ist mit der Standardisierung von HTML sehr wohl vergleichbar.

das ganze geschieht automatisch und EDIFACT ist ein Standard den die meisten größeren Firmen unterstützen.

Edifact mag ein Standard sein - aber soweit ich das mitbekommen habe, ein Standard auf der Abstraktionsebene von XML, nicht von HTML. Und was nützt Dir XML ohne die Definition einer DTD, an die alle Beteiligten sich halten? Aus Deiner Sicht ist diese DTD der gewünschte Standard - XML oder Edifact sind nur die Notationssprachen.

(Edifact-Geschädigter)
Was heißt das? Was hast Du damit gemacht und warum hat es Dir Schmerzen zugefügt ? ;-)

Na gut, bevor Du mich schlägst, mache ich halt mal ein bißchen Werbung: ;-)
     http://www.isys.ch/news/vdf_d.html
(nein, das habe ich nicht gemacht - nur versucht, es zu decodieren ...)

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

keineswegs. Wer sagt denn, daß Edifact nicht schon für rein interne Zwecke eine bessere Lösung ist als etwas selbst Entwickeltes?

Aber eigentlich wäre ja gerade Edifact eine Paradedisziplin von XML, nur das es das damals vermutlich noch nicht gab. Daher vermute ich das  man bei einer Neuentwikkung doch liebr auf eien XMl-Lösung zurückgreifen sollte, nur ist es bei XML das problem das es vielleicht wieder zu frei ist, zumindest gibt es doch auch hier zu edifact vergleichbare Standardisierungsversuche, nur davon hat sich IMHO noch nichts durchgesetzt und viele Köche verderben den Brei!

Es geht hier vor allem um elektronische Bestellungen und Rechnungen, mir vor allem um die Bestellungen.

Das ist aber ein sehr weites Feld.

Erstmal nur Bestellungen, das ist sehr stark eingegrenzt.

Je enger Du dieses Feld eingrenzen kannst, desto mehr Sinn macht der Standard - denn ein Datenformat, das Rechnungen und Bestellungen jeglicher Art (beispielsweise jeglicher denkbarer Zahlungsmodalitäten!) abbilden können soll, würde irre komplex - das könnte niemand mehr verstehen.

Aber ich dachte edifact würde gerade das lösen, eben weil es ein Standard für jeden erdenklichen Geschäfts-Datenverkehr darstellt. Es gibt doch sogar ne ISO norm und der Standrd wird doch von den UN jedes Jahr definiert. Was will man daran groß ändern?

Gerade größere Lieferanten haben oft eine derartige Schnittstelle, um Prozesskosten zu sparen,

Genau - und jeder seine eigene.
Denn wollten alle dieselbe Schnittstelle nutzen, dann müßte jeder die Spezialitäten eines jeden anderen Teilnehmers an diesem Standard ertragen. Oder man müßte sich auf eine sinnvolle Teilmenge dieser Obermenge einigen - was für viele Teilnehmer an diesem Standard einen Verzicht gegenüber ihren proprietären Methoden bedeuten würde ... und das reduziert den Willen, sich an den gemeinsamen Standard zu halten, enorm.

verstehe ich jetzt nicht. was kann man bei Bestellungen und rechnungen so groß verschiedene Anforderungen haben? Die Daten sind ja sogar gesetzlich festgelegt die eien Rechnung enthalten muß, also wo liegt das Problem? Es geht ja weniger um eienn Produktkatalog, sondern um den reinen Bestellvorgang.

Edifact mag ein Standard sein - aber soweit ich das mitbekommen habe, ein Standard auf der Abstraktionsebene von XML, nicht von HTML. Und was nützt Dir XML ohne die Definition einer DTD, an die alle Beteiligten sich halten? Aus Deiner Sicht ist diese DTD der gewünschte Standard - XML oder Edifact sind nur die Notationssprachen.

Hm? so wie ich das bis jetzt verstanden habe(http://www.edifactory.de/openhtml.php3?ref=%2Fediexam1.htm) wird doch innerhalb des edifact-dokuments einiges definiert, und der Rest ist vorgeschrieben. Außerdem weiß ich das einige Firmen das einsetzen. Vor allem in einer Branche werden die Undterschiede nicht so groß sein.

Na gut, bevor Du mich schlägst, mache ich halt mal ein bißchen Werbung: ;-)
     http://www.isys.ch/news/vdf_d.html
(nein, das habe ich nicht gemacht - nur versucht, es zu decodieren ...)

sowas komplexes will ich ja gar nicht. Es reichen erstmal Bestellungen. Oder meinst Du das so gut wie alle großen Firmen noch  mit Fax/Brief/Telefon arbeiten? Die kleinen sicherlich, aber die größeren? Es _gibt_ doch bereits einen elektronischen Verkehr an Geschäftsdaten, und es _bringt_ den Fiemn ja auch einiges, udn gerade Sachen wie Rechnungen  udn bestellungen sind doch IMHO weitgehend standardisiert. Wenn ich mir 10 Rechnungen angucke enthalten alle so gut wie dieselben Angaben. Wo soll da ein Problem sein? Verschiedene Zahlungsmodalitäten? Wie viele gibt es denn? 10? Nichtmal. Natürlich kombiniert mit Zahlungszielen und Skonti, aber das ist bis auf die genaue Kombinbation dieser Daten doch in allen Unternehmen gleich!

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

verstehe ich jetzt nicht. was kann man bei Bestellungen und rechnungen so groß verschiedene Anforderungen haben? Die Daten sind ja sogar gesetzlich festgelegt die eien Rechnung enthalten muß,

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

Edifact mag ein Standard sein - aber soweit ich das mitbekommen habe, ein Standard auf der Abstraktionsebene von XML, nicht von HTML. Und was nützt Dir XML ohne die Definition einer DTD, an die alle Beteiligten sich halten? Aus Deiner Sicht ist diese DTD der gewünschte Standard - XML oder Edifact sind nur die Notationssprachen.
Hm? so wie ich das bis jetzt verstanden habe(http://www.edifactory.de/openhtml.php3?ref=%2Fediexam1.htm) wird doch innerhalb des edifact-dokuments einiges definiert, und der Rest ist vorgeschrieben.

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.

Außerdem weiß ich das einige Firmen das einsetzen.

Klar - wir ja auch.

Vor allem in einer Branche werden die Unterschiede nicht so groß sein.

Mit "Branche" hat das gar nichts zu tun, sondern mit "Anwendungszweck".
Zwei Sprachen sind einander bezüglich ihrer Verarbeitung nicht dann ähnlich, wenn diese Ähnlichkeit sich auf die Syntax beschränkt (weil beide beispielsweise aus "tags" bestehen) - wesentlich für die Auswertung von Informationen sind die Inhalte, nicht die Form.
Das siehst Du ja an Deinem Projekt mit dem dynamischen Datenbankformat: Schon die Syntax ist etwas, das man am liebsten einheitlich hätte, aber wenn Du die Semantik der Daten nicht mehr verstehst, wie willst Du dann diese Daten auswerten? Was nützt es Dir beispielsweise, wenn Du den Inhalt einer Datenbanktabelle als "Tabelle" anzeigen kannst, falls diese Tabellendaten für sich selbst gar keine nachvollziehbare Bedeutung haben, sondern nur im Kontext mit anderen Tabellen? Was nützt es Dir, eine Liste von Fremdschlüsseln auf eine andere Tabelle auszugeben, deren Bedeutung niemand verstehen kann, weil er diese andere Tabelle nicht hat und weil Dein Datenmodell auf syntaktischer Ebene nicht "weiß", daß diese Werte Fremdschlüssel sein sollen, die Anzeige des Tabelleninhalts ohne die entsprechenden JOINs also für eine inhaltliche Betrachtung gar keinen Sinn machen kann? (Reine Debug-Anzeigen eines Developers mal ausgenommen.)

Na gut, bevor Du mich schlägst, mache ich halt mal ein bißchen Werbung: ;-)
     http://www.isys.ch/news/vdf_d.html
(nein, das habe ich nicht gemacht - nur versucht, es zu decodieren ...)
sowas komplexes will ich ja gar nicht. Es reichen erstmal Bestellungen. Oder meinst Du das so gut wie alle großen Firmen noch  mit Fax/Brief/Telefon arbeiten?

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.

Die kleinen sicherlich, aber die größeren? Es _gibt_ doch bereits einen elektronischen Verkehr an Geschäftsdaten, und es _bringt_ den Firmen ja auch einiges, udn gerade Sachen wie Rechnungen und bestellungen sind doch IMHO weitgehend standardisiert. Wenn ich mir 10 Rechnungen angucke enthalten alle so gut wie dieselben Angaben. Wo soll da ein Problem sein? Verschiedene Zahlungsmodalitäten? Wie viele gibt es denn? 10? Nichtmal. Natürlich kombiniert mit Zahlungszielen und Skonti, aber das ist bis auf die genaue Kombinbation dieser Daten doch in allen Unternehmen gleich!

Das "so gut wie" und das "bis auf" sind aber das Problem. Jemand, der Deinen Standard unterstützen will, muß diesen vollständig unterstützen - egal, welche Teilbereiche davon er bisher nur im Angebot hatte.
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.

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.
Gibt es Informationen, die Du darstellen können mußt, die aber von etablierten, auf Edifact basierenden Standards nicht abgedeckt werden? Gibt es inhaltliche Defizite in den bestehenden Standards? Gibt es einen Bedarf, den Standard durch einen neuen, mächtigeren Standard abzulösen, basierend auf dem neue Anwendungen möglich wären? 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.

Viele Grüße
      Michael