CSV Import
Geert Janssens
geert.gnucash at kobaltwit.be
Wed Apr 26 16:35:17 EDT 2017
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