Legal API Validation - TING Put Back On

[Mihai-QuickSilverDev]

In short: when putting back on a TING, should we validate that the TED has been dissolved?

THIS FEATURE IS STILL UNDER DESIGN. SEE COMMENTS BELOW FOR DETAILS.

• [ ] if the TED was dissolved with Administrative Dissolution, then allow TINGs to be Put Back On
  • but, what if the TED ceased operations and was admin-dissolved -- don't we want to block the TINGs from being put back on?

[OlgaPotiagalova]

Already implemented. No change is required.

[vysakh-menon-aot]

@OlgaPotiagalova @NaveenHebbale Do we need to validate if TED is dissolved before TING can put back on? or is it something staff should handle by themself?

Note: This can also be handled in allowable actions. In this case Put back on filing will not available without dissolving the TED. This will be an exception from rest of the putbackon options

[NaveenHebbale]

@vysakh-menon-aot , TED need to be dissolved first and TINGs can be Put-back-on.

• How much effort we have put to create this logic
• Staff is already doing similar process in COLIN Kathy Shared the Undo -Amalgamation Process To Undo the amalgamation:

1. File court order on amalgamated company (BC1113483) a. Text description: COURT ORDER DATED JUNE 2, 2017 NULLIFYING AMALGMATION OF 465857 B.C. LTD., BOYLES BACKHOE LTD. AND NORTH COAST BOOMING CONTRACTORS LTD. COMPANIES TO BE REAMALGMATED AND RENAMED EFFECTIVE MARCH 31, 2017
2. Put company (BC1113483) in Administrative Dissolution (D2A)
3. Raise urgent ticket to have company made historical immediately.
4. Once made historical, put the amalgamating companies back onto the register a. On COLIN, under Restore company select "restore a company that was dissolved in error" b. Document Amended/Corrected = amalgamation c. New ledger text description: COURT ORDER 171884 ISSUED JUNE 2, 2017 - HORIZONTAL AMALGMATION DONE INCORRECTLY.

[OlgaPotiagalova]

Thank you for pointing this out, Vysakh. If the validation in simple to implement, we might add it. Please advise.

[vysakh-menon-aot]

Validation would be the easiest implementation

SB says: unfortunately we don't know if the TED was admin-dissolved because it ceased operation or the amalgamation needs to be reverted -- so we might accidentally allow a TING to be put back on.

[OlgaPotiagalova]

@vysakh-menon-aot In this case we would like to have the validation added to respect data integrity principles. Thank you

[severinbeauvais]

Olga, we would always implement the validation to protect data integrity, but this check happens after you try to file the Put Back On. Two downsides here:

• staff will already have tried to Put Back On and it didn't work (we prefer to block them from mistakes up front)
• the validation error message provided by the API (eg, "can't put back on until TED is dissolved") won't be displayed by the UI; this is a staff filing with very simple error handling -- we just say there's an error, not what the error is -- would need extra work in UI to handle this

In addition to the validation, should we disable/hide the Put Back On staff action (via allowable actions) if the TED isn't historical? The downsides here are:

• we don't yet have this kind of logic in the allowable actions
• if we disable/hide the Put Back On staff action, staff might not understand why it's not available (showing a tooltip to explain why would get complex here)

I have a slight preference for the first option because it's potentially less work and less confusing for staff. If possible, ask Yui for his opinion on this. @yuisotozaki Please check this.

[yuisotozaki]

From UX point of view, it would be good to let the user know what they can and cannot do before they attempt an action. So option 2 would be preferred.

[severinbeauvais]

@yuisotozaki Can you please list the details of what option 2 means to you (tooltip, disabled action, error messages, etc)? Thx.

[yuisotozaki]

@severinbeauvais I meant to refer to the "disable/hide the Put Back On staff action (via allowable actions) if the TED isn't historical" option.

Ideally, when a staff loads the entity dashboard of a business that was made historical due to amalgamation, we check if the TED's amalgamation was reversed via administrative dissolution.

If the TED is still active, we disable the put-back-on with a tooltip stating, "This business cannot be put back on. The amalgamated business is active."

If the TED is historical, we need to somehow discern whether the dissolution of that company was a "reversal of the amalgamation" (and which one if there were multiple) or it was just a dissolution due to court order to cease operation.

If we can tie admin-dissolutions to an amalgamation, that would make this logic easier to handle. We would also need to ensure that only the latest amalgamation can be admin-dissolved. We would be able to support 2+ layers of amalgamation reversal this way too.

[severinbeauvais]

deleted obsolete comment

[vysakh-menon-aot]

deleted obsolete comment

[vysakh-menon-aot]

