Dynamics GP
Dynamics GP
Organizer:
- Organized by
-
-
Multicurrency posting error
-
Multicurrency posting error
Hi. Again coming to the experts!! We started using Multicurrency last year. We currently have the Mexican Peso and Canadian Dollar and all was going great. Everything was working as it should. But recently users are having issue when posting batches using the peso. Whether posting or running an batch edit list, all the transactions shows the error, This batch contains multicurrency errors. I thought checking Include Multicurrency Info on posting setup would help with the error. It does, sort of it expands the credits/demos amounts to show the functional/originating currency amouts, and it also removes the error message! But when posting, the batches get thrown to Batch Recovery. I’m not sure what to look for. I will say, that there could be quite some time from the time the batch is entered to the time it is posted. I’m betting that has something to do with it.
-
7 Replies
-
Hi Howard,
Could it be that the exchange rate used on the transaction has expired by the time the batch is posted? Although I would expect that to be reported in an error message on the Multicurrency posting report, it was the first thing I thought of when you mentioned the batch could be open for a long time.
-
Thanks Tori for your reply. This is really a strange one. I have two physically separate instances of GP one being production and the other test. Test is essentially a clone of prod. The older batches that I cannot post in prod, post without a hitch in test! I’ve looked at all the setup of MC between the two and cannot see any difference. The only difference if the test environment is about three months out of date. The test environment was stage at the time we were testing the GP year end update. In production these batches give an error message that there are mutlicurrency errors and posting them throws them into Batch Recovery saying Transaction Edit needed(or something like that). No useful messages on the Edit list. Even though we are not seeing messages saying the Exchange rate is expired, could I update SQL to push the expiration date into the future to see what happens?
-
-
To get past the posting errors, which still do not say anything about rate being expired, I did an update to the MC00100 table and pushed out Expiration dates a year for the rate that correspond to the invoice dates from the PM10000 table. That allowed all the batches to get posted.
Our user that manually maintains the rates, updates it every day. Should we adjust how the daily rates are entered? Should the expiration date be entered using a date way in the future? Attached are pics of the table setup and the rate window. Are we doing something wrong?
Our company marches to its own drummer and some of the batches we have to post are from last year. Payments are made outside of GP via a wire.
-
Good Morning Howard,
GP is smart, in that it will use the NEWEST exchange Rate that fits the date range.
(Time is also a consideration)
Example:
Transaction Date = 2024-04-03 it will use 1.37000
EXCHANGE TABLE
DATE TIME RATE EXPIRY DATE
2024-04-04 12:00.00 AM 1.38000 2024-05-01
2024-04-03 12:00.00 AM 1.37000 2024-05-01
2024-04-02 12:00.00 AM 1.36000 2024-05-01
2024-04-01 12:00.00 AM 1.35000 2024-05-01
So if you do Daily and it is NOT an automated process (Manually Entered) I suggest you at least set the expiry date 1 week, incase the person responsible is away.
I would also highly suggest you set the times always to 12:00.00 AM – this makes sure you are doing true days.
-
-
As I mentioned, updating the MC00100 expiration dates did allow batches to post without error…but some batches are not posting completely. There are a few batches where 1 or 2 transactions did not post, and digging in, the transactions are not posting because there is not an exchange rate entered for their document dates. So if I am understanding things, if frequency in the exchange table is set to Daily, and for whatever reason a day is missed AND a transaction is entered with that date, it won’t post? I was thinking with it set to Daily and rate default Previous Date, if a exchange rate was missing it would look to the previous date and use it’s rate. Should we be using Miscellaneous instead of Daily?
-
Sorry, sorry, sorry this is getting long and convoluted. And I am not an accountant so if none of this makes sense, my apologies. We are working through getting the batches posted. But that leaves us with another issue regarding applying payment to these invoices. All our MXP invoices are paid outside of GP, so Accounting does Manual Payments, but they want to do this with US dollars which GP doesn’t like. But they come back to me saying they need this and this is the reason…”Our bank account is all US cash so the GL account is listed in USD. Our concern is if we apply payment in MXP, GP will convert MXP to USD using a different exchange rate than our bank. This will cause discrepancies with what our bank statement shows was paid in USD and what GP shows. Therefore, we will not be able to reconcile the US bank.”
I did mention a recommendation by Richard Wheeler saying…” You will need a checkbook in the vendor’s currency and need to pay them using this same checkbook. You can, however, point the checkbook back to the same cash account as your regular checking account, keeping all the transactions automatically in one GL for reconciliation.”
But….Accounting came back with this…<b style=”background-color: var(–bb-content-background-color); font-family: inherit; color: var(–bb-body-text-color);”>AP uploads invoice in MXP, but GP posts the USD equivalent based on GP’s exchange rate table.
Invoice 14,213.48 MXP
GP Equivalent 824.38 USD
Treasury pays invoice based on MXP, but the USD equivalent based on banks rate actually comes out of the bank.
Payment 14,213.48 MXP
Bank Equivalent 820.67 USD
We need GP to be able to post $820.67 USD to the cash GL account, GP should not post $824.38 USD to cash GL account.
<ul type=”disc”>
- If 824.38 needs to be posted to clear the invoice’s
USD equivalent amount then 820.67 still needs to go to GL cash account and
3.71 to the currency exchange loss/(gain) GL account.-
@hblitsteindatasystemservicesllc-com -Hi Howard,
The exchange rate differences you are noting between the payment coming out of the bank and the GP equivalent are due to the dates you have in your exchange rate table setup in GP administration tab.
It sounds like you have a bit of a mess on your hands, and it appears that you are missing key setup pieces.
For instance the blog you mentioned advised you can pay those vendors through a separate checkbook – you can actually assign those vendors to that checkbook and better control the currency. You assign that on the options tab of the vendor card.
- If 824.38 needs to be posted to clear the invoice’s
Log in to reply.
