RE: [Gnue] What is EDIFACT GL

[Todd Boyle]

vio said Monday, September 18, 2000

> Pardon my EDI newbie status, but how wise is it to build anything 
> based on EDI in the first place ? My understanding is that EDI is 
> currently a sinking ship, who for whatever reasons can't stand 
> the coming XML titlewave. 

separately, derek said,

> Look at EDI and the barrier to entry for EDI system and monthly VAN
> costs.  A small guy cant start in this environment.  If standards 
> are gonna help the little guy they must be of no entry cost and co 
> developed by the small guys of the world. 

EDI is far from dead or sinking; it is more efficient and smoother
than ever.  Like other platforms it has benefited continuously from
much better computers, networks, and overall skill levels in the
workforce.  It has benefited from much better EDI toolsets and 
much better general purpose software development tools, etc.

Paradoxically the small business can pickup and use EDI easier than
ever, and there are no doubt, valuable marketplaces that are more
accessible than ever through EDI.

But EDI still shows no significant prospects of linking 
28 million small businesses let alone individuals.  

It still requires a lot of professional services, and most of small 
business software are all determinedly lock-in anyway.  EDI also won't
be used for devices or wireless or SMBs webledgers and BSPs.  Maybe
it should be.   Commercial XML is fragmented, and the only scheme
to unify it is ebXML.  Their core components are heavily influenced by 
EDI vocabulary.  Like XBRL, the ebXML consensus is that EDI has achieved
a great thing by hammering out so many countless thousands of elements 
and descriptors into co-existence.

Zack is right, an EDI ledger would be just fine.  It's just another
object model.  But how far do you go, down into the rabbit hole? 
There is no dividing line between ENTREC and the entire EDI vocabulary.
So, there can't be a "standard GL schema."   To say that XBRL GL will
be coherent with ENTREC and EDIFACT is to say, it has to be integrated,
harmonized with all of global commerce.  and ebXML core components.  
If so, XBRL GL should turn out the lights, and go down the street 
and work with ebXML to create ebXML/GL.

Ultimately you deduce that any GL they can throw at us, can be
resolved into double-entry rows anyway, so who cares.  I will
continue working on the flat array GL, and map to their format 
whenever it arrives.

As you know, we are entering the era of 64Bit processors,
and everybody will have a Gig of RAM.  This argues in favor of
in-memory GLs.  Very few SMBs generate a Gig of transactions/year.
So, a completely in-memory general ledger is attractive.

The only interesting question is whether all those classic business
needs of fiscal control, cash and receivables management, 
reporting, consolidation, etc. should be an exercise within the 
enterprise' entire XML object database, or a flat array GL 
which stands on its own, which maps to whatever internal or 
external business modules may exist.  So, you already know my
opinion.

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