;doc: update manuals
This commit is contained in:
		
							parent
							
								
									9f8381426c
								
							
						
					
					
						commit
						8de85be658
					
				| @ -1,2 +1,2 @@ | ||||
| m4_dnl Date to show in man pages. Updated by "Shake manuals" | ||||
| m4_define({{_monthyear_}}, {{December 2021}})m4_dnl | ||||
| m4_define({{_monthyear_}}, {{April 2022}})m4_dnl | ||||
|  | ||||
| @ -1,2 +1,2 @@ | ||||
| m4_dnl Date to show in man pages. Updated by "Shake manuals" | ||||
| m4_define({{_monthyear_}}, {{December 2021}})m4_dnl | ||||
| m4_define({{_monthyear_}}, {{April 2022}})m4_dnl | ||||
|  | ||||
| @ -1,5 +1,5 @@ | ||||
| 
 | ||||
| .TH "HLEDGER-UI" "1" "December 2021" "hledger-ui-1.25.99 " "hledger User Manuals" | ||||
| .TH "HLEDGER-UI" "1" "April 2022" "hledger-ui-1.25.99 " "hledger User Manuals" | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
|  | ||||
| @ -548,4 +548,4 @@ SEE ALSO | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| hledger-ui-1.25.99               December 2021                   HLEDGER-UI(1) | ||||
| hledger-ui-1.25.99                April 2022                     HLEDGER-UI(1) | ||||
|  | ||||
| @ -1,2 +1,2 @@ | ||||
| m4_dnl Date to show in man pages. Updated by "Shake manuals" | ||||
| m4_define({{_monthyear_}}, {{December 2021}})m4_dnl | ||||
| m4_define({{_monthyear_}}, {{April 2022}})m4_dnl | ||||
|  | ||||
| @ -1,5 +1,5 @@ | ||||
| 
 | ||||
| .TH "HLEDGER-WEB" "1" "December 2021" "hledger-web-1.25.99 " "hledger User Manuals" | ||||
| .TH "HLEDGER-WEB" "1" "April 2022" "hledger-web-1.25.99 " "hledger User Manuals" | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
|  | ||||
| @ -585,4 +585,4 @@ SEE ALSO | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| hledger-web-1.25.99              December 2021                  HLEDGER-WEB(1) | ||||
| hledger-web-1.25.99               April 2022                    HLEDGER-WEB(1) | ||||
|  | ||||
| @ -1,2 +1,2 @@ | ||||
| m4_dnl Date to show in man pages. Updated by "Shake manuals" | ||||
| m4_define({{_monthyear_}}, {{December 2021}})m4_dnl | ||||
| m4_define({{_monthyear_}}, {{April 2022}})m4_dnl | ||||
|  | ||||
| @ -1,6 +1,6 @@ | ||||
| .\"t | ||||
| 
 | ||||
