-
-
Notifications
You must be signed in to change notification settings - Fork 729
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
[Vouchers] Percentage rate #10821
[Vouchers] Percentage rate #10821
Conversation
New commit start here: 28b3163 Admin screen and Calculation are done.
TODO:
|
From @mkllnk on slack :
This sounds like the long-term solution that also works with calculating tax adjustments for mixed in-ex-cluded taxes. |
This is unblocked now since #10761 has been merged. |
4fb198c
to
2a85ddc
Compare
2a85ddc
to
60b4b0c
Compare
Reviewers new commit starts here b461dfd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIP - didn't finish the review. I'll continue tomorrow.
@@ -1439,7 +1439,7 @@ def advance_to_delivery_state(order) | |||
describe "#voucher_adjustments" do | |||
let(:distributor) { create(:distributor_enterprise) } | |||
let(:order) { create(:order, user: user, distributor: distributor) } | |||
let(:voucher) { create(:voucher, code: 'new_code', enterprise: order.distributor) } | |||
let(:voucher) { create(:voucher_flat_rate, code: 'new_code', enterprise: order.distributor) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could have kept the voucher
factory as an alias for specs which don't care.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. I have a few comments but nothing blocking this.
385d087
to
85e1387
Compare
|
b04be5f
to
cc75d36
Compare
New commit starts here cb54397 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice refactoring!
I have some comments but nothing blocking the delivery of this part.
def compute_amount(order) | ||
percentage = amount / 100 | ||
-percentage * order.pre_discount_total | ||
rate(order) * order.pre_discount_total | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should add compute_tax_amount
to the model as well... or take this out of the model. But then this is to comply with the originator interface of the Spree adjustments, right? Nevermind...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the compute_amount
is there to comply with the originator interface, see CalculatedAdjustments
concern. That said, I believe voucher adjustments are decoupled from other adjustment lifecycle, so I think we "should be able" to take it out of the model.
case params[:voucher][:voucher_type] | ||
when "Vouchers::FlatRate" | ||
@voucher = | ||
Vouchers::FlatRate.create(permitted_resource_params.merge(enterprise: @enterprise)) | ||
when "Vouchers::PercentageRate" | ||
@voucher = | ||
Vouchers::PercentageRate.create(permitted_resource_params.merge(enterprise: @enterprise)) | ||
else | ||
@voucher.errors.add(:type) | ||
return render_error | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could constantize
the type string after checking it against the known types. Maybe worth if we add more types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something like ?
voucher_types = ["Vouchers::FlatRate", "Vouchers::PercentageRate"]
if voucher_types.include?(params[:voucher][:voucher_type])
@voucher = params[:voucher][:voucher_type].constantize.create(permitted_resource_params.merge(enterprise: @enterprise))
else
@voucher.errors.add(:type)
return render_error
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc75d36
to
7e2b104
Compare
7e2b104
to
e803980
Compare
We need to wait on this #11117 before merging, but yes we can create issues for the remaining problems. It'd be good to at least fix the error 500. |
I have a fix for the 500 error but I kept it on a separate branch, I think this is big enough as it is 😄 |
@rioug I have created the following issues as an outcome of this testing a discussion: |
It is important that the calculated voucher adjustments don't change if they are recalculated and it is equally important that they are updated if the order has changed
And update related specs voucher_type doesn't do anything for now.
Plus specs
It include calculation for order with taxes included in the price
Add calculation when tax is not included in price
Similar to tax included in price scenario, adds a test for percentage based voucher to check the adjustments are recalculated when needed. Plus fix tax incluced in price specs to use new factory
Refactor voucher to use a single table inheritance. It will simplify the code and remove a bunch of conditional
9e7e987
to
7a563cd
Compare
We are taking advantage of having a FlatRate and a PercentageRate model to simplify the code a little
We now check against known type to instanciate the correct voucher instead of using a case
Co-authored-by: David Cook <[email protected]>
Add explicit 'order.item_total' to make specs more readable
It triggers a Brakeman error that can be safely ignored
7a563cd
to
a2def24
Compare
Done ! Thanks for creating the issues @drummer83 ! |
ℹ️ Please track code review under the project
##10430 Vouchers - Aus Pt 2 (UK)
.What? Why?
Add the ability to have a percentage based voucher. It supports tax included in price and tax excluded from price to same extend that flat rate voucher ie. we can't have order which mix tax included and tax exclude from price.
See calculation reference here : #10432 (comment)
What should we test?
In the backoffice logged as an enterprise user:
--> It should redirect you to the vouchers page on the enterprise edit page
--> You should now see a list of vouchers with the one you just created, included the entered percentage rate
On the website logged as a customer :
--> You should see a "xx % Voucher" box where xx is the amount you entered when creating a voucher
--> you should see the voucher applied to the order in the order summary column, with the correct amount
--> you should see the voucher applied to the order in the order summary with the correct amount
Repeat the above scenario with tax included in price and tax excluded from price
Payment fees and voucher
Payment fees are calculated based on the item total, and are recalculated when confirming the order. Vouchers are calculated based on the order total. The main thing to check here, is to make sure :
See this #11117 (comment) for more background
Release notes
Changelog Category: User facing changes
The title of the pull request will be included in the release notes.
Dependencies
This is base on this PR #11117,
which depends on #11135. They will need to be merged first.Documentation updates