| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
With -s, -M/Y/D, -n, and a few other flags, postings get "grouped" into
meta-transactions that contain more postings than before. In all these
cases, -V use the date of the *earliest* posting in that group, which
makes little sense and caused breakages with -J. It now uses the latest
date.
Fixes #197 / 68EAF363-D0FE-4127-866E-A5AEBACB65D6
|
|
|
|
| |
Fixes #226 / C1C1E731-D991-40ED-BE43-8ED55585386C
|
|
|
|
|
| |
account_id is the "whicheth" number for that posting within its
account. The xact_id is within its transaction.
|
|
|
|
|
| |
There ended up being too many corner cases for the generalized formatter
to handle.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is necessary because sometimes, a post from one account will get
reported as though it were in another account (this happens with
--budget, to show child account postings within their parent account).
In that case, the account needs to remember which postings have been
reported as being within it, so that it can add these amounts to its own
total in the balance report.
|
|
|
|
|
| |
This allows journal_t objects to be completed serialized to disk and
deserialized.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This way, if the running total is off by a penny or two due to rounding
of one or more commodities in the account, the user will see it.
This commit also reorganizes the testing code a bit, which I did after
adding the ninth test series (ConfirmTests), to validate the new
rounding code.
|
| |
|
| |
|
|
The last commit did not contain the majority of changes because of a
slight mishap. This contains the real changeset.
|