Broadleaf Microservices
  • v1.0.0-latest-prod

Order Operation Release Notes for 1.8.12-GA

Table of Contents

New Features & Notable Changes

  • 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.