Working on the catalog import tool, I came to knwo that the List Price (Display) price is obselete in the latest release of 7.5. In the current version fo 7.5 I have the list price of a varaition and then the sale prices. Our requirement is to display the regular (list price) on the web page along with the sale price but the shopping cart will take the minimum sale price.
The question is how can we import the regular price along with all the sale prices into EPI Server commerce manager 7.5.
We are planning to use IPriceDetailService over Catalog Dto and the IPriceDetailService does not support a list price. We can still use the Catalog Dto that supports the list price but the fact that it is obelete tell us that EPI Server is not planning to support it going forward.
The concept of ListPrice and SalePrice is rather confusing. We're considering to improve the situation - with the possiblity of ListPrice removed.
For your question, let's me clear it a bit - by what criterias a sale price is defined? EPiServer Commerce supports ways to define a sale price - by a selected period of time, by a quantity of goods, by customer and/or special discount code, belongs with any combinations of above conditions.
Let's say for product A, the normal price is 100$, while a sale price will be 80$ for a quantity of 5 or greater, or 90$ for a selected time, you can can use IPriceDetailService for editing those prices (pseudo code, please refer to API documentation)
IPriceDetailService priceService = ServiceLocator.Current.GetInstance<IPriceDetailService>();
IPriceDetailValue price = new PriceDetailValue();
price.CatalogKey = new CatalogKey(...);
price.UnitPrice = new Money(100, Money.USD);
price.ValidFrom = DateTime.Now; //valid from now, we leave ValidUntil to null
price.MinQuantity = 0; //valid for all purchase
//Now create new price
IPriceDetailValue newprice = new PriceDetailValue();
newPrice.CatalogKey = new CatalogKey(...);
newPrice.UnitPrice = new Money(80, Money.USD);
newPrice.ValidFrom = DateTime.Now; //valid from now, we leave ValidUntil to null
newPrice.MinQuantity = 5; //valid for purchase with 5 or greater quantity
//Create another price
newprice = new PriceDetailValue();
newPrice.UnitPrice = new Money(90, Money.USD);
newPrice.ValidFrom = DateTime.Now.AddDays(1); //The price is valid for tomorrow only
newPrice.ValidUntil = DateTime.Now.AddDays(2);
Hope this helps.
Hi Quan, This all makes sense and add a little bit more into my knowledge about EPI Server pricing.
I our case, the existance of the sale price itself will define wheather an item is on sale or not. The current data structure of the pricing in EPI Server does not tell you wheather the price value you are retrieving is the regular price or the sale price.
SKU: 1234, Regular price: $10 : The website will display the price as Price: $10.
SKU: 5432, Regural price: $10, Sale Price: $5: The website will show both the prices where the regular prices is crossed out.
all other parameters (dates, currency, qty etc) of the price and sale price remains the same.
What is the best way to import this kind of data in the system and on the front end side to identify if there was a sale price present for the item. Can we name a price like(regular, sale etc)?
What we want is exatly as you have the price of the item on EPI Server demo site, where it shows the list price, the sale price and the saving on the product details page.
Couldn't you do for all sku's listprice, use AllCustomer with no Sale Code and quantity 0.
And for the sale price either specifiy a salecode or a quantity.
The sale price is not conditional on any qty and sales code. It is just based on event. E.g. durning memorial day, everything is 25% off. The customer would like to display list price and a 24% off sale price on the website.
In your case a promotion seems to be better fit. Refer here for more detail: http://docs.mediachase.com/display/ecf51devguide/Custom+Promotion+Development+Explanation
In that case as Quan Mai says, the promotion would suit better.
I do not understand how the ListPrice can be obsolete, with the possibility of removal in v8.
BasePrice, aka ListPrice, aka MSRP, is standard in Retail and Ecommerce.
And MarkdownPrice, aka SalePrice, aka OnlinePrice, is also a common retail and ecommerce idiom. It is used at product EOL to help shift them from warehouse stock, or on low margin products to encourage up/cross selling of higher margin products. It can also be a general rulle for all the products on ecommerce websites. [the whole, $12.99 is what the MSRP is, but in our online store you get it for only $10.99.]
It is usually a very simple decimal attribute on the product along with the BasePrice.Promotional Pricing, supported by the very nice pricing engine you guys have, is a seperate and far more complicated beast alltogether. This is the whole, `buy product x in may and get a 10% order discount` or `buy two get one free`, type of business rule that is applied "soley" during the checkout process.
I could be getting confused here if you are simply changing the way the API can get at the BasePrice and the surrounding nomenclature, but on first blush your comments about the future of the Commerce pricing architecture is quite concerning.
With the raise of Markets, ListPrice - which has been there long before Market concept introduced, becomes irrelevant. As it's attached to entry level, you'll be unable to know which market it targeting - and which timeframe it's valid ... In some specific cases, it might be still useful, but for general, it's one old piece which need to be obsoleted in the favor of new price services - and new price services can archive what ListPrice can do with ease.
I would say the single ListPrice is coming to an end. With ECommerce sites going global with multi warehouse.
And the recommendeed retail price is different from region to region eventhough the same currency can be used.
With that you need a solution where you have a listprice per currency available in the market.
A product can have a different ListPrice sold in the US with USD than the same product sold in Europe still with USD.
All this is supported with pricing service used.
This makes a little more sense now.
So what you are saying you are moving towards a pricing engine that supports a standard ListPrice and SalePrice for each product per market per currency?
So I could use the service to grab these two different prices for a specified product for the current market and currency and then display them.
I guess this model also lends itelf to having different list price per usertype? [per market per currency per usertype]
Such as a list price for end consumer and a list price for businesses. [I had to do this in a java ecommerce system in '07 and it was so painful we ended up creating two seperate catalogues instead.]
How does EPI Server support the list price and the sale price per market, per currency? The price object does not have any identifier that says list price vs sale price.
How would the web page (front end) determine which one is which without any identifier?
If you know a workaround to achieve this, please share becuase that is what we are up to.
Keep in mind for specific timebased promotins as a Memorial Day sale, i would use the Promotion engine. Just like buy two of one product and get a third for free. The SalePrice isn't the price used when there is a sale, but a price used when selling product on your site.
The pricevalue entity used in can hold among other things:
How do you intend to use your listrpice only to show, or will you have a facet, and in that case what kind of search provider will be used.
The way i would do is to have one method GetSalePrice and on GetListPrice, in the StoreHelper.
I would create ListPrice's by creating prices with SaleType AllCustomer, SaleCode MSRP(or Similar), and the other fields according to market, price and currency.
In your methods for fetching prices i would then create an appropriate filter to fetch prices.
In the ListPrice, use AllCustomer with MSRP, the current currency and market.
For the frontend part, it depends on how you fetch the prices, with AJAX, i would have two fields in the return object one ListPrice and SalePrice. In MVC i would create a viewmodel for the product with one SalePrice and one ListPrice. And if you use webforms without ajax just call the methods from the codebehind or similar.
This solution is something i have used when developing an B2B site, where we showed the MSRP as info and the Sale Price is what the dealers bought the products for.
I am under impression that EPI Server picks the lowest possible price in the shopping cart?\
Can we override the price calculator module to chose the price value that we want (in further calculations like checkout, promotions etc)
The reason I am asking is that sometimes our clients have the contract pricing and sometimes that is greate than the sale price but at the same time the customer takes advantage of other benifits e.g. free freight etc by giving up the sale price.
Sometimes the cilent asks to apply the promotion discounts ton only the list price but not sale price and then pick the possible lowest price.
Is there a place in EPI Server where we can identify the workflow to caculate the final price?
You can add Activity in CartValidate and CartCheckout Workflows also to override prices