Define the other Reg Type form field requirements

[Bryce13Reid]

These are the requirements on a case by case basis for all the types of registrations that are not security agreements.

MISCELLANEOUS REGISTRATIONS ACT

1. A selector that allows the user to select the appropriate Act for the Crown Charge:

Crown Charge Filed Pursuant to the Following Act: Social Service Tax
Forest
Hotel Room Tax Insurance Premium Tax
Logging Tax
Mining Tax Mineral Resource Tax
Carbon Tax
Income Tax Petroleum and Natural Gas
Rural Property Tax
Motor Fuel Tax Corporation Capital Tax Provincial Sales Tax
Excise Tax Consumption Tax and Transition Act

2. A single line freeform text field where the user can enter information if the registration is made for an "Other" reason.

AMENDMENT / OTHER CHANGE

1. A freeform text field spanning multiple lines called "Details Description", example entry:

   GENERAL COLLATERAL SHOULD READ: EFFECTIVE JANUARY 17, 2014: FURTHER INFORMATION RELATING TO NAME OR ADDRESS: JOHN SMITH: THE COMPLETE NAME OF THE DEBTOR SHOULD READ JOHN WILLIAM JOSEPH RANDOLPH SMITH INSTEAD OF: EFFECTIVE JANUARY 17, 2014: FURTHER INFORMATION RELATING TO NAME OR ADDRESS: JOHN SMITH: THE COMPLETE NAME OF THE DEBTOR SHOULD READ

2. A selector that allows the user to indicate the change type: AC - Addition of Collateral DR - Debtor Release DT - Debtor Transfer PD - Partial Discharge ST - Secured Party Transfer SU - Substitution of Collateral

RENEWAL

No additional fields identified at this point

TOTAL DISCHARGE

No additional fields identified at this point

[LivMac-Git]

Idea from Colin

Idea for exploration: figure out some way to bake the regulations for collateral description into the UX, if you look at the comments of this ticket, you will see the list of rules for the collateral description part. For example, "If the registration does not relate to a security interest in personal property. the words "uncrystallized floating charge on land" must be entered." - can we encompass this as a toggle, and in fact, all of these regulations into kind of a checklist that the user manipulates, and then the collateral input field is pre-composed with the correct legal words in the correct order?

Should we have a "guided mode" and an "expert mode" where they can copy-paste stuff?

[KevinB-gbc]

RE: "(1) a Serial number must be AT LEAST six characters" -- I am not aware of a requirement for the serial number to be a minimum of six characters. Where is this from? Does the PPR have this minimum today? Is it a misunderstanding of the searchable portion of the serial number being the last six or eight characters?

If I understand correctly from the text "All Other Collateral" down you are considering adding an interactive editing, widget, or guidance facility for the drafting of a General Description of Collateral. If I am understanding this correctly, I would consider this entire initiative, both above and below the line beginning "Other - freeform text?, highly problematic. I advise against it, but I don't know that I am even able to think of all the reasons I would oppose this on short notice You are undertaking to "assist" a secured party in drafting a general collateral description consistent with their legal requirements? My problems with this:

1. This is not aligned to the needs of your user base. Who do you think needs this?
2. Potential legal liability for ineffective general collateral description, or -- at a minimum -- implication of rules that do not exist, e.g. that there is such a thing as a "correct order" for entry of general collateral terms.
3. Providing a few words -- e.g. "goods", "chattel paper", "inventory", "proceeds", etc. does little good for the secured party. They still have to fill in all of the other words that they need in order to complete the description.
4. Providing some words could suggest to unsophisticated registrants that getting general collateral description is not difficult and may be undertaken without the participation of a lawyer or legal advice -- "The system is here to help. Just click the boxes." Do you think that an unsophisticated user will understand what is missing after they have checked some boxes?
5. Suggestion that values like "goods" and "inventory" are items that are valuable under Canadian PPSA to be explicitly trackable and searchable items -- e.g. check-box items. They are not. In fact, explicitly tracking of such values outside of the context of the rest of general collateral text is more likely to be deemed problematic than helpful.
6. This entire endeavor is likely a waste of time unless you have some explict indication from the registry AND legislative authorities would find it to be acceptable, e.g. an "approval in principal" from both the Registrar and Dept of Finance to undertake the trouble and RISK of doing this.

The one set of text that IS appropriate for a system to help support a Registrant to enter or make available (e.g. by default) when appropriate (e.g. by registration type) is item (ii) in the list -- all present and after-acquired personal property. Item (iii) is NOT okay because the registrant must define the terms of exception themselves, without guidance from the registry.

Other comment: I hope that you are not trying to apply something you have seen in the Australia or New Zealand PPSA/PPRs here -- they have different models with regard to describing collateral than is used in Canada.

[colinanderson-cgi]

We will not be proceeding with the avenue of offering a semi-assisted registration.

[KevinB-gbc]

I am pleased to see within this ticket description of: 'A freeform text field spanning multiple lines called "Details Description",...'

I have long been puzzled by where the BC PPR stores a lot of the information that registrants are either explicitly instructed to record within the registry or which they feel needs to be recorded in addition to regulatory instructions. In some cases, information to be "entered" by the registrant actually appeared to be recorded via an amendment type code, but such type codes are insufficient to address all possibilities. I was concerned that some registrants may be adding required or optional information in an inappropriate location, such as the General Collateral text field.

I therefore welcome a "Details Description" field. In many other jurisdictions in Canada this is referred to as an "Additional Information" field. This will support evolution from "intention-based" amendments to "functionally-based" amendments if BC chooses to adopt such a direction now (before transition) or later.

Please comment: What similarly-purposed data fields, if any, exist in the registry application today? For example, is this a "re-purposing" of one or more other, more-specialized data fields?"

[colinanderson-cgi]

This was derived by looking at the existing legacy printout registrations. There is no field implemented right now and I suspect that the statements shown above were classically entered into the system through the abuse of an existing field - Barb told us for some use cases the users abuse the fields.