Combined shipping option: Weight + price.

[toplakd]

As many regular users do not track github I will post the question here, to see if users would use such function for the shipping or not.

Copied from github:

As core already has option for shipping calculation per weight or per price, would there be an option to extend this even further by adding 3rd option which combines both?
3rd radio button - Billing: According to total weight and total price.

Table thbees_carrier/shipping_method currently uses value 1 for weight and value 2 for price based shipping.
So if there was an option to add value 3 for combined weight/price range shipping, no extra columns in table would be needed.

So for third option "According to total weight and total price" The weight ranges would be main ranges, which one could add in the bottom fields below as ussual, and price range would be Single option only "Total price From 0 to X" and if other price ranges are needed one can create new Carrier which has "Total price From X to Y" and so on.

Real world use:
1.You have a product, which weighs 2kg and is worh 50€/$, you can ship it with carrier that charges 10€ for 2kg package which they offer insurance to maximum 100.
2.You have second product, which also weighs 2 kilo, but its worth 300€/$ and you don't want to ship it with carrier which has only 100 insurance, but with the one who provides insurance up to 500.

This is where total weight/price option kicks in.
If 2kg AND 50price -- > carrier with 0-100 range
If 2kg AND 300price -- > carrier with 100-500 range

Attached picture of how this could look in backoffice:

Edited March 28, 2020 by toplakd

[haylau]

@dynambee had a module developed that helps with this. He was considering releasing but not sure if he did. Not quite the same, but it allows you to set a cart value over which the carrier is not available

[DRMasterChief]

I think some more variable shipping options are a good thing.  We are also looking for a combination for  'small lightweight items' with additional 'very heavy items'  and shipping costs will increase when such a heavy item is in cart  and/or there should be no free shipping then. 

[toplakd]

possibilitiesI see it like this:

For high value products also the shipping costs are higher as you want to insure it higher, even if weight is same as some cheaper product for which shipping costs less due to smaller insurance value. As one could create few weight based carriers which have different total price ranges like 0-99, 100-299, 300-1000 and each one would have its own weight ranges.

So once products are in cart, system checks what is total products value and total weight and throws out carrier that meets both criteria.

I have talked to datakick few days back, and he might look into it what can be done if he finds some spare time.

Currently there are 2 native options which are both good, but if we could combine both current options into new 3rd option that would open more possibilities.

Edited March 29, 2020 by toplakd

[toplakd]

Had some time today, so decided to play with Carrier controllers:

Added 3 additional fields into step 3 in carrier settings, together with 3 new columns in _carrier table.

Now I'm able to limit "weight based carriers" by total price range (min/max), or limit "price based carriers" by total weight range (min/max).

Everything works in backoffice and also in front office all values are respected, so if either value goes out of range, carrier is disabled. Only carriers which meet both criteria are shown.

The only thing where i could not find the solution, is to show currency sign on side of Minimum/maximum order value, as it currently shows only the ID (2 instead € or $ or XXX)  🙂

Edited April 1, 2020 by toplakd

[dynambee]

On 3/29/2020 at 5:50 AM, haylau said:

@dynambee had a module developed that helps with this. He was considering releasing but not sure if he did. Not quite the same, but it allows you to set a cart value over which the carrier is not available

I wanted to list it and a couple of other small but useful modules in the TB store for a nominal price, say $10.

Unfortunately the cost to list in the TB store is very high which makes it not financially viable for me to do so. I'd much sooner have a situation where I don't pay a yearly fee of hundreds of dollars but instead TB takes, for example, a 30% cut of the sales.

Not my decision to make of course, I can only say that I can't personally afford the high cost of entry.

Edit: And yes, the module I have does fix @toplakd's problem. Carriers are set up as usual with weight ranges. Then separately you set a maximum cart value for a carrier. If the cart value exceeds that amount the carrier is no longer available to the customer. The only caveat is that this module does NOT work for custom carriers added via separate modules. It only works for carriers you define using the standard TB shipping system.

Edited April 17, 2020 by dynambee

[toplakd]

My working solution allows minimum and maximum price limit setting for the carrier and is working as wanted.

 

Edited April 17, 2020 by toplakd

[dynambee]

2 minutes ago, toplakd said:

My working solution allows minimum and maximum price limit setting for the carrier and is working as wanted.

I'm glad you have a working solution. I don't personally have a need for minimum price setting as it's not a problem for me if someone wants to ship a cheap item with expensive shipping. I've seen it happen where people pay $20 in shipping for a $1 part because they need it immediately. The reverse however is a huge problem, I don't want basic untracked shipping used for shipments over about $30 in total value so I need a maximum value set for basic carriers.

