Multi-Vendor Support

[blucollarguy]

I too want multi-vendor shipping origins. It looks to me like this wouldn't be that hard to implement for US zip codes, but before I reinvent the wheel, I want to see if anyone else has solved this yet, and/or if my plan will work (at least for my needs).

It looks to me like SHIPPING_ORIGIN_ZIP is what determines the shipping cost. That is used to calculate shipping in three places, that I've seen -- the UPS shipping module, the USPS shipping module, and google checkout (plus there must be a fedex addon where it is used, which I haven't installed).

What I am investigating doing is setting up a zip code per manufacturer. Since each of my products is related to a manufacturer, when I need the zip code, I'll go to the product's manufacturer, and get the zip code there. If there is no manufacturer, or that zip code is blank, I'll revert back to the store zip code. Or, I could just use the vendors from ty's drop ship module to set the zipcode.

The second part, which is much more complicated, is to break the shipping from a single cost into an array or table, with each unique origin getting its own cost / line. So, shipping goes from a single entry to multiple, but that is really what is needed (that's how Amazon handles it too). I'm sure this second part is more sticky, but really doesn't seem unmanageable to me.

So, looking for feedback on whether my approach will work.

Advantages: customers pay true shipping costs, so no approximations / averaging.

Disadvantages: More code/db changes / another module to install. More importantly, customers will see that all the products do not really come from a single store, but are shipped from different locations. However, they'll figure that out when they receive multiple packages anyway.

So -- feedback on this idea please. What am I missing? Is it much more complicated than I realize? Are there other areas that get touched that I haven't factored in (like the invoices and packing slips association with the drop shipper module)?

What I'm trying to do is get the real requirements up front -- maybe I won't solve this for global shipping, but if I can do just the US, that will help enough people out.

If I know everything that is needed, I'll see how bad it is to actually implement. Doesn't look intimidating yet, but maybe I just don't know better

Will update Zen Cart v1.3.8 if I do it.

Well, as one of the two people who wrote the MVS package for osCommerce, I can tell you that your on track. I can also tell you that it isn't quite as simple as it sounds. You WILL need to alter the invoices/packing slips and order views to properly reflect the additional information being collected/saved. If you want an idea of how much is involved, download a copy of osCommerce and do a quick install of MVS into it.

You will also find that the shipping modules will need to be altered individually. With the version for osC, each shipping module is installed specifically for each "vendor" or "manufacturer" and the quotes are displayed for each one as a group on it's own.

I haven't gotten to it simply because I haven't had the time to go through the whole process.

Good luck, and I'll be looking forward to seeing the project.

[BradScott]

Well, as one of the two people who wrote the MVS package for osCommerce, I can tell you that your on track. I can also tell you that it isn't quite as simple as it sounds. You WILL need to alter the invoices/packing slips and order views to properly reflect the additional information being collected/saved. If you want an idea of how much is involved, download a copy of osCommerce and do a quick install of MVS into it.

Thanks -- it helps to see how you approached things.

The good news -- much of the multi-vendor work has already been created for Zen Cart, so no need to duplicate. That looks to be a big part of all the changes you made.

The bad news -- I do see that it is a bit more involved, as expected. You added many features that I may or may not need, so it is hard to figure out the multi-shipping only changes. I like how you have dimensions per product -- that is needed anyway. I also have products that ship in two packages, so the number of packages per product would be a nice feature to add.

What does seem complex to me is figuring out how many packages ship from a given vendor -- given that vendors may or may not be able to combine items into a single package. I guess that can be estimated by total weight, with some approximations based on total dimensions.

What I'll have to weigh is whether to go for the mod soon, or wait to see what is offered along these lines in 2.0. And, to see if I am better off spending my time promoting the online store versus getting the shipping costs right.

But, I just thought of a quicker fix that might solve 80% of my problem. What if I keep a single origin zip code for the order, but set that zip code based on the "primary" vendor? Since I'm sure many orders will be single products, that makes the shipping calculation closer (ignores dimensions, multiple packages still). That greatly simplifies the number of changes needed -- only the shipping cost calculation changes (I think).

Looks to me that then I only need the zip code per manufacturer or vendor updates, and the calculation to choose which zip code to use. The customer never sees the origin zip code anyway (until they get the package(s)).

To calculate the "primary" vendor, if more than one exist, I could simply calculate the weight totals per vendor, and the largest wins.

Would this quick fix really solve 80% of the issue? I know it isn't complete, but the current system of one shipping zip code for all packages is even less complete.

I guess the real question is: does this solve enough of the problem for enough people? Or, is it still far too inaccurate to be practical? I think it would be a huge benefit for my needs, but then again, I might not understand my needs completely ...

[BradScott]

But, I just thought of a quicker fix that might solve 80% of my problem. What if I keep a single origin zip code for the order, but set that zip code based on the "primary" vendor? Since I'm sure many orders will be single products, that makes the shipping calculation closer (ignores dimensions, multiple packages still). That greatly simplifies the number of changes needed -- only the shipping cost calculation changes (I think).

Another limitation of my quick fix approach is that it assumes all vendors ship with the same carrier, and the same service, e.g., all ship UPS Ground. So, if one uses UPS, another the post office, and another Fedex, then the calculation will be even less accurate. Of course, there is no provision for entering multiple tracking numbers either.

I think I could calculate shipping costs per vendor, then add them up for one shipping cost total. That would be more accurate since to ship two packages is always more expensive than one, regardless of weight. The only issue I see there is that customers would not get an explanation of why their shipping costs are so high (two 1 pound items could cost $15 total shipping). Maybe I could add a comment to the invoice in that case that simply says shipping from multiple vendors? It would be easy to add a "vendor_count" field to the order, the bigger question is where to let the customer know that it affects the shipping costs. Any thoughts?

I guess I could explain in shipping policies that if they want some items shipped ground and others shipped next day, better place two orders. That does seem to be a practical workaround.

So, once again I'm trying to think this all through and see if I can come up with a solution that works, albeit imperfectly, but is simple enough that I actually take the time to implement it.

[blucollarguy]

Another limitation of my quick fix approach is that it assumes all vendors ship with the same carrier, and the same service, e.g., all ship UPS Ground. So, if one uses UPS, another the post office, and another Fedex, then the calculation will be even less accurate. Of course, there is no provision for entering multiple tracking numbers either.

I think I could calculate shipping costs per vendor, then add them up for one shipping cost total. That would be more accurate since to ship two packages is always more expensive than one, regardless of weight. The only issue I see there is that customers would not get an explanation of why their shipping costs are so high (two 1 pound items could cost $15 total shipping). Maybe I could add a comment to the invoice in that case that simply says shipping from multiple vendors? It would be easy to add a "vendor_count" field to the order, the bigger question is where to let the customer know that it affects the shipping costs. Any thoughts?

I guess I could explain in shipping policies that if they want some items shipped ground and others shipped next day, better place two orders. That does seem to be a practical workaround.

So, once again I'm trying to think this all through and see if I can come up with a solution that works, albeit imperfectly, but is simple enough that I actually take the time to implement it.

What you are suggesting is actually a feature that has been requested for MVS quite a bit, just work out a total shipping cost rather than showing the customer multiple locations and therefore, shipping options as well, because of multiple vendors in any given order.

The question still remains: HOW do you calculate the shipping costs per vendor? If you go through enough of the work to be capable of doing that, then you have already completed the most difficult part of MVS. I see many simply select a zipcode "in the middle" of each vendor they use, remove all shipper names from one of the shipping modules(UPS, USPS, FedEx, it doesn't matter really) so that there is only a simple shipping "method" being shown to the customer, and then hope that shipping costs even out over time. This eliminates any expectations of who the actual shipper is, reduces overall shipping costs on most orders(shipping is the number 1 competetive advantage the "big boys" have in ecommerce), and doesn't complicate order tracking as much.

There obvious downsides to doing business this way, but for some, it works out just fine.

I do think you are seeing the big picture though, there are many factors with this, and I think the decision process has to be different for each store owner. I don't do online sales anymore myself(though I did and was why I started working on this whole thing in the first place), and one of the many reasons I stopped was that I had difficulties competing because of high shipping costs. Shipping is such a large part of dropshipping, it absolutely must be worked out for each store owner.

Good luck, Craig

[BradScott]

The question still remains: HOW do you calculate the shipping costs per vendor? If you go through enough of the work to be capable of doing that, then you have already completed the most difficult part of MVS.

Thanks for replying Craig -- you are really helping me think this through.

My first quick fix might be to simply to select the zip code of the vendor with the most weight in packages. Once I pull all the product id's in from the cookies, I can use this query (with my sql setting the product id's where I have (15, 19) in this example):

SELECT zen_subcontractors.subcontractors_id, zen_subcontractors.zip, sum(products_weight) AS fltTotalWeight
FROM zen_products
LEFT JOIN zen_subcontractors ON zen_products.default_subcontractor=zen_subcontractors.subcontractors_id
WHERE zen_products.products_id IN (15, 19) AND zen_subcontractors.zip IS NOT NULL
GROUP BY zen_subcontractors.zip
ORDER BY sum(products_weight) DESC

If I get no results, use the standard store zip code, else use the first zip code returned. A second part of this quick fix might be to add a flat fee for each extra vendor, say $6 (configurable), since we know the first pound of a new shipment always has the overhead.

Now, if I have all the vendor shipping zips, and I know the shipping method per carrier (assume all shippers use ground, next day, etc -- comparable service levels), then it doesn't seem so hard to calc shipping costs for each vendor/carrier (as in for each vendor, calc shipping ...). Add them up, and I've got a total shipping cost.

Now, getting the carrier/vendor/shipping cost per vendor all to display (with the products grouped) and reported (invoices etc.) seems more challenging to me. Not impossible, but far more complex, because it touches so much more of the interface. Maybe you can just point me to the spots that need updating, but I would guess there are many.

My point is really that if I start with my quick fixes, it will cover a lot of the cases (all cases where there is only one product in the basket), and I'm much more likely to do it. Not anywhere near perfect, but it would prevent the worst cases. Right now I could ship to the same zip I'm in and calculate a low rate, when in reality the products are shipped across the country.

So, please continue with my reality check ... I'm sure it is easy to overlook something.

Thx!

[blucollarguy]

The tricky part at this juncture in your "quick fix" will likely be "looping" through each vendor to get each quote. This is where the need to modify each shipping module comes in. Each module needs a "ship from" address in order to generate a quote, so the module needs to be called, executed, data collected, individually for each vendor, before you can add up a total shipping cost.

Simply using a "flat rate" add on after getting a basic quote is probably the only REAL "quick fix" that can be done. If you go through the work to be able to loop through each vendor, obtain each quote, then you will have effectively written MVS for Zen. Displaying choices to the customer isn't as big a deal once the vendor loop has been done, and adding things up, altering invoices, packing slips, order views, are all time consuming, but not that difficult once the vendor loop is worked out.

You definitely have a good grasp one what is involved, and that's a good start. When I started for osC, I really didn't have any clue just how much needed to be done to implement this idea.

I can only help so much with which files will need to be worked with though, as my knowledge of Zen and it's core are pretty limited.

Craig

[BradScott]

The tricky part at this juncture in your "quick fix" will likely be "looping" through each vendor to get each quote. This is where the need to modify each shipping module comes in. Each module needs a "ship from" address in order to generate a quote, so the module needs to be called, executed, data collected, individually for each vendor, before you can add up a total shipping cost.

Well, I'll start with step 1 (pick the "best" zip code and add a flat rate for each additional vendor).

Then I'll see if I get to step two (looping through each vendor). That doesn't scare me, since going to each vendor is just a call to their rating and validation engine (that's where the name rave comes from in the cgi call, if you were ever wondering). I used to work for UPS with the guys who wrote RAVE.

My real goal would be to have every order contain one to n shipments, where each shipment can be tracked separately. One vendor might have multiple shipments, and multiple vendors clearly have multiple shipments. But, that's not gonna happen any time soon.

Thanks for all the help.