After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744858 - Update exchange rate on bill only possible once per session (after unpost/repost)
Update exchange rate on bill only possible once per session (after unpost/rep...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Business
2.6.5
Other Windows
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-20 14:11 UTC by kenreto00
Modified: 2018-06-29 23:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Demo file with a separate bill for each issue described. See the note in each bill. (26.82 KB, application/xml)
2015-02-20 14:11 UTC, kenreto00
Details

Description kenreto00 2015-02-20 14:11:59 UTC
Created attachment 297398 [details]
Demo file with a separate bill for each issue described. See the note in each bill.

Using PortableApps GnuCashPortable 2.6.5 on Windows XP.

I used the following procedures to record a bill in DKK, paid using a card denominated in EUR and with the cost allocated to an expense account denominated in AUD. The DKK/EUR and EUR/AUD exchange rates are known.

0. Go to File > Properties, and check Use Trading Accounts under the Accounts tab.
1. Go to Business > Vendor > New Vendor... to create a new vendor, Test Vendor (DKK), with currency DKK.
2. Go to Business > Vendor > New Bill... to create a bill from Test Vendor (DKK). Allocate a purchased item to an AUD denominated expense account, Expenses:Test.
3. Post the bill. The user is asked to enter a DKK/AUD conversion rate. The user can enter the DKK/AUD exchange rate or the AUD expense amount if known, or calculate the rate using the other 2 known rates.
4. Click Process Payment to open the Process Payment dialog. Enter the amount paid in EUR in the Payment field under the Amount section heading, and select the EUR denominated card account from the account tree in the Transfer Account box. Click OK to complete the processing of the payment.

Two separate issues arise when completing this procedure.

1. When posting the bill, if an incorrect exchange rate is entered it is not possible to unpost the bill, repost the bill and enter a correct exchange rate. It appears that any reposting of the bill automatically uses the original exchange rate entered. A new bill must be created to enter the correct exchange rate.

2. When processing the payment, an Imbalance-DKK split is created despite the user having entered the required exchange rate to calculate all relevant splits in their respective currencies. The user must manually adjust the Accounts Payable split and delete the Imbalance split.
Comment 1 Frank H. Ellenberger 2015-02-20 23:52:52 UTC
For the records:
We have been in IRC before: http://lists.gnucash.org/logs/2015/02/2015-02-20.html#T04:57:39

The reporter has australian settings - default currency is AUD.

Motivation: If there is no bug we should improve the documentation.

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.
Comment 2 kenreto00 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.
Comment 3 Frank H. Ellenberger 2015-02-21 03:07:24 UTC
I do the following:
 * If it exists, remove the payment transaction;
 * unpost the invoice;
 * Remove the wrong entry from the price DB
 * Post the Invoice again
 Then I get the message "One or more of the entries are for accounts different from the invoice/bill currency. You will be asked a conversion rate for each."
 "Transfer Funds" pops up with 
  Amount 200 and
  Exchange Rate 0.2 (1 AUD : 5 DKK)
  (To Amount 40.00 - after tabing over Exchange rate)
That is the remaining quote in our price db.

Don't forget to process payment, if it was there before.
Here I run in Bug 727423 again. My workaround now:
 * open account "card, EUR"
 * Edit the splits of the payment transaction:
 ** in acount Assets:Card. Euro insert "/6.25" (divide by the rate) behind the amount, 
 -> results in Amount with 32.00
 *** Confirm transer funds
 ** remove the lines with Imbalance and Trading (<TAB><DEL>...)
 ** leave the transaction
 -> the Trading splits are recalculated, the imbalance is eleminated.
Voilá! So I can not reproduce issue 1. What did you different?

One additional issue, which I see in my control reports: Bug 482186 - Customer report for customer who gets invoiced in AUD shows total with label JPY if accounts "Default currency" is JPY.
Comment 4 kenreto00 2015-02-28 01:08:29 UTC
(In reply to Frank H. Ellenberger from comment #3)
>  * If it exists, remove the payment transaction;

The demo file I filed with this bug included 2 bills:

- 000001 had its payment processed to demonstrate the issue of the imbalance created in the payment transaction (issue 2 in the original post).
- 000002 did not have its payment processed as this solely demonstrated the issue of being unable to correct a previously entered incorrect exchange rate when the reposting a bill (issue 1 in the original post).

(I should have numbered these so they are in the same order, and in future file separate issues as separate bugs for easier tracking.)

So no payment transaction to remove in this instance.

>  * unpost the invoice;
>  * Remove the wrong entry from the price DB
>  * Post the Invoice again
>  Then I get the message "One or more of the entries are for accounts
> different from the invoice/bill currency. You will be asked a conversion
> rate for each."

My experiences trying different procedures...

* Open data file, unpost bill, repost bill:

- A message box with the message "One or more of the entries are for accounts different from the invoice/bill currency. You will be asked a conversion rate for each." is displayed. Click Close. A Transfer Funds dialog is displayed allowing the user to enter an exchange rate. The FX rate set in the Exchange Rate field is the previously entered (in this case, incorrect) rate.
- If the user enters the correct FX rate, the bill transaction in Liabilities:Payables:DKK is updated to reflect the new/correct rate.
- If the user enters the incorrect FX rate again, the bill transaction in Liabilities:Payables:DKK reflects the rate entered.

* Open data file, *remove the incorrect price from price editor*, unpost bill, repost bill:
- The message box/Transfer Funds dialog are displayed as above allowing the user to enter an exchange rate. The FX rate set in the Exchange Rate field is the remaining (in this case, correct) rate.
- If the user enters the correct FX rate, the bill transaction in Liabilities:Payables:DKK is updated to reflect the new/correct rate (as above).
- If the user enters the incorrect FX rate again, the bill transaction in Liabilities:Payables:DKK reflects the rate entered.

In either case, if the user attempts to unpost/repost a second (or third, fourth, ...) time since opening data file, the bill is posted without displaying the message box/Transfer Funds dialog to provide an opportunity to re-enter the FX rate.

If an incorrect price is removed from the price editor after the first unpost/repost, the message box/Transfer Funds dialog is no longer displayed to provide an opportunity to re-enter the FX rate.

So it appears that there is different behaviour depending on whether the unpost/repost is initiated for the first or subsequent time since the data file was opened.

Also, removing a previously entered incorrect rate may provide the user with an opportunity to re-enter a correct rate, though it appears not to provide this opportunity any more than closing/re-opening the data file as it does not provide an opportunity to re-enter the FX rate after the first unpost/repost.
Comment 5 Geert Janssens 2015-06-14 22:33:18 UTC
Thanks for taking the time to report this.

As you say it's easier to track bugs if they are in separate reports.

The part about problematic payments in a multi-currency business transaction was already reported in bug 746792. And this has been fixed yesterday.

The other part of this bug is about correcting a wrong exchange rate when unposting and reposting a bill. I will keep this bug open to track only that part still and I have changed the title to reflect this.

I can confirm your observations. It appears one can only enter an exchange rate once for a given bill during a session.  After that, the gnucash file has to be closed an reopened in order to make another correction to the exchange rate.
Comment 6 Geert Janssens 2015-06-15 20:31:57 UTC
Today I changed the behaviour on reposting:
each time a bill is (re)posted all exchange rates will be asked
again. If for a conversion the rate was already known beforehand
it will be suggested as default value. That leaves the user
free to accept the previous value or to enter a new one as needed.

This fix will first appear in gnucash 2.6.7.
Thank you for your bug report.
Comment 7 John Ralls 2018-06-29 23:38:40 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=744858. Please update any external references or bookmarks.