Feature Request: Make PriceAdjustments more deliberate and controlled

[seanrockster]

Which component is this idea for?

Umbraco Commerce (Core)

Describe your idea

Optionally add one or more adjustments when/where needed and not rely on a PriceAdjuster.

Context

First off, we use PriceAdjusters and rely on them for auditing purposes. However I have a situation where using a PriceAdjuster is causing a bit of friction and it would be better if they could be more deliberate, i.e. I can specifically add an adjustment when and where I need to rather than having the framework call the PriceAdjuster, repeatedly, when maybe its not optimal.

The site is a b2b, high traffic/volume clothing distributor with 1000’s of orders per day. Orders can contain a single line or 100’s of lines. Stock and price can be volatile and orders might linger for hours, days or even weeks. So, we need to ensure stock and price are correct in the cart immediately before the order is finalized (there is no stock allocation unfortunately, first order to hit the erp wins), and using a PriceAdjuster seems the way to go because we can have an audit of the change and we can also force the customer to acknowledge the change (you’d be surprised at the number of customers that checkout then complain they didn’t put product x in the cart).

One issue is the PriceAdjuster is call repeatedly. To check the stock and price we have to make several db calls and run business rules to get to the customer’s discounted (if any) price, times by 100’s of potential lines. None of this can be cached as it needs to be real-time data so the latency is very noticeable.

Another issue is we may need to make multiple updates and not just prices. I.e. Products may be discontinued and the lines need to be removed, stock can fluctuate which can affect back order status. So we need to potentially update, prices, stock quantities, order and orderline properties. And of course saving those changes causes the PriceAdjuster to run again.

Currently I’m updating prices in the adjuster and persisting the price adjustments as well as any other changes that must be made to a separate db table, and then make any non-price changes when customers view the cart. Making all the changes as an atomic operation would be safer imo and reduce the risk of leaving the order in an inconsistent state.

There are many events available but they seem to validating changes being made rather than validating the current state of the cart/order. Maybe an IOrderValidator or ICartValidator to make multiple order, property, line, line property changes in a single step.

Unless there is a better way??

[mattbrailsford]

That's a lot to try an get my head around, but just in relation to your last comment, wouldn't using the ValidateOrderSave validation event suffice? This runs before an order is saved allowing you to block the order being saved.

[seanrockster]

I'm looking at ValidateOrderFinalize to see if it can work.

[seanrockster]

It looks like OrderFinalizingNotification is past the point where I need to do my validation. Throwing an exception in the handler shows an error page with the payment provider url in the browser. For now I i'll skip price updates (spent far too much time on this) as its too problematic and do what updates I can where I need to. Possibly look at rebuilding lines for price changes.

I suppose the feature request still stands, it would allow adding adjustments only when i need them and keep the expensive updates in one place and at bare minimum. That or a .ValidateOrder() method/handler that can make sweeping changes to an order.

[seanrockster]

Or, a way to tell the framework to ignore adjustors when getting an order. I have to retrieve the current order in multiple components, api endpoints, controls etc, so if i could actually control when the adjusters are fired, that would be useful.

[mattbrailsford]

This is your own adjuster though right? So can't you cache it's output unless you see a specific trigger?

[seanrockster]

Yes but not sure what you mean by cache the output of the adjuster. However it has given me an idea, basically now i'm checking if the current request is the cart page, skip the adjuster's logic otherwise.