Rounding rules applied on 50% payment plan
Answered
Customer : Disney Paris - DLP ( The customer is on premise and on old version 20.96)
Customer is currently putting in place an integration with their accounting solution and they need a solution to have matching amounts for their invoices.
Here is the use case presented by the customer:
- There is a contract of 9936€ tax included
- If we set 2 deposits of 50% each, each deposit amount should be 4968€
-
However, we end up in EBMS with a deposit of 4968.01 and another one of 4967.99
What is the rule for EBMS to be able to regulate the amount of both deposit to match the total contract ?
Regardless of what setting the customer has chosen from the below two options, the amounts shouldn't be reflected as such: the total amount was already whole. However, it has been broken down.
Amount - Calculation for each payment plan step.
- Round to the Nearest Whole Amount - Any percentage based order phase payment plan step rounds to the nearest whole amount. The difference is accounted for in the final payment plan invoice.
- Use Calculated Amount - Exact amount calculation is used.
Are there other configuration rules or rounding settings in the payment plan logic that we should check which might influence this behavior?
-
Official comment
The calculation by default does 50% of the tax exclusive amount (rounded) and 50% of the tax amount (rounded) and adds them together. If you run the math on the amounts on your order - thats whats happening currently.
A parameter setting can assist. Try manually adding the following and recalculating the payment plan:
Application: AR
Parameter: 9X0
Description: Inclusive Tax Handling on Payment Plans
Value: Y
NOTE: In 25.4 - we created a new option for Creating Step Details - which drastically changed the calculation methods,. The parameter above only is recognized by the old payment plan calculation model - which is still used when Create Step Detail = N on a payment plan.
Long term plan is to retire the 9X0 parameter as we move to the new calculation models over the next year or so - which has this logic built in by default. -
Ryan Ungerboeck tagging you for visibility
Please sign in to leave a comment.
Comments
2 comments
Date Votes