@yuisotozaki current idea is to enable/validate TING putbackon when TED is dissolved via administrative dissolution. But I am not completely convinced with that logic since a staff can do an administrative dissolution for other reason's as well.

SB says: that's right. I'll hash this out in detail in a new comment below.

[severinbeauvais]

deleted obsolete comment

[severinbeauvais]

deleted obsolete comment

[vysakh-menon-aot]

deleted obsolete comment

[severinbeauvais]

deleted obsolete comment

[jdyck-fw]

Sev and Vysakh will discuss a design in more depth here, then we can reconsider the estimation if needed.

[severinbeauvais]

After some discussion, we don't have a workable design for this after all.

The main problem is that, if the TED (new business) is admin-dissolved, we don't know why it was dissolved. It could be due to ceased operations, or it could be due to an amalgamation reversal.

There's also the complexity of enabling/disabling Put Back On staff action on a TING and showing a tooltip on the disabled one -- currently we hide the PBO when it's not allowed, and the tooltip doesn't apply in all cases when it's allowed.

We talked about a more straight-forward design (fewer edge cases): if the TED needs to be dissolved to revert an amalgamation (ie, make a new staff menu option, and likely add a dissolution sub-type), then we have the Filer restore the TINGs. @yuisotozaki @NaveenHebbale @OlgaPotiagalova @thorwolpert , what do you think about this? We'd need to walk through this a bit to see if everything looks OK at all stages.

[severinbeauvais]

@mihai is pushing for a fully manual process here (at least initially). I will add comments below on this, but be aware that there are edge cases that we will NOT be able to handle. (However, these may not be a problem if the staff do all steps in a single session.)

cc: @vysakh-menon-aot @OlgaPotiagalova

[severinbeauvais]

Option 1 - manual process

Steps:

1. staff does Admin Dissolution on the TED
2. staff does Put Back On for all the TINGs

Pros:

• least amount of work, since we already support Admin Dissolution (for TED) and Put Back On (for TINGs)

Cons:

• Put Back On is not yet complete for TINGs, since we need to do something with the amalgamation object
• TINGs will be in a weird state where they are historical but don't have an amalgamation object to display the reason why (in UI badge)
• we don't record (other than detail comments) why the TED was admin dissolved (*)
• TING Put Back On menu option won't have tooltip (*)
• we can't prevent Put Back On for a TING where the TED was admin dissolved for another reason (*)
• we can't prevent Put Back On for a TING where the TED is still active (*)
• TING ledger may show Put Back On without a prior dissolution

(*) if we don't know that the TED was dissolved to revert an amalgamation then we can't apply special allowable actions rules for this scenario

Option 2 - automated

Steps:

1. staff clicks "Reversal of Amalgamation" (new staff filing action but is effectively same as Admin Dissolution) on TED (should we use type D2A?)
2. Filer automatically does Put Back On (or "restore company dissolved in error") for all TINGs (or, filer just makes TINGs active again without a filing -- the reverse of when they were made historical due to amalgamation)

Pros:

• easiest for staff
• we record the reason the TED was dissolved (using Admin Dissolution subtype?)
• no need for Put Back On of TINGs
• maybe don't need Put Back On filing in TING's ledger

Cons:

• needs some extra Filer work (but Filer already knows how to make TINGs historical so it can easily do the opposite now)
• needs some extra Legal API allowable actions work (which doesn't fit well in existing code)

[thorwolpert]

@severinbeauvais there's already subtypes for dissolution to handle self filing; administrative which is added when a job dissolves the business, or the Register dissolves a business. It should get filed for a dissolution event, unlike Colin.

[severinbeauvais]

@thorwolpert Yes, thanks. I was thinking that we could use a new subtype to indicate that this is a reversal of amalgamation instead of a regular admin dissolution.

[severinbeauvais]

There is actually a hybrid option:

1. staff clicks new "Reversal of Amalgamation" filing action (which, again, is the same as an admin dissolution except we'd use a new subtype so we know this isn't a regular admin dissolution)
2. staff does Put Back On for all the TINGs

The reason for the new (admin) dissolution subtype is so that we can apply special rules / allowable actions to the TINGs regarding their restoration / put back on.

Notes:

• "Reversal of Amalgamation" staff action would only be visible for TEDs (ie, businesses created as a result of an amalgamation)
• "Admin Dissolution" staff action would be visible for all active businesses (same as today) including TEDs
• "Put Back On" would be hidden for TINGs (ie, made historical as a result of an amalgamation) or
• we could add a separate "Put Back On" (mutually exclusive with the regular one) for TINGs, which we could enable/disable and show a tooltip

[OlgaPotiagalova]

If adding validation generates much more work, the simplest solution for the MVP release will be enabling the Put Back On, without validating the TED has been dissolve, and let the staff to decide when to use the option. Then do enhancements after the MVP. We will discuss with the business next week.

[severinbeauvais]

If adding validation generates much more work, the simplest solution for the MVP release will be enabling the Put Back On, without validating the TED has been dissolve, and let the staff to decide when to use the option.

I agree.

@vysakh-menon-aot , how much extra work do you think validation (including new dissolution subtype + allowable actions) will take?

As far as UI work, adding a couple of staff filing actions, according to allowable actions, is very straightforward.

[vysakh-menon-aot]

@severinbeauvais if we introduce new dissolution type then we can simply disable putbackon on TING, otherwise we need to implement validation on TING as we discussed here. I agree with @OlgaPotiagalova for now lets go without validation or new dissolution type. Let the staff decide when to do putBackOn.

[thorwolpert]

@thorwolpert Yes, thanks. I was thinking that we could use a new subtype to indicate that this is a reversal of amalgamation instead of a regular admin dissolution.

Sounding complicated to me. We should push to make it simpler.

[severinbeauvais]

@thorwolpert Your dismissive comment isn't helpful.

Anyway, I think it's been decided that we will NOT keep track of whether a TED admin dissolution is due to a reversal of amalgamation or a regular business end, and we will NOT add validation to prevent putting back on a TING (ie, can be put back on even if the TED hasn't been dissolved). Staff will just have to be extra careful.

Therefore, this ticket is obsolete and can be closed.

[thorwolpert]

I wasn't being dismissive, it was sounding complicated to me. There's also all of the names integration needed to use names that have been marked open. For MVP, I truly hope we can take a simpler approach before trying to build out something like this .

[severinbeauvais]

Some of this design was discussed over email:

From: Dinu, Mihai CITZ:EX <Mihai.Dinu@gov.bc.ca> 
Sent: Friday, March 8, 2024 10:15 AM
Subject: Business process - undoing an amalgamation

Hi All,

At least from a business process pov and keeping the like-for-like principle, things appear to be relatively clear.

Amalgamation reversal steps – proposed/to be state:

1.  Request is put forward to undo the amalgamation 
   a.   Client has court order to that extent
   b.   Staff realizes a mistake was made
   c.   Other
2.  Staff Admin Dissolves the Ted company
3.  Staff manually make all the TINGs involved back Active 
   a.   Via Put back on
   b.   Or via Restoration
4.  The above steps are usually done by Staff in one run, so there should not be timing issues.
5.  Once the amalgamation is undone, the Ted which now would be historical should not be able to permanently become back active. 
   a.   That Ted only existed in light of the original amalgamation, and that is now done.
6.  The Put Back On filing needs to be made available for any entity in the registry, independent of their allowable states.
7.  Once the amalgamation is undone, the Ted and all TINGs need to continue to have history showing that they were involved in an amalgamation that was later undone. 
   a.   For Ted this is done in ledger and Business Summary.
   b.   For Ting this is done in Business Summary.

Thank you,

Mihai Dinu

From: Beauvais, Severin 
Sent: Friday, March 8, 2024 10:22 AM
Subject: RE: Business process - undoing an amalgamation

Hello,

Do we need validation (or to disable staff actions) to prevent a TING from being restored/put back on if the TED hasn’t been dissolved?

Can you please expand on what the TED and TINGs will show in their ledger and/or Business Summary?

Thanks,
Severin

From: Dinu, Mihai CITZ:EX <Mihai.Dinu@gov.bc.ca> 
Sent: Friday, March 8, 2024 10:45 AM
Subject: Follow-up - RE: Business process - undoing an amalgamation

> Do we need validation (or to disable staff actions) to prevent a TING from being restored/put back on if the TED hasn’t been dissolved?
Staff would be working with documentation on hand and can control the scope from their end, without extra system safeguards in place.

> Can you please expand on what the TED and TINGs will show in their ledger and/or Business Summary?
The business opened a double door for us on this. 
a.  We could use the Dissolution/Put Back On section
b.  We could use a new Amalgamation details section

> Will come back here with more details to this question.

Thank you,

Mihai Dinu

[NaveenHebbale]

As Discussed during COLIN Migration Phase I - BEN, ULC, CCC, BC - Requirements Gathering Meeting Notes March 12,2024, Point b .For MVP release (to keep it simple, without increasing complexity) - Put Back On will be available for TINGs, and there won’t be a validation that TED is dissolved. Staff will be responsible for ensuring the Put Back On option is used properly in this scenario. (We can implement such validation as an enhancement later, possibly after the MVP). Business Answer is OK