Relationships between Grower, Company and Person

[knelson-farmbeltnorth]

Brand currently has a mapping to Manufacturer which I'm interpreting as required.

Neither Grower nor Manufacturer has any relationship to Company, which is the mapping from Facility and PersonRole.

We need to clarify these or they will be used without consistency.

My initial thinking is that a Manufacturer and Grower are both Companies and what is applicable to any Company can be applicable to Manufacturers or Growers.

[brycehemme]

Manufacturer and Brand make sense.

The first gap I see is a grouping mechanism for people that farm together (Farming Operation) although that is sort of handled via Grower through the GrowerId on the PersonRole class.

The other gap is the potential need to model out a hierarchy within a company. If we think of Company being something like an ag retailer, is there a need to model out organizational hierarchies within the company? For example, BigAgRetailer might want to track all of their employees (Person/PersonRole) into separate territories such as western IA vs. eastern IA. If this is something we think is an in-scope use case then I'd question if a generic concept of Organization would be a better solution in order to track an organizational tree (recursive Organization objects) where Person/PersonRole objects can be attached to any level in the tree.

[knelson-farmbeltnorth]

We discussed on the Aug 10 call.

There was general agreement that Manufacturer and Brand are good as they are. They should not be anything other than textual reference information by which one can categorize inputs or equipment. As ADAPT doesn't model the manufacturing process of inputs or equipment, it would be excessive to tie these into richer objects intended for the agricultural production process.

Company is intended to mean an entity working with the grower in some way. I.e., a retailer, cooperative, crop consultant or custom applicator/harvester.

@brycehemme and @strhea both have brought up the need for additional hierarchy above GFF, and there was agreement on the call that we should rethink the relationships between Person, PersonRole, Company & Grower.

[knelson-farmbeltnorth]

Updating title for clarity moving forward.

[knelson-farmbeltnorth]

I'm proposing that we collapse Person and Company into a single object called Party. In many cases, the assignment of responsibility is to a company without knowledge of individuals. In other cases, a sole proprietor is indistinguishable from his business.

The Party object will have a Parent Party Id allowing for n-levels of hierarchy. E.g., an individual can map to his business or business subsidiary, the subsidiary to its parent and so on.

PersonRole becomes PartyRole and dtPersonRole becomes dtPartyRole in the RepresentationSystem.

Lastly, we need to add an "Other" type to dtPartyRole. While the below list is long, there are certainly types of business relationships we cannot anticipate.

Authorizer
Crop Advisor
Customer
Custom Service Provider
Data Services Provider
End User
Farm Manager
Financier
Fixed Asset Supplier
Government Agency
Grower
Input Supplier
Insurance Agent
Irrigation Manager
Laborer
Market Advisor
Market Provider
Mobile Asset Supplier
Operator
Owner
Transporter

[strhea]

Is there a need for a "party type" property to distinguish between Person & Company in defining the resource? That distinction would be separate from the "party role" property used in explaining how the resource is used in the context of a field operation.

[zwing99]

+1 for Party! 🎉

I would agree with @strhea that we need to have a Party Type. I am open to it being a boolean (IsPerson) if that is easier with a default of false. Or as an Enum with values of Company, Person, and more to be added later. I would, however, suggest that we want to avoid having an "Unknown" type of Party. I think it risks being overly defaulted and unuseful in communicating information between FIS systems. I would suggest that we instead default to Company or IsPerson=false.

[knelson-farmbeltnorth]

Agreement on Oct 19 2022 call for condensing Person & Company into Party, with the addition of the Party Type. For now, there is no consensus on Party Type Unknown so we leave that as an open issue.

Further agreement that PartyRole should be a value and not a reference type, and its id and name be removed. In the call we validated the usages of PartyRole in the system and confirmed a single role is appropriate on a Summary Value, with multiple roles appropriate elsewhere. We decided to avoid adding PartyRole-Other, choosing instead to encourage additions to the list rather than misclassified data.

[knelson-farmbeltnorth]

PartyType is currently defined as follows.
"Business",
"Individual"

Whether or not to add Unknown is the one remaining item on this issue.

[knelson-farmbeltnorth]

November 30, 2022 meeting resolution: PartyType should be "Organization," "Individual," and "Unknown"

[knelson-farmbeltnorth]

Looks like we went out with "business" instead of "organization." Rerouting to review for a decision on whether or not to leave as is.