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...
