If ProductRevision were created then it seems additional entities such
as OrderItemProductRevision would need to be created or alternatively
the OrderItem entity would need to include the productRevisionId field.
Adding the ability to handle a new revision field in entities such as
OrderItem, etc. seems like a lot of work.
Maybe operations could be performed similar to how variant products are
automatically created when virtual features are selected? So if a new
ProductRevision record gets created then a new Product is created to
provide a separate productId for the revision. This seems fairly
similar to how ProductAssoc is already used except the productId to be
related already exists instead of automatically being created.
I haven't found any DEMO data using the ProductAssocTypeId=REVISION yet
so I'm not sure how such records are intended to be handled. If new
Product records were to be created for each product revision, I'm not
sure if ProductAssoc records with productAssocTypeId=REVISION would need
to be created. Also ProductAssoc would still be needed to track
revisions of revisions.
Maybe ProductRevision should be used to associate a virtual-like product
to its revisions and the ProductAssoc entity used to related the
revisions with other revisions.
On 01/13/2014 01:06 PM, Christian Carlow wrote:
Thanks Adrian,
ProductRevision entity seems like the best way to go so far. If this
were implemented, wouldn't the productId lookup field query need to be
changed to include revision numbers in the search (joining of Product
and ProductRevision entitites)?
The specification document that goes with the product determines the
revision so I think the ProductContent entity would have to be updated
to account for the different revisions when relating Specification
Content Documents. Or maybe the Content or Document entity should
include a revision to match with the related product revision?
I wonder if its worth creating a JIRA issue this early in the discussion.
On 01/13/2014 11:05 AM, [email protected] wrote:
It might be better to have a ProductRevision entity with an effective
date field.
-Adrian
Quoting Christian Carlow <[email protected]>:
Thanks Adrian,
I agree with your awkward perspective. Preferably I would like the
users to be able to select the revision as they are typing the
productId but currently only the internalName and brandName are
listed. Does anyone think adding a revision field to Product to be
specified along with internalName and brandName would be a bad
design choice? If not I could change the productId lookup to
include the revision field in the search results.
On 01/13/2014 08:46 AM, [email protected] wrote:
A GOOD IDENTIFICATION is a code to uniquely identify goods or
services (DMRB, chapter 3). A revision identifier could be included
in that definition, but that seems a bit awkward.
-Adrian
Quoting Christian Carlow <[email protected]>:
Or maybe use the GoodIdentification entity and add a
GoodIdentificationTypeId="REVISION"?
On 01/13/2014 07:51 AM, Christian Carlow wrote:
Has anyone used OFBiz to track product revisions yet? I see a
prodAssocTypeId=REVISION on the Product Associations page but
need to be able to specify the revision number somewhere. Should
the the revision stored in ProductAttribute or as a feature?
