We use manufacturer information in the components that go into our homes.
For instance, one "Product" would be a bathroom sink faucet. For simplicity, we
refer to it as a bathroom sink faucet - no mention of manufacturer. Depending
upon the year and the current style, the bathroom sink faucet may be
manufactured by different companies. This year it's Kohler, five years ago
it was Price-Pfister. Our suppliers know we will accept only the the brand we
use currently.
So, whenever we look up bathroom sink faucet we need to know which manufacturer
was used and when. If we're sticking to a single generic product, then that
means we need to link it to two manufacturers.
Historical information is crucial for warranty service issues. If a homeowner
calls about a failed bathroom sink faucet, we can find out the manufacturer
based upon the date the home was manufactured. (In real life the homeowner would
just run down to Home Depot for a replacement, but the process would apply for
other items.)
Is this an immediate need here? No. If the capability doesn't make it into the
project before I address it here, then I'll just make the mods and contribute
them back.
David E. Jones wrote:
Yeah, ProductCategoryRole might be a good model for multiple
manufacturers as well, but in a way it would be nice if it were more
directly associated with a Product... so I can see that being a possible
way to go as well. I guess it depends on how it would actually be used
by the people and the automated processes... Is this something that
anyone actually has a need and scenarios for right now?
-David
Adrian Crum wrote:
I'm looking over David's suggestion of using ProductCategoryRole.
Multiple manufacturers could be handled that way - then just ignore
the manufacturer field in Product.
So, we could have a Product Category called "XYZ Manufacturing
Products" then the products they manufacture could be linked to that
category. The company itself can be linked to the category through the
party ID in the role of manufacturer.
Manufacturers and Suppliers are different parties, btw. A supplier
could provide the same part from several manufacturers.
Chris Howe wrote:
Technically, I would think you should make them two
separate products and then relate the two products as
equivelents. But of course that depends on how
detailed the company wants to be. Aside from making
them two seperate products, you could treat the
manufacturers as seperate suppliers for the same
generic product.
However, I can think of an example where the current
structure is limiting. When the manufacturer or
product line is acquired by another company.
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
There are many examples of standard products that
can come from multiple manufacturers. If I have a hardware store and
I sell
3/4 inch galvanized pipe tees, they could come from three or four
different
manufacturers. Should I have a separate 3/4 inch galvanized tee
product for each
manufacturer? I hope not! I used the example of electronic
components the last
time this was discussed - the same holds true there.
It IS a limitation. It will come up again, and when
it does, I'll continue to make the same suggestion.
Chris Howe wrote:
why would you have more than one manufacturer for
the
same product? wouldn't that make it a different
product? I agree that it would be better for a
more
generic product role setup, but if all the roles
are
addressed AND it's not limiting, why go through
the
trouble of refactoring?
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
I know about the manufacturer field in the Product
entity. What do you do if there is more than one manufacturer for
a product?
That's the limitation that brought forth my original suggestion.
Why have a dozen different entities linking
products
to a dozen different party roles? We could have one entity that links
products
to any party - regardless of their role.
So, one entity could link a product to one or more
suppliers, one or more manufacturers, one or more product
managers, etc.
It
seems more flexible to me.
Chris Howe wrote:
The manufacturer is desribed in the Product
entity.
The only other relationship to a product that I
can
think of is the supplier and that is desribed in
the
SupplierProduct entity. Having a product
manager,
again is probably managed easiest by putting the
product into a productCategory and managing the
productCategoryRoles on that. Outside of those
relationships, can you think of another that
would
have to do with a product?
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
I had suggested some time ago a
ProductRelationship
entity - where a product can be related to a party, such as a
manufacturer.
Would
something like that meet your needs?
Al Byers wrote:
I think I have a need for a ProductRole that
mirrors the ContentRole
entity. I want to associate a manager with a
product. Is there another
way to do this? If not, should I just create
such
an entity for this
custom use or should it be something to propose
for general use?
-Al
