From: Todd Boyle [tboyle@rosehill.net] Sent: Sunday, April 16, 2000 5:40 PM To: dunwin; kontor_en@ios-online.de Cc: Gnu E Subject: RE: General Ledger for Linux Kontor & GNUE These are my core arguments: 1. the decision whether the main GL should be tightly coupled with the operational business systems of a company by CORBA /RMI /DCOM, or loosely coupled by journal entries expressed in XML, is driven by objective criteria. Some selected criteria favoring a loosely coupled GL are - minimizing transaction cost thru application integration now that transactions will apparently flow across frontiers, up and down supply chains, between unrelated companies, in and out of vertical portals, in and out of unrelated BSPs, etc. - access to markets: greater numbers of suppliers, incrementally lower purchasing costs, greater numbers of customers etc. via internet. - access to services: getting bills delivered, payments executed, orders delivered etc. over the internet. - access to labor: distributing work processes including commerce, to remote employees, agents, and contractors. - access to software functionality: ability to quickly implement business modules locally or on internet, and non-disruptively migrate to successive platforms by maintaining a minimalist GL that requires nothing of the business module except periodic summary entries. 2. the general ledger domain may be defined as that which is *necessary* for financial and tax reporting, internal controls such as control totals on operational or business systems, and, for accountability within the enterprise e.g. budgets for sales and expenses for organizational units. 3. data duplication from source systems into a root ledger should be eschewed. Audit trails, backups, etc. should be maintained at source. Duncan said, >I know what you mean by 'not G/L activities' but are you really proposing a >whole pletora of systems trying to coorperate together to produce integrated >Financial Reporting? I lived throught the 'best of breed' era and I just does >not work without huge budgets for integration effor - XML won't fix this >either! The model I advocate isn't much different than the way people and departments actually operate already: it is an accountability model in which the Business System or ERP module maintains a robust statutory-grade audit trail, and would submit coherent summary reports to the G/L. I acknowledge the need for certain ERP modules to interoperate with each other fairly deeply, and regard that outside the scope of the root ledger. I acknowledge some enterprises' need for business reports drawing on data from multiple business models at times. There is a terrific industry that provides an abundance of data warehouse and reporting solutions, and if they (or you) want to call that a "General Ledger" module that's fine with me, but it is not a root ledger. It is a sub ledger. A root ledger must accommodate ecommerce by providing financial reporting and fiscal control in an environment where the enterprise has dealings on remote agents and hosts as well as same-vendor business modules. >I think of the the domain of the G/L as being integrated financial >reporting - to do this the G/L need a fair bit of detail in it. Not I'm not >saying that MUST be the case but to limit the capabilities tool and prevent >people for providing a single system for their financial reporting. I'm not taking issue with those structures that are apparently needed within L-K to provide integration between ledger accounts and the business system of L-K. What I'm saying is, if it doesn't have XML interfaces then it won't be suitable as a root ledger. Since you need XML interfaces, why build the other interfaces at all? Are you saying, the G/L is so interwoven with the rest of the business system it cannot really run without it? hmmmmmm. It *is* the business system, then. So, go ahead and build a COA and General journals and the balance sheet report. That's not a problem. But it's not a root ledger- if this was a commercial ERP system I'd call it a lock-in platform and set up an honest G/L down the hall for financial reporting. Hyperion or something. >>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. > >Near Zero Probability for this one I think. I would welcome further clarification, perhaps offline! Because I think we're going to see it. >>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. > >Sounds a touch Messianic but I think big goals can lead to big success. Some woman keeps phoning me, saying "Neo. You're the One." What is she talkin' about? who the hell is Neo? >Virtual and Transient orgs is the subject of a post-grad reseach degree I'm doing. Supply chains will not exist, they will only be erected for an instant by POS terminals Corporations won't exist; encrypted tokens containing data and executables will attach to all products and services, and people won't be able to extract funds from them until they do their job and pass the work along. People will compete to get ahold of tokens and deliver value into them but sometimes the tokens will refuse Brands will not exist; there will be mathmatical images in lables in the supermarket, containing the actual reputations of the members who made the product >I don;t think the issue is technology but rather building more >advanced conceptual models of business. The simplest thing is the most advanced when it come to financial reporting. Have you read the XBRL spec? >In this sense the G/L represents >orthodoxy - which is why I like to rethink it. try building pricing models >from your current G/L data and find out what I mean. Of course I'm also aware >that the G/L and accountancy bring a particular language and Weltanschauung >(approximately meaning is World View) which needs to respected and related to >any new forms that are proposed. Financial statements and tax reports are a bunch of garbage that needs to be done without disrupting business systems. Especially now that business systems are spreading across company boundaries. The owners of companies will have very good reasons to establish a root General Ledger uncoupled from their business system, and keep it as an XML object because in doing so, they not only free themselves from lock-in by the application software and their trading partner, but from their CPA. The key problem here is to recognize tax and financial reporting as a PROBLEM and devise an effective solution unbundled from anybody else's layer of the value chain. No business should ever let their software vendor or bank or trading partner, or controller or CPA, capture their root ledger. Good heavens. >>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. > >Sounds like an DaDaist's fantasy to me. The problem is the information >interchange - you forget that each system implements a model of business >activity not the activity itself. These models must be related if we want to >get information, rather than mere data, from our computer systems. Maybe the >OMG efforts can do this - noble attempts but I fear they deal with the lowest >common demoninator pragmatics not the really hard semantic issues. BTW not >singling out the OMG - 99% of the XML initiatives have this attribute. Let me revise my comment. It may be necessary to replicate detail data from multiple BSPs to a central repository i.e. data warehouse, if it needs to be interrelated. I think that will be a small fraction of the time. Most enterprises will use a single BSP for a particular part of their business (payroll, billing, web storefront/inventory, supply chain, etc.) Most of the necessary management reporting for each activity will be provided by the vertical or horizontal BSP in most cases. Fantasy? Watch and see! >>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. > >G/L is for financial activity reporting not for the reporting of the >transactional activities themselves.. Right. The General Ledger is for reporting the income, expenditure, asset, etc. together with its classification for tax/fiscal reporting. The root ledger of an enterprise should not usually store any other attributes such as customer, vendor, product, segment, etc. because they will inevitably be duplicated from other systems needlessly. When those systems need shared customer repository on an OLTP basis, the root ledger should get the hell out of the way of that whole CRM freight train and let best-of-breed hosts, trading hubs, big directory registries/repositories handle it. Because THAT is not general ledger and accountants have no business butting into that part of the value chain other than to REQUIRE that there should be audit trail etc. >>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. > >Agreed - in most cases keep customers out of the G/L but what about Sales >Areas, Sales Regions. These may need to be in both - in the subsidiary system >to capture the transaction and in the G/L for integrated reporting. Excellent point. When sales taxes are reported by region they are typically the responsiblity of the root ledger since they must report on all of the combined activities of the taxpayer. When budget/accountability is computed for a department, that must include combined activities of that department. Owners, taxing agencies, etc. final point of reference is the financial statements of the company and that's why the same numbers have to be used for tax and budget. Anyway-- that's how I would decide what goes into the root ledger, at this point. It is sort of a contractual view of life. Nonrepudiation must get built into these XML messages at some point, via digital signatures or something otherwise this is all a dead-end. But once you have real purchases and sales and payments happening, and flowing across company boundaries and supply chains, there's going to be a tremendous ripping and tearing at the LAN based accounting models. It's just going to be impossible to achieve deeply integrated systems for a while, and you;d lose money in these markets if you wait for deeply integrated systems. Actors on the internet that conduct business will have to be held accountable to their owners and stakeholders. But other than that, it will be very important to let them run wild without any further constraint or data demands from the accounting profession or their software object the GL. We just want the summary journal entry, and we're gonna cut their balls off if they don't have the detail when we come to check on it. The views of transactions necessary for effective operation and for effective control over business systems will be provided, of course, on those systems and those views and interfaces will be hopelessly diverse to replicate them on the root ledger host anyway, so, this is destiny. Thanks Duncan, let's go another round. I have unlimited time to explore this question. There is no more important question.