Status of Multi-Vendor?

[lindapowers]

The customers have to pay you directly and at the end of the month you make an invoice for each vendor with your commission. Basicly customers pay you and you pay the vendors.

At least I think thats the legal way of doing it.

And of course customers should be able to buy different products for different vendors on the same order, how to deal with that, no idea but you can't just limit customers to choose a product for one vendor.

So you say most of this is already implemented, but for what I read we as admins have to manually enter the details for each product etc and manage all orders.

The idea of a multivendor site is to asign rights to those vendors to enter their own information, upload images, products, confirm orders.

As you already known front end editing is basic for these to work. I don't want vendors on the backend administration.

[Milbo]

And of course customers should be able to buy different products for different vendors on the same order, how to deal with that, no idea but you can't just limit customers to choose a product for one vendor.

It all depends on the cash and the wares flow. When you take all the money and distribute it to the vendors, you have from legal point a singlevendor store. Then you can have different vendors in one checkout.

[CavySpirit]

The customers have to pay you directly and at the end of the month you make an invoice for each vendor with your commission. Basicly customers pay you and you pay the vendors.

As Milbo has said, that makes you a single-vendor really. You end up with all the headaches. You end up with a customer service nightmare. You end up with reportable income to the IRS of every dollar and then must make sure you have 1099's filed on everyone and detailed on your tax returns. IF you don't pay your vendors by snail mail via a check (more paperwork for you and them), then you will pay them electronically. How? Typically Paypal. For free? Heck no. You now need to factor in more expense, say 3%. That 3% has to come from somewhere. Product price (increased cost to customer) or expense to Vendor or expense to You. So, in addition to whatever commission you are charging, AND the commission to the payment processing the first time on the sale of the goods, you are paying another 3% on top of that. I would never expect my vendors --who are making and delivering the products-- to wait a month to get their money from me. So, now you've got at least a 6% cost of doing business BEFORE any commissions. Let's say you charge a conservative 5% commission. Cost of doing business on your site is now 11%. More if you charge more. That's before any gross margin the vendor hopes to get. Times are tight and tough. I think we need to be smarter, leaner and more competitive.

I can wait a month for my commission. I'm not the one out there buying inventory, supplies, labor, etc. And if I want, I can use my Freshbooks account (www.freshbooks.com) to bill my vendors (because it makes sense for me to have a freshbooks account). When I send my vendors a Freshbooks invoice, I only have to pay a 50-cent fee if they use paypal--no matter how much money we are talking about. A great deal currently only found on Freshbooks as far as I know. So, that saves the whole 3% coming out of someone's pocket, AND a FB invoice is a very professional way to go. (US only, unfortunately.)

And of course customers should be able to buy different products for different vendors on the same order, how to deal with that, no idea but you can't just limit customers to choose a product for one vendor.

I don't think it's an "of course." Not, if you think about the implications of what "One Order" means. I see no reason why you can't limit customers to purchasing from one vendor at a time. I think the ability to have a logical overlay of one cart is a big 'nice-to-have' but by no means mission-critical in the shopping experience.

The idea of a multivendor site is to asign rights to those vendors to enter their own information, upload images, products, confirm orders.

As you already known front end editing is basic for these to work. I don't want vendors on the backend administration.

I agree. But, it seems like a huge additional level of effort if not done via the backend. For those reading this thread interested in the other solutions, the IXXO way actually gives vendors very controlled access to the back-end, but only for store management. IXXO also does some encrypting of the joomla index.php file in /administrator to prevent hacking.

I also hope that something can be done to facilitate a vendor's experience to accomplish this.

[lindapowers]

Well yes, you are right in that sense, you do all the customer service but you have 0 responsability in legal terms.

example: If a customer get's intoxicated by one of our products the commission agency has 0 responsibility and is legally covered in that case and the vendor has to deal with that.

