How store product revisions?

[Christian Carlow-OFBizzer]

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?

[Christian Carlow-OFBizzer]

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?

[Christian Carlow-OFBizzer]

The drawing number of the product also has to be stored and it seems
related to the revision.  It seems like the drawing number should be
stored as ProductContent with productContentTypeId="SPECIFICATION" with
the actual drawing number stored in the "Product Description" field.  
Should the revision relate to the SPECIFICATION content and have the
product revision based on the SPECIFICATION revision?

I'm looking at the Manufacting section of the Data Model Resource Book
V2 which covers part specifications and documentation.

On 01/13/2014 07:58 AM, Christian Carlow wrote:
> 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?
>

[Adrian Crum-3]

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 <[hidden email]>:

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

[Christian Carlow-OFBizzer]

Seems like OFBiz has diverged from the way that the Data Model Resource
book intended specification, revision, and documents to be handled.

It uses the DOCUMENT entity with subType PRODUCT_DOCUMENT with the
further subtype  PRODUCT_DRAWING to tracking drawings.  A separate
SPECIFICATION entity is used to store the actual specs that might be
provided in documents such as tolerances and other constraints.

On 01/13/2014 08:34 AM, Christian Carlow wrote:

> The drawing number of the product also has to be stored and it seems
> related to the revision.  It seems like the drawing number should be
> stored as ProductContent with productContentTypeId="SPECIFICATION"
> with the actual drawing number stored in the "Product Description"
> field.  Should the revision relate to the SPECIFICATION content and
> have the product revision based on the SPECIFICATION revision?
>
> I'm looking at the Manufacting section of the Data Model Resource Book
> V2 which covers part specifications and documentation.
>
> On 01/13/2014 07:58 AM, Christian Carlow wrote:
>> 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?
>>
>

[Christian Carlow-OFBizzer]

I'm working on quotes and need the ability for the user to select
specific revisions of a part to quote but the productId field does not
list the product revisions.  One way might be to suffix the productId
with "-REV-A" or "-REV-B".  Otherwise I think I'll have to create a
custom productId query so that the revision (wherever it will be stored)
will appear in the productId list.

On 01/13/2014 08:58 AM, Christian Carlow wrote:

> Seems like OFBiz has diverged from the way that the Data Model
> Resource book intended specification, revision, and documents to be
> handled.
>
> It uses the DOCUMENT entity with subType PRODUCT_DOCUMENT with the
> further subtype  PRODUCT_DRAWING to tracking drawings.  A separate
> SPECIFICATION entity is used to store the actual specs that might be
> provided in documents such as tolerances and other constraints.
>
> On 01/13/2014 08:34 AM, Christian Carlow wrote:
>> The drawing number of the product also has to be stored and it seems
>> related to the revision.  It seems like the drawing number should be
>> stored as ProductContent with productContentTypeId="SPECIFICATION"
>> with the actual drawing number stored in the "Product Description"
>> field.  Should the revision relate to the SPECIFICATION content and
>> have the product revision based on the SPECIFICATION revision?
>>
>> I'm looking at the Manufacting section of the Data Model Resource
>> Book V2 which covers part specifications and documentation.
>>
>> On 01/13/2014 07:58 AM, Christian Carlow wrote:
>>> 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?
>>>
>>
>

[Christian Carlow-OFBizzer]

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, [hidden email] 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 <[hidden email]>:
>
>> 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?
>>
>>
>
>
>

[Adrian Crum-3]

It might be better to have a ProductRevision entity with an effective  
date field.

-Adrian

Quoting Christian Carlow <[hidden email]>:

> 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, [hidden email] 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 <[hidden email]>:
>>
>>> 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?
>>>
>>>
>>
>>
>>
>
>

[Pierre Smits]

Under the 'Associations' tab of a product you can connect to another
product with an association type of 'Revision'.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Christian Carlow-OFBizzer]

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, [hidden email] wrote:

