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

[David Carlson]

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