mirror of
https://github.com/simonmichael/hledger.git
synced 2024-11-08 07:09:28 +03:00
49 lines
2.0 KiB
Plaintext
49 lines
2.0 KiB
Plaintext
|
|
||
|
|
2014/5/11: new read system spec.
|
||
|
|
--------------------------------
|
||
|
|
|
||
|
|
Reading a journal from some data source conceptually consists of:
|
||
|
|
|
||
|
|
1. Parse the data records into fields providing some or all of the standard
|
||
|
|
journal transaction fields - at least date, description and amount.
|
||
|
|
|
||
|
|
2. Expand (if needed) these partial journal transactions into
|
||
|
|
complete ones.
|
||
|
|
|
||
|
|
In practical terms, it happens in one of these ways:
|
||
|
|
|
||
|
|
1. the data source is a file or stdin
|
||
|
|
|
||
|
|
2.
|
||
|
|
If FILE.rules (or other file specified with --rules-file)
|
||
|
|
exists, it can define rules which help with parsing. Eg the skip,
|
||
|
|
fields, and date-format rules.
|
||
|
|
|
||
|
|
2. Expansion: partial transactions are fleshed out into complete ones.
|
||
|
|
Eg partial transactions from CSV records need to have an account and
|
||
|
|
a balancing posting added. Expansion is done in several ways:
|
||
|
|
|
||
|
|
1a. Rules: if FILE.rules (or other file specified with --rules-file)
|
||
|
|
exists, it can define rules which help with expansion. Eg field
|
||
|
|
assignments and conditional blocks.
|
||
|
|
|
||
|
|
Pro: easy, somewhat backward compatible, built in, cross platform.
|
||
|
|
Con: limited flexibility.
|
||
|
|
|
||
|
|
1b. Filter: or, if FILE-read (or other file specified with --read-filter)
|
||
|
|
exists, it is used as a filter to translate FILE into (partial) journal
|
||
|
|
format, which is then parsed with the (partial) journal reader.
|
||
|
|
Pro: powerful, flexible.
|
||
|
|
Con: requires programming & tools, data is parsed twice.
|
||
|
|
|
||
|
|
2a. History: if a transaction is still not complete, the best recent match
|
||
|
|
for it among existing transactions is used as a template to fill out
|
||
|
|
missing fields/postings (as with hledger add or ledger-autosync).
|
||
|
|
Pro: no rules or programming required, learns from past manual corrections.
|
||
|
|
Con: less precise, more likely to require manual correction, requires existing data.
|
||
|
|
|
||
|
|
2b. Guess: or, if there is no existing data or no acceptable match (or
|
||
|
|
history matching has been disabled with --no-history-match), we guess
|
||
|
|
default values for the missing fields.
|
||
|
|
|