[GNC-dev] Is the import match map still required?

[Chris Good]

Message: 5
Date: Sun, 24 May 2020 15:44:48 +1000
From: flywire <flywire0 at gmail.com>
To: gnucash-devel <gnucash-devel at gnucash.org>
Subject: [GNC-dev] Fwd:  Is the import match map still required?
Message-ID:
	<CAOthWL1JrqzJmuOxUjn2byniM_ujfWT7V8NQfS6yDycC8P_dcg at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

The most obvious match would be to match any Transfer Accounts in the data
to gnu Accounts, even if the result needs to be verified.

Other comments:
1) User's rapid clicks can unintentionally select the wrong account,
mapping invalid data
2) Seems there could be an opportunity for user to re-run a process to
recreate map and prune the useless matches David refers to ( dates,
connectors (a, and, the etc.), transaction amounts ?). With enough
transactions this should be pretty good.
3) I assume the table is updated with merged accounts,

...
4) Assuming match is case sensitive, should it be optionally turned off?


Hi flywire,

Re matching input file accounts to GnuCash accounts:
I guess this would only apply to QIF or CSV imports, but sounds like a good
idea.

1) & 2) You can always run the Import Map Editor to delete bad matches.
I've always thought it would be a good idea if there was a parameter for the
minimum token length the Bayesian matching would consider, so I could get it
to ignore silly data that in no way helps a correct match, like date
separator "/", "-", dd or mm or yy or yyyy.
It would also be useful but a fair but of work to have screen where you
could enter string tokens to be ignored, like "Receipt", "September" etc.

3) What does that mean "I assume the table is updated with merged accounts"?
If you mean when you delete an account, and elect to move all the
transactions to another account, I've got no idea but would be easy enough
to test. Not sure it would be worth the effort as it is easy enough to build
up mapping history again. The problem is to make the mapping history useful.

4) Possibly useful

Regards, Chris Good