We’ve launched 5 CS-Cart sites now and almost all of the issues we have revolve around live shipping quotes.
Previously the issue was that all products in the cart are put into 1 “box”. When the weight limit was reached, instead of splitting the products up into more than 1 box, it sent the “can’t ship this” message.
Then the magical upgrade came that allowed multiple products to go into a box. Great!
But, not practical. From what I can tell, they can only be grouped into a box with more of itself, meaning, if you buy 2+ of something you can group them together into one box. It doesn’t seem different products can mix into a box unless there are no box dimensions for that product, in which case they go into the “box” I mentioned above.
Here is an example of the frustration:
User buys 2 different, big products (with the same box dimensions set) and a tiny product (that has no box dimensions set). Both of the big products are the same size, and are both set to allow 2 to fit in a box. However, this order will result in 3 packages. This means the shipping charge will be astronomically higher than it should be and the user will simply go shop somewhere else. Bad.
Is there something I’m missing?
I feel as though there needs to be two different set of dimensions: product dimensions (which should replace the current “box dimensions” and “items in a box” on the shipping tab), and box dimensions (which would go into the global shipping settings – allow multiple box sizes). The cart would then select a box size that is just large enough to hold all of the products that are in the cart and do the shipping quote based on that (or split up accordingly if overweight or too much for one box).
Thanks,
Jack
I am having this same issue at the moment, does anyone know of a solution?
Trouble is that whatever scheme you come up with is going to have to be rules-based. I.e. you would have to calculate dimensionally what fits into each of the box sizes you support. I’ve seen some algorithms for this, but invariably they are based around one person’s needs. It is extremely difficult to create the algorithm for one-size fits all (or many).
Do you have any suggestions on what the rules could be that would account for CD’s and lampshades? Seems like you can always cram in another CD but lampshades are a bit fussier.
[quote name=‘tbirnseth’]Trouble is that whatever scheme you come up with is going to have to be rules-based. I.e. you would have to calculate dimensionally what fits into each of the box sizes you support. I’ve seen some algorithms for this, but invariably they are based around one person’s needs. It is extremely difficult to create the algorithm for one-size fits all (or many).
Do you have any suggestions on what the rules could be that would account for CD’s and lampshades? Seems like you can always cram in another CD but lampshades are a bit fussier.[/QUOTE]
Yes, I agree. However, I think this could easily be remedied with the item dimensions solution I’m suggesting. If you know the dimensions of each individual product and know what sizes of shipping boxes are available to put products into, you can get MUCH better shipping quotes.
[QUOTE]If you know the dimensions of each individual product and know what sizes of shipping boxes are available to put products into, you can get MUCH better shipping quotes.[/QUOTE]
The additional dimensional details would be quite useful for rating/utilyzing Priority Mail “Flat Rate boxs”, however, IMO it is serious overkill and not really needed for standard parcel shipping via UPS, Fedex. We don’t have any problems obtaining very accurate realtime shipping rates with UPS in 2.1.4. Our shipment weights are all over the board from flat rate letters to several thousand pounds.
I believe the addition of product dimensions (as well as carton dimensions) would create far too much complexity both from the administrative side in having to add all of these product & package dimensions (could you imagine determining/adding all of the dimensions for a store with hundreds or thousands of products) as well as the additional load on shipping calculations being performed in realtime for each rate call. And especially when you are returning rates from multiple carriers at the same time as we and many others will be doing.
[quote name=‘Struck’]The additional dimensional details would be quite useful for rating/utilyzing Priority Mail “Flat Rate boxs”, however, IMO it is serious overkill and not really needed for standard parcel shipping via UPS, Fedex. We don’t have any problems obtaining very accurate realtime shipping rates with UPS in 2.1.4. Our shipment weights are all over the board from flat rate letters to several thousand pounds.
I believe the addition of product dimensions (as well as carton dimensions) would create far too much complexity both from the administrative side in having to add all of these product & package dimensions (could you imagine determining/adding all of the dimensions for a store with hundreds or thousands of products) as well as the additional load on shipping calculations being performed in realtime for each rate call. And especially when you are returning rates from multiple carriers at the same time as we and many others will be doing.[/QUOTE]
So you would prefer to put each individual product (or multiples of one individual product) into it’s own box and give the customer a shipping quote that is much higher than the actual shipping cost?
Shipping in CS-Cart is broken for anyone that ships products together in one box.
[QUOTE]Shipping in CS-Cart is broken for anyone that ships products together in one box.[/QUOTE]
Interesting we do this every day, all day long, works like a charm & rates are extremely accurate… 
You need to revisit your settings as you are missing “something” in your interpretation or configuration.
CS-Cart staff has current documentation available for reading.
It’s only broken (actually it’s non existent) if you want to ship multiple different products (not multiple of the same product) in the same box.
I gave up and signed up for readyshipper. Great discounts for shipping too.