A few motivations for this:
* This makes the fund report more maintainable, because the data structure
is better suited to the task at hand, making it easier to follow what's
going on.
* This helps put Balances through a little more testing with a high-level
report.
* This makes the fund report a little faster, since totals are usually
calculated from a smaller number of Balance objects rather than all
Postings over a period.
The balances reported on the trial balances sheet included an account's
subaccounts. e.g., the balance for Expenses:A would include the balance
for Expenses:A:B. We don't want that traversal for this report, so
inhibit it and report only exact account balances.
This is basically a pure maintainability change: concurrent.futures is the
nicest API that's available in both Python 3.6 and 3.7, and our other tools
are using it.
We're basically always going to have a "packet build step," and it makes
more sense to have the manifest generated there, since it's the thing that
consumes the manifest, rather than here.
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.
This was already done correctly in RT links because rtutil takes care of the
quoting. The fact that we weren't doing it for file links was an oversight.
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.
This was most likely to happen with multiple bean-checks running in
parallel: they would both see a new RT URL, fetch it, and try to
insert it into the cache. That's not a problem as long as they're
both inserting the same URL, so catch that exception.
Make it look more like the spreadsheets:
* Don't normalize Expenses negative.
* Consistent account order: Income, then Expenses, then Equity.
* Include a bottom line divider for each fund.
* 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.
Basically the original bug was an incorrect sign. The last implementation
was very belt-and-suspenders to help me think through it. But it's also more
error-prone in the long run.
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.
