| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This resolves certain issues where value expressions were not being
looked up within their full context.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This creates its own problems; instead, only most are used.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
For example, in period reports null transactions are only generated for
empty periods if --empty is used. Otherwise, the presence of such
transactions can get confusing.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This means item_predicate is no longer a template.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, account-wise reports used a subset of the total number of
transaction filters, but this could cause confusing results, and made
some reports immpossible (such as account-wise monthly averages).
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
You now call session_t::close_journal_files() followed by
session_t::read_journal_files().
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This way the value shown follows the current reporting options.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since cost reports are now calculated by setting the amount_ expression,
there is no need to track a separate "total cost" entity.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now one does:
parent->HANDLER(display_total_).set_expr("total");
Rather than what was required previously:
parent->HANDLER(display_total_).on("total");
parent->HANDLER(display_total_).expr = "total";
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
xact_t::add_to_value, in cases where the xact had a "compound" total,
was adding transaction values to the running total twice.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This allows reports to access the "whicheth" index of the reported
transaction. It's used mainly by the --average report, which divides
the running total by this count to get the arithmetic mean.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
For example, if one uses -M to generate a monthly report for an entire
year, and there are no transaction in the month of February, ordinarily
Ledger would report nothing for that month, even if -E were used. Now
"null transactions" are generated for periods without any activity, in
order to make certain reports -- such as running monthly averages --
more accurate.
For example, instead of -MA being just a monthly running average of
months with activity, it is now a true average among all months during
the reported period.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
That is, if a metadata tag cannot be found in a transaction, look in the
parent entry to see if it was set there. Transactions "inherit"
notational details from their entries.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The previous behavior was to trigger a confusing assertion.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Note that the --uncleared flag includes --pending, since it specifically
means "not yet cleared".
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The prices report now uses the following scheme:
PAYEE -> name of commodity of price
ACCOUNT -> name of commodity of item
AMOUNT -> price
DATE -> date of pricing
However, the report does not show the payee. The only reason the payee
is set is to enable clever querying. For example:
ledger prices gold # show all known prices for GOLD
ledger prices @gold # show all known prices *in* GOLD
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is done in the value code, which knows -- based on the value's type
-- how best to apply the justification.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It now shows the formatted result against a sample entry, similar to
what "parse" now does.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
That is, if the user didn't enter an amount for that transaction in
their ledger journal, don't print one out either.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
However, the budget reports themselves still need to be tested.
|