product hierarchies
Locked
 
|
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... |
|
|
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... -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator. |
|
|
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... >> > > |
|
|
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...
|
|
|
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? > > 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. > > 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... >>>> >>>> >>> >>> >> >> > > |
|
|
Hi Ruth,
Please feel free to use this as an example. I have some more information to follow later... Many thanks, Chris
|
|
|
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... >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
|
|
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.
|
|
|
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... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |