CSV Import

[Geert Janssens]

On donderdag 27 april 2017 08:21:16 CEST GT-I9070 H wrote:
> 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:
> > > * 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 !

If you write a bug report for this, it would be very helpful if you could add 
a sample csv file that causes this. But please don't make it a 300K sample 
file. It should only have the lines needed to reproduce the problem.

> > > 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.
> 
Ok, I can follow you now when you said "not generated by the importer". You 
may be right, although the generic part of the importer (which I haven't 
touched) is also altering transactions before they really go into gnucash. It 
will need more investigation which part exactly does this.

Also here, please add a small sample csv file to the bug report.

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

Value importing will definitely help in avoiding rounding errors in multi-
currency transactions.

> > > 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.
> 
A fair point.

> I do not know how much work it would be, but it would be a very welcome
> facility.

I had considered this at some point while working on the c++ conversion. At 
that point it definitely was more work that I had available time.

Perhaps some middle ground can be found. For example by adding a "Reload csv 
file" button to the preview page the user could have both the importer open in 
gnucash and the csv file in a text editor. After editing the csv file, only 
the reload button need to be pushed to refresh the preview with the updated 
csv data instead of completely restarting the import.

While less work, it's still on my "a nice to have for someday" list in terms 
of priorities. For now there are more pressing matters to attend to.

> 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".
> 
That clearly needs debugging as well...

Regards,

Geert