We have worked with many sites that way and we as producers and vendors have to do most of the work and the commision agency just have to deal with the customer service (which in most cases will be just telling the customer to contact the producer as they can't solve the issue)  and take the money.

The price is not increased for the customer as you as commisionist take 20%, 15% or 10% over the original price per product, you "steal" from the vendor and not from the customer.

Maybe I didn't explain it correctly, customers pay the commission agency directly, and then, the vendors are payed each month reducing the 20% or whatever but each vendor has to make an invoice for the customer, that way commission agency is legally covered.

Paying the vendors each month is something usual and normal in my country and thats how it works.

I can understand multi-vendor for VM is something complicated to deal with, cause there are many scenarios and different ways to work on those sites, what may seem normal in the USA has nothing to do usually with how we work on Europe and the same for each country.

PD: Please don't tell me about customer service nightmate, any producer as me will jump on you directly, you do nothing, you just take the money from the producers and vendors doing all the work, dealing with the customers, product quality, transport system sending the products, having the store etc, my god you don't even see the product, it is send from vendor to customer directly, your cost is what? a website with 2 it technicians doing seo work and advertisements

The nightmare is for the producers and vendors, thats why we want to become one of those commission agencies or "white globe thiefs" as we call them here.

[CavySpirit]

Lindapowers, in the US, I would have more than zero legal responsibility with that flow. I can appreciate that business models and income tax accountability are different in Europe (and other countries, of course). They must be, as IXXO is based in Europe and has developed their process along the lines that you've indicated. But, it just doesn't work that well for the US. If I were you, I would absolutely be going with IXXO. They sound like a perfect fit for you. If I could make the model work for me, I'd probably still be using them.

The only thing I would disagree with is the notion that you are taking your commissions from the vendor and not the customer. In the end, it's still the customer. The vendor must raise the price or has already raised the price in order to cover the commissions (regardless of when and how the commissions are paid). Therefore, the customer pays. Otherwise, it would be a non-profit company and the fees could ultimately come from the investors or contributors. That was my point. The price of the products (overall and generally) must cover all of the expenses as well as the profit margins to the vendor. Margins matter. So, reducing unnecessary expenses (money flow) is important to me. I want the prices of products on my site to be as competitive as possible.

[ibelieve]

I have learned that there is a major issue with communication between developers and business people a lot of the time. 

I, not being a "developer", am still intelligent enough to know when my questions are either being misunderstood or not answered 100%.

That does not mean I consider the developer lacking intelligence, it simply means I'm not understanding the lingo, the concept etc.. from the "DEVELOPERS" point of view.

Perhaps I'm not asking a question in a way that makes sense to a developer, but if I'm trying to use a product that someone has developed...which is the entire reason why the developer would create the product in the first place.... then I would expect even more time would be shown on the developer's part to be sure that the person who was asking the questions were getting the answers they are trying to get.  *takes breath*

With all that being said.... 

I gather that the newest/latest version of VirtueMart has the Multi Vendor capability, but it requires additional "DEVELOPER" work to make it function the way that is required for the site owner's individual needs - correct?

So, how does it "WORK" as it is, out of the box as of now? 

Does it function at all? OR does it require, in any case of use, the additional support, knowledge etc.. of a DEVELOPER?

If I install the latest version of VirtueMart as a brand new install, without any expectations other than how it works as is, does the Multi Vendor feature work the way that VirtueMart intends for it to be used?

How does VirtueMart intend it to work?  Perhaps if I understood what VM's take on MV is, then I would better understand what to expect from it.

To me, as a site owner, MV would mean that I could run a website where multiple people could sign up and have their own profile/account to sell items, control their own shipping, manage their own sales etc...  then as the site owner/admin I could then charge a percentage of each of their sales or charge a monthly fee etc...

So, how does MV work right now out of the box with a brand new install?

Would anyone who wants to use the MV functionality of VM HAVE to hire a developer in order to get it to work - period?
or would it just be tailoring if the site owner's needs fall "outside" of the normal use the VM has it currently set up to work.

I'm trying really hard to convey my question in hopes someone will do the same courtesy in return with an answer that I can understand, again, I'm NOT a developer.

Thanks :-)

[Milbo]

Would anyone who wants to use the MV functionality of VM HAVE to hire a developer in order to get it to work - period?
or would it just be tailoring if the site owner's needs fall "outside" of the normal use the VM has it currently set up to work.

