CSV Import

[David Carlson]

I am a user that has mostly used the OFX import tool, but I am watching
this thread to see what will be coming soon.

I never considered using any import tool to import into either Income or
Expense accounts.  I thought they were only for Asset or Liability
accounts, with transfers to any type of account.  I personally cannot think
of any reason to import directly to an Income or Expense account.

Perhaps the import tools should only allow imports into Asset or Liability
accounts, period.


David C

On Wed, Apr 26, 2017 at 3:48 PM, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> 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
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>