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.
dropped journalPrices
renamed Price to AmountPrice, AKA "transaction price"
renamed MarketPrice to PriceDirective.
added new MarketPrice (more pure form of PriceDirective without the amount style information)
Prices is now a more efficient data structure, but not used yet.
These Ledger-ish spellings were dropped over the years, to improve
--help's layout. Now they work again, but are considered hidden flags
so --help doesn't show them automatically (but I decided to mention
them manually in --date2's description).
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.
This test prints the time elapsed (before the OK message).
Mainly to support current performance tuning
(make ghcid-test-Hledger.Cli.Utils.journalApplyValue),
but also for future reference.
-V is still quite a bit slower than no -V, but not as much as before:
+===========================================================++=======+
| hledger.999.pre -f examples/10000x10000x10.journal bal || 5.20 |
| hledger.999.pre -f examples/10000x10000x10.journal bal -V || 57.20 |
| hledger.999 -f examples/10000x10000x10.journal bal || 5.34 |
| hledger.999 -f examples/10000x10000x10.journal bal -V || 17.50 |
+-----------------------------------------------------------++-------+
cmdargs wraps any lines longer than 78 characters. To (mostly) avoid
this, we now display verbatim blocks unindented, and some of
register's examples have been altered to make them fit.
This means committing a bunch more generated files, but it's probably
worthwhile, so we can have both rich hyperlinked/styled command docs
and clean readable command help.
These commands now detect the account types declared by account directives.
Whenever such declarations are not present, built-in regular expressions
are used, as before.
A bunch of account sorting changes that got intermingled.
First, account codes have been dropped. They can still be parsed and
will be ignored, for now. I don't know if anyone used them.
Instead, account display order is now controlled by the order of account
directives, if any. From the mail list:
I'd like to drop account codes, introduced in hledger 1.9 to control
the display order of accounts. In my experience,
- they are tedious to maintain
- they duplicate/compete with the natural tendency to arrange account
directives to match your mental chart of accounts
- they duplicate/compete with the tree structure created by account
names
and it gets worse if you think about using them more extensively,
eg to classify accounts by type.
Instead, I plan to just let the position (parse order) of account
directives determine the display order of those declared accounts.
Undeclared accounts will be displayed after declared accounts,
sorted alphabetically as usual.
Second, the various account sorting modes have been implemented more
widely and more correctly. All sorting modes (alphabetically, by account
declaration, by amount) should now work correctly in almost all commands
and modes (non-tabular and tabular balance reports, tree and flat modes,
the accounts command). Sorting bugs have been fixed, eg #875.
Only the budget report (balance --budget) does not yet support sorting.
Comprehensive functional tests for sorting in the accounts and balance
commands have been added. If you are confused by some sorting behaviour,
studying these tests is recommended, as sorting gets tricky.
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 ?
This was added in 2012, I guess to prevent CPP breaking on some
needed and I don't want to do this everywhere; we'll just remember
to not put CPP-like content in quasi-quoted blocks.
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.
Using "actual" and "budget" terminology. "real" is already used in the
context of real/virtual postings. "actual" should be familiar from
unit testing (expected & actual)..
Per feedback from peti. These files will no longer be installed to
cabal's data directory, where it might seem as if they are required at
runtime, which they are not. Packagers will still find them in the
tarball and can put them in the proper place.
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.
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.
Builtin commands are now gathered more tightly in a single module,
Hledger.Cli.Commands, reducing duplication and facilitating change.
The tests command was difficult and has been dropped for now.
The obsolete convert/info/man commands have been dropped.
cli: refactor: a proper commands list, better Main/Commands separation
The legacy "convert" command has been dropped.
The activity command's module is now named consistently.
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).
You can select a docs format/viewer with one of the `--info`, `--man`, `--pager`, `--cat` flags.
Otherwise, it will use info if available, otherwise man if available,
otherwise $PAGER if defined, otherwise less if available, otherwise it
prints on stdout (and always prints on stdout when piped).
Preferring info over man might not suit everyone.
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.
* Add an option to use unicode in balance tables
fixes#522
* Add a test for unicode tables
* Document --pretty-tables
* Support --pretty-tables in BalanceView
* factored out multi-column balance reporting into table creation and string rendering
* preliminary multicolumn balance reporting for BalanceView
* added -T and -A options for balance views
* support for overriding balanceview defaults
* fixed unecessary whitespace stripping to make tree view work
* no need for ViewPatterns in BalanceView
* fixed regression where balancesheet didn't ignore the start date when in single column mode
* removed trailing whitespace to pass tests
* handling warnings in Balance.hs
* force -E to line up lines for bs/is/cf
I was working through the documentation, and this wouldn't work as-is. I noticed that there is an additional argument `assrt` which is not used here. Passing `True` causes this example to work.
Source and compiled versions of all addons in bin are cluttering up
the commands list. I think this was reasonably well behaved, so I'm
re-enabling it, possibly with a slight fix (.c shadowing .exe).
Some notes:
- when there's only one addon with its base filename, its extension is not displayed (as before)
- addons with (case insensitive) .exe extension or no extension are considered compiled
- when there's exactly two addons with the same base filename, and one of them looks compiled, only that one is kept
- modification time is not checked; an old compiled addon overrides a newer source version
- when there's more than two addons with same base filename, all are kept
The previous cleanup defined long help separately from the usage text
generated by cmdargs. This meant keeping flag descriptions synced
between the two, and also the short help was often too verbose and
longer than the long help.
Now, the non-usage bits of long help are defined as pre and postambles
within the cmdargs mode, letting cmdargs generate the long help
including all flags. We derive the short help from this by truncating
at the start of the hledger common flags.
Most of the bundled addons (all but hledger-budget) now use the
new scheme and have pretty reasonable -h and --help output.
We can do more to reduce boilerplate for addon authors.
* cli: fix bug in pivot for postings without tag
Without this fix for postings without tag query checked effective
account which is always empty text ("").
* rewrite: inherit dates, change application order
For budgeting it is important to inherit actual date of posting if it
differs from date of transaction. These dates will be added
as a separate line of comment.
More natural order of rewrites is when result of first defined one is
available for all next rewrites.
* rewrite: factor out Hledger.Data.AutoTransaction
* rewrite: add diff output
With this option you can modify your original files without loosing
inter-transaction comments etc. I.e. you can run:
hledger-rewrite --diff Agency \
--add-posting 'Expenses:Taxes *0.17' \
| patch
As result multiple files should be updated.
Also it is nice to review your changes using colordiff instead of
patch.
* lib: track source lines range for journal
* doc: auto entries and diff output for rewrite
