[GNC] Import CSV Multi-currency

[GTI .H]

Em sáb, 24 de nov de 2018 às 19:47, David Cousens <davidcousens at bigpond.com>
escreveu:

> GTI,
>
> David Carlson's description is actually more correct in accounting terms
> and
> the way GnuCash actually works. This is a double entry accounting system
> which means that all transactions have at least two splits.
>
> In the case of a currency conversion transaction, the transfer of asset
> value is between the account in the initial currency and a separate account
> in the final currency, so there is at least a split for each account. (If
> there are currency conversion fees involved that are not incorporated in
> the
> price/currency conversion information for example you could have additional
> splits to account for this.)
>

heheheh!
Without an official definition of "split", it seems that each of us has
created its own definition!

According to your definition, there is no single line transaction in
GnuCash.

For me what you described was not a split but a balancing act.
For me, you can balance by creating splits or without creating splits.


> Each of the two (or more)  "splits" which constitutes the transaction only
> affects the account to which it refers. The data structures internal to
> GnuCash maintain a separate data structure for each component of the split
> which has a pointer to the transaction it belongs to and the transaction
> data structure maintain pointers to all the splits which constitute that
> transaction.
>

I know the data structure a bit, it is prepared to receive transactions
with splits, but not every transaction has splits (in my definition).


> For convenience and compactness, in the register display, this is normally
> (depending on optional choices in the preferences for the register display)
> compacted to a single line display which can be expanded to show the full
> structure of the transaction. That expanded structure is  more
> representative of the way a transaction is represented internally inside
> GnuCash.
>

Why do you think what you see (expanded to show the full structure of the
transaction) is the real structure of the transaction, splitted or
simple-line? Do you count the lines you see?
We can create for our registers as many  views/display formats as our
imagination allows without altering the real structure of the transaction
and this does not necessarily show the real structure of the transaction
only shows the data fields arranged in a standard view.

As you noted GnuCash's default export format is multiline but it can also
> export in single line format if you check the SImple Layout box in the
> first
> page of the wizard but this can cause a loss of information compared to the
> multiline format.
>

True! This had escaped me and it seems that Price is always lost on
single-line export.
It seems we have bugs here too.


> There is currently a problem with importing data with a currency exchange
> even with the multilline format, which I will be reporting as a separate
> bug. In essence for importing a currency exchange between an AUD and a USD
> account for $100AUD to $110 USD, the importer creates the trnsaction
> correctly in the AUD asset account and the USD asset account but it also
> creates an Imbalance account transaction for $1000, which it should not. To
> correct this requires deletion of the Imbalance account transaction which
> is
> incorrectly created on import,
>

Bugs, bugs, and more bugs.
Something similar occurs in my bug report of this thread, try reproduce it
to see.

The single line format data cannot be imported correctly at all at the
> moment as Geert indicated in his reply. The single line exported data has a
> separate column for the base account for the transaction and a separate
> column for the transfer account but in the importer as it is coded at the
> moment there is no facility to associate a transfer account to this column.
>

"Transfer account" is available only for single line import which only
works for one currency, in mult-split this is replaced by "Account Name".

Geert also indicated that the main developer effort is currently directed to
> other areas. I have had a little bit of experience with some parts of the
> importer code although not that associated with currency/commodities to
> data
> so far. I will try have a look at the code area to see if I can isolate at
> least the above problem with the multiline import which is in the
> import-matcher I have previously looked at and fix that. I may learn enogh
> to start looking at the single line import problems, but that will
> certainly
> take longer.
>

This will be really very good!
If it does not start it will never end.


--
Regards
GTI