You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Scott Gray <sc...@hotwaxmedia.com> on 2010/05/01 00:06:49 UTC
Re: Storing supplier provided account number
On 1/05/2010, at 3:52 AM, Adam Heath wrote:
> Scott Gray wrote:
>> I think Agreements are more like the terms of a relationship and can change over the course of that relationship.
>>
>> I would tend to think of an account number as being more like relationship meta data that exists so long as the relationship exists and for that reason I would either add a generic field to PartyRelationship or otherwise add a new entity SupplierRelationship and one-to-one it with PartyRelationship.
>
> I like the latter, SupplierRelationship, as there could be an
> unbounded set of SupplierIdentificationType and
> SupplierIdentificationPurpose fields.
That wasn't what I was suggesting, I was describing SupplierRelationship as being an extension to PartyRelationship in the same way that Person or PartyGroup extends Party.
> Type has IDENTIER as a parent, then SECURITY_CARD, EMPLOYEE_ID as
> children.
>
> And, in that vein, SECURITY_CARD could very well change over time too,
> separate from the parent PartyRelationship.
I'm not sure how I would handle something like a security card but IMO the Employment entity should be an extension to PartyRelationship, I mean it already shares the same primary key fields.
Regards
Scott
Re: Storing supplier provided account number
Posted by Robert Morley <rm...@emforium.com>.
On May 4, 2010, at 12:59 AM, Scott Gray wrote:
>
> Personally I like using natural PKs whenever possible and the number
> of them doesn't really bother me with all the tools we have for auto-
> setting fields.
>
> It would be interesting to see if there is some way to smarten up
> the entity engine so that these sub-types could be more deeply
> integrated. I have no idea at the moment what form that might take
> though.
>
FYI -- Patch created as part of JIRA OFBIZ-3764.
Re: Storing supplier provided account number
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 4/05/2010, at 2:22 PM, Bob Morley wrote:
> Scott Gray-2 wrote:
>>
>> I think you missed the second half of my earlier email:
>>> I'm not sure how I would handle something like a security card but IMO
>>> the Employment entity should be an extension to PartyRelationship, I mean
>>> it already shares the same primary key fields.
>>
>> Employment already has the same PK fields as PartyRelationship.
>>
>
> Yep; I had definitely glossed over that. In my head I was thinking that
> PartyRelationship had a partyRelationshipId that could be added to
> Employment and Employment could have those other fields removed. But you
> are quite correct, we could simply use the existing primary key fields.
>
> Would there be any thought to doing the former? I don't think I want to
> bite that off to be honest, but one could create the entity such that it has
> a single primary key and the others would make up a unique index.
> Personally, I don't know if that is a good idea but it would reduce
> redundancy in the sub-classes.
Personally I like using natural PKs whenever possible and the number of them doesn't really bother me with all the tools we have for auto-setting fields.
It would be interesting to see if there is some way to smarten up the entity engine so that these sub-types could be more deeply integrated. I have no idea at the moment what form that might take though.
Regards
Scott
Re: Storing supplier provided account number
Posted by Bob Morley <rm...@emforium.com>.
Scott Gray-2 wrote:
>
> I think you missed the second half of my earlier email:
>> I'm not sure how I would handle something like a security card but IMO
>> the Employment entity should be an extension to PartyRelationship, I mean
>> it already shares the same primary key fields.
>
> Employment already has the same PK fields as PartyRelationship.
>
Yep; I had definitely glossed over that. In my head I was thinking that
PartyRelationship had a partyRelationshipId that could be added to
Employment and Employment could have those other fields removed. But you
are quite correct, we could simply use the existing primary key fields.
Would there be any thought to doing the former? I don't think I want to
bite that off to be honest, but one could create the entity such that it has
a single primary key and the others would make up a unique index.
Personally, I don't know if that is a good idea but it would reduce
redundancy in the sub-classes.
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-tp2076162p2124868.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Storing supplier provided account number
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 4/05/2010, at 7:34 AM, Robert Morley wrote:
>
> On May 3, 2010, at 3:09 PM, Robert Morley wrote:
>
>>>
>>> That wasn't what I was suggesting, I was describing SupplierRelationship as being an extension to PartyRelationship in the same way that Person or PartyGroup extends Party.
>>>
>>
>>
>> Yes I think this is the solution that Adrian has original suggested a couple of years back and is the same solution I had thought about implementing when I started this thread. I think the difficulty here comes in the fact that the data model book has sub-classes for both PartyRelationship and Agreement for this purpose (Supplier Relationship and Purchase Agreement respectively from page 43 and 149 of The Data Model Resource Book volume 1). There are also sub-classes for both for "Employeement" named "Employment" and "Employment Agreement".
>>
>> The book suggests that Agreement is involved in a single PartyRelationship (but the relationship may be associated with a collection of Agreements). Ofbiz does not model this association, but I think it probably should. A scan of the forum for anything on this topic did not produce any results. Again the book suggests the PartyRelationship is an informal relationship where the agreement is created "when a formal agreement is established between these parties and a contract is drawn stipulating certain terms of this agreement ...".
>>
>> For a supplier I think it is desirable to have an informal PartyRelationship between the Internal Organization and the Party that will be supplying products. We may also (optionally) have a formal agreement that dictates pricing and other terms (like net 30, etc). However, the life of this section agreement may be much shorter than the life of the relationship to the supplier. And it is very likely that the supplier supplied "customerNumber" or "accountNumber" would live across many agreements.
>>
>> As a result, I would like to get started on this new entity "SupplierRel" and will provide a patch soon.
>
> Argh! Ok now I understand why "Employment" which is a logic sub-class of PartyRelationship was not coded as such. The issue is that there is not a specific single primary key for PartyRelationship -- its primary keys are partyto, partyfrom, roleto, roleform, and fromDate. As a result, without duplicating all of those keys you can not recall create the Employment entity like we do with other "inherited" entities like Party / Person & PartyGroup.
>
> So the options are to add "partyRelationshipId" to the entity and the changes that would involve (including about a 100 seeded PartyRelations), duplicate the fields in SupplierRel (like Employment does now), or fall back to putting the field directly on PartyRelationship itself.
>
> Community direction requested ... :)
I think you missed the second half of my earlier email:
> I'm not sure how I would handle something like a security card but IMO the Employment entity should be an extension to PartyRelationship, I mean it already shares the same primary key fields.
Employment already has the same PK fields as PartyRelationship.
Re: Storing supplier provided account number
Posted by Robert Morley <rm...@emforium.com>.
On May 3, 2010, at 3:09 PM, Robert Morley wrote:
>>
>> That wasn't what I was suggesting, I was describing
>> SupplierRelationship as being an extension to PartyRelationship in
>> the same way that Person or PartyGroup extends Party.
>>
>
>
> Yes I think this is the solution that Adrian has original suggested
> a couple of years back and is the same solution I had thought about
> implementing when I started this thread. I think the difficulty
> here comes in the fact that the data model book has sub-classes for
> both PartyRelationship and Agreement for this purpose (Supplier
> Relationship and Purchase Agreement respectively from page 43 and
> 149 of The Data Model Resource Book volume 1). There are also sub-
> classes for both for "Employeement" named "Employment" and
> "Employment Agreement".
>
> The book suggests that Agreement is involved in a single
> PartyRelationship (but the relationship may be associated with a
> collection of Agreements). Ofbiz does not model this association,
> but I think it probably should. A scan of the forum for anything on
> this topic did not produce any results. Again the book suggests the
> PartyRelationship is an informal relationship where the agreement is
> created "when a formal agreement is established between these
> parties and a contract is drawn stipulating certain terms of this
> agreement ...".
>
> For a supplier I think it is desirable to have an informal
> PartyRelationship between the Internal Organization and the Party
> that will be supplying products. We may also (optionally) have a
> formal agreement that dictates pricing and other terms (like net 30,
> etc). However, the life of this section agreement may be much
> shorter than the life of the relationship to the supplier. And it
> is very likely that the supplier supplied "customerNumber" or
> "accountNumber" would live across many agreements.
>
> As a result, I would like to get started on this new entity
> "SupplierRel" and will provide a patch soon.
Argh! Ok now I understand why "Employment" which is a logic sub-class
of PartyRelationship was not coded as such. The issue is that there
is not a specific single primary key for PartyRelationship -- its
primary keys are partyto, partyfrom, roleto, roleform, and fromDate.
As a result, without duplicating all of those keys you can not recall
create the Employment entity like we do with other "inherited"
entities like Party / Person & PartyGroup.
So the options are to add "partyRelationshipId" to the entity and the
changes that would involve (including about a 100 seeded
PartyRelations), duplicate the fields in SupplierRel (like Employment
does now), or fall back to putting the field directly on
PartyRelationship itself.
Community direction requested ... :)
Re: Storing supplier provided account number
Posted by Robert Morley <rm...@emforium.com>.
On Apr 30, 2010, at 6:06 PM, Scott Gray wrote:
> On 1/05/2010, at 3:52 AM, Adam Heath wrote:
>
>> Scott Gray wrote:
>>> I think Agreements are more like the terms of a relationship and
>>> can change over the course of that relationship.
>>>
>>> I would tend to think of an account number as being more like
>>> relationship meta data that exists so long as the relationship
>>> exists and for that reason I would either add a generic field to
>>> PartyRelationship or otherwise add a new entity
>>> SupplierRelationship and one-to-one it with PartyRelationship.
>>
>> I like the latter, SupplierRelationship, as there could be an
>> unbounded set of SupplierIdentificationType and
>> SupplierIdentificationPurpose fields.
>
> That wasn't what I was suggesting, I was describing
> SupplierRelationship as being an extension to PartyRelationship in
> the same way that Person or PartyGroup extends Party.
>
Yes I think this is the solution that Adrian has original suggested a
couple of years back and is the same solution I had thought about
implementing when I started this thread. I think the difficulty here
comes in the fact that the data model book has sub-classes for both
PartyRelationship and Agreement for this purpose (Supplier
Relationship and Purchase Agreement respectively from page 43 and 149
of The Data Model Resource Book volume 1). There are also sub-classes
for both for "Employeement" named "Employment" and "Employment
Agreement".
The book suggests that Agreement is involved in a single
PartyRelationship (but the relationship may be associated with a
collection of Agreements). Ofbiz does not model this association, but
I think it probably should. A scan of the forum for anything on this
topic did not produce any results. Again the book suggests the
PartyRelationship is an informal relationship where the agreement is
created "when a formal agreement is established between these parties
and a contract is drawn stipulating certain terms of this
agreement ...".
For a supplier I think it is desirable to have an informal
PartyRelationship between the Internal Organization and the Party that
will be supplying products. We may also (optionally) have a formal
agreement that dictates pricing and other terms (like net 30, etc).
However, the life of this section agreement may be much shorter than
the life of the relationship to the supplier. And it is very likely
that the supplier supplied "customerNumber" or "accountNumber" would
live across many agreements.
As a result, I would like to get started on this new entity
"SupplierRel" and will provide a patch soon.