OFBiz › OFBiz - Dev

[PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Pierre Smits-3

[PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Hi All,

Currently several entities capture the (contractual) parties in fields like
fromPartyId and toPartyId. These parties commonly represent the internal
(accounting) organisation and the external party (the customer, supplier,
contact, account, carrier etc).

Such entities are:

- Agreement (in party)
- Employment (in humanres)
- Invoice (in accounting
- OrderReportPurchasesGroupByProduct
- PartyBenefit (in humanres)
- Payment (in accounting)
- PayHistory (in humanres)
- ReturnHeader (in Order)
- UnemploymentClaim (in humanres

However there are a (quite a) few entities that defy these 1-on-1
relationships (between internal party and the object, and the external
party and the object), like:

- OrderHeader: neither partyIdFrom nor partyIdTo
- Quote: neither partyIdFrom nor partyIdTo but having a partyId field
- CustRequest: only having fromPartyid (plus its role
- Subscription: having originatedFromPartyId (plus the role) and partyId
- ReorderGuideline: having partyId (plus the role)

And I am confident I am missing a few.

In oder to simplify processes for capturing the main parties in various
entity records I propose to realign these (master) entities to ensure that
both the primary internal and external parties (and their primary roles)
are captured.

What are your thoughts?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

Rishi Solanki

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Dear Pierre,
Few inputs for thoughts;

One agreement from company to multiple parties may exists. For example;
From Company if sale is more than $10,000 then company may credit/discount
10% of sale to its suppliers. Then it will be applicable to more than one
supplier, then AgreementRole entity is suitable in that case.

To be clarify I'm not against this proposal because other entities in the
list are good candidate for this. Also following common pattern is good
reason to go with this, may be we can add or filter some entities.

But I will be able to say yes/no for the proposal after some more inputs
come from community.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847

On Mon, May 13, 2019 at 5:11 PM Pierre Smits <[hidden email]> wrote:

> Hi All,
>
> Currently several entities capture the (contractual) parties in fields like
> fromPartyId and toPartyId. These parties commonly represent the internal
> (accounting) organisation and the external party (the customer, supplier,
> contact, account, carrier etc).
>
> Such entities are:
>
> - Agreement (in party)
> - Employment (in humanres)
> - Invoice (in accounting
> - OrderReportPurchasesGroupByProduct
> - PartyBenefit (in humanres)
> - Payment (in accounting)
> - PayHistory (in humanres)
> - ReturnHeader (in Order)
> - UnemploymentClaim (in humanres
>
>
> However there are a (quite a) few entities that defy these 1-on-1
> relationships (between internal party and the object, and the external
> party and the object), like:
>
> - OrderHeader: neither partyIdFrom nor partyIdTo
> - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> - CustRequest: only having fromPartyid (plus its role
> - Subscription: having originatedFromPartyId (plus the role) and partyId
> - ReorderGuideline: having partyId (plus the role)
>
> And I am confident I am missing a few.
>
> In oder to simplify processes for capturing the main parties in various
> entity records I propose to realign these (master) entities to ensure that
> both the primary internal and external parties (and their primary roles)
> are captured.
>
> What are your thoughts?
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>

Pierre Smits-3

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Hi Rishi, All,

The agreement entity caters for capturing the principal two parties and
their appropriate roles. This caters for the majority of the agreements
struck between the representatives of the internal (accounting)
organisation and their business partners.

The use case you presented (one agreement between the internal organisation
and multiple supplier parties to pay those suppliers a fee based on sales)
is, IMO,:

1. unlikely to happen. Any such agreement can be broken up into unique
contracts between the internal organisation and each supplier, with each
having their unique conditions. Besides, who would willingly agree to
having the same conditions as its competitors. Each principal party aims to
get the best deal for itself.
2. needlessly complex to maintain. When the agreement is the precursor
to the legal document (i.e. through the pdf) such would only be valid if
and when the document is signed by all principal parties involved. And as a
follow-up a copy of that signed document retained through the context
object associated with the agreement.

I would say that, given the (potential) adopter audience, multi-principles
agreements are currently not the first thing on their mind in their process
to vet OFBiz for their business.But I may be mistaken, and there are
multiple (existing) adopters out there that work with such contracts. I
would love to hear from them.

In most cases, the AgreementRoles associated with an agreement are the
persons (of the internal organisation) involved in reviewing, viewing and
approving the contract, and the persons (contacts in various roles) of the
opposing party

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Tue, May 14, 2019 at 11:10 AM Rishi Solanki <[hidden email]>
wrote:

> Dear Pierre,
> Few inputs for thoughts;
>
> One agreement from company to multiple parties may exists. For example;
> From Company if sale is more than $10,000 then company may credit/discount
> 10% of sale to its suppliers. Then it will be applicable to more than one
> supplier, then AgreementRole entity is suitable in that case.
>
> To be clarify I'm not against this proposal because other entities in the
> list are good candidate for this. Also following common pattern is good
> reason to go with this, may be we can add or filter some entities.
>
> But I will be able to say yes/no for the proposal after some more inputs
> come from community.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems <http://www.hotwaxsystems.com/>
> Linkedin: *Rishi Solanki*
> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> Direct: +91-9893287847
>
>
> On Mon, May 13, 2019 at 5:11 PM Pierre Smits <[hidden email]>
> wrote:
>
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields
> like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> > - Agreement (in party)
> > - Employment (in humanres)
> > - Invoice (in accounting
> > - OrderReportPurchasesGroupByProduct
> > - PartyBenefit (in humanres)
> > - Payment (in accounting)
> > - PayHistory (in humanres)
> > - ReturnHeader (in Order)
> > - UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> > - OrderHeader: neither partyIdFrom nor partyIdTo
> > - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> > - CustRequest: only having fromPartyid (plus its role
> > - Subscription: having originatedFromPartyId (plus the role) and
> partyId
> > - ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure
> that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
>

Michael Brohl-3

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

In reply to this post by Pierre Smits-3

Hi Pierre,

I think there are more sophisticated concepts for some of the mentioned
entities, for example

- OrderRole for orders allows to connect an unlimited number of parties
with different roles

- CustRequestParty, QuoteRole, CustRequestRole - same principle

For these, introducing from/toPartyId would be no improvement IMO. *If*
we would want to make a change, I would tend more to implementing the
...Role principle where it is missing and get rid of the from/toPartyId
pattern. But this would be a big change...

I'm not sure why we have these in some entities which also have the
...Role entities, such as Invoice.

Maybe others can give more insights?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 13.05.19 um 13:41 schrieb Pierre Smits:

smime.p7s (5K) Download Attachment

Rishi Solanki

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Dear Pierre,
I agree on the point that the AgreementRole entity is not good example for
the point I would like to put. But yes I was on the similar lines that we
have role entities which allows multiple party to be in same role with
respect to any transaction.

@Michael Brohi, The invoice role entity also uses sales rep and bill from
vendor roles for the same invoice for different parties. Also in case of
reconciliation and settlement these roles can be enhanced as per business
requirement. So giving flexibility in data model seems fine to me.

I'm okay with from/to party concept for the cases where large amount of
data may exists for those entities like order, invoice and other. It is
denormalised data form but requires in case of large amount of data where
two direct (primary) parties involve. And secondary parties linked thru
role entities.

My basic idea is to think on each entity before considering it for this
improvement or considering for role entity extension, on the basis of
following questions;
- Is it core entity which may have large amount of data?
- Are two primary parties can be identified for that entity?
- Are secondary parties can be identified for that entity?
- Possible business cases if possible.

I just wanted to suggest go slow for these changes as these are core
changes. We can list all entities and I would be happy to help list
entities and research around it. So that we will be confident to proceed
with. Side note Any change requires entity, service and other business call
changes as well.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847

On Fri, May 17, 2019 at 1:55 AM Michael Brohl <[hidden email]>
wrote:

> Hi Pierre,
>
> I think there are more sophisticated concepts for some of the mentioned
> entities, for example
>
> - OrderRole for orders allows to connect an unlimited number of parties
> with different roles
>
> - CustRequestParty, QuoteRole, CustRequestRole - same principle
>
> For these, introducing from/toPartyId would be no improvement IMO. *If*
> we would want to make a change, I would tend more to implementing the
> ...Role principle where it is missing and get rid of the from/toPartyId
> pattern. But this would be a big change...
>
> I'm not sure why we have these in some entities which also have the
> ...Role entities, such as Invoice.
>
> Maybe others can give more insights?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields
> like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> > - Agreement (in party)
> > - Employment (in humanres)
> > - Invoice (in accounting
> > - OrderReportPurchasesGroupByProduct
> > - PartyBenefit (in humanres)
> > - Payment (in accounting)
> > - PayHistory (in humanres)
> > - ReturnHeader (in Order)
> > - UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> > - OrderHeader: neither partyIdFrom nor partyIdTo
> > - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> > - CustRequest: only having fromPartyid (plus its role
> > - Subscription: having originatedFromPartyId (plus the role) and
> partyId
> > - ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure
> that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
>
>

Pierre Smits-3

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

In reply to this post by Michael Brohl-3

Hi Michael, All,

The reason why we have the partyIdFrom and partyIdTo fields (and the
associated roleTypeIdFrom and roleTypeIdTo fields) is that the project
started out following the Unified Data Model (UDM) by Len Silverton.

And then we digressed from that.
Were each of those digressions carefully thought through and the impact
thoroughly discussed before they went into the code base?

The reason why these are in several entities in the UDM is that the values
of these fields (relating to these principal parties) are regarded as
immutable when the object reaches a certain state (the *_APPROVED or
similar)[1].

The various associated *Role entities are intended to capture:
1. additional roles for the principal parties
2. additionally involved parties (both internal and external) in their
respective roles, per [2]

If we were to only use *Role entities we are creating a more complex
problem to solve the immutability issue.

As an example:

The OFBiz operator needs to have the ability to add parties (and a role of
the party) and expire existing *Role records associated to the principal
object (agreement, invoice, order, project, employment contract, etc.).

With this function the operator can add a new party as the customer (and
expire the original) to e.g. the sales order after the order has been
approved.

In order to prevent this from happening, we would need to have a mechanism
to ensure that the principal parties (and their principal role regarding
the object) don't change during the lifespan of the object. IMO this will
be a complex solution given all permutations possible.

[1] We're not talking about what can be done at database level (or via
WebTools) by SystemAdmins.
[2] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

>

taher

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

In reply to this post by Michael Brohl-3

I'm also in favor of the more flexible design based on roles. Let the
services worry about sorting this stuff out and leave the entity
domain layer solid and well designed.

On Thu, May 16, 2019 at 11:25 PM Michael Brohl <[hidden email]> wrote:

>
> Hi Pierre,
>
> I think there are more sophisticated concepts for some of the mentioned
> entities, for example
>
> - OrderRole for orders allows to connect an unlimited number of parties
> with different roles
>
> - CustRequestParty, QuoteRole, CustRequestRole - same principle
>
> For these, introducing from/toPartyId would be no improvement IMO. *If*
> we would want to make a change, I would tend more to implementing the
> ...Role principle where it is missing and get rid of the from/toPartyId
> pattern. But this would be a big change...
>
> I'm not sure why we have these in some entities which also have the
> ...Role entities, such as Invoice.
>
> Maybe others can give more insights?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> > - Agreement (in party)
> > - Employment (in humanres)
> > - Invoice (in accounting
> > - OrderReportPurchasesGroupByProduct
> > - PartyBenefit (in humanres)
> > - Payment (in accounting)
> > - PayHistory (in humanres)
> > - ReturnHeader (in Order)
> > - UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> > - OrderHeader: neither partyIdFrom nor partyIdTo
> > - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> > - CustRequest: only having fromPartyid (plus its role
> > - Subscription: having originatedFromPartyId (plus the role) and partyId
> > - ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
>

Pierre Smits-3

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

I totally agree with

leave the entity designs well designed and solid

The Unified Data Model has been designed well and is still withstanding the
test of time. This design is the reason why our project opted to have this
at its core for all the business applications.
It is the digressions from (even more so the explanation regarding the
applicability of those digressions) that have us going through hoops to
ensure that what is used where, when, how and why remains consistent. From
persistence, through service/functions and UI to documentation.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <[hidden email]>
wrote:

> I'm also in favor of the more flexible design based on roles. Let the
> services worry about sorting this stuff out and leave the entity
> domain layer solid and well designed.
>
> On Thu, May 16, 2019 at 11:25 PM Michael Brohl <[hidden email]>
> wrote:
> >
> > Hi Pierre,
> >
> > I think there are more sophisticated concepts for some of the mentioned
> > entities, for example
> >
> > - OrderRole for orders allows to connect an unlimited number of parties
> > with different roles
> >
> > - CustRequestParty, QuoteRole, CustRequestRole - same principle
> >
> > For these, introducing from/toPartyId would be no improvement IMO. *If*
> > we would want to make a change, I would tend more to implementing the
> > ...Role principle where it is missing and get rid of the from/toPartyId
> > pattern. But this would be a big change...
> >
> > I'm not sure why we have these in some entities which also have the
> > ...Role entities, such as Invoice.
> >
> > Maybe others can give more insights?
> >
> > Regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > > Hi All,
> > >
> > > Currently several entities capture the (contractual) parties in fields
> like
> > > fromPartyId and toPartyId. These parties commonly represent the
> internal
> > > (accounting) organisation and the external party (the customer,
> supplier,
> > > contact, account, carrier etc).
> > >
> > > Such entities are:
> > >
> > > - Agreement (in party)
> > > - Employment (in humanres)
> > > - Invoice (in accounting
> > > - OrderReportPurchasesGroupByProduct
> > > - PartyBenefit (in humanres)
> > > - Payment (in accounting)
> > > - PayHistory (in humanres)
> > > - ReturnHeader (in Order)
> > > - UnemploymentClaim (in humanres
> > >
> > >
> > > However there are a (quite a) few entities that defy these 1-on-1
> > > relationships (between internal party and the object, and the external
> > > party and the object), like:
> > >
> > > - OrderHeader: neither partyIdFrom nor partyIdTo
> > > - Quote: neither partyIdFrom nor partyIdTo but having a partyId
> field
> > > - CustRequest: only having fromPartyid (plus its role
> > > - Subscription: having originatedFromPartyId (plus the role) and
> partyId
> > > - ReorderGuideline: having partyId (plus the role)
> > >
> > > And I am confident I am missing a few.
> > >
> > > In oder to simplify processes for capturing the main parties in various
> > > entity records I propose to realign these (master) entities to ensure
> that
> > > both the primary internal and external parties (and their primary
> roles)
> > > are captured.
> > >
> > > What are your thoughts?
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > > *Apache Directory <https://directory.apache.org>, PMC Member*
> > > Apache Incubator <https://incubator.apache.org>, committer
> > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > > since 2008*
> > > Apache Steve <https://steve.apache.org>, committer
> > >
> >
>

Scott Gray-3

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

In my experience very few things in the business world are immutable.
Dated *Role entities enhance flexibility and provide a decent audit trail
for the inevitable changes that businesses need to support (I placed this
order against the wrong customer, customer A has bought customer B so we
need to transfer over all existing orders).

Having *Role entities alongside from/to partyIds (or any time there's
multiple ways to link two objects) leads to confusion, behavioral
inconsistencies and a complicated code base.

For example why is there an originFacilityId on OrderHeader when there is a
facilityId field on OrderItemShipGroup as well? That's just an example I
noticed recently, I've noticed a bunch over the years and they only serve
to complicate development.

I'm sure there are scenarios where from/to partyIds are suitable (like
PartyRelationship) but I disagree with a broad proposal such as this to
apply them to a range of entities. I'd prefer to see us move in the other
direction and remove top-level entitiy from/to fields if there is an
existing *Role entity in order to simplify the datamodel while maintaining
flexibility.

Regards
Scott

On Sun, 19 May 2019 at 22:57, Pierre Smits <[hidden email]> wrote:

> I totally agree with
>
> leave the entity designs well designed and solid
>
>
> The Unified Data Model has been designed well and is still withstanding the
> test of time. This design is the reason why our project opted to have this
> at its core for all the business applications.
> It is the digressions from (even more so the explanation regarding the
> applicability of those digressions) that have us going through hoops to
> ensure that what is used where, when, how and why remains consistent. From
> persistence, through service/functions and UI to documentation.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <
> [hidden email]>
> wrote:
>
> > I'm also in favor of the more flexible design based on roles. Let the
> > services worry about sorting this stuff out and leave the entity
> > domain layer solid and well designed.
> >
> > On Thu, May 16, 2019 at 11:25 PM Michael Brohl <[hidden email]
> >
> > wrote:
> > >
> > > Hi Pierre,
> > >
> > > I think there are more sophisticated concepts for some of the mentioned
> > > entities, for example
> > >
> > > - OrderRole for orders allows to connect an unlimited number of parties
> > > with different roles
> > >
> > > - CustRequestParty, QuoteRole, CustRequestRole - same principle
> > >
> > > For these, introducing from/toPartyId would be no improvement IMO. *If*
> > > we would want to make a change, I would tend more to implementing the
> > > ...Role principle where it is missing and get rid of the from/toPartyId
> > > pattern. But this would be a big change...
> > >
> > > I'm not sure why we have these in some entities which also have the
> > > ...Role entities, such as Invoice.
> > >
> > > Maybe others can give more insights?
> > >
> > > Regards,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> > > Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > > > Hi All,
> > > >
> > > > Currently several entities capture the (contractual) parties in
> fields
> > like
> > > > fromPartyId and toPartyId. These parties commonly represent the
> > internal
> > > > (accounting) organisation and the external party (the customer,
> > supplier,
> > > > contact, account, carrier etc).
> > > >
> > > > Such entities are:
> > > >
> > > > - Agreement (in party)
> > > > - Employment (in humanres)
> > > > - Invoice (in accounting
> > > > - OrderReportPurchasesGroupByProduct
> > > > - PartyBenefit (in humanres)
> > > > - Payment (in accounting)
> > > > - PayHistory (in humanres)
> > > > - ReturnHeader (in Order)
> > > > - UnemploymentClaim (in humanres
> > > >
> > > >
> > > > However there are a (quite a) few entities that defy these 1-on-1
> > > > relationships (between internal party and the object, and the
> external
> > > > party and the object), like:
> > > >
> > > > - OrderHeader: neither partyIdFrom nor partyIdTo
> > > > - Quote: neither partyIdFrom nor partyIdTo but having a partyId
> > field
> > > > - CustRequest: only having fromPartyid (plus its role
> > > > - Subscription: having originatedFromPartyId (plus the role) and
> > partyId
> > > > - ReorderGuideline: having partyId (plus the role)
> > > >
> > > > And I am confident I am missing a few.
> > > >
> > > > In oder to simplify processes for capturing the main parties in
> various
> > > > entity records I propose to realign these (master) entities to ensure
> > that
> > > > both the primary internal and external parties (and their primary
> > roles)
> > > > are captured.
> > > >
> > > > What are your thoughts?
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > > > *Apache Directory <https://directory.apache.org>, PMC Member*
> > > > Apache Incubator <https://incubator.apache.org>, committer
> > > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > privileges)
> > > > since 2008*
> > > > Apache Steve <https://steve.apache.org>, committer
> > > >
> > >
> >
>

Jacques Le Roux

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Administrator

Hi Pierre,

In the DMRB, Silverstein mentions from and to party fields for PARTY RELATIONSHIPS, SHIPMENTs, FIXED ASSET ASSIGNMENTs, and PAYMENT ACCTG TRANSs entities

In the "Logical Data Model Entities and Attributes Listing" section there is actually from and to party fields for the following entities:

AGREEMENT
CUSTOMER RELATIONSHIP
EMPLOYMENT
ORGANIZATION CONTACT RELATIONSHIP
PARTY RELATIONSHIP
PAY HISTORY

------------------------------------------------------------------------------------------------------------------------------------------------------

In OFBiz we have from and to party fields for the following entities:

Invoice
InvoiceItemAssoc
Payment
Employment
PartyBenefit
PayHistory
UnemploymentClaim
Agreement
AgreementEmploymentAppl
CommunicationEvent
PartyInvitation
PartyRelationship
Shipment
PartyRelationship
PartyInvitation

Each entity in OFBiz which has from and to party fields has also roleTypeIdFrom and roleTypeIdTo.

You lastly wrote:

However there are a (quite a) few entities that defy these 1-on-1
relationships (between internal party and the object, and the external
party and the object), like:

- OrderHeader: neither partyIdFrom nor partyIdTo
- Quote: neither partyIdFrom nor partyIdTo but having a partyId field
- CustRequest: only having fromPartyid (plus its role
- Subscription: having originatedFromPartyId (plus the role) and partyId
- ReorderGuideline: having partyId (plus the role)

And I am confident I am missing a few.

In order to simplify processes for capturing the main parties in various
entity records I propose to realign these (master) entities to ensure that
both the primary internal and external parties (and their primary roles)
are captured.

In OFBiz we have also 29 '*role" entities (I let you check searching for '/<entity entity-name="*Role" /' in *mode*.xml files.):

accounting-entitymodel.xml (5 matches)
218: <entity entity-name="BudgetRole"
419: <entity entity-name="FinAccountRole" package-name="org.apache.ofbiz.accounting.finaccount" title="Financial Account Role">
1?498: <entity entity-name="InvoiceRole"
2?281: <entity entity-name="GlAccountRole"
2?692: <entity entity-name="BillingAccountRole"
content-entitymodel.xml (3 matches)
631: <entity entity-name="ContentRole"
921: <entity entity-name="DataResourceRole"
1?599: <entity entity-name="WebSiteRole" package-name="org.apache.ofbiz.party.party" title="WebSite Role Association">
marketing-entitymodel.xml (3 matches)
125: <entity entity-name="MarketingCampaignRole"
359: <entity entity-name="SegmentGroupRole"
728: <entity entity-name="SalesOpportunityRole"
order-entitymodel.xml (4 matches)
855: <entity entity-name="OrderItemRole"
1?164: <entity entity-name="OrderRole"
1?553: <entity entity-name="QuoteRole"
2?254: <entity entity-name="RequirementRole"
party-entitymodel.xml (4 matches)
343: <entity entity-name="AgreementRole"
910: <entity entity-name="CommunicationEventRole"
1?325: <entity entity-name="ValidContactMechRole"
2?536: <entity entity-name="PartyRole"
product-entitymodel.xml (6 matches)
121: <entity entity-name="ProdCatalogRole"
429: <entity entity-name="ProductCategoryRole"
1?230: <entity entity-name="FacilityGroupRole" package-name="org.apache.ofbiz.product.facility" title="Facility Group Role">
3?007: <entity entity-name="ProductRole"
4?127: <entity entity-name="ProductStoreGroupRole"
4?269: <entity entity-name="ProductStoreRole"
shipment-entitymodel.xml (3 matches)
128: <entity entity-name="ItemIssuanceRole"
278: <entity entity-name="PicklistRole"
408: <entity entity-name="ShipmentReceiptRole"
workeffort-entitymodel.xml
102: <entity entity-name="TimesheetRole"

This is more than what Silverstein proposes in the "Logical Data Model Entities and Attributes Listing" section (19).

Note that both models don't intersect (eg CASE ROLE, ORGANIZATION ROLE, PERSON ROLE - redundant with PARTY ROLE IMO-, REQUEST ROLE - did not find
CustRequestRole mentioned by Rishi -, "misses" in OFBiz data model)

AGREEMENT ROLE
BILLING ACCOUNT ROLE
BUDGET ROLE
CASE ROLE
COMMUNICATION EVENT ROLE
FINANCIAL ACCOUNT ROLE
INVOICE ROLE
ITEM ISSUANCE ROLE
ORDER ITEM ROLE
ORDER ROLE
ORGANIZATION ROLE
PARTY ROLE
PERSON ROLE
QUOTE ROLE
REQUEST ROLE
REQUIREMENT ROLE
SHIPMENT RECEIPT ROLE
TIMESHEET ROLE
VALID CONTACT MECHANISM ROLE

I think we should consider Scott's proposition:

I'd prefer to see us move in the other
direction and remove top-level entitiy from/to fields if there is an
existing *Role entity in order to simplify the datamodel while maintaining
flexibility.

Even if I don't think it's a priority task as it also implies a lot of changes and work

My 2 cts

Jacques

Le 20/05/2019 à 10:27, Scott Gray a écrit :

> In my experience very few things in the business world are immutable.
> Dated *Role entities enhance flexibility and provide a decent audit trail
> for the inevitable changes that businesses need to support (I placed this
> order against the wrong customer, customer A has bought customer B so we
> need to transfer over all existing orders).
>
> Having *Role entities alongside from/to partyIds (or any time there's
> multiple ways to link two objects) leads to confusion, behavioral
> inconsistencies and a complicated code base.
>
> For example why is there an originFacilityId on OrderHeader when there is a
> facilityId field on OrderItemShipGroup as well? That's just an example I
> noticed recently, I've noticed a bunch over the years and they only serve
> to complicate development.
>
> I'm sure there are scenarios where from/to partyIds are suitable (like
> PartyRelationship) but I disagree with a broad proposal such as this to
> apply them to a range of entities. I'd prefer to see us move in the other
> direction and remove top-level entitiy from/to fields if there is an
> existing *Role entity in order to simplify the datamodel while maintaining
> flexibility.
>
> Regards
> Scott
>
> On Sun, 19 May 2019 at 22:57, Pierre Smits <[hidden email]> wrote:
>
>> I totally agree with
>>
>> leave the entity designs well designed and solid
>>
>>
>> The Unified Data Model has been designed well and is still withstanding the
>> test of time. This design is the reason why our project opted to have this
>> at its core for all the business applications.
>> It is the digressions from (even more so the explanation regarding the
>> applicability of those digressions) that have us going through hoops to
>> ensure that what is used where, when, how and why remains consistent. From
>> persistence, through service/functions and UI to documentation.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>> *Apache Directory <https://directory.apache.org>, PMC Member*
>> Apache Incubator <https://incubator.apache.org>, committer
>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
>> since 2008*
>> Apache Steve <https://steve.apache.org>, committer
>>
>>
>> On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <
>> [hidden email]>
>> wrote:
>>
>>> I'm also in favor of the more flexible design based on roles. Let the
>>> services worry about sorting this stuff out and leave the entity
>>> domain layer solid and well designed.
>>>
>>> On Thu, May 16, 2019 at 11:25 PM Michael Brohl <[hidden email]
>>>
>>> wrote:
>>>> Hi Pierre,
>>>>
>>>> I think there are more sophisticated concepts for some of the mentioned
>>>> entities, for example
>>>>
>>>> - OrderRole for orders allows to connect an unlimited number of parties
>>>> with different roles
>>>>
>>>> - CustRequestParty, QuoteRole, CustRequestRole - same principle
>>>>
>>>> For these, introducing from/toPartyId would be no improvement IMO. *If*
>>>> we would want to make a change, I would tend more to implementing the
>>>> ...Role principle where it is missing and get rid of the from/toPartyId
>>>> pattern. But this would be a big change...
>>>>
>>>> I'm not sure why we have these in some entities which also have the
>>>> ...Role entities, such as Invoice.
>>>>
>>>> Maybe others can give more insights?
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Am 13.05.19 um 13:41 schrieb Pierre Smits:
>>>>> Hi All,
>>>>>
>>>>> Currently several entities capture the (contractual) parties in
>> fields
>>> like
>>>>> fromPartyId and toPartyId. These parties commonly represent the
>>> internal
>>>>> (accounting) organisation and the external party (the customer,
>>> supplier,
>>>>> contact, account, carrier etc).
>>>>>
>>>>> Such entities are:
>>>>>
>>>>> - Agreement (in party)
>>>>> - Employment (in humanres)
>>>>> - Invoice (in accounting
>>>>> - OrderReportPurchasesGroupByProduct
>>>>> - PartyBenefit (in humanres)
>>>>> - Payment (in accounting)
>>>>> - PayHistory (in humanres)
>>>>> - ReturnHeader (in Order)
>>>>> - UnemploymentClaim (in humanres
>>>>>
>>>>>
>>>>> However there are a (quite a) few entities that defy these 1-on-1
>>>>> relationships (between internal party and the object, and the
>> external
>>>>> party and the object), like:
>>>>>
>>>>> - OrderHeader: neither partyIdFrom nor partyIdTo
>>>>> - Quote: neither partyIdFrom nor partyIdTo but having a partyId
>>> field
>>>>> - CustRequest: only having fromPartyid (plus its role
>>>>> - Subscription: having originatedFromPartyId (plus the role) and
>>> partyId
>>>>> - ReorderGuideline: having partyId (plus the role)
>>>>>
>>>>> And I am confident I am missing a few.
>>>>>
>>>>> In oder to simplify processes for capturing the main parties in
>> various
>>>>> entity records I propose to realign these (master) entities to ensure
>>> that
>>>>> both the primary internal and external parties (and their primary
>>> roles)
>>>>> are captured.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>> privileges)
>>>>> since 2008*
>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>

Rishi Solanki

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

Thanks everyone for valuable inputs.

+1 for Scott's proposal to go with Role entity. Thanks for the details
added around it.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847

On Mon, May 20, 2019 at 3:17 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi Pierre,
>
> In the DMRB, Silverstein mentions from and to party fields for PARTY
> RELATIONSHIPS, SHIPMENTs, FIXED ASSET ASSIGNMENTs, and PAYMENT ACCTG TRANSs
> entities
>
> In the "Logical Data Model Entities and Attributes Listing" section there
> is actually from and to party fields for the following entities:
>
> AGREEMENT
> CUSTOMER RELATIONSHIP
> EMPLOYMENT
> ORGANIZATION CONTACT RELATIONSHIP
> PARTY RELATIONSHIP
> PAY HISTORY
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> In OFBiz we have from and to party fields for the following entities:
>
> Invoice
> InvoiceItemAssoc
> Payment
> Employment
> PartyBenefit
> PayHistory
> UnemploymentClaim
> Agreement
> AgreementEmploymentAppl
> CommunicationEvent
> PartyInvitation
> PartyRelationship
> Shipment
> PartyRelationship
> PartyInvitation
>
> Each entity in OFBiz which has from and to party fields has also
> roleTypeIdFrom and roleTypeIdTo.
>
> You lastly wrote:
>
> However there are a (quite a) few entities that defy these 1-on-1
> relationships (between internal party and the object, and the external
> party and the object), like:
>
> - OrderHeader: neither partyIdFrom nor partyIdTo
> - Quote: neither partyIdFrom nor partyIdTo but having a partyId
> field
> - CustRequest: only having fromPartyid (plus its role
> - Subscription: having originatedFromPartyId (plus the role) and
> partyId
> - ReorderGuideline: having partyId (plus the role)
>
> And I am confident I am missing a few.
>
> In order to simplify processes for capturing the main parties in
> various
> entity records I propose to realign these (master) entities to ensure
> that
> both the primary internal and external parties (and their primary
> roles)
> are captured.
>
> In OFBiz we have also 29 '*role" entities (I let you check searching for
> '/<entity entity-name="*Role" /' in *mode*.xml files.):
>
> accounting-entitymodel.xml (5 matches)
> 218: <entity entity-name="BudgetRole"
> 419: <entity entity-name="FinAccountRole"
> package-name="org.apache.ofbiz.accounting.finaccount" title="Financial
> Account Role">
> 1?498: <entity entity-name="InvoiceRole"
> 2?281: <entity entity-name="GlAccountRole"
> 2?692: <entity entity-name="BillingAccountRole"
> content-entitymodel.xml (3 matches)
> 631: <entity entity-name="ContentRole"
> 921: <entity entity-name="DataResourceRole"
> 1?599: <entity entity-name="WebSiteRole"
> package-name="org.apache.ofbiz.party.party" title="WebSite Role
> Association">
> marketing-entitymodel.xml (3 matches)
> 125: <entity entity-name="MarketingCampaignRole"
> 359: <entity entity-name="SegmentGroupRole"
> 728: <entity entity-name="SalesOpportunityRole"
> order-entitymodel.xml (4 matches)
> 855: <entity entity-name="OrderItemRole"
> 1?164: <entity entity-name="OrderRole"
> 1?553: <entity entity-name="QuoteRole"
> 2?254: <entity entity-name="RequirementRole"
> party-entitymodel.xml (4 matches)
> 343: <entity entity-name="AgreementRole"
> 910: <entity entity-name="CommunicationEventRole"
> 1?325: <entity entity-name="ValidContactMechRole"
> 2?536: <entity entity-name="PartyRole"
> product-entitymodel.xml (6 matches)
> 121: <entity entity-name="ProdCatalogRole"
> 429: <entity entity-name="ProductCategoryRole"
> 1?230: <entity entity-name="FacilityGroupRole"
> package-name="org.apache.ofbiz.product.facility" title="Facility Group
> Role">
> 3?007: <entity entity-name="ProductRole"
> 4?127: <entity entity-name="ProductStoreGroupRole"
> 4?269: <entity entity-name="ProductStoreRole"
> shipment-entitymodel.xml (3 matches)
> 128: <entity entity-name="ItemIssuanceRole"
> 278: <entity entity-name="PicklistRole"
> 408: <entity entity-name="ShipmentReceiptRole"
> workeffort-entitymodel.xml
> 102: <entity entity-name="TimesheetRole"
>
> This is more than what Silverstein proposes in the "Logical Data Model
> Entities and Attributes Listing" section (19).
>
> Note that both models don't intersect (eg CASE ROLE, ORGANIZATION ROLE,
> PERSON ROLE - redundant with PARTY ROLE IMO-, REQUEST ROLE - did not find
> CustRequestRole mentioned by Rishi -, "misses" in OFBiz data model)
>
> AGREEMENT ROLE
> BILLING ACCOUNT ROLE
> BUDGET ROLE
> CASE ROLE
> COMMUNICATION EVENT ROLE
> FINANCIAL ACCOUNT ROLE
> INVOICE ROLE
> ITEM ISSUANCE ROLE
> ORDER ITEM ROLE
> ORDER ROLE
> ORGANIZATION ROLE
> PARTY ROLE
> PERSON ROLE
> QUOTE ROLE
> REQUEST ROLE
> REQUIREMENT ROLE
> SHIPMENT RECEIPT ROLE
> TIMESHEET ROLE
> VALID CONTACT MECHANISM ROLE
>
> I think we should consider Scott's proposition:
>
> I'd prefer to see us move in the other
> direction and remove top-level entitiy from/to fields if there is an
> existing *Role entity in order to simplify the datamodel while
> maintaining
> flexibility.
>
> Even if I don't think it's a priority task as it also implies a lot of
> changes and work
>
> My 2 cts
>
> Jacques
>
> Le 20/05/2019 à 10:27, Scott Gray a écrit :
> > In my experience very few things in the business world are immutable.
> > Dated *Role entities enhance flexibility and provide a decent audit trail
> > for the inevitable changes that businesses need to support (I placed this
> > order against the wrong customer, customer A has bought customer B so we
> > need to transfer over all existing orders).
> >
> > Having *Role entities alongside from/to partyIds (or any time there's
> > multiple ways to link two objects) leads to confusion, behavioral
> > inconsistencies and a complicated code base.
> >
> > For example why is there an originFacilityId on OrderHeader when there
> is a
> > facilityId field on OrderItemShipGroup as well? That's just an example I
> > noticed recently, I've noticed a bunch over the years and they only serve
> > to complicate development.
> >
> > I'm sure there are scenarios where from/to partyIds are suitable (like
> > PartyRelationship) but I disagree with a broad proposal such as this to
> > apply them to a range of entities. I'd prefer to see us move in the
> other
> > direction and remove top-level entitiy from/to fields if there is an
> > existing *Role entity in order to simplify the datamodel while
> maintaining
> > flexibility.
> >
> > Regards
> > Scott
> >
> > On Sun, 19 May 2019 at 22:57, Pierre Smits <[hidden email]>
> wrote:
> >
> >> I totally agree with
> >>
> >> leave the entity designs well designed and solid
> >>
> >>
> >> The Unified Data Model has been designed well and is still withstanding
> the
> >> test of time. This design is the reason why our project opted to have
> this
> >> at its core for all the business applications.
> >> It is the digressions from (even more so the explanation regarding the
> >> applicability of those digressions) that have us going through hoops to
> >> ensure that what is used where, when, how and why remains consistent.
> From
> >> persistence, through service/functions and UI to documentation.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >> *Apache Directory <https://directory.apache.org>, PMC Member*
> >> Apache Incubator <https://incubator.apache.org>, committer
> >> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> >> since 2008*
> >> Apache Steve <https://steve.apache.org>, committer
> >>
> >>
> >> On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <
> >> [hidden email]>
> >> wrote:
> >>
> >>> I'm also in favor of the more flexible design based on roles. Let the
> >>> services worry about sorting this stuff out and leave the entity
> >>> domain layer solid and well designed.
> >>>
> >>> On Thu, May 16, 2019 at 11:25 PM Michael Brohl <
> [hidden email]
> >>>
> >>> wrote:
> >>>> Hi Pierre,
> >>>>
> >>>> I think there are more sophisticated concepts for some of the
> mentioned
> >>>> entities, for example
> >>>>
> >>>> - OrderRole for orders allows to connect an unlimited number of
> parties
> >>>> with different roles
> >>>>
> >>>> - CustRequestParty, QuoteRole, CustRequestRole - same principle
> >>>>
> >>>> For these, introducing from/toPartyId would be no improvement IMO.
> *If*
> >>>> we would want to make a change, I would tend more to implementing the
> >>>> ...Role principle where it is missing and get rid of the
> from/toPartyId
> >>>> pattern. But this would be a big change...
> >>>>
> >>>> I'm not sure why we have these in some entities which also have the
> >>>> ...Role entities, such as Invoice.
> >>>>
> >>>> Maybe others can give more insights?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Michael Brohl
> >>>>
> >>>> ecomify GmbH - www.ecomify.de
> >>>>
> >>>>
> >>>> Am 13.05.19 um 13:41 schrieb Pierre Smits:
> >>>>> Hi All,
> >>>>>
> >>>>> Currently several entities capture the (contractual) parties in
> >> fields
> >>> like
> >>>>> fromPartyId and toPartyId. These parties commonly represent the
> >>> internal
> >>>>> (accounting) organisation and the external party (the customer,
> >>> supplier,
> >>>>> contact, account, carrier etc).
> >>>>>
> >>>>> Such entities are:
> >>>>>
> >>>>> - Agreement (in party)
> >>>>> - Employment (in humanres)
> >>>>> - Invoice (in accounting
> >>>>> - OrderReportPurchasesGroupByProduct
> >>>>> - PartyBenefit (in humanres)
> >>>>> - Payment (in accounting)
> >>>>> - PayHistory (in humanres)
> >>>>> - ReturnHeader (in Order)
> >>>>> - UnemploymentClaim (in humanres
> >>>>>
> >>>>>
> >>>>> However there are a (quite a) few entities that defy these 1-on-1
> >>>>> relationships (between internal party and the object, and the
> >> external
> >>>>> party and the object), like:
> >>>>>
> >>>>> - OrderHeader: neither partyIdFrom nor partyIdTo
> >>>>> - Quote: neither partyIdFrom nor partyIdTo but having a partyId
> >>> field
> >>>>> - CustRequest: only having fromPartyid (plus its role
> >>>>> - Subscription: having originatedFromPartyId (plus the role) and
> >>> partyId
> >>>>> - ReorderGuideline: having partyId (plus the role)
> >>>>>
> >>>>> And I am confident I am missing a few.
> >>>>>
> >>>>> In oder to simplify processes for capturing the main parties in
> >> various
> >>>>> entity records I propose to realign these (master) entities to ensure
> >>> that
> >>>>> both the primary internal and external parties (and their primary
> >>> roles)
> >>>>> are captured.
> >>>>>
> >>>>> What are your thoughts?
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>> privileges)
> >>>>> since 2008*
> >>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>
>

Paul Foxworthy

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

In reply to this post by Scott Gray-3

On Mon, 20 May 2019 at 18:27, Scott Gray <[hidden email]>
wrote:

> I'm sure there are scenarios where from/to partyIds are suitable (like
> PartyRelationship) but I disagree with a broad proposal such as this to
> apply them to a range of entities. I'd prefer to see us move in the other
> direction and remove top-level entitiy from/to fields if there is an
> existing *Role entity in order to simplify the datamodel while maintaining
> flexibility.
>

I agree with Scott.

Cheers

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

Zhang Wei

回复: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

+1
________________________________
发件人: Paul Foxworthy <[hidden email]>
发送时间: 2019年6月21日 15:36
收件人: [hidden email]
主题: Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

On Mon, 20 May 2019 at 18:27, Scott Gray <[hidden email]>
wrote:

> I'm sure there are scenarios where from/to partyIds are suitable (like
> PartyRelationship) but I disagree with a broad proposal such as this to
> apply them to a range of entities. I'd prefer to see us move in the other
> direction and remove top-level entitiy from/to fields if there is an
> existing *Role entity in order to simplify the datamodel while maintaining
> flexibility.
>

I agree with Scott.

Cheers

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]