CSV Importer

[Benjamin Sperisen]

Hi everyone,

Sorry for the long silence from my end! I just committed the work I've
done over August in a big chunk. I should have committed it in smaller
increments, but the main reason I refrained was that for much of the
time it was in a not-so-functional state. :-( I guess this is a lesson
in "release (or commit) early and often."

Anyway, most of what I've done has been to address the shortcomings
discussed earlier.

First, I've reworked the internal error handling code so that, if
there are errors, a new column to the right is created listing the
errors on each particular row. For example, if a row has "abc" in its
"Deposit" column, it will put "Deposit column could not be understood"
in the "Errors" column for that row.

Second, fixed-width files are now supported. The interface is actually
virtually identical to Gnumeric's, as I merged their code into mine,
particularly for the context menu for column merging.

Third (and this took much more time than expected), I've implemented a
real "Balance" column. I ended up having to rework a lot of my code a
few times before I got this right, mainly because of edge cases I
failed to consider at first. The idea is that if we get a file that
has the following values in the Balance column:

$10
$20
$40
$5

we will get transactions with amounts +$10, +$10, +$20, and -$35 -- if
we're importing into an empty account (which is probably the most
likely use case). However, if there are already transactions in the
account, the importer uses that to change the amounts appropriately
such that the balances are always correct. For example, if there was a
deposit of $20 already in the account that took place between the
dates for the first and second transactions in the file, the second
transaction's amount will be changed to -$20 (because the balance
would be $40 at that point).

If there is a deposit or withdrawal column, I will always use that in
preference to the balance column, since this is a much more unreliable
way to calculate transaction amounts (as it depends entirely on the
values for other transactions, both in the file and not). Never the
less, it should work as expected for most people (importing into empty
accounts).

I've also added support for (ignoring) currency symbols in strings,
month-day and month-day (i.e. (no year) dates, and the transaction
number field. I put "ignoring" in parentheses because I'm not sure if
I should be checking to see if the symbols match the commodity in the
account (or if we should even be doing currency conversions), but
under normal circumstances this should work. There has also been a
significant amount restructuring of the code to ease the building of
the features above (and future features as well).

During the fall, I would like to keep working on the importer, even
though I won't be able to work quite as much because of school. The
next feature I'd like to implement is actual editing within the dialog
of data (so that users don't have to go back and manually edit it in a
spreadsheet, save and reimport).

I would also like to thank you, Josh and Christian, as well as the
rest of the GnuCash community, for all of your help and guidance over
the summer! This was definitely a great learning experience in many
practical aspects of open source and software development in general.
I have really enjoyed working with all of you and hope to continue in
the future.

Kind regards,
Benny