There is no tailering done. There is no frontend for the vendors, they must be allowed to have backend access. and yes you need almost always a developer. There exists one case you can do it almost without.

[ibelieve]

Thanks...

I'm assuming there is probably way more to this than what your reply states.

I either missed the bulk of it, which seems to be scattered a little here and a little there throughout the entire forum over many months and years of discussion regarding the multi vendor concept, or you have just chosen to give the most simplified answer possible... thus leaving a lot of grey area. 

I'm not sure what you mean by first saying there is "no tailoring" then you say you "almost always need a developer...."

Well, if you need a developer to get something to work...to me that is considered tailoring. 
Something either works as it is intended, or it simply does not.

So if the "intent" of the multi vendor feature is to hire a developer to use it, then so be it.

What I guess I'm sorta looking for here is someone to say, 'The Multi Vendor function available in the current release of VM is still in BETA, it works, but not to where it is conducive to use in a live site where an administrator can have multiple vendors or "sellers" log in and conduct their own sales from there OWN separate admin area.  In order to do that you will need to hire a developer.'

Then, it would be lovely if someone would then say.... 'VM plans to develop the Multi Vendor feature further so that it can eventually serve as a true solution, out of the box, for site admins/owners to run their own "Virtual Mall" type website.'  Because ultimately....that is what a multi vendor site IS, a Virtual Mall.

But of course, I'd only want someone to say this if it were actually TRUE.  If it is NOT, then I'd love to hear that as well.

My point being....  it either works as a true multi vendor concept as most of the people interested in it needs it to work "out of the box" or it does not, in which case you would need to have it tailored to your specific needs thus by hiring a developer.

This part of the VM project has been one of the most confusing things I've ever tried to wrap my head around and honestly it's because I've never heard a straight forward answer about it - EVER.  It is not my lack of intelligence causing my confusion, it is lack of properly conveyed information from the source.  And that comment is not meant to be taken personally, it is simply some constructive criticism.

For years now, I've listened to the faint chirping of a multi vendor capability for this shopping cart system and from what I'm gathering from all the vague and somewhat even foreign replies, this probably will never be something that VM can actually do, at least not without many more years of experience and funding...at least that is what it appears.  And that is perfectly fine, you have a great cart system and it's free, not too many can complain based on that fact alone.

I'm just irritated to the extreme and confused to boot with the replies that I've seen to some very valid questions asked by users of VM in this forum.

If there is no front end for vendors, only back-end access...then this really can't be called a Multi Vendor anything at this point.
And your last sentence didn't make any sense to me at all, sorry.

I seriously doubt anyone's goal is to allow back-end access to multiple sellers...so from what your saying, this is NOT a feature that is ready for any real "use" as it is.

It is something that you are allowing to be part of the VM cart for TAILORING "if" someone really wants or needs to use it, thus the need for the developer.

I honestly appreciate your attempt at clarifying things.

Thanks.

[Milbo]

You did not read correctly, I said, there is no tailering done, so you need a developer todo this.

and your post sees not to consider that I gave already this answers in this thread http://forum.virtuemart.net/index.php?topic=90892.msg298360#msg298360 .

And as Cavyspirit and lindapowers already discussing, there exists a lot of different multivendor solutions and a lot of them are NOT a mall.

You must differ who takes care of the cash and wares flow. Then you can differ if people are allowed to have backend or frontend access. You can also differ if the customer should notice that there exists different vendors. Sounds not reasonable for you? Some examples.

You can use the vendors just internally for your employes. You can use multivendor for a strong partnership/affiliate program. For example the tires store in the car store (exists already with vm1.1 ! ). Another idea is that a manufacturer or distributor is adding his products himself and the merchant is just doing marketing/delivery/support and infrastructure. Then additionally to that you can have things like dawanda, ebay or amazon. Consider here also that there exists for ideas like dawanda, but only with approved vendors.
This are the main multivendor things and not a mall. The mall is the most uninteresting, because you can solve all of that with server/maintaining scripts. Another idea with multivendor is also to have 2 shops with simular but not the same content, running on the same db. This concept is surprisingly, after the dawanda model the most asked one.

[ibelieve]

