[GNC] Import CSV Multi-currency

GTI .H gti9070h at gmail.com
Sun Nov 25 17:12:16 EST 2018


I like a good debate and you are a good partner.

I consider your information more relevant. you're an accountant, maybe I'm
a physicist, I do not feel the need to show credentials.

It is clear, you and John confirmed my suspicions, David Cousens's
references are from the docs of GnuCash, mine are from the natural reality.

We continue without a clear definition of "split".
But, although I do not agree, yes, truth, it is written in the docs
apparently written by accountants and not by engineers physicists: "Every
transaction in GnuCash has at least two splits."

It is clear in the docs that the use of "split" is more for the Visual
Database Structure approach than for my logical mathematical approach.
*For me this could be a bug in the docs.*
May God deliver us from bugs!

In double-entry accounting/balancing there are accounts concepts,
mathematics concepts and not "splits" concepts.

"Split" is a creation of Gnucash and not of transactions logical reality or
real transactions estructure or of Accounting or World Practices or
mathematics.
That's one of the things that all along seemed to me that you are
mixing and as John confirmed, they're just together in GnuCash, the reality
logic and math are universal, what Gnucash tries to be.

"GnuCash Split" has nothing to do with Accounting, doubly-entry, World
Practice or with math.
"GnuCash Split" or "Virtual Split" is similar to the free SW of some, it is
free but in reality it is not, in reality someone has to pay, "Virtual
Split" also sometimes is not a real split.

It is a good opportunity to change in the GnuCash docs this DB-based
concept from the programming point of view and take on the concept of the
practical mathematical accounting goal of the *notorious* "*split*".

In the real world a transaction has no lines, lines are created when
registered. The natural way to write a transaction is on a line until the
line ends or becomes non-visible.

We are talking about import (Real world for the virtual world), the
interface between two universes, the real one and the one that intends to
reproduce reality. I agree that displaying milti lines is best because it
concentrates infomations on the visual portion of the screen, but
lines/splits have nothing to do with real-world transaction structure.

How long has IT taken to assume that Kilo is 1000 and not 1024?

Let's be more agile than that.
Let the experience at least make us conceptually more real . . .


Em dom, 25 de nov de 2018 às 01:47, David Cousens <davidcousens at bigpond.com>
escreveu:

> On Sun, 2018-11-25 at 00:14 -0300, GTI .H wrote:
> > 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!
>
> There is an official definition of what a split is. See
> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html
> and the following section
>
> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-registers-txntypes.html
> and also
> https://www.gnucash.org/docs/v3/C/gnucash-guide/basics-accounting1.html.
> I am not creating my understanding of splits in
> transactions out of thin air. I have a Masters degree in accounting and my
> description is in accordance with accounting
> practice world wide as well as the implementation within GnuCash.
>
> >
> > 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.
>
> You may need to look far more deeply at the underlying principles behind
> double entry accounting which is implemented in
> GnuCash if you think this is the case.
> >
> >
> > > 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).
>
> Every transaction has splits and affects at least two accounts at least
> internally within GnuCash. Data to be imported
> depending on the source may or may not have information about the second
> split however. In the case of a transaction
> involving a currency converion that data either has to contain information
> about the second split or at least sufficient
> information to reconstruct it. I am in the process of preparing a more
> detailed analysis of what is exported from a
> currency conversion transaction and whether it can be reimported
> successfully. This will take some time, but I will post
> the results in this thread when complete.
>
> Results so far indicate a transaction exported from an account in the main
> currency your books are kept in in single
> line format does not contain enough information to recreate the original
> transaction. If the transaction is exported
> from the account in the second currency to or from which conversion took
> place, the single line record does contain
> sufficient data to reproduce the transactions, however there may be
> rounding errors depending on how the conversion
> ratio/price was stored.
> >
> >
> > > 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.
>
> True only relevant information from the complete data structure is
> displayed in the register. However internally within
> GnuCash there is no such thing as a single line transaction.
> >
> > 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.
>
> When you export in single line format from an account in the main currency
> your books are kept in there is no currency
> conversion information in the record. It is however in a record exported
> from the "foreign currency" account that the
> transaction was targeting with its second split. In principle this could
> be imported to recreate the record. I am still
> checking out whether it can in fact be imported successfully
> >
> >
> > > 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 CSV importer was originally written primarily for importing data from
> sources such as banks from a single account
> and probably did not envisage dealing with multicurrency transactions. The
> export capability is a comparatively recent
> development and the whole importer is really still a work in progress as
> Geert pointed out. I have an interest in this
> problem as I import Paypal account data with CSV and if I have purchases
> in a foreign currency Paypal insist on
> including the currency conversion details. I currently pre-edit the file
> to delete this but it would be more convenient
> to be able to setup a proper import of the conversion detail so i retain
> it.
> >
> > 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
>
> Cheers
>
> David Cousens
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
>

-- 
Regards
GTI


More information about the gnucash-user mailing list