Re: [GNC] Import CSV Multi-currency

[Geert Janssens]

Op maandag 13 mei 2019 16:32:46 CEST schreef Derek Atkins:
> Hi,
> 
> boldstripe  writes:
> > Just checking: am I correct in expecting Gnucash 3.5 to have the same
> > problem with multiple-currency CSV data as Gnucash 3.4?
> > 
> > The origina bug report is here:
> > https://bugs.gnucash.org/show_bug.cgi?id=796955
> 
> This bug is still open, so I would not expect the status to have changed
> in the code.
> 
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> 
> -derek

Nothing has changed yet. 

Regards,

Geert


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[Derek Atkins]

Hi,

boldstripe  writes:

> Just checking: am I correct in expecting Gnucash 3.5 to have the same problem
> with multiple-currency CSV data as Gnucash 3.4?
>
> The origina bug report is here:
> https://bugs.gnucash.org/show_bug.cgi?id=796955

This bug is still open, so I would not expect the status to have changed
in the code.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[boldstripe]

Just checking: am I correct in expecting Gnucash 3.5 to have the same problem
with multiple-currency CSV data as Gnucash 3.4?

The origina bug report is here:
https://bugs.gnucash.org/show_bug.cgi?id=796955



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Em seg, 26 de nov de 2018 às 07:44, John Ralls <
jra...@ceridwen.fremont.ca.us> escreveu:

>
>
> On Nov 26, 2018, at 11:26 AM, GTI .H  wrote:
>
> Em dom, 25 de nov de 2018 às 21:26, John Ralls <
> jra...@ceridwen.fremont.ca.us> escreveu:
>
>> Meh. The word “split” may not be in your accounting textbook, but the
>> concept of it is. Every transaction requires an entry in each of at least
>> two account ledgers (hence “double entry”). GnuCash calls those entries
>> “splits”. You can argue about the name if you want, but the concept is the
>> foundation of formal accounting.
>>
>> Regards,
>> John Ralls
>>
>
> I see you're attentive and will not let me talk bullshit!
>
> Out of GnuCash, in double-entry accounting in a transaction of two
> accounts, if you look at one side you will see for example 10 and if you
> look at the other side you will see 10, there is nothing splitted but
> rather balanced.
>
> GnuCash has appropriated, modified and expanded the concept of the
> *split *word, so within GnuCash it has been "split" that may have the
> same concept of left side and right side, top line, bottom line, and also
> the same concept that accounts, yes, now belongs to accounting.
>
> When the concept of "split" is left side and right side, top line, bottom
> line I'm right, when the concept is accounts, you're right.
>
>
> ;-)
>
> English overloads words a lot, and we often come up with new overloads.
> That sometimes makes it tough for non-native speakers. 75 years ago a
> "computer” was a person who was skilled at doing arithmetic in (usually)
> her head. Now it’s a square centimeter of dirty silicon.
>
> Regards,
> John Ralls
>

I do not see "split" as most people do, nor do I see time like most
scientists.

I have my own theory to explain the time, truth.
If it simplifies the understanding of the universe and if it is elegant,
then it is probably right.

Sometimes I debug my texts and find some inverted logic, this does not
worry me much because:
It's not easy to corner a black hat!
{|;-)


-- 
Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[John Ralls]

> On Nov 26, 2018, at 11:26 AM, GTI .H  wrote:
> 
> Em dom, 25 de nov de 2018 às 21:26, John Ralls  > escreveu:
> Meh. The word “split” may not be in your accounting textbook, but the concept 
> of it is. Every transaction requires an entry in each of at least two account 
> ledgers (hence “double entry”). GnuCash calls those entries “splits”. You can 
> argue about the name if you want, but the concept is the foundation of formal 
> accounting.
> 
> Regards,
> John Ralls
> 
> I see you're attentive and will not let me talk bullshit!
> 
> Out of GnuCash, in double-entry accounting in a transaction of two accounts, 
> if you look at one side you will see for example 10 and if you look at the 
> other side you will see 10, there is nothing splitted but rather balanced.
> 
> GnuCash has appropriated, modified and expanded the concept of the split 
> word, so within GnuCash it has been "split" that may have the same concept of 
> left side and right side, top line, bottom line, and also the same concept 
> that accounts, yes, now belongs to accounting.
> 
> When the concept of "split" is left side and right side, top line, bottom 
> line I'm right, when the concept is accounts, you're right.

