Faucets are not serialized.
Six purchasing clerks have memorized part numbers for commonly ordered parts.
They're not going to like the idea of having to memorize new part numbers every
time a manufacturer changes.
Bill Of Materials use the same part numbers. Every assembly that uses a faucet
would have to be changed when the manufacturer changes.
I view the manufacturer of a component as a kind of meta data - not worth
creating a separate product for.
Chris Howe wrote:
It's obviously not my project, but I would think in
that scenario, were warranty information is important,
you would definately want to track them as seperate
products. Otherwise you're forced to create your
reports by custom time periods that are more prone to
innacuracy. Isn't this product already going to be
serialized? If you're going to that specificity, why
go back toward generics?
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
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.
=== message truncated ===
