| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This isn't being used yet, but it likely will to improve the information
presented to users if their value expressions fail to compile or
evaluate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'
|
| |
|
| |
|
|
|
|
|
| |
Now when the Y directive sets the current year for a region, it affects
everything, as if the clock really were set back to that year.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These can occur in many places:
; Within an automated transaction, the assert is evaluated every time
; a posting is matched, with the expression context set to the
; matching posting.
= /Food/
assert account("Expenses:Food").total >= $100
2010-06-12 Sample
Expenses:Food $100
Assets:Checking
; At file scope, the expression is evaluated with "global" scope.
assert account("Expenses:Food").total == $100
; At the top of a transction, the assertion's scope is the
; transaction. After a posting, the scope is that posting. Note
; however that account totals are only adjusted after successful
; parsing of a transaction, which means that all the assertions below
; are true, even though it appears as though the middle posting should
; affect the total immediately (which is not the case).
2010-06-12 Sample 2
assert account("Expenses:Food").total == $100
Expenses:Food $50
assert account("Expenses:Food").total == $100
Assets:Checking
assert account("Expenses:Food").total == $100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example, consider the following automated transaction:
= /Food/
; Next Date:: date + 10
(Expenses:Tax) 1.00
; Next Date:: date + 20
This will add a metadata field named 'Next Date' to the _matching
posting_, with a value that is 10 days later than that posting. It will
also generate a new posting for that transaction, whose amount is the
same as the matching posting. Further, it will add a 'Next Date'
metadata tag to the _generated posting_ whose value is 20 days later
than the date of the matching posting.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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'
|
| |
|
|
|
|
|
|
|
|
|
| |
You can now establish a fixated price automatically by way of a fixated
cost. The syntax for this is:
2009/11/01 Sample
Assets 1 apple @ =$0.10
Equity
|
| |
|
|
|
|
| |
Fixes #210 / D4C2DD6F-8967-4FFC-BBBC-A941F9C53475
|
|
|
|
| |
Fixes 0F17CB7F-A000-4F99-8471-739948AD575F
|
|
|
|
| |
Fixes F4A477E6-C4F6-43B1-ABCC-4DC325C2869A
|
|
|
|
| |
Fixes 89233B6D-CB21-4162-98E3-BE38B9336070
|
|
|
|
|
| |
This only happens at the base filename, not for any of the directory
names for now.
|
| |
|
| |
|
|
|
|
|
| |
There ended up being too many corner cases for the generalized formatter
to handle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The payee directive allows for transformation of payee names during the
parsing of a Ledger file. This means you can record the payee name in
one form, but always have it reported in another form. The syntax is
(and will be):
payee PAYEE_NAME REGEXP
or
payee PAYEE_NAME
REGEXP1
REGEXP2
...
The account directive sets the account automatically based on the payee
iff the base account name is Unknown. For example, if you have a bunch
of transaction in Expenses:Unknown, you can assign accounts for several
automatically using:
account ACCOUNT_NAME PAYEE_REGEXP
or
account ACCOUNT_NAME
PAYEE_REGEXP1
PAYEE_REGEXP2
...
|
| |
|
| |
|
|
|
|
|
| |
This indicates the absolute parsing order of every transaction and
posting. It is 0 for generated items.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It lets you specify a fixed cost for a duration of a ledger file, for
example:
fixed ecu $2
2008/01/01 income
assets:bank:checking 1 ecu
income:salary
end fixed
This is equivalent to:
2008/01/01 income
assets:bank:checking 1 ecu {=$2}
income:salary
|
| |
|
| |
|
|
|
|
|
| |
Now you must specify "account / end account", and "tag / end tag". For
backwards compatability, plain "end" is the same as "end account".
|
|
|
|
|
| |
This was from an earlier time, when it was intended to be used by
Python. But it's not needed anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Example of a tagged entry:
i 2009/11/01 12:00:00 Account Payee ; :Foo:
o 2009/11/01 13:00:00
Two spaces or a tab must separate account from payee, and payee from
note.
|
| |
|
|
|
|
| |
This returns their behavior back very close to what 2.x accepts.
|
| |
|
| |
|
| |
|