| .TH "HLEDGER" "1" "December 2021" "hledger-1.25.99 " "hledger User Manuals" | ||||
| .TH "HLEDGER" "1" "April 2022" "hledger-1.25.99 " "hledger User Manuals" | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| @ -1849,6 +1849,20 @@ two commodities, unbalanced). | ||||
| .IP \[bu] 2 | ||||
| but not, currently, from \[dq]more correct\[dq] multicommodity | ||||
| transactions (no \f[C]\[at]\f[R], multiple commodities, balanced). | ||||
| .PP | ||||
| There is another limitation (bug) currently: when a valuation commodity | ||||
| is not specified, prices inferred with \f[C]--infer-market-prices\f[R] | ||||
| do not help select a default valuation commodity, as \f[C]P\f[R] prices | ||||
| would. | ||||
| So conversion might not happen because no valuation commodity was | ||||
| detected (\f[C]--debug=2\f[R] will show this). | ||||
| To be safe, specify the valuation commmodity, eg: | ||||
| .IP \[bu] 2 | ||||
| \f[C]-X EUR --infer-market-prices\f[R], not | ||||
| \f[C]-V --infer-market-prices\f[R] | ||||
| .IP \[bu] 2 | ||||
| \f[C]--value=then,EUR --infer-market-prices\f[R], not | ||||
| \f[C]--value=then --infer-market-prices\f[R] | ||||
| .SS Valuation commodity | ||||
| .PP | ||||
| \f[B]When you specify a valuation commodity (\f[CB]-X COMM\f[B] or | ||||
| @ -2497,8 +2511,9 @@ Normally hledger sums amounts, and organizes them in a hierarchy, based | ||||
| on account name. | ||||
| The \f[C]--pivot FIELD\f[R] option causes it to sum and organize | ||||
| hierarchy based on the value of some other field instead. | ||||
| FIELD can be: \f[C]code\f[R], \f[C]description\f[R], \f[C]payee\f[R], | ||||
| \f[C]note\f[R], or the full name (case insensitive) of any tag. | ||||
| FIELD can be: \f[C]status\f[R], \f[C]code\f[R], \f[C]description\f[R], | ||||
| \f[C]payee\f[R], \f[C]note\f[R], or the full name (case insensitive) of | ||||
| any tag. | ||||
| As with account names, values containing \f[C]colon:separated:parts\f[R] | ||||
| will be displayed hierarchically in reports. | ||||
| .PP | ||||
| @ -3143,6 +3158,12 @@ the account\[aq]s historical running balance after this transaction. | ||||
| Transactions making a net change of zero are not shown by default; add | ||||
| the \f[C]-E/--empty\f[R] flag to show them. | ||||
| .PP | ||||
| For performance reasons, column widths are chosen based on the first | ||||
| 1000 lines; this means unusually wide values in later lines can cause | ||||
| visual discontinuities as column widths are adjusted. | ||||
| If you want to ensure perfect alignment, at the cost of more time and | ||||
| memory, use the \f[C]--align-all\f[R] flag. | ||||
| .PP | ||||
| This command also supports the output destination and output format | ||||
| options. | ||||
| The output formats supported are \f[C]txt\f[R], \f[C]csv\f[R], and | ||||
| @ -5523,6 +5544,12 @@ $ hledger register checking | ||||
| .PP | ||||
| With --date2, it shows and sorts by secondary date instead. | ||||
| .PP | ||||
| For performance reasons, column widths are chosen based on the first | ||||
| 1000 lines; this means unusually wide values in later lines can cause | ||||
| visual discontinuities as column widths are adjusted. | ||||
| If you want to ensure perfect alignment, at the cost of more time and | ||||
| memory, use the \f[C]--align-all\f[R] flag. | ||||
| .PP | ||||
| The \f[C]--historical\f[R]/\f[C]-H\f[R] flag adds the balance from any | ||||
| undisplayed prior postings to the running total. | ||||
| This is useful when you want to see only recent activity, with a | ||||
| @ -6090,19 +6117,30 @@ tags | ||||
| .PD 0 | ||||
| .P | ||||
| .PD | ||||
| List the unique tag names used in the journal. | ||||
| With a TAGREGEX argument, only tag names matching the regular expression | ||||
| (case insensitive) are shown. | ||||
| With QUERY arguments, only transactions matching the query are | ||||
| considered. | ||||
| List the tags used in the journal, or their values. | ||||
| .PP | ||||
| With the --values flag, the tags\[aq] unique values are listed instead. | ||||
| This command lists the tag names used in the journal, whether on | ||||
| transactions, postings, or account declarations. | ||||
| .PP | ||||
| With --parsed flag, all tags or values are shown in the order they are | ||||
| parsed from the input data, including duplicates. | ||||
| With a TAGREGEX argument, only tag names matching this regular | ||||
| expression (case insensitive, infix matched) are shown. | ||||
| .PP | ||||
| With -E/--empty, any blank/empty values will also be shown, otherwise | ||||
| they are omitted. | ||||
| With QUERY arguments, only transactions and accounts matching this query | ||||
| are considered. | ||||
| If the query involves transaction fields (date:, desc:, amt:, ...), the | ||||
| search is restricted to the matched transactions and their accounts. | ||||
| .PP | ||||
| With the --values flag, the tags\[aq] unique non-empty values are listed | ||||
| instead. | ||||
| With -E/--empty, blank/empty values are also shown. | ||||
| .PP | ||||
| With --parsed, tags or values are shown in the order they were parsed, | ||||
| with duplicates included. | ||||
| (Except, tags from account declarations are always shown first.) | ||||
| .PP | ||||
| Tip: remember, accounts also acquire tags from their parents, postings | ||||
| also acquire tags from their account and transaction, transactions also | ||||
| acquire tags from their postings. | ||||
| .SS test | ||||
| .PP | ||||
| test | ||||
| @ -7027,19 +7065,28 @@ break and require updating. | ||||
| This order dependence does bring an advantage: precise control over the | ||||
| order of postings and assertions within a day, so you can assert | ||||
| intra-day balances. | ||||
| .SS Assertions and included files | ||||
| .SS Assertions and multiple included files | ||||
| .PP | ||||
| With included files, things are a little more complicated. | ||||
| Including preserves the ordering of postings and assertions. | ||||
| If you have multiple postings to an account on the same day, split | ||||
| across different files, and you also want to assert the account\[aq]s | ||||
| balance on the same day, you\[aq]ll have to put the assertion in the | ||||
| right file. | ||||
| .SS Assertions and multiple -f options | ||||
| Multiple files included with the \f[C]include\f[R] directive are | ||||
| processed as if concatenated into one file, preserving their order and | ||||
| the posting order within each file. | ||||
| It means that balance assertions in later files will see balance from | ||||
| earlier files. | ||||
| .PP | ||||
| Balance assertions don\[aq]t work well across files specified with | ||||
| multiple -f options. | ||||
| Use include or concatenate the files instead. | ||||
| And if you have multiple postings to an account on the same day, split | ||||
| across multiple files, and you want to assert the account\[aq]s balance | ||||
| on that day, you\[aq]ll need to put the assertion in the right file - | ||||
| the last one in the sequence, probably. | ||||
| .SS Assertions and multiple -f files | ||||
| .PP | ||||
| Unlike \f[C]include\f[R], when multiple files are specified on the | ||||
| command line with multiple \f[C]-f/--file\f[R] options, balance | ||||
| assertions will not see balance from earlier files. | ||||
| This can be useful when you do not want problems in earlier files to | ||||
| disrupt valid assertions in later files. | ||||
| .PP | ||||
| If you do want assertions to see balance from earlier files, use | ||||
| \f[C]include\f[R], or concatenate the files temporarily. | ||||
| .SS Assertions and commodities | ||||
| .PP | ||||
| The asserted balance must be a simple single-commodity amount, and in | ||||
| @ -7128,10 +7175,26 @@ or \f[C]==*\f[R], eg: | ||||
| .fi | ||||
| .SS Assertions and virtual postings | ||||
| .PP | ||||
| Balance assertions are checked against all postings, both real and | ||||
| virtual. | ||||
| They are not affected by the \f[C]--real/-R\f[R] flag or \f[C]real:\f[R] | ||||
| Balance assertions always consider both real and virtual postings; they | ||||
| are not affected by the \f[C]--real/-R\f[R] flag or \f[C]real:\f[R] | ||||
| query. | ||||
| .SS Assertions and auto postings | ||||
| .PP | ||||
| Balance assertions \f[I]are\f[R] affected by the \f[C]--auto\f[R] flag, | ||||
| which generates auto postings, which can alter account balances. | ||||
| Because auto postings are optional in hledger, accounts affected by them | ||||
| effectively have two balances. | ||||
| But balance assertions can only test one or the other of these. | ||||
| So to avoid making fragile assertions, either: | ||||
| .IP \[bu] 2 | ||||
| assert the balance calculated with \f[C]--auto\f[R], and always use | ||||
| \f[C]--auto\f[R] with that file | ||||
| .IP \[bu] 2 | ||||
| or assert the balance calculated without \f[C]--auto\f[R], and never use | ||||
| \f[C]--auto\f[R] with that file | ||||
| .IP \[bu] 2 | ||||
| or avoid balance assertions on accounts affected by auto postings (or | ||||
| avoid auto postings entirely). | ||||
| .SS Assertions and precision | ||||
| .PP | ||||
| Balance assertions compare the exactly calculated amounts, which are not | ||||
| @ -7901,7 +7964,7 @@ See Rewriting accounts > Aliases and account types. | ||||
| .IP \[bu] 2 | ||||
| As mentioned above, subaccounts will inherit a type from their parent | ||||
| account. | ||||
| To be precise, an account\[aq]s type is decided by the first of these | ||||
| More precisely, an account\[aq]s type is decided by the first of these | ||||
| that exists: | ||||
| .RS 2 | ||||
| .IP "1." 3 | ||||
| @ -8043,7 +8106,11 @@ alias checking = assets:bank:wells fargo:checking | ||||
| .SS Regex aliases | ||||
| .PP | ||||
| There is also a more powerful variant that uses a regular expression, | ||||
| indicated by the forward slashes: | ||||
| indicated by wrapping the pattern in forward slashes. | ||||
| (This is the only place where hledger requires forward slashes around a | ||||
| regular expression.) | ||||
| .PP | ||||
| Eg: | ||||
| .IP | ||||
| .nf | ||||
| \f[C] | ||||
| @ -8051,14 +8118,23 @@ alias /REGEX/ = REPLACEMENT | ||||
| \f[R] | ||||
| .fi | ||||
| .PP | ||||
| or \f[C]--alias \[aq]/REGEX/=REPLACEMENT\[aq]\f[R]. | ||||
| or: | ||||
| .IP | ||||
| .nf | ||||
| \f[C] | ||||
| $ hledger --alias \[aq]/REGEX/=REPLACEMENT\[aq] ... | ||||
| \f[R] | ||||
| .fi | ||||
| .PP | ||||
| Any part of an account name matched by REGEX will be replaced by | ||||
| REPLACEMENT. | ||||
| REGEX is case-insensitive as usual. | ||||
| .PP | ||||
| If you need to match a forward slash, escape it with a backslash, eg | ||||
| \f[C]/\[rs]/=:\f[R]. | ||||
| .PP | ||||
| REGEX is a case-insensitive regular expression. | ||||
| Anywhere it matches inside an account name, the matched part will be | ||||
| replaced by REPLACEMENT. | ||||
| If REGEX contains parenthesised match groups, these can be referenced by | ||||
| the usual numeric backreferences in REPLACEMENT. | ||||
| Eg: | ||||
| the usual backslash and number in REPLACEMENT: | ||||
| .IP | ||||
| .nf | ||||
| \f[C] | ||||
| @ -8067,8 +8143,8 @@ alias /\[ha](.+):bank:([\[ha]:]+):(.*)/ = \[rs]1:\[rs]2 \[rs]3 | ||||
| \f[R] | ||||
| .fi | ||||
| .PP | ||||
| Also note that REPLACEMENT continues to the end of line (or on command | ||||
| line, to end of option argument), so it can contain trailing whitespace. | ||||
| REPLACEMENT continues to the end of line (or on command line, to end of | ||||
| option argument), so it can contain trailing whitespace. | ||||
| .SS Combining aliases | ||||
| .PP | ||||
| You can define as many aliases as you like, using journal directives | ||||
| @ -8328,11 +8404,23 @@ There is an additional constraint on the period expression: the start | ||||
| date must fall on a natural boundary of the interval. | ||||
| Eg \f[C]monthly from 2018/1/1\f[R] is valid, but | ||||
| \f[C]monthly from 2018/1/15\f[R] is not. | ||||
| .SS Periodic rules and relative dates | ||||
| .PP | ||||
| Partial or relative dates (M/D, D, tomorrow, last week) in the period | ||||
| expression can work (useful or not). | ||||
| They will be relative to today\[aq]s date, unless a Y default year | ||||
| directive is in effect, in which case they will be relative to Y/1/1. | ||||
| Partial or relative dates (like \f[C]12/31\f[R], \f[C]25\f[R], | ||||
| \f[C]tomorrow\f[R], \f[C]last week\f[R], \f[C]next quarter\f[R]) are | ||||
| usually not recommended in periodic rules, since the results will change | ||||
| as time passes. | ||||
| If used, they will be interpreted relative to, in order of preference: | ||||
| .IP "1." 3 | ||||
| the first day of the default year specified by a recent \f[C]Y\f[R] | ||||
| directive | ||||
| .IP "2." 3 | ||||
| or the date specified with \f[C]--today\f[R] | ||||
| .IP "3." 3 | ||||
| or the date on which you are running the report. | ||||
| .PP | ||||
| They will not be affected at all by report period or forecast period | ||||
| dates. | ||||
| .SS Two spaces between period expression and description! | ||||
| .PP | ||||
| If the period expression is followed by a transaction description, these | ||||
|  | ||||
							
								
								
									
										1077
									
								
								hledger/hledger.info
									
									
									
									
									
								
							
							
						
						
									
										1077
									
								
								hledger/hledger.info
									
									
									
									
									
								
							
										
											
												File diff suppressed because it is too large
												Load Diff
											
										
									
								
							| @ -1309,6 +1309,18 @@ VALUATION | ||||
|        o but  not,  currently, from "more correct" multicommodity transactions | ||||
|          (no @, multiple commodities, balanced). | ||||
| 
 | ||||
|        There is another limitation (bug) currently: when a valuation commodity | ||||
|        is  not  specified,  prices  inferred with --infer-market-prices do not | ||||
|        help select a default valuation commodity, as P prices would.  So  con- | ||||
|        version  might  not  happen because no valuation commodity was detected | ||||
|        (--debug=2 will show this).  To be safe, specify the valuation commmod- | ||||
|        ity, eg: | ||||
| 
 | ||||
|        o -X EUR --infer-market-prices, not -V --infer-market-prices | ||||
| 
 | ||||
|        o --value=then,EUR --infer-market-prices, not --value=then --infer-mar- | ||||
|          ket-prices | ||||
| 
 | ||||
|    Valuation commodity | ||||
|        When you specify a valuation commodity (-X COMM or --value TYPE,COMM): | ||||
|        hledger will convert all amounts to COMM, wherever it can find a  suit- | ||||
| @ -1590,6 +1602,8 @@ VALUATION | ||||
|                        played  val-   played  val-   valued              played  val-   played values | ||||
|                        ues            ues                                ues | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
|        balance  (bs, | ||||
|        bse,  cf, is) | ||||
|        with   report | ||||
| @ -1605,7 +1619,6 @@ VALUATION | ||||
|        is,        bs   postings  in                  period at respec-   each period,   sums of post- | ||||
|        --change,  cf   period                        tive      posting   valued    at   ings | ||||
|        --change)                                     dates               period ends | ||||
| 
 | ||||
