Hey Dave. It is a little confusing, so I looked at Data Model Resource Book to see if there is clarification. From what I can garner, a Vendor "sells" stuff (to you), and a Supplier "supplies" you with repetitive items, over and over.
You may call your local light vendor and ask for 100 15w br30 CFL bulbs. You don't care about the make and models. The vendor looks at his OWN suppliers, and ends up shipping to you 100 sylvania 15w, model xyzzy, or a combination of equivalent items from various sources. That is a Vendor. He takes your order, looks at what suppliers HE has relationships with, and ships to you what you need. He's a middleman, and he may also use his own, unique part numbers for these items. (VendorProduct). A Supplier is more precise. He still takes your order, and sends to you ONLY what HE makes/manufactures/distributes. That's it. You know exactly what you need, you know the exact make, model, manufacturer, size and part number. He supplies the same exact part to you, over and over. (SupplierProduct) Is this closer, or am I way off. On Fri, Dec 9, 2011 at 6:31 PM, David E Jones <[email protected]> wrote: > > > Ruth Hoffman wrote: >> Hi David: >> Nice to hear from you again. Thanks for your input. I have some >> responses. Please see below: >> >> On 12/9/11 4:44 PM, David E Jones wrote: >>> >>> Ruth Hoffman wrote: >>>> 2) If you look at how vendor/supplier is used in some of the OFBiz >>>> applications, you might observe that: >>>> >>>> A vendor "supplies" goods or services to the Company of record for the >>>> OFBiz instance. Those goods or services may be raw materials for >>>> manufacturing, products for resale on the ecommerce site or computers to >>>> run your business. When a vendor (with a record in the VENDOR table) >>>> supplies you with something, they are acting in a role called a >>>> "SUPPLIER". >>>> >>>> So, in the OFBiz world, my interpretation is: A vendor is a supplier. It >>>> is as simple as that. Anything more is making it too complicated :-) >>>> >>>> Anyone care to comment on my interpretation? >>> Actually a Supplier is a Party the sells things to the company running >>> OFBiz, hence the SupplierProduct entity. In other words, a purchase >>> order is sent to a Supplier. >> A vendor is also a Party that could sell things to the company running >> OFBiz. Just depends on how you set up your accounting system and how you >> name your accounts. >>> The term vendor doesn't mean much in OFBiz, but has been used for any >>> Party that sells something. For example, if you have multiple stores in >>> your OFBiz instance you may have a vendor per store. You could also have >>> multiple vendors selling through a single store. >> Seems to me if the Party sells something and the term vendor is used to >> express that activity, then the term DOES have lots of meaning. OFBiz >> e-commerce, after all, is all about selling products. >> >> That said, there is also an entity named VendorProduct that when coupled >> with the Vendor entity may be used in the same way as the >> SupplierProduct entity. Perhaps I should have said a vendor is a type of >> supplier? Unfortunately (or maybe fortuneately - who is to say?), the >> data model does not enforce this relationship. > > Okay, so did you ask to get an answer, or did you ask to start a > discussion? It's not like this is open to interpretation, this was > discussed and decided on a long time ago. > > A supplier sells stuff to the company running OFBiz. A vendor sells > stuff to the customers of the company, and a vendor could be an > affiliate or consignment seller sort of thing. > > The SupplierProduct and VendorProduct entities are VERY different and > meant to model these 2 totally different things. I'm sorry, but looking > at them again to make sure, I'm not even sure how they could possibly be > confused. > >>> They are not really equivalent terms. >> Maybe, maybe not, but I would argue, based on the data model, that they >> ARE equivalent terms when a vendor acts in the role of supplier. >> Regardless, there is really no need to make this more confusing or >> complex than it already is. > > There is a clear distinction here. It's not making things complex, it's > two different concepts. It's not one concept, that would be > over-simplifying it. It is two separate, distinct concepts that need > different words, and have them. > > Damn, with all the mis-information buzzing around these lists no wonder > people have so many issues with OFBiz. Of course, OFBiz itself is > admittedly complex and often unclear or just plain buggy and > inconsistent, so this is understandable. > > I don't know exactly what we can do about all of this, but being more > careful and detailed might be a good start for all of us. > > -David
