I've been using Ubercart for quite some time now and I've run into a show stopping roadblock with one of my sites and it all revolves around shipping. I need to force my shipping methods and combine the price at the checkout instead of giving an option for the cheapest shipping method. Some products ship UPS, others ship freight. We drop ship everything, sometimes the same product from different sources and don't have any sort of physical warehouse. With that being said, the roadblock lies with the fact that since we ship some stuff UPS and other stuff freight, we need to be able to specify that a specific product will ONLY ship UPS or ONLY ship freight (or ONLY ship as a flat rate etc.) and then combine those shipping quotes, giving the final shipping quote at checkout. I've tried to find someone to make a contrib module for Ubercart but very few have stepped up to the challenge and I believe a lot of it has to do with the way the core of Ubercart is designed which doesn't allow for any other scenarios other than "Store has 3 shipping methods enabled, let's give the customer a choice from those three quotes". One option I've toyed with is setting everything to a flat rate but the problem is that some of our freight products will ship for $150 to one location and $350 to another. Sure, I could average out the shipping, making more on some orders and less on the others and "hope" that it all comes out in the wash but this isn't really the best practice for a business that is trying to make money... The other option is to set the flat rate to the highest possible shipping price but this doesn't present a fair scenario to the folks in areas where shipping should be considerably less... To make matters worse, shipping prices, as you might know, change daily. If I set a flat rate shipping for a product to $200, it might end up being $250 in three months which means I then have to go change the flat rate shipping price on 200+ products every few months? A maintenance nightmare.
I won't ramble on any more with my frustrations and instead dive into my proposition of how I think the shipping should be approached for Drupal Commerce, since at this point, the shipping is in it's infancy and hasn't quite evolved yet. I am generating this as a feature request in hopes to get some feedback from others in the community who need the shipping to be a much more powerful and robust to encompass almost any scenario of shipping instead of the "typical" methods of shipping like Ubercarts current approach.
Store Shipping Level
At the store shipping level, the shipping methods should be turned on and off, similar to how Ubercart is done. I think this approach is pretty straight forward and doesn't need much changing. The one difference being a set radio option to offer:
- All shipping is the same for all products. Provide customer option for their prefered method of shipping at checkout
- Shipping methods are in a mixed mode. Sum Total / Combine all shipping quote prices upon checkout
Product Level
At the product level, you should be able explicitly apply the shipping methods for that individual product. Ubercart currently inherits and applies all of the shipping methods that are applied, then you have to fine tune them through conditional actions / rules which makes it a pain to cross reference product SKU's against the shipping methods you want to use.
I think the shipping method should be specified at the product level itself. When a product is created, you specify how it's going to ship. If you have three methods and you want all three methods applied, then you put a check next to each of the methods you want. If you only want that product to ship UPS, then put a check next to UPS.
Product Content Type
At the product content type level, you can specify the default shipping methods that all products will inherit upon their creation. If you want all products to ship UPS, FedEx and USPS, you can tell it at this level to make all products inherit those types. If each product is going to be a case-by-case basis, you can uncheck them all and specify it yourself when the product is created.
Batch / Bulk Operation
Some of you might look at the "shipping at the product level" to be rather daunting when dealing with a site of more than 100-200 products. I would also be annoyed at trying to maintain the individual shipping for products of a large site as well, which is why I believe this can be easily and completely eliminated by the use of a bulk operation "view" for the shipping methods. Provide a table of the product titles, SKU's and current shipping method. If you want to apply a new / different shipping method to all of the products, or a handful of products, it could be done with a few check boxes within a matter of minutes.
-----------
I will say that one problem I have no idea how to work around, is specifying how a UPS product is going to ship (Ground, 3day, Next Day Air etc.) presenting the customer with that option, then also combining in the freight quote or flat rate with it. I think that more information should be presented to the customer at checkout, detailing how the individual products will be shipped to help avoid confusion and clarify that producs a, b & c will ship UPS ground whereas products x, y & z are going to ship freight.
At this point, this is a rough draft of what I believe could be a more encompassing workflow to the shipping problems that many of us have run into. If this is completely out of line, feel free to let me know; if I need to post this somewhere else, let me know; if you think this is spot on and would love to see this type of workflow implemented, post your support and let the dev's know! If you have other suggestions or better ideas, let's get some discussion going!
Comments
Comment #1
eclipsegc commentedSo... that was some light reading ;-)
TR and I are beginning to work in this space a bit. Nothing specifically working yet, but beginning to try to get a shipping framework that these sorts of features can hopefully be extracted from. This is all sandbox, unsupported and non-working at the moment, but if you want to follow along:
http://drupal.org/sandbox/eclipsegc/1183870
Lots of good ideas in your post, I'll be referring back here a bit.
Comment #2
googletorp commentedNot thinking about the technical difficulties in doing this, have you thought about to present this to users. It almost sounds like they need to select a shipping method per line item. Wont this make shipping selection more complicated for the end users than need be. How will they figure out what shipping combination is best for them?
I've had something similar with multiple shipping methods used with commerce for a while, but ended up making it more simple in favor of an increased convert rate. For a site selling wholesale, I can see how something like this can be useful, but I have a hard time seeing how present this for end users in a way that's simple, transparent and easy.
Some times it's a good idea to trade flexibility for simplicity. While I don't think we should handle shipping in a way that disallows this, I'm not sure that we should aim for this either. You could probably come a long way with a custom module, fields and rules in order to make something like this.
Comment #3
mustanggb commentedLots of the solutions mentioned here would have helped me in the past
Another thing I would like to be able to do is specify site-wide whether or not shipping is VAT chargeable
Comment #4
dirtysteak commentedI've made a couple of suggestions here: http://drupal.org/node/962948#comment-4793024.
In short, the ability to add and fill multiple box sizes (based on product dimensions) and to specify product warehousing locations
Comment #5
rszrama commentedMoving this to the Commerce Shipping queue. I think you'll find that the way I've restructured the module in the 2.x branch will work well with your proposals. I haven't applied them in detail to the current code, but I do appreciate the write-up!
Comment #6
googletorp commentedCleaning up the issue queue.
If there is more to this please reopen. Closing this to remove clutter and since 2.x should "fix" the issues addressed here.