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

[Robert Lemense]

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
======================================================

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.

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.
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

===============================

Todd Boyle wrote:
> 
> -------------------------- eGroups Sponsor -------------------------~-~>
> NetLedger is the online solution for small business.
> >From payroll to inventory, you get the tools you need to run your
> business totally online. Try it FREE for 30 days!
> http://click.egroups.com/1/9014/0/_/794493/_/969329557/
> ---------------------------------------------------------------------_->
> 
> Zack Coffin (XBRL Liaison) said,
> >
> > Frankly... we are at the early stages of working on XBRL G/L.  So, in
> > short, we don't have any answers for you.  It's a work in progress.
> > That said, I am particularly keen on leveraging the very good work of
> > EDIFACT G/L in Europe, and we are pursuing this angle as a starting
> > point.
> 
> The EDIFACT GL messages are certainly a puzzle.  There is nothing
> on the internet that explains them in plain english-- no tutorials,
> no context, etc.   Whatever exists is aimed TOTALLY at the EDI
> community.  In other words, all documentation says "Dear EDI person
> who already knows EDI:  Here is a message format for sending GL
> transactions.  Good Bye."
> 
>   CHACCO   chart of accounts
>   ENTREC   accounting entries
>   BALANC   to transmit trial balances
>   LEDGER   to transmit part or the complete Ledger.
> 
> See http://www.unece.org/trade/untdid/d00a/content.htm and click
>  [Message types by name]  This will take you to
> http://www.unece.org/trade/untdid/d00a/trmd/trmdi2.htm
> 
> 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.
> 
> In other words, you have entered Lewis Carrolls' rabbit hole,
> go ahead, click around for a few minutes.  You will pick it
> up.   It is a vast and interconnected, multidimensional,
> seamless, whole.
> 
> In case you are confused, here is a nice [BRANCHING DIAGRAM]
> http://www.gefeg.com/edifact/d00a.un/naty/mb22.htm
> 
> Here are some more reading materials.
> http://www.fee.be/hi-lites/hi03-edi.htm
> http://www.edifact-wg.org/EWG%20Subworking%20Groups/ewg_d14.htm
> http://www.edifact-wg.org/images/ewg_d17.gif
> http://www.unece.org/trade/cnnct/ref941.htm
> 
> I am finished looking at ENTREC and CHACCO etc.  I'm going back
> to work on my flatfile array general ledger, ymmv,
> 
> * Todd F. Boyle CPA    http://www.GLDialtone.com/
> * address@hidden    Kirkland WA    (425) 827-3107
> * XML accounting, web ledgers, BSPs, ASPs, whatever it takes
> 
> To Post a message, send it to:   address@hidden
> To Unsubscribe, send a blank message to: address@hidden