CSV Import

[GT-I9070 H]

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

> On donderdag 27 april 2017 21:54:01 CEST GT-I9070 H wrote:
>
> > Even if you don't have it personally, it's entirely possible that the
> > assets used to pay certain expenses have been provided by more than one
> > bank, credit card or others asset/liability.
> >
> In double entry accounting you can look at a transaction from any account
> and
> consider the others as transfer accounts.
>
> This should be known by the most basic user of gnucash, I expected someone
to say this to give credibility to my words and I hoped it was you who
would say.

What I was waiting to say is that since a transaction involves two accounts
and the transaction can be viewed by either side, it does not make sense to
say "Import DIRECT to Asset or to Liabilities or to Income or to Expense."

If there's at least one (and possibly more) asset/liability account involved
> in a transaction you can model the import source file such that it looks
> as if
> you are importing into an asset/liability account. So this particular
> example
> is not a motivation to be able to import income/expense accounts.
>
> What I mean is, If you design an importer who filters out a certain asset
or liability or Income or Expense account, you are eliminating all
transactions that involving this account and your pair (which can be any
other account), you will be crippling the importer, you will be disabling
the importer.

The most common and the most number are those transactions that involving
an asset/liability account and an expense account, how are we going to
import into an asset/liability account this transactions if the importer
filters expense accounts? Impossible.

> An importer is made for everyone and not for particular cases.
>
> While I love to agree and surely do in theory unfortunately that's not
> always
> true in reality for various practical reasons.
>
>  I agree, what I should have written is:
 An importer SHOULD BE made for for everyone and not for particular cases.

> It makes no sense to work to limit the good capabilities of an importer or
> > app.
>
> There are: time required vs available to implement and maintain the code.
>
> To illustrate: in the bank/cc company scenario the provided data is usually
> pretty limited (date/num/description/amount) so much data needs to be
> guessed/
> deduced. The import/export between different accounting applications or
> even
> between different gnucash books can potentially provide much more detail
> making life easier on the importer. So we're discussing a very broad
> spectrum
> of use cases with greatly varying amounts of data to start from. I don't
> expect the importer to be able to handle every possibly conceivable csv
> file.
> In certain cases one will need to preprocess the csv file to be able to
> import
> successfully. One such example is gnucash will incorrectly import negative
> numbers with a trailing negative sign [1]. This is a restriction in code I
> haven't touched (yet). If time permits I eventually will.
>
> Regardless, as I have said before I don't think there are technical
> restrictions that should prevent the importer from being used to import
> income/expense data.
>
> I'm very relieved and pleased to know that!

What I forgot to ask in the other email is:
Do you prefer a Bug Report for each Issue/Improvement or a Bug Report for
everything?

Regards
GTI