Register a Security Agreement

[sandrajoandaniel]

Story: As a basic external user registering party I want to Submit/register my security agreememt financing statement to the PPR Registry when I’m ready so that I can have the financing statement officially recognized.

Acceptance Criteria: Verify

• Can be searched - TEST
• Has a base registration number - WHEN SUBMITTED
• One or more Debtors must be specified - with name, address and corporation only, where corporation name is open field and optional birthday. - ADDRESS NEEDS TO BE IMPLEMENTED, AND A SCROLL-ABLE LIST, AND BIRTHDAY
• One or more secured parties - with name, address and corporation name, where corporation name is open field - VALIDATION (BACKEND),
• Users must be in active authentication session (cannot register anonymously) - DONE
• Registering party will be as is today. - review this in future stories. - NO OP
• When you click the Submit button in the Verify/Register screen to register a document, the PPR system assigns a base registration number, date, and time of registration to the document and calculates the document's expiry date. - SUBMISSION IS INCOMPLETE
• Security agreement should have at least 1 associated collateral of either vehicle or general type (free form text). - BACKEND VALIDATION
• User needs to receive some form of validation before registering a security agreement (such as, but not limited to, star next to required fields, confirmation text) - FORM VALIDATION IS DONE

Out of scope

• Payment type is credit card and paid at time of transaction.
• Party code instead of secured will be used as form of entering registration information in new system
• You are charged the registration fee at this point. The document is registered as of the date you click the Submit button, and it can be searched in the database.
• If payment system is down, the submission cannot be completed.
• If user does not populate registering party content, pull the account information from account information.
• The user has to pay before the submission is completed
• Bulk addition of VC (aka serial collateral) fieldsets.
• Scrollable lists of items in non-edit/display mode

Questions to clarify:

• [x] @sandra determine payment options w/ relationships team for basic users. Assuming it is credit card and paid at time of transaction.
• [x] @sandrajoandaniel confirm for expiry date, number of years is calculated for life from today's date.
• [x] @sandrajoandaniel date is captured pacific time
• [x] @sandrajoandaniel confirm weekends and holidays should not be included in expiry date.
• [x] @sandrajoandaniel confirm we can assume that the registering party is a logged in user
• [x] @sandrajoandaniel confirm with relationships team that we can pull account info to populate registering party field (auth system - do we need to persist the registering users address or can we rely on other systems to update this info)
• [x] @sandrajoandaniel confirm that party code will be carried over in new system
• [x] @sandrajoandaniel clarify if there are limitations in terms of length of description in regulation for general collateral (currently 70 character line and users don't like)
• [x] @sandrajoandaniel clarify fields in vehicle collateral (make and model or integrated into 1 field, split out fields)
• [x] @sandrajoandaniel determine what is required in name of debtor. Do we need to split business name versus individual name.
• [x] @sandrajoandaniel Do we share birthday in debtor field. (privacy question - by sharing birthday and name we create privacy issue through search).
• [ ] @sandrajoandaniel confirm if we want to offer 'infinity" security agreements. - regulation. (Loren/Bob/Thor).
• [ ] @sandrajoandaniel do we allow bulk upload of collateral and what does that look like?
• [ ] @LivMac-Git Does it make sense to support Bulk import of Fields from csv/excel? Do users desire to do this?

[bryan-gilbert]

Text from issue #162. Will close that issue.

As a registering party I need to be able to:

o Register a financing statement so that I can record my interest in a piece of collateral

Create a draft financing statement so that I can compose a financing statement without having to submit it all at once

Edit a draft financing statement so that I can change a draft financing statement without having to submit or delete it

Delete a draft financing statement so that I can remove draft financing statement without having to submit it

Optionally associate the financing statement with one of my clients [folio tag] so that I can determine which client to bill

Optionally verify a financing statement before registering so that I can confirm that I have correctly entered the financing statement's information

Submit [register] a draft financing statement to the PPR Registry so that I can have the financing statement officially recognized

See a confirmation of financing statement registration success so that I can be assured that the registration was successful

See a printer-friendly confirmation of a financing statement of registration success so that I can easily print the confirmation

Receive a summary of my change [verification statement] in my BC Online mailbox so that I can reference the details of my registration at a later time

[colinanderson-cgi]

@sandrajoandaniel determine payment options w/ relationships team for basic users. Assuming it is credit card and paid at time of transaction.

This assumption is correct, ref: https://preview.uxpin.com/6960b05b78d46bf96ce257272989faee5bd343ae#/pages/121089949/simulate/sitemap and was confirmed with Loren

@sandrajoandaniel confirm for expiry date, number of years is calculated for life from today's date.

Division 4, Section 55 of the regulations only state that years to expiration are calculated as 1 calendar year from registration date + 1 day.

@sandrajoandaniel date is captured pacific time

****The Repairer's Lein act says: (3)Registration of a financing statement is effective from the time assigned to it in the office of the registry.

The "office of the registry" in this case is a server in BC, so it should be in PST, not relative to the user's timezone.**

http://www.bclaws.ca/EPLibraries/bclaws_new/document/ID/freeside/00_96404_01#section3**

@sandrajoandaniel confirm weekends and holidays should not be included in expiry date.

The expiry date should be an absolute date in the future that is irrespective of whether there are weekends or holidays in between. There is no mention of weekends or holidays in the regulations or the legislation

@sandrajoandaniel confirm we can assume that the registering party is a logged in user

The logged in user is the account owner in the organization. This can be different than the registering party, see point below

In addition, the logged in user info is passed in the form of the JWT token from the auth platform so this is easy to determine using code. DO NOT assume the user is logged in, but check in code.

@sandrajoandaniel confirm with relationships team that we can pull account info to populate registering party field (auth system - do we need to persist the registering users address or can we rely on other systems to update this info)

Take address from Account Info and name from User Profile and make these fields overtypable in the form, discussed with Justin and Loren

@sandrajoandaniel confirm that party code will be carried over in new system

This is required system functionality from Barb's perspective so the answer to this is Yes.

@sandrajoandaniel clarify if there are limitations in terms of length of description in regulation for general collateral (currently 70 character line and users don't like)

** Section 44, Table 4 of Regulations give characteristic of the field formats for the various inputs of PPR. Specifically, Table 4 dictates the width of the various fields for the SCREEN and PRINT functions. Performing analysis of the regulations, it becomes immediately apparent that:

1. Table 4 exists to ensure that the SCREEN output of the system is formatted correctly. This is desirable behaviour in a VT-200 terminal scenario but DOES NOT appear to be in-scope for the completed web portal, as the implementation will be a web page, not a VT-220 screen.

2. Table 4 exists to ensure that the PRINT output of the system is formatted correctly. The print output is formatted as a proportional font with a 80 character maximum line length. This behaviour and output of the system, and the restrictions of output dictated by the regulations, is IN-SCOPE for the project for the following reasons:

   a) There is a requirement for print output of the system b) The print output of the system is a recognized legal document by users of the Registries system c) The print output of the system is copied-and-pasted into other legal documents.

