This is generally helpful to keep for future reference, plus this
presentation can support multiple queries and is more discoverable than the
previous file property.
* Provide dedicated formatting for more Beancount types.
* Improve code to determine when we're looking up link metadata
and should format output as links.
query-report was heading to a place where it was going to bifurcate. You
could structure input with its own special input switches, and with ODS
output, it would have its own dedicated grouping logic and use that.
But those things shouldn't be tied together for users. Instead, add
functions to BQL to be able to do the kind of grouping we want. This commit
adds those. Next we'll extend the ODS output to detect and format these
groups correctly.
Most of these account for the fact that mypy now reports that Hashable is
not an allowed return type for sort key functions.
That, plus the new ignore for the regression in config.py.
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.
Now that we have richer exceptions, this is the easiest way to refactor out
rewrite rule error handling from the various main functions where it
currenly lives.
This functionality already existed in the code three times, and it's about
to get more important for the ledger report, so now was the time to abstract
it.
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.