|        end  balances   sums      of   same      as   sums of values of   period   end   value      at | ||||
|        (bal  -H,  is   costs     of   --value=end    postings     from   balances,      DATE/today of | ||||
|        --H, bs, cf)    postings                      before     period   valued    at   sums of post- | ||||
| @ -1665,9 +1678,9 @@ PIVOTING | ||||
|        Normally hledger sums amounts, and organizes them in a hierarchy, based | ||||
|        on account name.  The --pivot FIELD option causes it to sum  and  orga- | ||||
|        nize  hierarchy  based on the value of some other field instead.  FIELD | ||||
|        can be: code, description, payee, note, or the full name (case insensi- | ||||
|        tive) of any tag.  As with account names, values containing colon:sepa- | ||||
|        rated:parts will be displayed hierarchically in reports. | ||||
|        can be: status, code, description, payee, note, or the full name  (case | ||||
|        insensitive)  of  any  tag.   As  with account names, values containing | ||||
|        colon:separated:parts will be displayed hierarchically in reports. | ||||
| 
 | ||||
|        --pivot is a general option affecting all reports;  you  can  think  of | ||||
|        hledger transforming the journal before any other processing, replacing | ||||
| @ -2112,6 +2125,12 @@ COMMANDS | ||||
|        Transactions  making a net change of zero are not shown by default; add | ||||
|        the -E/--empty flag to show them. | ||||
| 
 | ||||