;-)

English overloads words a lot, and we often come up with new overloads. That 
sometimes makes it tough for non-native speakers. 75 years ago a "computer” was 
a person who was skilled at doing arithmetic in (usually) her head. Now it’s a 
square centimeter of dirty silicon.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Em dom, 25 de nov de 2018 às 21:26, John Ralls <
jra...@ceridwen.fremont.ca.us> escreveu:

> Meh. The word “split” may not be in your accounting textbook, but the
> concept of it is. Every transaction requires an entry in each of at least
> two account ledgers (hence “double entry”). GnuCash calls those entries
> “splits”. You can argue about the name if you want, but the concept is the
> foundation of formal accounting.
>
> Regards,
> John Ralls
>

I see you're attentive and will not let me talk bullshit!

Out of GnuCash, in double-entry accounting in a transaction of two
accounts, if you look at one side you will see for example 10 and if you
look at the other side you will see 10, there is nothing splitted but
rather balanced.

GnuCash has appropriated, modified and expanded the concept of the
*split *word,
so within GnuCash it has been "split" that may have the same concept of
left side and right side, top line, bottom line, and also the same concept
that accounts, yes, now belongs to accounting.

When the concept of "split" is left side and right side, top line, bottom
line I'm right, when the concept is accounts, you're right.


--
Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[John Ralls]

Meh. The word “split” may not be in your accounting textbook, but the concept 
of it is. Every transaction requires an entry in each of at least two account 
ledgers (hence “double entry”). GnuCash calls those entries “splits”. You can 
argue about the name if you want, but the concept is the foundation of formal 
accounting.

Regards,
John Ralls

> On Nov 26, 2018, at 7:12 AM, GTI .H  wrote:
> 
> 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  >
> 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 <
>> davidcous...@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 

Re: [GNC] Import CSV Multi-currency

[David Cousens]

I have a foot in both the physicist and accounting camps having spent most
of my working life as a professional physicist and then doing accountancy
after an enforced early retirement as a result of government cutbacks in
science/education.

The clearest definition of split is really in the data structures in the
code. A lot of people have struggled with describing what a split is in the
documentation. The docs are also largely written by a team of users many of
whom are business owners or just manage their personal finances. There are a
few of us with a more formal background who also contribute at times. It is
hard to balance a more formal description that requires you to have done an
accountancy course before you can read it and something that makes sense to
someone without that background.

I agree that "Split" is a GnuCash specific term. I struggled with use of it
initially as it did not correspond with what I was familiar with in my
accounting text books which did not assign any name to the various
components of a transaction. I personally would have preferred something
like transaction component. 

To say however that it is unrelated to accountancy is however unwarranted.
In accountancy to satisfy the accounting equation, any transaction must
involve debits and credits to two or more accounts where the total sum of
the debits and credits for a transaction is zero. GnuCash uses the term
"split" to describe those individual components of a transaction. This is
outlined in the Tutorial and Concepts Guide. As a name for the internal data
structre "TransactionComponent" is probably a bit long winded back in the
days when auto completeion was not very common in IDE's so the developers
named it internally as a Split. It is also used within the documentation to
refer to the representations of the information contained in the Split data
structures within the registers as individual lines, which is most likely a
carry over from early discussions between users and the developers. 

A formal minimal definition of a split would likely consist of an account to
be debited or credited, an amount of the debit or credit and whether that
amount is being debited or credited to the account. GnuCash and its
documentation is not however an accountancy or mathematical textbook, it is
a compromise which has to span the knowledge domains of the developers,
accountants and users. 