However, the print output of the system should be CONSTRAINED by the existing regulations to conform to regulation for the following reasons:

a) The output of the system is predictable and expected by the users of the system. Changing this predictable output in the manner of modifying the system output will lead to enduser confusion and may cause scenarios where the validity of the document itself is called into question.
b) Modifying the system output to express data in a different (and one would interpret, more modern) fashion would impede with the existing copy-and-paste workflow regime that the users of the system undertake, specifically:

    1. If one considers the use case of applying formatting to the system output, if a certain output element was formatted in a specific font, a specific font weight, and a specific font size, modern operating systems will take that style operation in a cut-and-paste operation and apply it to the paste target. A user will have to take extra steps in order to retain formatting in the target document.
    2. Copying and pasting is facilitated by the use of the existing system's output TAB STOPS. The output data is delimited using tab stops. Opening the output on a modern PC and using that to cut and paste facilitates copying and pasting because modern operating systems automatically extend the selection range to the next tab stop or delimiter, making cut and paste operations faster.

3. The regulation for SCREEN and PRINT field requirements do not conflict with modern database requirements; for example, the regulations state that a date field must be EXPRESSED in a specific format but they do not state how a date can be STORED AND INTERNALLY PROCESSED. In this fashion, one can align the legacy system requirements with "nice to have" asks, such as allowing a longer debtor name INTERNALLY and possibly TRUNCATING the output in order to conform to regulation.

The ask for how this particular piece of regulation is to be interpreted is something like: "Given that the SCREEN regulations were intended to work in the context of a VT-220 session, we are asking if we can not implement the regulations specifically for the SCREEN portion. The PRINT portion would be implemented as per existing regulation, and the print output of the system (future state) will be largely almost identical to the existing system state" **

@sandrajoandaniel clarify fields in vehicle collateral (make and model or integrated into 1 field, split out fields)

Make and model is a single freetext field ref User's Guide page 27, Regulations Schedule 4 Section 44. The user is responsible for typing in the information in a specific format. Do not recommend to change this behaviour. Recommend 255 characters. (Exemption required)

@sandrajoandaniel determine what is required in name of debtor. Do we need to split business name versus individual name.

We do, in fact all 4 need to be filled in in some edge cases. First Name, Middle Name, Last Name, Business Name. Ref user's manual P25, Regulations section 7 & 8

@sandrajoandaniel Do we share birthday in debtor field. (privacy question - by sharing birthday and name we create privacy issue through search).

PIPEDIA legislation states that if the birthdate is required in order to perform the function, then that is allowed by authorized users. Authorized user is, in this case, the general public. The rule of thumb here is, if a member of the public goes into a registry and pays for an extract, and that extract contains birth dates, then there is no problem with exposing the birth dates in the context of the online search because the user is authorized. We "make" the user an authorized user by the fact that 1. They are logged in and registered 2. They paid. Actually, it doesn't matter so much because there is a specific clause in the legislation that covers our use because it is a debt: Ref http://www.bclaws.ca/civix/document/id/complete/statreg/03063_01#section5 (15)(1)(j)