|        For performance reasons, column widths are chosen based  on  the  first | ||||
|        1000  lines;  this means unusually wide values in later lines can cause | ||||
|        visual discontinuities as column widths are adjusted.  If you  want  to | ||||
|        ensure  perfect alignment, at the cost of more time and memory, use the | ||||
|        --align-all flag. | ||||
| 
 | ||||
|        This command also supports the output  destination  and  output  format | ||||
|        options.  The output formats supported are txt, csv, and json. | ||||
| 
 | ||||
| @ -2689,6 +2708,7 @@ COMMANDS | ||||
|        tion show: | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
|        Valua-     no valuation       --value= then       --value= end       --value= YYYY- | ||||
|        tion:                                                                MM-DD /now | ||||
|        >Accumu- | ||||
| @ -3907,6 +3927,12 @@ COMMANDS | ||||
| 
 | ||||
|        With --date2, it shows and sorts by secondary date instead. | ||||
| 
 | ||||
|        For performance reasons, column widths are chosen based  on  the  first | ||||
|        1000  lines;  this means unusually wide values in later lines can cause | ||||
|        visual discontinuities as column widths are adjusted.  If you  want  to | ||||
|        ensure  perfect alignment, at the cost of more time and memory, use the | ||||
|        --align-all flag. | ||||
| 
 | ||||