If you feel the documentation is unclear and you feel you are able to make
it clearer by all means join the documentation team but you will find an
strongly embedded accpetance of split by the team and the user community - a
lot of inertia to overcome. Other programs equally use arcane terms, for
example, Quicken's use of "Categories" to describe expense accounts is one
that offends my own sensibilities

GnuCash is not an abstract mathematical construct. Neither is accountancy.
Accountancy is a system for rtecording transactional events in a world of
commerce. It has a few embedded, fairly simple, mathematical concepts, but
if you were able to describe it in formal mathematical terms it would more
than likely be totally unintelligible to the majority of practising
accountants and those who need to use it. Luca Pacciola who first recorded
the procedures in a mathematical text was a mathematician (Leonardo da
Vinci's mathematics tutor) as well as being the son of a Venetian trader
engaged in commerce with Arabian North Africa and learned the principles of
accounting he espoused from those traders.

Some things are simnply a matter of context, As a computer programmer when
dealing with binary digital information my brain has no problem recognising
k or kilo as 1024. When the context is not binary digital and I am a
physicist using SI units, then it is 1000. True this is a problem for those
who don't understand the difference between binary digital representations
and decimal representations of numbers and do not have the context within
which to evaluate it and also use an abbreviation without making absolutely
clear its context. A binary Roman would no doubt have severly punished a
decimal Arab who shortchanged him by 24 pieces of silver when the agreed
price was 1 kilo of silver pieces. Or was he expecting kilograms perhaps??

If you go back far enough in the GnuCash forum archives, you will find many
discussions about splits, what they are and mean and what they are not, some
informed, some uninformed. One could debate what a split is ad infinitum and
an appropriate use of terminology, but I really need to spend time
investigating how the importer actually works and where it doesn't do what
we would like it to do. The latter is subject to extreme scope creep at
times.

Cheers
David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:

Re: [GNC] Import CSV Multi-currency

[Geert Janssens]

Op zondag 25 november 2018 23:04:45 CET schreef David Cousens:
> Hi Geert,On Sun, 2018-11-25 at 15:47 +0100, Geert Janssens wrote:
> > Op zaterdag 24 november 2018 23:47:33 CET schreef David Cousens:
> > > 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.
> > 
> > This is inaccurate. You definitely can associate a transfer account to the
> > column in single line import mode. There is "Account" and "Transfer
> > Account" for a reason. And it works well in a single currency
> > environment. It breaks down in a multi currency one.
> 
> Agreed that it works generally but ther are some specific limitations
> someone importing transactions will need to be aware of. I have started
> testing the importer as systematically as I can for a multicurrency import,
> specifically a multicurrency transaction AUD to USD for a withdrawal/credit
> to an AUD savings account of $100 AUD deposited/debited to a USD savings
> account with an exchange rate entered as 10/11 in the currency dialog. I
> have created single line exports in the GnuCash Export Format for the
> transaction from both the AUD Savings account and the USD Savings account.
> 
> The exported transaction in SL mode from the AUD account contains no
> information that it involves another currency other than that the Full
> Category Path points to the USD account.
> 
> If I select the import format as GnuCash Export Settings, set the date
> format and most of the columns to the values suggested by the headers, I
> cannot set the Full Category Path column in the exported data to Transfer
> Account as it does not appear in the drop down list. I would have expected
> that GnuCash on import would have been able to set the Transfer Account
> with the export settings.
> 
Ah, now I'm with you. You are correct in so far that the import preset 
"GnuCash Export Settings" will always assume the export happens in multi line 
mode as that's the only way we can manage a complete export/re-import cycle 
without data loss. The single line export facility can't preserve all 
information in case of multi-split transactions (in the more common use of 
more than 2 splits). I realize we never made that part clear anywhere.

And as I mentioned, in multi line mode a "Transfer account" makes no sense.

> If however I use No Settings, set the date format and assign the columns as
> their headings suggest, the Transfer Account does come up and I can set the
> import data Full Category Path as Transfer Account however the price data
> is 1.00 and when imported it shows the transaction value as $100, which is
> reasonable as there is no currency conversion information in the exported
> record, however the import is not triggering the currency conversion
> dialog.
> 
Right. Multi currency does need more work. Please continue with your detailed 
analysis. I think that will help a lot in framing the problem space.

Geert


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

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 
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 <
> davidcous...@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 

Re: [GNC] Import CSV Multi-currency

[David Cousens]

Hi Geert,On Sun, 2018-11-25 at 15:47 +0100, Geert Janssens wrote:
> Op zaterdag 24 november 2018 23:47:33 CET schreef David Cousens:
> > 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.
> > 
> 
> This is inaccurate. You definitely can associate a transfer account to the 
> column in single line import mode. There is "Account" and "Transfer Account" 
> for a reason. And it works well in a single currency environment. It breaks 
> down in a multi currency one.
Agreed that it works generally but ther are some specific limitations someone 
importing transactions
will need to be aware of. I have started testing the importer as systematically
as I can for a multicurrency import, specifically a multicurrency transaction 
AUD to USD for
a withdrawal/credit to an AUD savings account of $100 AUD deposited/debited to 
a USD
savings account with an exchange rate entered as 10/11 in the currency dialog. 
I have created 
single line exports in the GnuCash Export Format for the transaction from both 
the AUD Savings account
and the USD Savings account.
 
The exported transaction in SL mode from the AUD account contains no 
information that it involves another
currency other than that the Full Category Path points to the USD account.

If I select the import format as GnuCash Export Settings, set the date format 
and most of the columns to the values
suggested by the headers, I cannot set the Full Category Path column in the 
exported data to Transfer Account as it does
not appear in the drop down list. I would have expected that GnuCash on import 
would have been able to set the Transfer
Account with the export settings.

If however I use No Settings, set the date format and assign the columns as 
their headings suggest, the Transfer Account
does come up and I can set the import data Full Category Path as Transfer 
Account however the price data is 1.00 and
when imported it shows the transaction value as $100, which is reasonable as 
there is no currency conversion information
in the exported record, however the import is not triggering the currency 
conversion dialog.

I am still experimenting with importing the export from the USD account. There 
is more hope of getting restoration of
the internal record of the transaction here as it does contain the conversion 
price information. Doing it systematically
and exploring the effects of various import setting and recording them is 
fairly time consuming however so it may take
me some time to complete and report it.

I hope to identify any problems/limitations and perhaps provide some guidelines 
for importing multicurrency transactions
to use. I'll try and play a dumb user with no knowledge of the internals who 
does the totally unexpected.

> 
> Obviously with one "Account" column and one "Transfer Account" column there 
> can only be a maximum of two accounts per line. As such a 'single line' 
> import 
> can only work for transactions involving only two accounts.
> 
> And that's why a multi-line mode was added: in this mode each line represents 
> one split of a transaction. As one split can only belong to one transaction, 
> the "Transfer Account" no longer makes sense in the multi-line mode. That's 
> why it only appears in single-line mode.
> 
> > 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.
> 
> That would be really cool. Don't hesitate to ask for clarifications of the 
> code if needed.
Will do. Thanks. It is difficult to penetrate the GnuCash code from scratch. I 
am beginning
to understand the importer better than other areas. I have looked at the 
register code
a bit as well and everytime I think I have grasped something it slips out of 
reach again.
> 
> Geert
> 
> 

David

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[Geert Janssens]

Op zaterdag 24 november 2018 23:47:33 CET schreef David Cousens:
> 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.
> 
This is inaccurate. You definitely can associate a transfer account to the 
column in single line import mode. There is "Account" and "Transfer Account" 
for a reason. And it works well in a single currency environment. It breaks 
down in a multi currency one.

Obviously with one "Account" column and one "Transfer Account" column there 
can only be a maximum of two accounts per line. As such a 'single line' import 
can only work for transactions involving only two accounts.

And that's why a multi-line mode was added: in this mode each line represents 
one split of a transaction. As one split can only belong to one transaction, 
the "Transfer Account" no longer makes sense in the multi-line mode. That's 
why it only appears in single-line mode.

> 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.

That would be really cool. Don't hesitate to ask for clarifications of the 
code if needed.

Geert


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[John Ralls]

> On Nov 25, 2018, at 12:14 PM, GTI .H  wrote:
> 
> Em sáb, 24 de nov de 2018 às 19:47, David Cousens 
> 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.

What David described is formal, a.k.a. double-entry, accounting. It’s the only 
way to account for money that’s legally recognized and it’s how GnuCash works. 
His use of “split” is from GnuCash’s code and documentation.

Perhaps you’d be more comfortable with KMyMoney, which doesn’t use double-entry 
accounting and so is less formal in its approach.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Cousens]

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 
> 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.
> 

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Em sáb, 24 de nov de 2018 às 19:47, David Cousens 
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
___
gnucash-user mailing list
gnucash-user@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 

