Gross Monthly Income responses should overflow in PDF only if more than 4 entries

[vbellissimo]

Issue Description

VBMS Claim ID 105149251 (va.gov claim ID 8487132) has the Gross Monthly Income responses in the PDF overflow despite not exceeding the allotted space on the 527EZ.

Acceptance Criteria

• If the veteran enters 4 or fewer Gross Monthly Income entries, the responses should map to the question fields in the PDF. These map to: -- 9H(1) through 9H(4) -- 9I(1) through 9I(4) -- 9J(1) through 9J(4) -- 9K(1) through 9K(4)

• If the veteran enters 5 or more Gross Monthly Income entries, the responses should map to the PDF's overflow section.

[TaiWilkin]

@vbellissimo I think I've finally tracked down what triggered this situation. In general, we don't overflow to the income sources with only four entries. However, if one of the fields contained within the income sources (ie, any of 9H(1) through 9H(4)) is longer than its allowed limit, then the income sources are moved to the overflow page. For example, if there are only three income sources but the name of the payer is "John Bartleby Sampson Joseph Oliver Alexander Jonathon Doe", the income sources will be moved to the overflow page.

The specific limits are: 4 income sources, 29 characters in dependent name, 31 characters in type of income other, and 25 characters in income payer. VBMS should be able to confirm if one of the values in one of the income sources exceeds one of the limits.

In the form filler (which is shared code among multiple forms), it appears that this functionality was set up this way intentionally. Do we want to continue with this task? If so, we will probably want to re-frame this as a spike to figure out the level of effort required to create a custom implementation.

[vbellissimo]

Thank you @TaiWilkin for explaining this! Let me relay this information to the business and get their thoughts on this before we close this

[vbellissimo]

@TaiWilkin , Julie Strothman is suggesting to VBA we hold off on making this change a priority. With this in mind, I think it's safe to close this ticket. I created a future ticket for this work (#76820) when we're ready to prioritize. Thank you for investigating!