This removes transactionModifierToFunction's extra query parameter;
the rewrite command sets it in the TransactionModifier instead, which
I think is equivalent. I had to change one functional test, but it
seems correct now, so perhaps it wasn't working right before ?
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.
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.
A commodity directive that doesn't specify the decimal point character
increases ambiguity and the chance of misparsing numbers, especially
as it overrides all style information inferred from the journal amounts.
In some cases it caused amounts with a decimal point to be parsed as if
with a digit group separator so 1.234 became 1234.
We could augment it with extra info from the journal amounts, when available,
but it would still be possible to be ambiguous, and that won't be obvious.
A commodity directive is what we recommend to nail down the style.
It seems the simple and really only way to do this reliably is to require
an explicit decimal point character. Most folks probably do this already.
Unfortunately, it makes another potential incompatiblity with ledger and
beancount journals. But the error message will be clear and easy to
work around.
Inferred amounts now have the appropriate standard amount style applied.
And when checking for balanced transactions, amount styles declared with
commodity directives are also used (previously only inferred amount styles were).
This makes budget reports more intuitive. It is a temporary hack which
can misorder columns in some cases (if actual and budget activity
occur in a different range of columns). We should redo this in a more
principled way.
Tabular reports from bal, bs etc. have until now been rendered on
the terminal with one final blank line, for readability.
This change drops the blank line.
This is consistent with the non-tabular balance and register output
(not print, which is a special case), and with most unix commands.
The real reason for it, which I admit is flimsy, is that I can now omit
the final delimiter (>=0) when using shelltestrunner 1.9's new format,
making functional tests easier to maintain and more readable.
If there's opposition, this could be reverted.
Previously, if you specified no report interval, the text output of
these commands was a simple report like the original balance command,
with amounts on the left and account names on the right. Also,
balances used arithmetic sign like the balance command.
Now it always draws a table, with account names in the left
column, and shows balances with normal-positive sign, consistent with
the multicolumn reports. Less code, fewer bugs.
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.
For multi-column balance report, if there are no transactions in the
given period for budgeted account, display [0% of <budget>] for
consistency.
If balance is a mix of commodities, convert to cost basis for the
purposes of computing percent of balance spent.
Budget goals specified with periodic transactions (as with
hledger-budget) can now be displayed in balance report (but not in bs/is/cf).
--budget shows the target amount and percentage alongside the actual
amount, per account and period.
Unbudgeted accounts will be hidden, unless --show-unbudgeted is used.
Budgeted accounts are displayed folded (depth-clipped) at a depth
matching the budget specification. Unbudgeted accounts, if shown, are
displayed at their usual depth (in full detail, or according to --depth).
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.
Add "fixed" to the regex used to exclude asset accounts from cashflow
reports. Assumes accounts are set up something like:
assets:fixed assets:equipment
assets:fixed assets:vehicles
assets:fixed assets:buildings
That's the current most robust way. Otherwise, it can fail due to
stack's progress output as it reinstalls hledger libs, and that
reinstallation also forces all the addons to be relinked.
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.
Related to #563, when rendering a transaction, we reserve two more chars
of width so that amounts remain aligned when there are posting flags.
Affects hledger-ui's transaction screen, print, hledger-rewrite etc.
