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 < jacques.le.r...@les7arts.com> 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 <pierresm...@apache.org> > 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 < > >> slidingfilame...@gmail.com> > >> 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 < > 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 > >>>>> >
