To get the previous behaviour, you can call with the additional query "not📅tomorrow-".
This is because we are preparing to move forecast_ to InputOpts, where
it is not accessible to AccountTransactionsReport.
AccountTransactionsReport.
Only a limited number of journal transformations are allowed in
accountTransactionReports due to the need to include the original
transaction. Document these.
Make sure to remove currency and amount queries from the reportq, so
they do not cause problems after valuation.
Avoid confusion by calculating transaction date at one point, and
passing that down with the transaction.
valuation after all reportq filtering is done (in both the historical
and recent postings), and make sure filtering is done at the correct
point based on whether --txn-dates is set. (#1634)
This is done to be more consistent with future field naming conventions,
and to make automatic generation of lenses simpler. See discussion in
\#1545.
rsOpts -> _rsReportOpts
rsToday -> _rsDay
rsQuery -> _rsQuery
rsQueryOpts -> _rsQueryOpts
reportq from the ReportSpec, rather than being supplied as a separate
option.
This is the same approach used by the other reports, e.g. EntryReport,
PostingReport, MultiBalanceReport. This reduces code duplication, as
previously the reportq had to be separately tweaked in each of 5
different places.
If you call accountTransactionreport, there is no need to separately
derive the report query.
functions to AccountTransactionsReport.
If you use transactionsReport, you should either use entryReport if you
don't require a running total, or using accountTransactionsReport with
thisacctq as Any or None (depending on what you want included in the
running total).
This does costing and valuation on a journal, and is meant to replace
most direct calls of costing and valuation. The exception is for reports
which require amounts to be summed before valuation is applied, for
example a historical balance report with --value=end.
supplant the old interface, which relied on the Num typeclass.
MixedAmount did not have a very good Num instance. The only functions
which were defined were fromInteger, (+), and negate. Furthermore, it
was not law-abiding, as 0 + a /= a in general. Replacements for used
functions are:
0 -> nullmixedamt / mempty
(+) -> maPlus / (<>)
(-) -> maMinus
negate -> maNegate
sum -> maSum
sumStrict -> maSum
Also creates some new constructors for MixedAmount:
mixedAmount :: Amount -> MixedAmount
maAddAmount :: MixedAmount -> Amount -> MixedAmount
maAddAmounts :: MixedAmount -> [Amount] -> MixedAmount
Add Semigroup and Monoid instances for MixedAmount.
Ideally we would remove the Num instance entirely.
The only change needed have nullmixedamt/mempty substitute for
0 without problems was to not squash prices in
mixedAmount(Looks|Is)Zero. This is correct behaviour in any case.
independently.
You can now combine costing and valuation, for example "--cost
--value=then" will first convert to costs, and then value according to
the "--value=then" strategy. Any valuation strategy can be used with or
without costing.
If multiple valuation and costing strategies are specified on the
command line, then if any of them include costing
(-B/--cost/--value=cost) then amounts will be converted to cost, and for
valuation strategy the rightmost will be used.
--value=cost is deprecated, but still supported and is equivalent to
--cost/-B. --value=cost,COMM is no longer supported, but this behaviour can be
achieved with "--cost --value=then,COMM".
costing and valuation.
This currently is given a dummy NoCost argument and is equivalent to
"maybe id (*ApplyValuation ...)", but provides a constant interface so
that internal behaviour can be changed freely.
Also adds a postingDate argument to amountApplyValuation, and re-orders
the ValuationType and (Transaction/Posting) arguments to
(transaction/posting)ApplyValuation, to be consistent with
amountApplyValuation.
;areg: debug output
;areg: show a title indicating which account was picked
This might be a bit of a pain for scripting, but otherwise it can be
quite confusing if your argument matches an account you didn't expect.
;areg: improve CSV headings
;areg: show at most two commodities per amount
accountTransactionsReport now filters transactions more thoroughly, so
eg transactions dated outside the report period will not be shown.
Previously the transaction would be shown if it had any posting dated
inside the report period. Possibly some other filter criteria now get
applied that didn't before. I think on balance this will give slightly
preferable results.
