OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Comments on XBRL draft General Ledger schema


The XBRL website announces the first drafts of the XBRL schema for
General Ledger data at http://www.xbrl.org, and invites comments. 

The overall structure of the XBRL GL draft has three tiers, or levels, 
which is a good thing.  There are very few publicly available GL schemas 
in the world.  But the ones that exist generally have three-tier 
structures just as does the XBRL GL draft structure,

   accountingEntry contains entryHeader, contains entryDetail.  

The OMG's General Ledger facility also has three tiers. 

   ledger contains transaction, contains entry.

We believe the OAGIS Postjournal GL schema also represents the same
three tier information model, although they are flattened into the 
POST_JOURNAL structure:

   LEDGER contains JEHEADER, contains JELINE.

The UN/CEFACT EDIFACT messages for general ledger data include ENTREC 
and LEDGER.  EDIFACT is intended to be universal, and provides a large 
number of alternative message structures to be used by two endpoints.  

The ENTREC and LEDGER messages are similar to all of the above schemas 
in that they require accounting line entries ("LIN" segments) to be 
owned, or organized, within transaction headers ("IND" segments), and 
these parent-child transactions are contained in a container with other 
information about the company and ledger.  The information preceding 
EDIFACT GL header-row transaction sets, such as a journal identifier 
("RJL segment") is analogous to the root element in XBRL GL, therefore 
you have something like

   RJL (journal) contains IND (index) contains LIN (line items).

In conclusion these publicly available GL schemas or specifications all 
have equivalent structure.  Names should be registered for these things as 
ebXML core components.  The accounting community should work hard to 
develop a consensus and communicate it to the EWG on appropriate naming 
for core components for these three tiers of data within the general 
ledger information model.

In our opinion, general ledger entries for real 3rd party transactions 
are almost entirely composed of the same ebXML core components as the 
data elements within the native transaction such as invoice, order, ship 
notice, payment, etc.  This includes datetime, amount, products, 
parties, organizational structure, location, etc. etc.  The accounting 
community will not have the freedom to define these in the registry of 
core components.  They are native transaction attributes, and they are 
owned by the entire business community.  

What is needed, but not yet done, is to define core components for GL 
itself.  OMG, OAG, UN/CEFACT, and now XBRL, should agree on the same 
names for the headers, rows and for the "container" of headers and rows.  
These enable the assembly of GL entries as documents, under ebXML 
assembly rules, and transformation of all transaction documents into and 
out of general ledgers. This is crucial to using ebXML messaging and BP
choreography for A2A integration inside the firm. 

Names should be registered for these things as ebXML core components
by EWG http://www.edifact-wg.org/

There are two steps.

1. The accounting community should participate vocally, here and on EWG, 
in the conceptual necessity for three-tiered structure of a GL (which I 
advocate, and agree with XBRL about.)  This is a classic ISO 11179 
question.  ISO 11179 uses syntax neutral identifiers for concepts, to
avoid the divisive problems of language and naming.  Review of the
existing GL schemas demonstrates that conceptual agreement already
exists for the meaning and usage of three tiered structure of GL data. 

2. The accounting community should then participate in agreeing on 
naming of the three tiers of general ledger information.  In my view, 
the responsible representatives from each of the standards organizations ,
OMG FDTF, OAG, UN/CEFACT D14 and XBRL having existing GL schemas 
should also participate in the determination of common naming, and sunset 
their disparate naming of these obvious things.

Our suggestion for naming ebXML core components for general ledgers, the 
common intellectual property of all of the global GL user community, 
would begin with GL:

   GLTransactionSet  contains  GLTransaction  contains  GLEntry

This GL-prefixed naming will help future users find these elements in 
dictionaries and registries, and differentiate these GL components from 
other very similar-named "transaction" and "entry" vocabulary which will 
be needed by many other communities.  The names of ebXML core components 
are unique, and once assigned cannot easily be changed.

Establishing clear naming that is usable in multiple contexts is quite 
valuable. The same terms can be used in some of our human readable 
runtime and user interfaces as well as at designtime and in software 
objects, IDL, Java, scripting languages such as perl, python, etc.  This 
will improve the speed we can automate bookkeeping which is so badly 
needed. 

We humbly submit draft definitions below.  

Thank you for your consideration.

Morten Jacobsen
Executive Vice President Next Gen. Services
Netaccount AS, Norway
www.netaccount.com
morten@netaccount.com
+47 9822 7310

Todd Boyle CPA
Functional architect, Netaccount AS, Oslo, NO
www.netaccount.com  www.arapxml.net  www.gldialtone.com


================ SUGGESTED EBXML CORE COMPONENT DEFINITIONS:


GLEntry -- a monetary value assigned to a specific economic resource, in 
an arms-length exchange between two or more parties at a specific date 
and time, together with any collection of additional data elements 
pertaining to the GLEntry.

GLTransaction -- a balanced set of 2 or more instances of GLEntry, 
together with any collection of additional data elements pertaining to 
all GLEntry instances in the GLTransaction.

GLTransactionSet -- a collection of GLTransaction elements, together 
with any collection of additional data elements pertaining to all 
GLTransaction instances in the GLTransactionSet. 

============ MORE ELEMENTS THAT APPEAR TO BE NECESSARY,
=====AND MIGHT AS WELL GO INTO THE FIRST BATCH OF CORE COMPONENTS:

GLAccount -- an identifier which uniquely associates or classifies
one GLEntry with one corresponding account in the chart of accounts,
i.e. with one line in an accounting trial balance.

generalLedger -- a set of 1 or more GLTransactionSet elements.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC