gnue
[Top][All Lists]
Advanced

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

[Gnue] Architecture suggestion for the GL table


From: Todd Boyle
Subject: [Gnue] Architecture suggestion for the GL table
Date: Mon, 18 Sep 2000 12:25:32 -0700

Derek A. Neighbors said Sunday, September 17, 2000
>Duncan said,
> > I had a subsidiary in Brazil that had complex requirements ACCPAC
> > just could not handle in it's G/L - and ACCPACs ledger is more
> > comprehensive/rich than your proposal .  I think you have some
> > fundamental assumptions that need review.  These are:
>
> This is why most standards fail.  They are either too encompassing or
> too vague.  Those that are very complex dont get used.  Those that are
> simple get customized to where biz2biz partners can do business, but
> customization is needed everytime a new player steps to the table.  EDI
> is a perfect example of such silliness.

Dear Developers:

I do not share these pessimistic outlooks, which disempower the
small business.

Contrary to popular belief, there is very substantial equality
or equivalence among accounting and business applications' naming
and usage of fields.  Note I did not say "Total" or "unambiguous".
But there is such overwhelming similarity that porting a transaction
set between general ledger packages, or online webledgers, is
quite a reasonable prospect and would extend up into the sales
and purchases and other business modules with some degree of
success.

Have a look at these threads.  Search deja,
keywords "FBW" newsgroup "alt.accounting"
http://www.deja.com/[ST_rn=ps]/qs.xp?ST=PS&svcclass=dnyr&firstsearch=yes&pre
serve=1&QRY=fbw&defaultOp=AND&DBS=1&subjects=&OP=dnquery.xp&LNG=english&grou
ps=alt.accounting&authors=&fromdate=&todate=&showsort=score&maxhits=25

The software application I am designing ("RootLedger") will have a GUI
and an API, with limited functions, in V. 1.0.  It will be a
high performance software application which maintains a flatfile
GeneralLedger in an array in memory.  (No big deal, you could write this
in a week.)

The "RootLedger" application will have columns (fields) defined in
http://www.gldialtone.com/rootledgerXML.htm which is just a collection
of every field I could find in the small and midrange accounting
platforms.

Most companies know what fields they need.  The RootLedger application
will implement subsets of rootledgerXML fields when it initializes
(rather than the whole 86 columns) by reference to RootLedger.cfg
configuration file.   It may load persistent ledger data from data
files upon initiating.

Functions will include:

Import or Export a rootledger ASCII file or stream
   in space-delimited ASCII format
   in comma-delimited format
   in xxx format

Import/Export XML files or streams
   in rootledgerXML format
   in OAGIS 6.2 PostJournal XML format
   in SMBXML format
   in FastXML format

Import/Export to Peachtree 8.0 format
   in comma-delimited format
   or using PAWCOM DLL

Import a Quickbooks company
   using Datablox DLL

All of these functions will have options to

 - sort by various collections of columns,
 - filter for expressions in various columns, and
 - group by various columns.  i.e. generate sums by account, etc.

All import functions will impose constraints

 - transaction deck must balance; transactions must balance.
 - future versions may maintain Charts of Accounts and other
    structures and constraints.


Note that this application is nothing less than a General Ledger back
end for any arbitrary collection of business modules. It will scream,
having all data in RAM.  It will persist its CDEA transaction rows to
disk in rootledgerXML format or any other supported format, whenever
instructed by its API or GUI.   The "Disk" can be local, on a LAN, on
an internet host, or on FreeNet or MojoNation.

Note that this application is the foundation of the FBW, the FileBased
Webledger client which will enable exchange
http://www.gldialtone.com/FBWspec.htm of commerce documents on
FreeNets.

An immediate use case for this software application is:

Step 1:  crack your data out of those lock-in accounting platforms.
Step 2:  upload it to a decent webledger host someplace.
Step 3:  start conducting business on the internet
Step 4:  keep conducting business with the local GL, too.
Step 5:  download your transaction decks from your webledger
   and BSPs and local applications, to maintain your consolidated
   view on your own root ledger.  Update your views as often
   as necessary to maintain fiscal control over the service
   providers or local operations.

The eventual goal is multi-party webledger architecture that
enables submission of intercompany journals or transactions,
conducting business in more flexible, immediate ways without
the fees and interruptions caused by banks or other intermediaries.

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



reply via email to

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