Ok so I understand product attributes, and specification attributes.
One thing i need though is a user changable field.
Example product table:
standard size
Width: 100
height: 100
depth:100
I would like the user to be able to change the width to what they need (say from 100-500)
any size change would incure a surcharge of say 50.
As far as i can find, there is no user editable attribute for a product i can use.
So whats the basic steps i need to create a new product attribute call it "editable field?"
User editable product field
MVP
- 580
- 4292
- 7/22/2014
- India
you can create width product attribute with control type drop down add all supported width with its price adjustment value so when user will choose appropriate width it will surcharge the price adjustment value
For Textbox control type you will not be able to set price adjustment so adding the dropdown and its value with price adjustment is one of the options to achieve your requirement
For Textbox control type you will not be able to set price adjustment so adding the dropdown and its value with price adjustment is one of the options to achieve your requirement
MVP
Certified Developer
- 558
- 6401
- 7/29/2011
- United Kingdom
If it's a fixed surcharge for any width then you could look at using a conditional attribute. So have a checkbox attribute called "Specify custom width" which incurs the surcharge when ticked and a textbox attribute which is conditional so only appears when the custom width checkbox is ticked.
- 45
- 235
- 10/21/2016
- United Kingdom
petemitch wrote:
Seems like a good option actually.
One other thing is that there are a number of products that require price adjustments every 100mm this isnt a fixed surcharge but a fixed rate that is applied per 100mm increase. This is why im thinking i will need to do a full customization.
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
If it's a fixed surcharge for any width then you could look at using a conditional attribute. So have a checkbox attribute called "Specify custom width" which incurs the surcharge when ticked and a textbox attribute which is conditional so only appears when the custom width checkbox is ticked.
Seems like a good option actually.
One other thing is that there are a number of products that require price adjustments every 100mm this isnt a fixed surcharge but a fixed rate that is applied per 100mm increase. This is why im thinking i will need to do a full customization.
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
MVP
Certified Developer
- 558
- 6401
- 7/29/2011
- United Kingdom
[email protected] wrote:
If it's just one dimension that varies the price and it's fixed to multiples of 100mm then you might get away with a dropdown that lists all the available options with their respective price increase.
If the dimension doesn't stick to fixed multiples or you need to vary 2 or more dimensions then I think it gets a bit more complicated. I'm not sure there's any one best practice but one thing I would say is that at some point your going to need to override some of the functions in the PriceCalculationService as your going to need the dimension based pricing to work in the cart/checkout as well as on the product page.
There are some threads in the forum about dimension based pricing including this one in the suggestions forum: https://www.nopcommerce.com/boards/t/16762/suggestion-enhance-product-attributes-for-selling-by-dimensions.aspx and a related work item on Github, but I don't think it's been started yet.
One other thing is that there are a number of products that require price adjustments every 100mm this isnt a fixed surcharge but a fixed rate that is applied per 100mm increase. This is why im thinking i will need to do a full customization.
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
If it's just one dimension that varies the price and it's fixed to multiples of 100mm then you might get away with a dropdown that lists all the available options with their respective price increase.
If the dimension doesn't stick to fixed multiples or you need to vary 2 or more dimensions then I think it gets a bit more complicated. I'm not sure there's any one best practice but one thing I would say is that at some point your going to need to override some of the functions in the PriceCalculationService as your going to need the dimension based pricing to work in the cart/checkout as well as on the product page.
There are some threads in the forum about dimension based pricing including this one in the suggestions forum: https://www.nopcommerce.com/boards/t/16762/suggestion-enhance-product-attributes-for-selling-by-dimensions.aspx and a related work item on Github, but I don't think it's been started yet.
MVP
- 580
- 4292
- 7/22/2014
- India
petemitch wrote:
I Agree with Pete.
By just reroute CatalogController or get views at plugin level won't work as you need to manage the priceCalcualation as well for every 100mm with its values.
if you don't want to handle or manage price calculation then one other way is by rerouting you can set the calculated price to ShoppingCartItem.CustomerEnteredPrice so it will use this as price of product on checkout.
but above you can use only if you don't want to manage prices at attribute level otherwise it will be complex stuff to manage all things at attribute level.
I hope you get what i am trying to say.
One other thing is that there are a number of products that require price adjustments every 100mm this isnt a fixed surcharge but a fixed rate that is applied per 100mm increase. This is why im thinking i will need to do a full customization.
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
If it's just one dimension that varies the price and it's fixed to multiples of 100mm then you might get away with a dropdown that lists all the available options with their respective price increase.
If the dimension doesn't stick to fixed multiples or you need to vary 2 or more dimensions then I think it gets a bit more complicated. I'm not sure there's any one best practice but one thing I would say is that at some point your going to need to override some of the functions in the PriceCalculationService as your going to need the dimension based pricing to work in the cart/checkout as well as on the product page.
There are some threads in the forum about dimension based pricing including this one in the suggestions forum: https://www.nopcommerce.com/boards/t/16762/suggestion-enhance-product-attributes-for-selling-by-dimensions.aspx and a related work item on Github, but I don't think it's been started yet.
I was thinking my new plugin, grab catalog controller, set up a reroute to use that. Grab tyhe view that adjusts price via a postback in js. And applie my changes there.
Only other thing was using filters to applie changes before after the methods are called, but as i need to also change the view i assume its better doing the re-route?
Whats best practice here or is there a simpiler way im missing?
If it's just one dimension that varies the price and it's fixed to multiples of 100mm then you might get away with a dropdown that lists all the available options with their respective price increase.
If the dimension doesn't stick to fixed multiples or you need to vary 2 or more dimensions then I think it gets a bit more complicated. I'm not sure there's any one best practice but one thing I would say is that at some point your going to need to override some of the functions in the PriceCalculationService as your going to need the dimension based pricing to work in the cart/checkout as well as on the product page.
There are some threads in the forum about dimension based pricing including this one in the suggestions forum: https://www.nopcommerce.com/boards/t/16762/suggestion-enhance-product-attributes-for-selling-by-dimensions.aspx and a related work item on Github, but I don't think it's been started yet.
I Agree with Pete.
By just reroute CatalogController or get views at plugin level won't work as you need to manage the priceCalcualation as well for every 100mm with its values.
if you don't want to handle or manage price calculation then one other way is by rerouting you can set the calculated price to ShoppingCartItem.CustomerEnteredPrice so it will use this as price of product on checkout.
but above you can use only if you don't want to manage prices at attribute level otherwise it will be complex stuff to manage all things at attribute level.
I hope you get what i am trying to say.