What I actually ended up doing is creating carriers on a per-country basis (we ship everything internationally). This allows me to set different limits for different countries, or to completely exclude some types of shipping to some destinations. It means I have a couple hundred different carriers defined but they were created programatically so it's not an issue.

[lesley]

Personally I would say no to this. I know I have been away and my opinion might not be valued as much any more, but there would be problems trying this in a wide release. The main issue would be overlapping ranges, it would be hard to hedge against and give proper warnings. It could be done, but if you are using a table rate like this you do not depend on accurate data. What I mean is when you have a weight entered, but you are not passing that rate to an api, its just used in house. So it does not need to be that accurate. It can be totally wrong for all intents and purposes. You can just hedge the weight to and manipulate it to make carriers work how you want.

 

If something like this were to be added I think we would need a full fledged carrier debug system. Its something we talked about adding years ago, but with complications like this it would be helpful. Basically when turned on the system would list all of the non displayed carriers and the reason they are not displayed. Like: 

 

Carrier 1 (over weight)

Carrier 2 (outside of shipping zone)

Carrier 3 (price range)

Carrier 4 : $3.56

 

[dynambee]

35 minutes ago, lesley said:

Personally I would say no to this. I know I have been away and my opinion might not be valued as much any more

Hi @lesley, I'm sorry to hear you have been sick, and I hope things are improving for you.

 

36 minutes ago, lesley said:

there would be problems trying this in a wide release. The main issue would be overlapping ranges, it would be hard to hedge against and give proper warnings.

I agree, making fundamental changes to the way a core feature like shipping works is likely to break a lot of stuff in unintended and unexpected ways.

 

37 minutes ago, lesley said:

It could be done, but if you are using a table rate like this you do not depend on accurate data. What I mean is when you have a weight entered, but you are not passing that rate to an api, its just used in house. So it does not need to be that accurate. It can be totally wrong for all intents and purposes. You can just hedge the weight to and manipulate it to make carriers work how you want.

In some cases this can work, but it's not a total solution. If I understand correctly you are suggesting to use different weight ranges for different types/prices of items. For example, for cheap items use their real weights. For expensive items, add 1000lbs or 1000kgs to their weights and then make separate shipping carriers with shipping costs set for those high weights instead of the real weights.

This can work well if you have clearly delineated items that people don't buy in multiples. For example if you have a $2 item that people only ever buy one of, or maybe 2 or 3 of, your system would work well. However if you have a situation where people sometimes buy 1 or 2 of a $2 product but other times a bulk buyer comes along and buys 100 of them, you still have a problem. You don't want the bulk buyer to be able to use the cheapest types of shipping, often without tracking or insurance. At the same time you don't want the person buying a single $2 item to have to use expensive shipping.

Of course this can also be worked around by having different listings on the site. $2 single items with 10 in stock, then listings with bundles of 10, 20, 50, 100 etc which would have different shipping carrier options. This kind of works too, but it's not a very elegant solution.

This is why I had a module created that uses an override to enable a maximum price for carriers. It doesn't screw with the core shipping system but still allows me to limit the total cart value for a given carrier. This gives me total flexibility without making me do unusual things like incorrect weights or bundle listings. It's still not a perfect solution because the errors displayed by TB don't always match the real reason a carrier isn't available but it does work.

[toplakd]

Displaying disabled carriers and reason why they are not displayed on carriers selection site would not be good idea, specially when one has a lot of carriers and used display space is very precious on mobile devices.

Overlapping is not an issue, as if within overlapping all carriers are displayed which meet the criteria (if overlapping is something that user wants). And thats why preselected value is 0, as if 0 then this

In current system one can not manipulate the carriers optimally because of missing additional options to limit displayyed carrier selection list and some do not want to show more carriers available as needed for completing the order.

Above mentioned options from @dynambee sound good, but missing the option to enable minimum price - to not show more carriers than needed.

[dynambee]

9 minutes ago, toplakd said:

Above mentioned options from @dynambee sound good, but missing the option to enable minimum price - to not show more carriers than needed.

It shouldn't be difficult to implement a minimum price feature, I just don't have a need for it myself. I only have 3 or 4 available carriers to any given destination and they are all clearly separated by price & delivery speed. I just need a way to make sure someone making a big purchase can't choose untracked & uninsured shipping.

[toplakd]

And this is exactly the point where min/max price limitation kicks in if one has carrier weight based.

I have 4 different carriers which each have 4 weight ranges (same on each), I have set them for price range 0-100 - that's how much basic insurance covers
One can have to maximum 2 kilograms of products if total value is less than 100$, than this carrier is shown

 

