CSV Import

GT-I9070 H gti9070h at gmail.com
Sun Apr 30 18:54:25 EDT 2017


2017-04-28 4:06 GMT-04:00 Geert Janssens <geert.gnucash at kobaltwit.be>:

> 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.
>
>  Ok, And it will not be 300K!

> > > 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.
>
>  This here is the same issue as the previous paragraph, so far, we need a
transaction to demonstrate the issue.

> > > 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.
>
> Yes, it would be better than nothing.
A little better than your suggestion would be a button to open and
search/locate the error in a pre-defined editor!

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.
>
> Yes, time and availability is lacking for some people.
This sounds ironic in a world with so many people unemployed, hungry,
refugees.
There is a big problem with capitalism, it does not work, but forget it,
that's not the issue here until someday someone steals or explodes our
servers.  : )
What we need is more people and not that you work harder!

> 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...
>
> Every monkey on your twig, that's how it works best. LOL.


> Regards,
>
> Geert
>


More information about the gnucash-user mailing list