COLIN Sync - Incorrect COLIN filing type used for alteration filing synchronization (BC to Benefit).

eve-git commented 7 months ago

We have a job running hourly to sync alteration filings between BC and Benefit. During syncing BC to Benefit filings, we use 'NOALA' (Alteration of Company Information) as the COLIN filing type. However, it should actually be 'NOALE,' indicating an alteration from a BC Company to a Benefit Company.

As per David R., COLIN alteration filing types below:

NOALA FILING Alteration of Company Information Notice of Alteration NOALD BENCOM Alteration from a BC ULC to a Benefit Company Alteration from a BC ULC to a Benefit Company NOALE BENCOM Alteration from a BC Company to a Benefit Company Alteration Application from a BC Company to a Benefit Company NOALR BENCOM Alteration from a Benefit Company to a BC Company Alteration Application from a Benefit Company to a BC Company

https://docs.google.com/document/d/1epRhvE7uwXnHQ15FRxgh7Pi_rBSPLCth/edit

Mihai-QuickSilverDev commented 6 months ago

@eve-git

[ ] Synch process from BCROS --> COLIN should only apply to BEN company types
[ ] The BEN-->BC company type alteration is not live in BCROS.
[ ] When an Ops developer completes this filing manually, then they should use the correct filing type in COLIN.
[ ] A list of COLIN filing types was added in this ticket's description.
[ ] Names team will verify synchronization now works as expected.
[ ] Names Team to fix any old alteration issues @ozamani9gh @rarmitag

OlgaPotiagalova commented 3 months ago

Filing types reference table:

OlgaPotiagalova commented 3 months ago

More information from the e-mail from Michael Kagis:

"Here’s a screenshot of the ledger for BC1257470, which David R. points to in his email below (note the hyperlinks for Notice of Alteration and Notice of Articles in the Notice of Alteration filing below; those are filing outputs that COLIN is providing):

Now, contrast that screenshot, where the incorrect filing type was passed to the legacy system, with this one. For the alteration filing on BC1234376, the correct filing type was used to sync data back to legacy infrastructure. Not only is the same of the filing now correct for its purpose, but COLIN also is displaying no outputs, which I understand to be the correct and expected behaviour. The underlying idea there is that, when a limited company alters itself to become a benefit company, the system of record is BCROS and, therefore, the filing outputs only should be displayed in that system.

"

Take away from the above :

"When data is synced back to legacy applications, modern infrastructure needs to be very detail-oriented about the data that is being passed back. The secondary takeaway, though perhaps the more interesting one, is that the filing dates here are interesting. The filing that synced back incorrect data, in David’s example, came from just yesterday, May 17, 2024. However, the filing that provided the correct data came from just 6 months ago, December 5, 2023. Moreover, we have records of the correct data being synced back to the legacy systems as late as March 28, 2024 – just over 6 weeks ago.

This secondary takeaway leads to a very interesting question: what happened roughly 6 weeks ago? My understanding is that these alteration filings, for pushing back to legacy infrastructure, are Jupyter Notebooks, which I understand to be scripts that developers run. Am I correct there? If yes, how do developers implement these Jupyter Notebooks? Do they work from one standard script? Or do they each have their own scripts?"

Mihai-QuickSilverDev commented 3 months ago

@OlgaPotiagalova @MKagis Hi Olga, Michael,

[ ] There is one Alteration Jupyter Notebook template used by all Ops Developers.
[ ] Once the Alteration Jupyter Notebook is executed, the Ops Developer will wait for the BCROS to COLIN API Synch to take place.
[ ] As per executive decision made about one year ago by Linda, the Alteration is going to be the last filing in the ledger of the source system.
For example, for a BC LTD ---> BEN alteration, COLIN record will end with the alteration and the BCROS record will start with the alteration. And viceversa.
Previous ledger transactions would not be carried over from one system to another.

severinbeauvais commented 3 months ago

Mihai, won't the COLIN data be imported into BCROS around MVP? How do you see the COLIN-only ledger items syncing with the BCROS-only ledger items?

severinbeauvais commented 3 months ago

Is there a simple list of things that need to be implemented in this ticket?

severinbeauvais commented 3 months ago

Note: per Vysakh, we do not currently sync ULC and CCC to COLIN, so that is either a pre-requisite or else we can only handle BEN and BC atm.

rarmitag commented 3 months ago

@severinbeauvais - no simple list, but this ticket was originally just for Alteration of Ltd to Ben. which involves changing the filing type code from NOALA to NOALE.

severinbeauvais commented 3 months ago

Thanks, Richard. It's just that I see a lot of checkbox todo items above, and side conversations.

If we limit the scope of this ticket to what you said then we are ready to estimate and implement this ticket. cc @NaveenHebbale

rarmitag commented 3 months ago

I would limit the scope for this, just to sure that you're not changing too much. This sync job is really important and can't break. So please change it with caution.

OlgaPotiagalova commented 3 months ago

Agreed. Let's limit the scope of this ticket to just fixing the codes used in syncing alterations

[ ] Use "NOALE" instead of "NOALA" for Alteration filings between BC and Benefit company
[ ] Names Team to verify synchronization works as expected.
[ ] Names Team to fix any old alteration issues (relevant to the scope of this problem)

Additional tickets will have to be created - TBD