[Top][All Lists]
[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