For example, if a Ledger file contains transactions with the use of both
EUR and EUR {=PRICE}, then regular reports will always show the
{=PRICE}, disabling the by-name commodity merging that takes place. In
brief, fixated and non-fixated commodities are now non-mergable.
If a file contains all of one, or all of the other, they will still be
merged, since these separate usages do not conflict the way that fixated
and non-fixated together do.
1. A bounded budget "from DATE to DATE" will now generate entries
throughout that entire range, if it is triggered.
2. An unbounded budget begins, as before, in the timeframe of the
reported posting which triggered it, but now continues until the
present date.
The metadata construct 'Key: Value' is now just a special case for
'Key:: "Value"'. Another after a :: in metadata setting is parsed as a
full value expression and typed as such. For example:
; Key:: $400 + $500
ledger -l 'tag("Key") < $1000'
This is used by reports like register and balance so that separated
commodities without spaces in them needed be surrounded by quotes. It
will still occur in most other places.
Fixes#200 / F82CF11F-BFD9-4512-A562-202B04B68051
With -X COMM, all values are computed in terms of COMM, regardless.
With -V, only secondary commodities will ever be computed, never
primaries. Further, if a secondary commodities has an associated price,
the valuation is done in terms of that price's commodity.
This allows for value expressions to be used which reference the
incoming posting, for example:
= Income:Clients:
(Liabilities:Taxes:VAT1) (floor(amount) * 1)
(Liabilities:Taxes:VAT2) 0.19
2009/07/27 * Invoice
Assets:Bank:Checking $1,190.45
Income:Clients:ACME_Inc
The automated posting for VAT1 will use the floored amount multiplied by
a factor, while the posting for VAT2 multiples the whole amount as
before.
This is necessary because sometimes, a post from one account will get
reported as though it were in another account (this happens with
--budget, to show child account postings within their parent account).
In that case, the account needs to remember which postings have been
reported as being within it, so that it can add these amounts to its own
total in the balance report.
The code now uses Boost's input and output facets for times and dates.
This ensures completely consistency regarding timezones and times, and
fixes the regression test that was broken while I was away coding in
London (where it was GMT-0 and I didn't notice the difference between
local and GMT).