No, I read what it said quite clearly.  The definition of tailoring is still going outside of the boxed application and using a developer to obtain the desired end result which your saying is needed if you want to use the multi vendor feature.

Just the same as when the "large" man tries to wear the "tiny" suit, a tailor is required to get it to fit, unless it doesn't work at all in which case...why is it even there?

And my post did consider that there might be posts out there in this forum that may provide further detail, I'm pretty sure I said this exactly, perhaps you missed that?

So thank you for providing the link so I didn't have to go wondering about looking for it aimlessly.

Those still all seem just variables to what most consider a virtual mall...and when you look for "multi vendor" applications, mall scripts is what pops up and to the majority I'm pretty sure that is what they expect it to be able to do.

I'm sure someone could take this and go in any direction they'd like so long as it was actually within the means of VM and they have the funding to pay a developer to tailor it for them.

What my major issue is that there appears to be no documentation that clearly states what the multi vendor feature in VM does out of the box as it is right now and from what I'm gathering it does nothing at all without a developer which means it's basically a useless feature unless someone brings in a developer.


....okey so I just looked at the post you referred me too... she is describing a virtual mall... that is what the virtual mall concept is, exactly what she is asking for, and the same thing I'm looking for.  Just to clarify that part....

 

[Letterhead]

I don't think VM is capable of answering this question whatsoever, not at least without making sense or being sarcastic.  I've been waiting for an answer to this for several years now and every time I inquire about it, it's the same incoherent responses tainted with belittling and rude comments from someone who obviously doesn't have any real answers.  I'm done LOL.

What is your definition of Multi Vendor? it has taken me ages to get my head around this, but it does work, it's mainly i was unsure how to set it up and how to wrap my brain around the concept and what i actually need.

I am well to dumbass to hack, so use an out of the box version.

I have needed to install several versions on 1.5 and 1.7 and will now produce a site for live use.

I have added this only because i really get humped off when people write here saying can't, it don't, and other negative comments.

These guys have regularly helped many business collect the money that drips off the Internet daily, they are to me hero's

Thanks for VM 1 and now the new VM2

[webgobe]

I have keeping a low profile until now here, but as a contributor and heavy user of the MultiVendor hack for the original Joomla 1.0.* series must add my 2 cents here.
Yea, MultiVendor can mean a lot of things. Is not that simple to give a definition of "true MultiVendor" solution, and is even harder to implement it. On surface everything looks simple, but if you are getting deeper, things are looking not so simple anymore.
Here are some simple issues need to be answered.
For example: who is doing the shipping? Each vendor for his/her own location? Or shipments will be made from a central warehouse? This alone is a huge difference between two potential MultiVendor Shops. Also how the money are collected? who pays where? Each vendor is directly paid to his/her PayPal account? Or each vendor has different payment processors?
Can a shopper buy in one shopping session - with one cart/checkout goods sold by any number of vendors or in cart can be goods sold by a single vendor?
These are crucial questions. And I only scratched the surface.
Come on, boys. This is a very complex issue. You must have some really clearly drawn scenarios in your mind BEFORE you began to deploy a MultiVendor shop. Think before you are asking questions.
One size fits all is something in-existing when comes about MultiVendor shop.
Some possible scenarios can be addressed - and I will be VERY happy if VM 2.0 makes possible one of simplest things:
1. Multiple vendors can register and set up their products, their shipping and payment options
2. All products from all vendors are shown TOGETHER, inside the same category structure
3. Shoppers can browse all products - and buy in one cart products from a single vendor. In case of trying to add product from a second vendor, shopper will be warned, and the product won't be added.
If this will work, will be a huge advance. Will find out myself in the next couple of days - and will share my experience.
Thumbs up for the work already done, regardless to the actual stage of the project. I am aware of the amount and complexity of work needed here.

[Milbo]

Heyhoo webgobe,

your dream is really near, I suggest you join us in skype. I built a kind of taskforce. We finally defined the following multivendor scenarios we want to achieve in the next major version:

