| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #188 / 53BCED29-F3B9-4E02-9A35-6C739ABB9662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The --group-by option allows for most reports to be split up into
sections based on the varying value of EXPR. For example, to see
register subtotals by payee, use:
ledger reg --group-by=payee -s
This works for separated balances too:
ledger bal --group-by=payee
Another interesting possibility is seeing a register of all the accounts
affected by a related account:
ledger reg -r --group-by=payee
The option --group-title-format can be used to add a separator bar to
the group titles. The option --no-titles can be used to drop titles
altogether.
|
| |
|
|
|
|
|
|
|
|
| |
The purpose of this option is to add special "<Rounding>" postings, to
ensure that a regiter's running total is *always* the sum of its
postings. Within --rounding, these adjustment postings are missing,
which was the behavior in Ledger 2.x. It can be orders of magnitude
slower to turn it on for large reports with many commodities.
|
| |
|
|
|
|
| |
The switches the default back to the same as 2.x, which is --unsorted.
|
| |
|
|
|
|
|
|
| |
This is equivalent to the following:
--account='"TAG:" + tag(/TAG/)'
|
|
|
|
|
|
| |
When this option is on, then in balance report which show market values,
any gains or losses in value will be balanced into a pair of accounts
called Equity:Unrealized Gains and Equity:Unrealized Losses.
|
| |
|
| |
|
|
|
|
|
|
| |
It used to be "account_wise", since it only happens for non-account-wise
reports. Now it's called just "calc_running_total", so anyone can
request it.
|
| |
|
|
|
|
|
|
|
| |
This lets you do things like store a date as the value of a tag, then
run:
ledger --date='has_tag("Foo") ? to_date(tag("Foo")) : date' reg
|
| |
|
|
|
|
|
|
|
| |
This fits better with the --amount and --total options, which both
change the amount and total used for calculation. Same with --account:
it happens after filtering, but before calculation so that balance
reports look as you'd expect.
|
| |
|
|
|
|
|
| |
This sets how many years of forecasting Ledger will do before it
terminates the attempt.
|
|
|
|
| |
The journal_t now completely represents the data part of a session.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This option sets the total by which revalued transactions are
determined. Only needed if the display total is not appropriate.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The purpose of this option is that usually when you do a --monthly
periodic report, you see dates ranges from the first day of each month,
to the last day. With --exact, the first day of each range will be the
date of the first transaction found in that range, and likewise with the
end of the range. Essentially it "contracts" the reported period dates
to reflect the exact begin and end dates.
|
| |
|
|
|
|
|
|
| |
The old implementation used an account formatter, and was very
specialized. The new is done as a transaction filter, and works along
with everything else, eliminating bugs special to the equity report.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It now takes the --display and --only predicates into account, so that
it never appears to be collapsing single transactions.
There are cases where there are multiple transactions, but the display
or only predicate filters them out, so that if collapse didn't consider
this, the user would wonder why a single transaction was being collapsed
-- since they'd never see that collapse saw more than two.
|
|
|
|
|
|
| |
These fully generalize the previous --payee-as-account and such options,
which, for example, is now implemented to be the same as saying,
"--set-account payee".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To help with gathering specific reports:
- --payee-as-account copies the entry's payee field to the account,
allowing the subtotal report to show unique payees for each period.
- --comm-as-account copies the transaction's amount's commodity to the
account.
- --code-as-account copies the entry's code to the account
Also created aliases for some of these options, for conistency's sake:
- --commodity-as-payee is now an alias for --comm-as-payee
- --commodity-as-account is now an alias for --comm-as-account
|
| |
|
|
|
|
|
| |
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).
|
| |
|
| |
|