;doc: regen manuals
[ci skip]
This commit is contained in:
parent
150a74c5a0
commit
06a54f70b0
@ -30,120 +30,91 @@ the add or web commands to create and update it.
|
||||
Many users, though, also edit the journal file directly with a text
|
||||
editor, perhaps assisted by the helper modes for emacs or vim.
|
||||
.PP
|
||||
Here\[aq]s an example:
|
||||
Helper modes exist for popular text editors, which make working with
|
||||
journal files easier.
|
||||
They add colour, formatting, tab completion, and helpful commands, and
|
||||
are quite recommended if you edit your journal with a text editor.
|
||||
They include ledger-mode or hledger-mode for Emacs, vim-ledger for Vim,
|
||||
hledger-vscode for Visual Studio Code, and others.
|
||||
See the Editor configuration at hledger.org for the latest information.
|
||||
.SH FILE FORMAT
|
||||
.PP
|
||||
Here\[aq]s a description of each part of the file format (and
|
||||
hledger\[aq]s data model).
|
||||
These are mostly in the order you\[aq]ll use them, but in some cases
|
||||
related concepts have been grouped together for easy reference, or
|
||||
linked before they are introduced, so feel free to skip over anything
|
||||
that looks unnecessary right now.
|
||||
.SS Transactions
|
||||
.PP
|
||||
Transactions are the main unit of information in a journal file.
|
||||
They represent events, typically a movement of some quantity of
|
||||
commodities between two or more named accounts.
|
||||
.PP
|
||||
Each transaction is recorded as a journal entry, beginning with a simple
|
||||
date in column 0.
|
||||
This can be followed by any of the following optional fields, separated
|
||||
by spaces:
|
||||
.IP \[bu] 2
|
||||
a status character (empty, \f[C]!\f[R], or \f[C]*\f[R])
|
||||
.IP \[bu] 2
|
||||
a code (any short number or text, enclosed in parentheses)
|
||||
.IP \[bu] 2
|
||||
a description (any remaining text until end of line or a semicolon)
|
||||
.IP \[bu] 2
|
||||
a comment (any remaining text following a semicolon until end of line,
|
||||
and any following indented lines beginning with a semicolon)
|
||||
.IP \[bu] 2
|
||||
0 or more indented \f[I]posting\f[R] lines, describing what was
|
||||
transferred and the accounts involved.
|
||||
.PP
|
||||
Here\[aq]s a simple journal file containing one transaction:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
; A sample journal file. This is a comment.
|
||||
|
||||
2008/01/01 income ; <- transaction\[aq]s first line starts in column 0, contains date and description
|
||||
assets:bank:checking $1 ; <- posting lines start with whitespace, each contains an account name
|
||||
income:salary $-1 ; followed by at least two spaces and an amount
|
||||
|
||||
2008/06/01 gift
|
||||
assets:bank:checking $1 ; <- at least two postings in a transaction
|
||||
income:gifts $-1 ; <- their amounts must balance to 0
|
||||
|
||||
2008/06/02 save
|
||||
assets:bank:saving $1
|
||||
assets:bank:checking ; <- one amount may be omitted; here $-1 is inferred
|
||||
|
||||
2008/06/03 eat & shop ; <- description can be anything
|
||||
expenses:food $1
|
||||
expenses:supplies $1 ; <- this transaction debits two expense accounts
|
||||
assets:cash ; <- $-2 inferred
|
||||
|
||||
2008/10/01 take a loan
|
||||
assets:bank:checking $1
|
||||
liabilities:debts $-1
|
||||
|
||||
2008/12/31 * pay off ; <- an optional * or ! after the date means \[dq]cleared\[dq] (or anything you want)
|
||||
liabilities:debts $1
|
||||
assets:bank:checking
|
||||
2008/01/01 income
|
||||
assets:bank:checking $1
|
||||
income:salary $-1
|
||||
\f[R]
|
||||
.fi
|
||||
.SH FILE FORMAT
|
||||
.SS Transactions
|
||||
.PP
|
||||
Transactions are movements of some quantity of commodities between named
|
||||
accounts.
|
||||
Each transaction is represented by a journal entry beginning with a
|
||||
simple date in column 0.
|
||||
This can be followed by any of the following, separated by spaces:
|
||||
.IP \[bu] 2
|
||||
(optional) a status character (empty, \f[C]!\f[R], or \f[C]*\f[R])
|
||||
.IP \[bu] 2
|
||||
(optional) a transaction code (any short number or text, enclosed in
|
||||
parentheses)
|
||||
.IP \[bu] 2
|
||||
(optional) a transaction description (any remaining text until end of
|
||||
line or a semicolon)
|
||||
.IP \[bu] 2
|
||||
(optional) a transaction comment (any remaining text following a
|
||||
semicolon until end of line)
|
||||
.PP
|
||||
Then comes zero or more (but usually at least 2) indented lines
|
||||
representing...
|
||||
.SS Postings
|
||||
.PP
|
||||
A posting is an addition of some amount to, or removal of some amount
|
||||
from, an account.
|
||||
Each posting line begins with at least one space or tab (2 or 4 spaces
|
||||
is common), followed by:
|
||||
.IP \[bu] 2
|
||||
(optional) a status character (empty, \f[C]!\f[R], or \f[C]*\f[R]),
|
||||
followed by a space
|
||||
.IP \[bu] 2
|
||||
(required) an account name (any text, optionally containing \f[B]single
|
||||
spaces\f[R], until end of line or a double space)
|
||||
.IP \[bu] 2
|
||||
(optional) \f[B]two or more spaces\f[R] or tabs followed by an amount.
|
||||
.PP
|
||||
Positive amounts are being added to the account, negative amounts are
|
||||
being removed.
|
||||
.PP
|
||||
The amounts within a transaction must always sum up to zero.
|
||||
As a convenience, one amount may be left blank; it will be inferred so
|
||||
as to balance the transaction.
|
||||
.PP
|
||||
Be sure to note the unusual two-space delimiter between account name and
|
||||
amount.
|
||||
This makes it easy to write account names containing spaces.
|
||||
But if you accidentally leave only one space (or tab) before the amount,
|
||||
the amount will be considered part of the account name.
|
||||
.SS Dates
|
||||
.SS Simple dates
|
||||
.PP
|
||||
Within a journal file, transaction dates use Y/M/D (or Y-M-D or Y.M.D)
|
||||
Leading zeros are optional.
|
||||
Dates in the journal file use \f[I]simple dates\f[R] format:
|
||||
\f[C]YYYY-MM-DD\f[R] or \f[C]YYYY/MM/DD\f[R] or \f[C]YYYY.MM.DD\f[R],
|
||||
with leading zeros optional.
|
||||
The year may be omitted, in which case it will be inferred from the
|
||||
context - the current transaction, the default year set with a default
|
||||
context: the current transaction, the default year set with a default
|
||||
year directive, or the current date when the command is run.
|
||||
Some examples: \f[C]2010/01/31\f[R], \f[C]1/31\f[R],
|
||||
\f[C]2010-01-31\f[R], \f[C]2010.1.31\f[R].
|
||||
Some examples: \f[C]2010-01-31\f[R], \f[C]2010/01/31\f[R],
|
||||
\f[C]2010.1.31\f[R], \f[C]1/31\f[R].
|
||||
.PP
|
||||
(The UI also accepts simple dates, as well as the more flexible smart
|
||||
dates documented in the hledger manual.)
|
||||
.SS Secondary dates
|
||||
.PP
|
||||
Real-life transactions sometimes involve more than one date - eg the
|
||||
date you write a cheque, and the date it clears in your bank.
|
||||
When you want to model this, eg for more accurate balances, you can
|
||||
specify individual posting dates, which I recommend.
|
||||
Or, you can use the secondary dates (aka auxiliary/effective dates)
|
||||
feature, supported for compatibility with Ledger.
|
||||
specify individual posting dates.
|
||||
.PP
|
||||
A secondary date can be written after the primary date, separated by an
|
||||
equals sign.
|
||||
The primary date, on the left, is used by default; the secondary date,
|
||||
on the right, is used when the \f[C]--date2\f[R] flag is specified
|
||||
(\f[C]--aux-date\f[R] or \f[C]--effective\f[R] also work).
|
||||
Or, you can use the older \f[I]secondary date\f[R] feature.
|
||||
(Ledger calls it auxiliary date or effective date.) But I would
|
||||
recommend avoiding this feature; posting dates are almost always clearer
|
||||
and simpler.
|
||||
We support it mainly for compatibility.
|
||||
.PP
|
||||
A secondary date is written after the primary date, following an equals
|
||||
sign.
|
||||
The primary date\[aq]s year will be used if the year is omitted.
|
||||
When running reports, the primary (left) date is used by default, but
|
||||
with the \f[C]--date2\f[R] flag (or \f[C]--aux-date\f[R] or
|
||||
\f[C]--effective\f[R]), the secondary (right) date will be used instead.
|
||||
.PP
|
||||
The meaning of secondary dates is up to you, but it\[aq]s best to follow
|
||||
a consistent rule.
|
||||
Eg write the bank\[aq]s clearing date as primary, and when needed, the
|
||||
date the transaction was initiated as secondary.
|
||||
.PP
|
||||
Here\[aq]s an example.
|
||||
Note that a secondary date will use the year of the primary date if
|
||||
unspecified.
|
||||
Eg \[dq]primary = the bank\[aq]s clearing date, secondary = date the
|
||||
transaction was initiated, if different\[dq], as shown here:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
@ -166,12 +137,6 @@ $ hledger register checking --date2
|
||||
2010-02-19 movie ticket assets:checking $-10 $-10
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Secondary dates require some effort; you must use them consistently in
|
||||
your journal entries and remember whether to use or not use the
|
||||
\f[C]--date2\f[R] flag for your reports.
|
||||
They are included in hledger for Ledger compatibility, but posting dates
|
||||
are a more powerful and less confusing alternative.
|
||||
.SS Posting dates
|
||||
.PP
|
||||
You can give individual postings a different date from their parent
|
||||
@ -320,6 +285,178 @@ payee/payer name on the left (up to the first \f[C]|\f[R]) and an
|
||||
additional note field on the right (after the first \f[C]|\f[R]).
|
||||
This may be worthwhile if you need to do more precise querying and
|
||||
pivoting by payee or by note.
|
||||
.SS Comments
|
||||
.PP
|
||||
Lines in the journal beginning with a semicolon (\f[C];\f[R]) or hash
|
||||
(\f[C]#\f[R]) or star (\f[C]*\f[R]) are comments, and will be ignored.
|
||||
(Star comments cause org-mode nodes to be ignored, allowing emacs users
|
||||
to fold and navigate their journals with org-mode or orgstruct-mode.)
|
||||
.PP
|
||||
You can attach comments to a transaction by writing them after the
|
||||
description and/or indented on the following lines (before the
|
||||
postings).
|
||||
Similarly, you can attach comments to an individual posting by writing
|
||||
them after the amount and/or indented on the following lines.
|
||||
Transaction and posting comments must begin with a semicolon
|
||||
(\f[C];\f[R]).
|
||||
.PP
|
||||
Some examples:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
# a file comment
|
||||
|
||||
; also a file comment
|
||||
|
||||
comment
|
||||
This is a multiline file comment,
|
||||
which continues until a line
|
||||
where the \[dq]end comment\[dq] string
|
||||
appears on its own (or end of file).
|
||||
end comment
|
||||
|
||||
2012/5/14 something ; a transaction comment
|
||||
; the transaction comment, continued
|
||||
posting1 1 ; a comment for posting 1
|
||||
posting2
|
||||
; a comment for posting 2
|
||||
; another comment line for posting 2
|
||||
; a file comment (because not indented)
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
You can also comment larger regions of a file using \f[C]comment\f[R]
|
||||
and \f[C]end comment\f[R] directives.
|
||||
.SS Tags
|
||||
.PP
|
||||
Tags are a way to add extra labels or labelled data to postings and
|
||||
transactions, which you can then search or pivot on.
|
||||
.PP
|
||||
A simple tag is a word (which may contain hyphens) followed by a full
|
||||
colon, written inside a transaction or posting comment line:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2017/1/16 bought groceries ; sometag:
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Tags can have a value, which is the text after the colon, up to the next
|
||||
comma or end of line, with leading/trailing whitespace removed:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
expenses:food $10 ; a-posting-tag: the tag value
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Note this means hledger\[aq]s tag values can not contain commas or
|
||||
newlines.
|
||||
Ending at commas means you can write multiple short tags on one line,
|
||||
comma separated:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
assets:checking ; a comment containing tag1:, tag2: some value ...
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Here,
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]a comment containing\f[R]\[dq] is just comment text, not a tag
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]tag1\f[R]\[dq] is a tag with no value
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]tag2\f[R]\[dq] is another tag, whose value is
|
||||
\[dq]\f[C]some value ...\f[R]\[dq]
|
||||
.PP
|
||||
Tags in a transaction comment affect the transaction and all of its
|
||||
postings, while tags in a posting comment affect only that posting.
|
||||
For example, the following transaction has three tags (\f[C]A\f[R],
|
||||
\f[C]TAG2\f[R], \f[C]third-tag\f[R]) and the posting has four (those
|
||||
plus \f[C]posting-tag\f[R]):
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 a transaction ; A:, TAG2:
|
||||
; third-tag: a third transaction tag, <- with a value
|
||||
(a) $1 ; posting-tag:
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Tags are like Ledger\[aq]s metadata feature, except hledger\[aq]s tag
|
||||
values are simple strings.
|
||||
.SS Postings
|
||||
.PP
|
||||
A posting is an addition of some amount to, or removal of some amount
|
||||
from, an account.
|
||||
Each posting line begins with at least one space or tab (2 or 4 spaces
|
||||
is common), followed by:
|
||||
.IP \[bu] 2
|
||||
(optional) a status character (empty, \f[C]!\f[R], or \f[C]*\f[R]),
|
||||
followed by a space
|
||||
.IP \[bu] 2
|
||||
(required) an account name (any text, optionally containing \f[B]single
|
||||
spaces\f[R], until end of line or a double space)
|
||||
.IP \[bu] 2
|
||||
(optional) \f[B]two or more spaces\f[R] or tabs followed by an amount.
|
||||
.PP
|
||||
Positive amounts are being added to the account, negative amounts are
|
||||
being removed.
|
||||
.PP
|
||||
The amounts within a transaction must always sum up to zero.
|
||||
As a convenience, one amount may be left blank; it will be inferred so
|
||||
as to balance the transaction.
|
||||
.PP
|
||||
Be sure to note the unusual two-space delimiter between account name and
|
||||
amount.
|
||||
This makes it easy to write account names containing spaces.
|
||||
But if you accidentally leave only one space (or tab) before the amount,
|
||||
the amount will be considered part of the account name.
|
||||
.SS Virtual Postings
|
||||
.PP
|
||||
A posting with a parenthesised account name is called a \f[I]virtual
|
||||
posting\f[R] or \f[I]unbalanced posting\f[R], which means it is exempt
|
||||
from the usual rule that a transaction\[aq]s postings must balance add
|
||||
up to zero.
|
||||
.PP
|
||||
This is not part of double entry accounting, so you might choose to
|
||||
avoid this feature.
|
||||
Or you can use it sparingly for certain special cases where it can be
|
||||
convenient.
|
||||
Eg, you could set opening balances without using a balancing equity
|
||||
account:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 opening balances
|
||||
(assets:checking) $1000
|
||||
(assets:savings) $2000
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
A posting with a bracketed account name is called a \f[I]balanced
|
||||
virtual posting\f[R].
|
||||
The balanced virtual postings in a transaction must add up to zero
|
||||
(separately from other postings).
|
||||
Eg:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 buy food with cash, update budget envelope subaccounts, & something else
|
||||
assets:cash $-10 ; <- these balance
|
||||
expenses:food $7 ; <-
|
||||
expenses:food $3 ; <-
|
||||
[assets:checking:budget:food] $-10 ; <- and these balance
|
||||
[assets:checking:available] $10 ; <-
|
||||
(something:else) $5 ; <- not required to balance
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Ordinary non-parenthesised, non-bracketed postings are called \f[I]real
|
||||
postings\f[R].
|
||||
You can exclude virtual postings from reports with the
|
||||
\f[C]-R/--real\f[R] flag or \f[C]real:1\f[R] query.
|
||||
.SS Account names
|
||||
.PP
|
||||
Account names typically have several parts separated by a full colon,
|
||||
@ -465,47 +602,99 @@ indirectly.
|
||||
amount, or when an amountless posting is balanced using a price\[aq]s
|
||||
commodity, or when -V is used.) If you find this causing problems, use a
|
||||
commodity directive to set the display format.
|
||||
.SS Virtual Postings
|
||||
.SS Transaction prices
|
||||
.PP
|
||||
When you parenthesise the account name in a posting, we call that a
|
||||
\f[I]virtual posting\f[R], which means:
|
||||
.IP \[bu] 2
|
||||
it is ignored when checking that the transaction is balanced
|
||||
.IP \[bu] 2
|
||||
it is excluded from reports when the \f[C]--real/-R\f[R] flag is used,
|
||||
or the \f[C]real:1\f[R] query.
|
||||
Within a transaction, you can note an amount\[aq]s price in another
|
||||
commodity.
|
||||
This can be used to document the cost (in a purchase) or selling price
|
||||
(in a sale).
|
||||
For example, transaction prices are useful to record purchases of a
|
||||
foreign currency.
|
||||
Note transaction prices are fixed at the time of the transaction, and do
|
||||
not change over time.
|
||||
See also market prices, which represent prevailing exchange rates on a
|
||||
certain date.
|
||||
.PP
|
||||
You could use this, eg, to set an account\[aq]s opening balance without
|
||||
needing to use the \f[C]equity:opening balances\f[R] account:
|
||||
There are several ways to record a transaction price:
|
||||
.IP "1." 3
|
||||
Write the price per unit, as \f[C]\[at] UNITPRICE\f[R] after the amount:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 special unbalanced posting to set initial balance
|
||||
(assets:checking) $1000
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 \[at] $1.35 ; one hundred euros purchased at $1.35 each
|
||||
assets:dollars ; balancing amount is -$135.00
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
When the account name is bracketed, we call it a \f[I]balanced virtual
|
||||
posting\f[R].
|
||||
This is like an ordinary virtual posting except the balanced virtual
|
||||
postings in a transaction must balance to 0, like the real postings (but
|
||||
separately from them).
|
||||
Balanced virtual postings are also excluded by \f[C]--real/-R\f[R] or
|
||||
\f[C]real:1\f[R].
|
||||
.RE
|
||||
.IP "2." 3
|
||||
Write the total price, as \f[C]\[at]\[at] TOTALPRICE\f[R] after the
|
||||
amount:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 buy food with cash, and update some budget-tracking subaccounts elsewhere
|
||||
expenses:food $10
|
||||
assets:cash $-10
|
||||
[assets:checking:available] $10
|
||||
[assets:checking:budget:food] $-10
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 \[at]\[at] $135 ; one hundred euros purchased at $135 for the lot
|
||||
assets:dollars
|
||||
\f[R]
|
||||
.fi
|
||||
.RE
|
||||
.IP "3." 3
|
||||
Specify amounts for all postings, using exactly two commodities, and let
|
||||
hledger infer the price that balances the transaction:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 ; one hundred euros purchased
|
||||
assets:dollars $-135 ; for $135
|
||||
\f[R]
|
||||
.fi
|
||||
.RE
|
||||
.PP
|
||||
(Ledger users: Ledger uses a different syntax for fixed prices,
|
||||
\f[C]{=UNITPRICE}\f[R], which hledger currently ignores).
|
||||
.PP
|
||||
Use the \f[C]-B/--cost\f[R] flag to convert amounts to their transaction
|
||||
price\[aq]s commodity, if any.
|
||||
(mnemonic: \[dq]B\[dq] is from \[dq]cost Basis\[dq], as in Ledger).
|
||||
Eg here is how -B affects the balance report for the example above:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
$ hledger bal -N --flat
|
||||
$-135 assets:dollars
|
||||
\[Eu]100 assets:euros
|
||||
$ hledger bal -N --flat -B
|
||||
$-135 assets:dollars
|
||||
$135 assets:euros # <- the euros\[aq] cost
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Virtual postings have some legitimate uses, but those are few.
|
||||
You can usually find an equivalent journal entry using real postings,
|
||||
which is more correct and provides better error checking.
|
||||
Note -B is sensitive to the order of postings when a transaction price
|
||||
is inferred: the inferred price will be in the commodity of the last
|
||||
amount.
|
||||
So if example 3\[aq]s postings are reversed, while the transaction is
|
||||
equivalent, -B shows something different:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:dollars $-135 ; 135 dollars sold
|
||||
assets:euros \[Eu]100 ; for 100 euros
|
||||
\f[R]
|
||||
.fi
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
$ hledger bal -N --flat -B
|
||||
\[Eu]-100 assets:dollars # <- the dollars\[aq] selling price
|
||||
\[Eu]100 assets:euros
|
||||
\f[R]
|
||||
.fi
|
||||
.SS Balance Assertions
|
||||
.PP
|
||||
hledger supports Ledger-style balance assertions in journal files.
|
||||
@ -722,200 +911,6 @@ $ hledger print --explicit
|
||||
(a) $1 \[at] \[Eu]2 = $1 \[at] \[Eu]2
|
||||
\f[R]
|
||||
.fi
|
||||
.SS Transaction prices
|
||||
.PP
|
||||
Within a transaction, you can note an amount\[aq]s price in another
|
||||
commodity.
|
||||
This can be used to document the cost (in a purchase) or selling price
|
||||
(in a sale).
|
||||
For example, transaction prices are useful to record purchases of a
|
||||
foreign currency.
|
||||
Note transaction prices are fixed at the time of the transaction, and do
|
||||
not change over time.
|
||||
See also market prices, which represent prevailing exchange rates on a
|
||||
certain date.
|
||||
.PP
|
||||
There are several ways to record a transaction price:
|
||||
.IP "1." 3
|
||||
Write the price per unit, as \f[C]\[at] UNITPRICE\f[R] after the amount:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 \[at] $1.35 ; one hundred euros purchased at $1.35 each
|
||||
assets:dollars ; balancing amount is -$135.00
|
||||
\f[R]
|
||||
.fi
|
||||
.RE
|
||||
.IP "2." 3
|
||||
Write the total price, as \f[C]\[at]\[at] TOTALPRICE\f[R] after the
|
||||
amount:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 \[at]\[at] $135 ; one hundred euros purchased at $135 for the lot
|
||||
assets:dollars
|
||||
\f[R]
|
||||
.fi
|
||||
.RE
|
||||
.IP "3." 3
|
||||
Specify amounts for all postings, using exactly two commodities, and let
|
||||
hledger infer the price that balances the transaction:
|
||||
.RS 4
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:euros \[Eu]100 ; one hundred euros purchased
|
||||
assets:dollars $-135 ; for $135
|
||||
\f[R]
|
||||
.fi
|
||||
.RE
|
||||
.PP
|
||||
(Ledger users: Ledger uses a different syntax for fixed prices,
|
||||
\f[C]{=UNITPRICE}\f[R], which hledger currently ignores).
|
||||
.PP
|
||||
Use the \f[C]-B/--cost\f[R] flag to convert amounts to their transaction
|
||||
price\[aq]s commodity, if any.
|
||||
(mnemonic: \[dq]B\[dq] is from \[dq]cost Basis\[dq], as in Ledger).
|
||||
Eg here is how -B affects the balance report for the example above:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
$ hledger bal -N --flat
|
||||
$-135 assets:dollars
|
||||
\[Eu]100 assets:euros
|
||||
$ hledger bal -N --flat -B
|
||||
$-135 assets:dollars
|
||||
$135 assets:euros # <- the euros\[aq] cost
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Note -B is sensitive to the order of postings when a transaction price
|
||||
is inferred: the inferred price will be in the commodity of the last
|
||||
amount.
|
||||
So if example 3\[aq]s postings are reversed, while the transaction is
|
||||
equivalent, -B shows something different:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2009/1/1
|
||||
assets:dollars $-135 ; 135 dollars sold
|
||||
assets:euros \[Eu]100 ; for 100 euros
|
||||
\f[R]
|
||||
.fi
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
$ hledger bal -N --flat -B
|
||||
\[Eu]-100 assets:dollars # <- the dollars\[aq] selling price
|
||||
\[Eu]100 assets:euros
|
||||
\f[R]
|
||||
.fi
|
||||
.SS Comments
|
||||
.PP
|
||||
Lines in the journal beginning with a semicolon (\f[C];\f[R]) or hash
|
||||
(\f[C]#\f[R]) or star (\f[C]*\f[R]) are comments, and will be ignored.
|
||||
(Star comments cause org-mode nodes to be ignored, allowing emacs users
|
||||
to fold and navigate their journals with org-mode or orgstruct-mode.)
|
||||
.PP
|
||||
You can attach comments to a transaction by writing them after the
|
||||
description and/or indented on the following lines (before the
|
||||
postings).
|
||||
Similarly, you can attach comments to an individual posting by writing
|
||||
them after the amount and/or indented on the following lines.
|
||||
Transaction and posting comments must begin with a semicolon
|
||||
(\f[C];\f[R]).
|
||||
.PP
|
||||
Some examples:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
# a file comment
|
||||
|
||||
; also a file comment
|
||||
|
||||
comment
|
||||
This is a multiline file comment,
|
||||
which continues until a line
|
||||
where the \[dq]end comment\[dq] string
|
||||
appears on its own (or end of file).
|
||||
end comment
|
||||
|
||||
2012/5/14 something ; a transaction comment
|
||||
; the transaction comment, continued
|
||||
posting1 1 ; a comment for posting 1
|
||||
posting2
|
||||
; a comment for posting 2
|
||||
; another comment line for posting 2
|
||||
; a file comment (because not indented)
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
You can also comment larger regions of a file using \f[C]comment\f[R]
|
||||
and \f[C]end comment\f[R] directives.
|
||||
.SS Tags
|
||||
.PP
|
||||
Tags are a way to add extra labels or labelled data to postings and
|
||||
transactions, which you can then search or pivot on.
|
||||
.PP
|
||||
A simple tag is a word (which may contain hyphens) followed by a full
|
||||
colon, written inside a transaction or posting comment line:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
2017/1/16 bought groceries ; sometag:
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Tags can have a value, which is the text after the colon, up to the next
|
||||
comma or end of line, with leading/trailing whitespace removed:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
expenses:food $10 ; a-posting-tag: the tag value
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Note this means hledger\[aq]s tag values can not contain commas or
|
||||
newlines.
|
||||
Ending at commas means you can write multiple short tags on one line,
|
||||
comma separated:
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
assets:checking ; a comment containing tag1:, tag2: some value ...
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Here,
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]a comment containing\f[R]\[dq] is just comment text, not a tag
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]tag1\f[R]\[dq] is a tag with no value
|
||||
.IP \[bu] 2
|
||||
\[dq]\f[C]tag2\f[R]\[dq] is another tag, whose value is
|
||||
\[dq]\f[C]some value ...\f[R]\[dq]
|
||||
.PP
|
||||
Tags in a transaction comment affect the transaction and all of its
|
||||
postings, while tags in a posting comment affect only that posting.
|
||||
For example, the following transaction has three tags (\f[C]A\f[R],
|
||||
\f[C]TAG2\f[R], \f[C]third-tag\f[R]) and the posting has four (those
|
||||
plus \f[C]posting-tag\f[R]):
|
||||
.IP
|
||||
.nf
|
||||
\f[C]
|
||||
1/1 a transaction ; A:, TAG2:
|
||||
; third-tag: a third transaction tag, <- with a value
|
||||
(a) $1 ; posting-tag:
|
||||
\f[R]
|
||||
.fi
|
||||
.PP
|
||||
Tags are like Ledger\[aq]s metadata feature, except hledger\[aq]s tag
|
||||
values are simple strings.
|
||||
.SS Directives
|
||||
.PP
|
||||
A directive is a line in the journal beginning with a special keyword,
|
||||
@ -1421,11 +1416,14 @@ account other:zoo
|
||||
would influence the position of \f[C]zoo\f[R] among
|
||||
\f[C]other\f[R]\[aq]s subaccounts, but not the position of
|
||||
\f[C]other\f[R] among the top-level accounts.
|
||||
This means: - you will sometimes declare parent accounts (eg
|
||||
\f[C]account other\f[R] above) that you don\[aq]t intend to post to,
|
||||
just to customize their display order - sibling accounts stay together
|
||||
(you couldn\[aq]t display \f[C]x:y\f[R] in between \f[C]a:b\f[R] and
|
||||
\f[C]a:c\f[R]).
|
||||
This means:
|
||||
.IP \[bu] 2
|
||||
you will sometimes declare parent accounts (eg \f[C]account other\f[R]
|
||||
above) that you don\[aq]t intend to post to, just to customize their
|
||||
display order
|
||||
.IP \[bu] 2
|
||||
sibling accounts stay together (you couldn\[aq]t display \f[C]x:y\f[R]
|
||||
in between \f[C]a:b\f[R] and \f[C]a:c\f[R]).
|
||||
.SS Rewriting accounts
|
||||
.PP
|
||||
You can define account alias rules which rewrite your account names, or
|
||||
@ -1876,15 +1874,6 @@ rules will have these tags added:
|
||||
.IP \[bu] 2
|
||||
\f[C]_modified:\f[R] - a hidden tag not appearing in the comment; this
|
||||
transaction was modified \[dq]just now\[dq].
|
||||
.SH EDITOR SUPPORT
|
||||
.PP
|
||||
Helper modes exist for popular text editors, which make working with
|
||||
journal files easier.
|
||||
They add colour, formatting, tab completion, and helpful commands, and
|
||||
are quite recommended if you edit your journal with a text editor.
|
||||
They include ledger-mode or hledger-mode for Emacs, vim-ledger for Vim,
|
||||
hledger-vscode for Visual Studio Code, and others.
|
||||
See the Editor configuration at hledger.org for the latest information.
|
||||
|
||||
|
||||
.SH "REPORTING BUGS"
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user