gnue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue] GL requirements for integration


From: Todd Boyle
Subject: [Gnue] GL requirements for integration
Date: Wed, 20 Sep 2000 10:02:05 -0700

Chad "^chewie" Walstrom <address@hidden said
>Todd said
> > I will argue that EDIFACT GL is irrelevant to SMBs except to
> > the extent it influences ebXML and XBRL GL.  
> 
> Um...  I worked for a company for over a year that would be considered
> a small business that was FORCED to use EDI, EDIFACT or X.12 with
> large companies.  They were a manufacturing OEM supplier, and in order
> to please the customer, we had to pay into a proprietary service
> network to lease software and network access.  Yeah, there is need for
> EDIFACT/X.12 EDI for small businesses.  To say otherwise is to choose
> to be naieve.  I'm sorry, to say it so, but you've been arguing this
> for the last year and it's still falling on deaf ears, but what you're
> preaching IS NOT IN THE REAL WORLD.

If you would kindly read my comment more carefully!  

The issue is EDI as a *General Ledger standard*, not EDI itself.
EDI interfaces should take their place among all the other business 
applications that generate GL data.  It must be accommodated.

EDI data is great, but it's just another peculiar data format, 
and a very minor one in the SMB's long requirements list.  It
is YOU who are not in the real world, if you advocate EDI ENTREC
and CHACCO as a foundation or organizing principle for small
business general ledger data.  SMBs requirements for integration 
begin with the Intuit Quickbooks, and descends thru all the 
Peachtree and MYOB and DACeasy thru the midrange, and of course 
the SMBXML and other BSP formats, now.   Requirements include
multicompany and international issues (currencies, languages
and GAAP)

There is a compelling business need for a common general ledger
format, which enables SMBs to choose among best of breed solutions
for their needs, with some minimal integration to achieve fiscal
control, cash managment etc. and you're right, this often falls on
deaf ears.

It would be NUTS to model the general ledger XML schema around 
EDI GL.  It's never going to happen.  If XBRL or ebXML goes in
that direction SMBs certainly won't follow.  EDI sucks major
rocks, and had 20 years to help small business, the EDI attitude
was let them eat cake.  Now that XML developers are helping us,
EDI titans stride petulently into all the forums dishing out
condescending advice --I have been in public accounting 20 years and
worked in global corp. accounting, 6 years in Big 5 firms, etc.
and I am not intimidated by these EDI bureaucrats.  They can 
just take a number, and get inline behind Intuit and Peachtree
and NetLedger, for general ledger interfaces.

Now that you have taken your potshots, what is your overall
solution or philosophy of a GL, anyway?  

What is a GL?
What should be the boundaries of a GL? 
Should a GL such as GNUE GL have dependencies on a particular
  set of business applications?
What is your proposal for an XML schema for GL? 
Should a GL be a hierarchic object structure or a flat CDEA?
Is a GL primarily a data backplane for developers, to integrate
 business systems, which only incidentally, supports a CDEA GUI
 and reporting? 

OK, I'm honestly not trying to be provocative-- What is your 
vision of a general ledger?   Drawing on your experience in
the REAL WORLD.

Todd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]