https://solidus.io logo
Join Slack
Powered by
So I've noticed inside of order taxation that if a...
# support
b
So I've noticed inside of order taxation that if a refund is sent out, it'll update the tax adjustments in a normal callback. But if there's been a change or something that could effect the tax amount to change, a finalized adjustment can get updated. https://github.com/solidusio/solidus/blob/main/core/app/models/spree/order_taxation.rb#L68 I think we should be blocked adjustments from being automatically updated after an adjustment has been marked as finalized.
Copy code
module Spree::OrderTaxationDecorator
  def update_adjustment(item, tax_item)
    tax_adjustment = item.adjustments.detect do |adjustment|
      adjustment.source == tax_item.tax_rate
    end

    if tax_adjustment.present? && tax_adjustment.persisted? && tax_adjustment.finalized?
      return tax_adjustment
    end

    super
  end

  Spree::OrderTaxation.prepend self
end
This is essentially what I'm doing atm to prevent tax adjustments from changing one there's a complete order/finalized adjustment. Would love feedback on this.
c
This comes up every once in a while 😅 My question would be, how would this work when you cancel and item and adjust it's amount to $0 after the order has been completed and adjustments have been finalized? The tax adjustment needs to be recalculated to account for the new line item amount of $0 so that the tax is correctly removed.
Similarly if a store has a flow where customer service can adjust items after the order has been completed, through a promotion or by creating an adjustment through the admin (currently those can only be order level) taxes need to reflect that change in the amount.
b
I think we should handle that explicitly in the unit cancellation. Not with automatic adjustments. I guess we could also just check on the adjustment that's finalized here and see if it's source has been cancelled.
If the store has a flow that adjusts items, then I think they should mark their adjustments as unfinalized.
Because if it's finalized: it's done. No more editing.
c
Yeah, there are definitely workarounds, like creating an additional adjustment to cancel the tax adjustment, I am just pointing out the reasoning why this is allowed to happen currently.
Anyone can un-finalize adjustments through the admin so that's definitely an option too
b
Yes, but it's explicit. The system can't automatically unfinalize an adjustment.
There's also the tell, don't ask. So if a unit cancellation is made, I think it should just make adjustments that negate the previous ones.
c
I think the 
finalized
language may be a bit confusing when it comes to tax adjustments specifically. I don't know if there are other types of adjustments that can be recalculated once finalized.
b
Also, what if an admin changes a tax rate or an API comes back with a different rate after the order has completed?
c
Yeah, there may have been an open issue wrt to that, it will be recalculated based on the current rate iirc
b
Then the payment state for a completed order could change when a user, say, ships the product.
It shouldn't be recalculated IMO since it's finalized.
And the customer isn't going to want to give more money than what was asked after the fact.
c
There needs to be a change on the order to trigger that, changing tax rates won't affect it
But yeah, it's a valid concern by all means
b
There could be a script that updates orders for something from a year ago.
I think we ran into that at Bevv.
c
Yeah, that's a bit out of scope imho, if you are modifying orders programatically, and recalculating them
b
I think that's within scope. It shows that taxes could be recalculated accidentally for completed orders.
c
Yeah, but that needs to happen when the item amount changes, right? So it's just a matter of how that is done, either by updating the original adjustment or creating a new adjustment. Solidus opts out to update the original, instead of having to tally up multiple tax adjustments.
I am not saying it's the correct approach, it's one approach.
Orders in Solidus are not immutable after they've been completed, so that's something to keep in mind.
b
A cancellation should negate the tax rate associated. That seems pretty simple. If the cart changes, then I can see the tax rates change as well. Essentially it should be a small set of features that can implicitly change a finalized adjustment.
👍🏼 1
c
For cancellations I think this could be pretty simple, by making the adjustment include the taxes as well. There may be other types of adjustment like promo/discount where that would not work.
b
That's a good point
c
I think your concern is very valid though, the current behaviour complicates things when the order is sync'd to external systems like ERPs because we do allow mutations to it after it's been finalized in a way that is hard to keep track of. I've definitely struggled with this on some stores.
b
Is there anything else besides taxes and promos that are created in solidus?
c
I can't think of any other types of adjustments
I guess the cancellation, not sure if that's a different type
b
Because promos seems like a different ballgame, but for taxes, it seems like we could keep it scoped to just trying to find how to have finalized respected.
There is an explicit call to update the amount of a tax adjustment. I wonder if there could be a flag to identify if finalized should be respected or not.
But managing cart for a completed order, we could do a subset. Unfinalize only the adjustments whose line items have been updated. Do not touch anything else.
Then finalize can remain acting as its own flag. We just unfinalize when appropriate.
This is complicated though...
Open in Slack
PreviousNext
Powered by