RFC - Amalgamations

[argush3]

Overview

This document is intended to help flesh out some of the design elements for amalgamation filings.

Specifically, we would like to establish a shared understanding of how to move forward with respect to the following items:

• How will the amalgamation information be represented from a data modelling perspective
• What actions will take place in the filer besides the creation of a new business
• Will an additional ledger item be created for historical amalgamating businesses to represent the amalgamation?
• What will the business response look like
• Does the UI have everything it needs from an API perspective to display amalgamation information for the amalgamating businesses and the amalgamated business?
  • ledger item
  • tombstone

Db Model Updates

Add amalgamating_business and amalgamation table

Filer Updates

• New business created per items defined in amalgamation filing json. This will be similar to how business are created via an IA filing.
• New business will have state_filing_id populated with amalgamation filing id
• Amalgamating businesses will have following fields updated in businesses table
  • state = HISTORICAL
  • state_filing_id = amalgamation filing id (populated but not available in TING's business response)
  • dissolution_date = filing effective date
• Populate amalgamating_businesses table
• Populate amalgamation table

Business Response

Amalgamated Business

GET /businesses/<business_id>

No changes to current GET business endpoint.

{
  "business": {
    "identifier": "BC1531299",
    "legalName": "amalgamated business name",
    "legalType": "BC",
    "state": "ACTIVE",
    "hasCourtOrders": true
  }
}

Amalgamating Business

Note that the state_filing is not populated as TINGS should not be able to access the TED's filing.

{
  "business": {
    "identifier": "BC1111111",
    "legalName": "amalgamating business name 1",
    "legalType": "BC",
    "state": "HISTORICAL",
    "dissolutionDate": "2010-06-09T07:00:00+00:00",
    "hasCourtOrders": false,
    "amalgamatedInto": {
      "amalgamationDate": "2010-06-09T07:00:00+00:00",
      "amalgamationType": "regular",
      "identifier": "BC1531299 ",
      "legalName": "amalgamated business name"
    }
  }
}

UI

• Amalgamating businesses will have no additional ledger item for the amalgamation
• Amalgamation info returned in business response can be used for tombstone data specific to amalgamations

Misc

• allowable actions can use amalgamation tables or state_filing_id to determine if a historical amalgamating business can be restored

[severinbeauvais]

I'm OK with having another table or 2 to hold amalgamation info, but the lack of a ledger entry requires quite a lot of extra info/complexity in the business response, which I think is undesirable.

[argush3]

I'm going to post an alternate version of business responses to just provide the info I see being used in legacy system.

The business summary can access the amalgamation tables directly behind the scenes.

[argush3]

I've added a "version 2" for the business responses.

Basically only amalgamating businesses have a change in business response.

Legacy system examples:

TED

TING

[argush3]

yeah, I think I like v2 of the business response for TINGs if that is good enough for our needs.

[severinbeauvais]

I like v2 better as well.

"stateFiling": "https://legal-api-dev.apps.silver.devops.gov.bc.ca/api/v2/businesses/BC1531299/filings/147326",
"amalgamatedInto" ...

There's some redundancy here (they both provide the same view into what happened). And there's still a question whether this business (BC1111111) can fetch a filing indexed to the other business (BC1531299). see other comment below

If we definitely don't want a (hidden) final filing in the ledger then I think this is next best thing.

PS Is the ting still ACTIVE?

[argush3]

Updated TING to be HISTORICAL

[severinbeauvais]

Will the Legal API need a special authz for an amalgamating business to fetch the "state" filing using the amalgamated business' identifier?

[severinbeauvais]

Oh. It feels like it should be, otherwise I can look at anyone's ledger.

[argush3]

yeah, feels like it should.

Just not sure what if we open up a can of worms if we start locking it down.

[severinbeauvais]

Yeah, but what's worse? Worms or a security issue? 🤷‍♂️

[argush3]

Not saying we shouldn't lock it down. Just envisioning the glass eating.

[severinbeauvais]

New ticket (for future):
https://app.zenhub.com/workspaces/entities-team-space-6143567664fb320019b81f39/issues/gh/bcgov/entity/18968

[severinbeauvais]

Do you have an example of an amalgamating business' business response with the state filing id?

[severinbeauvais]

Will an amalgamating business have both a state filing and the filing in the amalgamationInfo object?

[argush3]

Yes, and I just added a state_filing property to the amalgamating business response.

[severinbeauvais]

Nice.

Should the amalgamated business also have a state_filing -- does a corp show its IA as the state filing that caused it to exist?

[argush3]

I think it makes sense to include fill the state filing for creation of a businesses via IA, registration and amalgamation filing.

We don't do this yet for IA or registration filings yet though. If we do there will need to be a data update exercise.

[severinbeauvais]

Sounds good to me. Curious what @thorwolpert thinks.

[severinbeauvais]

Also, I see a name mismatch between dissolved_date and dissolutionDate. Intentional?

[argush3]

Thanks and fixed.

Meant dissolution_date

[severinbeauvais]

Are we OK with an amalgamating business seeing the other amalgamating/ted business info? I thought Yui expressed an issue with that.

[argush3]

Well, info is pretty limited.

Let me see if OrgBook provides all that info right now for amalgamating businesses.

[severinbeauvais]

Good point. There may be a business/legal requirement.

[severinbeauvais]

Not quite the same, but:

We could always have a final ledger filing but not display it, same as bcgov/entity#16967.

[argush3]

So yeah there is limited info on the ledger and tombstones of TINGs and TEDs involved in amalgamations when I look into SOFI.

And Orgbook has minimal info too.

[argush3]

what does hide do

[severinbeauvais]

what does hide do

It hides the comment I hide, but not the whole thread.

[severinbeauvais]

It also looks like it creates a new thread 🤦

[severinbeauvais]

I still favour the idea of a "final filing" for each amalgamating business (hidden from ledger with a flag). This:

• would be consistent with our business state flow,
• wouldn't need one business to access another business' filings (ie, state filing), and
• wouldn't require "historical by amalgamation" to be a very special case.

[severinbeauvais]

Maybe that's the "date of dissolution"?

[argush3]

Is the amalgamation date available anywhere?

So are you saying you don't want the amalgamationInto block in the business response? That blocks contains the amalgamation date and a few other things.

[severinbeauvais]

Oops, I missed that.

Looks like the amalmagationInto block has all the info the UI needs for a historical reason.

Maybe the state filing is redundant then? Especially if the TING cannot open it. What do you think - could it be used in the future? Could it be used to cross-reference filings between businesses (kind of rebuilding the amalgamation references)?

[argush3]

I think we go back to original suggestion of not showing the state filing then.

The state_filing will still be set in the business table and still be used by the BE in addition to the new amalgamation tables.

[severinbeauvais]

Yes. Sorry about the run-around on this one 😅

[argush3]

@severinbeauvais @thorwolpert I've updated the RFC to an end state that I think we can move forward with.

If anyone has any objections, stop me now!

[severinbeauvais]

I think there are some tiny details to work out but I think this will work.

In the end: amalgamations will require a special case to handle them in the UI (ie, separate from other historical businesses).

[severinbeauvais]

New business will have state_filing_id populated with amalgamation filing id

Is that what we do for IAs also? I already asked this question above, though there's no resolution on this yet.

[argush3]

No, we don't it currently for IAs or registrations but as per our previous discussion, it makes sense I think.

My thought is we add it for amalgamations(TEDs) and have future tickets to update filer for IAs/registrations as well as backfill the data.

[severinbeauvais]

For IAs, Regs, and the TED 👍

[severinbeauvais]

Did we ever decide whether to show an alert on the historical TINGs? The UI designs don't show one, and I'm not sure it's needed, but it could be used to approximate what COLIN currently shows (or we could add a tooltip to the HISTORICAL badge - I'll ask Yui).