Talk:EDIFACT

The article is worthy, but would benefit from some information about the historical evolution of EDIFACT and its relationship to other EDI standards, and the manner in which it is maintained using twice-yearly directory issues Chrisj1948 (talk) 08:58, 23 March 2008 (UTC)

This page isn't going to mean much to people who aren't familiar with EDIFACT terminology. It doesn't help to tell people what characters a "release character" or "segment terminator" are when you don't tell people what those mean to begin with.Anphanax (talk) 00:27, 21 August 2008 (UTC)

Some citations are needed or the editorial comment about "most widely used in high tech, civil aviation, retail and tourism industries" should be removed. —Preceding unsigned comment added by 12.5.54.215 (talk) 18:39, 30 September 2008 (UTC)

EDIFACT and e-commerce

Hello, This is an open question: I imagine e-commerce when companies join a server (Internet or not) and accept some protocols that bring them the opportunity of purchase goods and services and do online payments. Is that more or less true? Thank you. —Preceding unsigned comment added by LLFT (talk • contribs) 07:42, 11 February 2009 (UTC)

Protocol Stack

I come from the computer science world and understand protocol stack like Ethernet/IP/TCP/Application...Recently involved in the industry that uses EDI and I believe it certainly has some relationship. It took me a few moments to figure out AS2 is a common way to ship EDI document (be it X12 or EDIFACT), maybe it's worthwhile to point that out and relate them together so reader can have a clear picture. Sam0737 (talk) 16:35, 17 March 2011 (UTC)

Encapsulation protocols vs. transmissions protocols

One might mention such things in an end-of-article note but one should keep in mind the distinction between data encapsulation protocoles (e.g. EDIFACT) and data transmission protocoles (e.g. AS2).

As with XML or X12, one can send EDIFACT data through whatever file-oriented transmission system one likes. As a historical note, EDIFACT was designed in the steam-engine days of digital communications nearly two decades before AS2 reared its ugly head. To put this in perspective, the original Level-A character set description mentioned apologetically that EDIFACT permitted the use of some characters which couldn't be sent through the Telex network!

Up until the mid-2000s, EDIFACT's principal medium of transfer, by volume anyway, was certainly by X400 over commercial, "value added networks". This may possibly still be the case in 2012, but the general availability of inexpensive and off-the-shelf alternatives like FTP or e-mail have diverted a huge portion of the messages (interchanges in EDIFACT parlance) away from X400, which requires specialized software whose use is definitely not for the casual or non-technical user.

EDIFACT and X400 were developed more or less concomitantly and I think EDIFACT's design was influenced by the constraints and costs of X400 and the low transmission speeds available at the time... 9600 bps would have been quite zippy! There is often a fairly limited maximum file size for an X400 message - two or three megabytes is not uncommon - and the value-added networks were (and still are!) quite expensive. EDIFACT attempts to economize the resultant file size down to the level of single bytes. For example, "2" is valid, "2." is not; "NAD+CZ+123'" is valid, "NAD+CZ+123++++++'" is not; leading zeroes and trailing spaces are in most cases banned; it's effectively a "delimited" format which minimizes the space required for dealing with missing data.

Returning to Sam0737's suggestion, it depends what the objective of the article is. If the EDIFACT entry is intended to describe the syntax or the methodology of the language (those are two disctinct points), it doesn't seem useful to go beyond mentioning the fact there are no constraints on the choice of the transmission or messaging protocol used for sending EDIFACT data. Sam0737's idea would, however, be appropriate in an article about common uses of EDIFACT.

80.12.81.14 (talk) 18:06, 28 October 2012 (UTC)Jamie in Paris

Gzip compression

WritersBlok claims that most data transmission takes place using Gzip compression. Could he provide some justification for this, since to my knowledge most EDI transfer occurs over VAN's, which do not use compression for data transfer? Chrisj1948 (talk) 11:43, 4 February 2012 (UTC)

UNA Syntax

