Multi-currency transactions with trading accounts from 2.4.13 getting messed up in latest 2.6.3

Sat Jun 21 21:00:06 EDT 2014

Hi David,

I'm using sqllite files rather than XML, so they are not that 
straight-forward to open.
I also don't think that the exchange rate is stored in each transaction 
- at least not explicitly. It's there implicitly, of cource, simply 
because there are 2 amounts in the trading accounts of the respective 
currencies.

Either way - I'll just try to put out as many details as I can, hoping 
that the team will pick this up and release a fix (if it is indeed a 
bug). I don't want to mess with my files and break something else on the 
way....

Mark

On 2014-06-21 07:54, David Carlson wrote:
> On 6/21/2014 9:44 AM, David Carlson wrote:
>> On 6/20/2014 11:18 PM, David Carlson wrote:
>>> On 6/20/2014 3:37 PM, Mark wrote:
>>>> So here is an exact example of what I am talking about:
>>>>
>>>> In 2.4.15, my transaction looks like this:
>>>> Account                  Decrease        Increase Currency
>>>> =============================================================
>>>> Asset account-USD        4,522.34                       USD
>>>> Trading:CURRENCY:EUR     3,379.15                       EUR
>>>> Asset account-EUR                        3,379.15       EUR
>>>> Trading:CURRENCY:USD                     4,522.34       USD
>>>>
>>>>
>>>> Opening the file in 2.6.3, the amount of the EUR trading account is
>>>> suddenly changed to the amount of the USD trading account, which
>>>> throws the transaction out of balance.
>>>> In order to compensate, an Imbalance split line is being added:
>>>>
>>>> Account                  Decrease        Increase Currency
>>>> =============================================================
>>>> Asset account-USD        4,522.34                       USD
>>>> Trading:CURRENCY:EUR     4,522.34                       EUR
>>>> Asset account-EUR                        3,379.15       EUR
>>>> Trading:CURRENCY:USD                     4,522.34       USD
>>>> Imbalance-EUR                            1,143.19       EUR
>>>>
>>>>
>>>> This is happening right after I open the file, before I even select or
>>>> open any accounts or transactions.
>>>> And as I said, trying to manually adjust the transaction to look like
>>>> it did originally is not possible. When I try to save it, it kicks it
>>>> back to the second version with the Imbalance line.
>>>>
>>>> Thank you,
>>>>
>>>> Mark
>>>> _______________________________________________
>>>> gnucash-user mailing list
>>>> gnucash-user at gnucash.org
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>>> -----
>>>> Please remember to CC this list on all your replies.
>>>> You can do this by using Reply-To-List or Reply-All.
>>>>
>>> We need some help from a developer on this.  I am just another user.
>>> All of my experience is in Release 2.4.13 (and earlier) in Windows 7.  I
>>> have not migrated to 2.6.3.  Your description suggests that there may be
>>> something odd happening in release 2.6.3 as well.  Generally, each
>>> account is supposed to have a specific currency assigned to it and when
>>> there is a transfer to an account that has a different currency assigned
>>> to it there should be an exchange rate included in the transaction.
>>> That exchange rate is not displayed, but it is included in the data.
>>> Trading accounts are supposed to make it possible to manage the ever
>>> changing exchange rates so that all transactions will be balanced over
>>> time if I understand things correctly.
>>>
>>> I was able to use a text editor that could read the XML format to find
>>> the corrupted transactions that did not have a valid currency assigned
>>> in my data file, then use GnuCash to replace them.  I do not trust
>>> myself to edit in XML format.
>>>
>>> You might also try using the IRC chatroom #gnucash for some help.  There
>>> is frequently one or more developers there.
>>>
>>> David C
>> After sleeping on it I think that your problem (or at least the
>> solution) may be similar to mine.  In my case, once the Since Last Run
>> assistant in release 2.4.13 had created a corrupted transaction, that
>> transaction looked ok until I tried to manually edit a field in it that
>> involved the exchange rate.  Then it became clear that it could not be
>> edited correctly period.
>>
>> If a corrupted transaction is duplicated, the new transaction is also
>> corrupted.  The only recourse is to completely replace it with a
>> manually created (with no auto-completed fields) transaction.  The
>> problem seems to stem from the fact that the (hidden) exchange rate
>> cannot be corrected because it is not properly defined in the
>> transaction record.  Since I could not directly see the corruption while
>> using GnuCash, I had to use an XML editor to find the bad transactions
>> within my data file.  That was a little tricky.
>>
>> It is also possible to use the duplicate transaction function starting
>> from a transaction that is known to be good then editing that new
>> transaction to match the correct information visible in the bad
>> transaction.  I put identifying characters in the Number fields of the
>> transactions to keep track of which were bad and which were
>> replacements.  That process worked for me with the 27 or so bad
>> transactions in my file.
>>
>> Hopefully, once you have eliminated the corrupted transactions from your
>> file, release 2.6.3 and newer should not create any more corrupted
>> transactions.
>>
>> David C
> Since at least some of the corrupted transactions in your file develop
> Imbalance lines when opened in release 2.6.3, searching for those
> Imbalance lines would be a nice way to find the corrupted transactions.
>
> David C
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>