You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hledger's CSV conversion rules look at each record in isolation, with no memory (except what you have encoded in the static rules).
...
I agree this (inferring accounts, perhaps other characteristics, from similar-looking existing journal entries) is an interesting idea and could potentially work well, though it would also make conversion less predictable. Here is Ledger's https://ledger-cli.org/doc/ledger3.html#The-convert-command , which I assume you're referring to ?
I can imagine feeling that you must write a rule for every description/payee is a bit unpleasant. I have never done that myself, it has been a more incremental process of adding a few rules each time, according to the latest transactions and my motivation for detailed categories, clean descriptions, etc.
If someone is bulk converting a huge backlog of CSV, with high goals for categorising and cleaning, I can see it's a bigger job. Though in such cases, past journal entries might be nonexistent, or too different to help much. hledger's if table rules, possibly programmatically generated, might be some help.
Apparently Ledger does this and it's useful, so we should try it. I guess ideally it means you just write minimal CSV rules, then manually fix the uncategorised transactions each time you import, pretty soon you don't have to do that much any more, you're always doing that one thing and not switching context to edit rules, and the results are good and sufficiently reliable, at least for straightforward categorising cases.
Details to be clarified:
What to infer and how. The most useful thing would be to at least identify a good other account for simple two-posting transactions, by looking for recent journal transactions with similar description or payee. add does this (and also works for >2 postings).
Interaction with rules. Apply rules first, and when an account is left uncategorised, try to infer it from the journal transactions ? Assigning a special value to an account field activates it ?
The text was updated successfully, but these errors were encountered:
simonmichael
added
A-WISH
Some kind of improvement request, hare-brained proposal, or plea.
csv
The csv file format, csv output format, or generally CSV-related.
labels
Feb 15, 2024
As discussed at https://www.reddit.com/r/plaintextaccounting/comments/1arkzfg/can_hledger_import_use_account_mappings_from/ :
Apparently Ledger does this and it's useful, so we should try it. I guess ideally it means you just write minimal CSV rules, then manually fix the uncategorised transactions each time you import, pretty soon you don't have to do that much any more, you're always doing that one thing and not switching context to edit rules, and the results are good and sufficiently reliable, at least for straightforward categorising cases.
Details to be clarified:
What to infer and how. The most useful thing would be to at least identify a good other account for simple two-posting transactions, by looking for recent journal transactions with similar description or payee.
add
does this (and also works for >2 postings).Interaction with rules. Apply rules first, and when an account is left uncategorised, try to infer it from the journal transactions ? Assigning a special value to an account field activates it ?
The text was updated successfully, but these errors were encountered: