This allows us to guarantee that the report periods are well-formed and
don't contain errors (e.g. empty spans, spans not contiguous, spans not
a partition).
Note the underlying representation is now for disjoint spans, whereas
previously the end date of a span was equal to the start date of the
next span, and then was adjusted backwards one day when needed.
In end-value reports with unspecified end date, a market price later
than the latest transaction can extend the default report end date and
valuation date. Now, only market prices on or before "today" can do this;
market price declarations dated in the future will be ignored.
Report span and valuation date calculations have been clarified.
Previously accounts were clipped in getPostings, however compound
balance reports re-use the output of getPostings for the different
subreports. This caused a problem when clipping erased the information
needed to determine the account type, as would be used by e.g.
incomestatement.
Add some extra tests for --count.
- Do not turn "other accounts" into a comma-delimited string when the
report is constructed, but pass `AccountName`s up the chain. This
requires modifying the `AccountTransactionsReportItem` type to contain
`[AccountName]` rather than `Text`.
- Perform the account name summarization
(`Hledger.Data.AccountName.accountSummarizedName`) closer to the
actual rendering of the report, so that different report formats can
choose summarization strategy.
- Continue to summarize as before for terminal/text output (ie.
human-readable). Do not summarize any more for machine-readable output
(csv/html/fods).
This adds a safer version of spanDefaultsFrom that won't create spans
that end before they start, and updates all reports to use it.
The only related change noticed so far is that close now gives an
error instead of a malformed entry, when there's no data to close.
[#2409]
This upgrades Account to enable it to store a multiperiod balance, with
a separate balance for each date period. This enables it do the hard
work in MultiBalanceReport.
Some new types are created to enable convenient operation of accounts.
- `BalanceData` is a type which stores an exclusive balance, inclusive
balance, and number of postings. This was previously directly stored
in Account, but is now factored into a separate data type.
- `PeriodData` is a container which stores date-indexed data, as well as
pre-period data. In post cases, this represents the report spans,
along with the historical data.
- Account becomes polymorphic, allowing customisation of the type of
data it stores. This will usually be `BalanceData`, but in
`BudgetReport` it can use `These BalanceData BalanceData` to store
both actuals and budgets in the same structure. The data structure
changes to contain a `PeriodData`, allowing multiperiod accounts.
Some minor changes are made to behaviour for consistency:
- --declared treats parent accounts consistently.
- --flat --empty ensures that implied accounts with no postings are not displayed, but
accounts with zero balance and actual postings are.
Previously, hledger could read CSV files containing non-ascii
characters only if they are UTF8-encoded. Now there is a new CSV
rule, encoding ENCODING, which allows reading CSV files with other
encodings.
This adds a dependency on the encoding library, which supports fewer
encodings than text-icu but does not require a third-party C library.
To avoid build issues on various platforms, we require version 0.10+.
This adds some use of the ImplicitParams language extension, required
by encoding's API, but only in a small code region.
This also changes the type of Reader's rReadFn; it now takes
a `Handle` rather than a `Text`, allowing more flexibility.
Previously depth-limiting was universal across all accounts, e.g. all
accounts are clipped to depth 2. However, sometimes you want certain
accounts clipped to a different depth than others, e.g. all expenses to
depth 3, while all assets to depth 2. This commit enables depth-limiting
to optionally include a regular expression, which limits the accounts it
applies to.
More than one depth limit can be passed, and they are applied to each
account name by the following rules:
- If one or more regular-expression depth limit applies, use the
most specific one
- If no regular-expression depth limits apply, and a flat depth limit is
supplied, use that
- Otherwise, do not do any depth limiting
For example, this will clip all accounts matching "assets" to depth 3,
all accounts matching "expenses" to depth 2, and all other accounts to
depth 1.
--depth assets=3 --depth expenses=2 --depth 1
Market prices are now shown using one line each,
the known prices are listed (forward / forward+reverse),
and the status of --infer-market-prices is shown.
--color now also works in a config file, like --pager, except for two
cases: it does not affect colouring of debug output, or the colouring
helpers used in the check recentassertions error message.