|        The --historical/-H flag adds the balance from  any  undisplayed  prior | ||||
|        postings  to  the  running  total.  This is useful when you want to see | ||||
|        only recent activity, with a historically accurate running balance: | ||||
| @ -4337,18 +4363,29 @@ COMMANDS | ||||
| 
 | ||||
|    tags | ||||
|        tags | ||||
|        List  the  unique tag names used in the journal.  With a TAGREGEX argu- | ||||
|        ment, only tag names matching the regular expression (case insensitive) | ||||
|        are  shown.  With QUERY arguments, only transactions matching the query | ||||
|        are considered. | ||||
|        List the tags used in the journal, or their values. | ||||
| 
 | ||||
|        With the --values flag, the tags' unique values are listed instead. | ||||
|        This command lists the tag names used in the journal, whether on trans- | ||||
|        actions, postings, or account declarations. | ||||
| 
 | ||||
|        With --parsed flag, all tags or values are shown in the order they  are | ||||
|        parsed from the input data, including duplicates. | ||||
|        With a TAGREGEX argument, only tag names matching this regular  expres- | ||||
|        sion (case insensitive, infix matched) are shown. | ||||
| 
 | ||||
|        With  -E/--empty,  any blank/empty values will also be shown, otherwise | ||||
|        they are omitted. | ||||
|        With  QUERY  arguments,  only  transactions  and accounts matching this | ||||
|        query are considered.  If the query involves transaction fields (date:, | ||||
|        desc:, amt:, ...), the search is restricted to the matched transactions | ||||
|        and their accounts. | ||||
| 
 | ||||
