This commit introduces the commandline argument -%/--percent to show
percentages of the column's total instead of the absolute amounts for
each account in reports. The signs of the values are preserved.
This option is especially useful for the balance and incomestatement
commands.
If there are multiple commodities involved in a report hledger bails
with an error message. This can be avoided by using --cost. Also note
that if one uses -% with the balance command the chances are high that
all numbers are 0. This is due to the fact that by default balance sums
up to zero. If one wants to use -% in a meaningful way with balance one
has to add a query.
In order to keep the implementation as simple as possible --tree has no
influence over how the percentages are calculated, i.e., the percentages
always represent the fraction of the columns total. If one wants to know
the percentages relative to a parent account, one has to use a query to
narrow down the accounts.
Invalid transactions generated from CSV will now be rejected.
I updated some csv tests to avoid this, except for 21, which
probably needs more cleanup.
-V (and -X) now respects a report end date set with -e/-p/date: when
choosing the valuation date, similar to hledger 1.14 and Ledger.
This means that -V/-X aren't exactly like either --value=end or
--value=now. The "Effect of --value on reports" doc has been extended
accordingly, and much of it has been reworded and made more accurate.
Compound balance reports showing ending balances (eg balancesheet),
now show the ending date (single column) or range of ending
dates (multi column) in their title. ,, (double comma) is used
rather than - (hyphen) to suggest a sequence of discrete dates
rather than a continuous span.
Transaction prices were being collapsed/misreported after close/open;
this is fixed. Now each separately-priced amount gets its own posting,
and only the last of these (for each commodity) gets a balance
assertion. Also the equity posting's amount is now always shown
explicitly, which in multicommodity situations means that multiple
equity postings are shown. The upshot is that a balance -B report
will be unchanged after closing & opening transactions.
To reduce confusion, multiperiod balance reports using -H/--historical
or --cumulative, which show end balances, no longer show a Totals
column since summing end balances generally doesn't make sense.
Also the underlying MultiBalanceReport now returns zero for those
totals when in cumulative or historical mode.
This feature turns out to be quite involved, as valuation interacts
with the many report variations. Various bugs/specs have been
fixed/clarified relating to register's running total, balance totals
etc. Eg register's total should now be the sum of the posting amount
values, not the values of the original sums. Current level of support
has been documented.
When valuing at transaction date, we once again do early valuation of
all posting amounts, to get more correct results. variants. This means
--value-at=t can be slower than other valuation modes when there are
many transactions and many prices. This could be revisited for
optimisation when things are more settled.
Instead of converting all journal amounts to value early on, we now
convert just the report amounts to value, before rendering.
This was basically how it originally worked (for the balance command),
but now it's built in to the four basic reports used by print,
register, balance and their variants - Entries, Postings, Balance,
MultiBalance - each of which now has its own xxValue helper.
This should mostly fix -V's performance when there are many
transactions and prices (the price lookups could still be optimised),
and allow more flexibility for report-specific value calculations.
+------------------------------------------++-----------------+-------------------+--------------------------+
| || hledger.999.pre | hledger.999.1sort | hledger.999.after-report |
+==========================================++=================+===================+==========================+
| -f examples/1000x1000x10.journal bal -V || 1.08 | 0.96 | 0.76 |
| -f examples/2000x1000x10.journal bal -V || 1.65 | 1.05 | 0.73 |
| -f examples/3000x1000x10.journal bal -V || 2.43 | 1.58 | 0.84 |
| -f examples/4000x1000x10.journal bal -V || 4.39 | 1.96 | 0.93 |
| -f examples/5000x1000x10.journal bal -V || 7.75 | 2.99 | 1.07 |
| -f examples/6000x1000x10.journal bal -V || 11.21 | 3.72 | 1.16 |
| -f examples/7000x1000x10.journal bal -V || 16.91 | 4.72 | 1.19 |
| -f examples/8000x1000x10.journal bal -V || 27.10 | 9.83 | 1.40 |
| -f examples/9000x1000x10.journal bal -V || 39.73 | 15.00 | 1.51 |
| -f examples/10000x1000x10.journal bal -V || 50.72 | 25.61 | 2.15 |
+------------------------------------------++-----------------+-------------------+--------------------------+
There's one new limitation, not yet resolved: -V once again can pick a
valuation date in the future, if no report end date is specified and
the journal has future-dated transactions. We prefer to avoid that,
but reports currently are pure and don't have access to today's date.
Hopefully this is will do it. This restores the past behaviour:
- parsing prices in balance assertions/assignments
- ignoring them in assertions
- using them in assignments
- and printing them
and clarifies tests and docs.
