Radio Vs. Checkbox

philsward's picture
Offline
Joined: 09/15/2007
Juice: 136
Radio Vs. Checkbox

Hi Alexpz,

The module by design, uses the radio buttons to select a shipping method for a product, to force a single option of shipping for that product. When it combines them, if you have 3 products that are UPS, the customer chooses how they want the UPS to ship. If two products are FedEx, they get to choose how those two FedEx products ship.

I have a feeling that if we setup a product to ship through multiple avenues, it would create a lot of confusion at the checkout for the customer unless a lot more work is done to the existing structure. For example, you give the customer a choice between UPS & FedEx on product 1, but you force UPS on product 2. When the customer gets to the checkout, they are now presented with a UPS delivery option that must be forced for Product 2, but optional for Product 1. If they choose UPS for both products, no worries, but if they see a choice between both methods for Product 1, but then see that Product 2 is UPS only, it might get kinda confusing for them. You could lump all like shipping methods together, that way they could choose the delivery option, but then you would have to give them a choice between UPS or FedEx. If it were me, I would look at it and go "Why did I just choose a delivery option for both, if now I have to choose if I want one or the other?" I think the end result workflow would turn out to be a bit of a nightmare unless a lot of time and thought is put into it.

Since I don't personally develop the module (I pay to have someone work on it) I can only really afford to make updates when I need them done. However, davidarthur is working on getting the module over on drupal.org so we can start collecting a list of bugs / feature requests that can be implemented when I have things done, or we as a community collect enough to have the developer implement the changes.

----

In your scenario mentioned above, I too am running into a similar situation with some of our product. To ship a quantity of 1 would cost the customer ~$50 in shipping (heavy stuff...) but if I ship 2, the shipping for both would be closer to ~$80. If I ship a quantity of 3, the shipping would be around ~$120. Basically, my question to you is: "Can you break down the shipping and include the shipping into the options?" The other alternative might be to break the product out into two different pages. One being "Product 1 Qty 1 - 4", Product 1 Qty 5 - 10", Product 2 Qty 1 - 8, Product 2 Qty 9 - 16

I think what we are going to do in our situation, is use the "options / attributes" to denote the sell price (included shipping) for each quantity of product, instead of using the default ubercart quantity field. (This would pose other problems, but I think overall it will work fine)

Example:

Product 1 base sell price: $100 (shipping flatrate = $0.00):
Option:
Qty 1 x widget: $100
Qty 2 x widget: $180
Qty 3 x widget: $270
Qty 4 x widget: $340
Qty 5 x widget: $400

If you want a quantity that is more than 5, please call in for a custom freight quote!

With this scenario, if they were to choose option 2, at $180, then add to cart a quantity of 2, their total would be $360 (This is where the problem lies...) However, if they choose option 4 and add to cart as a quantity of 1, they get charged the correct amount of $340.

In your situation, you could do:

Product 1 Base Sell Price: $31.90 (base sell price: $20 / shipping flat rate: $11.90)
Option:
Qty 1 x Bottle: $31.90
Qty 2 x Bottle: $51.90
Qty 3 x Bottle: $71.90
Qty 4 x Bottle: $91.90
Qty 5 x Bottle: $135.70
Qty 6 x Bottle: $155.70
(etc.)

Ubercart unfortunately wasn't really designed for situations like ours (which is why I had the combine shipping module built). However, Drupal Commerce, being a ground up re-think / re-write, "should" accommodate for just about any situation we might run into. Eventually, Ubercart will merge into Drupal Commerce. The hope is by D8, but I have a feeling it won't be until D9...

Ubercart Combine Shipping By: philsward (41 replies) Mon, 08/29/2011 - 13:50