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.
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 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
--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.
This and the preceding commits were "work in progress" that got out of control.
There's more to do, but this one brings these precision-related improvements
(at least):
When "infinite decimals" arise, they are now generally shown with
8 decimal digits rather than 255.
print and prices no longer add trailing decimal zeros unnecessarily.
Some code has been refactored or given more debug output.
All tests have been updated to match the recent changes.
Add a flag --summary-only for multi-column balance reports, which does
not display the main date columns for a report, but only displays the
summary columns (--row-total, --average). This is useful when there are
many columns (a weekly summary over many years) where you're only
interested in the average (or some other summary).
This can be useful to override defaults in scripts.
These flags will now toggle when repeated on the command line:
--invert
--transpose
-r/--related
-%/--percent
-E/--empty
-N/--no-total
-T/--row-total
-A/--average
-S/--sort-amount
Boolean queries are now prefixed with an 'expr:' prefix, making them
completely separable from old queries and making the addition of them a
little more migration proof.
The tests are updated accordingly, changes made to the tests previously
are removed and extra cautious documentation is also removed.
This commit changes some of the functions in the Query module and
changes the overall way to parse queries. Instead of using the words''
split function, this commit starts to fully parse the query, as it's
seen as a type of expression.
AND, OR, NOT, and space operators can be used. The space operator
simulates the behaviour from before, leaving a minimal amount of tests
that need to be adjusted to comply to the new behaviour.
Eg, where previously -p 'monthly from 1/15' or -M -b 1/15 would always
adjust the report start date to 1/1,
unless you used the special -p 'every 15th day of month from 1/15' form,
now the start date will not be adjusted. (It is still adjusted if
the report date is not specified explicitly, eg inferred from the journal).
This keeps behaviour consistent between report periods and periodic transactions.
'in' period expressions, like 'in 2023-01', are a grey area; they
do specify a start date (2023-01-01), although they look a bit implicit.
So previously, -p 'weekly in 2023-01' would adjust the start date to
the preceding monday (2022-12-26), but now it will start exactly on
2023-01-01 (a sunday, which also causes ugly verbose column headings).
To ensure monday based weeks and simple report headings here,
you would have to explicitly specific a start date that is a monday,
eg -p 'weekly from 2022-12-26 to 2023-02'.
Introduce --infer-equity option which will generate conversion postings.
--cost will override --infer-equity.
This means there will no longer be unbalanced transactions, but will be
offsetting conversion postings to balance things out. For example.
2000-01-01
a 1 AAA @@ 2 BBB
b -2 BBB
When converting to cost, this is treated the same as before.
When used with --infer-equity, this is now treated as:
2000-01-01
a 1 AAA
equity:conversion:AAA-BBB:AAA -1 AAA
equity:conversion:AAA-BBB:BBB 2 BBB
b -2 BBB
There is a new account type, Conversion/V, which is a subtype of Equity/E.
The first account declared with this type, if any, is used as the base account
for inferred equity postings in conversion transactions, overriding the default
"equity:conversion".
API changes:
Costing has been changed to ConversionOp with three options:
NoConversionOp, ToCost, and InferEquity.
The first correspond to the previous NoCost and Cost options, while the
third corresponds to the --infer-equity flag. This converts transactions with costs
(one or more transaction prices) to transactions with equity:conversion postings.
It is in ConversionOp because converting to cost with -B/--cost and inferring conversion
equity postings with --infer-equity are mutually exclusive.
Correspondingly, the cost_ record of ReportOpts has been changed to
conversionop_.
This also removes show_costs_ option in ReportOpts, as its functionality
has been replaced by the richer cost_ option.
Together with -E, this shows a balance for both used and declared
accounts (excluding empty parent accounts, which are usually not
wanted in list-mode reports).
This is somewhat consistent with --declared in the accounts and payees
commands, except for the leaf account restriction.
The idea of this is to be able to see a useful "complete" balance
report, even when you don't have transactions in all of your declared
accounts yet. I mainly want this for hledger-ui, but there's no harm
in exposing it in the balance CLI as well.
