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.
 | 
						|
 |