Not sure that the developers could make that suggestion work. It is much harder to find records which have been imported to the wrong account after the fact than it is to identify the correct account the first time it is imported at the time it is imported.
The account names as specified in a CSV file import are only labels unless the CSV record contains the GUUID that has been assigned and is associated with an internal account name in the GNuCash program. Account Names internally are only labels and the GUUID is used in all transaction processing internally. These GUUIDs are only available with an association to a specific internal GnuCash account where the records have been exported specifically from a GNuCash book/file using the GNUCash CSV export format which includes the internal GUUID of any accounts in the record as well as the account name labels . For CSV records originating elsewhere, GnuCash has no way of knowing which internal account is specifically matched to a given label in an import record until you create that association by making and confirming a selection. Once you have successfully imported a record which contains a specific label, that label is then mapped onto the GUUID associated with the account you selected to match the label to from that point on. The importer has to be able to cope with the situation where the name your bank may choose to give an account or category in their records may not be the name you may choose to give it internally. Miss one space in the label or change or add one character and the label is also a separate distinct entity. That is why it is necessary to confirm and select the specific internal account the first time a label is encountered in an import record. The problem is that the importer not only has to cope with your specific use case but with all possible use cases in some 189 countries world wide. What might be possible is to preselect the internal account whose account name most closely matches the imported label in the drop down list of internal account names in the selection dialog but that final confirmation step would still be necessary. I suspect when it was written, since it is a once only operation, whoever wrote it opted to have the user manually select the internal account matching he wants associated with a specific imported label, likely well before the Bayesian matching procedure was put in for matching the transfer accounts. While it may be possible to adapt the Bayesian matching process to do this, it is by no means a 5 minute exercise and , so far no-one on the main development team has considered it a high enough priority to address. If it has not been enetered as a feature request bug in the bugs data base, it is also unlikely to be addressed unless someone takes an interest in it. That requires that someone to have an understanding of the code not only in the specific area but as some parts of the code are used in many different areas, an overall understanding of the code base. Ive never counted how many million lines of code are in GnuCash. It also does not stop the operation of Gnucash and issues which do affect that are usually the highest priority. It is a relatively minor user inconvenience. Until and unless someone in the volunteer force of developers is prepared to consider addressing the problem it is unlikely to change. Even with OFXQFX imports where the banks usually specify a GUUID for each account and each transaction, those externally assigned GUUIDs have to be mapped onto the GUUIDs created and associated with an account name internally the first time a transaction with an external GUUID is imported. Your bank could change a GUUID associated with an account at any time of its choosing. Once that mapping is done however importing is extremely reliable with OFX/QFX because there is a defined standard institutions have to agree to - some still manage to stuff it up though. With CSV there is no such defined standard and every developer in every institution can choose to do their own thing so the situation is chaotic and importers have to cope with a wide range of different and sometimes aberrant behaviour on the part of the file creators. ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
