Now it’s time to design a core
object model. The module transac.py
class that captures the key notions we
covered earlier. It also goes somewhat further; we’ve used
Magic Methods to define a basic algebra of accounting. The class
construction is straightforward. However, first we need to mention
three design issues. Since this is a contrived application,
we’ve gone for simple solutions that are good enough for our
needs; for a proper accounting system, the solutions would be
The first issue is how to represent the tree structure behind a company’s accounts. After several years of experimenting with different designs, it’s clear that simple strings do the job nicely. Thus a cash account can be represented with a string like MyCo.Assets.NCA.CurAss.Cash.MyWallet. This reduces lots of complex tree operations to simple string functions; finding the sum of all cash accounts becomes trivial. It should of course be hidden in the user interface to save end users from typing, but it clarifies the data structure.
The second issue is how to keep the balance sheet in the right order
as shown in Figure 6.3. You’ll see that the
accounts were named in alphabetical order at every level; we cheated
2_Capital at the top level to force an alphabetical order. This hack keeps our tree in the conventional balance sheet order without needing any extra sort fields. The display account names used in reports (or indeed a GUI) could ...