You’re offline. This is a read only version of the page.
Announcements
85
I have a customer using purchase ledger invoice matching. Ideally they want to set a maximum tolerance as an amount rather than a percentage. As far as I can tell, this is only possible by using the "match price totals" option and choosing either "amount" or "percentage and amount". It does not seem to be possible to use any of the other forms of invoice matching without setting the tolerance as a percentage.
Unfortunately it seems that where the price totals matching option includes "amount", one of the validation checks that AX runs is against the line value in the accounting currency. According to the information at https://ax.help.dynamics.com/en/wiki/invoice-matching-details-page-field-descriptions/ the invoice matching field "Unmatched purchase price total in accounting currency" is determined as follows (emphasis mine):
"The amount of the variance between the cumulative invoice price total and the purchase order price total, in the accounting currency. The invoice price total includes the invoice line that you are working with plus any posted and pending invoices for the same purchase order. The calculation to the accounting currency uses the exchange rate for the invoice that you are currently working with for the invoice price total. The exchange rate for the purchase order is used for the purchase order price total. The calculation uses the exchange rate as of the date that the purchase order line was created. This field is not displayed if None or Percentage is selected in the Match price totals field in the Accounts payable parameters page."
So my customer has a situation where they have placed a purchase order in JPY where their accounting currency is USD. The invoice has arrived and the amount on the invoice is exactly the same as the amount on the purchase order in JPY. However it is failing invoice matching because the exchange rate has moved since the purchase order was created such that the difference between the order amount at today's rate and the order amount when the order was placed, as expressed in the accounting currency USD, is more than the amount we specified as an allowable tolerance.
Has anybody else encountered this situation or found a workaround? It seems fairly insane for invoice validation to fail due to currency movements that the customer has no control over and which do not give them any grounds to reject the invoice. As far as I can tell the only workarounds would be either to turn off the price totals matching (or change to percentage based) or to accept the variance. The first of those options isn't really acceptable. A percentage based tolerance could potentially still be a very large sum of money. The second option creates a significant extra workload.
Hi Sabina,
The screenshot is from an environment on the following version:
Installed product version : 10.0.26 (10.0.1192.87)
Installed platform version : Update50 (7.0.6354.79)
I don't know in what version this option has been added, ...
Hi Thomas
Do you know which version this was released in?
I have a customer who is on 10.0.24 and are asking for a mod in relation to this so want to be able to let them know which version it was released in (can't seem to find any documentation in relation to it).
Thanks
Sabina
Hi all,
We have encountered the same "issue" as mentioned here. We now have the option to select the currency that needs to be used for total matching. Changing following setup to transaction currency gives the expected behavior.
And that is a frustration. If the Invoice and Purchase Orders are consistent in their currency, then exchange rates need not be considered. The management of exchange rates, involving Treasury, taking of cover etc - is a separate issue altogether. I wish there was a parameter that could make it work this way. Is is naivete that has us with the current functionality? Or have I overlooked some other reason?
If the JPY price is correct and you will pay in JPY then At the end of the day the difference has to be accepted in the accounts one way or another. The rate will no doubt change again the day you approve payment, cut the cheque, and when the vendor receives the cheque, banks the cheque etc
Thanks, both of you for your replies. I agree that given this is standard behaviour, the only options are to either customise it or to use percentage based tolerances. Unfortunately percentage based tolerances may still give allowable variances that are in excess of what my customer considers acceptable if the purchase order is large.
You've both confirmed my thoughts that there aren't any other ways around this that I've missed.
Hi Andrew,
I do agree with you that it looks insane. But the documentation is clear how the check is performed. I can understand why the accounting currency will be checked. This is e.g. due to possible budget control.
Or the tolerance should be setup where it could take excessive currency changes into account or like Nuno mentioned you can consider a customization. Setting up the tolerance with a percentage would give a better flow for this compared to an amount.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
290,186
Super User 2024 Season 2
#2
Martin Dráb
227,996
Super User 2024 Season 2
#3
nmaenpaa
101,148
Share
Report
All responses (
Answers (