To try this, map or call the following function:
LedgerSetTransactionState('') – removes state
LedgerSetTransactionState('*') – sets 'checked' state
…
The logic used to distinguish the different parts
of the first line of a transaction is rather basic
but proved to work so far.
Now instead of ledger reg expense -p "this month", you can say:
ledger reg expense for this month
And as a shorthand for "for until this month", you can just say "until
this month" or "since this month".
Consider the following transaction:
2010-06-22 Sample
Assets:Brokerage 10 AAPL {$30}
Assets:Brokerage
Previously, this would have been equivalent to:
2010-06-22 Sample
Assets:Brokerage 10 AAPL @ $30
Assets:Brokerage
However, this is not always what the user expects to happen. When @ is
not being used, the transaction should reflect a mere transfer of
commodities. This is now how it works, and thus the above transaction
is now equivalent to the following instead:
2010-06-22 Sample
Assets:Brokerage 10 AAPL {$30}
Assets:Brokerage -10 AAPL {$30}
For example:
ledger bal assets bold checking
Or you can use expressions:
ledger bal assets bold '=total > 1000'
This last is identical to saying:
ledger bal -l 'account =~ /assets/' --bold-if='total > 1000'
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.
With -n, the first argument is parsed as a string containing
subarguments. Otherwise, each argument is parsed as a separate
argument.
In short, the -n mode mimicks what happens when the query expr after "="
is parsed for automated expressions. The non -n mode mimicks what
happens at the command line for users.