- single vendor, multi-administrator =>this absolute basic case. This is done in 2.0.0 but only for j1.5, the svn has already all fixes.
- multivendor single cart => different vendors, but same payment and shipment methods for all vendors, all vendors can share one cart.
- multivendor single cart strict => This is the case you mentioned and the case I also had in mind. Some are already working on it. But to sent a warning is a bit odd, so we had the idea to extend it to
- multivendor multicart, which means that you can have different carts, per vendor.

Already in place is that you can share categories, rules, and other stuff, so you can use this with other vendors. So they can have their products in own categories or in shared ones. Al of them need a different level of administration. It is also a security thing, if you wanna allow vendors to upload own images and similar. Write a pn, when you are interested.

[meowser]

Multiple vendors on an eCommerce venue is an extremely difficult problem, not only for logistics as many have stated.  That is to say, how vendors get paid, how consumers pay, how vendors access backend management functions.  But also from an engineering standpoint is extremely difficult.  Its not only the issues noted above, some vendor products have varied features, small, medium, large, some have specific static informational requirements such as say software operating system, memory, video card requirement on and on and vendors dont like keying such stuff in over and over and over.  If they are given capability of field creations be they static or live input field creation that opens up a whole different barrel of issues both in the software development but vendors not screwing up.

Do developers understand sales or marketing? Not many.  Do vendors understand engineering? No, not many.  All three of these areas rarely come in one person (I am fortunate, I do know all three as well as enterprise level development).  Thats another matter.  Folks here might think, "Well gee, multivendor, I can have 250 or 1000 vendors all with lots of products!".  You will quickly find if traffic becomes anything near brisk your webserver will start slowing to snails pace, sure... one can do somethings with PHP/Apache/MySQL to try ease things such as Memcache, better server hardware, more memory in it, distribution of the database to another server.  But, in terms of scalability a brick wall does exist and essentially the only ways around that without custom solutions (expensive options) are going with enterprise level and/or at least technologies that can be expanded to enterprise levels in "natural form".  What is natural form?  Natural form means that the core software has scalability in mind from the word go.    For example, Microsoft ASP.NET, MSSQL Server, CommerceServer etc. all are naturally scalable.  Java, Oracle etc. all are scalable, Apache, mySQL (to an extent) are scalable but PHP does not scale well nor are most of these open source projects like Joomla etc. built in a way where distributed components are easily done.

Amazon.com is BIG enterprise level.  So what type of architecture does an eBay or Amazon or others that have many vendors and considerable traffic do?

They have connections servers located in most states, sheer responsibility is basically handling connections.  Amazon appears to be "one site" but in reality Amazon has many "stores" handled by numerous distributed server banks, checkouts, accounting and considerably more.  Its all distributed.  Thats "Enterprise" level.  So lets not confuse terms.  I dont think anyone here thinks they are going to become walmart.

But...  At the sametime you would be VERY surprised to find out actually how poorly sites that develop high traffic end up performing because they did not pick the right solutions.  For example, Joomla is very popular but in comparison to say Liferay (java CMS) as scaling and general performance comes into play its night and day.  Essentially the same reasons Walmart or Target etc. use Java to do store SKU pushes on and on.  There regional networks pull/push data from servers daily.  If they used PHP to do it, it would not be finished by the time the following push/pull need be done.  It simply doesnt have the "Umph" or be easily and MAINTAINABLE scaling to do so nor was it or has it been designed to do so where as Java, ASP.NET etc. are.  Even though a similar ASP.NET site might perform slower than the same site in PHP when the "brick wall" is hit the ASP.NET platform has solutions, in PHP it comes time to start finding whatever kludges one can come up with to deal with it.  The kludges eventually are either a brick wall or spaghetti that becomes difficult to maintain.

There is no "All in one" multi-vendor solution that exists, Magento enterprise (which is PHP) is the best platform in PHP.

But, you wont see enterprise level existing commerce jumping all over it.  Magento's people know that.  They in a way are seeking to "attract" entrepreneurs who are now developer savvy.  Because if just for sake of say a name, "Starbucks" wanted enter into enterprise ecommerce no development firm would say, "Lets use magento" or "joomla".  No...  Its Java, its C++ or its ASP.net (generally) and custom development.  As thats pretty much the only way to ensure scalability, performance, extensibility and keeping COSTS downward long term while ensuring the service can handle what may come at it.

