It now works slightly differently. Eg:
- <unbudgeted>'s subaccounts are hidden by default
- --show-unbudgeted shows all unbudgeted accounts, including subaccounts of budgeted parents
- --show-unbudgeted doesn't affect the grouping under <unbudgeted>
IMHO it's a nice simplification and increase in consistency, while still meeting the original intent.
Accounts which have no budget goals within the report period are now
grouped under <unbudgeted> - not just accounts with no budget goals ever.
Haddocks have been clarified, especially for budgetRollup. In some
ways things are much clearer without this feature, but it remains
enabled by default for now.
Budgets were restricted to a single interval in 1.9, but this was
a mistake. This restores the 1.5 behaviour, where a budget can be built
up from multiple periodic transactions with different intervals.
Income, liability and equity balances, which until now we have
always displayed as negative numbers, are now shown as normally positive
by these reports.
Negative numbers now indicate a contra-balance (eg an overdrawn
checking account), a net loss, a negative net worth, etc.
This makes these reports more like conventional financial statements,
and easier to read and share with normal people.
Ledger-style automated postings, previously supported only by
hledger-budget, have landed as a first-class feature. The --auto
flag activates them, so that any postings they generate are
included in reports.
Ledger-style periodic transactions, previously supported only by
hledger-budget, have landed as a first-class feature. The --forecast
flag activates them, so that any transactions they generate are
included in reports.
Compound balance commands like these can now be aware of normal account
balance sign, and sort negative balances accordingly.
This also adds utility-ht as a dependency, only for the uncurry function
right now but it looks potentially useful to have.
This patch fixes a bug that happened when using the -H option on
a period without any transaction. Previously, the behavior was no
output at all even though it should have shown the previous ending balances
of past transactions. (This is similar to previously using -H with -E,
but with the extra advantage of not showing empty accounts)
The new entry effectively adds a loan which is placed in the checking account.
This loan is then closed by the "pay off" transaction (which was already
present).
This is mainly to be used as a test point for the -H option; to make
sure -H does not show empty accounts.
All previous tests were changed to reflect the new change.
The documentation of the journal module was updated too.
Of the 2 tests, the first is a simple test on a specific period.
The second is expected to fail at this point until the new upcoming
code to fix the issue with the history option is implemented.
For the record : this issue happens when we use the -H flag for a period
that does not contain any transactions. Currently, the ending balance
values are only taken into account if the current period contains
a Transaction containing one of the previous populated accounts.
For example, if we have a statement on the 2008/01/01 for $1
and we do a command (with -H) to check the value on the
(without transactions) 2008/01/02, we will not get the $1 from
2008/01/01. In that same example, if we had a transaction for the same
account as 2008/01/01 in say 2008/01/03 then the -H command would
successfully show the statement from 2008/01/03 with the initial amount
that we set in 2008/01/01.
These tests verify the behavior when we input a very specific period.
The second test is meant to make sure that the new upcoming code in
MultiBalanceReports will not change anything in the behavior of
the module BalanceReport.
See the issue and linked mail list discussion. Ambiguity between the
uncleared state, and the "not cleared" --uncleared flag causes confusion
and friction. At this point it seems best to break with Ledger and
past hledger, pick a new name and drop --uncleared to put an end to it.
The balance command now shows negative amounts in red, when it thinks
ANSI codes are supported, ie when TERM is not "dumb" and stdout is not
being redirected or piped somewhere.
