- v1.0.0-latest-prod
The Pricing Service provides dynamic, context driven prices. Price lists can be used to address a number of pricing related use cases. This section describes the key features of price lists.
Price lists have an active date range. Using date ranges provides support for … - Date bounded sales - Seasonal price lists
Price lists can be used to drive sale prices which can be specific item prices or formula based prices.
A price list can be setup with modifiers to control item prices. Prices can be modified using percentage, multiplier, or addition/subtraction operations.
Price lists can use the customer segment or account information to drive pricing. Common examples: - Loyalty member pricing - Employee discount pricing - Contract pricing to override prices for a specific B2B account
Price lists can be managed globally (at the tenant level) or at the application level. If you have application specific pricing, you can choose to manage all prices at the application level or you can manage all prices globally and then just manage the overrides at the application level.
When using sparse overrides, use a lower price list priority for the application so that the application prices take precedence over the global pricing.
A single SKU could be targeted by multiple price lists. The price list can have an optional priority which determines the order it will be applied in the case multiple prices apply.
The priority is per Price List Type. So, if there are two standard price lists that have a price for the same SKU and all context and customer rules apply, then the lower priority price list price will be used.
The Broadleaf admin provides the ability to make price list changes through the preview and approval workflows.
This service includes out-of-box import implementations.
Each of the different types of price data can be imported.
The import types are STANDARD_PRICE_DATA, SALE_PRICE_DATA, and CONTRACT_PRICE_DATA.
The corresponding specification implementation in ImportServices is PriceDataSpecification - each type of price data gets its own bean of this type, thereby resulting in separate specifications.
Key Components:
PriceDataImportBatchHandler is responsible for processing imports of PriceData entities into a PriceList
PriceDataConverter is responsible for converting input price data rows into PriceData instances
Price lists are always in a target currency that represents what value the amount refers to. There are two approaches for using price lists in multi-currency implementations.
It is common to maintain full price lists by country (or currency). In this case, use a context rule to restrict the price lists in play.
Another approach is to use currency conversion. In this case, price lists can be managed in a base currency with currency conversion being used to convert from the source currency to the target currency.
|
Tip
|
recurring and usage pricing are introduced with 2.1.0 of Pricing Services |
Other than maintaining a basic price for a product or SKU, we’ve also introduced the ability to configure more advanced pricing scenarios using Broadleaf’s Pricing Engine to manage different price lists which can be targeted and applied in certain contexts and to certain SKUs.
Specifically, you can now manage not only an upfront price, but also a recurring price as well as a usage base price.
The standard or Upfront price is meant to denote a price that is levied once typically at the time of checkout
A Recurring price is levied repeatedly for a configured period
A Usage price defines a base rate where the actual charge is calculated by usage events typically maintained outside of Broadleaf. The primary purpose of specifying this here is really for merchandising purposes to customers as well as providing a way to define the rate needed for downstream calculations and billing systems
Additionally, each of these pricing properties can be associated with a Pricing Term which may match a term defined on the Product. Again, terms are conditions under which this price is available to the customer. The key aspect being that the term associated with any advanced price must match terms that are specified and available on a Product.
|
Tip
|
Introduced with 2.2.0 of Pricing Services |
Adjustment price lists work in conjunction with other types of price lists to further modify the price of an item. This satisfies use cases such as markups or discounts where the price of a group of products needs to be altered without maintaining an entire price list or modifying an existing one.
An adjustment price list can be configured to target a specific pricing phase based on the PriceList#adjustmentPhase:
Standard
Sale
Standard and Sale
Contract
All
|
Tip
|
Introduced with 2.2.0 of Pricing Services |
Cost price lists adjust the base cost of a product that will be used by the Pricing Service, overriding the original cost defined on the product.
Costs cannot be applied globally to all products in one context. Instead, specific price data needs to be defined for each product whose cost needs to be overridden.
When Cost price data is found for a given product, other price lists that use cost as a basis for their price calculations will perform them on said overridden cost instead of the original cost defined on the product.
|
Tip
|
Introduced with 2.2.0 of Pricing Services |
Pricing Categories enable dynamic pricing configurations by allowing you to override the default costs or amounts defined in price modifiers.
Defined directly on the product, a pricing category acts as a tag that can be targeted by a pricing modifier formula. When you enable price modifications in a price list, you can provide a modifier amount override. The override will only take effect if the pricing category specified in the modifier matches the product’s assigned category.
The Pricing Service includes support for Fees, which is a new domain addition as of Release Train 2.3.0. Fees can be used to represent extra charges that customers incur from purchasing products or having services rendered unto them, such as Service Fees or Processing Fees.
By default, Fees are identified by unique codes and can be configured through several attributes to determine how to calculate them and when to apply them.
The method to use to get the basis for calculating the fee during cart pricing.
This is represented by the enum type FeeCalculationMethod.
By default, Fees use the cart subtotal (FeeCalculationMethod#CART_SUBTOTAL) to calculate fees.
The operation to implement when calculating the fee during cart pricing.
This is represented by the enum type FeeCalculationOperation.
By default, Fees can be configured to have a rate (FeeCalculationOperation#RATE) that represents a percentage of the configured Fee Calculation Method that will be computed to be the final fee amount.
Fees can also be configured to have a fixed amount (FeeCalculationOperation#FIXED_AMOUNT) that will require no additional computation to get the fee amount.
The attribute that determines if a fee should be applied to a cart before or after discounts have been applied. Since it is possible for fees to be computed using the cart subtotal, the application of discounts can affect the final fee amounts. As such, fees can be configured to be applied before or after discounts so that fees can more accurately represent the charges according to the products or services being purchased.
The application of fees onto a cart can be customized by updating Cart Operation Services to determine extra rules or conditions for them to be applied.
For more information on how the current flow for applying fees is executed, and how fees are being retrieved and computed, read the Cart Operations Pricing documentation, which includes the changes made to the Pricing Provider and Cart Pricing Service, and the new Fee Pricing Service that handles fee computation and application onto the cart.