Re: [GNC] Import CSV Multi-currency

[David Cousens]

GTI,
 
>No. I have in my register a ton of one-line two-currency transactions even 
>though the register allow them to be displayed on 4 lines pressing the 
>split button: 1 Description, 2 involved currencies, 1 in white. 
>
>In my humble understanding, splitted transactions are transactions where a 
>value is transferred to two or more destinations because the possible logic 
>for this is split. 
>Two-currencies transactions does not allow the logic for splits = Division 
>by 1 (if you prefer). 

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.)

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.

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.

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.

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,

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. 

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. 

David Cousens




-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Let's go to the laborious enlightenment:

Em sáb, 24 de nov de 2018 às 06:59, David Carlson <
david.carlson@gmail.com> escreveu:

> GTI,
>
> Whenever there is more than one currency in a transaction GnuCash creates
> a split to record the exchange between currencies, so there is a separate
> split line for each currency.
>

No. I have in my register a ton of one-line two-currency transactions even
though the register allow them to be displayed on 4 lines pressing the
split button: 1 Description, 2 involved currencies, 1 in white.

In my humble understanding, splitted transactions are transactions where a
value is transferred to two or more destinations because the possible logic
for this is split.
Two-currencies transactions does not allow the logic for splits = Division
by 1 (if you prefer).


