Developer forum

Hi Nuno

No, that field is not available in the viewmodels currently. You can create the price as informational on the price matrix - then it is available on product.PriceInformative property.

If we were to add the database price seperately, it could be one of these 2

• Just the raw value from the database as a double on the product viewmodel. No vat or priceviewmodel.
• A full priceviewmodel as a property on the product viewmodel.
• We can automagically add the db price to ProductViewmodel.Prices collection (which is mostly for quantites, so probably not nice)
  • Set the informative price to db price if it is different from what comes from price provider - but then you cannot use price, informative and db price in one go.

Thoughts?

Hi guys,

We had a similar situation and we ended up using a ProductField for the MSRP price.

Of course, this solves it partially since you only have a value and you don't have the advantage of VAT calculation and all of the other details.

@Nicolai maybe it would be a good idea to have a standard MSRP price field on a product that can be accessed in the ProductViewModel. I know that PriceIsInformative is supposed to handle that part, but sometimes this requires some adjustments to the Batch integration, while having it on the product can make the integration easier and standard.

Thank you,
Adrian

Hi Nicolai,

Although not necessary for US, a full PriceViewModel may be a better option for VAT related projects where they may want to see the price with and without VAT.

Just like you, I don't like the concept of adding the db price to the Prices collection. 

@Adrian In your projects how different is MSRP from the Price? The way we see is:

• The Price is "the price"
   
• In our Batch imports we get the ERP's MSRP to the Price field
  That takes care of Anonymous users for example
   
• When there is User Specific Pricing, Live Integration will update the Price value
  And we rely on the db price to tell the difference
   
• A standard field called MSRP would just have the same value as Price
  Considering that Live Pricing would still update the Price value but since it does not persist to the database you can never tell the difference looking at the db or backend
   
• If you need to batch user specific prices, you'll use the Price Matrix anyways, so the MSRP is equal to the Price

So I wonder what real use you'd have for a standard field called MSRP? We've had projects where we'd had to import multiple prices, but they were so rare that custom fields were the right fit for us. 

Best Regards,

Nuno Aguiar

Hi guys,

In my case, the price was just informative. We were always using LivePrices. Therefore the value was just for display purposes and for outlining the saving.

Adrian

Hi Adrian,

Same as us then, but we just use it differently then. We typically check if Ecom:Product.Price != Ecom:Product.DBPrice. That way we don't need additional fields.

Maybe with adding the DBPrice as part of the ViewModel we can make it consistent and have it be built into Swift (a small Component) to show price savings based on the difference of the two.

Best Regards,

Nuno Aguiar

Hi Nuno,

We ended up with this solution because DbPrice was not always accessible while a ProductField is easier to access.

Our case could be simpler than yours.

Adrian