LEAR?: removing pre-existing company provisions doesn't work

[severinbeauvais]

1. load a BEN
2. start a change filing
3. change Pre-existing Company Provisions to "none" (enable checkbox)
4. click Done
5. file and pay
6. start another change filing
7. observe that Pre-existing Company Provisions has not changed

[severinbeauvais]

I'm moving this to this sprint / backlog because some of us are looking for more work.

[lewischenstudio]

Current Issue: Filing a BEN IA alteration filing with "Pre-existing Company Provisions" being checked will update "hasRestrictions" in the business object. Edit UI didn't hook up this field. Suggestion: Edit UI hook up this field to render the component. Question: Do we want to render the component for alteration filings upon creation? . . New issue: Filing a BEN IA correction filing with "Pre-existing Company Provisions" being checked does not update that field in the backend. Entity-filer? Legal API? BC0871200 FYI. Ticket: waiting the above issue gets resolved. Is the above suggested solution the accepted solution?

[jdyck-fw]

Blocked pending updates from @Mihai-QuickSilverDev and @sarahelz19 .

[lewischenstudio]

Moving the discussion from RC to here:

Do we want to make the component “Pre-existing Company Provisions” mandatory for BEN IA alteration filings when staff users create them for the first time? It is currently not being displayed for a new alteration filing, but it is displayed for a new correction filing. The suggested solution will be implemented for both or only correction filings depending on the business decision.

@Mihai-QuickSilverDev @sarahelz19 Any update on the business decision?

[Mihai-QuickSilverDev]

Do we want to make the component “Pre-existing Company Provisions” mandatory for BEN IA alteration filings upon creation? It is currently not being displayed for a new alteration filing, but it is displayed for a new correction filing.

@lewischenstudio Lewis, the answer from the Business is Yes. Please add the "Pre-existing Company Provisions” section on Alterations too.

SB: I believe the above is incorrect. Read comments below instead.

[lewischenstudio]

@Mihai-QuickSilverDev That's great to know. Thank you Mihai. This ticket is no longer blocked.

[jdyck-fw]

Pre-existing company provisions doesn't apply to a BEN. @lmcclung

[lmcclung]

@Mihai-QuickSilverDev @lewischenstudio here's your answer: Pre-existing conditions are conditions that were allowed under the now defunct Companies Act legislation. ULCs, CCCs and BENs did not exist under the old legislation. Any new IA for all four corporate entity types would not have a 'pre-existing conditions' option as the entity does not legally exist and never existed under the defunct legislation.

But... if we're talking database fields and the pre-existing conditions indicator. We still need this indicator for potentially all 4 flavours of corporations for different filings. Needs more investigation, but I'm thinking restorations, alterations and maybe amalgamations.