> It might be better to have a ProductRevision entity with an effective
> date field.
>
> -Adrian
>
> Quoting Christian Carlow <[hidden email]>:
>
>> 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, [hidden email] 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 <[hidden email]>:
>>>
>>>> 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?
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Christian Carlow-OFBizzer]

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, [hidden email] wrote:
>> It might be better to have a ProductRevision entity with an effective
>> date field.
>>
>> -Adrian
>>
>> Quoting Christian Carlow <[hidden email]>:
>>
>>> 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, [hidden email] 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 <[hidden email]>:
>>>>
>>>>> 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?
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Adrian Crum-3]

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 <[hidden email]>:

> 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, [hidden email] wrote:
>> It might be better to have a ProductRevision entity with an  
>> effective date field.
>>
>> -Adrian
>>
>> Quoting Christian Carlow <[hidden email]>:
>>
>>> 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, [hidden email] 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 <[hidden email]>:
>>>>
>>>>> 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?
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

[Christian Carlow-OFBizzer]

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, [hidden email] 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 <[hidden email]>:
>
>> 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, [hidden email] wrote:
>>> It might be better to have a ProductRevision entity with an
>>> effective date field.
>>>
>>> -Adrian
>>>
>>> Quoting Christian Carlow <[hidden email]>:
>>>
>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-3]

Well, you can make things as complicated as you please. I was simply
trying to offer a suggestion for a shortcut.

I don't know what your requirements are, so I don't understand why you
need to persist the product revision in order items, quote items, and in
third-party advertising.

Most people are only interested in purchasing a Widget. They don't care
if it is Widget revision A or Widget revision B. Usually, that level of
detail is only a concern in an internal organization.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/13/2014 4:57 PM, Christian Carlow wrote:

> 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, [hidden email] 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 <[hidden email]>:
>>
>>> 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, [hidden email] wrote:
>>>> It might be better to have a ProductRevision entity with an
>>>> effective date field.
>>>>
>>>> -Adrian
>>>>
>>>> Quoting Christian Carlow <[hidden email]>:
>>>>
>>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Christian Carlow-OFBizzer]

Thanks Adrian,

The customers will always order the newest revision so I could use the
ProductRevision.effectiveDate you mentioned to determine the revision
according to the quote and order dates.  I suppose the specification
revision could be determined according to the fromDate and thruDate
also.  Its sort of an weak/indirect way of linking the revisions to
products but I think it will suffice. The users will have to make sure
they are careful when changing revision or product-referencing entity dates.

Luckily I can take your shortcut but if there is some enterprise out
there with customer needing to choose specific revisions then more work
will be needed before OFBiz can support it.  It seems possible that many
entities that reference the productId would also need to account for
revision in some way.

I'll create a JIRA issue to add this feature.

On 01/13/2014 05:16 PM, Adrian Crum wrote:

> Well, you can make things as complicated as you please. I was simply
> trying to offer a suggestion for a shortcut.
>
> I don't know what your requirements are, so I don't understand why you
> need to persist the product revision in order items, quote items, and
> in third-party advertising.
>
> Most people are only interested in purchasing a Widget. They don't
> care if it is Widget revision A or Widget revision B. Usually, that
> level of detail is only a concern in an internal organization.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/13/2014 4:57 PM, Christian Carlow wrote:
>> 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, [hidden email] 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 <[hidden email]>:
>>>
>>>> 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, [hidden email] wrote:
>>>>> It might be better to have a ProductRevision entity with an
>>>>> effective date field.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Quoting Christian Carlow <[hidden email]>:
>>>>>
>>>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>

[Adrian Crum-3]

If an enterprise needs to give customers the ability to order specific
versions of a product, then it can create a new product for each version.

That is why it is called an alternate model. There are other examples of
this in the DMRB and in OFBiz. A business can choose the model that
works for them.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/13/2014 7:14 PM, Christian Carlow wrote:

