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