|        With the --values flag, the tags' unique non-empty  values  are  listed | ||||
|        instead.  With -E/--empty, blank/empty values are also shown. | ||||
| 
 | ||||
|        With  --parsed, tags or values are shown in the order they were parsed, | ||||
|        with duplicates included.  (Except, tags from account declarations  are | ||||
|        always shown first.) | ||||
| 
 | ||||
|        Tip:  remember, accounts also acquire tags from their parents, postings | ||||
|        also acquire tags from their account and transaction, transactions also | ||||
|        acquire tags from their postings. | ||||
| 
 | ||||
|    test | ||||
|        test | ||||
| @ -4579,6 +4616,8 @@ JOURNAL FORMAT | ||||
|        uncleared    recorded but not yet reconciled; needs review | ||||
|        pending      tentatively reconciled (if needed, eg during a big reconcil- | ||||
|                     iation) | ||||
| 
 | ||||
| 
 | ||||
|        cleared      complete, reconciled as far as possible, and considered cor- | ||||
|                     rect | ||||
| 
 | ||||
| @ -5022,16 +5061,25 @@ JOURNAL FORMAT | ||||
|        order of postings and assertions within a day, so you can assert intra- | ||||
|        day balances. | ||||
| 
 | ||||
|    Assertions and included files | ||||
|        With included files, things are a little more  complicated.   Including | ||||
|        preserves  the ordering of postings and assertions.  If you have multi- | ||||
|        ple postings to an account on the  same  day,  split  across  different | ||||
|        files,  and  you  also want to assert the account's balance on the same | ||||
|        day, you'll have to put the assertion in the right file. | ||||
|    Assertions and multiple included files | ||||
|        Multiple  files included with the include directive are processed as if | ||||
|        concatenated into one file, preserving  their  order  and  the  posting | ||||
|        order  within  each  file.   It  means that balance assertions in later | ||||
|        files will see balance from earlier files. | ||||
| 
 | ||||
