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 <michael.br...@ecomify.de> 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 > > >