>  When a multi-currency transaction is imported, there will be two split
> lines, not one.
>

If this does not follow the logic above, this is a bug.


> That is an artifact of double entry accounting as implemented in GnuCash
> See chapter 12 if the tutorial <
> https://www.gnucash.org/viewdoc.phtml?rev=3=C=guide>.  As
> explained therein, you need to have some account that is denominated in the
> other currency to use in the transaction, occupying the second split line
> and triggering the exchange rate dialog.  Stock purchases and sales are
> accounted in a similar way.
>

>
The old CSV importer would choke on security purchase transactions which
> have a currency and a commodity which is handled roughly similarly to a
> currency.  I do not know whether the improved CSV importer still has this
> issue, but as Geert, the developer notes, the issue may be in the part that
> he has not addressed yet.
>

Thanks for the efforts, but for me, what you said seems undefined, not
delimited and everything mixed.


--
Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Carlson]

GTI,

Whenever there is more than one currency in a transaction GnuCash creates a
split to record the exchange between currencies, so there is a separate
split line for each currency.  When a multi-currency transaction is
imported, there will be two split lines, not one.  That is an artifact of
double entry accounting as implemented in GnuCash  See chapter 12 if the
tutorial .
As explained therein, you need to have some account that is denominated in
the other currency to use in the transaction, occupying the second split
line and triggering the exchange rate dialog.  Stock purchases and sales
are accounted in a similar way.

The old CSV importer would choke on security purchase transactions which
have a currency and a commodity which is handled roughly similarly to a
currency.  I do not know whether the improved CSV importer still has this
issue, but as Geert, the developer notes, the issue may be in the part that
he has not addressed yet.

On Fri, Nov 23, 2018 at 9:23 PM GTI .H  wrote:

