Possible bug in IPlacedPriceProcessor causing added validation issue



We have problems with the cart validation. 

Running the UpdatePlacedPriceOrRemoveLineItems always adds a validation issue.

cart.UpdatePlacedPriceOrRemoveLineItems(CustomerContext.GetContactById(cart.CustomerId), (item, issue) => validationIssues.AddValidationIssues(item, issue), PlacedPriceProcessor);

I found this in the IPlacedPriceProcessor implementation:

      Money? placedPrice = this.GetPlacedPrice(entryContent, lineItem.Quantity, customerContact, marketId, currency);
      if (placedPrice.HasValue)
        Money money = new Money(currency.Round(lineItem.PlacedPrice), currency);
        if (money == placedPrice.Value)
          return true;
        if (money.Amount > Decimal.Zero)
          onValidationError(lineItem, ValidationIssue.PlacedPricedChanged);
        lineItem.PlacedPrice = placedPrice.Value.Amount;
        return true;

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.


Aug 15, 2018 9:53

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 

Aug 15, 2018 10:34


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?


Aug 15, 2018 11:02

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. 

Aug 15, 2018 11:08

Thanks Quan!

Edited, Aug 15, 2018 11:43

By the way, do think it is best to Round the value placedPrice och skip rounding on the lineItem.PlacedPrice?

Aug 15, 2018 16:09

It would work the same, however when it comes to rounding it's complicated, I don't know which would be down the path, but I think the former works better. 

Aug 15, 2018 16:26
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.