|    Assertions and multiple -f options | ||||
|        Balance assertions don't work well across files specified with multiple | ||||
|        -f options.  Use include or concatenate the files instead. | ||||
|        And if you have multiple postings to an account on the same day,  split | ||||
|        across  multiple files, and you want to assert the account's balance on | ||||
|        that day, you'll need to put the assertion in the right file - the last | ||||
|        one in the sequence, probably. | ||||
| 
 | ||||
|    Assertions and multiple -f files | ||||
|        Unlike  include,  when multiple files are specified on the command line | ||||
|        with multiple -f/--file options, balance assertions will not  see  bal- | ||||
|        ance from earlier files.  This can be useful when you do not want prob- | ||||
|        lems in earlier files to disrupt valid assertions in later files. | ||||
| 
 | ||||
|        If you do want assertions  to  see  balance  from  earlier  files,  use | ||||
|        include, or concatenate the files temporarily. | ||||
| 
 | ||||
|    Assertions and commodities | ||||
|        The  asserted  balance must be a simple single-commodity amount, and in | ||||
| @ -5101,8 +5149,24 @@ JOURNAL FORMAT | ||||
|                 checking         1  ==* 11 | ||||
| 
 | ||||
|    Assertions and virtual postings | ||||
|        Balance assertions are checked against all postings, both real and vir- | ||||
|        tual.  They are not affected by the --real/-R flag or real: query. | ||||
|        Balance assertions always consider both real and virtual postings; they | ||||
|        are not affected by the --real/-R flag or real: query. | ||||
| 
 | ||||
|    Assertions and auto postings | ||||
|        Balance  assertions  are  affected  by the --auto flag, which generates | ||||
|        auto postings, which can alter account balances.  Because auto postings | ||||
|        are optional in hledger, accounts affected by them effectively have two | ||||
|        balances.  But balance assertions can only test one  or  the  other  of | ||||
|        these.  So to avoid making fragile assertions, either: | ||||
| 
 | ||||
|        o assert the balance calculated with --auto, and always use --auto with | ||||
|          that file | ||||
| 
 | ||||
|        o or assert the balance calculated without --auto, and never use --auto | ||||
|          with that file | ||||
| 
 | ||||
|        o or avoid balance assertions on accounts affected by auto postings (or | ||||
|          avoid auto postings entirely). | ||||
| 
 | ||||
|    Assertions and precision | ||||
|        Balance assertions compare the exactly calculated  amounts,  which  are | ||||
| @ -5617,8 +5681,8 @@ JOURNAL FORMAT | ||||
|          Rewriting accounts > Aliases and account types. | ||||
| 
 | ||||
|        o As mentioned above, subaccounts will inherit a type from their parent | ||||
|          account.  To be precise, an account's type is decided by the first of | ||||
|          these that exists: | ||||
|          account.  More precisely, an account's type is decided by  the  first | ||||
|          of these that exists: | ||||
| 
 | ||||
|          1. A type: declaration for this account. | ||||
| 
 | ||||
| @ -5722,23 +5786,32 @@ JOURNAL FORMAT | ||||
| 
 | ||||
|    Regex aliases | ||||
|        There is also a more powerful variant that uses a  regular  expression, | ||||
|        indicated by the forward slashes: | ||||
|        indicated  by  wrapping  the  pattern in forward slashes.  (This is the | ||||
|        only place where hledger requires  forward  slashes  around  a  regular | ||||
|        expression.) | ||||
| 
 | ||||
