# Party Restructure Work Plan

This is an outline of how to introduce and transition parties from MDS only data, where data duplication is an issue, to use a friendly unique identifer (like mine number or permit number) based on their legal registration with the BC Registrar.

This should be considered a draft, to be expanded on an revised as needed, this not detailed enough to be converted directly to backlog items, so planning and refinement still needs to take place.

## Goal:
1 entity (individual or business) should have one party record in MDS.

## Blockers:
permit_amendments relate to permits, permits related to permitees (a type of party)

Multiple parties have the identical names, but different emails/phone numbers

Multiple parties have very simliar names, but it's unclear if those are the same BC Business, or not.

Organizations do not have a friendly unique identifier, so we should just make or produce one, why not make it the BC Business Registration Number.

## Phases
These can be carried out at what ever pace the product owner, development team, and business are able to handle. I imagine over a yera or more starting in May 2024 with the need for VC's to use the BC Registration Identifier.

### Phase 1

#### Requirement:
For every permit_amendment record, there must be a BC Business Registration number

##### Proposed Changes:

1) Allow multiple parties to be associated with Orgbook Entities through CORE Party Edit.

### Phase 2

#### Requirment:
Expand Party data structure to be more representative, ADD data structure for Organizations.

##### Proposed Changes:
1) Explore how an Organziation is different that a party of type organziation.
1) Relate People to Organizations?
2) handle multiple emails
3) handle multiple phone numbers

### Phase 3
#### Requirement:
Require BC Business Number from users (Ministry and Minespace) to introduce identifier.

##### Proposed Changes:

1) Only allow use of party that is related to orgbook entity (by registration number) on input forms, either by adding the orgbook business registration to an existing party, or only using a party that has the business registration already attached.
**Build with strong REUSE in mind (replace any form fields that reference businesses with this identical component, intercept any new data creation by suggesting existing parties)**

1) lookup or submission by BC Registration number s hould attach to ANY party record that has the same number. If none, make new.

1) Make mandatory to use on the following input forms?

CORE
- Selecting permitee
- Creating new organization (do not allow if orgbook entity already used?)

Minespace
- Applying to major project
- Applying for Notice of work

3) Allow historical clean up of party relationships
- Change permit_amendment permitee
- Combine sequential mine_party_appts

### Phase 4
#### Requirement:
Incentivise business to clean up data, and add BC Registrations to 100% of active business records, even duplicates.

##### Proposed Changes:
1) Metabase reports and manual efforts to get full coverage of identifier
2) Decide on what value to give historical or deleted records.

### Phase 5
#### Requirement:
Merge all party records with the same BC Business Registration to one database row.

##### Proposed Change:
1) Update all party_guid FK's to one party_guid per business
2) Combine all information from all copies that were merged (emails/phone numbers, etc)

# Mines Act Permit as UNTP Conformity Credential for Major Mines

### Current Issues
What BC Business Registration Number do we issue given permit_amendments to?

Permits have Permitees, and permits have permit_amendments, but permit_amendments are not directly related to parties.

Data from MMS did not consider reuse of parties, so many data duplication comes from that legacy data.

PROD MDS DATA:
https://metabase-4c2ba9-prod.apps.silver.devops.gov.bc.ca/collection/239-jason-syrotuck-1-s-personal-collection

What needs to be fixed.

Permit_amendment - BC Business Registration needs to be strongly linked through the party table.

One Business Registration should have one party in CORE, this requirement could be dropped, but it will perpetuate data quality issues.

Quick fixes:

1) Allow multiple parties to relate to the same Orgbook entity
2) Add a party_identity layer to connect multiple parties into a collection, and assign all the entries in that collection to an Orgbook entity.
3) Manually transition data and combine parties
- What data would be lost by this
- What data structure changes could happen to reduce this data loss or improve the use of it.

# MDS Parties in General

## Business Usage:

What Uniquely Identifies an Organization?
What Uniquely Identifies a Person? Email address?

Are they fundamentally different or the same?

## Data Structure Changes Ideas:

Add `organization` table that more represents how the buisness uses this data. People relate to orgs, e.g.

party_organization get a friendly identifier as it's unique ID
- first letter of each word65 + 4 random digits?
- OR introduce the BC Registration Number early and use that to clean later.

## Data Entry:

Proposal: Stop making parties if they aren't going to be reused.

How do we stop making new parties?

How do we reuse existing parties?

## Data Clean up:

How do we fix the existing data?

party_guid has 27 fk's

| table_name | column_name | party_type |
|:-------------------------------------------- |:---------------------------------- | ---------- |
| address | party_guid | either |
| bond | payer_party_guid | either |
| explosives_permit | issuing_inspector_party_guid | person |
| mine_incident | determination_inspector_party_guid | person |
| mine_incident | reported_to_inspector_party_guid | person |
| mine_incident | responsible_inspector_party_guid | person |
| mine_party_appt | merged_from_party_guid | ? |
| mine_party_appt | party_guid | either |
| now_application | issuing_inspector_party_guid | person |
| now_application | lead_inspector_party_guid | person |
| now_party_appointment | merged_from_party_guid | ? |
| now_party_appointment | party_guid | either |
| party_business_role_appt | merged_from_party_guid | ? |
| party_business_role_appt | party_guid | either |
| party | merged_party_guid | ? |
| party_orgbook_entity | party_guid | organization |
| project | project_lead_party_guid | |
| project_summary | project_summary_lead_party_guid | |
| variance | applicant_guid | |
| variance | inspector_party_guid | person |
| project_summary | agent_party_guid | |
| explosives_permit_amendment | issuing_inspector_party_guid | person |
| party | organization_guid | organization |
| party_verifiable_credential_connection | party_guid | organization |
| party_verifiable_credential_mines_act_permit | party_guid | organization |
| project_summary | applicant_party_guid | |
| project_summary | facility_operator_guid | |