Shippingcost calculation doesn't take PriceAdjustments into account

[ipsisPuckHolshuijsen]

Describe the bug
I've got a fixed rate shipping provider setup, which should add 25 euros (excl. vat) to an order when the subtotal is below 800, and should be free when above that amount.
The issue I am having, is that I've got bundled orderlines, and those underlying orderlines can get extra PriceAdjustments added to the TotalPrice.Adjustments.
It looks like the shipping calculation is not taking the adjustments into account.

So what I've got:
Total orderline amount without adjustments is 646,28 excluding vat, and 782,00 including vat (21% vat).
With the adjustments however it is 891.28 excluding vat, and 1.078,45 including vat (21% vat).

During checkout I am showing the possible shippingoptions with their costs, this is going great (shows free), which is calculated like this:
item.ShippingMethod.CalculatePrice()

The order shippingcosts however show the 25 excluding vat - 30.25 including vat:

Steps To Reproduce
Steps to reproduce the behavior:

1. Add a bundled product to the cart which has a TotalAmount that is below the shipping threshold
2. Add a PriceAdjustment to the TotalPrice of an underlying orderline, which should put the TotalAmount above the shipping threshold
3. Check the ShippingInfo inside the current order

Expected behavior
I was expecting to see a free shippingcost because the subtotal (with all adjustments) of the order is above the threshold

Screenshots
Shippingcost setup

Additional context

I am using the Checkout package

Umbraco Commerce version:

Installed Version
Umbraco.Commerce v13.1.12
Installed Payment Providers
Invoicing v13.1.12
Zero Value v13.1.12
Mollie (One Time) v13.1.1 (hotfix - preview 2)
Installed Shipping Providers
Basic v13.1.12

[mattbrailsford]

Hmm, this is pretty strange because in theory the item.ShippingMethod.CalculatePrice() should go through the exact same process as the order calculation process so it seems odd it's producing differing results.

Let me see if I can setup a similar environment

[mattbrailsford]

Ok, so I think I know what the issue is, but it's going to be a bigger problem to solve. I might have a workaround for you though.

So the problem appears to be in our calculation flow, we work out all prices initially without adjustments, and then we work out the adjustments and work out an adjusted price. The problem is, the shipping calculator runs during that first step when calculating all prices without adjustments and so when it does it's calculation it does so without adjustments yet applied. The reason this works for the shipping methods page however is because that process isn't mid calculation and so it uses the current order as it's data source, which already has the price adjustment on and so is correctly taken into account.

I think the solution to this might be to adjust the calculation flow such that we calculate all order line rows with and without adjustments, then the sub total, then the shipping, then the payment method, and then the total. But that's a big change to the flow so will need some thorough testing.

As an interim workaround, I think the following will work. When calling AddUmbracoCommerce add the folloiwing

builder.WithCalculateOrderAdjustedPricesPipeline()
    .InsertBefore<CalculateOrderSubtotalPricePreviousAdjustmentsTask, CalculateOrderSubtotalPriceWithoutAdjustmentsTask>()
    .InsertBefore<LimitOrderShippingTotalPriceAdjustmentsTask, CalculateOrderShippingTotalPriceWithoutAdjustmentsTask>()
    .InsertBefore<LimitOrderPaymentTotalPriceAdjustmentsTask, CalculateOrderPaymentTotalPriceWithoutAdjustmentsTask>()
    .InsertBefore<CalculateOrderTotalPricePreviousAdjustmentTask, CalculateOrderTotalPriceWithoutAdjustmentsTask>();

This will add the tasks that calculate the prices without adjustments into the same pipeline that calculates the adjusted prices, this way it recalculates the price again just before applying adjustments.

The thing to be aware of here though is the adjusted prices pipeline can get called several times. This should be fine if you are just using the dynamic shipping option, but if you used a realtime shipping option this would trigger multiple API calls that could slow things down or cause you to hit a rate limit.

[ipsisPuckHolshuijsen]

Good morning Matt,

Glad you figured it out!

Just tried the workaround and it works like a charm.
Luckily for us we are using fixed shippingcosts, which means it isn't a problem.

Thanks again!

[mattbrailsford]

As we've found a workaround, I'm going to close this issue, but I've started a feature discussion to keep the suggestion of changing the calculation process #665