You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by snowc <ch...@gmail.com> on 2009/08/07 21:14:53 UTC
product hierarchies
I have some customers that break second hand cars and trucks. When they
receive a vehicle for breaking, they would like to enter the vehicle into
ofbiz and also input the major components that the vehicle can be broken
into. The whole vehicle and the major components will be listed on the
ecommerce site.
Is this possible? how?
Many thank in advance...
--
View this message in context: http://www.nabble.com/product-hierarchies-tp24870315p24870315.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: product hierarchies
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Chris:
I would try something like this:
Product: productId = StockNum[E320C] productName= Engine, facilityId =
"my back yard"
|- ProductFeature name = condition, FeatureValue = new
|- ProductFeature name= model, FeatureValue = Volvo
|- ProductFeature name=make, FeatureValue = X
Product: productId = StockNum[DEF234], productName=Engine,
faclityId="lot 10"
|- ProductFeature name=condition, FeatureValue=engine seized, will not start
|- ProductFeature model, FeatureValue=Toyota
|- ProductFeature make, FeatureValue=Camery
|- ProductFeature model_year, FeatureValue=1996
...
Your virtual product is "Engine" and your variants are the physical
products: StockNums [E320C] and [DEF234]. Then you can decide how each
variant is associated with the virtual product. For example, you can
associate by the make, model, condition or year. Or perhaps all four.
I don't have time to try this out right now. But, you could try building
a couple of these with the Catalog Manager and seeing how they would
render (by default) on the ecommerce website. See if you can get the
desired result. If I get a chance in the next day or so, I'll see if I
can't try it. You may need to create some new feature types like
"condition".
Regards,
Ruth
snowc wrote:
> Hi Ruth,
>
> The stock number that is allocated is shared by all components of the
> vehicle. Therefore, the product ID would probably be a manufacturer
> identifier, e.g. E320C for a specific engine type.
>
> For an item of stock such as the engine E320C. The description and photos
> would be for the product, but each inventory item would probably need
> additional comments relating to the specific item. For example:
>
> Product: Engine[E320C]
> |-Inventory Item StockNum[ABC123] - condition new
> |-Inventory Item StockNum[DEF234] - engine seized. will not start.
>
> Would this type of structure work for virtual products? E.g. the Engine
> E320C is the virtual product. But Engine StockNum[ABC123] and Engine
> StockNum[DEF234] are the actual physical products with inventory items?
>
> Many thanks in advance, Chris.
>
>
> Ruth Hoffman-2 wrote:
>
>> Thanks. Please keep us posted.
>> Ruth
>> snowc wrote:
>>
>>> Hi Ruth,
>>>
>>> Please feel free to use this as an example.
>>>
>>> I have some more information to follow later...
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>>
>>> Ruth Hoffman-2 wrote:
>>>
>>>
>>>> Hi Chris:
>>>> Quick answer and MHO would be as follows (and I'm hardly an expert on
>>>> this, so others, feel free to chime in):
>>>> snowc wrote:
>>>>
>>>>
>>>>> Hi Ruth,
>>>>>
>>>>> When a vehicle is received, they would like to book the vehicle and
>>>>> each
>>>>> of
>>>>> it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
>>>>>
>>>>> Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
>>>>> Year[2000])
>>>>> |- Engine (e.g. ModelId[400E34])
>>>>> |- Gearbox (e.g. ModelId[5206B])
>>>>> |- Etc
>>>>>
>>>>> Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
>>>>> Year[1985])
>>>>> |- Engine (e.g. ModelId[231AA])
>>>>> |- Gearbox (e.g. ModelId[345BB])
>>>>> |- Etc
>>>>>
>>>>> When the vehicle is received whole, the component locations will be the
>>>>> same
>>>>> as the vehicle location. However, when broken, the individual
>>>>> components
>>>>> locations will be different.
>>>>>
>>>>> The customer would like to be able to answer customer enquiries such
>>>>> as:
>>>>> "Do
>>>>> you have any Ford Escort engines (model 231AA) in stock?".
>>>>>
>>>>> The customer would like to also list all stock (vehicle and components)
>>>>> on
>>>>> their website. They do not want ecommerce cart, just a list of
>>>>> available
>>>>> stock.
>>>>>
>>>>> I think I can maybe model the relationship between the vehicle and
>>>>> component
>>>>> as associations, e.g.:
>>>>>
>>>>> Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
>>>>> (StockRef[ABC234])
>>>>>
>>>>>
>>>>> Does this relationship make sense?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Yes. Here is my reasoning: Since you want to track and list major
>>>> components as entities separate from their source - a vehicle, I think
>>>> both the vehicle and each of the major components that you want to track
>>>> are "PRODUCTS". The productID could be the StockRef# or VIN depending on
>>>> the item (since I don't think gear boxes have VINs?).
>>>>
>>>> Then, for browsing (and tracking) purposes you could create one or more
>>>> product associations (bundles) so that an engine (StockRef#/VIN,
>>>> facilityID=still in the vehicle) may be associated with a vehicle (with
>>>> stockref #/VIN, facilityId = sitting on back lot) and a gearbox (with
>>>> stockref #, facilityId = building 10, shelf 2) may be associated with a
>>>> vehicle etc. You could even have categories set up to just show gear
>>>> boxes (as products) or entire vehicles.
>>>>
>>>> So, without actually trying this out with some test data, I can't really
>>>> say if it would work exactly as you envision. [if you don't mind I'd
>>>> like to use something like this example in the book since, as of today,
>>>> I don't really talk much about product associations. This would be a
>>>> great use-case.]
>>>>
>>>>
>>>>> For storing the attibutes such as make, model, year would feature be
>>>>> the
>>>>> best way? For example, if I create a feature hierarchy:
>>>>>
>>>>> Make (E.g. Ford)
>>>>> | - Model (e.g. Escort)
>>>>>
>>>>> I would also create a feature group for each Make/Model combination to
>>>>> constrain the allowed make model combinations.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Exactly how I would do it.
>>>> I like to keep things as simple as possible. And so, maybe I'm missing
>>>> something here - but I think that is all you need to do. Maybe someone
>>>> who has lots of experience with product data modeling and OFBiz could
>>>> comment?
>>>>
>>>>
>>>>> Does the above approach make sense?
>>>>>
>>>>> Many thanks in advance...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ruth Hoffman-2 wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Just curious - do they only want to list configurations (like
>>>>>> inventory)
>>>>>> or do they intend to sell either the vehicles or parts thereof?
>>>>>> Ruth
>>>>>> BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> yes.
>>>>>>> Could do it OOTB but a lot of data entry.
>>>>>>> Look at the PC configure for Ideas.
>>>>>>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>>>>>>> Customization would let them build a library of car models then it
>>>>>>> would
>>>>>>> automatically build the products.
>>>>>>>
>>>>>>>
>>>>>>> snowc sent the following on 8/7/2009 12:14 PM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I have some customers that break second hand cars and trucks. When
>>>>>>>> they
>>>>>>>> receive a vehicle for breaking, they would like to enter the vehicle
>>>>>>>> into
>>>>>>>> ofbiz and also input the major components that the vehicle can be
>>>>>>>> broken
>>>>>>>> into. The whole vehicle and the major components will be listed on
>>>>>>>> the
>>>>>>>> ecommerce site.
>>>>>>>>
>>>>>>>> Is this possible? how?
>>>>>>>>
>>>>>>>> Many thank in advance...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: product hierarchies
Posted by snowc <ch...@gmail.com>.
Hi Ruth,
The stock number that is allocated is shared by all components of the
vehicle. Therefore, the product ID would probably be a manufacturer
identifier, e.g. E320C for a specific engine type.
For an item of stock such as the engine E320C. The description and photos
would be for the product, but each inventory item would probably need
additional comments relating to the specific item. For example:
Product: Engine[E320C]
|-Inventory Item StockNum[ABC123] - condition new
|-Inventory Item StockNum[DEF234] - engine seized. will not start.
Would this type of structure work for virtual products? E.g. the Engine
E320C is the virtual product. But Engine StockNum[ABC123] and Engine
StockNum[DEF234] are the actual physical products with inventory items?
Many thanks in advance, Chris.
Ruth Hoffman-2 wrote:
>
> Thanks. Please keep us posted.
> Ruth
> snowc wrote:
>> Hi Ruth,
>>
>> Please feel free to use this as an example.
>>
>> I have some more information to follow later...
>>
>> Many thanks,
>>
>> Chris
>>
>>
>> Ruth Hoffman-2 wrote:
>>
>>> Hi Chris:
>>> Quick answer and MHO would be as follows (and I'm hardly an expert on
>>> this, so others, feel free to chime in):
>>> snowc wrote:
>>>
>>>> Hi Ruth,
>>>>
>>>> When a vehicle is received, they would like to book the vehicle and
>>>> each
>>>> of
>>>> it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
>>>>
>>>> Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
>>>> Year[2000])
>>>> |- Engine (e.g. ModelId[400E34])
>>>> |- Gearbox (e.g. ModelId[5206B])
>>>> |- Etc
>>>>
>>>> Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
>>>> Year[1985])
>>>> |- Engine (e.g. ModelId[231AA])
>>>> |- Gearbox (e.g. ModelId[345BB])
>>>> |- Etc
>>>>
>>>> When the vehicle is received whole, the component locations will be the
>>>> same
>>>> as the vehicle location. However, when broken, the individual
>>>> components
>>>> locations will be different.
>>>>
>>>> The customer would like to be able to answer customer enquiries such
>>>> as:
>>>> "Do
>>>> you have any Ford Escort engines (model 231AA) in stock?".
>>>>
>>>> The customer would like to also list all stock (vehicle and components)
>>>> on
>>>> their website. They do not want ecommerce cart, just a list of
>>>> available
>>>> stock.
>>>>
>>>> I think I can maybe model the relationship between the vehicle and
>>>> component
>>>> as associations, e.g.:
>>>>
>>>> Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
>>>> (StockRef[ABC234])
>>>>
>>>>
>>>> Does this relationship make sense?
>>>>
>>>>
>>>>
>>> Yes. Here is my reasoning: Since you want to track and list major
>>> components as entities separate from their source - a vehicle, I think
>>> both the vehicle and each of the major components that you want to track
>>> are "PRODUCTS". The productID could be the StockRef# or VIN depending on
>>> the item (since I don't think gear boxes have VINs?).
>>>
>>> Then, for browsing (and tracking) purposes you could create one or more
>>> product associations (bundles) so that an engine (StockRef#/VIN,
>>> facilityID=still in the vehicle) may be associated with a vehicle (with
>>> stockref #/VIN, facilityId = sitting on back lot) and a gearbox (with
>>> stockref #, facilityId = building 10, shelf 2) may be associated with a
>>> vehicle etc. You could even have categories set up to just show gear
>>> boxes (as products) or entire vehicles.
>>>
>>> So, without actually trying this out with some test data, I can't really
>>> say if it would work exactly as you envision. [if you don't mind I'd
>>> like to use something like this example in the book since, as of today,
>>> I don't really talk much about product associations. This would be a
>>> great use-case.]
>>>
>>>> For storing the attibutes such as make, model, year would feature be
>>>> the
>>>> best way? For example, if I create a feature hierarchy:
>>>>
>>>> Make (E.g. Ford)
>>>> | - Model (e.g. Escort)
>>>>
>>>> I would also create a feature group for each Make/Model combination to
>>>> constrain the allowed make model combinations.
>>>>
>>>>
>>>>
>>> Exactly how I would do it.
>>> I like to keep things as simple as possible. And so, maybe I'm missing
>>> something here - but I think that is all you need to do. Maybe someone
>>> who has lots of experience with product data modeling and OFBiz could
>>> comment?
>>>
>>>> Does the above approach make sense?
>>>>
>>>> Many thanks in advance...
>>>>
>>>>
>>>>
>>>>
>>>> Ruth Hoffman-2 wrote:
>>>>
>>>>
>>>>> Just curious - do they only want to list configurations (like
>>>>> inventory)
>>>>> or do they intend to sell either the vehicles or parts thereof?
>>>>> Ruth
>>>>> BJ Freeman wrote:
>>>>>
>>>>>
>>>>>> yes.
>>>>>> Could do it OOTB but a lot of data entry.
>>>>>> Look at the PC configure for Ideas.
>>>>>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>>>>>> Customization would let them build a library of car models then it
>>>>>> would
>>>>>> automatically build the products.
>>>>>>
>>>>>>
>>>>>> snowc sent the following on 8/7/2009 12:14 PM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I have some customers that break second hand cars and trucks. When
>>>>>>> they
>>>>>>> receive a vehicle for breaking, they would like to enter the vehicle
>>>>>>> into
>>>>>>> ofbiz and also input the major components that the vehicle can be
>>>>>>> broken
>>>>>>> into. The whole vehicle and the major components will be listed on
>>>>>>> the
>>>>>>> ecommerce site.
>>>>>>>
>>>>>>> Is this possible? how?
>>>>>>>
>>>>>>> Many thank in advance...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/product-hierarchies-tp24870315p25011111.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: product hierarchies
Posted by Ruth Hoffman <rh...@aesolves.com>.
Thanks. Please keep us posted.
Ruth
snowc wrote:
> Hi Ruth,
>
> Please feel free to use this as an example.
>
> I have some more information to follow later...
>
> Many thanks,
>
> Chris
>
>
> Ruth Hoffman-2 wrote:
>
>> Hi Chris:
>> Quick answer and MHO would be as follows (and I'm hardly an expert on
>> this, so others, feel free to chime in):
>> snowc wrote:
>>
>>> Hi Ruth,
>>>
>>> When a vehicle is received, they would like to book the vehicle and each
>>> of
>>> it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
>>>
>>> Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
>>> Year[2000])
>>> |- Engine (e.g. ModelId[400E34])
>>> |- Gearbox (e.g. ModelId[5206B])
>>> |- Etc
>>>
>>> Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
>>> Year[1985])
>>> |- Engine (e.g. ModelId[231AA])
>>> |- Gearbox (e.g. ModelId[345BB])
>>> |- Etc
>>>
>>> When the vehicle is received whole, the component locations will be the
>>> same
>>> as the vehicle location. However, when broken, the individual components
>>> locations will be different.
>>>
>>> The customer would like to be able to answer customer enquiries such as:
>>> "Do
>>> you have any Ford Escort engines (model 231AA) in stock?".
>>>
>>> The customer would like to also list all stock (vehicle and components)
>>> on
>>> their website. They do not want ecommerce cart, just a list of available
>>> stock.
>>>
>>> I think I can maybe model the relationship between the vehicle and
>>> component
>>> as associations, e.g.:
>>>
>>> Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
>>> (StockRef[ABC234])
>>>
>>>
>>> Does this relationship make sense?
>>>
>>>
>>>
>> Yes. Here is my reasoning: Since you want to track and list major
>> components as entities separate from their source - a vehicle, I think
>> both the vehicle and each of the major components that you want to track
>> are "PRODUCTS". The productID could be the StockRef# or VIN depending on
>> the item (since I don't think gear boxes have VINs?).
>>
>> Then, for browsing (and tracking) purposes you could create one or more
>> product associations (bundles) so that an engine (StockRef#/VIN,
>> facilityID=still in the vehicle) may be associated with a vehicle (with
>> stockref #/VIN, facilityId = sitting on back lot) and a gearbox (with
>> stockref #, facilityId = building 10, shelf 2) may be associated with a
>> vehicle etc. You could even have categories set up to just show gear
>> boxes (as products) or entire vehicles.
>>
>> So, without actually trying this out with some test data, I can't really
>> say if it would work exactly as you envision. [if you don't mind I'd
>> like to use something like this example in the book since, as of today,
>> I don't really talk much about product associations. This would be a
>> great use-case.]
>>
>>> For storing the attibutes such as make, model, year would feature be the
>>> best way? For example, if I create a feature hierarchy:
>>>
>>> Make (E.g. Ford)
>>> | - Model (e.g. Escort)
>>>
>>> I would also create a feature group for each Make/Model combination to
>>> constrain the allowed make model combinations.
>>>
>>>
>>>
>> Exactly how I would do it.
>> I like to keep things as simple as possible. And so, maybe I'm missing
>> something here - but I think that is all you need to do. Maybe someone
>> who has lots of experience with product data modeling and OFBiz could
>> comment?
>>
>>> Does the above approach make sense?
>>>
>>> Many thanks in advance...
>>>
>>>
>>>
>>>
>>> Ruth Hoffman-2 wrote:
>>>
>>>
>>>> Just curious - do they only want to list configurations (like inventory)
>>>> or do they intend to sell either the vehicles or parts thereof?
>>>> Ruth
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>> yes.
>>>>> Could do it OOTB but a lot of data entry.
>>>>> Look at the PC configure for Ideas.
>>>>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>>>>> Customization would let them build a library of car models then it
>>>>> would
>>>>> automatically build the products.
>>>>>
>>>>>
>>>>> snowc sent the following on 8/7/2009 12:14 PM:
>>>>>
>>>>>
>>>>>
>>>>>> I have some customers that break second hand cars and trucks. When
>>>>>> they
>>>>>> receive a vehicle for breaking, they would like to enter the vehicle
>>>>>> into
>>>>>> ofbiz and also input the major components that the vehicle can be
>>>>>> broken
>>>>>> into. The whole vehicle and the major components will be listed on
>>>>>> the
>>>>>> ecommerce site.
>>>>>>
>>>>>> Is this possible? how?
>>>>>>
>>>>>> Many thank in advance...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: product hierarchies
Posted by snowc <ch...@gmail.com>.
Hi Ruth,
Please feel free to use this as an example.
I have some more information to follow later...
Many thanks,
Chris
Ruth Hoffman-2 wrote:
>
> Hi Chris:
> Quick answer and MHO would be as follows (and I'm hardly an expert on
> this, so others, feel free to chime in):
> snowc wrote:
>> Hi Ruth,
>>
>> When a vehicle is received, they would like to book the vehicle and each
>> of
>> it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
>>
>> Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
>> Year[2000])
>> |- Engine (e.g. ModelId[400E34])
>> |- Gearbox (e.g. ModelId[5206B])
>> |- Etc
>>
>> Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
>> Year[1985])
>> |- Engine (e.g. ModelId[231AA])
>> |- Gearbox (e.g. ModelId[345BB])
>> |- Etc
>>
>> When the vehicle is received whole, the component locations will be the
>> same
>> as the vehicle location. However, when broken, the individual components
>> locations will be different.
>>
>> The customer would like to be able to answer customer enquiries such as:
>> "Do
>> you have any Ford Escort engines (model 231AA) in stock?".
>>
>> The customer would like to also list all stock (vehicle and components)
>> on
>> their website. They do not want ecommerce cart, just a list of available
>> stock.
>>
>> I think I can maybe model the relationship between the vehicle and
>> component
>> as associations, e.g.:
>>
>> Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
>> (StockRef[ABC234])
>>
>>
>> Does this relationship make sense?
>>
>>
> Yes. Here is my reasoning: Since you want to track and list major
> components as entities separate from their source - a vehicle, I think
> both the vehicle and each of the major components that you want to track
> are "PRODUCTS". The productID could be the StockRef# or VIN depending on
> the item (since I don't think gear boxes have VINs?).
>
> Then, for browsing (and tracking) purposes you could create one or more
> product associations (bundles) so that an engine (StockRef#/VIN,
> facilityID=still in the vehicle) may be associated with a vehicle (with
> stockref #/VIN, facilityId = sitting on back lot) and a gearbox (with
> stockref #, facilityId = building 10, shelf 2) may be associated with a
> vehicle etc. You could even have categories set up to just show gear
> boxes (as products) or entire vehicles.
>
> So, without actually trying this out with some test data, I can't really
> say if it would work exactly as you envision. [if you don't mind I'd
> like to use something like this example in the book since, as of today,
> I don't really talk much about product associations. This would be a
> great use-case.]
>> For storing the attibutes such as make, model, year would feature be the
>> best way? For example, if I create a feature hierarchy:
>>
>> Make (E.g. Ford)
>> | - Model (e.g. Escort)
>>
>> I would also create a feature group for each Make/Model combination to
>> constrain the allowed make model combinations.
>>
>>
> Exactly how I would do it.
> I like to keep things as simple as possible. And so, maybe I'm missing
> something here - but I think that is all you need to do. Maybe someone
> who has lots of experience with product data modeling and OFBiz could
> comment?
>> Does the above approach make sense?
>>
>> Many thanks in advance...
>>
>>
>>
>>
>> Ruth Hoffman-2 wrote:
>>
>>> Just curious - do they only want to list configurations (like inventory)
>>> or do they intend to sell either the vehicles or parts thereof?
>>> Ruth
>>> BJ Freeman wrote:
>>>
>>>> yes.
>>>> Could do it OOTB but a lot of data entry.
>>>> Look at the PC configure for Ideas.
>>>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>>>> Customization would let them build a library of car models then it
>>>> would
>>>> automatically build the products.
>>>>
>>>>
>>>> snowc sent the following on 8/7/2009 12:14 PM:
>>>>
>>>>
>>>>> I have some customers that break second hand cars and trucks. When
>>>>> they
>>>>> receive a vehicle for breaking, they would like to enter the vehicle
>>>>> into
>>>>> ofbiz and also input the major components that the vehicle can be
>>>>> broken
>>>>> into. The whole vehicle and the major components will be listed on
>>>>> the
>>>>> ecommerce site.
>>>>>
>>>>> Is this possible? how?
>>>>>
>>>>> Many thank in advance...
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/product-hierarchies-tp24870315p25003579.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: product hierarchies
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Chris:
Quick answer and MHO would be as follows (and I'm hardly an expert on
this, so others, feel free to chime in):
snowc wrote:
> Hi Ruth,
>
> When a vehicle is received, they would like to book the vehicle and each of
> it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
>
> Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
> Year[2000])
> |- Engine (e.g. ModelId[400E34])
> |- Gearbox (e.g. ModelId[5206B])
> |- Etc
>
> Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
> Year[1985])
> |- Engine (e.g. ModelId[231AA])
> |- Gearbox (e.g. ModelId[345BB])
> |- Etc
>
> When the vehicle is received whole, the component locations will be the same
> as the vehicle location. However, when broken, the individual components
> locations will be different.
>
> The customer would like to be able to answer customer enquiries such as: "Do
> you have any Ford Escort engines (model 231AA) in stock?".
>
> The customer would like to also list all stock (vehicle and components) on
> their website. They do not want ecommerce cart, just a list of available
> stock.
>
> I think I can maybe model the relationship between the vehicle and component
> as associations, e.g.:
>
> Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
> (StockRef[ABC234])
>
>
> Does this relationship make sense?
>
>
Yes. Here is my reasoning: Since you want to track and list major
components as entities separate from their source - a vehicle, I think
both the vehicle and each of the major components that you want to track
are "PRODUCTS". The productID could be the StockRef# or VIN depending on
the item (since I don't think gear boxes have VINs?).
Then, for browsing (and tracking) purposes you could create one or more
product associations (bundles) so that an engine (StockRef#/VIN,
facilityID=still in the vehicle) may be associated with a vehicle (with
stockref #/VIN, facilityId = sitting on back lot) and a gearbox (with
stockref #, facilityId = building 10, shelf 2) may be associated with a
vehicle etc. You could even have categories set up to just show gear
boxes (as products) or entire vehicles.
So, without actually trying this out with some test data, I can't really
say if it would work exactly as you envision. [if you don't mind I'd
like to use something like this example in the book since, as of today,
I don't really talk much about product associations. This would be a
great use-case.]
> For storing the attibutes such as make, model, year would feature be the
> best way? For example, if I create a feature hierarchy:
>
> Make (E.g. Ford)
> | - Model (e.g. Escort)
>
> I would also create a feature group for each Make/Model combination to
> constrain the allowed make model combinations.
>
>
Exactly how I would do it.
I like to keep things as simple as possible. And so, maybe I'm missing
something here - but I think that is all you need to do. Maybe someone
who has lots of experience with product data modeling and OFBiz could
comment?
> Does the above approach make sense?
>
> Many thanks in advance...
>
>
>
>
> Ruth Hoffman-2 wrote:
>
>> Just curious - do they only want to list configurations (like inventory)
>> or do they intend to sell either the vehicles or parts thereof?
>> Ruth
>> BJ Freeman wrote:
>>
>>> yes.
>>> Could do it OOTB but a lot of data entry.
>>> Look at the PC configure for Ideas.
>>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>>> Customization would let them build a library of car models then it would
>>> automatically build the products.
>>>
>>>
>>> snowc sent the following on 8/7/2009 12:14 PM:
>>>
>>>
>>>> I have some customers that break second hand cars and trucks. When they
>>>> receive a vehicle for breaking, they would like to enter the vehicle
>>>> into
>>>> ofbiz and also input the major components that the vehicle can be broken
>>>> into. The whole vehicle and the major components will be listed on the
>>>> ecommerce site.
>>>>
>>>> Is this possible? how?
>>>>
>>>> Many thank in advance...
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: product hierarchies
Posted by snowc <ch...@gmail.com>.
Hi Ruth,
When a vehicle is received, they would like to book the vehicle and each of
it's main components (Engine, Gearbox, Axles, Body, Etc) into stock:
Vehicle (e.g. StockRef[ABC123] Make[Volvo] Model[F10] Type[4x2 TU]
Year[2000])
|- Engine (e.g. ModelId[400E34])
|- Gearbox (e.g. ModelId[5206B])
|- Etc
Vehicle (e.g. StockRef[ABC234] Make[Ford] Model[Escort] Type[Sedan]
Year[1985])
|- Engine (e.g. ModelId[231AA])
|- Gearbox (e.g. ModelId[345BB])
|- Etc
When the vehicle is received whole, the component locations will be the same
as the vehicle location. However, when broken, the individual components
locations will be different.
The customer would like to be able to answer customer enquiries such as: "Do
you have any Ford Escort engines (model 231AA) in stock?".
The customer would like to also list all stock (vehicle and components) on
their website. They do not want ecommerce cart, just a list of available
stock.
I think I can maybe model the relationship between the vehicle and component
as associations, e.g.:
Engine (StockRef[231AA]) is an "Actual Product Component" of Vehicle
(StockRef[ABC234])
Does this relationship make sense?
For storing the attibutes such as make, model, year would feature be the
best way? For example, if I create a feature hierarchy:
Make (E.g. Ford)
| - Model (e.g. Escort)
I would also create a feature group for each Make/Model combination to
constrain the allowed make model combinations.
Does the above approach make sense?
Many thanks in advance...
Ruth Hoffman-2 wrote:
>
> Just curious - do they only want to list configurations (like inventory)
> or do they intend to sell either the vehicles or parts thereof?
> Ruth
> BJ Freeman wrote:
>> yes.
>> Could do it OOTB but a lot of data entry.
>> Look at the PC configure for Ideas.
>> https://demo.ofbiz.org/catalog/control/EditProductConfigs?productId=PC001
>> Customization would let them build a library of car models then it would
>> automatically build the products.
>>
>>
>> snowc sent the following on 8/7/2009 12:14 PM:
>>
>>> I have some customers that break second hand cars and trucks. When they
>>> receive a vehicle for breaking, they would like to enter the vehicle
>>> into
>>> ofbiz and also input the major components that the vehicle can be broken
>>> into. The whole vehicle and the major components will be listed on the
>>> ecommerce site.
>>>
>>> Is this possible? how?
>>>
>>> Many thank in advance...
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/product-hierarchies-tp24870315p24981526.html
Sent from the OFBiz - User mailing list archive at Nabble.com.