[Gnue] RE: [xbrl-public] What is EDIFACT GL

[Todd Boyle]

Gentlemen,

I will argue that EDIFACT GL is irrelevant to SMBs except to
the extent it influences ebXML and XBRL GL.  XML applications
are far better than EDI for accounting application integration,
for so many reasons they hardly bear repeating: readability
of the messages, ease of application development, far better
tools, namespaces, registries, repositories, linking and pointing,
transformations, -in a word, cost/benefit.

Nobody should be persuaded otherwise for an instant.  You may skip
what follows, it is just explanatory.

  - - -

It is a fact of history that EDI did not reach small and medium
businesses in the US.  EDI professionals lacked a business model
to bring EDI to the SMB.  Viewed from the SMB, you might say,
EDI was too costly and/or it did not provide a benefit.

Today, the internet and web industry is in the process of bringing
cheap solutions to small business, enabling SMBs to conduct business.
Still, EDI is not performing that service, or competing, to bring
solutions to SMBs.

It is quite analogous to the 1980s when unix was objectively better
than DOS, but unix vendors simply did not bring to market, practical
solutions that compared with DOS.  There are many other examples of
this phenomenon, in which mature industries had only themselves to
blame, as new providers entered their markets.  The collective
behavior of the EDI industry, and for example, the RDBMS industry,
resembles the behavior of cartels.  Being the only providers,
collectively, equilibrium prices settled at artificially high
levels, weakening demand, causing a moral sloth in the industry,
and attracting a profusion of alternatives.

Therefore, regardless of the protestations of EDI vendors or
professional bodies, the web industry is in the process of taking
over the business (or should I say, providing solutions for the
first time) to the SMB segment of the economy.  This is obvious.

