You’re offline. This is a read only version of the page.
Announcements
3,089
I am adjusting an 'Expense' transaction that originates in the TRY currency and is converted to GBP (Accounting Currency) and USD (Sales Currency).
When attempting to post, I receive the following error:
In doing a bit of research, I have determined that the reason they don't balance is currency exchange rates. The original transaction used the effective exchange rate at the time while the adjustment appears to be trying to used the most current exchange rate based on the 'Adjusted Date' which is set before posting the adjustment:
Is it standard behavior to use a new, current exchange rate instead of the one used with the original transactions? If this is standard behavior what can be done?
If I change the 'Adjustment Date' to the original 'Transaction Date', then it will go through properly. However, this can be challenging when the transaction is a bit old and we have 'Closed' the ledger for that period.
Hi Brad,
Please create a support ticket with MS if you have not yet found a solution on this issue.
Ludwig,
Thank you very much for your guidance here. We will reach out to MS and see what help we can get. Thanks!
Brad
Hi bRadlyJames,
I think for this one you should contact the MS support.
They should be able to review and correct/adjust the code; not only for your issue but in general and ensure that there are no repercussions to other areas/functions.
Best regards,
Ludwig
Update:
I received an .xpo from an R3 environment and it didn't make a difference.
I ran the CU8 update in my test environment, exported an .xpo and it didn't make a difference. (Laughably, there were only comments from the CU8 update. lol)
After debugging a little further, I found that TmpProjAdjustmentCreate methods 'createFromAdjustment' and 'totalCostAmount' are never called when doing an adjustment.
After digging a little further, I found the 'postCost' method in the 'ProjPost' class with this line:
exchangeRateHelper = CurrencyExchangeHelper::newExchangeDate(Ledger::primaryLedger(CompanyInfo::findDataArea(curext()).RecId), ledgerVoucherObject.parmAccountingDate());
This is the crux of the problem (Is it really a problem though?). It is initializing the 'exchangeRateHelper' object with the 'parmAccountingDate()' from the 'ledgerVoucherObject'. This date is the 'Adjusted Date' from the adjustment. The 'Adjusted Date' is defaulted to 'Todays' date. Then comes the 'do not balance' error because of the exchange rate.
This is fairly easy to remedy... Simply replace the 'ledgerVoucherObject.parmAccountingDate()' with 'projTrans.transDate()' which will initialize the 'exchangeRateHelper' with the original transaction date.
HOWEVER, there are some questions surrounding this approach...
1. From an accounting 'best practices' standpoint, which date should be used for getting an exchange rate?
2. Could this break other functionality around Expense Adjustments?
Still a lot of questions surrounding a fix for this. I'm not sure yet how we will proceed.
Ludwig,
Thank you for your help. I believe that KB2949821 will fix my issue, however, these hotfixes never come alone. This one is part of R2 CU8.
I've narrowed down the object to Tables\TmpProjAdjustmentCreate and methods createFromAdjustment and totalCostAmount.
I'm reaching out to some colleagues to see if I can get an export from a version that is R2 CU8 or later. That would save me from messing with my test environments and a CU8 install. However, I plan on doing that install if I can't get the .xpo another way.
Thanks!
Great.
Would be great if you could keep us updated how things are going.
Cheers,
Ludwig
Ludwig,
Thank you. I'm on 2012 R2 and found this.
fix.lcs.dynamics.com/.../1301179
I was also able to narrow this down to the DynamicsAX2012R2-KB3100111-Foundation.axmodel. I'm going to give this a try and see if it works. Thank you!
Hi bRadlyJames,
Is it possible that your issue is related to the following bug/hotfix?
fix.lcs.dynamics.com/.../Details
Best regards,
Ludwig
You are correct and I agree. The only question is, why do I get an error with what appears to be standard functionality?
As you can see in my example, the original Transaction Date is 2/3/2020 and the Adjusted Date is 7/6/2020 (Basically 'Today'). That appears, as you've said, to be standard functionality. However, I still can't figure out why I see the 'Transactions do not balance' error.
Hello bRradlyJames,
Is your adjustment date the same date on which the transaction was originally posted?
What I get from your description is that this is not the case.
It sounds as if you want to backdate the transaction into a previous period, is that right?
If this is the case then you have to ensure that exchange rates are correctly setup for this period into which your adjustment date falls into.
Using the exchange rate that was valid on the original posting date would be wrong in my opinion. Imagine you post a transaction in July where an exchange rate of 1:2 is in place and then you adjust this transaction to June where an exchange rate of 1:3 is in place. I would expect that the transaction in June is posted with the 1:3 rate and not with the one that is valid in July.
Hope this helps.
Best regards,
Ludwig
#1
André Arnaud de Cal...
294,110
Super User 2025 Season 1
#2
Martin Dráb
232,866
Most Valuable Professional
#3
nmaenpaa
101,158
Moderator
Share
Report
All responses (
Answers (
