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

[David Carlson]

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