User: Password:
Subscribe / Log in / New account

Accounting systems: a rant and a quest

Accounting systems: a rant and a quest

Posted May 17, 2012 4:00 UTC (Thu) by fest3er (guest, #60379)
In reply to: Accounting systems: a rant and a quest by jcm
Parent article: Accounting systems: a rant and a quest

Actually, you need to take responsibility for your accounting data yourself. It is inexcusable to blindly enter information into a system and blindly trust the results that come out. And unthinkable to then expect someone else to take the blame. Any good accountant will look at the data in at least three different way to ensure that it is correct: double-entry bookkeeping view, financial accounting view, and financial management view, and in at least three different dimensions, such as by income/expense, by account, and by person. The sums of all dimensions better add up the same. She'll know very quickly whether or not the software is correct.

Money is the lifeblood of every business; without it, the business dies. The purpose of accounting is to know where your money is coming from and where it is going. And, at times, how fast the flow is changing. Satisfying the tax man is secondary.

The basis of any accounting system must be the Generally Accepted Accounting Principles (GAAP). While there are localized variances, GAAP is almost as universally used as is the Uniform Commercial Code (UCC).

I've worked, on and off, for a small accountant for 15 years. He spent the previous 17 years building a fairly complete accounting system (general ledger for client data, time & billing for his work with clients, phone logging, lead tracking, etc.) His programmer essentially wrote 2½ programs a week for 17 years, on average; she did use sound practices, such as code-reuse and good structures. But it's still ISAM-based, business BASIC, one-letter variable names, and almost uncommented (to be expected; disk space was at a premium then: it started on an early BASIC system, moved to a DG NOVA, and finally to Unibasic on SCO UNIX).

If I were to build a small business accounting system, I'd start with his and re-implement it using modern languages and a modern UI. And the first premise of the database system would be as already mentioned: every record inserted must include a record insertion date/time, the record this one retired (or null if it's new), a record retirement date/time, the record that retired this one (or null if it's current) and who did each deed. Nothing is ever deleted from the database or updated in it: 'DELETE' and 'UPDATE' don't exist. Call it 40 bytes per record; in 100M records, that's all of 4GB: mice nuts compared to the bit trail you'd get. And accounting is all about traceability.

(Log in to post comments)

Accounting systems: a rant and a quest

Posted May 20, 2012 19:31 UTC (Sun) by renszarv (guest, #84721) [Link]

btw, your requirements are contradicting. If no UPDATE-s are allowed, how/when the 'record retirement date` is modified in that record ? :)

Accounting systems: a rant and a quest

Posted May 20, 2012 21:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

You don't.

Instead you create a _new_ record pointing to the old record as the predecessor. So that all new documents from that point on would use the retiree's record, not the old ones.

Accounting systems: a rant and a quest

Posted May 21, 2012 5:32 UTC (Mon) by jackb (guest, #41909) [Link]

A bitemporal data model works like that. Information is only added to the database, never deleted or changed.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds