doc: regenerate builtin manuals
This commit is contained in:
		
							parent
							
								
									f168d74010
								
							
						
					
					
						commit
						d0771a8526
					
				| @ -212,52 +212,89 @@ With this syntax, DATE infers its year from the transaction and DATE2 | ||||
| infers its year from DATE. | ||||
| .SS Status | ||||
| .PP | ||||
| More about the status field: transactions, or individual postings within | ||||
| a transaction, can be in one of three states, represented by a single | ||||
| character: | ||||
| .IP \[bu] 2 | ||||
| empty (no status character) = uncleared | ||||
| .IP \[bu] 2 | ||||
| \f[C]!\f[] = pending (aka "tentatively cleared") | ||||
| .IP \[bu] 2 | ||||
| \f[C]*\f[] = cleared | ||||
| Transactions, or individual postings within a transaction, can have a | ||||
| status mark, which is a single character before the transaction | ||||
| description or posting account name, separated from it by a space, | ||||
| indicating one of three statuses: | ||||
| .PP | ||||
| When reporting, you can filter by status using the | ||||
| \f[C]\-C/\-\-cleared\f[] and \f[C]\-U/\-\-uncleared\f[] flags or the | ||||
| \f[C]status:\f[] query. | ||||
| .TS | ||||
| tab(@); | ||||
| l l. | ||||
| T{ | ||||
| mark \  | ||||
| T}@T{ | ||||
| status | ||||
| T} | ||||
| _ | ||||
| T{ | ||||
| \  | ||||
| T}@T{ | ||||
| uncleared (no mark) | ||||
| T} | ||||
| T{ | ||||
| \f[C]!\f[] | ||||
| T}@T{ | ||||
| pending | ||||
| T} | ||||
| T{ | ||||
| \f[C]*\f[] | ||||
| T}@T{ | ||||
| cleared | ||||
| T} | ||||
| .TE | ||||
| .PP | ||||
| This feature is optional, but can be helpful for reconciling with | ||||
| When reporting, you can filter by status with the | ||||
| \f[C]\-U/\-\-uncleared\f[], \f[C]\-P/\-\-pending\f[], and | ||||
| \f[C]\-C/\-\-cleared\f[] flags; or the \f[C]status:\f[], | ||||
| \f[C]status:!\f[], and \f[C]status:*\f[] queries; or the U, P, C keys in | ||||
| hledger\-ui. | ||||
| .PP | ||||
| Note from hledger 1.3 onwards, \-U/\-\-uncleared matches the uncleared | ||||
| (unmarked) status only. | ||||
| To replicate Ledger and old hledger\[aq]s behaviour of also matching | ||||
| pending, combine \-U and \-P. | ||||
| .PP | ||||
| Status marks are optional, but can be helpful eg for reconciling with | ||||
| real\-world accounts. | ||||
| Some editor modes provide highlighting and shortcuts working with | ||||
| status. | ||||
| Eg in Emacs ledger\-mode, you can toggle transaction status with C\-c | ||||
| C\-e, or posting status with C\-c C\-c. | ||||
| .PP | ||||
| What "uncleared", "pending", and "cleared" actually mean is up to you. | ||||
| Here\[aq]s one suggestion: | ||||
| .PP | ||||
| A suggestion: use cleared (\f[C]*\f[]) to mark transactions that are | ||||
| "complete", ie: | ||||
| .IP \[bu] 2 | ||||
| they have cleared with the bank, or the cash has been handed over | ||||
| .IP \[bu] 2 | ||||
| you are satisfied they are recorded accurately in the journal | ||||
| .IP \[bu] 2 | ||||
| the resulting account balance reported by hledger agrees exactly with | ||||
| the external source of truth, if any (eg the bank\[aq]s online register | ||||
| or statement) | ||||
| .TS | ||||
| tab(@); | ||||
| lw(10.7n) lw(8.8n). | ||||
| T{ | ||||
| status | ||||
| T}@T{ | ||||
| meaning | ||||
| T} | ||||
| _ | ||||
| T{ | ||||
| uncleared | ||||
| T}@T{ | ||||
| recorded but not yet reconciled; needs checking | ||||
| T} | ||||
| T{ | ||||
| pending | ||||
| T}@T{ | ||||
| tentatively reconciled, during reconciliation (if needed); "I think I | ||||
| have matched this one" | ||||
| T} | ||||
| T{ | ||||
| cleared | ||||
| T}@T{ | ||||
| complete, reconciled/checked as far as possible, and considered correct. | ||||
| T} | ||||
| .TE | ||||
| .PP | ||||
| Then, with \-\-cleared you\[aq]ll see the current balance at your bank, | ||||
| with \-\-uncleared you\[aq]ll see things which will probably hit your | ||||
| bank soon (eg uncashed checks), and with neither flag (the default) | ||||
| you\[aq]ll see the most up\-to\-date state of your finances. | ||||
| .PP | ||||
| I don\[aq]t use pending (\f[C]!\f[]), but perhaps it is useful in very | ||||
| tricky reconciliations, as a temporary marker for transactions matched | ||||
| so far, allowing you start over more easily. | ||||
| Note, the \-\-uncleared flag matches both uncleared and pending things | ||||
| ("everything not definitely cleared"). | ||||
| Currently, to match pending things only, use \f[C]status:!\f[], and to | ||||
| match uncleared things only, \f[C]not:status:!\ not:status:*\f[] | ||||
| (\f[C]status:\f[] seems buggy). | ||||
| .PP | ||||
| Some editor modes highlight entries differently based on their status. | ||||
| In Emacs ledger\-mode, you can toggle transaction status with | ||||
| \f[C]C\-c\ C\-e\f[], or posting status with \f[C]C\-c\ C\-c\f[]. | ||||
| With this scheme, you would use \f[C]\-PC\f[] to see the current balance | ||||
| at your bank, \f[C]\-U\f[] to see things which will probably hit your | ||||
| bank soon (eg uncashed checks), and no flags to see the most | ||||
| up\-to\-date state of your finances. | ||||
| .SS Account names | ||||
| .PP | ||||
| Account names typically have several parts separated by a full colon, | ||||
|  | ||||
| @ -232,46 +232,67 @@ File: hledger_journal.5.info,  Node: Status,  Next: Account names,  Prev: Dates, | ||||
| 1.4 Status | ||||
| ========== | ||||
| 
 | ||||
| More about the status field: transactions, or individual postings within | ||||
| a transaction, can be in one of three states, represented by a single | ||||
| character: | ||||
| Transactions, or individual postings within a transaction, can have a | ||||
| status mark, which is a single character before the transaction | ||||
| description or posting account name, separated from it by a space, | ||||
| indicating one of three statuses: | ||||
| 
 | ||||
|    * empty (no status character) = uncleared | ||||
|    * '!' = pending (aka "tentatively cleared") | ||||
|    * '*' = cleared | ||||
| mark  status | ||||
|   | ||||
|    When reporting, you can filter by status using the '-C/--cleared' and | ||||
| '-U/--uncleared' flags or the 'status:' query. | ||||
| ---------------------------- | ||||
|       uncleared (no mark) | ||||
| '!'   pending | ||||
| '*'   cleared | ||||
| 
 | ||||
|    This feature is optional, but can be helpful for reconciling with | ||||
| real-world accounts.  What "uncleared", "pending", and "cleared" | ||||
| actually mean is up to you. | ||||
|    When reporting, you can filter by status with the '-U/--uncleared', | ||||
| '-P/--pending', and '-C/--cleared' flags; or the 'status:', 'status:!', | ||||
| and 'status:*' queries; or the U, P, C keys in hledger-ui. | ||||
| 
 | ||||
|    A suggestion: use cleared ('*') to mark transactions that are | ||||
| "complete", ie: | ||||
|    Note from hledger 1.3 onwards, -U/-uncleared matches the uncleared | ||||
| (unmarked) status only.  To replicate Ledger and old hledger's behaviour | ||||
| of also matching pending, combine -U and -P. | ||||
| 
 | ||||
|    * they have cleared with the bank, or the cash has been handed over | ||||
|    * you are satisfied they are recorded accurately in the journal | ||||
|    * the resulting account balance reported by hledger agrees exactly | ||||
|      with the external source of truth, if any (eg the bank's online | ||||
|      register or statement) | ||||
|    Status marks are optional, but can be helpful eg for reconciling with | ||||
| real-world accounts.  Some editor modes provide highlighting and | ||||
| shortcuts working with status.  Eg in Emacs ledger-mode, you can toggle | ||||
| transaction status with C-c C-e, or posting status with C-c C-c. | ||||
| 
 | ||||
|    Then, with -cleared you'll see the current balance at your bank, with | ||||
| -uncleared you'll see things which will probably hit your bank soon (eg | ||||
| uncashed checks), and with neither flag (the default) you'll see the | ||||
| most up-to-date state of your finances. | ||||
|    What "uncleared", "pending", and "cleared" actually mean is up to | ||||
| you.  Here's one suggestion: | ||||
| 
 | ||||
|    I don't use pending ('!'), but perhaps it is useful in very tricky | ||||
| reconciliations, as a temporary marker for transactions matched so far, | ||||
| allowing you start over more easily.  Note, the -uncleared flag matches | ||||
| both uncleared and pending things ("everything not definitely cleared"). | ||||
| Currently, to match pending things only, use 'status:!', and to match | ||||
| uncleared things only, 'not:status:! not:status:*' ('status:' seems | ||||
| buggy). | ||||
| status      meaning | ||||
| ---------------------- | ||||
| uncleared   recorded | ||||
|             but not | ||||
|             yet | ||||
|             reconciled; | ||||
|             needs | ||||
|             checking | ||||
| pending     tentatively | ||||
|             reconciled, | ||||
|             during | ||||
|             reconciliation | ||||
|             (if | ||||
|             needed); | ||||
|             "I | ||||
|             think I | ||||
|             have | ||||
|             matched | ||||
|             this | ||||
|             one" | ||||
| cleared     complete, | ||||
|             reconciled/checked | ||||
|             as far | ||||
|             as | ||||
|             possible, | ||||
|             and | ||||
|             considered | ||||
|             correct. | ||||
| 
 | ||||
|    Some editor modes highlight entries differently based on their | ||||
| status.  In Emacs ledger-mode, you can toggle transaction status with | ||||
| 'C-c C-e', or posting status with 'C-c C-c'. | ||||
|    With this scheme, you would use '-PC' to see the current balance at | ||||
| your bank, '-U' to see things which will probably hit your bank soon (eg | ||||
| uncashed checks), and no flags to see the most up-to-date state of your | ||||
| finances. | ||||
| 
 | ||||
|  | ||||
| File: hledger_journal.5.info,  Node: Account names,  Next: Amounts,  Prev: Status,  Up: FILE FORMAT | ||||
| @ -1060,67 +1081,67 @@ Node: Posting dates6832 | ||||
| Ref: #posting-dates6963 | ||||
| Node: Status8337 | ||||
| Ref: #status8461 | ||||
| Node: Account names10271 | ||||
| Ref: #account-names10411 | ||||
| Node: Amounts10898 | ||||
| Ref: #amounts11036 | ||||
| Node: Virtual Postings13137 | ||||
| Ref: #virtual-postings13298 | ||||
| Node: Balance Assertions14518 | ||||
| Ref: #balance-assertions14695 | ||||
| Node: Assertions and ordering15591 | ||||
| Ref: #assertions-and-ordering15779 | ||||
| Node: Assertions and included files16479 | ||||
| Ref: #assertions-and-included-files16722 | ||||
| Node: Assertions and multiple -f options17055 | ||||
| Ref: #assertions-and-multiple--f-options17311 | ||||
| Node: Assertions and commodities17443 | ||||
| Ref: #assertions-and-commodities17680 | ||||
| Node: Assertions and subaccounts18376 | ||||
| Ref: #assertions-and-subaccounts18610 | ||||
| Node: Assertions and virtual postings19131 | ||||
| Ref: #assertions-and-virtual-postings19340 | ||||
| Node: Balance Assignments19482 | ||||
| Ref: #balance-assignments19651 | ||||
| Node: Prices20770 | ||||
| Ref: #prices20905 | ||||
| Node: Transaction prices20956 | ||||
| Ref: #transaction-prices21103 | ||||
| Node: Market prices23259 | ||||
| Ref: #market-prices23396 | ||||
| Node: Comments24356 | ||||
| Ref: #comments24480 | ||||
| Node: Tags25593 | ||||
| Ref: #tags25713 | ||||
| Node: Implicit tags27142 | ||||
| Ref: #implicit-tags27250 | ||||
| Node: Directives27767 | ||||
| Ref: #directives27882 | ||||
| Node: Account aliases28075 | ||||
| Ref: #account-aliases28221 | ||||
| Node: Basic aliases28825 | ||||
| Ref: #basic-aliases28970 | ||||
| Node: Regex aliases29660 | ||||
| Ref: #regex-aliases29830 | ||||
| Node: Multiple aliases30545 | ||||
| Ref: #multiple-aliases30719 | ||||
| Node: end aliases31217 | ||||
| Ref: #end-aliases31359 | ||||
| Node: account directive31460 | ||||
| Ref: #account-directive31642 | ||||
| Node: apply account directive31938 | ||||
| Ref: #apply-account-directive32136 | ||||
| Node: Multi-line comments32795 | ||||
| Ref: #multi-line-comments32987 | ||||
| Node: commodity directive33115 | ||||
| Ref: #commodity-directive33301 | ||||
| Node: Default commodity34173 | ||||
| Ref: #default-commodity34348 | ||||
| Node: Default year34885 | ||||
| Ref: #default-year35052 | ||||
| Node: Including other files35475 | ||||
| Ref: #including-other-files35634 | ||||
| Node: EDITOR SUPPORT36031 | ||||
| Ref: #editor-support36151 | ||||
| Node: Account names10360 | ||||
| Ref: #account-names10500 | ||||
| Node: Amounts10987 | ||||
| Ref: #amounts11125 | ||||
| Node: Virtual Postings13226 | ||||
| Ref: #virtual-postings13387 | ||||
| Node: Balance Assertions14607 | ||||
| Ref: #balance-assertions14784 | ||||
| Node: Assertions and ordering15680 | ||||
| Ref: #assertions-and-ordering15868 | ||||
| Node: Assertions and included files16568 | ||||
| Ref: #assertions-and-included-files16811 | ||||
| Node: Assertions and multiple -f options17144 | ||||
| Ref: #assertions-and-multiple--f-options17400 | ||||
| Node: Assertions and commodities17532 | ||||
| Ref: #assertions-and-commodities17769 | ||||
| Node: Assertions and subaccounts18465 | ||||
| Ref: #assertions-and-subaccounts18699 | ||||
| Node: Assertions and virtual postings19220 | ||||
| Ref: #assertions-and-virtual-postings19429 | ||||
| Node: Balance Assignments19571 | ||||
| Ref: #balance-assignments19740 | ||||
| Node: Prices20859 | ||||
| Ref: #prices20994 | ||||
| Node: Transaction prices21045 | ||||
| Ref: #transaction-prices21192 | ||||
| Node: Market prices23348 | ||||
| Ref: #market-prices23485 | ||||
| Node: Comments24445 | ||||
| Ref: #comments24569 | ||||
| Node: Tags25682 | ||||
| Ref: #tags25802 | ||||
| Node: Implicit tags27231 | ||||
| Ref: #implicit-tags27339 | ||||
| Node: Directives27856 | ||||
| Ref: #directives27971 | ||||
| Node: Account aliases28164 | ||||
| Ref: #account-aliases28310 | ||||
| Node: Basic aliases28914 | ||||
| Ref: #basic-aliases29059 | ||||
| Node: Regex aliases29749 | ||||
| Ref: #regex-aliases29919 | ||||
| Node: Multiple aliases30634 | ||||
| Ref: #multiple-aliases30808 | ||||
| Node: end aliases31306 | ||||
| Ref: #end-aliases31448 | ||||
| Node: account directive31549 | ||||
| Ref: #account-directive31731 | ||||
| Node: apply account directive32027 | ||||
| Ref: #apply-account-directive32225 | ||||
| Node: Multi-line comments32884 | ||||
| Ref: #multi-line-comments33076 | ||||
| Node: commodity directive33204 | ||||
| Ref: #commodity-directive33390 | ||||
| Node: Default commodity34262 | ||||
| Ref: #default-commodity34437 | ||||
| Node: Default year34974 | ||||
| Ref: #default-year35141 | ||||
| Node: Including other files35564 | ||||
| Ref: #including-other-files35723 | ||||
| Node: EDITOR SUPPORT36120 | ||||
| Ref: #editor-support36240 | ||||
|  | ||||
| End Tag Table | ||||
|  | ||||
| @ -169,59 +169,79 @@ FILE FORMAT | ||||
|        infers its year from DATE. | ||||
| 
 | ||||
|    Status | ||||
|        More  about  the  status  field:  transactions,  or individual postings | ||||
|        within a transaction, can be in one of three states, represented  by  a | ||||
|        single character: | ||||
|        Transactions,  or  individual postings within a transaction, can have a | ||||
|        status mark,  which  is  a  single  character  before  the  transaction | ||||
|        description  or  posting  account  name,  separated from it by a space, | ||||
|        indicating one of three statuses: | ||||
| 
 | ||||
|        o empty (no status character) = uncleared | ||||
| 
 | ||||
|        o ! = pending (aka "tentatively cleared") | ||||
|        mark     status | ||||
|        ----------------------------- | ||||
|                 uncleared (no mark) | ||||
|        !        pending | ||||
|        *        cleared | ||||
| 
 | ||||
|        o * = cleared | ||||
|        When reporting, you can  filter  by  status  with  the  -U/--uncleared, | ||||
|        -P/--pending,  and  -C/--cleared  flags;  or the status:, status:!, and | ||||
|        status:* queries; or the U, P, C keys in hledger-ui. | ||||
| 
 | ||||
|        When  reporting,  you  can  filter by status using the -C/--cleared and | ||||
|        -U/--uncleared flags or the status: query. | ||||
|        Note from hledger 1.3 onwards,  -U/--uncleared  matches  the  uncleared | ||||
|        (unmarked)  status  only.  To replicate Ledger and old hledger's behav- | ||||
|        iour of also matching pending, combine -U and -P. | ||||
| 
 | ||||
|        This feature is optional, but  can  be  helpful  for  reconciling  with | ||||
|        real-world  accounts.  What "uncleared", "pending", and "cleared" actu- | ||||
|        ally mean is up to you. | ||||
|        Status marks are optional, but can be helpful eg for  reconciling  with | ||||
|        real-world accounts.  Some editor modes provide highlighting and short- | ||||
|        cuts working with status.  Eg in  Emacs  ledger-mode,  you  can  toggle | ||||
|        transaction status with C-c C-e, or posting status with C-c C-c. | ||||
| 
 | ||||
|        A suggestion: use cleared (*) to mark transactions that are "complete", | ||||
|        ie: | ||||
|        What  "uncleared", "pending", and "cleared" actually mean is up to you. | ||||
|        Here's one suggestion: | ||||
| 
 | ||||
|        o they have cleared with the bank, or the cash has been handed over | ||||
| 
 | ||||
|        o you are satisfied they are recorded accurately in the journal | ||||
| 
 | ||||
|        o the resulting account balance reported by hledger agrees exactly with | ||||
|          the external source of truth, if any (eg the bank's  online  register | ||||
|          or statement) | ||||
|        status        meaning | ||||
|        ---------------------------- | ||||
|        uncleared     recorded | ||||
|                      but   not | ||||
|                      yet  rec- | ||||
|                      onciled; | ||||
|                      needs | ||||
|                      checking | ||||
|        pending       tenta- | ||||
|                      tively | ||||
|                      recon- | ||||
|                      ciled, | ||||
|                      during | ||||
|                      reconcil- | ||||
|                      iation | ||||
|                      (if | ||||
|                      needed); | ||||
|                      "I  think | ||||
|                      I    have | ||||
|                      matched | ||||
|                      this one" | ||||
|        cleared       complete, | ||||
|                      recon- | ||||
|                      ciled/checked | ||||
|                      as far as | ||||
|                      possible, | ||||
|                      and  con- | ||||
|                      sidered | ||||
|                      correct. | ||||
| 
 | ||||
