Importing of transactions

[Males Tomlinson]

Dear GnuCash developers

I have a few questions regarding the importing of transactions for which I
cannot get a clear-cut answer.

BACKGROUND
Version: GnuCash 2.5.9 (unstable). As far as I can see, this applies the
2.4.13 as well.
Accounts: Start with a new empty common accounts file.

I have downloaded my financial transactions from my bank in OFX, QIF and
CSV formats. I do not intend to manually enter transactions unless they are
cash payments. My bank does not support OFX direct connect and they do not
intend to implement that in the near future because of local legislation.
As a result, I will only be importing.

My questions follow after having tested the importing functionality for all
three formats.

QUESTIONS/SUGGESTIONS
1. There are substantial differences between the importing druids/wizzards
for each format. Especially with the matching of duplicate transactions and
the techniques used to do the matching. Why is that? Wouldn't it be better
to use one generic importing wizard (with different intermediate depending
on the format) for all the formats?

2. OFX importing: The normal account transaction registers have split
transactions and auto-completion which makes life a lot easier. However,
when importing an OFX file into my empty checking account for the first
time, the data isn't loaded into the account unless I specify the transfer
account for every item. Since no matching data exists yet, I will have to
specify each transaction manually. The problem is that in the import
wizard, I do not have those nice features such as auto-complete and split
transactions. I need to double-click each transaction and go through the
tedious task of using the pop-up window with the account tree (and still no
split accounts). I also cannot import if there are unspecified transfers so
that I can do that afterwards in the account register. So my question is,
am I doing it wrong or is it intended to be done in this fashion, it there
a bug that hinders me from importing without specifying all the transfer
accounts?

2. QIF importing: QIF importing works differently from OFX importing. Here,
the import wizard creates an unbalanced account and allows me to import the
data first and then specify the transfer accounts afterwards if I want to.
This is great for dealing with the lack of the auto-complete and split
account features, but, here lies the problem. When importing a 90 day
transaction history every month, there will be transactions for 60 days
that need to be matched to those already imported to avoid duplication. The
automatic matching process of the QIF importer is tedious because it
doesn't display the matched/duplicate accounts in one list. It shows the
imported transactions in the top list and shows the possible duplicates
only for the selected transaction in a list below. Furthermore, the matches
are not automatically selected, so it takes quite a while to work through
an imported transaction list if there are many duplicate entries. Am I
doing it wrong or is this the intended way?

3. (More of a suggestion-question) The two importing methods are clearly
two different philosophical approaches to how transactions should be
imported. In my humble opinion, the OFX import's way of displaying the
transactions makes more sense, but it lacks the auto-completion and split
transactions features to effectively assign transfer accounts. Wouldn't it
be better to suggest, for future releases, that a unified generic importer
is used that combines the best  aspects of all the importers and supports
all the formats?

4. The importers uses matching algorithms to look at how transactions have
been assigned in the past (data already in the account register). Is there
a way to apply this matching algorithm to also look at the newly assigned
transfers and apply that to the remainder of the unmatched entries of the
import as I go along? Or was there a specific reason for not doing it this
way?

As a hardware developer I know that a lack of knowledge of the design often
leads to unrealistic requests/suggestions by end users. That said, I would
like thanks to the contributors of gnucash, this is a good piece of
software.

Best regards
Males