Diskussion:EDIFACT

Gab's einen Grund warum das Beispiel gelöscht wurde? Hieraus war nämlich erkennbar, was ein Segment,Element ist. Diese Begriffe stehen nun ohne weitere Erläuterung im Text. --BlueKarlVie 18:42, 28. Mai 2006 (CEST) (ups. war vorhin nicht eingeloggt)

warum wurde unter edifact nachrichtentypen noch nicht contrl erwähnt? in der praxis so wichtig... -- 62.52.0.98 10:29, 18. Dez. 2007 (CET)

- Wahrscheinlich da es vor Version 3 nicht Teil des Standards war. Vgl. hierzu zB https://service.unece.org/trade/untdid/d11a/trmd/trmdi2.htm wo alle erlaubten Message-Types für Version 1+2 aufgelistet sind. Für Version 3 findet sich zB diese Definition https://www.gefeg.com/jswg/v3/data/v3-contrl.htm wo Version 4 diese dann auch für Batch und Interactive Messages zulässt https://www.gefeg.com/jswg/v4/data/v4_docs.htm (nicht signierter Beitrag von 84.114.16.39 (Diskussion) 10:08, 28. Mai 2021 (CEST))

BAPLIE

Wo ist BAPLIE (Ladeplan von Containerschiffen) anzusiedeln? --Abubiju 12:08, 23. Jan. 2008 (CET)

Ich glaube ich habe noch nie zuvor einen derart grottenschlechten wiki-artikel gelesen. 77.11.221.168 23:46, 7. Mai 2009 (CEST)

Geschichte

Seit wann gibt es EDIFACT? Wie war die Entwicklung? 91.43.78.169 13:30, 21. Feb. 2010 (CET)

Wenn das Beispiel stimmt, mindestens seit 1996! -- Jpr65 16:22, 4. Mai 2010 (CEST)

Kritik am Artikel

- EDIFACT ist eine Norm. Der Hinweis darauf wäre eigentlich sehr wichtig und sollte im Leitartikel stehen: ISO 9735 - Ihr Artikel ist völlig auf die nationale Verwendung in Deutschland ausgerichtet. Die Verwendung (wie auch die Verbreitung der Leser von Wikipedia) gehen aber über eure Grenzen weit hinaus. Die verschiedenen Codierungen sollten unbedingt kommentiert werden, respektive es sollten eigentlich Tabellen sein, in denen man erkennt, in welchen EU oder weltweiten Ländern die entsprechende Coduierung überhaupt anerkannt ist oder gar verwendung findet. - Der Stand der Nutzung und die Alternativen sollten doch diskutiert werden. Beispiel: die europäische Organisation für Stromnetze (ETSO) hatte sich für den Datenaustausch für EDIFACT entschieden. Die einzelnen Länder implementieren jeder was Anderes: Frankreich: proprietäres Protokoll, Deutschland: Edifact angelehnt (edi@energy) aber nicht konsequent durchgezogen, Schweiz: im Sinne von EDIFACT, aber codiert als XML usw... - Es gibt andere, gute Beschreibungen von Standards, vielleicht können Sie sich daran orientieren? die http://en.wikipedia.org/wiki/EDIFACT enthält schon mal die erwähnten fehlenden Facts. --Cosy-ch (Diskussion) 11:09, 30. Okt. 2012 (CET)

Siehe auch

• ANSI ASC X12
• DTAUS
• EANCOM
• ebXML
• EDIFICE
• Electronic Data Interchange
• Odette
• VDA
• X.400

Warum soll sich der Leser die alle ansehen? Nach welchem System sind die asssoziativen Verweise ausgewählt und sortiert? --Siehe-auch-Löscher (Diskussion) 13:23, 27. Jun. 2013 (CEST)

Datenformat, allgemeines

Seit Spezial:Diff/128183013/prev ist dieser Satz kaputt, weshalb ich ihn analog zur Vorversion korrgiert habe:

„Mit dem sogenannten Mappingtabellen erzeugt werden, die dem Konverter zugeführt werden.“

In anderen Bereichen dieser Enzyklopädie hätten die entsprechend geneigeten Benutzer_innen den Artikel wegen mangelnder Bequellung wahrscheinlich schon schnellgelöscht... --87.169.116.234 17:55, 19. Dez. 2015 (CET)

Codierung

Irgendwie fehlt für mich etwas ganz Wichtiges - die Codierung. Bei Beispiel sind etliche Zeichen aufgeführt. Daraus vermute ich, dass es ein Textformat ist. Falls ja aber welches? ASCII, ANSI, UTF-x? Freimatz (Diskussion) 18:01, 29. Nov. 2017 (CET)

Die Codierung ergibt sich aus dem definierten "Syntax Identifier", also UNOA, UNOB, UNOC, ..., und der gewählten "Syntax Versions Number", beide im ersten Element des UNB Segmentes zu finden. Die letzt-genannte Syntax Versions Nummer hat hier eigentlich mWn nur Auswirkungen auf die "Service Segmente", also UNB, UNH usw. Z.B scheint bei Version 1 hier die "Message Version Number" und "Message Release Number" (beide im UNH Segment zu finden) auf nummerische Werte beschränkt zu sein, wohingegen ab Version 2 bis 4 diese alpha-nummerisch sind (also D:96A zB). Gerade mit Version 4 kamen ein paar neue Service Segmente hinzu, zB UGH, UGT, UIB, UIH, ..., die entweder der "anti-collision" bzw. der "interactivity" dienen sollen.

Version 1: https://www.gefeg.com/jswg/v3/data/v1-9735.pdf Version 2: https://www.gefeg.com/jswg/v3/data/v2-9735.pdf Version 3: https://www.gefeg.com/jswg/v3/data/1992_amd1.htm Version 4: https://www.gefeg.com/jswg/v4/data/v4-9735-1.pdf

Bis einschließlich Version 2 wird bei der Codierung nur UNOA und UNOB unterstützt. UNOA erlaubt hier eigentlich nur einige wenige ausgewählte Zeichen aus dem IOS-646 Zeichensatz, u.a. 0-9, und A-Z jedoch KEINE (!) Kleinbuchstaben! Diese finden sich jedoch in UNOB wieder, welches auch lediglich ein Subset von ISO-646 darstellt, und noch ein paar mehr. Mit Version 3 kamen dann UNOC, UNOD, ... hinzu die jeweils eigene Character-Encodings definieren. So ist zB im zentraleuropäischen Raum UNOC sehr stark verbreitet, das den ISO-8859-1 (Latin1) Zeichensatz verwendet. UNOD verwendet hier ISO-8859-2 (Latin1) usw. (vgl. https://www.gefeg.com/jswg/v3/data/1992_amd1.htm). Mittlerweile scheint es aber deutlich mehr "etablierte" Syntax Identifier zu geben, zB UNOW für UTF-8, UNOY für UTF-32 (vgl. https://www.gs1.org/docs/EDI/eancom/2012/ean02s4/part1/part1_05.htm), UCS2 (quasi UTF-16), UCS4, KECA für 2-4 byte variable Symbole die hauptsächlich Koreanische Schriftzeichen darstellen. (nicht signierter Beitrag von 84.114.16.39 (Diskussion) 01:31, 28. Apr. 2021 (CEST))