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 <[email protected]> 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 > > > >