> Em sex, 23 de nov de 2018 às 05:08, Geert Janssens <
> geert.gnuc...@kobaltwit.be> escreveu:
>
> > I think you're right this is currently not possible.
> >
> > In the csv importer rewrite only the csv specific parts have been redone.
> > However once all the info is gathered from the csv file this info is
> > passed on
> > to the generic import matcher, which handles final evaluation of the
> > transactions. This is not yet rewritten as it is used by all importers.
> It
> > looks like this generic import matcher can't cope with the multi-currency
> > data
> > it receives from the csv parser.
> >
> > Can you file a bug report for this please and add your example csv
> snippet
> > from above ?
> >
> > At some point I will continue the work on the importers, though there are
> > currently more pressing matters to handle first.
> >
> > Regards,
> >
> > Geert
> >
>
> Thank you Geert,
>
> Your answer clarifies and directed my next actions.
>
> Well, my import jobs I started to do stopped here and went back to the "To
> Do" list.
>
> It's unfortunate that currently we can't import Single-line two-currency
> transactions. I have transactions waiting since 2008 to enter GnuCash.
>
> Bug report openned: https://bugs.gnucash.org/show_bug.cgi?id=796955
>
>
> The importer is the gateway of new immigrant users from other financial SW,
> the more users, the larger the project, the greater its importance.
> We hope you can dedicate to the importer soon.
>
>
> --
> Regards
> GTI
> ___
> gnucash-user mailing list
> gnucash-user@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.
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Em sex, 23 de nov de 2018 às 05:08, Geert Janssens <
geert.gnuc...@kobaltwit.be> escreveu:

> I think you're right this is currently not possible.
>
> In the csv importer rewrite only the csv specific parts have been redone.
> However once all the info is gathered from the csv file this info is
> passed on
> to the generic import matcher, which handles final evaluation of the
> transactions. This is not yet rewritten as it is used by all importers. It
> looks like this generic import matcher can't cope with the multi-currency
> data
> it receives from the csv parser.
>
> Can you file a bug report for this please and add your example csv snippet
> from above ?
>
> At some point I will continue the work on the importers, though there are
> currently more pressing matters to handle first.
>
> Regards,
>
> Geert
>

Thank you Geert,

Your answer clarifies and directed my next actions.

Well, my import jobs I started to do stopped here and went back to the "To
Do" list.

It's unfortunate that currently we can't import Single-line two-currency
transactions. I have transactions waiting since 2008 to enter GnuCash.

Bug report openned: https://bugs.gnucash.org/show_bug.cgi?id=796955


The importer is the gateway of new immigrant users from other financial SW,
the more users, the larger the project, the greater its importance.
We hope you can dedicate to the importer soon.


-- 
Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Sorry, there was a mistake here I did not copy the list.

Here follows this comment for the list.

Em sex, 23 de nov de 2018 às 02:19, GTI .H  escreveu:

> Em sex, 23 de nov de 2018 às 01:14, David Carlson <
> david.carlson@gmail.com> escreveu:
>
>> GTI,
>>
>> While I am not addressing the issue you stated in your first post, I do
>> expect an import to consider existing multi-split transactions that match
>> the amount and timing of a single line imported transaction in the base
>> account.  A very common case would be to match an existing payroll
>> transaction to an incoming bank account import.  Of course a lot of similar
>> date and amount transactions are not matches.
>>
>
> Okay, I had disregarded this possibility because in this CSV import
> process there is not a step to match repeated transactions and disregard it
> as occurs with the QIF importer, at least for this case of this thread.
>
> One of your posts states that the new GnuCash CSV importer does correctly
>> import single line transactions . . .
>>
>
> I did not say that. CSV importer does correctly import single line
> transactions only for transactions in the same currency.
>
>
>> but you said originally that is the structure of the transaction that it
>> does not correctly import.  I guess I am missing something.
>>
>
> There are several errors that occur (Wrong price value, split of the other
> currency does not accept price edit saying that one currency balances the
> other), not just added unnecessary unbalanced split or unnecessary balanced
> if balanced in the import process.
>
> Regards
> GTI
>


-- 
Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[Geert Janssens]

