Thanks Adrian,
You mentioned that the DMRB is correct and should be followed but I
haven't been able to find anything the book covering product revisions
yet. Which Volumes/Chapters cover this?
I don't quite understand the "real-world eCommerce" problem you
mentioned. Are not the same problems faced when variants are
automatically created? Are you saying revision product auto-creation
shouldn't happen just for eCommerce-only scenarios?
Without a separate productId to represent the revision it seems the
revision field needs to be added to the OrderItem, QuoteItem, etc. entities.
On 01/13/2014 02:49 PM, [email protected] wrote:
Like a lot of things in OFBiz, sometimes we need to deviate a bit from
the DMRB.
The product revision model in the DMRB is technically correct and it
should be followed. The problem comes with real-world eCommerce web
sites - where the product ID is included in search engines and various
third-party services. Creating a new product ID with each revision
will break all of that external functionality. So, in that scenario,
it might be best to record a revision change without creating a new
product.
As long as we document the entity's purpose and why it is there, it
shouldn't be a problem. It will be an "alternate model". If an
enterprise needs detailed information on product revisions, then it
can use the model from the DMRB. Most likely, such an enterprise would
publish a GOOD IDENTIFICATION (which can be shared across product
revisions) to the outside world instead of a product ID.
-Adrian
Quoting Christian Carlow <[email protected]>:
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?