|        Eg: | ||||
| 
 | ||||
|               alias /REGEX/ = REPLACEMENT | ||||
| 
 | ||||
|        or --alias '/REGEX/=REPLACEMENT'. | ||||
|        or: | ||||
| 
 | ||||
|        REGEX is a case-insensitive regular expression.   Anywhere  it  matches | ||||
|        inside  an  account name, the matched part will be replaced by REPLACE- | ||||
|        MENT.  If REGEX contains parenthesised match groups, these can be  ref- | ||||
|        erenced by the usual numeric backreferences in REPLACEMENT.  Eg: | ||||
|               $ hledger --alias '/REGEX/=REPLACEMENT' ... | ||||
| 
 | ||||
|        Any  part  of  an  account  name  matched  by REGEX will be replaced by | ||||
|        REPLACEMENT.  REGEX is case-insensitive as usual. | ||||
| 
 | ||||
|        If you need to match a forward slash, escape it with  a  backslash,  eg | ||||
|        /\/=:. | ||||
| 
 | ||||
|        If  REGEX  contains parenthesised match groups, these can be referenced | ||||
|        by the usual backslash and number in REPLACEMENT: | ||||
| 
 | ||||
|               alias /^(.+):bank:([^:]+):(.*)/ = \1:\2 \3 | ||||
|               ; rewrites "assets:bank:wells fargo:checking" to  "assets:wells fargo checking" | ||||
| 
 | ||||
|        Also  note that REPLACEMENT continues to the end of line (or on command | ||||
|        line, to end of option argument), so it  can  contain  trailing  white- | ||||
|        space. | ||||
|        REPLACEMENT continues to the end of line (or on command line, to end of | ||||
|        option argument), so it can contain trailing whitespace. | ||||
| 
 | ||||
|    Combining aliases | ||||
|        You  can  define  as many aliases as you like, using journal directives | ||||
| @ -5939,10 +6012,20 @@ JOURNAL FORMAT | ||||
|        date must fall on a natural boundary of the interval.  Eg monthly  from | ||||
|        2018/1/1 is valid, but monthly from 2018/1/15 is not. | ||||
| 
 | ||||
|        Partial  or  relative dates (M/D, D, tomorrow, last week) in the period | ||||
|        expression can work (useful or not).  They will be relative to  today's | ||||
|        date,  unless  a  Y  default year directive is in effect, in which case | ||||
|        they will be relative to Y/1/1. | ||||
|    Periodic rules and relative dates | ||||
|        Partial  or  relative  dates (like 12/31, 25, tomorrow, last week, next | ||||
|        quarter) are usually not  recommended  in  periodic  rules,  since  the | ||||
|        results  will change as time passes.  If used, they will be interpreted | ||||
|        relative to, in order of preference: | ||||
| 
 | ||||
|        1. the first day of the default year specified by a recent Y directive | ||||
| 
 | ||||
|        2. or the date specified with --today | ||||
| 
 | ||||
|        3. or the date on which you are running the report. | ||||
| 
 | ||||
|        They will not be affected at all by report period  or  forecast  period | ||||
|        dates. | ||||
| 
 | ||||
|    Two spaces between period expression and description! | ||||
|        If  the  period  expression  is  followed by a transaction description, | ||||
| @ -6196,7 +6279,6 @@ CSV FORMAT | ||||
|        if table                     apply  some  rules to CSV records matched by | ||||
|                                     patterns, alternate syntax | ||||
|        end                          skip the remaining CSV records | ||||
| 
 | ||||
|        date-format                  how to parse dates in CSV records | ||||
|        decimal-mark                 the decimal mark used  in  CSV  amounts,  if | ||||
|                                     ambiguous | ||||
| @ -7903,4 +7985,4 @@ SEE ALSO | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| hledger-1.25.99                  December 2021                      HLEDGER(1) | ||||
| hledger-1.25.99                   April 2022                        HLEDGER(1) | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user