From: Todd Boyle [tboyle@rosehill.net] Sent: Wednesday, May 31, 2000 9:32 AM To: gnue@gnu.org Subject: Data cleardown / Year end Ben Cohen said, > On Wed, 31 May 2000, Lakshmi Anand K. wrote: > > 1. What about Financial Years? Do we put data that belongs to > > all financial years in a same table or keep seperate tables > > for each financial year? > > Presumably keeping separate tables would be better as most operations > would be on the current year's data so a one-year table would be smaller > and accessed faster. Access to previous years' data could then be kept > elsewhere, and perhaps users would be given different access privileges > for the old data. There would be smaller chunks required for backing up, > etc. Historical searches would then have to span multiple tables, though. > > Would it be preferable for auditing for the years to be separate? > > Would this be implemented by keeping any previous years' transactions > which are still open in the current year's table? This might improve > performance. I disagree with every single point in the above three paragraphs. The data structures should just roll on continuously with an absolute minimum of fiscal year periodicity anyplace in the system. The configuration of the software telling it your company's yearend day is necessary only for some very narrow purposes such as retained earnings. At a time when you can buy 20 GByte disks for $100, and 99% of small business accounting databases would easily run in a memory array below 100 Megs, it's nuts to incur *ANY* cost of futzing with annual datafiles. As only one of MANY examples, your programming task for ordinary processes of recording Accounts Payable, Accounts Receivable, and Cash, and of functions to match entries in reconcilation modules, is much more complex if the AR AP or Cash are in separate datafiles. So lets say you keep them in their own file and don't cleardown those files. Then, they run out of synch with the balance sheet. This whole thing is an incredible can of worms. Don't go there. Intuit bet on a single, eternal file and bet right, in 1993 when a 100Meg hard disk and a 386 was more typical. ------------- The correct question to ask is, "How will we design our cleardown module, for shrinking the file size?" And the answer might be something that can be configured to attack 1. certain periods [From Month] [To Month] 2. certain accounts [From Account] [To Account] 3. with choices to preserve or eliminate the ability to report on particular attributes [Consolidate Reporting by Customer (Yes/No)] [Consolidate Reporting by Department/Activity (Yes/No)] etc. The cleardown function might apply certain wellknown logic for clearing down the transaction detail as requested, and summarizing it into only the totals for the period. If the user wanted to preserve dept. reporting for historical reasons then the system might summarize the detail into a total by dept. by account. This is what I've seen in a number of software packages. I'm not saying its' the RIGHT answer. The principle doubt arises because you need to know the role of the "General Ledger" within the whole business system and I do not assume, any longer, that the "General Ledger" has any reporting role other than statutory tax and GAAP. Those reporting needs are much more limited than todays data mining and reporting hypercubes. So, the correct question to ask is "What is the principle business reporting solution for an enterprise running GNUE?" Are we really going to attempt to develop a reporting package that would serve a business well? Knowing how incredibly difficult it has been, and that almost every leading commercial accounting package, midrange and above, relies on specialized, best of breed reporing vendors like FRX, F9, Crystal etc http://www.cfonet.com/html/acctgswbg1-99.html Those of you who have read my wild and irresponsible comments the last couple of years, are forwarned what I'm going to say next: Small/midsized businesses need to send and receive orders, invoices, bills, payments etc. over the internet. We are going to do it for free, or nearly free. The way this is happening is already quite apparent by the over 1500 BSPs and ASPs on the internet; there is a small portion of those BSPs listed on my website at http://www.gldialtone.com/links.htm SMBs will use BSPs because it's much cheaper than maintaining an adequately reliable, functional host of their own, with payments grade security 24x7 on the internet. SMBs will use multiple BSPs because there is no way that any single vendor could possibly corner this market and become best of breed in any significant segment of functionality. 1. they don't have time 2. they don't have the money 3. they don't have the knowledge of all the business domains 4. it would be impossibly complex, to build into one monolithic platform 5. and even if Microsoft, AOL, IBM, SAP etc built this thing it would scare everyone to death and they would fear lock-in. SO there will be multiple BSPs. Lots and Lots of them. You will use one for banking, one for payroll, 3 or 4 for your purchasing, one for your webstorefront, etc. And they will all generate business results which must be posted down into your ' 1. root ledger for purpose of statutory financial reporting and tax 2. your root AR / AP which will contain your master contact list and single, manageable view of payables/receivables Now, its fine with me, if the root ledger is also the root AR.AP and that's probably necessary to achieve cash management and the cash flow statement. But I certainly would not assume the root ledger is where your sales by department, by region, by productline is going to be hosted. Do you see why the cleardown might be much simpler now, and the data volumes in the GNUE general ledger might be much thinner than earlier assumed? * 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