CSV Import

GT-I9070 H gti9070h at gmail.com
Thu Apr 27 02:21:16 EDT 2017


2017-04-26 16:48 GMT-04:00 Geert Janssens <geert.gnucash at kobaltwit.be>:

> On vrijdag 21 april 2017 00:28:08 CEST GT-I9070 H wrote:
> > * 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.
>
> Yes, experience has led me to conclude what you have confirmed here.


> > * 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 ?
>
> A big yes.
An additional split in a transaction that was not part of the csv file.
You understood my poor English well !


> > 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.
>
> No, I said *im*porter.
I thought I explained it in the old next paragraph, but I'll try to detail
it in the following new lines:
I exported transactions from GnuCash to a csv and then imported adding (On
the match transactions screen I selected "A") these transactions from this
csv and compared the transactions imported with their existing originals
(which were exported). They should be obligatorily the same.

But in some of these new imported transactions some values had decimal
changes and a new split with blank commenting appeared with values that I
figured would be to balance the transaction. I did not make calculations to
check the balance, there may be an imbalance.

I said I don't think this decimal changes was generated by the importer
because I know the behavior of GnuCash and I know it automatically adds
divisions with values to balance transactions.

As you mentioned the exporter, we will analyze it better.

Perhaps the fault is the exporter because it exports currency 1 value and
rate and compels us to calculate the currency 2 value where it would be
best to export currency 1 value and currency 2 value and the rate would be
calculated.

I fully agree with what you said in the following paragraph.


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

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


>
It can't be done after the import because the transactions with errors,
with fields not understood will be ignored and not imported. In order not
to lose the transaction, we will have to cancel the import, locate the
error in the csv edit it and try the import again.

I do not know how much work it would be, but it would be a very welcome
facility.
Who decides if it's worth it is you.

>
> > 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...
>
> Yes of course, this is the least I can do to contribute.
I'll find time to do it.


> Thanks again for testing and feedback!
>
> Geert
>

Thank you Geert  : )

I was testing/debugging/disassembling a virus that causes .exe and others
to no run and I reversed my VM and discarded the data from the first test,
but I would like to take the test to the end but in
gnucash-2.6.99-2017-04-18-git-b2b32e2+-setup.exe if just opening and saving
you destroy the data file.
When we tried to reopen it, we received the message "There was an error
parsing the file".

Thus, there is no way to finalize the importer's test.


Regards
GTI


More information about the gnucash-user mailing list