Remove order-level adjustments from core Solidus

[jordan-brough]

Order-level adjustments are not first-class citizens in Solidus. Can we get rid of them?

Some of the problems:

• Taxes don't work correctly when they are present
• They have unexpected side effects for promotions. E.g. by default Solidus chooses one promotion to apply per line item, but in the presence of order promotions a single item can end up being discounted twice.
• They make analytics and attribution more difficult. E.g. if you want to know how much revenue a particular variant has brought in, you'll need to figure out how to divvy up order-level promotion amounts amongst line items.
• They make partial refunds more difficult. If you want to refund a customer for one item, you again need to divvy up order-level promotion amounts to figure out the amount to refund.
• If you have some items that are not discountable (like gift cards) the logic for determining how to divvy up order-level promotions has an additional complication

On the other hand, it does make conceptual sense for a store to say "Here's a promotion for $5 off a purchase of $30 or more", which sounds like an order-level promotion/adjustment. But a promotion like that could be stored in the DB as either:

• One -$5 adjustment on the order (order-level adjustment)
• Multiple adjustments totaling -$5 (the $5 split up amongst the line items)

The former feels more intuitive to me but the latter makes a lot of other things easier.

[jordan-brough]

Here's a few first ideas on TODO items for accomplishing the above:

• Reimplement Spree::Promotion::Actions::CreateAdjustment to generate line-level adjustments
  • @graygilmore is working on this in Distributed Amount Calculator #1949
• Allow having Admin adjustments at the line level (see Include all adjustments in ItemAdjustments in adjustment_total #1274)
  • @alexstoick did this in Calculating the adjustment total including null source adjustments #1933
• Update the admin UI so that manual admin adjustments are generated at the line level instead of the order level. This could involve providing a tool to automatically spread out a certain amount across an order's line items proportionally.
• Figure out what to do about existing order-level adjustments. Write a tool for migrating them? Continue to support but deprecate them? Move support into an extension?

[bbuchalter]

I agree this is a noble goal, but is likely a big breaking change for many, many stores. Would need to be part of a major version bump and a lot of care given to a sane upgrade path. Nonetheless, 👍 .

[jasonfb]

I wonder if there's a way to bridge the old-and-new paradigms:

An "order level adjustment" that looks to the customer & business as-if it is applied at the "order" level, but then there is a calculation of how much was discounted per line item.

In fact, I'd even go so far as to suggest two "promo_total" fields on the line items — One for the existing line-item adjustments, and a 2nd one that keeps track of the proportioned discount applied to this line item from the order-level adjustments. Then for the purposes of taxation & refunds, to get the "actual amount paid for this item", you take the line item's total minus the line item adjustments and then minus the proportioned adjustment from the order level adjustments.

Does that makes sense? That way, you have the best of both worlds: you keep order-level adjustments as a high-level concept, and bubble it down into a specific calculation for each line item for the purpose of taxes and refunds.

This way you can keep the high-level concept of order-level promotions (which are indeed critical to our marketing team) and just make relatively under-the-hood fixes to how taxes & refunds work.

Also FYI Avalara — widely used here in the U.S. — actually expects the full amount to be passed along with the discounts, and then it does the discount calculation itself. It does not expect that you pass the already-discounted amounts to them. Since I know of no jurisdiction in which the discounted amount is taxable (in all cases the discount reduces tax), this does not seem to have a functional purpose but I believe the purpose of this is exclusively for bookkeeping and reporting.

[graygilmore]

Just as a heads up, currently working on allowing TieredFlatRate to be using as a line item level adjustment as a part of #1812

[alexstoick]

Tackled one part of this in #1933

[jordan-brough]

An "order level adjustment" that looks to the customer & business as-if it is applied at the "order" level, but then there is a calculation of how much was discounted per line item.

💯

In fact, I'd even go so far as to suggest two "promo_total" fields on the line item

Hm, this adds some low-level Solidus complexity that I think would be nice to avoid unless we really need it.

Avalara — widely used here in the U.S. — actually expects the full amount to be passed along with the discounts

My understanding from working and talking with Avalara was that the line-level amount field is supposed to represent the discounted amount, not the full amount. And that the order-level discount amount is provided for convenience. (They distribute it amongst the line items)