Developer forum

Hi Guys,

Quick update that confuses me more.

By unchecking "Round orderline discounts per quantity" the calculation was made as expected.

But the description of the above setting does not seem to have any connection with how the discount is included in the subtotal calculation.

Please help me understand.

Thank you,
Adrian

Hi Adrian

Hard to say with no templates and screendumps. Try using the attached cheatsheet template and make screen dumps with and without the checkbox. Some of the tags in the cheatsheet only exists in 9.6, but should just render empty cells in 9.5

BR Nicolai

Hi Nicolai,

This part of the checkout is standard Rapido 3.0. No changes made to it.

I will try and use the cheatsheet.

Thank you,
Adrian

Yes, but you still have 1000 settings to fiddle with :-)

Hi Nicolai,

True. But I don't think that any setting should result in something like the attached situation.
I agree I might be doing something wrong but this result is totally unexpected.

Please have a look and let me know your opinion.

Thank you,
Adrian

I need more information. In this case numbers are so small and adding rounding, vat rules and rounding settings would cause weird stuff happening. I want steps to reproduce on a default solution or access to this solution. What was the result of the cheatsheet template?

Hi Nicolai,

I did not actually got to the testing part. This screenshot was sent by my customer today and I started investigating a few hours ago.

I tried to replicate it but I could not. The order is saved in the system though, which means it happened somehow.

My bet is on the Order discount but I cannot be 100% sure. I also suspect the small amounts might be triggering some weird calculations.

We had to create some custom functions to handle the selective rounding.

In the back-end, the price is always 0.01 :)

I will try to replicate it then I will send you the details.

Thank you,
Adrian

Hi Nicolai,

Unfortunately, I could reproduce it.

Here are the steps:

https://dev.allmedia.dotfusion.ro

Search and choose this product: DQ512016 (it's the first variant of the product returned by the search result). Add 100 units to the cart

Go to the cart and choose Remax Courier and Dobierka.

Fill some details in the Address.
Checkout.

The cart will display everything fine until the checkout. The Receipt is displayed as in the screenshot (with wrong calculation). And you can also check the order in the backend. The values are consistent with the receipt.

Please let me know if you need anything else.

Thank you,
Adrian

Oh, and you can access the Cart Cheatsheet here: https://dev.allmedia.dotfusion.ro/Default.aspx?ID=13467&Purge=True

Thank you
Adrian

I just tested the same scenario on the production environment, without the discount, and I got the same wrong result.

Therefore the discount is not the issue here.

Thank you,
Adrian

Hi Adrian

The price of the product is less than one cent... €0,0078. I am pretty sure that will not work since there is rounding to 2 decimals in may calculations.

I am sorry, but we do not support that currently

BR Nicolai

Hi Nicolai,

Quite frankly, this is not the answer I was expecting.

You cannot tell me after 8 month of work on a project that you don't support 4 decimals.

Coming from and Enterprise solution that is integrated with NAV, it does not sound like a reasonable sales statement.

Furthermore, all figures are calculated and stored in the database with 4 decimals.

If you would have tried a test on the solution I have given you as an example, you would have seen that all calculations in the database are correct.

The calculation problem is surfacing ONLY when we have Payment and/or Shipping fees.

Therefore, there is something wrong on that part and it has nothing to do with the number of decimals.

Even with unit prices rounded up to 2 decimals, the calculation should not be less than the cost of shipping and payment.

If you try this product: MT020604 that has a price of 0.92 and add 5 units in the cart, using the same payment and shipping methods indicated above, you will see the total odf the order is still off.

It looks like everytime the subtotal before shipping and payment is lower than the sum of fees, the calculation goes crazy.

Please, have a more in depth look at this issue as it does not seem particular to my project and it is surely unrelated with the number of decimals.

Thank you,
Adrian

Hi Nicolai,

My investigation says that the Fees are subtracted from the subtotal.
Initially I thought (hoped) that it would happen only for amounts smaller than the total fees but it looks like it is happening for all amounts, no matter their value.
Can you think of any setting that might trigger this behavior?

Thank you,
Adrian

Hi Nicolai,

Apparently, the problem is in the default shipping provider.

Adding GLS as a shipping method, calculated the amounts correctly.

I hope these findings are helpful for fixing the issue.

Thank you,
Adrian

Hi Nicolai,

Look no further.

The problem si snot the Shipping provider, nor the number of decimals.

The problem is in the Integration Framework. We are not using any live calculations with NAV, but apparently the code that updates the IntegrationOrderID also overwrites the value for the Subtotal leading to misscalculations. Both parts of the code (DW and NAV) are as standard as they can be. We made no changes to them in this area.

You might wanna look into that part.

Thank you,

Adrian