Krisoffer, nice investigation. However GetPlacedPrice gets the configured price for the SKU, and it's per item, via IPriceService. I really doubt that you would configure an item to be 46.66666667 so it's very very unlikely to have mismatch here. TBO I'm not sure why lineItem.PlacedPrice needs to be rounded here, but it should be not a problem
Hi!
I look in the database and the UnitPrice in PriceDetail is set to 46.666666667.
We update prices using the service API I guess that is why there are so many decimals. If I use the GUI Commerce writes 46.667 in the database.
Should you always round to three decimals maybe when updating prices using the service API? But I guess that wont fix the issues? Then there would be 46.67 = 46.667 and that still would fail I guess?
/Kristoffer
So yours is one of very very unlikely cases :). I will file a bug for this so it'll not be overlooked. However, this can be fixed quite easily by overriding the default implementation of IPlacedPriceProcessor (using intercept pattern) so you will round the value returned from default GetPlacedPrice.
By the way, do think it is best to Round the value placedPrice och skip rounding on the lineItem.PlacedPrice?
Hi!
We have problems with the cart validation.
Running the UpdatePlacedPriceOrRemoveLineItems always adds a validation issue.
I found this in the IPlacedPriceProcessor implementation:
The lineItem.PlacedPrice is rounded which in our case gives us money.Amount = 46.67.
Meanwhile the placedPrice.Value is not rounded giving us placedPrice.Value.Amount = 46.666666667
Therefor the if (money == placedPrice.Value) is not true and the validationIssues is added.
Maybe I'm doing something wrong here, but it looks like a bug to me.
/Kristoffer