From: Todd Boyle [tboyle@rosehill.net] Sent: Saturday, April 15, 2000 11:47 AM To: dunwin; kontor_en@ios-online.de Cc: Gnu E Subject: RE: General Ledger for Linux Kontor & GNUE Hi Dunwin -- thanks for your post. You da MAN! wow! Spirited debate follows, fasten your seat belts :-) > > - a transaction table containing about 6 or 8 columns of > >data including AMOUNT, which sums to zero (i.e. the debits > >equal the credits.) > > I think this is very simplistic. Such a G/L would be of limited > utility in a real business. Whatever you are building, if its purpose is "utility" in conducting business, it sounds like you are talking about something related to the purchasing cycle, sales, logistics, accounts receivable, accounts payable, etc. None of those things are General Ledger activities. So I don't know what you're building but it isn't a General Ledger. :-) > >Best practices for a general ledger are to keep the chart > >of accounts well below 100 and use them *only* for the reporting > >domain. This module would not serve double duty as a business > >system. It should not have departments, product lines etc. > >banded into the chart of accounts, etc. It will *not* have > >deep integration with LK but rather stand alongside and receive > >postings of economic events from the business system. A G/L > >is a WORM device (write-once, read many) not having much locking > >or concurrency problems. > > I fundamentally disagree with your assertion here. 'Best Practice' by whom? > For example SAP has the G/L at the very center of all activity of the company. > Oracle financials models complex activity in the G/L. In fact every ERP > system I have every seen used in anger in an organization models > organizational atributes in the G/L. It is the central repository of the > 'financial world view' of the company. I understand L-K is intended to be used by small and medium enterprises (SMEs). If otherwise please let me know because I'm outa here. I am not interested in building ERP systems for global corporations, for free. To the contrary I am interested in liberating ordinary businesses from the government-dictated transaction and network rules, resulting in continual ripoff of the SME community by software companies, telcos, and banks. I'm only interested in ending the printing of invoices and checks, totally ending bank fees for payments, or settling receivables and payables, and ending the continual cost of commercial accounting software. SMEs need to send and receive invoices, orders, payments, catalogs and other messages by internet, for free. That is my quest, and my whole purpose in life. > Lack of 'Deep Integration' has been at > the root cause of inaccuracy in financial reporting in a number of > organizations I have consulted to. How can you present a set of numbers to > the board when you can not justify those numbers by drilling down into the > underlying source data! Answer: you can't and BTW such a system would not > comply via GAAP as far as I am concerned. It would be un-auditable. Now, I would like to gently direct your attention to the emerging software architecture on the internet. Business modules for selling, purchasing, and every other business activity will not usually reside on drive C: or the local fileserver. They will usually run on websites on the internet. To see 1200 examples go to http://www.aspnews.com and go into the "Directory", and search for whatever you want. Visit some of the websites. They are all aligning into partnerships, exchanging data by XML. The proper role of a General Ledger in this new architecture is to serve as a Root Ledger to an arbitrary collection of business modules on DotComs (BSPs -business services providers) These DotComs will do a perfectly accountable job of whatever business process is needed by SMEs including, obviously, maintaining totals and details of transactions at the host. In the 1980s millions of DOS programs were written. In the 1990s millions of VB and Delphi and Foxpro programs were written. Now, there is no intelligent life in the packaged or custom software industry; they have all woken up and started building it on webservers instead of fileservers. In this environment the proper question is whether the General Ledger has *any role at all*. Almost everybody is going to have more than one DotCom BSP, for payments, billing, ordering, selling, etc. and the details of transactions are going to remain in the host system. It is assinine to duplicate them all to a central repository. So, at the end of a tax or reporting period the default, and arguably the best, architecture is to simply visit your 5 BSPs, print a summary JE from the website and keypunch them into your TaxPrep99 program or your Excel spreadsheet, or an old copy of Quickbooks 5, etc. which does a nice job of formatting financial statments. Personally, I feel it is important to have a root ledger and it would consist of control accounts for the subledgers (sales, inventory, AR/AP, fixed assets BSP, etc.) I don't think SMEs are going to let go of the steering wheel and run their control accounts on an Excel Spreadsheet. They are going to expect their BSPs to prepare coherent General Journal entries in XML formats, and transmit them across the wire securely, to post into their root ledger for fiscal control. Any decently designed root ledger will be able to format a query back up to the sub-ledger, requesting the detail for any entry, and present the results in the browser or GUI for the user. Any decently compliant sub-ledger will respond with an XML document or set of transactions for the given range represented in the original entry which they are responsible for. That's the way the game is going to be played. > Todd Boyle said > >GL reports don't necessarily need to be anything more than > >a group-by query on the transactions (i.e. trial balance > >of the sums of all the accounts for a particular date range.) > >together with some drilldown capability to fetch or view the > >detail behind the totals. Duncan said, > This misses a fundamental conceptual issue - the conflict between the > relational data model and the 'accounting double-entry data model' developed > by 15th C italian merchants. Basically when you use concepts like Account, > Sub-account, Department, Cost Centre and you overload their meaning in > different parts of the chart, you are essentially violating the relational > model. Let me give you a concrete example. Lets say that I want to use > sub-a/c to record the geographic region for sales account (01 - Nth America, > 02 - Canada) but I want to record product line classifaction for R&D expenses > (01 - Cars, 02 - Trucks). Now I want ot find all activities related to > America so I select on sub A-c = 01. See the problem. Now of course you can > qualify this only to look at sales and COGS accouts but where is all this > tacit knowledge stored? It is too error prone and makes using relation query > tools difficult. Try writing an income statement with Crystal Reports on one > of your existing reports and you will see what I mean. This is not an > academic arguement - I have seen income statements presented to boards of > international companies which have fallen into this trap. In fact there are > many other examples with much worse consequences. You have pointed to two well-known issues: The problem of segmented account codes, and the problem that financial reporting requires somewhat specialized report writers. Designs based on segmented account codes in the chart of accounts for things like departments, have disadvantages. There have been entire books written about this; whenever you denormalize a design by combining multiple attributes into a single foreign key in a table you get certain predicable results. For example the number of account codes is a cartesian product, e.g. 100 financial reporting buckets X 4 operational divisions X 6 average number of departments in each division X 8 major categories of product and service X 15 average number of sub-categories =288,000 potential account codes in the chart of accounts The health care industry is a great example, they have got an ingrown festering mass of account codes that has got all kinds of insurance and government regulatory requirements built into it. So, now they're in awful position, and breaking out will be like moving from english measures to metric system. It is important to understand why many companies use segmented account codes, at least, at the user interface: they enable certain combinations of Account, Division, Product etc. to be valid while completely preventing other combinations from being used. If you let the accountant in hospitals select these independently you will get expenses charged to uncollectible or unbillable combinations, such as surgical supplies for a department or facility which has no surgery activity. At the end of the day all this detail belongs in a whole medical system, which might maintain a "general ledger" with numerous assets, liabilities and income and expenses. But that system would be a poor candidate for a root ledger platform where the hospital is served by an arbitrary number of external BSPs for billing, payments, supply chain, etc. Surely, this is obvious. The medical "general ledger" will be managed as a subledger, or managed with classic consolidation techniques. Arguably, ERP systems, medical systems etc. make a poor choice for a root ledger for the enterprise' consolidation, financial reporting and fiscal control, etc. They are operational systems. YES, they should have an audit trail, integrity etc. but NO, it is not particularly important that they model the complete enterprise financial reporting and taxation problem space on top of all the other difficult challenges they face. In summary, the integration point between large scale business systems, ERP, etc. and BSPs such as for supply chain, billing, etc. is a matter to be worked out among those functional modules-- not thru the General Ledger. Yes, they must share a customer list or supplier list or consolidated ARs and APs. But NO, those difficult integrations do not necessarily have any intrinsic connection with the root ledger component in the emerging architecture. In my opinion, it is particularly important the General Ledger design for LK and GNUE should avoid deep integration with the AR, AP, and Customer and Supplier lists. This enables a decoupling of these important lists from the LK or GNUE business platforms when necessary. It enables the user run their GL interfaced with their LK or GNUE business system, and also use it supporting other business systems that have contact lists, etc without collisions. It is a question for LK business system designers whether to enable the AR and AP modules to interoperate with 3rd party software over the internet via XML. There is a growing need for a "Root AR", and "Root AP" ledger for multiple purchasing and selling channels and BSPs out on the internet to ride on, as well as other LAN applications. A combined view of AP and AR are highly important when you have multiple purchasing and selling channels (the most common being physical warehouse and web-based selling or purchasing) The AR and AP problem are a different project from the General Ledger. > ... the interface (i.e. input) in not as important as the > 'output' inteface (ie income statements, trail balances, funds > statements, tax reports etc. XML is an interesting concept and > nice technology but the issue is really the XML schema you are going > to use. Exactly right. The *whole* question is achieving a common XML vocabulary and semantics. When there is a standard XML invoice, and feature to associate it with appropriate XSL stylesheet for presentation, you won't have an application for invoicing. It will be just like any other document. People will start asking "Why do I need an *application* wrapped around my goddamned invoices???" The invoices will come into the GUI from many sources. And they will go out. You might drag and drop them onto the "PAY" icon, or "HOLD" icon which will just send the XML to your service provider for payment. Or if you've got digital cash, it might send a payment point-to-point. Or if you've got a paypal account like *over 1,000,000 people today*, the icon might send a paypal payment. Or if you are one of 10,000 people who have NetLedger accounts you might send it as a OneCore payment. Or if you're one of 4 million people on Quicken.com you might pay their fees and get it settled some other way. If you drag it to the "HOLD" icon, it will be sent by SMTP to your root AP Ledger provider (or posted to your AP application if you're running it locally.) Go ahead. Look inside the PO, the invoice, etc. in CBL, cXML, ebis-XML, or anything you like. They have all the tags necessary. They have tags, for GL account codes for classifying sales and expense etc. (All these XML vocabularies are on my XML Links page) Can you see why I have so little enthusiasm for a hard-coded, finegrained accounting software that sits on the LAN, and only talks to the laser printer, and doesn't know how to communicate over the internet? * Todd F. Boyle CPA http://www.GLDialtone.com/ * tboyle@rosehill.net Kirkland WA (425) 827-3107 * XML accounting, WebLedgers, ASPs, GL dialtone, whatever it takes