Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase scale on pre tax amount #459

Merged

Conversation

jhawthorn
Copy link
Contributor

Commits from @mamhoff in spree 3.0 which increase the scale on the pre_tax_amount columns.

Needed for #440

mamhoff and others added 2 commits October 21, 2015 14:25
The `pre_tax_amount` column is used when calculating VATs. When the
precision is too low for this field, rounding errors occur.

For a line item with a price of 4.92 $ and a tax rate of 17%, the
calculation has to go like this:

```
4.92 / 1.17 = 4.205128205128205
line_item.save
-->
    pre_tax_amount: 4.205128205128205
    pre_tax_amount (rounded): 4.21
    included_tax_amount 71 ct.
    amount 4.92
```

Without this PR, whenever the line item is saved and reloaded, and then
the taxes are re-calculated, the calculation wrongly goes like this:

```
4.92 / 1.17 = 4.205128205128205
line_item.save
-->
    pre_tax_amount: 4.21
    included_tax_amount: 72 ct.
    amount: 4.92
```

That's an error: `4.21 + 72 != 2.92`.

This should not affect any display_* methods, as those use
`Spree::Money`, which takes care of good rounding.

Fixes #6472
On existing installations, the migrations `IncreaseScaleOnPreTaxAmounts`
will fail because of existing shipments not having a `pre_tax_amount` set.

Fixes #6525
Fixes #6527
@jhawthorn jhawthorn added this to the 1.1.0 milestone Oct 21, 2015
# set pre_tax_amount on shipments to discounted_amount - included_tax_total
# so that the null: false option on the shipment pre_tax_amount doesn't generate
# errors.
#
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we do this with a

Spree::Shipment.where(pre_tax_amount: nil).update_all('pre_tax_amount = (cost + promo_total) - included_tax_total)

rather than the exec? its a nit-pick but will ensure right table names or whatever are used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer what is there. This is a migration, where the table names are already hardcoded.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming that IS the name of your spree shipments table...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been going back and forth these days on whether to use SQL or to use AR for migrations. For me, I would have done:

Spree::Shipment.where(pre_tax_amount: nil).find_each do |shipment|
  pta = shipment.cost + shipment.promo_total - shipment.included_tax_total
  shipment.update_attribute 'pre_tax_amount', pta
end

This way its all inside of AR and none of the callbacks happen; I think. If the table name may change, then maybe:

class Shipment < Spree::Base
  self.table_name = 'spree_shipments'
end

Shipment.find_each do |shipment|
  ...
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look two lines lower in this file the table name is also hardcoded. Table names should be hardcoded in migrations, we don't want migrations to change behaviour.

SQL is always preferable to AR in migrations for the same reason.

@cbrunsdon
Copy link
Contributor

Yea this one is 👍 by me.

Also, BEDMAS.

@athal7
Copy link

athal7 commented Oct 26, 2015

👍

jhawthorn added a commit that referenced this pull request Oct 26, 2015
@jhawthorn jhawthorn merged commit dcfb791 into solidusio:master Oct 26, 2015
@jhawthorn jhawthorn deleted the increase_scale_on_pre_tax_amount branch October 26, 2015 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants