Multi-Vendor Support

[kbrand]

Please forgive me if this has already been covered in this thread. I didn't have time to do more than a quick scan of all the posts.

Would there be some way to use the product types to deal with shipping from multiple vendors? Could each vendors products be based on a different product type, and these product types have the specific shipping info?

I am asking from complete ignorance here. I need this type of functionality in my cart also. My first step was to look for some type of drop-ship module or multiple vendor module. Since this doesn't seem to exist (yet) my first inclination was to use the product types. Unfortunately, I haven't found a good tutorial on setting up or using product types. My time is very limited for the "playing with zen" that is usually required by me for setting up new features (as well as my trepidation of experimenting on my live site!).

Thanks!

[AndyII]

dont think this is exactly what I'm looking for...
but is there any such mod that will allow multiple vendors/affiliates to have their "own" store within the cart, they would take care of there own products and prices, uploading any needed pictures, files etc.
I would put some money on this, I am a convert from cubecart and was using their vendor mod.
Andy

[russmann]

Hello,

I'm looking for this functionality as well. Has anyone accomplished multi-vendor shipping calculations in Zen Cart yet?

[Mack32]

Any hope of this one yet?

Mack32

[Goanna]

Just want to say that I would like to see this contribution ported over to Zen Cart as well. I used it with OSC a couple years ago but now that I am in the progress of switching to zen cart I need to find another option.

[BradScott]

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.

[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