| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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'
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Parent accounts are abbreviated even more, so that child accounts can
show more text.
|
| |
|
|
|
|
| |
When a transaction has two commodities, but also a null posting, no
attempt should be made to resolve the costs in terms of the primary
commodity.
|
| |
|
|
|
| |
Things like "since last month" and "4 weeks ago", and "since 4 weeks
ago" are now all working.
|
| | |
|
| |
|
|
|
| |
This means you can forecast or budget against a file containing only
periodic transactions.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Do not record commodity exchanges where amount's commodity has a fixated
price, since this does not establish a market value for the base
commodity.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Before, this was valid:
; Today Yesterday: Tomorrow
Which would set the key Yesterday to the value Tomorrow. Now, it is
just an ordinary comment.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a posting has the metadata field "Payee" set to a string, that will
be used as the payee name for that posting. This affects the register
report, the payees report, and the --by-payee option.
This is useful because sometimes I send, say, 4 checks at a time to my
bank. So on my bank statement, this is all just one amount:
2010-06-17 Sample
Assets:Bank $400.00
Income:Check1 $-100.00
Income:Check2 $-100.00
Income:Check3 $-100.00
Income:Check4 $-100.00
Though it's important that the Assets:Bank posting be a single posting
of $400 value, I'd like for income reports to show whom each check came
from. Now I can say:
2010-06-17 Sample
Assets:Bank $400.00
Income:Check1 $-100.00 ; Payee: Person One
Income:Check2 $-100.00 ; Payee: Person Two
Income:Check3 $-100.00 ; Payee: Person Three
Income:Check4 $-100.00 ; Payee: Person Four
When I report this, it appears as:
10-Jun-17 Sample Assets:Bank $400.00 $400.00
Person One Income:Check1 $-100.00 $300.00
Person Two Income:Check2 $-100.00 $200.00
Person Three Income:Check3 $-100.00 $100.00
Person Four Income:Check4 $-100.00 0
This shows that they are all in the same transaction (which is why the
date is not repeated), but they have different payees.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
