Coding Transactions
Now it’s time to design a core
object model. The module transac.py
defines a
Transaction
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
different.
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 and used
1_NetAssets
and2_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 ...
Get Python Programming On Win32 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.