| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Also, support matching provided hashes against a prefixed of the generated
hash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following details of a posting contribute to its hash:
fullname of account
string representation of amount
Each posting hashes contributes to the transaction hash, which is compromised
of:
previous transaction’s hash (as encountered in parsing order)
actual date
optional auxiliary date
optional code
payee
hashes of all postings
Note that this means that changes in the “code” or any of the comments
|
| |
|
|
|
|
| |
[skip ci]
|
| |
|
|
|
|
| |
Fixes #2049
|
|
|
|
|
|
| |
Fixes:
Error: boost::bad_format_string: format-string is ill-formed
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
and all boost serialisation related code.
|
|
|
|
|
|
| |
The following script makes it a no-brainer:
% NEXT_YEAR=2015; ag -l 'Copyright.*Wiegley' \
| xargs sed -i '' -e "s/\(Copyright.*\)-20[0-9]\{2\}/\1-${NEXT_YEAR}/"
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
This gains another 15% for the parser, again with a very simple change
that has no impact if the fast predicate matcher fails to work.
|
|
|
|
|
|
| |
This reduces parsing time in the optimized build by 25%, and was a safe,
easy patch. If the "quick predicate evaluator" fails, we disable it
from that point on go back to what the standard code does.
|
| |
|
|
|
|
|
| |
This way you cannot violate the balancing rules, not even by adding a
stray posting via an automated transaction.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The different namespaces are:
Function Value expression functions, which receive a "context"
Option Command-line options
Precommand Commands which are invoked before reading the journal
Command Commands which are invoked after reading the journal
Directive Directives that occur at column 0 in a data file
This greatly eases the ability for Python uses to add intercept hooks to
change how the basic Ledger module functions. An example of what should
be possible soon:
import ledger
def my_foo_handler(value):
print "--foo received:", value
ledger.add_handler(ledger.Option, "foo=", my_foo_handler)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows journal_t objects to be completed serialized to disk and
deserialized.
|