Prices feature overviewEdit on GitHub
The Prices feature enables Back Office users to set prices for products and manage them effectively.
To accommodate business requirements, there can be various price types. For example, a default price is a product’s regular price. An original price is typically used to show a product’s price before a discount was applied. The original price is displayed in a strikethrough font next the the default price.
Product types and price inheritance
Back Office users can set prices for both abstract products and product variants. When an abstract product has multiple product variants, you can set a price for the abstract product and different prices for each product variant.
On the Storefront, when customers browse catalog and search pages, they see abstract product prices.
When a customer opens a Product Details page, they still see an abstract product price.
After selecting a product variant, they see the variant’s price.
In some cases, you may want to set the same price for all the product variants. Then, you set the price for the abstract product and don’t set any for the variants. When the variants don’t have prices, they inherit the price of their abstract product.
Similarly, when there is one product variant, it makes sense to set the price just for the abstract product.
In the last two cases described, since product variants don’t have prices, customers see the abstract product price on all the Storefront pages.
Prices in database
Prices are stored as an integer, in the smallest unit of a currency. For example, for Euro prices are stored in cents.
Each price is assigned to a price type, like DEFAULT or ORIGINAL price. For a price type, there can be one to n product prices defined. Price type entity is used to differentiate between use cases. For example, you can have DEFAULT and ORIGINAL types to use for sale pricing.
The price can have a gross or net value which can be used based on a price mode selected by a customer on the Storefront. You can have a shop running in both modes and select the net mode for the business customer, for example. Price also has currency and store assigned to it.
Price retrieving logic
If a concrete product doesn’t have a price entity stored, it inherits the values stored for its abstract product. When fetching the price of a concrete product, the price entity of the respective concrete product SKU is checked. If the entity exists, the price is returned. If not, an abstract product owning that concrete product is queried and it’s price entity is checked. If it exists, the abstract product’s price is returned for the concrete product. If it does not exist an exception is thrown.
The following diagram summarizes the logic for retrieving the price for a product:
Related Business User articles
|OVERVIEWS||BACK OFFICE USER GUIDES|
|Volume prices||Define prices when creating abstract products and product bundles|
|Edit prices of an abstract product|
|Define prices when creating a concrete product|
|Edit prices of a concrete product|
Related Developer articles
|INSTALLATION GUIDES||GLUE API GUIDES||DATA IMPORT||TUTORIALS AND HOWTOS||REFERENCES|
|Install the Prices feature||Retrieving abstract product prices||File details: product_price.csv||HowTo: Handle twenty five million prices in Spryker Commerce OS||Money module: reference information|
|Install the Product Price Glue API||Retrieving concrete product prices||PriceProduct module details: reference information|
For submitting the form