CSV Import

Steve Isenberg brrg58 at yahoo.com
Fri Apr 28 10:10:48 EDT 2017


Geert,thanks for the detailed answers to my questions. 

Afterwriting the email I experimented with the import and changed it to import intothe asset account and it worked. Through trial and error, I discovered how theimport works.

Isee there was some discussion regarding importing into an asset account. So,let me answer the question. Why would I try to import into an income accountand transfer to an asset account?

Ignoringconcepts about where income originates, here is the important point about howthe software works.

Ican manually enter transactions into the income account with a transfer to theasset account. Given that, it is not unreasonable for a new user to expect theimport function to follow the same rules as manually entering transactions.

Whatmight make the import a bit more useful is to allow for a transfer account tooccur in the import row. A user could still review on the screen and it mighteliminate the need for touching each import record. 
I mentioned previously about helping with some testing. I can put it on an olddesktop. Is there a windows development version ready for testing?
Also,are they test cases written or is it informal testing?

 

Thanksagain


On Wednesday, April 26, 2017, 4:35:22 PM EDT, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:Hi Steve,

On dinsdag 25 april 2017 21:52:00 CEST Steve Isenberg wrote:
> I'm finally at a point where I can test the import again before the next
> month of transactions arrive. Following your suggestion below I was in fact
> missing the step to click on the header row to indicate the column. Dang it
> on me.
> 
> Now, however, there are new issues!
> 
> I'm trying to import into an income account with an offsetting entry into an
> asset account. Twice I told it the amount column is a deposit and both
> times it reduced the income * and * the asset account.
> 
> Both times it did that and both times I ended up manually deleting the test
> import transactions. I tried a third time and now it wants to transfer the
> entire balance to the asset account. None of this makes any sense!
> 
This is hard to interpret without some example data unfortunately.

> Also, on the match transactions screen it shows three columns: A, U+R, R.
> What are they?

A = add (suggesting a new transaction will be added for this line)
U+R = update + reconcile (in case the current line is an update for an already 
existing transaction, which will also reconcile it)
R = reconcile (I presume for when an exact match is found for the current 
line)

> How do I know whether to check them or not?

The importer will make educated guesses if it finds transactions similar to 
the lines to import. Only you can know for sure whether these guesses are 
correct and may need to adjust what the importer thought to have found.

> CSV import should be straight-forward and easy. I've never seen an import
> that is so fickle, unreliable and lacking of information in how to use it.
> 
Unfortunately it's not that straight-forward. It has to be more complicated 
than a csv importer in say a generic spreadsheet because the imported data has 
to be mapped to very specific data structure. As there is very little 
information available to do this mapping, it requires human guidance at 
several points. This will remain so in the future implementation (for gnucash 
2.8) to some extent. The user will be able to import more detailed csv files 
making the mapping step more complete. But at the same time it still has to be 
able to cope with the absolute minimal csv file as well. Which will still 
require the user to fill in the gaps. 

> What exactly is the use-case for this?
The original use case for the csv importer is importing a bank statement in 
csv format. Traditionally this only has very limited information (from the 
gnucash point of view, that is): a date, a transaction number, a description 
and an amount. All the rest has to be added by the importer to come to proper 
(two-split) gnucash transactions. For this simple use case the primary missing 
elements are the two accounts involved in this simple transaction. As a bank 
statement is usually (but not even always) for one bank account at the time, 
the originating account should only be entered once. The transfer account can 
be different for each (bank) transaction. Gnucash tries to learn which 
transfer accounts you usually have based on the description. The effectiveness 
of this learning heavily depends on the quality of the descriptions your bank 
provides.

Imports get much more difficult when multiple currencies are involved (not 
supported at all in 2.6, limited support in 2.8), when the transaction is 
multisplit (for example our Belgian banks withdraw a service charge from time 
to time, but this is really split up in the real charge and a VAT part. These 
parts should go to separate accounts. Again, not supported at all in 2.6, 
limited support in 2.8)...

> What is the procedure to import into an income account with offsetting entry
> into an asset account?

I have never tried to import directly in the income account. Instead I have 
only seen imports into an asset account. So it's very well possible your use 
case has bugs.
> 
> Also, if you click the back button and then the forward button again. It
> errors and cannot proceed. Thank youSteve
> 
I think that was due to poor design in the 2.6 importer. The 2.8 one should be 
more resilient to such actions.

Regards,

Geert


More information about the gnucash-user mailing list