Op donderdag 22 november 2018 22:28:56 CET schreef GTI .H:
> I did several tests on GnuCash 3.3 on W10 and I can not import without
> errors(adding extra split) a simple transaction like this:
> 
> Date;Type;Amount;Value;Account;Category;Description;TX;Reconcile
> 10/10/2010;Spent;-10;5;Account(currency1);Account(currency2);Test;0.5;n
> 
> Where: Amount*TX = Value
> 
> Configured GnuCash CSV importer column headers:
> Date;None;Deposit;None;Account;Transfer Account;Description;Price;Reconciled
> 
> Any attempt results in a splitted transaction and should not.
> 
> What am I doing wrong?

I think you're right this is currently not possible.

In the csv importer rewrite only the csv specific parts have been redone. 
However once all the info is gathered from the csv file this info is passed on 
to the generic import matcher, which handles final evaluation of the 
transactions. This is not yet rewritten as it is used by all importers. It 
looks like this generic import matcher can't cope with the multi-currency data 
it receives from the csv parser.

Can you file a bug report for this please and add your example csv snippet 
from above ?

At some point I will continue the work on the importers, though there are 
currently more pressing matters to handle first.

Regards,

Geert


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Carlson]

GTI,

Because I did not see the word currency anywhere except the title, I
thought you were only discussing multi-line splits.

When there are two or more currencies involved, it is impossible to create
a single line transaction . Gnucash requires a split line in the base
account's currency and a separate split line in the second currency with an
assigned exchange rate.

While I have no experience with the new CSV importer, I suspect that, like
the old importer, it probably is not designed for multi-currency
transactions.

David C


On Thu, Nov 22, 2018, 11:19 PM GTI .H  Em sex, 23 de nov de 2018 às 01:14, David Carlson <
> david.carlson@gmail.com> escreveu:
>
>> GTI,
>>
>> While I am not addressing the issue you stated in your first post, I do
>> expect an import to consider existing multi-split transactions that match
>> the amount and timing of a single line imported transaction in the base
>> account.  A very common case would be to match an existing payroll
>> transaction to an incoming bank account import.  Of course a lot of similar
>> date and amount transactions are not matches.
>>
>
> Okay, I had disregarded this possibility because in this CSV import
> process there is not a step to match repeated transactions and disregard it
> as occurs with the QIF importer, at least for this case of this thread.
>
> One of your posts states that the new GnuCash CSV importer does correctly
>> import single line transactions . . .
>>
>
> I did not say that. CSV importer does correctly import single line
> transactions only for transactions in the same currency.
>
>
>> but you said originally that is the structure of the transaction that it
>> does not correctly import.  I guess I am missing something.
>>
>
> There are several errors that occur (Wrong price value, split of the other
> currency does not accept price edit saying that one currency balances the
> other), not just added unnecessary unbalanced split or unnecessary balanced
> if balanced in the import process.
>
> Regards
> GTI
>
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Carlson]

GTI,

While I am not addressing the issue you stated in your first post, I do
expect an import to consider existing multi-split transactions that match
the amount and timing of a single line imported transaction in the base
account.  A very common case would be to match an existing payroll
transaction to an incoming bank account import.  Of course a lot of similar
date and amount transactions are not matches. Matching splits in more than
one account during an import that is based on one account at a time would
be very complex to execute.  I am not sure what your previous bug report
addressed, as you did not give the report number.

One of your posts states that the new GnuCash CSV importer does correctly
import single line transactions but you said originally that is the
structure of the transaction that it does not correctly import.  I guess I
am missing something.

David C

On Thu, Nov 22, 2018 at 9:29 PM GTI .H  wrote:

