This provides more flexibility in repository setup while remaining backwards
compatible.
The changes to test_reports_query are just to accommodate the new
transaction in 2020-expenses.beancount.
Ultimately this is going to be a tool that can generate nicely-formatted
spreadsheets from arbitrary bean-queries. This initial version doesn't
generate spreadsheets yet, but it does integrate our usual books-loading
tools and rewrite rules into existing bean-query functionality, so it's a
start. It also has some of the query building and parsing that higher-level
spreadsheets will need.
For now, this is basically just a specialized ledger report. It highlights
rows that already appear reconciled, and reports different balances, with
appropriate formulas to assist interactive reconciliation.
In the future I hope we can extend this to read various CSV statements and
then highlight rows different based on discrepancies between the statement
and the books, sort of like the PayPal reconciler does now.
We've long supported skipping documentation checks by flagging the
transaction. We haven't done the same for enumerated metadata because we
need it less often, and bad values tend to do more damage to reports.
However, occasionally when something very off-process happens, we do need it
as a matter of expediency. So support it.
In order to skip validation of these fields, the plugin requires that the
value start with the string "FIXME". This helps ensure that reports have a
consistent way to detect and warn about unfilled values in flagged
transactions.
This is friendlier to the YAML input and consistent with FieldFlags.
Less consistent with the rest of the codebase, but local consistency matters
more IMO.
Next steps:
* A tool to fill the PDF form based on values written to that YAML.
* An extension to fill some of those values with numbers queried from the
books (which is why we need something more involved than FDF).
This is a *very* rough initial draft of a report. As the docstring mentions,
it's basically counting on the user to provide rewrite rules to provide the
desired representation.
Long-term I'm hoping maybe we can standardize the program metadata enough,
or plan its replacement well enough, that this report can be written against
that directly. But that will take more planning about books structure, and
support from the plugin, before the report can be written that way.
This is less "future-proof," but the thing is, it's premature to try
to anticipate what other link formats will be in the future. See
discussion in comments.
Introduce the get_commodity_format() function, which returns Babel's
usual format string for currencies, but returns a version of it
"merged" with the locale's currency unit pattern for other
commodities.
BaseODS then calls this function where needed to format amounts.
I realized that if ledger-report supported rewrite rules, then it would
include all the information necessary to reproduce the numbers on the
statement of functional expenses.
With that, it was easy enough to add support to the rest of the reports for
consistency's sake.
* Default "management" for more accounts.
* There's a good handful of accounts where in past audits, the functional
split has been "Conservancy expenses are management, project expenses are
program." Handle those cases too.
The old version was causing Income:Donations:Released postings to be
"double-released." This version gets the bottom line numbers for
Net Assets With/out Donor Restrictions match the corresponding numbers
in the fund report.