|        Then,  with --cleared you'll see the current balance at your bank, with | ||||
|        --uncleared you'll see things which will probably hit  your  bank  soon | ||||
|        (eg  uncashed  checks),  and with neither flag (the default) you'll see | ||||
|        the most up-to-date state of your finances. | ||||
| 
 | ||||
|        I don't use pending (!), but perhaps it is useful in very tricky recon- | ||||
|        ciliations,  as  a  temporary  marker  for transactions matched so far, | ||||
|        allowing you start  over  more  easily.   Note,  the  --uncleared  flag | ||||
|        matches  both  uncleared and pending things ("everything not definitely | ||||
|        cleared").  Currently, to match pending things only, use status:!,  and | ||||
|        to  match  uncleared  things  only,  not:status:! not:status:* (status: | ||||
|        seems buggy). | ||||
| 
 | ||||
|        Some editor modes highlight entries differently based on their  status. | ||||
|        In  Emacs  ledger-mode, you can toggle transaction status with C-c C-e, | ||||
|        or posting status with C-c C-c. | ||||
|        With this scheme, you would use -PC to see the current balance at  your | ||||
|        bank,  -U  to  see  things  which  will probably hit your bank soon (eg | ||||
|        uncashed checks), and no flags to see the most up-to-date state of your | ||||
|        finances. | ||||
| 
 | ||||
|    Account names | ||||
|        Account names typically have several parts separated by a  full  colon, | ||||
|        from  which hledger derives a hierarchical chart of accounts.  They can | ||||
|        be anything you like, but  in  finance  there  are  traditionally  five | ||||
|        top-level  accounts: assets, liabilities, income, expenses, and equity. | ||||
|        Account  names  typically have several parts separated by a full colon, | ||||
|        from which hledger derives a hierarchical chart of accounts.  They  can | ||||
|        be  anything  you  like,  but  in  finance there are traditionally five | ||||
|        top-level accounts: assets, liabilities, income, expenses, and  equity. | ||||
| 
 | ||||
|        Account names may contain single  spaces,  eg:  assets:accounts receiv- | ||||
|        able.   Because  of  this,  they must always be followed by two or more | ||||
|        Account  names  may  contain single spaces, eg: assets:accounts receiv- | ||||
|        able.  Because of this, they must always be followed  by  two  or  more | ||||
|        spaces (or newline). | ||||
| 
 | ||||
|        Account names can be aliased. | ||||
| @ -230,7 +250,7 @@ FILE FORMAT | ||||
|        After the account name, there is usually an amount.  Important: between | ||||
|        account name and amount, there must be two or more spaces. | ||||
| 
 | ||||
|        Amounts  consist of a number and (usually) a currency symbol or commod- | ||||
|        Amounts consist of a number and (usually) a currency symbol or  commod- | ||||
|        ity name.  Some examples: | ||||
| 
 | ||||
|        2.00001 | ||||
| @ -243,53 +263,53 @@ FILE FORMAT | ||||
| 
 | ||||
|        As you can see, the amount format is somewhat flexible: | ||||
| 
 | ||||
|        o amounts are a number (the "quantity") and optionally a currency  sym- | ||||
|        o amounts  are a number (the "quantity") and optionally a currency sym- | ||||
|          bol/commodity name (the "commodity"). | ||||
| 
 | ||||
|        o the  commodity  is  a  symbol, word, or phrase, on the left or right, | ||||
|          with or without a separating space.  If the commodity  contains  num- | ||||
|          bers,  spaces  or  non-word punctuation it must be enclosed in double | ||||
|        o the commodity is a symbol, word, or phrase, on  the  left  or  right, | ||||
|          with  or  without a separating space.  If the commodity contains num- | ||||
|          bers, spaces or non-word punctuation it must be  enclosed  in  double | ||||
|          quotes. | ||||
| 
 | ||||
|        o negative amounts with a commodity on the left can have the minus sign | ||||
|          before or after it | ||||
| 
 | ||||
|        o digit  groups  (thousands, or any other grouping) can be separated by | ||||
|          commas (in which case period is used for decimal  point)  or  periods | ||||
|        o digit groups (thousands, or any other grouping) can be  separated  by | ||||
|          commas  (in  which  case period is used for decimal point) or periods | ||||
|          (in which case comma is used for decimal point) | ||||
| 
 | ||||
|        You  can  use  any  of  these  variations when recording data, but when | ||||
|        hledger displays amounts, it will choose a consistent format  for  each | ||||
|        commodity.   (Except  for  price amounts, which are always formatted as | ||||
|        You can use any of these  variations  when  recording  data,  but  when | ||||
|        hledger  displays  amounts, it will choose a consistent format for each | ||||
|        commodity.  (Except for price amounts, which are  always  formatted  as | ||||
|        written).  The display format is chosen as follows: | ||||
| 
 | ||||
|        o if there is a commodity directive specifying the format, that is used | ||||
| 
 | ||||
|        o otherwise  the  format  is  inferred from the first posting amount in | ||||
|          that commodity in the journal, and the precision (number  of  decimal | ||||
|        o otherwise the format is inferred from the  first  posting  amount  in | ||||
|          that  commodity  in the journal, and the precision (number of decimal | ||||
|          places) will be the maximum from all posting amounts in that commmod- | ||||
|          ity | ||||
| 
 | ||||
|        o or if there are no such amounts in the journal, a default  format  is | ||||
|        o or  if  there are no such amounts in the journal, a default format is | ||||
|          used (like $1000.00). | ||||
| 
 | ||||
|        Price  amounts  and amounts in D directives usually don't affect amount | ||||
|        format inference, but in some situations they  can  do  so  indirectly. | ||||
|        (Eg  when  D's default commodity is applied to a commodity-less amount, | ||||
|        Price amounts and amounts in D directives usually don't  affect  amount | ||||
|        format  inference,  but  in  some situations they can do so indirectly. | ||||
|        (Eg when D's default commodity is applied to a  commodity-less  amount, | ||||
|        or when an amountless posting is balanced using a price's commodity, or | ||||
|        when  -V  is  used.) If you find this causing problems, set the desired | ||||
|        when -V is used.) If you find this causing problems,  set  the  desired | ||||
|        format with a commodity directive. | ||||
| 
 | ||||
|    Virtual Postings | ||||
|        When you parenthesise the account name in a posting,  we  call  that  a | ||||
|        When  you  parenthesise  the  account name in a posting, we call that a | ||||
|        virtual posting, which means: | ||||
| 
 | ||||
|        o it is ignored when checking that the transaction is balanced | ||||
| 
 | ||||
|        o it  is  excluded from reports when the --real/-R flag is used, or the | ||||
|        o it is excluded from reports when the --real/-R flag is used,  or  the | ||||
|          real:1 query. | ||||
| 
 | ||||
|        You could use this, eg, to set an  account's  opening  balance  without | ||||
|        You  could  use  this,  eg, to set an account's opening balance without | ||||
|        needing to use the equity:opening balances account: | ||||
| 
 | ||||
|               1/1 special unbalanced posting to set initial balance | ||||
| @ -297,8 +317,8 @@ FILE FORMAT | ||||
| 
 | ||||
|        When the account name is bracketed, we call it a balanced virtual post- | ||||
|        ing.  This is like an ordinary virtual posting except the balanced vir- | ||||
|        tual  postings  in a transaction must balance to 0, like the real post- | ||||
|        ings (but separately from them).  Balanced virtual  postings  are  also | ||||
|        tual postings in a transaction must balance to 0, like the  real  post- | ||||
|        ings  (but  separately  from them).  Balanced virtual postings are also | ||||
|        excluded by --real/-R or real:1. | ||||
| 
 | ||||
|               1/1 buy food with cash, and update some budget-tracking subaccounts elsewhere | ||||
| @ -308,13 +328,13 @@ FILE FORMAT | ||||
|                 [assets:checking:budget:food]  $-10 | ||||
| 
 | ||||
|        Virtual postings have some legitimate uses, but those are few.  You can | ||||
|        usually find an equivalent journal entry using real postings, which  is | ||||
|        usually  find an equivalent journal entry using real postings, which is | ||||
|        more correct and provides better error checking. | ||||
| 
 | ||||
|    Balance Assertions | ||||
|        hledger  supports  Ledger-style  balance  assertions  in journal files. | ||||
|        These look like =EXPECTEDBALANCE following a posting's amount.   Eg  in | ||||
|        this  example we assert the expected dollar balance in accounts a and b | ||||
|        hledger supports Ledger-style  balance  assertions  in  journal  files. | ||||
|        These  look  like =EXPECTEDBALANCE following a posting's amount.  Eg in | ||||
|        this example we assert the expected dollar balance in accounts a and  b | ||||
|        after each posting: | ||||
| 
 | ||||
|               2013/1/1 | ||||
| @ -326,31 +346,31 @@ FILE FORMAT | ||||
|                 b  $-1  =$-2 | ||||
| 
 | ||||
|        After reading a journal file, hledger will check all balance assertions | ||||
|        and  report  an error if any of them fail.  Balance assertions can pro- | ||||
|        tect you from, eg, inadvertently disrupting reconciled  balances  while | ||||
|        cleaning  up  old  entries.   You can disable them temporarily with the | ||||
|        --ignore-assertions flag, which can be useful  for  troubleshooting  or | ||||
|        and report an error if any of them fail.  Balance assertions  can  pro- | ||||
|        tect  you  from, eg, inadvertently disrupting reconciled balances while | ||||
|        cleaning up old entries.  You can disable  them  temporarily  with  the | ||||
|        --ignore-assertions  flag,  which  can be useful for troubleshooting or | ||||
|        for reading Ledger files. | ||||
| 
 | ||||
|    Assertions and ordering | ||||
|        hledger  sorts  an  account's postings and assertions first by date and | ||||
|        then (for postings on the same day) by parse order.  Note this is  dif- | ||||
|        hledger sorts an account's postings and assertions first  by  date  and | ||||
|        then  (for postings on the same day) by parse order.  Note this is dif- | ||||
|        ferent from Ledger, which sorts assertions only by parse order.  (Also, | ||||
|        Ledger assertions do not see the accumulated effect of  repeated  post- | ||||
|        Ledger  assertions  do not see the accumulated effect of repeated post- | ||||
|        ings to the same account within a transaction.) | ||||
| 
 | ||||
|        So,  hledger  balance  assertions  keep  working if you reorder differ- | ||||
|        ently-dated transactions  within  the  journal.   But  if  you  reorder | ||||
|        So, hledger balance assertions keep  working  if  you  reorder  differ- | ||||
|        ently-dated  transactions  within  the  journal.   But  if  you reorder | ||||
|        same-dated transactions or postings, assertions might break and require | ||||
|        updating.  This order dependence does bring an advantage: precise  con- | ||||
|        updating.   This order dependence does bring an advantage: precise con- | ||||
|        trol over the 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 | ||||
|        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 -f options | ||||
| @ -358,21 +378,21 @@ FILE FORMAT | ||||
|        -f options.  Use include or concatenate the files instead. | ||||
| 
 | ||||
|    Assertions and commodities | ||||
|        The  asserted  balance must be a simple single-commodity amount, and in | ||||
|        fact the assertion checks only  this  commodity's  balance  within  the | ||||
|        (possibly  multi-commodity) account balance.  We could call this a par- | ||||
|        tial balance assertion.  This is compatible with Ledger, and  makes  it | ||||
|        The asserted balance must be a simple single-commodity amount,  and  in | ||||
|        fact  the  assertion  checks  only  this commodity's balance within the | ||||
|        (possibly multi-commodity) account balance.  We could call this a  par- | ||||
|        tial  balance  assertion.  This is compatible with Ledger, and makes it | ||||
|        possible to make assertions about accounts containing multiple commodi- | ||||
|        ties. | ||||
| 
 | ||||
|        To assert each commodity's balance in such a  multi-commodity  account, | ||||
|        you  can  add multiple postings (with amount 0 if necessary).  But note | ||||
|        that no matter how many assertions you  add,  you  can't  be  sure  the | ||||
|        To  assert  each commodity's balance in such a multi-commodity account, | ||||
|        you can add multiple postings (with amount 0 if necessary).   But  note | ||||
|        that  no  matter  how  many  assertions  you add, you can't be sure the | ||||
|        account does not contain some unexpected commodity.  (We'll add support | ||||
|        for this kind of total balance assertion if there's demand.) | ||||
| 
 | ||||
|    Assertions and subaccounts | ||||
|        Balance assertions do not count  the  balance  from  subaccounts;  they | ||||
|        Balance  assertions  do  not  count  the balance from subaccounts; they | ||||
|        check the posted account's exclusive balance.  For example: | ||||
| 
 | ||||
|               1/1 | ||||
| @ -380,7 +400,7 @@ FILE FORMAT | ||||
|                 checking        1 = 1  ; post to the parent account, its exclusive balance is now 1 | ||||
|                 equity | ||||
| 
 | ||||
|        The  balance  report's  flat  mode  shows these exclusive balances more | ||||
|        The balance report's flat mode  shows  these  exclusive  balances  more | ||||
|        clearly: | ||||
| 
 | ||||
|               $ hledger bal checking --flat | ||||
| @ -394,10 +414,10 @@ FILE FORMAT | ||||
|        tual.  They are not affected by the --real/-R flag or real: query. | ||||
| 
 | ||||
|    Balance Assignments | ||||
|        Ledger-style  balance  assignments  are also supported.  These are like | ||||
|        balance assertions, but with no posting amount on the left side of  the | ||||
|        equals  sign;  instead  it is calculated automatically so as to satisfy | ||||
|        the assertion.  This can be a convenience during data  entry,  eg  when | ||||
|        Ledger-style balance assignments are also supported.   These  are  like | ||||
|        balance  assertions, but with no posting amount on the left side of the | ||||
|        equals sign; instead it is calculated automatically so  as  to  satisfy | ||||
|        the  assertion.   This  can be a convenience during data entry, eg when | ||||
|        setting opening balances: | ||||
| 
 | ||||
|               ; starting a new journal, set asset account balances | ||||
| @ -415,8 +435,8 @@ FILE FORMAT | ||||
|                 expenses:misc | ||||
| 
 | ||||
|        The calculated amount depends on the account's balance in the commodity | ||||
|        at that point (which depends on the previously-dated  postings  of  the | ||||
|        commodity  to  that account since the last balance assertion or assign- | ||||
|        at  that  point  (which depends on the previously-dated postings of the | ||||
|        commodity to that account since the last balance assertion  or  assign- | ||||
|        ment).  Note that using balance assignments makes your journal a little | ||||
|        less explicit; to know the exact amount posted, you have to run hledger | ||||
|        or do the calculations yourself, instead of just reading it. | ||||
| @ -424,12 +444,12 @@ FILE FORMAT | ||||
|    Prices | ||||
|    Transaction prices | ||||
|        Within a transaction, you can note an amount's price in another commod- | ||||
|        ity.   This can be used to document the cost (in a purchase) or selling | ||||
|        price (in a sale).  For  example,  transaction  prices  are  useful  to | ||||
|        ity.  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. | ||||
| 
 | ||||
|        Transaction  prices  are  fixed,  and do not change over time.  (Ledger | ||||
|        users: Ledger uses a different syntax for fixed  prices,  {=UNITPRICE}, | ||||
|        Transaction prices are fixed, and do not  change  over  time.   (Ledger | ||||
|        users:  Ledger  uses a different syntax for fixed prices, {=UNITPRICE}, | ||||
|        which hledger currently ignores). | ||||
| 
 | ||||
|        There are several ways to record a transaction price: | ||||
| @ -453,9 +473,9 @@ FILE FORMAT | ||||
|                     assets:euros     100          ; one hundred euros purchased | ||||
|                     assets:dollars  $-135          ; for $135 | ||||
| 
 | ||||
|        Amounts with transaction prices can be  displayed  in  the  transaction | ||||
|        Amounts  with  transaction  prices  can be displayed in the transaction | ||||
|        price's commodity by using the -B/--cost flag (except for #551) ("B" is | ||||
|        from "cost Basis").  Eg for the above, here is how -B affects the  bal- | ||||
|        from  "cost Basis").  Eg for the above, here is how -B affects the bal- | ||||
|        ance report: | ||||
| 
 | ||||
|               $ hledger bal -N --flat | ||||
| @ -465,8 +485,8 @@ FILE FORMAT | ||||
|                              $-135  assets:dollars | ||||
|                               $135  assets:euros    # <- the euros' cost | ||||
| 
 | ||||
|        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 | ||||
|        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's postings are reversed, while the transaction | ||||
|        is equivalent, -B shows something different: | ||||
| 
 | ||||
| @ -479,41 +499,41 @@ FILE FORMAT | ||||
|                               100  assets:euros | ||||
| 
 | ||||
|    Market prices | ||||
|        Market prices are not tied to a particular transaction; they  represent | ||||
|        historical  exchange rates between two commodities.  (Ledger calls them | ||||
|        historical prices.) For  example,  the  prices  published  by  a  stock | ||||
|        exchange  or the foreign exchange market.  hledger can use these prices | ||||
|        Market  prices are not tied to a particular transaction; they represent | ||||
|        historical exchange rates between two commodities.  (Ledger calls  them | ||||
|        historical  prices.)  For  example,  the  prices  published  by a stock | ||||
|        exchange or the foreign exchange market.  hledger can use these  prices | ||||
|        to show the market value of things at a given date, see market value. | ||||
| 
 | ||||
|        To record market prices, use P directives in the main journal or in  an | ||||
|        To  record market prices, use P directives in the main journal or in an | ||||
|        included file.  Their format is: | ||||
| 
 | ||||
|               P DATE COMMODITYBEINGPRICED UNITPRICE | ||||
| 
 | ||||
|        DATE  is a simple date as usual.  COMMODITYBEINGPRICED is the symbol of | ||||
|        the commodity being priced.  UNITPRICE is an  ordinary  amount  (symbol | ||||
|        and  quantity) in a second commodity, specifying the unit price or con- | ||||
|        version rate for the first commodity in terms of  the  second,  on  the | ||||
|        DATE is a simple date as usual.  COMMODITYBEINGPRICED is the symbol  of | ||||
|        the  commodity  being  priced.  UNITPRICE is an ordinary amount (symbol | ||||
|        and quantity) in a second commodity, specifying the unit price or  con- | ||||
|        version  rate  for  the  first commodity in terms of the second, on the | ||||
|        given date. | ||||
| 
 | ||||
|        For  example, the following directives say that one euro was worth 1.35 | ||||
|        For example, the following directives say that one euro was worth  1.35 | ||||
|        US dollars during 2009, and $1.40 from 2010 onward: | ||||
| 
 | ||||
|               P 2009/1/1  $1.35 | ||||
|               P 2010/1/1  $1.40 | ||||
| 
 | ||||
|    Comments | ||||
|        Lines in the journal beginning with a semicolon  (;)  or  hash  (#)  or | ||||
|        asterisk  (*)  are  comments,  and will be ignored.  (Asterisk comments | ||||
|        make it easy to treat your journal like an org-mode outline in  emacs.) | ||||
|        Lines  in  the  journal  beginning  with a semicolon (;) or hash (#) or | ||||
|        asterisk (*) are comments, and will  be  ignored.   (Asterisk  comments | ||||
|        make  it easy to treat your journal like an org-mode outline in emacs.) | ||||
| 
 | ||||
|        Also,   anything  between  comment  and  end comment  directives  is  a | ||||
|        (multi-line) comment.  If there is no end comment, the comment  extends | ||||
|        Also,  anything  between  comment  and  end comment  directives  is   a | ||||
|        (multi-line)  comment.  If there is no end comment, the comment extends | ||||
|        to the end of the file. | ||||
| 
 | ||||
|        You  can  attach  comments  to  a transaction by writing them after the | ||||
|        description and/or indented on the following lines  (before  the  post- | ||||
|        ings).   Similarly, you can attach comments to an individual posting by | ||||
|        You can attach comments to a transaction  by  writing  them  after  the | ||||
|        description  and/or  indented  on the following lines (before the post- | ||||
|        ings).  Similarly, you can attach comments to an individual posting  by | ||||
|        writing them after the amount and/or indented on the following lines. | ||||
| 
 | ||||
|        Some examples: | ||||
| @ -538,20 +558,20 @@ FILE FORMAT | ||||
|               ; a journal comment (because not indented) | ||||
| 
 | ||||
|    Tags | ||||
|        Tags are a way to add extra labels or labelled  data  to  postings  and | ||||
|        Tags  are  a  way  to add extra labels or labelled data to postings and | ||||
|        transactions, which you can then search or pivot on. | ||||
| 
 | ||||
|        A  simple  tag is a word (which may contain hyphens) followed by a full | ||||
|        A simple tag is a word (which may contain hyphens) followed by  a  full | ||||
|        colon, written inside a transaction or posting comment line: | ||||
| 
 | ||||
|               2017/1/16 bought groceries    ; sometag: | ||||
| 
 | ||||
|        Tags can have a value, which is the text after the  colon,  up  to  the | ||||
|        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: | ||||
| 
 | ||||
|                   expenses:food    $10   ; a-posting-tag: the tag value | ||||
| 
 | ||||
|        Note  this  means  hledger's  tag values can not contain commas or new- | ||||
|        Note this means hledger's tag values can not  contain  commas  or  new- | ||||
|        lines.  Ending at commas means you can write multiple short tags on one | ||||
|        line, comma separated: | ||||
| 
 | ||||
| @ -565,16 +585,16 @@ FILE FORMAT | ||||
| 
 | ||||
|        o "tag2" is another tag, whose value is "some value ..." | ||||
| 
 | ||||
|        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  (A, TAG2, | ||||
|        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  (A,  TAG2, | ||||
|        third-tag) and the posting has four (those plus posting-tag): | ||||
| 
 | ||||
|               1/1 a transaction  ; A:, TAG2: | ||||
|                   ; third-tag: a third transaction tag, <- with a value | ||||
|                   (a)  $1  ; posting-tag: | ||||
| 
 | ||||
|        Tags are like Ledger's metadata feature, except  hledger's  tag  values | ||||
|        Tags  are  like  Ledger's metadata feature, except hledger's tag values | ||||
|        are simple strings. | ||||
| 
 | ||||
|    Implicit tags | ||||
| @ -588,14 +608,14 @@ FILE FORMAT | ||||
| 
 | ||||
|        o note - the part of description after |, or all of it | ||||
| 
 | ||||
|        payee  and  note support descriptions written in a special PAYEE | NOTE | ||||
|        payee and note support descriptions written in a  special  PAYEE | NOTE | ||||
|        format, accessing the parts before and after the pipe character respec- | ||||
|        tively.   For descriptions not containing a pipe character they are the | ||||
|        tively.  For descriptions not containing a pipe character they are  the | ||||
|        same as description. | ||||
| 
 | ||||
|    Directives | ||||
|    Account aliases | ||||
|        You can define aliases which rewrite your account names (after  reading | ||||
|        You  can define aliases which rewrite your account names (after reading | ||||
|        the journal, before generating reports).  hledger's account aliases can | ||||
|        be useful for: | ||||
| 
 | ||||
| @ -612,8 +632,8 @@ FILE FORMAT | ||||
|        See also Cookbook: rewrite account names. | ||||
| 
 | ||||
|    Basic aliases | ||||
|        To set an account alias, use the alias directive in your journal  file. | ||||
|        This  affects all subsequent journal entries in the current file or its | ||||
|        To  set an account alias, use the alias directive in your journal file. | ||||
|        This affects all subsequent journal entries in the current file or  its | ||||
|        included files.  The spaces around the = are optional: | ||||
| 
 | ||||
|               alias OLD = NEW | ||||
| @ -621,52 +641,52 @@ FILE FORMAT | ||||
|        Or, you can use the --alias 'OLD=NEW' option on the command line.  This | ||||
|        affects all entries.  It's useful for trying out aliases interactively. | ||||
| 
 | ||||
|        OLD and NEW are full account names.  hledger will  replace  any  occur- | ||||
|        rence  of  the old account name with the new one.  Subaccounts are also | ||||
|        OLD  and  NEW  are full account names.  hledger will replace any occur- | ||||
|        rence of the old account name with the new one.  Subaccounts  are  also | ||||
|        affected.  Eg: | ||||
| 
 | ||||
|               alias checking = assets:bank:wells fargo:checking | ||||
|               # rewrites "checking" to "assets:bank:wells fargo:checking", or "checking:a" to "assets:bank:wells fargo:checking:a" | ||||
| 
 | ||||
|    Regex aliases | ||||
|        There is also a more powerful variant that uses a  regular  expression, | ||||
|        There  is  also a more powerful variant that uses a regular expression, | ||||
|        indicated by the forward slashes: | ||||
| 
 | ||||
|               alias /REGEX/ = REPLACEMENT | ||||
| 
 | ||||
|        or --alias '/REGEX/=REPLACEMENT'. | ||||
| 
 | ||||
|        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- | ||||
|        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.  Note, cur- | ||||
|        rently  regular  expression  aliases  may  cause noticeable slow-downs. | ||||
|        rently regular expression  aliases  may  cause  noticeable  slow-downs. | ||||
|        (And if you use Ledger on your hledger file, they will be ignored.) Eg: | ||||
| 
 | ||||
|               alias /^(.+):bank:([^:]+)(.*)/ = \1:\2 \3 | ||||
|               # rewrites "assets:bank:wells fargo:checking" to  "assets:wells fargo checking" | ||||
| 
 | ||||
|    Multiple aliases | ||||
|        You  can  define  as  many aliases as you like using directives or com- | ||||
|        mand-line options.  Aliases are recursive - each alias sees the  result | ||||
|        of  applying  previous  ones.   (This  is  different from Ledger, where | ||||
|        You can define as many aliases as you like  using  directives  or  com- | ||||
|        mand-line  options.  Aliases are recursive - each alias sees the result | ||||
|        of applying previous ones.   (This  is  different  from  Ledger,  where | ||||
|        aliases are non-recursive by default).  Aliases are applied in the fol- | ||||
|        lowing order: | ||||
| 
 | ||||
|        1. alias  directives,  most recently seen first (recent directives take | ||||
|        1. alias directives, most recently seen first (recent  directives  take | ||||
|           precedence over earlier ones; directives not yet seen are ignored) | ||||
| 
 | ||||
|        2. alias options, in the order they appear on the command line | ||||
| 
 | ||||
|    end aliases | ||||
|        You  can  clear  (forget)  all  currently  defined  aliases  with   the | ||||
|        You   can  clear  (forget)  all  currently  defined  aliases  with  the | ||||
|        end aliases directive: | ||||
| 
 | ||||
|               end aliases | ||||
| 
 | ||||
|    account directive | ||||
|        The  account directive predefines account names, as in Ledger and Bean- | ||||
|        count.  This may be useful for your own documentation; hledger  doesn't | ||||
|        The account directive predefines account names, as in Ledger and  Bean- | ||||
|        count.   This may be useful for your own documentation; hledger doesn't | ||||
|        make use of it yet. | ||||
| 
 | ||||
|               ; account ACCT | ||||
| @ -681,8 +701,8 @@ FILE FORMAT | ||||
|               ; etc. | ||||
| 
 | ||||
|    apply account directive | ||||
|        You  can  specify  a  parent  account  which  will  be prepended to all | ||||
|        accounts within a section of the journal.  Use  the  apply account  and | ||||
|        You can specify a  parent  account  which  will  be  prepended  to  all | ||||
|        accounts  within  a  section of the journal.  Use the apply account and | ||||
|        end apply account directives like so: | ||||
| 
 | ||||
|               apply account home | ||||
| @ -699,7 +719,7 @@ FILE FORMAT | ||||
|                   home:food           $10 | ||||
|                   home:cash          $-10 | ||||
| 
 | ||||
|        If  end apply account  is  omitted,  the effect lasts to the end of the | ||||
|        If end apply account is omitted, the effect lasts to  the  end  of  the | ||||
|        file.  Included files are also affected, eg: | ||||
| 
 | ||||
|               apply account business | ||||
| @ -708,16 +728,16 @@ FILE FORMAT | ||||
|               apply account personal | ||||
|               include personal.journal | ||||
| 
 | ||||
|        Prior to hledger 1.0, legacy account and end spellings were  also  sup- | ||||
|        Prior  to  hledger 1.0, legacy account and end spellings were also sup- | ||||
|        ported. | ||||
| 
 | ||||
|    Multi-line comments | ||||
|        A  line containing just comment starts a multi-line comment, and a line | ||||
|        A line containing just comment starts a multi-line comment, and a  line | ||||
|        containing just end comment ends it.  See comments. | ||||
| 
 | ||||
|    commodity directive | ||||
|        The commodity directive predefines commodities (currently this is  just | ||||
|        informational),  and  also it may define the display format for amounts | ||||
|        The  commodity directive predefines commodities (currently this is just | ||||
|        informational), and also it may define the display format  for  amounts | ||||
|        in this commodity (overriding the automatically inferred format). | ||||
| 
 | ||||
|        It may be written on a single line, like this: | ||||
| @ -729,8 +749,8 @@ FILE FORMAT | ||||
|               ; separating thousands with comma. | ||||
|               commodity 1,000.0000 AAAA | ||||
| 
 | ||||
|        or on multiple lines, using the "format" subdirective.   In  this  case | ||||
|        the  commodity  symbol  appears  twice  and  should be the same in both | ||||
|        or  on  multiple  lines, using the "format" subdirective.  In this case | ||||
|        the commodity symbol appears twice and  should  be  the  same  in  both | ||||
|        places: | ||||
| 
 | ||||
|               ; commodity SYMBOL | ||||
| @ -743,10 +763,10 @@ FILE FORMAT | ||||
|                 format INR 9,99,99,999.00 | ||||
| 
 | ||||
|    Default commodity | ||||
|        The D directive sets a default commodity (and display  format),  to  be | ||||
|        The  D  directive  sets a default commodity (and display format), to be | ||||
|        used for amounts without a commodity symbol (ie, plain numbers).  (Note | ||||
|        this differs from Ledger's default commodity directive.) The  commodity | ||||
|        and  display  format  will  be applied to all subsequent commodity-less | ||||
|        this  differs from Ledger's default commodity directive.) The commodity | ||||
|        and display format will be applied  to  all  subsequent  commodity-less | ||||
|        amounts, or until the next D directive. | ||||
| 
 | ||||
|               # commodity-less amounts should be treated as dollars | ||||
| @ -758,8 +778,8 @@ FILE FORMAT | ||||
|                 b | ||||
| 
 | ||||
|    Default year | ||||
|        You can set a default year to be used for subsequent dates which  don't | ||||
|        specify  a year.  This is a line beginning with Y followed by the year. | ||||
|        You  can set a default year to be used for subsequent dates which don't | ||||
|        specify a year.  This is a line beginning with Y followed by the  year. | ||||
|        Eg: | ||||
| 
 | ||||
|               Y2009      ; set default year to 2009 | ||||
| @ -779,24 +799,24 @@ FILE FORMAT | ||||
|                 assets | ||||
| 
 | ||||
|    Including other files | ||||
|        You can pull in the content of additional journal files by  writing  an | ||||
|        You  can  pull in the content of additional journal files by writing an | ||||
|        include directive, like this: | ||||
| 
 | ||||
|               include path/to/file.journal | ||||
| 
 | ||||
|        If  the path does not begin with a slash, it is relative to the current | ||||
|        If the path does not begin with a slash, it is relative to the  current | ||||
|        file.  Glob patterns (*) are not currently supported. | ||||
| 
 | ||||
|        The include directive can only  be  used  in  journal  files.   It  can | ||||
|        The  include  directive  can  only  be  used  in journal files.  It can | ||||
|        include journal, timeclock or timedot files, but not CSV files. | ||||
| 
 | ||||
| EDITOR SUPPORT | ||||
|        Add-on modes exist for various text editors, to make working with jour- | ||||
|        nal files easier.  They add colour, navigation aids  and  helpful  com- | ||||
|        mands.   For  hledger  users  who  edit  the journal file directly (the | ||||
|        nal  files  easier.   They add colour, navigation aids and helpful com- | ||||
|        mands.  For hledger users who  edit  the  journal  file  directly  (the | ||||
|        majority), using one of these modes is quite recommended. | ||||
| 
 | ||||
|        These were written with Ledger in mind,  but  also  work  with  hledger | ||||
|        These  were  written  with  Ledger  in mind, but also work with hledger | ||||
|        files: | ||||
| 
 | ||||
| 
 | ||||
| @ -813,7 +833,7 @@ EDITOR SUPPORT | ||||
| 
 | ||||
| 
 | ||||
| REPORTING BUGS | ||||
|        Report  bugs at http://bugs.hledger.org (or on the #hledger IRC channel | ||||
|        Report bugs at http://bugs.hledger.org (or on the #hledger IRC  channel | ||||
|        or hledger mail list) | ||||
| 
 | ||||
| 
 | ||||
| @ -827,7 +847,7 @@ COPYRIGHT | ||||
| 
 | ||||
| 
 | ||||
| SEE ALSO | ||||
|        hledger(1),     hledger-ui(1),     hledger-web(1),      hledger-api(1), | ||||
|        hledger(1),      hledger-ui(1),     hledger-web(1),     hledger-api(1), | ||||
|        hledger_csv(5), hledger_journal(5), hledger_timeclock(5), hledger_time- | ||||
|        dot(5), ledger(1) | ||||
| 
 | ||||
|  | ||||
| @ -151,13 +151,13 @@ include only cleared postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-\-pending\f[] | ||||
| .B \f[C]\-P\ \-\-pending\f[] | ||||
| include only pending postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-U\ \-\-uncleared\f[] | ||||
| include only uncleared (and pending) postings/txns | ||||
| include only unmarked postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| @ -255,7 +255,7 @@ using the same query terms as in hledger and hledger\-web. | ||||
| While editing the query, you can use CTRL\-a/e/d/k, BS, cursor keys; | ||||
| press \f[C]ENTER\f[] to set it, or \f[C]ESCAPE\f[]to cancel. | ||||
| There are also keys for quickly adjusting some common filters like | ||||
| account depth and cleared/uncleared (see below). | ||||
| account depth and transaction status (see below). | ||||
| \f[C]BACKSPACE\f[] or \f[C]DELETE\f[] removes all filters, showing all | ||||
| transactions. | ||||
| .PP | ||||
| @ -322,10 +322,11 @@ Period balances ignore transactions before the report start date, so | ||||
| they show the change in balance during the report period. | ||||
| They are more useful eg when viewing a time log. | ||||
| .PP | ||||
| \f[C]C\f[] toggles cleared mode, in which uncleared transactions and | ||||
| postings are not shown. | ||||
| \f[C]U\f[] toggles uncleared mode, in which only uncleared | ||||
| transactions/postings are shown. | ||||
| \f[C]C\f[] toggles cleared mode, which shows balances for postings with | ||||
| cleared status only. | ||||
| Similarly, \f[C]P\f[] toggles pending mode, which shows balances for | ||||
| pending postings only, and \f[C]U\f[] toggles uncleared mode, which | ||||
| shows balances for unmarked postings only. | ||||
| .PP | ||||
| \f[C]R\f[] toggles real mode, in which virtual postings are ignored. | ||||
| .PP | ||||
| @ -367,10 +368,11 @@ In other words, the register always shows the transactions responsible | ||||
| for the period balance shown on the accounts screen. | ||||
| As on the accounts screen, this can be toggled with \f[C]F\f[]. | ||||
| .PP | ||||
| \f[C]C\f[] toggles cleared mode, in which uncleared transactions and | ||||
| postings are not shown. | ||||
| \f[C]U\f[] toggles uncleared mode, in which only uncleared | ||||
| transactions/postings are shown. | ||||
| \f[C]C\f[] toggles cleared mode, which shows transactions with cleared | ||||
| status only. | ||||
| Similarly, \f[C]P\f[] toggles pending mode, which shows only pending | ||||
| transactions, and \f[C]U\f[] toggles uncleared mode, which shows only | ||||
| unmarked transactions. | ||||
| .PP | ||||
| \f[C]R\f[] toggles real mode, in which virtual postings are ignored. | ||||
| .PP | ||||
|  | ||||
| @ -107,12 +107,12 @@ the data. | ||||
| '-C --cleared' | ||||
| 
 | ||||
|      include only cleared postings/txns | ||||
| '--pending' | ||||
| '-P --pending' | ||||
| 
 | ||||
|      include only pending postings/txns | ||||
| '-U --uncleared' | ||||
| 
 | ||||
|      include only uncleared (and pending) postings/txns | ||||
|      include only unmarked postings/txns | ||||
| '-R --real' | ||||
| 
 | ||||
|      include only non-virtual postings | ||||
| @ -186,7 +186,7 @@ non-standard period, you can use '/' and a 'date:' query. | ||||
| using the same query terms as in hledger and hledger-web.  While editing | ||||
| the query, you can use CTRL-a/e/d/k, BS, cursor keys; press 'ENTER' to | ||||
| set it, or 'ESCAPE'to cancel.  There are also keys for quickly adjusting | ||||
| some common filters like account depth and cleared/uncleared (see | ||||
| some common filters like account depth and transaction status (see | ||||
| below).  'BACKSPACE' or 'DELETE' removes all filters, showing all | ||||
| transactions. | ||||
| 
 | ||||
| @ -260,9 +260,10 @@ disturbed by a filter query).  Period balances ignore transactions | ||||
| before the report start date, so they show the change in balance during | ||||
| the report period.  They are more useful eg when viewing a time log. | ||||
| 
 | ||||
|    'C' toggles cleared mode, in which uncleared transactions and | ||||
| postings are not shown.  'U' toggles uncleared mode, in which only | ||||
| uncleared transactions/postings are shown. | ||||
|    'C' toggles cleared mode, which shows balances for postings with | ||||
| cleared status only.  Similarly, 'P' toggles pending mode, which shows | ||||
| balances for pending postings only, and 'U' toggles uncleared mode, | ||||
| which shows balances for unmarked postings only. | ||||
| 
 | ||||
|    'R' toggles real mode, in which virtual postings are ignored. | ||||
| 
 | ||||
| @ -304,9 +305,10 @@ subaccounts.  In other words, the register always shows the transactions | ||||
| responsible for the period balance shown on the accounts screen.  As on | ||||
| the accounts screen, this can be toggled with 'F'. | ||||
| 
 | ||||
|    'C' toggles cleared mode, in which uncleared transactions and | ||||
| postings are not shown.  'U' toggles uncleared mode, in which only | ||||
| uncleared transactions/postings are shown. | ||||
|    'C' toggles cleared mode, which shows transactions with cleared | ||||
| status only.  Similarly, 'P' toggles pending mode, which shows only | ||||
| pending transactions, and 'U' toggles uncleared mode, which shows only | ||||
| unmarked transactions. | ||||
| 
 | ||||
|    'R' toggles real mode, in which virtual postings are ignored. | ||||
| 
 | ||||
| @ -357,17 +359,17 @@ Tag Table: | ||||
| Node: Top73 | ||||
| Node: OPTIONS831 | ||||
| Ref: #options930 | ||||
| Node: KEYS3656 | ||||
| Ref: #keys3753 | ||||
| Node: SCREENS6341 | ||||
| Ref: #screens6428 | ||||
| Node: Accounts screen6518 | ||||
| Ref: #accounts-screen6648 | ||||
| Node: Register screen8697 | ||||
| Ref: #register-screen8854 | ||||
| Node: Transaction screen10743 | ||||
| Ref: #transaction-screen10903 | ||||
| Node: Error screen11773 | ||||
| Ref: #error-screen11897 | ||||
| Node: KEYS3644 | ||||
| Ref: #keys3741 | ||||
| Node: SCREENS6330 | ||||
| Ref: #screens6417 | ||||
| Node: Accounts screen6507 | ||||
| Ref: #accounts-screen6637 | ||||
| Node: Register screen8767 | ||||
| Ref: #register-screen8924 | ||||
| Node: Transaction screen10867 | ||||
| Ref: #transaction-screen11027 | ||||
| Node: Error screen11897 | ||||
| Ref: #error-screen12021 | ||||
|  | ||||
| End Tag Table | ||||
|  | ||||
| @ -104,11 +104,11 @@ OPTIONS | ||||
|        -C --cleared | ||||
|               include only cleared postings/txns | ||||
| 
 | ||||
|        --pending | ||||
|        -P --pending | ||||
|               include only pending postings/txns | ||||
| 
 | ||||
|        -U --uncleared | ||||
|               include only uncleared (and pending) postings/txns | ||||
|               include only unmarked postings/txns | ||||
| 
 | ||||
|        -R --real | ||||
|               include only non-virtual postings | ||||
| @ -170,7 +170,7 @@ KEYS | ||||
|        the  same query terms as in hledger and hledger-web.  While editing the | ||||
|        query, you can use CTRL-a/e/d/k, BS, cursor keys; press  ENTER  to  set | ||||
|        it, or ESCAPEto cancel.  There are also keys for quickly adjusting some | ||||
|        common filters like account depth and  cleared/uncleared  (see  below). | ||||
|        common filters like account depth and transaction status  (see  below). | ||||
|        BACKSPACE or DELETE removes all filters, showing all transactions. | ||||
| 
 | ||||
|        ESCAPE  removes  all  filters and jumps back to the top screen.  Or, it | ||||
| @ -226,14 +226,15 @@ SCREENS | ||||
|        before the report start date, so they show the change in balance during | ||||
|        the report period.  They are more useful eg when viewing a time log. | ||||
| 
 | ||||
|        C toggles cleared mode, in which uncleared  transactions  and  postings | ||||
|        are  not  shown.   U  toggles  uncleared  mode, in which only uncleared | ||||
|        transactions/postings are shown. | ||||
|        C toggles cleared mode, which shows balances for postings with  cleared | ||||
|        status  only.   Similarly, P toggles pending mode, which shows balances | ||||
|        for pending postings only, and U toggles uncleared  mode,  which  shows | ||||
|        balances for unmarked postings only. | ||||
| 
 | ||||
|        R toggles real mode, in which virtual postings are ignored. | ||||
| 
 | ||||
|        Z toggles nonzero mode, in which only accounts  with  nonzero  balances | ||||
|        are  shown (hledger-ui shows zero items by default, unlike command-line | ||||
|        Z  toggles  nonzero  mode, in which only accounts with nonzero balances | ||||
|        are shown (hledger-ui shows zero items by default, unlike  command-line | ||||
|        hledger). | ||||
| 
 | ||||
|        Press right or enter to view an account's transactions register. | ||||
| @ -242,32 +243,33 @@ SCREENS | ||||
|        This screen shows the transactions affecting a particular account, like | ||||
|        a check register.  Each line represents one transaction and shows: | ||||
| 
 | ||||
|        o the  other  account(s)  involved, in abbreviated form.  (If there are | ||||
|          both real and virtual postings, it shows only the  accounts  affected | ||||
|        o the other account(s) involved, in abbreviated form.   (If  there  are | ||||
|          both  real  and virtual postings, it shows only the accounts affected | ||||
|          by real postings.) | ||||
| 
 | ||||
|        o the  overall change to the current account's balance; positive for an | ||||
|        o the overall change to the current account's balance; positive for  an | ||||
|          inflow to this account, negative for an outflow. | ||||
| 
 | ||||
|        o the running historical total or period total for the current account, | ||||
|          after  the  transaction.  This can be toggled with H.  Similar to the | ||||
|          accounts screen, the historical total  is  affected  by  transactions | ||||
|          (filtered  by  the  filter query) before the report start date, while | ||||
|          after the transaction.  This can be toggled with H.  Similar  to  the | ||||
|          accounts  screen,  the  historical  total is affected by transactions | ||||
|          (filtered by the filter query) before the report  start  date,  while | ||||
|          the period total is not.  If the historical total is not disturbed by | ||||
|          a  filter  query, it will be the running historical balance you would | ||||
|          a filter query, it will be the running historical balance  you  would | ||||
|          see on a bank register for the current account. | ||||
| 
 | ||||
|        If the accounts screen was in  tree  mode,  the  register  screen  will | ||||
|        If  the  accounts  screen  was  in  tree mode, the register screen will | ||||
|        include transactions from both the current account and its subaccounts. | ||||
|        If the accounts screen  was  in  flat  mode,  and  a  non-depth-clipped | ||||
|        account  was  selected,  the  register screen will exclude transactions | ||||
|        If  the  accounts  screen  was  in  flat  mode, and a non-depth-clipped | ||||
|        account was selected, the register  screen  will  exclude  transactions | ||||
|        from subaccounts.  In other words, the register always shows the trans- | ||||
|        actions  responsible  for  the  period  balance  shown  on the accounts | ||||
|        actions responsible for  the  period  balance  shown  on  the  accounts | ||||
|        screen.  As on the accounts screen, this can be toggled with F. | ||||
| 
 | ||||
|        C toggles cleared mode, in which uncleared  transactions  and  postings | ||||
|        are  not  shown.   U  toggles  uncleared  mode, in which only uncleared | ||||
|        transactions/postings are shown. | ||||
|        C  toggles  cleared  mode, which shows transactions with cleared status | ||||
|        only.  Similarly, P toggles pending  mode,  which  shows  only  pending | ||||
|        transactions,  and  U toggles uncleared mode, which shows only unmarked | ||||
|        transactions. | ||||
| 
 | ||||
|        R toggles real mode, in which virtual postings are ignored. | ||||
| 
 | ||||
|  | ||||
| @ -207,13 +207,13 @@ include only cleared postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-\-pending\f[] | ||||
| .B \f[C]\-P\ \-\-pending\f[] | ||||
| include only pending postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-U\ \-\-uncleared\f[] | ||||
| include only uncleared (and pending) postings/txns | ||||
| include only unmarked postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
|  | ||||
| @ -152,12 +152,12 @@ options as shown above. | ||||
| '-C --cleared' | ||||
| 
 | ||||
|      include only cleared postings/txns | ||||
| '--pending' | ||||
| '-P --pending' | ||||
| 
 | ||||
|      include only pending postings/txns | ||||
| '-U --uncleared' | ||||
| 
 | ||||
|      include only uncleared (and pending) postings/txns | ||||
|      include only unmarked postings/txns | ||||
| '-R --real' | ||||
| 
 | ||||
|      include only non-virtual postings | ||||
|  | ||||
| @ -149,11 +149,11 @@ OPTIONS | ||||
|        -C --cleared | ||||
|               include only cleared postings/txns | ||||
| 
 | ||||
|        --pending | ||||
|        -P --pending | ||||
|               include only pending postings/txns | ||||
| 
 | ||||
|        -U --uncleared | ||||
|               include only uncleared (and pending) postings/txns | ||||
|               include only unmarked postings/txns | ||||
| 
 | ||||
|        -R --real | ||||
|               include only non-virtual postings | ||||
|  | ||||
| @ -278,13 +278,13 @@ include only cleared postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-\-pending\f[] | ||||
| .B \f[C]\-P\ \-\-pending\f[] | ||||
| include only pending postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| .B \f[C]\-U\ \-\-uncleared\f[] | ||||
| include only uncleared (and pending) postings/txns | ||||
| include only unmarked postings/txns | ||||
| .RS | ||||
| .RE | ||||
| .TP | ||||
| @ -968,6 +968,8 @@ any of the description terms AND | ||||
| .IP \[bu] 2 | ||||
| any of the account terms AND | ||||
| .IP \[bu] 2 | ||||
| any of the status terms AND | ||||
| .IP \[bu] 2 | ||||
| all the other terms. | ||||
| .PP | ||||
| The print command: show transactions which | ||||
|  | ||||
| @ -217,12 +217,12 @@ different, like git.) | ||||
| '-C --cleared' | ||||
| 
 | ||||
|      include only cleared postings/txns | ||||
| '--pending' | ||||
| '-P --pending' | ||||
| 
 | ||||
|      include only pending postings/txns | ||||
| '-U --uncleared' | ||||
| 
 | ||||
|      include only uncleared (and pending) postings/txns | ||||
|      include only unmarked postings/txns | ||||
| '-R --real' | ||||
| 
 | ||||
|      include only non-virtual postings | ||||
| @ -686,6 +686,7 @@ match (or negatively match) | ||||
| 
 | ||||
|    * any of the description terms AND | ||||
|    * any of the account terms AND | ||||
|    * any of the status terms AND | ||||
|    * all the other terms. | ||||
| 
 | ||||
|    The print command: show transactions which | ||||
| @ -2119,123 +2120,123 @@ Node: OPTIONS3640 | ||||
| Ref: #options3744 | ||||
| Node: General options4025 | ||||
| Ref: #general-options4152 | ||||
| Node: Command options6675 | ||||
| Ref: #command-options6828 | ||||
| Node: Command arguments7226 | ||||
| Ref: #command-arguments7386 | ||||
| Node: Special characters7507 | ||||
| Ref: #special-characters7665 | ||||
| Node: Input files8833 | ||||
| Ref: #input-files8971 | ||||
| Node: Smart dates10934 | ||||
| Ref: #smart-dates11077 | ||||
| Node: Report start & end date12056 | ||||
| Ref: #report-start-end-date12228 | ||||
| Node: Report intervals13294 | ||||
| Ref: #report-intervals13459 | ||||
| Node: Period expressions13860 | ||||
| Ref: #period-expressions14020 | ||||
| Node: Depth limiting16360 | ||||
| Ref: #depth-limiting16506 | ||||
| Node: Pivoting16707 | ||||
| Ref: #pivoting16827 | ||||
| Node: Cost18598 | ||||
| Ref: #cost18708 | ||||
| Node: Market value18826 | ||||
| Ref: #market-value18963 | ||||
| Node: Regular expressions20263 | ||||
| Ref: #regular-expressions20401 | ||||
| Node: QUERIES21762 | ||||
| Ref: #queries21866 | ||||
| Node: COMMANDS25512 | ||||
| Ref: #commands25626 | ||||
| Node: accounts26299 | ||||
| Ref: #accounts26399 | ||||
| Node: activity27381 | ||||
| Ref: #activity27493 | ||||
| Node: add27852 | ||||
| Ref: #add27953 | ||||
| Node: balance30611 | ||||
| Ref: #balance30724 | ||||
| Node: Flat mode33739 | ||||
| Ref: #flat-mode33866 | ||||
| Node: Depth limited balance reports34286 | ||||
| Ref: #depth-limited-balance-reports34489 | ||||
| Node: Multicolumn balance reports34909 | ||||
| Ref: #multicolumn-balance-reports35120 | ||||
| Node: Custom balance output39768 | ||||
| Ref: #custom-balance-output39952 | ||||
| Node: Colour support42045 | ||||
| Ref: #colour-support42206 | ||||
| Node: Output destination42379 | ||||
| Ref: #output-destination42537 | ||||
| Node: CSV output42807 | ||||
| Ref: #csv-output42926 | ||||
| Node: balancesheet43323 | ||||
| Ref: #balancesheet43451 | ||||
| Node: cashflow45358 | ||||
| Ref: #cashflow45475 | ||||
| Node: help47343 | ||||
| Ref: #help47455 | ||||
| Node: incomestatement48293 | ||||
| Ref: #incomestatement48423 | ||||
| Node: info50315 | ||||
| Ref: #info50422 | ||||
| Node: man50786 | ||||
| Ref: #man50883 | ||||
| Node: print51288 | ||||
| Ref: #print51393 | ||||
| Node: register55149 | ||||
| Ref: #register55262 | ||||
| Node: Custom register output59758 | ||||
| Ref: #custom-register-output59889 | ||||
| Node: stats61186 | ||||
| Ref: #stats61292 | ||||
| Node: test62173 | ||||
| Ref: #test62260 | ||||
| Node: ADD-ON COMMANDS62628 | ||||
| Ref: #add-on-commands62740 | ||||
| Node: Official add-ons64027 | ||||
| Ref: #official-add-ons64169 | ||||
| Node: api64256 | ||||
| Ref: #api64347 | ||||
| Node: ui64399 | ||||
| Ref: #ui64500 | ||||
| Node: web64558 | ||||
| Ref: #web64649 | ||||
| Node: Third party add-ons64695 | ||||
| Ref: #third-party-add-ons64872 | ||||
| Node: diff65007 | ||||
| Ref: #diff65106 | ||||
| Node: iadd65205 | ||||
| Ref: #iadd65321 | ||||
| Node: interest65404 | ||||
| Ref: #interest65527 | ||||
| Node: irr65622 | ||||
| Ref: #irr65722 | ||||
| Node: Experimental add-ons65800 | ||||
| Ref: #experimental-add-ons65954 | ||||
| Node: autosync66347 | ||||
| Ref: #autosync66461 | ||||
| Node: budget66700 | ||||
| Ref: #budget66824 | ||||
| Node: chart66890 | ||||
| Ref: #chart67009 | ||||
| Node: check67080 | ||||
| Ref: #check67204 | ||||
| Node: check-dates67271 | ||||
| Ref: #check-dates67413 | ||||
| Node: check-dupes67486 | ||||
| Ref: #check-dupes67629 | ||||
| Node: equity67706 | ||||
| Ref: #equity67834 | ||||
| Node: prices67953 | ||||
| Ref: #prices68082 | ||||
| Node: print-unique68137 | ||||
| Ref: #print-unique68286 | ||||
| Node: register-match68379 | ||||
| Ref: #register-match68535 | ||||
| Node: rewrite68633 | ||||
| Ref: #rewrite68754 | ||||
| Node: Command options6663 | ||||
| Ref: #command-options6816 | ||||
| Node: Command arguments7214 | ||||
| Ref: #command-arguments7374 | ||||
| Node: Special characters7495 | ||||
| Ref: #special-characters7653 | ||||
| Node: Input files8821 | ||||
| Ref: #input-files8959 | ||||
| Node: Smart dates10922 | ||||
| Ref: #smart-dates11065 | ||||
| Node: Report start & end date12044 | ||||
| Ref: #report-start-end-date12216 | ||||
| Node: Report intervals13282 | ||||
| Ref: #report-intervals13447 | ||||
| Node: Period expressions13848 | ||||
| Ref: #period-expressions14008 | ||||
| Node: Depth limiting16348 | ||||
| Ref: #depth-limiting16494 | ||||
| Node: Pivoting16695 | ||||
| Ref: #pivoting16815 | ||||
| Node: Cost18586 | ||||
| Ref: #cost18696 | ||||
| Node: Market value18814 | ||||
| Ref: #market-value18951 | ||||
| Node: Regular expressions20251 | ||||
| Ref: #regular-expressions20389 | ||||
| Node: QUERIES21750 | ||||
| Ref: #queries21854 | ||||
| Node: COMMANDS25533 | ||||
| Ref: #commands25647 | ||||
| Node: accounts26320 | ||||
| Ref: #accounts26420 | ||||
| Node: activity27402 | ||||
| Ref: #activity27514 | ||||
| Node: add27873 | ||||
| Ref: #add27974 | ||||
| Node: balance30632 | ||||
| Ref: #balance30745 | ||||
| Node: Flat mode33760 | ||||
| Ref: #flat-mode33887 | ||||
| Node: Depth limited balance reports34307 | ||||
| Ref: #depth-limited-balance-reports34510 | ||||
| Node: Multicolumn balance reports34930 | ||||
| Ref: #multicolumn-balance-reports35141 | ||||
| Node: Custom balance output39789 | ||||
| Ref: #custom-balance-output39973 | ||||
| Node: Colour support42066 | ||||
| Ref: #colour-support42227 | ||||
| Node: Output destination42400 | ||||
| Ref: #output-destination42558 | ||||
| Node: CSV output42828 | ||||
| Ref: #csv-output42947 | ||||
| Node: balancesheet43344 | ||||
| Ref: #balancesheet43472 | ||||
| Node: cashflow45379 | ||||
| Ref: #cashflow45496 | ||||
| Node: help47364 | ||||
| Ref: #help47476 | ||||
| Node: incomestatement48314 | ||||
| Ref: #incomestatement48444 | ||||
| Node: info50336 | ||||
| Ref: #info50443 | ||||
| Node: man50807 | ||||
| Ref: #man50904 | ||||
| Node: print51309 | ||||
| Ref: #print51414 | ||||
| Node: register55170 | ||||
| Ref: #register55283 | ||||
| Node: Custom register output59779 | ||||
| Ref: #custom-register-output59910 | ||||
| Node: stats61207 | ||||
| Ref: #stats61313 | ||||
| Node: test62194 | ||||
| Ref: #test62281 | ||||
| Node: ADD-ON COMMANDS62649 | ||||
| Ref: #add-on-commands62761 | ||||
| Node: Official add-ons64048 | ||||
| Ref: #official-add-ons64190 | ||||
| Node: api64277 | ||||
| Ref: #api64368 | ||||
| Node: ui64420 | ||||
| Ref: #ui64521 | ||||
| Node: web64579 | ||||
| Ref: #web64670 | ||||
| Node: Third party add-ons64716 | ||||
| Ref: #third-party-add-ons64893 | ||||
| Node: diff65028 | ||||
| Ref: #diff65127 | ||||
| Node: iadd65226 | ||||
| Ref: #iadd65342 | ||||
| Node: interest65425 | ||||
| Ref: #interest65548 | ||||
| Node: irr65643 | ||||
| Ref: #irr65743 | ||||
| Node: Experimental add-ons65821 | ||||
| Ref: #experimental-add-ons65975 | ||||
| Node: autosync66368 | ||||
| Ref: #autosync66482 | ||||
| Node: budget66721 | ||||
| Ref: #budget66845 | ||||
| Node: chart66911 | ||||
| Ref: #chart67030 | ||||
| Node: check67101 | ||||
| Ref: #check67225 | ||||
| Node: check-dates67292 | ||||
| Ref: #check-dates67434 | ||||
| Node: check-dupes67507 | ||||
| Ref: #check-dupes67650 | ||||
| Node: equity67727 | ||||
| Ref: #equity67855 | ||||
| Node: prices67974 | ||||
| Ref: #prices68103 | ||||
| Node: print-unique68158 | ||||
| Ref: #print-unique68307 | ||||
| Node: register-match68400 | ||||
| Ref: #register-match68556 | ||||
| Node: rewrite68654 | ||||
| Ref: #rewrite68775 | ||||
|  | ||||
| End Tag Table | ||||
|  | ||||
| @ -185,11 +185,11 @@ OPTIONS | ||||
|        -C --cleared | ||||
|               include only cleared postings/txns | ||||
| 
 | ||||
|        --pending | ||||
|        -P --pending | ||||
|               include only pending postings/txns | ||||
| 
 | ||||
|        -U --uncleared | ||||
|               include only uncleared (and pending) postings/txns | ||||
|               include only unmarked postings/txns | ||||
| 
 | ||||
|        -R --real | ||||
|               include only non-virtual postings | ||||
| @ -623,6 +623,8 @@ QUERIES | ||||
| 
 | ||||
|        o any of the account terms AND | ||||
| 
 | ||||
|        o any of the status terms AND | ||||
| 
 | ||||
|        o all the other terms. | ||||
| 
 | ||||
|        The print command: show transactions which | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user