CSV Import

[Geert Janssens]

Hi GTI,

Thank you for your first testing results.

On vrijdag 21 april 2017 00:28:08 CEST GT-I9070 H wrote:
> I made an import of a 304KB csv file exported by GnuCash and these are my
> first remarks:
> 
That's a pretty huge import. We usually suggest to do smaller import runs, 
though that's mostly to allow the importer to train its bayesian transaction 
matcher.

> * Sometimes the importer/GnuCash either froze or was long parsing (eg. When
> to change the header), in doubt I killed the process and started again. A
> progress bar would be welcome!
> 
A fair point.

> * In the csv reconciled column I have the letters "n", "a" and "p" and only
> "n" was understood, I had to ignore this column in order not to lose
> transactions.
> 
Hmm, it looks like the importer and exporter aren't using the same 
translations for the reconcile letters. Needs fixing.

> * There are doubts about whether to select the "account" column header for
> csv's  "Account Name" or "Account Full Name".
> 
For importing in gnucash you most likely want "Account Full Name". The other 
one is in the import data as an extra column to be used as you like outside of 
gnucash. In some situations this would be more elegant than the full account 
name.

> * After import, some values had decimal changes and a new line with the
> blank comment came up, possibly to balance the transaction.
What do you mean with "a new line with the blank comment" ? An additional 
split in a transaction that was not part of the csv file ?

> I do not think this was generated by the importer.
Do you mean "generate by the *ex*porter" ? If not, please explain in more 
detail.

> When we register a multi-currency transaction with a single rate and with
> splits, GnuCash record rates with small differences for each split and when
> we export a csv these different rates are exported and reflect in the
> values (not in the default currency) when imported.
A good point! I believe this is a design mistake in the export/import 
functionality of gnucash. Internally it stores amount/value and exchange rate 
is calculated. However it exports amount/exchange rate, which upon importing 
is converted back to amount/value. That's two calculations adding potentially 
two rounding errors. I believe we should consider exporting value as well. I 
don't know how easy this will be, but it's worth investigating.

> 
> Suggestion:
> It would be nice if we could edit the csv on the importer to make minor
> corrections!

You can do that after importing. Adding such editing capabilities to the 
importer seems a lot of effort for little added benefit.
> 
> From my point of view, the importer sometimes showed to be cumbersome
> (possibly parsing), but it works well!

Can I ask you to write bug reports for each of the above issues/improvements ? 
The mailing lists has proven to be a poor bug tracker...

Thanks again for testing and feedback!

Geert