Loïc Dachary <loic@dachary.org>, during patch review, pondered whether the
ignoring of <Adjustment> by these scripts could ever be used to hide funds,
ala the movies Superman III and Office Space.
After discussion, we both concluded that it would not be possible to hide
funds merely with this report. Such hiding would have to also dig into the
main Ledger codebase and muck with how it handles auto-generated <Adjustment>
entries.
Based on patch review by Loïc Dachary <loic@dachary.org>, we discovered that
this script inconsistently used 0.02 as a float when comparing against
numbers from the Math::BigFloat() package. While there were no known bugs
related to this (presumably the 0.02 got coerced into a BigFloat (or
vice-versa) and compared properly), this change nevertheless normalizes to
use of a BigFloat for comparison.
The auditors seem to like to see the check deposits made to be subtotaled, so
that's done here. I attempted to aid this by using a --sort and/or
--sort-xacts option (or combo thereof) on the ledger command line, but this
didn't work as expected. I opened a bug in ledger about this:
http://bugs.ledger-cli.org/show_bug.cgi?id=901
The previous queries had a bug whereby an account in the form "A:B" would
include all transactions for sub accounts such as "A:B:C".
That's not the intended effect. Entries should appear in the lowest level
account, and not in their parent.
The regular expression now is anchored at start and finish in both queries to
ensure this works correctly.
Instead of always starting a search from the end date, allow a CLI option
that is the data to use for the start of searching (back from the end date).
This is useful when resuming a search (since they take a long time).
The dynamic programming version of the subset sum problem required far too
much RAM for larger bank balances. Meanwhile, the brute-force is not to bad
now that the loop tries the closer dates *first*.
For the times when we want to make shorter names of files by doing copies of
the documentation files for hyperlink usage, allow input of a new command
line option which is a list in the form of:
PATH_TO_FILE : sha25sum
so that those files can be used rather than new copies made.
Usually, transactions that didn't appear are nearby in date to the statement
date. This loop cycles through. Overall, this would take longer to find a
solution, but since most solutions are in the early dates "back" from the
statement date, this will probably be faster in typical cases.