The description of the UNA services characters is not quite right in regard to the third byte, the "decimal mark" character. (And it's out of date in respect to the 5th byte, formerly reserved and to be specified as a space but now used for indicating repetition... I haven't enough experience to comment on the latter.)

The decimal mark has often been a source of confusion, partly due to an initial choice of the comma (",") as the default when a UNA segment is not supplied. Some people might think this a somewhat unnatural choice when one considers common use in most computer languages and operating systems, but that is how it was defined by ISO 9735 Version 4 First Edition, apparently inspired by a now-defunct earlier recommendation, ISO 31/0-1981. See section 10.1 of the former document which in summary declares "if there's a UNA, use its specified decimal mark; if there isn't, use the comma."

With the release of ISO 9735 Version 4 Second Edition, this is no longer the case. No default value is now given for the decimal mark in the table of default service characters (section 5.2), Annex A specifies that this position in the UNA should be ignored, and section 10 now reads, "the full stop or the comma is allowed to represent the decimal mark for a single numerical value."

Since the CEFACT documentation is diffuse, obsure, and tedious reading, confusion about UNA usage has never been unusual... in my experience few EDIFACT message implementors start from first principles or have ever read the original documentation. (I suppose that's a blessing of sorts since otherwise EDIFACT would have gone the way of Esperato). I imagine that with the Second Edition in 2002, the CEFACT folks simply decided to end the confusion by declaring that henceforth, commas and decimal points will always be acceptable in numeric data in all circumstances... one must accept both and there's no longer a way to invalidate one or the other.

And everybody shall have prizes... ;)

80.12.81.14 (talk) 18:11, 28 October 2012 (UTC)Jamie in Paris

Alas, confusion abates not. Since there's been no dissention to my previous posting, I've changed the text. Too bad none of the CEFACT folks seem to take an interest in this page. 19:54, 1 April 2015 (UTC) Jamie in Paris — Preceding unsigned comment added by 80.12.81.14 (talk)

References

What is it good for?

Currently, this article only provides a technical and abstract description of EDIFACT. It doesn't show use cases of EDIFACT, i.e. the article doesn't show what EDIFACT is good for. A "real world" example could already clarify EDIFACT's purpose. --Abdull (talk) 13:33, 31 July 2013 (UTC)

component, composite, data element

I am really confused by the explanations which data separators are for which elements. The text says:

• component data element separator (: in this sample)
• data element separator (+ in this sample)

Should the first line mean "composite data element separator"? But then this would be "+", not ":" - in the following paragraph it describes it like:

"The component data element separator and data element separator are the "first level" and "second level" separators of data elements within a message segment. Referring to them as + and : for brevity [...]" - Here the order is the other way round.

Which one is "higher" in the hierarchy? This is really complicated to understand - in the second sentence "Referring to them as + and : for brevity..." the order should be switched: "Referring to them as : and + for brevity..." - then it would be a bit clearer - is this correct? Ddroetker (talk) 19:57, 13 May 2017 (UTC)

Example - How is UNT calculated?

The wiki-page says: "UNT+13+1' - This is the message trailer segment. It indicated that the message sent contains 13 segments"

But why 13? The whole example seems to have 16 segments and there seem to be 11 user data segments. Which segments are actually used for the UNT segment count? — Preceding unsigned comment added by Geeky de (talk • contribs) 19:38, 24 March 2018 (UTC)

The segment count in the UNT segment is for the total number of segments in the message, which includes the UNH message start segment and the UNT itself. The other 3 segments are for the interchange (envelope). An interchange can contain many messages. Chrisj1948 (talk) —Preceding undated comment added 09:06, 26 March 2018 (UTC)

Message sample

If the text below the sample is true, then the initial : in the sample message should also be colored red, as it does not yet have meaning in the context of the message. Given the way it is formatted, this may be difficult, so it may make sense to use a non-default delineator for the sample. If this would cause further uses of the delineator to be colored red, then this is an issue with the method used to format the example and should be fixed.

167.103.29.82 (talk) 00:48, 2 February 2024 (UTC)