Target.com is run by Amazon.com for example.

Now I dont know how virtuemart 2.0 has been coded up.  You see lotsa buzz about terms like MVC with Joomla (Model View Controller) which is now a 30 year old paradigm, there are MUCH more efficient ways to code than MVC.  If Amazon used MVC we'd be looking at another $30-$50 million dollars a month and triple that at holiday season in expense of server cycles alone.  Amazon is coded in C++ (the lions share of it).  eBay, C++ lions share of it.  Why?

Because C++ compiled native code will run rings around ByteCode platforms.  For example, the software you use that runs Joomla is PHP, Apache Server and mySQL Database server.  These were all coded in C++.  Benchmarks in performance are night and day.  If Joomla was "Pure C++" it'd hold thousands more users online at once .vs. PHP and do so far more efficient and effective.

The enterprise standards are C++, Java and slowly growing ASP.NET as Microsoft is counting on server, bandwidth and such continuing to go faster and faster at lesser and lesser costs and Microsoft is basically the only entity that has a full blown "everything" development platform.  That is to say, with Microsofts platform one can make websites, web applications, pc applications, mobile applications, distributed applications on and on using one set of tools.  The only other player in this market really is Adobe and their "Web Flagship" product be Flash & Flex is already being counted as "Dead but not yet knowing it" because of the new movements in HTML and CSS.  CSS 4 spells the death of flash. HTML 6 spells the death static sites, CSS 5, HTML 7 (I only saw cursory specs of both last year by a friend at W3C) and leveraging cloud based computing spells the end of content management systems, photo buckets and then some.  By 2015-2017 most of what seems familiar now will seem as stone age as DOS compared to Windows.

There are that I know of three drag and drop "Content Management Portals" being deployed late 2012 by "real money" that are going to severely injure the "open CMS" applications with capabilities far far in advance of the piecemeal and all of them are to be free, free everything.  Two I cant discuss at all, the other I saw prototypes of and thats coming from Yahoo.  Its why Yahoo worked several years at "YUI" and all the development that people thought "stopped" did not stop.  Instead, its went proprietary and they may be the first to deploy it.  Think of it like Joomla, content management with easy to use access controls, modular, drag and drop.  You literally have a toolbox of modules (or in joomla terms modules/components) and you can place them anywhere and set properties/restrictions there-of.  But, its also a portal, like "multi-vendor"... you can have yours or others "sites" under your site.  Now mix in facebook forms of human/business networking to develop, derive and maintain traffic from.  All sitting atop enterprise level architecture that maintains everything from load balancing to security.  Thats whats coming.

The idea is simple, you dont need to be a guru or developer to create webs that are not only highly effective but MORE effective than the piecemeal out there today.   One of the other entities doing this I cant talk about since my brother works for them, but, I did mention their name in the above paragraphs.  They will be doing so across global ecommerce which is one of the big reasons they have branched into selling computing resources, created a third party payment system and nearly killed off their affiliate type setup.  Essentially they will own eCommerce which is good and bad.  Good in that everything ends up regulated, so now nations can make decisions as to what comes in and what is allowed to leave/be sold etc. in their respective nations.  Bad in that it ends up regulated so now nations will make decisions that end up with the "little guys" out of business unless they work with the big guys who ultimately will provide all facets of eCommerce.  That means from purchase to packing to delivery and the small manufacturer or supplier will get their 70%.

Anyways... none here should think that Virtuemart or any other eCommerce multi-vendor package is going to suit all their needs or future needs.  Such things often require custom development.  The developers at Virtuemart are no different than developers at CS-Cart or others.  It is not the softwares goals to be able to solve every niche needed, its intended to be broad based to service the most vendors it can... Not be a "Well this will service every possible combination possible" as that does not exist nor will it until its provided by both technology advancement and big money involvement to make it a reality.

[lindapowers]

Completely agree.

If you are lucky enough to make a website where VM or any other e-commerce solution suits your needs for "multi-vendor" perfect.. but in 90% cases you will need a custom development.

Apart from all the mentioned problems you have to add the law issues different for each country which will require custom development too.