How to handle rounding difference caused by multicurrency?

(0) Share

Report

Posted on by JamesLyn

360

Hello,

I'm fairly new to the multicurrency functionality of GP so this may be a simple fix. We currently have receivable batches generated by an external application that get imported into GP. Also, CAD is our functional currency.

My issue is as follows, an invoice for $816 USD converts to $841.67 CAD (exch rate 0.9695). Its distribution is made up of $35 USD + $71*11 USD = $816 USD which all converts to $36.10 CAD + $73.23*11 CAD = $841.63 CAD. Note the CAD is out by $0.04 which I can verify in the "Rounding Difference" field (See attached image). Because of this difference, when we run the sales aged trial balance, there is forever an outstanding amount after the payment of $841.67 CAD is applied.

Is there an automated feature in GP to automatically adjust entries for rounding differences?

Thanks,

James

*This post is locked for comments

I have the same question (0)

All responses (8)

Answers (0)

Community Member on at

Like (0)

Report

What I have seen done is the use of an account for these particular Currency Exchange Differences and apply the 0.04 to that account. In this case it is short but there will be instances where it will be slightly over. This account just helps balance out these minor differences so that it won't show up on your aged TB.

kk

Was this reply helpful? Yes No
JamesLyn 360 on at

Like (1)

Report

I should have mentioned that the invoice and payments are in USD and since the USD $816 balances, the system says it is fully applied and nothing else can be applied. When the system detects FX difference, it auto-generates the FX entries to balance the transaction. I was hoping there was a similar functionality for rounding issues.

Was this reply helpful? Yes No
Rszeto 765 on at

Like (0)

Report

Hi James,

I've had the same problem. Were you able to find a fix to this?

Was this reply helpful? Yes No
DominicBeland 332 on at

Like (0)

Report

i'm having the same issue. Payebles documents are fully paid (cheque and invoice in history) but when pullign a Chronological TB with multicurrency, there are many documents that appear because the amount applied doesn'T add up to the Document amount although the documetn is fully paid.

Any resolution?

Was this reply helpful? Yes No
Tami Farrelly 5,080 on at

Like (0)

Report

many moons ago in GP version 10 we had to open up a support incident with MS to clear these out as we had 10 years worth....then we created an account to post the differences.

Was this reply helpful? Yes No
DominicBeland 332 on at

Like (0)

Report

I think My problem is slightly different. when entering a multicurrency transaction, a rounding difference is automatically sent to a rounding GL account in the distribution. However, nowhere in the header or details of the transacion does it show that there is a rounding difference. But you can clearly see functioning totals that differ.

The weirdest part is I am unable to untie the GL account for this rounding. I have taken it out from the Vendor, from the Class, from the Posting accounts and Currency account but It still post to the rounding account.

Was this reply helpful? Yes No
Suggested answer

JamesLyn 360 on at

Like (0)

Report

The way we solved this was through a combination of SQL queries and a manual journal entry

1. Investigate all of the applied amounts that need to be changed to balance against the invoice and make note of the voucher numbers and the functional amount of the invoice

2. Run the following SQL update statement to set the $ value equal to the amount of the invoice for each voucher number. If possible run this in a test environment, and at the bare minimum, make a database backup prior to running the update statement. Depending on where the voucher is (work, current, history) the PM table will change:

UPDATE [GP DATABASE].PM30200 SET DOCAMNT = [functional amount], PRCHAMNT = [functional amount] WHERE VCHRNMBR = '[voucher number]'

3. post a manual journal entry to your accounts payable control account for the net total of all $ changes and book it somewhere such as FX gain/loss

As of GP2013 R2, the issue stopped so we have not had to run this query since then.

EDIT: The route cause for us was we had a different ERP posting transactions into GP. GP uses an exchange rate such as 1.032 however the other system uses the inverse 0.9689. Because we only use up to four decimal places, it does not always round properly causing these differences. Since GP2013 R2, GP appears to be properly rounding for us.

~James

Was this reply helpful? Yes No
DominicBeland 332 on at

Like (0)

Report

ok thanks.. Yes We did something of this sort (changin the Applied amount in the PM30300 to correspond with the docamount in the PM30200.

So you're telling me that this is a probl;em in GP before 2013 R2.... my client is at GP 10... so it explains somewhat.

Was this reply helpful? Yes No