Rounding issues with refunds/returns

[niedfelj]

It seems like in this pull request, the field precision/scale was changed for returns:

#5043

This can't be changed like that without changing the scale on ALL db amount fields (or properly figuring out how to round everywhere), as calculations now after a refund will show an order total of something like, $50.1348 with payments of $50.13 and then the order updater says that a balance is due. If spree is going to switch to a scale of 4, it needs to be coordinated across the system/db.

[JDutil]

I believe there was also a related tax calculation rounding issue as well:
#6137

I think the proper solution here would be to change scale to 4 everywhere, and ensure we properly round for display methods.

[niedfelj]

Well, I guess the problem with changing to scale 4 everywhere, still requires that rounding to 2 is figured out for payments/totals etc, since we can't really charge to 4 decimals. I think the bigger problem, as it relates to the refund code, is mainly in the default calculator being used. It's trying to figure out refunds based on dividing line item counts, total items in order, adjustments etc. The longer term fix, IMO, would be to have every inventory_unit know its tax amounts, adjustments etc, because then refunds don't need to be "calculated" in the sense that the calculations should have been done already. This has primarily been a problem for us in applying some sort of editor/employee discount on an order that is not uniform (say one item is 40% off, one is 10% off) and the system has no way to "reverse" it. The simple solution for us right now has been to change the scale back to 2 and then added a round(2, :down) on the DefaultRefundAmount calculator so at least the "in memory" calculations align with the db:

    (weighted_order_adjustment_amount(return_item.inventory_unit) + weighted_line_item_pre_tax_amount(return_item.inventory_unit)).round(2, :down)