A little more background for you: When the Business Corporations Act came out in the early 2000s, all existing BC Limited companies has to transition to the new legislation. As part of this, they had to file a Transition Application. On that application they had to mention if they had pre-existing conditions. Once they transitioned, they got a Notice of Articles (a new output that didn't exist under the old legislation). If they declared they have pre-existing conditions, their Notice of Articles also included the statement: The Pre-existing Company Provisions apply to this company. At any time in the future they could file an alteration to remove the pre-existing company provisions. The Notice of Alteration output then had the statement: The company has resolved that the Pre-existing Company Provisions no longer apply to this company. The Notice of Articles would no longer have the “Pre-existing Company Provisions’ section on it. Once Pre-existing company provisions were removed, they can no longer be added. For alterations, the Pre-existing conditions option on the UI, when we build it, should only display as an option if the company had pre-existing conditions in COLIN.

Mihai, we'd need to test in COLIN whether an LTD with pre-existing conditions has to remove them before they can alter to become another corp type; or whether they have to remove them before they amalgamate (if short form and want to adopt).

[lewischenstudio]

Thank you @lmcclung for the update. This is very comprehensive and informative. Please correct me if anything in the discussion below.

[lewischenstudio]

@lekshmimallika-aot @severinbeauvais Based on the information above, the suggested solution will have the following behavior for alteration and correction filings, which are being considered so far on the UI. We use "hasRestrictions" to refer to the status that pre-existing conditions are resolved/removed, then we have the following behaviors:

New alteration/correction filing

1. Entity BEN IA BC0000001 has not removed the pre-existing conditions, and "hasRestrictions" is false.
2. Open a new alteration/correction filing to display the pre-existing conditions component.
3. Check the pre-existing conditions checkbox, submit the filing and have "hasRestrictions" to return true.
4. Open a new alteration/correction filing, and the pre-existing conditions component is no longer displayed.

The following feedback is open to discuss/consider in regard to the above behavior:

1. Since the pre-existing conditions indicator/checkbox is optional, the UI will display the pre-existing conditions component as long as "hasRestrictions" is false and will not display it if true.
2. "For alterations, the Pre-existing conditions option on the UI, when we build it, should only display as an option if the company had pre-existing conditions." However, there is no field to tell whether the company had pre-existing conditions. "hasRestrictions" is used here as an indicator for whether the pre-existing conditions are removed, and its value is false by default (most of the time). We then assume the company had pre-existing conditions -- to display the component -- because the pre-existing conditions have not been removed, which is equivalent to "hasRestrictions" is false.
3. Correction filings would not display the pre-existing conditions component if pre-existing conditions were removed, so it cannot be "un-removed" in the correction filing.

[Mihai-QuickSilverDev]

A few quick comments here:

1. If we performed in the modernization application an alteration from BC LTD (COLIN) to BEN (modernization), and if the BC LTD was incorporated under the old act, and if it has pre-existing conditions, then tentatively we could have a BEN with pre-existing conditions. We should be able to verify if we have any, between the COLIN and Postgres databases, as we have only performed so many alterations.
2. In COLIN there is a Pre-existing Conditions, PEC flag. Ideally we carry this flag over in our Postgres schema, as it would help us determine unequivocally when pre-existing conditions apply, and properly handle possible scenarios.

[lewischenstudio]

Thanks @Mihai-QuickSilverDev for the update.

Given the new requirement above, where we treat "hasRestrictions" as the pre-existing conditions (PEC) flag, the following behavior is the new suggested solution.

1. When "hasRestrictions" is true, UI displays the Pre-existing Conditions.
2. Check the PEC component checkbox, submit the filing and have "hasRestrictions" to return false.
3. Open a new alteration/correction filing, and the PEC component is no longer displayed.

[Mihai-QuickSilverDev]

Good Morning @lmcclung I wanted to ask if, in your recollection, in the modernization application, the Pre-existing Conditions could be removed from any of these three filings - Alteration, or Change, or Correction? Or does it have to be Alteration only? Thanks much!

[lmcclung]

@Mihai-QuickSilverDev - First off... corporations don't have 'change' filings like SP/GPs. FYI, if you start calling them change filings you are really going to confuse staff. The alterations/COD/COA filings are the equivalent of an SP/GP change filing.

But to answer your question... alterations, corrections, restorations and amalgamations would all potentially have pre-existing conditions across all corporate types (even a BEN, CCC or ULC if they were originally an old LTD or an old LTD was amalgamated to create the entity).

@lewischenstudio The pre-existing conditions component under the articles section should only display if the entity has pre-existing conditions that can be removed. @Mihai-QuickSilverDev @davemck513 I've never seen a time where pre-existing conditions were removed accidentally and needed to be put back on via correction. If it ever happens maybe we'd just do a jupyter notebook for it. I don't think we need to spend extra money to build in the extra logic to display it in correction filing if once upon a time an entity had the pre-existing conditions.

[Mihai-QuickSilverDev]

@lewischenstudio Hi Lewis, correct, and considering that Pre Existing Conditions is not an error to be corrected, then PEC should only dealt with in an Alteration.

[severinbeauvais]

@Mihai-QuickSilverDev

The requirements state: "The company has resolved that the Pre-existing Company Provisions no longer apply to this company."

The code display the follow. Is it OK or should I change it?

[Mihai-QuickSilverDev]

The requirements prevail.

[severinbeauvais]

Test Notes

• a business with pre-existing conditions should display the Articles - Pre-existing Company Provisions section, ie:

• a business without pre-existing conditions should not display the section
• if you check "the company has resolved..." and file the alteration, then you will not see the section in a future alteration
• this should display only for alterations (not corrections)

[severinbeauvais]

This fix contains Edit UI, Legal API and Entity Filer changes.

I have verified the above in Dev.

Here are some other Dev businesses that have "has restrictions" flag as True. (Note that BENs should not have this flag because BENs did not exist when this flag was set, but this fix is entity-type-agnostic so testing should still be valid.)

• BC0871185
• BC1230085
• BC0870655
• BC0871178
• etc

Query used above: select * from businesses where restriction_ind=true.

[severinbeauvais]

@argush3 Re:

• [ ] verify company provisions / has restrictions flag is carried over in data imported from COLIN (schema?)

Do you know whether this works, or where to check?

[argush3]

@argush3 Re:

• [ ] verify company provisions / has restrictions flag is carried over in data imported from COLIN (schema?)

Do you know whether this works, or where to check?

This is accounted for in the data mapping for corps data migration @severinbeauvais. I have that data in the COLIN data extract that the pipeline will be working off of. When I get back to working on bring over IAs, I will make sure the corps data pipeline will include the restrictions flag. As of now, we don't have any data imported into DEV/TEST that you can check yet.

Corp restriction section in data mapping spreadsheet