Now it just happens the web industry does not use EDI.  It uses HTML
pages with credit cards (Ughh :-(    But, for its just emerging
integrations, it uses XML.

EDI grandfathers scratch their chins and say, "XML is just beginning a
long road... it has no vocabulary, etc. "   Yes, that's right.  So,
ebXML draws upon EDIFACT as quite a useful resource.

> UN-EDIFACT rules and vocabulary are not very simple, but certainly not
> more difficult than Chinese; and consider more than 1.000.000.000
> people do speak Chinese. UN_EDIFACT IS AN ISO standard. The rules are
> available for free at your national standards organisation DISA or at
> UN/CEFACT.

The above is perfectly irrelevant.  The small business segment in the
US is not interested in UN-EDIFACT.  (Please don't shoot the
messenger.) And Robert, you are perfectly aware XML supports Chinese.

The mere existence of 1 billion Chinese anyways, adds nothing to the
credentials of ISO or EDIFACT, since virtually none of the Chinese use
EDI.  If EDI exists in China it is similar to the West, in that it
strengthens the state, and the largest industries usually protected,
thus favoring statism over individual enterprise.


> Moreover, about accounting messages, before the submission of our
> messages to UN approval, we have proposed to national accounting
> bodies to participate to our works. Those who want to use our messages
> have written their MiG(s) - Message Implementation Guidelines - in
> their own language, unfortunately one of those numerous ones that you
> don't know and you don't care.

I would like to point out that none of the English speaking accountancy
bodies has been so kind as to publish any migs containing the word
ENTREC on the internet.  I have spent half the day yesterday, among
many other sessions, searching for these fabled texts.  You are
aware that ALtavista, northernlight, google, etc. index countless
billions of pages ---- and nowhere is there a single document of
these MIGs and ENTREC.   This makes me doubt the credibility and utility
of these, MIGs anyway.


> Gentlemen,
>
> With his messaging prolixity, Todd is creating confusion between EDI
> methodology (electronic data interchange) and EDI syntaxes such as
> UN-EDIFACT, ANSI-X12, etc. EDI methodology is related to data
> communication (and processability) from computer application to
> computer application.
>
> I expect XBRL is intending to use XML syntax for EDI as well, in a
> machine to machine application process. If it is only oriented towards
> human-to-machine or machine-to-human approach, it will not to be that
> successful.
>
> Todd is probably joking when he says:
>
> > Click on ENTREC Accounting entries message, which takes you to
> > http://www.unece.org/trade/untdid/d00a/trmd/entrec_c.htm
> > And you will see that the accounting entries seem to have
> > a rigorously defined EDI header which is universally used
> > in EDI, plus a rich network of 9 segment sections, with
> > hierarchies of 3-character codes which only a few levels are
> > apparent on this ENTREC document.  The documentation for
> > the data elements continues on other documents, which then
> > continue endlessly connected to other EDIFACT documents.
>
> The way you are presenting EDIFACT is just utterly ridiculous.
>
> Are you seriously saying SMEs will be able to get total control on XML
> syntax ? On the other hand, are you prepared to learn Greek, Chinese,
> Russian or any other language spoken in this world just looking at a
> couple of pages in a dictionary ???
>
> In other words, paraphrasing your own words: "Dear Russian learning
> person who already knows Russian: Congratulations, You got the right
> page ! Here is a word to say this. Make a meaningful sentence with it.
> Good Bye."
>
> Forgive me, I am certainly wrong being just a European, even not
> native English trying to speak more or less other languages than my
> own; For sure, you don't need to know any other language than American
> English, do you ?
>
> UN-EDIFACT rules and vocabulary are not very simple, but certainly not
> more difficult than Chinese; and consider more than 1.000.000.000
> people do speak Chinese. UN_EDIFACT IS AN ISO standard. The rules are
> available for free at your national standards organisation DISA or at
> UN/CEFACT.
>
> Moreover, about accounting messages, before the submission of our
> messages to UN approval, we have proposed to national accounting
> bodies to participate to our works. Those who want to use our messages
> have written their MiG(s) - Message Implementation Guidelines - in
> their own language, unfortunately one of those numerous ones that you
> don't know and you don't care.
>
> We have also proposed to educate trainers for those who had the
> feeling to get lost in the EDIFACT stuff.
>
> I come back to the language itself: UN-EDIFACT is a very powerful and
> rich tool that enables computers to talk together all over the world
> since more than a decade.
>
> Proof XML has been as effective than just the very beginning of the
> begin of EDI (X12, UN-EDIFACT, EAN, ... I don't care).
>
> UN-EDIFACT  is just like a natural language : it is about syntax and
> words (semantics!!!) to be put together in order to express something
> that is comprehensive on both parties: the one who is saying or
> writing as well as the one who is reading or listening.
>
> A sentence is a sequence of words (article, noun(s), verb, etc.) that
> are arranged in conformance with semantics and grammatical
> construction rules. In american english, like in other languages you
> need to know words and their semantical meaning from a dictionary and
> at the same time to be able to apply the grammar rules to be able to
> say or write a comprehensive sentence.
>
> UN-EDIFACT is that kind of dictionary for computer-to-computer
> application; in fact a nest of dictionaries that are:
>
> - messages dictionary
> - segments dictionary
> - composite and elementary data
> - list of codes to be used for some elementary data
>
> A sentence in EDIFACT wording is a "message".
>
> The components to be used for such a sentence (message) are: -
> segments that are core elements of the message that your computer
> application programme wants to address to another computer application
> programme; it is equivalent to a main, subordinate or relative
> grammatical clause within a sentence in your native language;
>
> After the TAG identifyer of the segment, the sequence of the
> components in the segment is fix; the data itself is positionally
> self-defined by a separator with respect to the content of a standard
> segment; data that are optional may be ommitted using consecutive
> separators; - data elements (identified by a code) that are similar to
> a single word - qualifyers that are necessary to bring a precise
> meaning to the data element (list of codes devoted to one data
> element); A segment is identified with a mnemonic TAG that is three
> alphabetical characters long (i.e. "MOA" for "Monetary Amount")
>
> For an accounting entry, a monetary amount (segment tag "MOA") is for
> sure one of the requested (madatory) core elements;
>
> The MOA segment in the UNSM repository looks like this:
>
> =====================================================
> MOA   Monetary amount: To specify a monetary amount
>
>       C516    Monetary amount
>
> 5025  Monetary amount type code qualifier     an..3 (alpha-num - up to 3
characters)
> 5004  Monetary amount                         n..35 (num. up to 35 digits)
> 6345  Code specifying a monetary unit         an..3 (USE ISO 4217 code table)
> 6343  Currency type qualifier                 an..3
> 4405  Status description code                 an..3
> ======================================================

Currency type qualifiers are not needed within a small
business general ledger. We don't think that way.  When we
have an invoice amount, it is stored someplace logically
nearby the invoice and it just says "amount".  We don't
put an "Amount" in a document, and a currency, and store
within an attribute of the currency that, Oh, this is the
amount, having currency dollars, having currency type
"invoicing".  Maybe mainframes?

Status descriptions are a messaging subsystem problem or
automation implementation problem.

An XML spec for General Ledger should eschew any automation
integration or messaging roles anyway.  A general ledger record
is not a "computer thing" or a "telecommunications thing".  It
is a static document which memorializes the fact of a transaction
event, or other economic event.   It is the economic character of
the event which is important for XML for General ledger.  ENTREC and
other EDI structures are quite weak at this overriding requirement.

> To forward the information that the amount "100.000" "Canadian $" for
> an "unsigned" "invoicing amount" for an "accounting entry", the
> development of the corresponding MOA segment will look like this:
>
> MOA+376:100000:USD:4:66'
>
> Just compare with XML...
>
> - the data element # 5025 in the MOA segment is used to qualify the
> type of "monetary amount"; from the code list related to 5025, the
> coded value "376" means the amount is for "an accounting entry
> amount";
>
> - the data element # 6343 Currency type qualifier from the code list
> related to 6343, code value '4' says the monetary amount is for the
> invoicing currency
>
> - the data element # 6345 Code specifying a monetary unit, code ISO
> "CAD"
>
> - the data element # 4405 Status description code from the code list
> related to 4405, code value '66' means the amount in the current MOA
> segment is unsigned.
>
> In the UN-EDIFACT D14 subgroup, we have identified which are the core
> elements for any kind of accounting entries.
>
> It is what is in the "ENTREC" message. We hope it should be valid for
> the UN community. If it is proved not to be the case, changes are
> allways possible.
>
> eb-XML is the common initative between UN and OASIS. It is stated in
> the goals of the "core components" project team, they are tasked to
> preserve investments achieved in EDI and learn from EDI expertise.
>
> On provision those goals are met, we are ready to examine how to
> particiate in a project with another syntax (for instance XML).
>
> On the contrary, if XBRL is going its own way without taking care on
> what happened so far somewhere else, XBRL/GL will be one among the
> numerous dialects referring to DCEA.
>
> EDI is not yet dead and the future will tell us if XML is "THE
> standard" or if it will suffer of a drift turning towards IBM-XML,
> SUN-XML, MS-XML, ... anybody-XML. Remember UNIX, AIX, SINIX, etc.

Nobody in ebXML or active in ecommerce believes EDI is "dead".  It
has rather stopped growing and spreading, but seems to serve well
enough where it's been installed.  The vocabulary accomplishments in
B2B and A2A integration are useful and are the foundation of ebXML Core.

Regarding XML, yes the very definition of XML is undergoing continual
change but the big companies you mention are converging XML, not fragmenting
it.  The fracture line is that XML schema, SOAP, XSLT and other basic
standards are being defined in ways that serve the interests of these
big 4 or 5 software companies at the expense of small business and often,
larger enterprises as well.

If there is a fragmentation problem, it is the diversity of XML
applications in hundreds of nominally "separate" domains (HR, medical,
insurance, manufacturing, etc.) without coordination with other
domains that obviously interoperate.  ebXML is addressing that.  There
will be registries and repositories to resolve interoperability
issues.  over time, quite naturally vocabularies will tend to
converge nicely.

> Just continue with the other segments of ENTREC and you will get the
> complete set of the building blocks that are needed, (not
> always)requested for an accounting entry. What XBRL/GL should check is
> whether those core elements are valid and how to produce a
> corresponding DTD or schema (maybe several subsets because, as you
> said, small business does not need the same level of information than
> General Motros) .
>
> On the contrary of XBRL for reporting language, that is naturally
> attached to national GAAP, accounting entry schema should be
> universal.
>
> When I will buy something on the Net, I need to get the requested
> information for my GL/accounting entry in accordance to accounting
> regulations and legislation in my country. Not what is applicable in
> the US.

XBRL is designed to support multiple nations' GAAP taxonomies.
Are you referring to the rootledgerXML schema?  It also is GAAP
agnostic, it has an XBRL type and XBRL taxonomy on each row.

Nobody round here is going to build solutions limited to the US.
We need to harness the clerical and manual labor forces,
throughout the world so that we can maintain our US hegemony!

Feelin better yet?  :-)

> So just consider what was done earlier at the United Nations level for
> facilitation of trading procedures, where we try to put together the
> requirements in the UN-member states. Also for accounting entry.
>
> Robert Lemense
> UN-EWG / D14 Chair

I remain of the conviction that the General Ledger application, and
XML schema, is primarily a descriptive application.  The primary
requirements and purpose of a General Ledger are fiscal control,
management of cash and other assets and liabilities, management
tax, and statutory reporting, consolidations.  The EDIFACT messages
may indeed be capable of unambigously communicating transactions,
but so is morse code, the spoken word, or paper documents.  Why
do I raise these provocative examples?  To illustrate that the design
of XML schema for general ledger must be driven by practical
economic issues such as the following

1. backward and forward compatible to as many small software
packages as possible, not just huge global corporations EDI systems,

2. as easily understood as possible by as many domain experts
as possible (Not software or systems developers but accountants)

3. as rich as possible in legal, tax, and business meaning,

4. as platform neutral as possible, to avoid software lock-in
and prevent favoring any vendor over another,

All that kind of stuff.

TOdd

* Todd F. Boyle CPA    http://www.GLDialtone.com/
* address@hidden    Kirkland WA    (425) 827-3107
* XML accounting, web ledgers, BSPs, ASPs, whatever it takes