UI Design - MHR Manufacturers Qualified Supplier Application + Staff Review

[tlebedovich]

Visual Design Comps - MHR Qualified Supplier – Manufacturer Application:

https://www.figma.com/file/0sD17BVTK7OwTqPRsAoreu/MHR-Account-User-Flow?type=design&node-id=1006-3462&mode=design

Visual Design Comps - Staff Review/Approve Flow – Manufacturer Access:

https://www.figma.com/file/0sD17BVTK7OwTqPRsAoreu/MHR-Account-User-Flow?type=design&node-id=1037-17071&mode=design

• includes Existing Account adding MHR QS product
• includes setting up brand new BC Reg account with MHR QS product
• Views of Account Products and Services tile when QS access is pending review, approved and rejected
• Views of MHR Dashabord message when QS access is pending review and rejects
• saving data to manufacturer's table (DB2 and new DB)
• staff review/approve flow

[tlebedovich]

@mstanton1 - can you schedule a call with sharon to review submitting party needs for manufacturers and confirm needs for dealers and lawyers.

[mstanton1]

Discussed in today's Requirements gathering session. The decision made was to use the same approach for submitting party as we do elsewhere and pull from the logged on user. From a glance, it looks like Entities actually calls it 'Completing Party' and the data pulled from the account is first name, last name and address. That design doesn't actually include any contact information (email or phone). When a user is creating an account (administrator) they have the option to enter email and phone number which would be helpful. When adding team members (anyone other than the account creator) we collect email address. It seems like the modal used should pull the email address from the logged on user. @tlebedovich let me know if you need any other information to move this forward. Thanks!

Adding Completing Party

Administrator Info

Adding a team member

[tlebedovich]

@mstanton1 I was under the impression that we would be using the same Submitting Party read-only component we are currently using in MHR for QS Transfers. MHR/PPR are slightly different than business registries since they have both a submitting party and an authorization component.

---

MHR Submitting Party (Currently used in QS Transfers):

Name - Account Level Name (not individual user/team member) Mailing Address - Account Level Address Email - Account Level admin/contact email Phone - Account Level admin/contact phone

MHR Authorization (Currently used in Manufacturers Registration and QS Transfers):

Name - Individual user/team member Account Name - Account Level Name Address - Account Level Address Email - Individual user/team member email

[mstanton1]

@tlebedovich thanks for raising that. Yes, it makes much more sense to use what we've already used. Can we chat about this in the requirements meeting tomorrow? I had a few questions.

1. For the requirements above, I wonder if we should also list the individual user / team member in the MHR submitting party?
2. For the submitting party should a user be able to edit the information, or would they be presented with text to update the account details? Valuable to be consistent with other BCROS submitting party fields

[tlebedovich]

Decisions made Aug 16, 2023 after discussion with Melissa and Doug:

• set UI max characters for Legal Business Name (Required) and DBA Name (Optional) to allow for selection from the Business look ups and for future proofing
• If a DBA name is entered, both the legal name + the DBA name will get saved to the MHDEALER and MANUNAME fields in the Manfacturers Table with a space-backslash-space between them
• If a DBA isn't entered, the legal name will be saved to all three fields in the manufacturers table - OWNRNAME, MHDEALER, MANUNAME
• Longer name may get cut off in the legacy system but chances are low and names can be manually-edited as new manufacturers sign up with the new system

Mailing Address (aka Owner Address)

• Suggestion to keep field max characters as they are currently used for Owner Mailing Address

• Delivery instructions and Phone Extension will not be saved?

Whatever the UI is doing now for owner address lengths should be fine as far as saving to the legacy database as it is already in PROD. The legacy address parsing is minimizing data loss, starting with street, street additional, and city each 40 characters long. Country and region codes are 2 characters each. There are no delivery instructions stored in the ppr database - this field is not in the address definition. Legacy phone number is 10 characters all digits, there is no phone extension, and owner postal code length is 10.

Questions: To confirm my understanding... 1. even though the UI says Max 50 characters for Address Line 1 and 2 , when it gets saved to Legacy DB, it will remove the last 10 characters of each if the max was entered and keep the full 50 for the new DB, correct? 2. Delivery instructions that get entered aren't currently being saved anywhere in the new DB for any of MHR or PPR apps?

Answer: For question 1: no the data is saved but the format may look odd in the legacy system. For owners, up to 154 characters excluding the region and country codes will be saved. 2. Correct, no delivery instructions are being saved for any MHR/PPR addresses.

[tlebedovich]

@mstanton1 @LizGovier - could it be possible that manufacturer's qualified supplier and staff flows are now ready for pregrooming? yes!

[mstanton1]

Amazing! Thank you @tlebedovich