Vishal Bajad - I am trying to understand and rephrase your description above, because as it is, it is a little confusing. Please let us know if the following is correct. We should always have the style "when this step is taken, this happens, but this should have happened" so that it is understood clearly.

Scenario I - Plan has setting dependent enrolled separately = YES

• Election data is imported - where there is enrollment of E + Spouse + Child.
• For this enrollment - spouse and child records are kicked out for some reason (to bad file) and employee record gets imported as E Only.
• Bad file is corrected and imported.
• Result is: the original Employee record is overwritten - but still remains as E only, and new Spouse + Child (dependent enrolled separately) get created.

Scenario II - Plan has setting dependent enrolled separately = NO

• Election data is imported - where there is enrollment of E + Spouse + Child.
• For this enrollment - spouse and child records are kicked out for some reason (to bad file) and employee record gets imported as E Only.
• Bad file is corrected and imported.
• Result is: the original Employee record is overwritten - but still remains as E only, and new Spouse + Child (dependent enrolled separately) get kicked out again (as dependent can't be enrolled separately).

CORRECTION NEEDED: The correct behavior would be to kick out THE WHOLE ENROLLMENT to the bad file in the first place. It should be whole or nothing. Record should never get added in a piecemeal way.

CC Satya Jaideep Vinchurkar Vijay Siddha Cindy Wibbing Amit Thorve Suraj Sokasane

Nagini Indugula, Yamilka Coca and Jennifer Johnson - shouldn't the system honor what comes in the import file in total? If it can't, it should reject the whole thing, and not just admit a part of it that was never intended by the user.

Abhay Patil, Nagini Indugula, Yamilka Coca, Jennifer Johnson, Jaideep Vinchurkar, Vishal Bajad
This is an issue and it was reported and addressed long time back (a year back). I am trying to find a ticket for the same. But it was fixed and deployed on production as well. If this issue is recurring then development team needs to check what happened to earlier fix?

Hi Abhay Patil and Amit Thorve,

Scenario mentioned by Abhay are correct. This is what we are trying to achieve with this ticket.
Amit is referring to WT-6041 which is fixed and deployed on production. It is cause for WT-10853. Please consider below details,

Current system behavior:
1. Import checks validates data from file. Invalid data get kicked out.
2. From valid data, import searches if this enrollment from file is already present in system. Search criteria is employee SSN, plan design id, effective date.
3. If enrollment found, import terminates the current enrollment and adds new enrollment.
4. Once new enrollment created, import processes covered members data. And add coverage data in system.
5. After coverage import processes cost (rates) and health tier policy and contingency.

Since, import is processing data table by table, we have restrictions on kicking out coverage. Hence, to change current behavior of system, we have opened this ticket as an enhancement.
Now we have two tickets with us needing same code change, WT-10853 and WT-9056. For better maintainability, I am closing this ticket and Merging scope of this ticket with WT-10853.

Merging scope of this ticket with WT-10853