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.
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).
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.
Now we have:
-- | Sorted unique account names posted to by this journal's transactions.
journalAccountNamesUsed :: Journal -> [AccountName]
-- | Sorted unique account names implied by this journal's transactions -
-- accounts posted to and all their implied parent accounts.
journalAccountNamesImplied :: Journal -> [AccountName]
-- | Sorted unique account names declared by account directives in this journal.
journalAccountNamesDeclared :: Journal -> [AccountName]
-- | Sorted unique account names declared by account directives or posted to
-- by transactions in this journal.
journalAccountNamesDeclaredOrUsed :: Journal -> [AccountName]
-- | Sorted unique account names declared by account directives, or posted to
-- or implied as parents by transactions in this journal.
journalAccountNamesDeclaredOrImplied :: Journal -> [AccountName]
-- | Convenience/compatibility alias for journalAccountNamesImpliedOrUsed.
journalAccountNames :: Journal -> [AccountName]
accountsFromPostings is currently doing excessive work when adding up
postings in each account. It sorts (accountName, amount) tuples which
cause amounts in them to be compared. There is no need to look at amount
here at all since subsequent summing up and counting does not depend on
order. It is enough to sort by accountname only.
Went through similar pieces of code, made them all look uniform.
- Simplify doctests for periodexpr.
- Besides consuming leading space consume ending space for periodexpr also.
- Drop implicit option (def, def) behaviour of periodexpr. I.e. disallow
hledger reg -p '' and auto-transaction with heading just '~'.
- Slightly re-factor periodexpr.
- Ensure that reportinginterval doesn't consume trailing space.
Useful if we'll start disallowing periods like "every1stjan2009-".
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.
This is very helpful for periodic transactions, because in budget mode
you need to ensure that no periodic transactions extend past the end
of the journal, and in forecast mode you need to make sure that all
periodic transactions are strictly after the end of the journal.
Some of these demonstrate that runPeriodicTransaction could generate
transactions ouside of requested DateSpan. This happens because
runPeriodicTransaction uses splitSpan internally, and splitSpan always
generates dateSpans that fully cover original DateSpan, extending
beyound left/right boundary if necessary. This is ok if transactions
are generated for budgeting purpose, but during forecasting care should
be taken to check that all generated transactions are happening past
the end of the real journal.
Currently only lower-case account names are supported, both on the
command line, and in the journal (in periodic transactions):
This works:
$ hledger balance -p nov
This does not:
$ hledger balance -p Nov
First transaction will parse, second will not:
```
cat every-month.journal ~/devel/haskell/darcs-get/hledger/examples
~ aug to sep
assets
expenses $1
~ Aug to Sep
assets
expenses $2
```
$../bin/hledger-budget bal -f every-month.journal
hledger-budget: Failed to parse "Aug to Sep": date parse error ()
This commit fixes both cases.
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.
Trailing whitespace in the replacement part of a regular expression
account alias is now significant. Eg, slightly flattening some bank
accounts: --alias '/:somebank:/=somebank '
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
Older megaparsec is still supported.
Also cleans up our custom parser types,
and some text (un)packing is done in different places
(possible performance impact).
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.
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.
This affects hledger-ui's transaction screen, print, hledger-rewrite etc.
A pending flag on postings is now displayed, just like a cleared flag.
Also there will now be a space between flag and account name.
And it's slightly better at aligning amounts, due to now considering
virtual posting parentheses/brackets or something.
When generating a new posting as a multiple of an existing posting,
support conversion to a different commodity. For example, postings in
hours can be used to generate postings in USD.
Automatic transactions generated from rewrite rules use the commodity,
amount style, and transaction price if the rewrite defines a commodity.
