CSV Import

[Geert Janssens]

On donderdag 27 april 2017 05:17:11 CEST David Carlson wrote:
> 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,

While I am not the original author of any of the importers I suspect they were 
all written with importing statements from bank or credit card companies as 
primary use case. Such statements will only hold information about one side of 
a transaction, namely the asset or liability account.

On the other hand due to the double entry principle gnucash allows you to look 
at a transaction from any angle. So I think it would be nice if the importers 
showed the same flexibility and can manage sources that describe transactions 
from other perspectives. I see no reason why this can't work other than 
perhaps the importer not handling the sign reversals properly and the column 
names not always being very helpful.

One such (theoretical) example would be importing from another accounting 
package that does double entry as well. I can imagine I'd want to import 
everything in such a case, not only transactions touching assets or 
liabilities.

Regards,

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