In the function Import Bills & Invoices, if a data row has too few separator characters, the data row should be rejected (as the row obviously has too few data fields). But GnuCash matches and imports the data row anyway, with values appearing in unintended data fields (e.g. putting post to account value in the date posted field). The problem is with the regular expressions in dialog-bi-import-gui.c. The default regular expression, and the regular expressions for comma and semi-colon separator (without quotes) include a '?' character after the separator character for a number of fields. That can't be right.
Created attachment 373111 [details] Import file to illustrate the bug Using a book with common and business accounts, dd/mm/yyyy date format, vendor 2001. The attached file has one too few separators. When the file is imported, in the preview of the import dialog, one can see that the row is matched anyway, and that in this case intended data fields have shifted (e.g. date posted is listed under the account_posted column.
You've changed the assignment on several bugs to yourself. That means that you intend to fix them yourself and submit patches or pull requests, but you haven't submitted any, nor have you introduced yourself on gnucash-devel. Please do introduce yourself and I suggest that you make the PRs for the bugs you've already taken before taking any more.
My initial intention was to document the process; so I read the code, found a number of issues, and registered them (two of them were picked up and fixed). At a certain stage I decided to try an fix the other issues myself, so I assigned them to myself. At this stage, I have already fixed all issues that I assigned to myself. I have not yet submitted a patch, because I am still working on correcting/updating the doxygen documentation and user documentation for import bills & invoices. And now investigating import customers & vendors. I'd like to submit patches for code and help documentation when I have covered both functions of this module, so that all can be updated in one go. (In fact, I did submit a patch for 796991, but maybe I missed something in the procedure for submitting.) In fact, I did introduce myself to gnu-cash-devel, but as a documenter, not as developer. I'll send the same again, with some additional explanation.
Very good, then, and thanks for the re-introduction on gnucash-devel. Thanks also for reminding me about the patch on bug 796991. Since migrating to our own Bugzilla instance we've lost a lot of the nice Gnome customizations and there's now no good way to keep track of open patches. Consider using Github pull requests instead of uploading patch files on BZ. It does require that you set up a Github account, but once that's done it's easier for everyone and much easier for patches to not fall through the cracks. Just do a separate commit for each bug; you can bundle several into a single PR if it suits you. Do use feature branches for PRs so that you can have more than one open at once.
Are there optional fields in when importing invoices or bills ? In that case it does make sense to make separators (with their field) optional.
Yes, there are optional fields. But making individual fields optional in the data import (as opposed to leaving the blank) does not make sense, because the matching pattern would never be able to figure out which of the fields the user did not provide. You could make a complete sequence of fields optional in the match pattern, but that is not the case here (and just asking the user to provide all fields, and leave optional fields blank, is easier to work with on all sides). Moreover, some of the fields with an optional separator in these matching patterns are required, like account, price, quantity. And the matching patterns for "with quotes" have the expected number separators, none of them optional.
Ok. Those are reasonable arguments.
Pull request #457 merged into maint, https://github.com/Gnucash/gnucash/pull/457.
