Collateral

[Bryce13Reid]

User Story

As a registering party I want to describe all the collateral so that the registration secures my interest

Acceptance Criteria

• Enter a description of the general collateral not already specified as serial numbered collateral
• A valid financing statement must contain 1 entry for serial or general collateral
• Users may specify as much general collateral as they like and up to 999 of serial number collateral
• The front end will need to ensure input is blocked at 8000 characters

User Experience

• Wireframe exists
• Awareness needs to be provided to the user in case of copy-paste that exceeds 8000 characters. Block form submission until input under the limit

Business Rules

Kevin recommended the character limit as a way to help users be more concise in their collateral description. For example, if they are listing all the items of an estate down to each pair of socks, they may not understand what's needed. But, we also don't want to be prescriptive.

Constraints

• The content of the textbox will be passed to the API and it will handle splitting the string for Oracle.
• Legacy (multi-lined collateral) data will be merged into the new data structure

Reviews

• [x] Barb
• [x] Bob
• [ ] Business Stakeholders reviewed the wireframes
• [ ] Sandra

[bryan-gilbert]

UI work will build on the work from the previous sprint and (1) add the 8000 limit with UI feedback. Note that this component will not appear on the FS until until #649 is complete

[LivMac-Git]

Just to help provide clarity.

When a user first arrives to the Collateral section these are the two buttons they are shown.

They are required to have one entry of serial collateral or one general collateral text area, to create a valid registration.

After clicking "add general collateral" once the button to add General Collateral is removed unless they remove the GC field entirely. (Then the button returns allowing them to add the GC text field again)

But there is only ever ONE General collateral text area with the 8k character limit.

As GC is entered when there are 1000 characters remaining a validation message will dynamically show the remaining character limit. If users paste or enter more characters than the limit, the "Confirm & Submit" will be blocked, and a negative character limit will be shown until they reduce the entered text to 8k characters, or remove the GC text area.

[KevinB-gbc]

To clarify my expectations:

1. There will be a General Collateral text entry PER REGISTRATION, i.e. I can add one block of text when I enter a new registration, a second block when I amend it, a third block when I amend again...
2. The specification of General Collateral text being "one block of text" is not a strict rule to me. It definitely should NOT be a collection of 70-character lines, but is one 8k box better than 4 2k boxes?....I don't know. It depends upon how you are using them, facilitating editing, etc. Most jurisdictions today simply provide one big box, but if you have a better idea, go for it.
3. ...But if you are going to go with multiple General Collateral data fields (e.g. four 2k fields instead of one 8k field), then you need to be able to have fixed processes for the following: (a) associating all fields with one and only one registration (i.e. base or amendment); and, (b) GUARANTEEING that they will always be presented together and in a fixed and unchanging order. That is, unlike serial numbered collateral, the order would matter.
4. The question of conversion should be as I understand Bob is describing: all GC 70-character lines PER REGISTRATION will be written to a designated column able to support the max field size of 8k. One row per registration where General Collateral was added.
5. If there are existing registrations with more 70-character GC lines than will fit within a single 8k box, then we will need to get a little creative. We either (a) design-for/permit GC text larger than 8k for pre-transition registrations but not post-transition (likely easier for conversion but harder for other solution elements and long-term maintenance a pain), or (b) during conversion, split the 70-character GC lines during over multiple 8k fields.
6. If doing 5.b above, there are again two options: (a) permit multiple GC rows ONLY for pre-transition converted registrations (i.e. a converted registration may have one OR MORE 8k blocks), or (b) add "virtual amendments" during the data conversion process in order to store the extra large pre-transition GC entries (essentially we create extra "registrations" which are defined as having been created by the Registrar for purposes of transition of the registry). Option 6.b is a weird step, but it is within the Registrar's authority and can be effectively communicated. You might be surprised at the weird stuff we get into in order to convert a 30-year old database to a new home!
7. One of the reasons that option 6.b -- splitting a GC entry into multiple registrations -- is not difficult to communicate is because it mirrors what registrants do today, namely: If you give me an 8k GC field and I have 20k of GC text that I want to enter, then I will create a new registration with ~8k GC, amend that registration to add ~8k more GC text, amend that registration again to add ~4k GC text. Such massive GC text entries are rare, but do occur. They occur more frequently, of course in registries with relatively small GC fields such as 0.5 to 2k.

[LivMac-Git]

Re: Bryan's ask for the initial state wireframe for a FS when first opened please see the attached wireframe.

This would be the view a user see's when they first go to start a new registration before they have selected anything (assuming we opt for a security agreement to be selected by default)

[jguertin]

Summary of proposed solution

The basic principal is that once general collateral is submitted (wether on a new registration or amendment) it cannot be modified. Rather, changes to general collateral will be considered additive. To this point, a user can only submit one general collateral at a time (up to 8000 characters). So when updating a financing-statement, there may be multiple read-only general collateral existing on the statement, but the user may only add a single new value.

On historical data, the approach was different, where users could submit multiple line, and on occasion could remove lines. This data will need to be appropriately migrated.

Here's a technical overview of the approach: API Interface:

• The API specification for POSTs will remain as it is today (generalCollateral is a list of objects, each with a description property)
  • When submitting, generalCollateral can not contain more than 1 item in the list
  • description cannot exceed 8000 characters and cannot be empty or null
• The GET for a financing-statement will include a timestamp on the general collateral
• When amendments or changes are implemented, they should allow only the addition of 0 or 1 general collateral

API Internals:

• Input validation should enforce the limits as described above
• The database structure for the table that holds general collateral will remain as it is today, holding a description, base registration number, starting registration number and ending registration number
• When we move to Oracle there is a 4000 character limit on Varchar2. We will handle this limitation by splitting input into multiple rows as necessary.
  • On reads, rows with the same starting registration number will be concatenated

IMS Data Migration:

• Historical data may have multiple rows for each registration, each with a 70 character limit.
• Each line from the existing system will be migrated to a row in the general collateral table
  • This will allow it to be concatenated by the API in the new system and appear as a single general collateral from its perspective
  • To maintain display consistency, a line break will be appended to each row when it is migrated

[rstens]

So no long for the description? It's 2GB max, you can still enforce the 8000 chars limit. Saves you from having to split up the submitted string. "Gentlemen, we have the technology!" Bonus points for naming where this quote came from.

[jguertin]

So no long for the description? It's 2GB max, you can still enforce the 8000 chars limit. Saves you from having to split up the submitted string. "Gentlemen, we have the technology!" Bonus points for naming where this quote came from.

Certainly a good option, as long as the frame work supports it in a database agnostic way. Overall, the solution remains the same, it would just avoid us having to spit incoming data.

[bryan-gilbert]

Looks good. What is the API structure when there is a timestamp?