> Thanks for the answers!
>
> Em qui, 22 de nov de 2018 às 19:14, David Cousens <
> davidcous...@bigpond.com>
> escreveu:
>
> > GTI ,
> >
> > Don't know how to do it but perhaps the easiest way to find out is to
> > export
> > the record of a similar transaction  from Gnucash in the default GnuCash
> > Export Format and then examine the exported structure. You can use the
> > default Export Format for importing GnuCash records.
> >
> > David Cousens
> >
>
> Yes, I had already checked the CSV structure exported before attempting the
> import.
>
> So . . .
> Gnucash always exports Multi-line transactions and can import Multi-line or
> Single-Line transactions like the template transaction in my first post.
> Turning single-line transactions into multi-line requires extensive extra
> processing because I have a ton of transactions.
>
> Em qui, 22 de nov de 2018 às 21:09, David Carlson <
> david.carlson@gmail.com> escreveu:
>
> > I have not used the new CSV importer, so I am not sure whether this
> comment
> > actually applies to your case...
> >
> > If the new CSV importer is used similarly to the old CSV importer, there
> is
> > a step in the process to offer an opportunity to match the new
> transaction
> > to existing transactions if there are candidates to consider.  At this
> step
> > the importer may be offering a match to an existing multi-split
> > transaction.  If you do not correct it and declare the incoming
> transaction
> > to be new, that may cause your issue.
> >
> > David C
>
>
> Long ago I opened a bug report with a similar issue to this one.
>
> On importer process, first we need to do the Accounts Mappings, then if
> there is an unbalance, we must choose accounts to do the balancing.
>
> In this topic's case here, there are no existing transactions to consider,
> these are new and non-existent transactions, there are no existing
> transactions to match.
>
> Note that the template transaction in my first post has no way to be
> unbalanced (splitted transaction).
>
> Regards
> GTI
> ___
> gnucash-user mailing list
> gnucash-user@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.
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[GTI .H]

Thanks for the answers!

Em qui, 22 de nov de 2018 às 19:14, David Cousens 
escreveu:

> GTI ,
>
> Don't know how to do it but perhaps the easiest way to find out is to
> export
> the record of a similar transaction  from Gnucash in the default GnuCash
> Export Format and then examine the exported structure. You can use the
> default Export Format for importing GnuCash records.
>
> David Cousens
>

Yes, I had already checked the CSV structure exported before attempting the
import.

So . . .
Gnucash always exports Multi-line transactions and can import Multi-line or
Single-Line transactions like the template transaction in my first post.
Turning single-line transactions into multi-line requires extensive extra
processing because I have a ton of transactions.

Em qui, 22 de nov de 2018 às 21:09, David Carlson <
david.carlson@gmail.com> escreveu:

> I have not used the new CSV importer, so I am not sure whether this comment
> actually applies to your case...
>
> If the new CSV importer is used similarly to the old CSV importer, there is
> a step in the process to offer an opportunity to match the new transaction
> to existing transactions if there are candidates to consider.  At this step
> the importer may be offering a match to an existing multi-split
> transaction.  If you do not correct it and declare the incoming transaction
> to be new, that may cause your issue.
>
> David C


Long ago I opened a bug report with a similar issue to this one.

On importer process, first we need to do the Accounts Mappings, then if
there is an unbalance, we must choose accounts to do the balancing.

In this topic's case here, there are no existing transactions to consider,
these are new and non-existent transactions, there are no existing
transactions to match.

Note that the template transaction in my first post has no way to be
unbalanced (splitted transaction).

Regards
GTI
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Carlson]

I have not used the new CSV importer, so I am not sure whether this comment
actually applies to your case...

If the new CSV importer is used similarly to the old CSV importer, there is
a step in the process to offer an opportunity to match the new transaction
to existing transactions if there are candidates to consider.  At this step
the importer may be offering a match to an existing multi-split
transaction.  If you do not correct it and declare the incoming transaction
to be new, that may cause your issue.

David C

On Thu, Nov 22, 2018 at 4:15 PM David Cousens 
wrote:

> GTI ,
>
> Don't know how to do it but perhaps the easiest way to find out is to
> export
> the record of a similar transaction  from Gnucash in the default GnuCash
> Export Format and then examine the exported structure. You can use the
> default Export Format for importing GnuCash records.
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> ___
> gnucash-user mailing list
> gnucash-user@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.
>
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Import CSV Multi-currency

[David Cousens]

GTI ,

Don't know how to do it but perhaps the easiest way to find out is to export
the record of a similar transaction  from Gnucash in the default GnuCash
Export Format and then examine the exported structure. You can use the
default Export Format for importing GnuCash records.

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@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.