The next step is to represent a set of books. Many accounting systems grew up with programmers and analysts trying to model the paper processes of old accounting systems, with complex posting and validation rules. Our representation turns out to be nothing more than a list of transactions in date order. Many of the common financial reports can be extracted with some simple loops through this list. In database parlance, we have normalized our design, and will now define lots of views on top of it to get the data the users want. By storing transactions and only transactions, rather than allowing the line items to exist separately in some other kind of database, it’s easy to ensure that the whole system obeys the fundamental rule of summing to zero as we manipulate the data.
BookSet class now captures the logical
structure of a general set of books. We also give it the ability to
load and save its data, add, edit, and delete transactions, and
display common views of the data.
The examples at the web site
include a script, demodata1.py, that generates a
BookSet with 1,000 transactions and saves it to a
file for future use. This test set of data is constant and can be
used for volume testing and optimization. It shows a two-year
model for a small consulting company called Pythonics Ltd. which,
after a shaky start, achieves superior productivity and wealth
As before, we kick off with a quick ...