Hi Pallavi Kulkarni,

Please check.

CC-Mandar Kulkarni

Thanks,
Ganesh

Hi Alex Nguyen,

We have checked attached structure. We can add below benefit type and code for Enrollment Lincoln Financial Coverage Indicator.

Below benefit type are already added for Lincoln Financial. As we does not have implementation of company wise different code, so if we change existing code with new code. Then new codes will appear on all Lincoln feeds.

We have not added any new codes yet, please confirm above change then will add codes for Lincoln.

CC-Vinayak Kulkarni

Thanks
Ganesh

Hi Ganesh Sadawarte,

As long as the update doesn't impact other clients with Lincoln feeds, then I'm okay with this change. Few other clients such as LHP and Prime are using the same macro and 'Existing Code'. For Dakotaland, they use the 'New Code'. I'm not sure how this will work, unless you can clone the macro and modify it specifically for Dakotaland.

Thank you,

Alex

Hi Alex Nguyen,

Lincoln file Coverage Code fetch logic is based on benefit type name, which is configured in LinconFinancialGroup.xml

As mentioned by Ganesh Sadawarte Supplemental Employee Life,Supplemental Child Life and Supplemental Spouse Life Benefit Type Name is already configured with different coverage code.

We can get OLI,OSLI and OCLI code on file by changing benefit type name in system,can you please confirm is it possible to change Benefit Type Name in system as follow,

CC-Amit Thorve,Vinayak Kulkarni,Mandar Kulkarni

Hi Pallavi Kulkarni and Ganesh Sadawarte,

I'll need to refer your question to our Implementation team. I'm not sure what can happen if the benefit type name gets change and what impact it can have on current enrollments. Currently what we have in workterra production are Supplemental Employee Life, Supplemental Child Life, and Supplemental Spouse Life. According to your requirement, it needs to be change to optional life in order for the code to come out.

Veronica Blanco and Robyn Adkison - can you see comments from Development and look into this? I want to make sure this is okay before having development make the change in the system. We already have employees enrolled and if they make this change, will it have any impact or terminate the coverages?

Thanks,

Alex

Hi Alex Nguyen,

I'll review this with Robyn Adkison.

Can you update your question to include her? I'm not sure who was tagged in your comment by mistake.

Thanks,

Veronica Blanco

Sorry, I tagged the wrong Robyn. I have updated my previous message. Thanks for letting me know.

Alex

Hi Alex Nguyen,
I just want to make sure that I am understanding this correctly.
Specifically for the LFG files, the benefit type name is hard coded to produce VLI, VCLI, VSLI. If this is updated for Dakotaland, it would impact all LFG connections built for other clients. So the ask is to change our benefit type name in order to send the proper codes of OLI, OCLI, OSLI?

This can't be done in any other fashion through data mapping?
If this is the only way that we can make the file work for LFG files, then we can accommodate. It shouldn't impact members enrolled, however I don't know how it would impact (if any) DFCU's other connections. Would you be able to review their other connections and confirm that there would be no other impact to the connections?

thanks,
Robyn
Veronica Blanco, Jackie Sivigny

Hi Robyn Adkison,

That's correct the benefit type are hard coded on the back end on the xml file. The three supplemental listed are currently tie to VLI, VCLI, and VSLI. Prior to this ticket, I have already tried concatenate, data transform, leading value, and rule engine. The data were coming out incorrectly. Seems like the macro is the only option we have. I pulled up the latest feeds list from Mandar and went through each clients with the Lincoln feeds. The only other client that was using the Lincoln macro was LHP, but they already termed with us and all their feeds have been turned off. As for 2 other clients (PrimeHealth and El Dorado), they don't use the macro. They may be on an old spec that only requires the amount on the file. Dakotaland appears to be using a newer version.

I feel it should be safe now to just have Development move forward with the change, because there's no other clients using this macro. I think they will only make changes to the Lincoln xml file for the new code without touching the settings on the plans in WT, unless they need us to do anything. Let me know if we can move forward with this.

Thanks,

Alex

Hi Alex Nguyen,

Do you have any updates on this issue. Thanks!

---------------------------------------------------------------
CC: Mandar Kulkarni, Jaideep Vinchurkar, Satya, Prasad Patil

Hi Pallavi Kulkarni and Sumeet.Kolge,

Can you first check to make sure no other clients out there are using the Enrollment Lincoln Financial Coverage Indicator before you have it updated for Dakotaland FCU to use? Let us know once the Lincoln macro/indicator is updated, so I can run the file and review to make sure they are coming out correctly with the indicator.

Let me know if you need additional info from me. You mention from previous communication to change the benefit type in system. Our implementation confirmed it can be accommodated and shouldn't impact members enrollment. Our only concern is will it impact other connections under Dakotaland FCU. I don't think there's any other connections under client that can get impacted, since Lincoln file is the only file associate to the life plans.

Let us know if you need additional info.

Thank you,

Alex

Hi Prashant Samal,

Request you to please take this ahead. Thank you!

---------------------------------------------------------------------
CC: Mandar Kulkarni, Satya, Prasad Patil

Hi Alex Nguyen,

We have scanned all companys and found that Enrollment Lincoln Financial Coverage Indicator is mapped on following companies.

AS Per Pallavi Kulkarni 's previous comment We can get OLI, OSLI and OCLI code on file by changing benefit type name.

Could you please change benefittype name as below.

After this change OLI, OSLI and OCLI code will populate on file and there will no change required in XML file also that will not have any impact for other client.

Please let us know if you required more details on this.

CC-Ganesh Sadawarte, Vinayak Kulkarni

Hi Robyn Adkison,

Can you update the benefit type on the supplemental life plans? Development said the codes are already setup on the Lincoln macro. As long as the benefit type is correct in WT it should pass their codes on file. Please see Rakesh last comments.

Thank you,

Alex

Hi Alex Nguyen,
Thank you for your patience. We have updated the benefit type name for the following plans:
Supplemental EE Life => Optional Life
Supplemental Spouse Life => Optional Spouse Life
Supplemental Child Life => Optional Child Life
Supplemental EE Life Over 65 => Optional Life Over 65
Supplemental Spouse Life Over 65 => Optional Spouse Life Over 65

Please let me know if you have any questions
Thanks,
Robyn
CC Jennifer Mitchell, Monika Demla

Hi Robyn Adkison,

I will test them out later and will let you know if the macro is working properly. May need Development involve if the codes not coming out correctly after benefit type has been updated.

Thank you,

Alex

Hi Robyn Adkison,

You can go ahead and close out this ticket. We had a discussion with Amit and Vinayak regarding the existing Lincoln macro and found out it won't work with the Lincoln file I built due to the format being different than the Lincoln files they built for other clients. The Lincoln macro is passing the code/approved amount in the format I needed, but problem is it will pass all enrolled plans on 1 column with commas separating each. This will cause the data to appear out of order on my file.

I opened another ticket WT-12986. Their suggestion was to try selecting "Is Padding Required?" and "Do Not Apply Padding For Blank Value" under the sub template field settings that way if not enrolled in the plan, it will not pass the leading value on file. This took care of it. File is now scheduled to run weekly.

Thank you,

Alex

Thank you so much Alex Nguyenfor your help on this file.
CC: Jennifer Mitchell