> Thanks Adrian,
>
> The customers will always order the newest revision so I could use the
> ProductRevision.effectiveDate you mentioned to determine the revision
> according to the quote and order dates.  I suppose the specification
> revision could be determined according to the fromDate and thruDate
> also.  Its sort of an weak/indirect way of linking the revisions to
> products but I think it will suffice. The users will have to make sure
> they are careful when changing revision or product-referencing entity
> dates.
>
> Luckily I can take your shortcut but if there is some enterprise out
> there with customer needing to choose specific revisions then more work
> will be needed before OFBiz can support it.  It seems possible that many
> entities that reference the productId would also need to account for
> revision in some way.
>
> I'll create a JIRA issue to add this feature.
>
> On 01/13/2014 05:16 PM, Adrian Crum wrote:
>> Well, you can make things as complicated as you please. I was simply
>> trying to offer a suggestion for a shortcut.
>>
>> I don't know what your requirements are, so I don't understand why you
>> need to persist the product revision in order items, quote items, and
>> in third-party advertising.
>>
>> Most people are only interested in purchasing a Widget. They don't
>> care if it is Widget revision A or Widget revision B. Usually, that
>> level of detail is only a concern in an internal organization.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/13/2014 4:57 PM, Christian Carlow wrote:
>>> 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, [hidden email] 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 <[hidden email]>:
>>>>
>>>>> 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, [hidden email] wrote:
>>>>>> It might be better to have a ProductRevision entity with an
>>>>>> effective date field.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Quoting Christian Carlow <[hidden email]>:
>>>>>>
>>>>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>

[Christian Carlow-OFBizzer]

Thanks again Adrian,

I now see that I can simply create a separate product for each revision
and append the revision identifier to the end of the internalName so
that it appears in search results which is the primary reason the
initial message was created.  Some reports have to group revisions as
the same product in summary calculations so I guess the product
revisions should be variants of a virtual product without a revision
identifier appended to the end of the internalName to accomplish this.

On 01/13/2014 06:23 PM, Adrian Crum wrote:

> If an enterprise needs to give customers the ability to order specific
> versions of a product, then it can create a new product for each version.
>
> That is why it is called an alternate model. There are other examples
> of this in the DMRB and in OFBiz. A business can choose the model that
> works for them.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/13/2014 7:14 PM, Christian Carlow wrote:
>> Thanks Adrian,
>>
>> The customers will always order the newest revision so I could use the
>> ProductRevision.effectiveDate you mentioned to determine the revision
>> according to the quote and order dates.  I suppose the specification
>> revision could be determined according to the fromDate and thruDate
>> also.  Its sort of an weak/indirect way of linking the revisions to
>> products but I think it will suffice. The users will have to make sure
>> they are careful when changing revision or product-referencing entity
>> dates.
>>
>> Luckily I can take your shortcut but if there is some enterprise out
>> there with customer needing to choose specific revisions then more work
>> will be needed before OFBiz can support it.  It seems possible that many
>> entities that reference the productId would also need to account for
>> revision in some way.
>>
>> I'll create a JIRA issue to add this feature.
>>
>> On 01/13/2014 05:16 PM, Adrian Crum wrote:
>>> Well, you can make things as complicated as you please. I was simply
>>> trying to offer a suggestion for a shortcut.
>>>
>>> I don't know what your requirements are, so I don't understand why you
>>> need to persist the product revision in order items, quote items, and
>>> in third-party advertising.
>>>
>>> Most people are only interested in purchasing a Widget. They don't
>>> care if it is Widget revision A or Widget revision B. Usually, that
>>> level of detail is only a concern in an internal organization.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 1/13/2014 4:57 PM, Christian Carlow wrote:
>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>
>>>>>> 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, [hidden email] wrote:
>>>>>>> It might be better to have a ProductRevision entity with an
>>>>>>> effective date field.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> Quoting Christian Carlow <[hidden email]>:
>>>>>>>
>>>>>>>> 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, [hidden email] 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 <[hidden email]>:
>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>