At present Ubercart provides options for cost and price differentials per option. My client would also like a shipping price differential per option: some options are more expensive to ship than others. The weight differential is nice, but we're using flat rate shipping, so rather than a weight differential, we need a ship price differential.

See attached image that I hope outlines what I'm talking about. So I'd like to replace "Weight" in the last column with "Shipping".


ship-differentials.png43.73 KBjoegml


joegml created an issue. See original summary.

TR’s picture

Version: 8.x-4.0-alpha4 » 8.x-4.x-dev

Here's a thought - if the uc_price field behaved like a computed field, then you could write your own function to compute the flat rate price per product using the flat rate override field, using any variables (attributes/options/etc) that you want. This would have additional benefits because then the product price could also be computed with a function. To do that now (in D7, not yet available for D8) requires the custom price module and the attribute tokens module. This could be the perfect thing to provide an algorithmic pricing API.

The problem with adding a column in addition to cost, price, and weight, is that there will always be a use case for some other variable to be added - we can't build an extensible system by including EVERYTHING in that adjustments table. But we do want the ability for you to be able to add whatever you need without the very heavy-weight solution of one entity per SKU.

joegml’s picture

@TR I guess I see your point. The flexible approach with function definition would be great.
Agreed that one SKU for each option is too much!
We can't be the only ones that need this. Our use case isn't that far out there.
For now we can repurpose on of cost/price fields as we have that info elsewhere. I hope that as D8 develops we'll have another option.
Thanx for all your work on Ubercart!

splash112’s picture

Have been away from Ubercart development for a while, but would making options fieldable not be a good starting point?