Verify doctype mapping in 10-10d supporting doc metadata

[baltes]

Currently supporting docs included with 10-10d submits don't carry a consistent document type from dropdown selection to the PEGA interface. For example:

• A document uploaded as a marriage license shows in PEGA as "Medicare"
• A document uploaded as back of medicare card shows in PEGA as "OHI Certificate"
• A document uploaded as back of other health insurance card shows in PEGA as "OHI Certificate"
• A document uploaded as front of other health insurance card shows in PEGA as "OHI Certificate"
• A document uploaded as a birth certificate shows in PEGA as "Marriage Document"
• A document uploaded as a social security card shows as "Miscellaneous Documents"
• A document uploaded as a 10-7959c shows in PEGA as "School Certificate"
• A document uploaded as adoption paper shows in PEGA as "Miscellaneous Documents"
• A document uploaded as a school certificate shows in PEGA as "Miscellaneous Documents"

This one appears correct

• A document uploaded as front of medicare card shows in PEGA as "Medicare"

This ticket isn't intended to fix any mapping downstream, but we need to confirm that we're sending the correct doctype.

Screenshots for reference

[michaelclement]

Reached out to Cindy to try and better understand the problem. For documentation's sake, when I submit a form with attachments locally this is what the attachments array looks like:

[ 
  "vha_10_10d",
  "School enrollment certification form",
  "Enrollment letter",
  "Front of Medicare Parts A or B card",
  "Back of Medicare Parts A or B card",
  "Front of Medicare Part D card",
  "Back of Medicare Part D card",
  "Front of health insurance card(s)",
  "Back of health insurance card(s)",
  "VA form 10-7959c",
  "Birth certificate",
  "Social Security card"
]

These labels line up with what I had previously sent to Cindy, so it's unclear if there's an error in the Pega logic that reads the categorization or if our metadata is getting malformed somehow (which seems unlikely).

I'll update here as things progress.

[michaelclement]

Talked with Cindy further, we're not seeing consistent failures on this (i.e., we were able to submit multiple 10-10D's on staging and have the attachments be properly categorized in UAT).

@cloudmagic80 will be submitting a followup 10-10d that should match exactly the one that Bo submitted when this error was first noticed, and we'll see what that looks like.

[cloudmagic80]

When a document is attached, the website uses the PersistentAttachments method to record it in the backend. The attachments are handled synchronously, and their order cannot be altered.

The issue with inconsistent document types arises when uploading optional documents, specifically Social Security and birth certificates. These optional documents are uploaded before the required ones, but their document types are appended to the end of the array.

This becomes even more complex when multiple applicants upload Social Security cards, birth certificates, and other required documents, leading to additional inconsistencies.