Basically this behavior is an extension of the fact that the outgoing report
is grouped by RT ticket rather than "accrual data." Ripping this
functionality out of other reports was correct, but it needed to stay for
the outgoing report.
Now that we're accepting classifications, it's possible to specify account
options that select some but not all accounts at the same level of the
hierarchy. This commit tracks requested account names separately from sheet
names to do that correctly.
This required keeping the balances from write_row, and then a lot of other
changes followed from that. In particular it makes more sense to build the
fund report sheet from scratch rather than copying the breakdowns report and
chiseling the fund report out of it.
Some readers care about recent accruals, some don't. This presentation
accommmodates both audiences, providing the data while making it easy to
ignore or filter out recent accruals.
Now that make_consistent is really robust, there's much less need to do all
the consistency checking that was done in AccrualPostings.__init__. I expect
this will provide a performance benefit for large reports, since we'll be
calculating data for many fewer accrual groups. The only performance penalty
I see is that the aging report has to calculate the balance three times for
each row it reports, twice in write() and once in write_row(), but that
seems okay and can be cached separately if needed.
This accommodates cases of contracts without separate invoices,
where a series of payments are scheduled over time.
The dance we used to do of group-by-invoice, then make consistent was
already suspect. It was originally motivated by the consistency checks that
are now gone. Use this opportunity to clean up and just make make_consistent
a classmethod.
I wrote the changes to Balance.format() before the dependent changes to
Balance.copy(), so I was sort of counting on them to be implicitly
tested. But they should be explicit.
The period totals were reporting the balance of all the loaded postings, not
just the ones in the reporting date range.
Like the accrual report, introduce a RelatedPostings subclass that records
and saves all the information we need at group definition time, to help us
get it consistently right rather than redoing the same math over and over.
