- v1.0.0-latest-prod
Fixed an issue where the fulfillment (shipping) charges of a fulfillment group would always be split in half when creating a split fulfillment.
This was caused by the splitting service making assumptions on the OrderFulfillmentItem domain prior to the introduction of the Broadleaf FulfillmentServices.
The DefaultFulfillmentSplittingService now derives the shipping charges of a split fulfillment from the new proratedFulfillmentCharge field of OrderFulfillmentItem.
Fixed the issue where a failed attempt to consume CheckoutCompletionEvents via the CheckoutCompletionListener could produce duplicates of the order’s fulfillments when message processing is re-attempted. Instead, we now check if the fulfillments already exist, prior to creating them.
Fixed a check for taxes in InclusiveTaxHelper which would only determine if a tax was a fulfillment tax if the fullfillment tax name was exactly FULFILLMENT/SHIPPING/HANDLING. It now checks if it starts with the fulfillment tax name.
Set the OrderFulfillmentItem.merchandiseSubtotal from the OrderItem.subtotal when building the OrderFulfillmentItem.
Before it was calculated as unitPrice * quantity. This may produce a slightly inaccurate result if the unitPrice was adjusted, for example, by subtracting a percentage of the calculated included tax. In this case, the precision of the MonetaryAmount when using division (e.g. the unit price taking 1/3rd of the included tax) can cause the calculated unit price to be off by a penny when rounding.
Note: If broadleaf.orderoperation.ordergeneration.remove-vat-from-item-price = true, then OrderItem.subtotal will already have the included merchandise tax subtracted from it before the OrderFulfillmentItem.merchandiseSubtotal is declared.
Fixed an issue with rounding of the OrderFulfillmentItem#proratedFulfillmentCharge after split.