GNOME Bugzilla – Bug 727423
Process payment uses the wrong currency for invoices and bills using trading accounts
Last modified: 2018-06-29 23:29:06 UTC
I have an A/R account in USD and created a customer invoice for say $10,000. I receive the payment for this invoice in a Euro bank account. Let's assume $1 = €0.75, so I receive €7,500. I enter this payment using the "Process Payment" dialog. I select the invoice, and the "Payment" input field gets pre-filled to "10,000", which suggests this is $10,00. When I click "OK", I get the currency conversion dialog, which says "Amount: 10,000" and "Transfer from EUR to USD", which suggests that it is now treating this as €10,000. If I enter "To amount: 7,500", then the exchange rate shown is €1 = $0.75, which is the inverse of what I need. If I ignore this and click OK, I get a payment transaction with €10,000 in the bank account, $10,000 in the A/R account and $2,500 in Imbalance-USD. I'm not sure where the imbalance comes from (I think in older versions of gnucash, this problem also occurred but without the imbalance split), but it seems that the main problem is that the payment amount entered in the "Process payment" dialog is used against the bank account, and then converted to the A/R amount using the entered exchange rate. In some previous GnuCash versions, I could work around this by ignoring the proposed payment amount and instead entering the bank account amount in the "Process payment" dialog and then entering the invoice amount in the currency conversion dialog. However, when I do this now, I still get an imbalance split in the resulting payment. E.g., I get: Bank account € 7,500 Trading:CURRENCY:USD $ 10,000 A/R USD $ 7,500 Imbalance-USD $ 2,500 Trading:CURRENCY:EUR € 7,500 This is nearly what I need, except the Imbalance-USD amount should go into the A/R USD account. If I fix that manually, things seem to work out as expected. So, in previous versions there was a bug where the process payment amount was used as the bank account amount instead of the A/R amount (which was probably not wrong, but just confusing, since the interface suggested the A/R amount as the default). In the latest version (perhaps some older versions as well, haven't checked) the problem seems to be that the payment amount entered in the process payment amount is used _both_ for the bank account _and_ the A/R account, causing any currency conversion difference to end up as imbalance. I haven't checked this same scenario with A/P, so I don't know if it also occurs there.
One more thing: if you apply the workaround of entering the bank amount in EUR in the process payment dialog, it seems that the lot link transaction also gets created using the EUR amount, in the A/R USD account, leaving part of the invoice unpaid.
Bug 744858 - "Bill in one currency, paid in second currency and allocated to account in third currency" in GC 2.6.5 has this as 2. and a nice demo file. As I tried to reproduce that, I started from Find Bill, selected a bill, called Process Payment, got the Invoice Amount 500 DKK, which should get paid by 80 EUR per card. The FX dialog popped up with the write protected Amount 500. Get online quote found 6.25 DKK:1EUR resulting in 3125 DKK... So we have the same wrong behavior for invoices and bills in the payment process. Matthijs, IIRC in stock accounts we had a tool to scrub lots, but I can't find it now. Perhaps something like that could help here too.
Scrub lots can be reached by right clicking on an account in the chart of accounts, then View Lots...
I didn't test if "Assign as Payment" has similar problems.
Copy of Bug 744858#c2 because most parts belong here: kenreto00@outlook.com [reporter] 2015-02-21 00:23:41 UTC (In reply to Frank H. Ellenberger from comment #1) > ad 2. Starting find bill dialog you tried to pay 500DKK with 80EUR, but got > 80 DKK on the invoice and 420 inbalance. > IMHO here GnuCash could be more smart. > I that behavior already described in Bug 727423 - Process payment uses the > wrong currency for invoices and bills using trading accounts. The user generally faces 2 possible scenarios at the Process Payment (PP) dialog: 1. Retain the figure initially displayed in the Payment field. In this case, this would be 500, corresponding to the total of the bill (in DKK) for which the user is seeking to process payment. If the initial figure is retained, transaction splits are created with amounts equal to 500 for both the A/P account (in DKK) and the bank/asset account (in EUR). An imbalance is created for any difference given the exchange rate entered and the user must manually adjust the EUR split to properly reflect the correct amount of EUR paid (debited to the bank/asset account) given the exchange rate. 2. Change the figure initially displayed in the Payment field. In this case, this would be 80, corresponding to the total paid from the selected bank/asset account (in EUR). If the initial figure is changed to a EUR-denominated figure, transaction splits are created with amount equal to 80 for both the A/P account (in DKK) and the bank/asset account (in EUR). Once again, an imbalance is created for any difference given the exchange rate entered and the user must manually adjust the DKK split to properly reflect the correct amount of DKK paid (credited to A/P account) given the exchange rate. > Motivation: If there is no bug we should improve the documentation. > Improved documentation may assist the user with understanding the need to enter a Payment amount in the same currency as the account from which payment is to be made. The user only makes the selection of an account from which payment is to be made once the Process Payment has already opened, and the figure added to the Payment field is the same amount as the total of the posted bill for which payment is being processed. It would also assist the user greatly to post the correct split amounts to the respective A/P and bank/asset accounts so an imbalance split is not created that then requires manual adjustment by the user for each such transaction. That is, once the user enter the exchange rate, the correct amounts can be calculated for each currency and posted to the respective accounts. It is this separate imbalance split issue that is the subject of Bug 727423. Issue #1 in the original post remains a separate issue entirely.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository. *** This bug has been marked as a duplicate of bug 746792 ***
Awesome, thanks. I'll see if I can get trunk compiled here and test if this fully fixes my problem.
You want the "maint" branch, not master/trunk.
Ah, thanks for the headsup. I just ran maint, and it indeed solves the problem I was having. Also, the explicit currency indication in the pay invoice window is a nice addition :-)
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=727423. Please update any external references or bookmarks.