and 4 new weight carriers will be added which will have price range 100-500 (higher incurance cover needs to be paid here, therefore different shipping costs)
If total value is over 100$ than previous carrier does not show up, instead this one kicks in, and it shows available carrier price that was set by the weight for order above 100$

The solution i'm using in my test environment respects all the core messages and always shows right carrier, or out of range if no carrier meets the criteria.

If price is over range of both carriers it disables it and shows price error, even if product selection is within acceptable weight range of all carriers,

and if weight is over range but it's within the price, it also shows correct stuff thats provided in the core.

[dynambee]

I'm not sure of your situation, I can only tell you about mine. I have three standard options:

1. Slow, but very cheap. No tracking, no insurance.
    
2. A little faster, has tracking, basic insurance. Middle price.
    
3. A lot faster, better tracking, more secure, can be insured up to $20k. Highest price.
    

If someone buys a $2 item I don't care which shipping they choose. There is no need to stop them from choosing better shipping if that is what they want, if they are willing to pay for it.

If someone buys a total cart value of $50 I don't care if they choose option #2 or #3 but I don't want them to have #1 as an option. Again, if they want to pay for faster shipping then #3 should be available to them.

If someone buys a total cart value of $200 then I only want them to be able to choose #3.

This is why I don't need a minimum price.

[toplakd]

In my situation all have same speed grade, so not want to confuse customers with additional higher price shipping options.

Even if all show same speed grade, many do think that if higher shipping price the order will be delivered sooner 🙂

And as more than 75% of my orders are placed through mobile devices, showing unneeded carriers consumes space on small mobile area.

[toplakd]

There is pull request on github showing 3 files that were modified and is working as intended.

The only issue I had, I could not display currency sign for field description as it shows currency ID.

https://github.com/thirtybees/thirtybees/pull/1170

Edited April 18, 2020 by toplakd

[dynambee]

Trying to modify the core like that will lead to unexpected consequences for some users. You should implement this as a module.

[toplakd]

It's basically same as with current core option maximum weight. If no value is added into current maximum field, then it's overlooked, if value is there, it uses natively implemented core stuff to check and respond.

That's why it was added to github (i was asked to) so devs can take look at it (if) to see what changes were made as I'm not a coder to be able to write modules. 😥

[datakick]

1 hour ago, toplakd said:

There is pull request on github

I reviewed this pull request. I must say, I was (and I still am) thrilled about it. This is exactly how I imagine new features to look like - it adds value, yet is fully backwards compatible. If you don't use these new conditions, your carriers will continue to work without any change. Even new database column don't pose any compatibility problems, as it has default value 0. If you, on the other hand, use these new conditions, you can much more easily manage your shipping options. It's a really great feature, if you ask me.

The reason why I didn't merge it is not the feature itself, it's existing bug in tb that should be fixed first. And once it's fixed, this proposed feature will have to be refactored as well.

Let me explain:

Not many people know that thirtybees supports multiple packages by default. Actually, it's often reported as a bug 🙂 This 'multiple package' feature can split your order into multiple one with the *same* reference. Every order can have different carriers, and/or different destination. This can happen, for example:

• if you use ASM, and have your products stored in different warehouses (this is obvious)
• if you have incompatible carrier restriction set on individual products
• if you use multiple destination feature (you can send one order to multiple addresses). This is just theoretical, I've never seen any theme that actually supports this. But backend does
• if you set 'Delayed shipping' option --> this would split your cart to two orders, one with product on stock (that can be immediately sent to customer), and other with products on backorder
• and maybe more, I'm not sure...

Most merchants don't use these options, and so they will get 1 order for one cart. But thirtybees can generates multiple orders for one cart, and we must continue to support this functionality.

Now, the bug I mentioned earlier is that the carrier Maximum package weight is evaluated using weight of all products in the cart. But it should be using package content only -- calculate the weight of the specific package. 

The feature in the PR does the same, but with min/max price. 

Let me give some example when this might be a problem.

Let's also have two carriers

• Carrier A that can handle high value packages
• Carrier B that can transport heavy objects

Let's have two products:

• very pricey Golden bracelet. You will associate this product with carrier A only.
• 50kg of dog food. You will associate this product with carrier B only.

If user adds both products to one cart, the result will be two orders with same reference. One order will contain Golden braclet and will be send using carrier A. Other order will contain Dog food and will be sent using carrier B. This is correct.

Now, let's edit Carrier A, and set Max package weight to 1kg. And try to order these two products again. Now, you will get 'No carrier available'. That's because thirtybees will calculate total weight of the 'cart', which is >50kg, and use this weight to check if all packaged can be sent. And obviously, this check will fail for carrier A.

Instead, tb should calculate weight of specific package (in this case weight of golden bracelet only) and check if it matches carrier restrictions. This needs to be fixed