| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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}
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Parent accounts are abbreviated even more, so that child accounts can
show more text.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have a typed metadata key which contains an amount, you can use
--inject=KEY to inject a posting with that amount wherever a match
occurs. There are two main forms of usage:
2010-06-18 Sample
; Key:: $100
Expenses:Food $100.00
Assets:Checking
The command would be:
ledger reg --inject=Key
In the above, transactional form, a posting under the account "Key" will
be injected before the first posting reported for this transaction.
It's amount will be $100. This only happens once for the whole
transaction.
It is also possible to associate the key with a posting:
2010-06-18 Sample
Expenses:Food $100.00
; Key:: $100
Assets:Checking
Now the injected posting is generated whenever that particular post is
reported.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is done using the multiprocessing library in Python 2.6. If that's
unavailable, this feature does nothing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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'
|
| |
|
| |
|
|
|
|
| |
Fixes #227 / 1C90D8AF-830E-43C2-A5B7-D382F68EBDE3
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #188 / 53BCED29-F3B9-4E02-9A35-6C739ABB9662
|
| |
|
| |
|
|
|
|
| |
Fixes #167 / 1D275740-D1A6-42B7-BDE4-F2F85E30CE8E
|
| |
|
|
|
|
| |
Fixes #210 / D4C2DD6F-8967-4FFC-BBBC-A941F9C53475
|
|
|
|
| |
Fixes #211 / 1736ACA5-5DE6-4826-AEB4-DB5B2A2217AC
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The purpose of this option is to add special "<Rounding>" postings, to
ensure that a regiter's running total is *always* the sum of its
postings. Within --rounding, these adjustment postings are missing,
which was the behavior in Ledger 2.x. It can be orders of magnitude
slower to turn it on for large reports with many commodities.
|
|
|
|
| |
The switches the default back to the same as 2.x, which is --unsorted.
|
|
|
|
|
| |
There ended up being too many corner cases for the generalized formatter
to handle.
|
| |
|
|
|
|
|
| |
This includes another baseline test for --unrealized, and also new ones
for --unrealized-gains and --unrealized-losses.
|