Importing of transactions

Derek Atkins warlord at MIT.EDU
Thu Dec 5 14:29:01 EST 2013


Males Tomlinson <malestomlinson at gmail.com> writes:

> 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?

History.  The QIF import code was the original importer, was written
completely in scheme and had a dedicated importer GUI.  When OFX was
added the developers wrote it in C (and C++) but at the same time
created a new, generic importer UI.  The plan at the time was to rewrite
the QIF importer in C and migrate to the generic importer UI, but that
work never happened.

So would it be better?  Yes.  Are you offering to do the work to
implement it?

> 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?

Philosophically, yes, you are doing it wrong.  IMHO you shouldn't import
your transactions from the bank, you should enter them by hand from your
receipts and then reconcile with your monthly bank statements.  If all
your data entry is via import then you lose the ability to notice a bank
error.

But to answer the question I think you are asking, no, you are not doing
it wrong.  You have to go through the importer target account selection.
The importer will learn over time, but on the first import it has no
idea where transactions are destined.  And how could it?

> 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?

Well, if you don't specify the target account in the importer it cannot
match transactions properly.  But yes, it is the way it works (so I
guess this is 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?

Sure!  Are you offering to implement it?!?

> 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?

Anything is possible; it's just a Simple Matter of Programming.  Are you
offering?

> 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.

Thanks!

> Best regards
> Males

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-user mailing list