Login  Register

Re: Need for ProductRole

Posted by cjhowe on Jul 10, 2006; 8:43pm
URL: http://ofbiz.116.s1.nabble.com/Need-for-ProductRole-tp169561p169579.html

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ===