- v1.0.0-latest-prod
JDK 11 is required for Broadleaf release trains 1.7.0-GA, and beyond.
JDK 17 is supported for Broadleaf release trains 1.8.1-GA, and beyond.
Introduced logic in the DefaultCartPricingService to prorate the fulfillmentCharge of a FulfillmentGroup across all of its FulfillmentItems.
The proportions are dependent upon the bandFields of the PricedFulfillmentOption. Out-of-box, Broadleaf handles the following cases:
Single bandField of PRICE: The prorated charge will be proportional to the item price.
Single bandField of WEIGHT: The prorated charge will be proportional to the item weight.
Both bandFields of PRICE and WEIGHT: The prorated charge will be proportional to the average of the item price and weight ratios.
No bandFields values: The prorated charge will be calculated by the default method. Out-of-box, this may be QUANTITY or LINE_ITEM
This value may be used by the fulfillment splitting service in Order Operation services.
Only send product sku when variant is null to avoid duplicate price infos when calling PricingService
This can cause issue where the more than 1 price infos are sent back with the same sku, and one of them would have product-level pricing, causing the variant-level pricing to not be chosen
Skip pricing when retrieving product details via CatalogBrowse
When CartOperationService goes through AddToCart or UpdateItemInCart flows, it first grabs catalog data from CatalogBrowse, and then prices the items via PricingService. Since CatalogBrowse automatically hydrates product pricing when retrieving product details, it’s redundant, as CartOps prices them after anyways. Additionally, it causes an issue with formula based sale PriceLists, as the sale price first gets modified by the call to PricingService from CatalogBrowse, and then gets modified again by the call to PricingService from CartOperationService when it prices the items again, causing the sale price to be modified twice