- v1.0.0-latest-prod
Added support for Retail Delivery Fees
Added support for mapping RDF attributes during Order & Order Fulfillment generation
Added support for fee amount capture & refunds in OMS
Added fees to the ReturnRequest
Populated the FeeRefund on the ReturnAuthorization from the OrderItems based on the fees included in the ReturnRequest
Include fee refund totals in the refund estimated totals
Ensure the fee is only refundable once, keeps track across all the order’s ReturnAuthorizations
Builds PaymentRefundPackages for the fees, and uses those when calling PaymentTransactionServices to issue refunds
For more information on Subscription Operation Service, please refer to the Subscription Operation Service 1.0.0 release notes.
Added support for provisioning Subscriptions & fulfilling subscription-based orders via the newly-created Subscription Operation Service. This support includes the following capabilities:
Processing subscription-related orders and order items.
Creating net-new Subscriptions based on orders and order items.
Splitting fulfillments based on the subscription items’s fulfillmentWorkflow
Managing subscription locks to avoid multiple processes manipulating the same subscription at the same time
Initiating subscription workflows based on the fulfillmentWorkflow and subscriptionActionFlow to fulfill each type of subscription action (create, edit, upgrade, downgrade, cancel)
|
Note
|
The environment variable broadleaf.subscription.enabled must be set to true to enable this support for Subscriptions in the Order Operation Service.
|
Return Authorization refunds can now be consolidated into a single transaction per payment.
When confirming multiple items for a refund, instead of executing a REFUND transaction per item, the item totals are aggregated and a single REFUND transaction request is sent to the payment gateways.
In order to support this feature, the TransactionExecutionRequest and similar DTOs have been modified to support multiple source entity IDs.
This consolidated refund flow is now enabled by default in the OMS.
To disable this flow, set the broadleaf.orderoperation.service.payment.consolidate-refund-transactions property to false.
Fixed RecordTooLargeException for large fulfillments by only using Order and OrderFulfillment ids for FulfillmentStatusChangeEvents
The AbstractFulfillmentStatusChangeHandler is updated to only emit Order and OrderFulfillment ids.
The FulfillmentStatusChange listeners are updated to read Order and OrderFulfillment by ids, to accommodate the new message payload that only contains IDs to avoid RecordTooLargeException for large fulfillments.
The listeners will still check for the full Order and OrderFulfillment payload in the message for the sake of backwards compatibility, but the logic is subject to removal in a future release.
Ensured ReturnConfirmedEvent is sent with a unique message idempotency key, fixing a bug where multiple quickly-submitted confirmations on the same return would not be successfully processed by consumers.
Fixed an issue where incorrect refund amounts were being calculated when refunding products with add-ons in quantities greater than 1 — updated the calculation of refund amounts to include parent Order Item quantity for dependent items such as add-ons.
Fixed an issue where building Order Line Items from a given Order was skipping the succeeding layer of dependent cart items (such as add-ons) — updated the logic to recursively build Order Line Items for all layers of dependent cart items, ensuring that all items are included in the Order Line Items list regardless of how many layers of dependencies there are.
Fixed an issue where a user could not refund the full remaining amount of an Order after overriding any item total to an amount exceeding its original amount during partial confirmation — the DefaultConfirmReturnRequestValidator was updated to check when the total to refund for items exceeds available funds especially when the total to refund is being overridden, and throw an appropriate error message to the user.
Additionally, the DefaultReturnConfirmationGenerationService was updated to use the overridden refund amount when calculating the remaining total refund amount for the confirmation, ensuring that the correct total refund amount is used when confirming a return with overridden item totals.
Updated existing and introduced new kafka bindings:
Added orderOperationsTaxHandlingOnOrderCreatedInput and orderOperationsVoucherCreationOnOrderCreatedInput for orderCreated topic
Added orderOperationsFulfillmentRefundTaxOnReturnConfirmedInput for returnConfirmed topic
Fixed FulfillmentRefundTaxHandler to subscribe to correct binding ReturnConfirmedFulfillmentRefundTaxConsumer.CHANNEL
Fixed VoucherCodeGenerationOrderCreatedListener to subscribe to OrderCreatedVoucherGenerationConsumer.CHANNEL
Fixed a bug where calculation of refund amounts didn’t include the parent order item’s quantity for Add-On Order Items, resulting in Add-On Order Items to only refund one quantity