beancount
'insert-entry' logic (first account is ignored)
I've been using insert-entry extensively, and it's been working well so far. I just found out insert-entry accepts regex, and decided to use this:-
2020-12-31 custom "fava-option" "insert-entry" ".*"
The objective was for any transactions which I don't have an explicit insert-entry for (all my other insert-entry options are dated 2021-01-01) to be caught by this one for my later sorting.
This didn't work the way I expected, instead ALL transactions are now being caught. When reviewing the documentation, I found this:-
"When adding an entry, the account of the entry (for a transaction, the account of the last posting is used) is matched against all insert-entry options and the entry will be inserted before the datewise latest of the matching options. If the entry is a Transaction and no insert-entry option matches the account of the last posting the account of the second to last posting and so on will be tried. If no insert-entry option matches or none is given, the entry will be inserted at the end of the main file."
This seems unintuitive to me because my 'primary' account is generally put as the first posting. So for example:-
2021-02-23 * "Lunch" Assets:Cash -15.00 XXX Expenses:Dining:Food
Previously without my catch-all this worked well as no insert-entry was matched so it 'fell through' to checking the first posting. Now of course the fall through doesn't happen.
Having to change how I order postings would be annoying to say the least (especially since the behaviour I have to change would be my wife's, not mine), so is it possible for matching to be done on first posting? Or another way of getting 'catch all' behaviour which doesn't totally ignore the first posting? Perhaps a hook to reorder postings automatically?
This seems unintuitive to me because my 'primary' account is generally put as the first posting.
Annoyingly for you, the Beancount convention is other way around, which is why Fava has the described behaviour. And I don't really want to change it to the reverse.
Or another way of getting 'catch all' behaviour which doesn't totally ignore the first posting? Perhaps a hook to reorder postings automatically?
Reordering sounds a bit excessive. Using a negative lookahead, you could try to write a regular expression that only matches when all your others don't, something like (?!(FIRST_RE)|(SECOND_RE)).*
Annoyingly for you, the Beancount convention is other way around, which is why Fava has the described behaviour. And I don't really want to change it to the reverse.
That's fair of course.
Or another way of getting 'catch all' behaviour which doesn't totally ignore the first posting? Perhaps a hook to reorder postings automatically?
Reordering sounds a bit excessive. Using a negative lookahead, you could try to write a regular expression that only matches when all your others don't, something like
(?!(FIRST_RE)|(SECOND_RE)).*
'All my others' in this case is 47 positive matches though, so I'm not sure a negative lookahead is feasible here (would there be performance issues for example, not to mention making sure my regex was updated would be a pain). Basically 47 bank accounts/credit cards/investment accounts that I keep track of.
So that circles round to whether there's another way I can get 'catch all' behaviour? Right now when nothing is found it will just dump the transaction at the end of the file, which is problematic for me because my Accounts.beancount file is just a list of includes. This wouldn't be a huge issue except it intersects with another issue where decimal placings for fava display (and previously bean-web, so I don't think this is a fava issue) prioritize what's in the main file for some reason. So for example I use X.XX everywhere and that's what is normally displayed by fava even when the odd transaction accidentally omits the two digits after the decimal. Then accidentally a transaction doesn't get caught by my insert-entry lines, gets dumped in Accounts.beancount, AND omits the digits after the decimal, and everything in fava now displays without the decimal.