Open denisecoveyduc opened 2 weeks ago
Here is the GMT data we pulled from the form
{
"gmt_data" => {
"is_eligible_for_streamlined" => true,
"pension_threshold" => 16037,
"national_threshold" => 39849,
"gmt_threshold" => 43050,
"income_upper_threshold" => 64575,
"asset_threshold" => 2798.25,
"discretionary_income_threshold" => 538.125,
"error" => nil,
"income_below_gmt" => true,
"income_below_one_fifty_gmt" => true,
"liquid_assets_below_gmt" => true },
"social_security" => { "spouse" => {} },
"employment_history" => { "spouse" => {} },
"agreed" => true
}
FE is returning shortform approved but from our calculations they MIGHT approve for longform, likely not.
We think this is a FE ticket, will provide data as needed.
Pinged in the dev chat about this ticket. I think we'll have a plan to sort this out tomorrow.
Maybe we can set up a test with the data you pulled?
Should one of these values have been false?
"income_below_gmt" => true,
"income_below_one_fifty_gmt" => true,
"liquid_assets_below_gmt" => true
I am going to pivot to the debts controller alert we are getting and prepare for a meeting with regards to that. I'll cirle back here.
Sounds good - I emailed Aleena Mirza & Varun Uppa (both with Huron) that we are looking into it and I will await any further updates from you :) Thanks!!
FYI @denisecoveyduc
@digitaldrk - any udpates on this?
No updates at the moment.
Kevin and I paired and we had a hunch that this was a FE issue as mentioned above. One evening this week, I took the form data we saved from this ticket and ran it through our backend FSR transform code to see what it determined. I ended up finding bugs in our BE FSR transform code and worked on that:
Between that and the debts controller, haven't gotten back to this.
I plan to hop on this tonight/tomorrow
I emailed Aleena and Varun to let them know that we are still working on this.
I formally wrote up a document and shard it with the team (mentioning FE particularly). The document outlines financial values the veteran has, the shortform criteria in the FE code has, and how there are discrepancies.
I think this is a frontend issue I will be available to pair and get any data needed to help run this down.
This is either a misunderstanding or a FE issue. The streamlined decision happens in the FE and it sends the following data to the BE:
'streamlined' => { 'value' => true, 'type' => 'short' }
We read the 'value' which is 'true' in this case and add the 'Automatically Approved, Waiver' to the payload we send off.
Who can I talk to about this to determine what business logic they are using to determine this should not receive 'Automatically Approved, Waiver' Aleena and Varun?
Update: Derek has been troubleshooting this issue. I have added @digitaldrk and @maxx1128 to email thread with Varun & Aleena so we can determine next steps needed. We may need to coordinate a quick meeting with them to discuss. This ticket will roll over to S129.
Issue Description
VHA has reported a potential miscalculation on a streamlined waiver submission, this ticket is to investigate and determine if there are any changes needed.
Background Details
c6c65a4fa0ba4340af8bedb9fd77b631
6/15/2024
Tasks
Acceptance Criteria
[ ] We have a clear understanding of why the discrepancy occurred and have defined next steps as needed.
How to configure this issue
product support
,analytics-insights
,operations
,service-design
,Console-Services
,tools-fe
)backend
,frontend
,devops
,design
,research
,product
,ia
,qa
,analytics
,contact center
,research
,accessibility
,content
)bug
,request
,discovery
,documentation
, etc.)