[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnue] Re: [xbrl-public] What is EDIFACT GL
From: |
Robert Lemense |
Subject: |
[Gnue] Re: [xbrl-public] What is EDIFACT GL |
Date: |
Tue, 19 Sep 2000 18:02:43 -0700 |
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
- [Gnue] RE: [xbrl-public] Requesting an official report on GL schema, Coffin, Zachary P, 2000/09/18
- Re: [Gnue] RE: [xbrl-public] Requesting an official report on GL schema, vio, 2000/09/18
- [Gnue] What is EDIFACT GL, Todd Boyle, 2000/09/18
- [Gnue] Re: [xbrl-public] What is EDIFACT GL,
Robert Lemense <=
- [Gnue] RE: [xbrl-public] What is EDIFACT GL, Todd Boyle, 2000/09/20
- Re: [Gnue] RE: [xbrl-public] What is EDIFACT GL, ^chewie, 2000/09/20
- [Gnue] GL requirements for integration, Todd Boyle, 2000/09/20
- Re: [Gnue] GL requirements for integration, ^chewie, 2000/09/20
- GLR, GLT, and the memory array GL, Todd Boyle, 2000/09/22
- Re: GLR, GLT, and the memory array GL, Derek Neighbors, 2000/09/22
Re: [Gnue] RE: [xbrl-public] Requesting an official report on GL schema, Derek A. Neighbors, 2000/09/18