This is a set of tools for supporting use of the ledger accounting package. The tools are aimed at making it easier to catch and fix mistakes and omissions. We'd like to make it easier and faster to reconcile checking accounts and the ledger.
These are the onyl useful things so far:
anvil monthly-bal
anvil reconcile
python-pytest python-pytest-cov
For this, we're using the PDFs, not the CSV.
- Log in to Chase
- Click Deposit Accounts
- Click Perfbus Chk
- Click See Statements
- Choose statements for the dates you need
- Save As and store them using default file name
Then, copy all the files to this dir and run make.
To add a new command:
-
Stub out a method with the name of the command to the Dispatch class.
-
Write the first comment to that class. This comment will be user-visible. Line 0 is the short help description of the comment that shows up in the standard '-h' view. The comment as a whole will be seen in the '-h foo' view.
-
Add a class that can handle the comment to each display_foo module.
-
Fill in the Dispatch method for this command. Have it call the display module as needed to display the results. For anything that produces a lot of output or takes a while, try to emit periodic progress rather than saving all the output for the end.
We have display_cl, and display_csv. Those are both collections of command line display classes. For every new command, you probably want to write display classes for both cl and csv.
At some point, we need to write display_web or something. I havent quite figured out what program flow for that will look like. I'm not sure how to use callbacks to respond to web requests and I need to look for frameworks that are callback-friendly.
We do a few things with Python that are not standard, so it might be worth documenting them in case I'm less clever tomorrow, which seems pretty likely.
Eveyr method in the Dispatch class (except for ones whose names starts
with an underscore) is a command that can be given to Anvil. The
argument parser uses object inspection to grab those command names. It
also takes the first comment in each method as documentation for the
command. Line 0 is the short documentation. The entire first comment,
including additional lines, is the detailed help one gets by calling
--help foo.
We separate the display (the "View" in MVC, I guess) from the implementation and the model by only talking to the user through display classes and our top-level python file, anvil.py. We pass these display classes as callbacks to the implementation (the "Controller" in MVC, I guess) classes. Mostly those classes are in accountant.py, chase.py, ledger.py.
Our display classes are in modules and we can select the module at run time (via the --csv switch, for example). We can then instantiate a class within the module and the class will DTRT with regard to both logic and display.
Some command line arguments affect the display. We cannot set those arguments in the instantiated display object because it doesn't exist until fairly late in the dispatch process. Waiting until those objects exist would be unwieldy. We'd have to set options in those objects in many places and in a repeated fashion. We can't just use module-level variables because what we really need is inheritance.
To solve this, we change attributes of the python class (display.Display) from which the other display classes inherit. Look at how the --output option is handled. We change it in display.Display and then when display_csv.Monthly_Bal inherits from display.Display, the new value is carried over.