Order level adjustments break re-reporting an order

[Noah-Silvera]

If you try to make an order level adjustment and then a new payment to process a refund for an order, the system will try to do two things

1. Create a 'refund transaction' with the amounts of the entire order
2. Create brand new transaction with the new order amount

However, order level adjustments are not taken into account when reporting the total order amount to Taxjar. This causes Taxjar to throw an error when trying to report the new amount.

This is because order level adjustments are not compatible with tax - creating an order level adjustment will not adjust the total tax collected. For this reason, we can't even split the amount of the order level adjustment between items.

To get the correct totals with the order level adjustment, we would need to convert the order level adjustment to individual line item adjustments and recalculate the order and tax.

[jarednorman]

It's not really a bug... we added a configuration option so that people can provide a calculator that allows people to implement the behaviour that they want. The reality is that no behaviour we do here will actually be "correct".

[Noah-Silvera]

Yeah I agree... the tricky bit is that this will currently break the default refunding behavior with no feedback.

We may at least want to display a clear message to the user about what happened and why and direct them to implementing their own behavior.

[Noah-Silvera]

Something to double check - We need to make sure we are using the discount_calculator config option in the create_transaction_params that are being sent using reporting

[Noah-Silvera]

Something to double check - We need to make sure we are using the discount_calculator config option in the create_transaction_params that are being sent using reporting

Update: This has been checked.

1. When creating a new transaction on taxjar, we use the line_item_params method to generate the params, which in turn uses the transaction_line_items_params method, which uses the configurable discount_calculator

   • solidus_taxjar/lib/super_good/solidus_taxjar/api_params.rb

     Line 136 in 3f6ae12

     discount: discount(line_item),

2. The refund_transaction_params params do not use the discount calculator config option, but this is actually ok and expected.

   solidus_taxjar/lib/super_good/solidus_taxjar/api_params.rb

   Line 61 in 3f6ae12

   discount: line_item.discount * -1,

   • A refund transaction should refund exactly the order that was posted to TaxJar. Therefore, all it has to do is negate the discount that was originally sent to taxjar (and calculated with the custom calculator).
   • However, future work (Handle refunding an order that has never been reported to Taxjar #162) will need to use the custom calculator for discounts because it handles a scenario where no order exists on TaxJar to negate.

[Noah-Silvera]

Closing in favour of #180 which describes implementing the error reporting and preventing the creation of a REFUND transaction without a corresponding CREATE transaction and getting TaxJar in a bad state.