1) While enrolling will employee each time will be redirected to Texaslife web site , because it is possible the EE will enroll in one of Texas life plan and another for other plan not of TexasLife and again in paln of Texas life. => No, All enrolled plan information by EE, we will keep in memory in WT application and will post all request in one go.
2) What about EOI scenario? => They have their own EOI processing unit for which we have post the request only. After their process they will send response back . If we have to catch response. For response tentatively we need to wait for 2-5 or more minutes as it may take time. Mean while either we have to keep waiting the user or find any other way to display processed result to user without keeping them idle.
3) Do we need to implement all Enrollment Services Mentioned in document? => Its completely optional and depends on the need.
4) What kind of Implementation is preferable as it seems like XML-RPC and HTTP POST are alternate of Embedding the Texas Life Enrollment system or vice-versa. => The implementation can be done in either way. we will decide only after seeing and analysis of demo.
5) Will it be possible to share any implementation demo apart from Mentioned Demo in the document. Any screen-shot will also be helpful. => Yes they are agree to show us demo ,need to scheduled a call with them.
Aditya Vishwakarma (Inactive)
added a comment - Queries discussed on the call (25-May-2017):
1) While enrolling will employee each time will be redirected to Texaslife web site , because it is possible the EE will enroll in one of Texas life plan and another for other plan not of TexasLife and again in paln of Texas life.
=> No, All enrolled plan information by EE, we will keep in memory in WT application and will post all request in one go.
2) What about EOI scenario?
=> They have their own EOI processing unit for which we have post the request only. After their process they will send response back . If we have to catch response. For response tentatively we need to wait for 2-5 or more minutes as it may take time. Mean while either we have to keep waiting the user or find any other way to display processed result to user without keeping them idle.
3) Do we need to implement all Enrollment Services Mentioned in document?
=> Its completely optional and depends on the need.
4) What kind of Implementation is preferable as it seems like XML-RPC and HTTP POST are alternate of Embedding the Texas Life Enrollment system or vice-versa.
=> The implementation can be done in either way. we will decide only after seeing and analysis of demo.
5) Will it be possible to share any implementation demo apart from Mentioned Demo in the document. Any screen-shot will also be helpful.
=> Yes they are agree to show us demo ,need to scheduled a call with them.
.
1) The URL https://www.empben.com/WKTest/WebConnect/FrameDemo.py is common for all developer or we (Workterra ) will have separate URL to test or devlop our cases.
– It is a common example site. It is meant to show examples of how to connect and to test the xml structure if need be.
2) The XML format is changed now on above url. As per our another email thread clean up is needed.Can you please cleanup or share the steps to clear it by our self
Sharing steps with us will useful if, we messed it up we can reset it again that will save time for both of us.
– I can reset it back to the original
+
XML section queries based on XML structure we had seen at the time of demo+ 3) Can we have concrete structure of XML so that we can implement it as I see some of get completely changed.
– I can provide the DTD that the XML structure is configured from. The XML is dynamic based on the number of people being passed to Texas Life. It is attached to this email.
4) Currently we have three scenario – there should be 7.
-Employee
-Employee and Spouse
-Employee Spouse and Child
-Employee and Child
-Spouse and Child
-Spouse Only
-Child Only
What will be the case if Employee has Child but no spouse ( divorce , deceased etc)?
5) Beneficiary section of Employee: What will be the structure if Employee has multiple beneficiaries?
– the beneficiary section is a list of the beneficiaries. it is defined in the dtd. 6) What is LOCATION, CITY, STATE at the end of employee section as we can see these fields already in Address section?
– This is the physical location that the application is completed at. The application is based on the state the person is completing it in.
– For a SELF SERVICE application (no agent present) - you can use the address city and state of the employee. 7) What is paymode? it is like ( by Cash ,Cheque) or ( biweekly , monthly etc).
– The is an integer for the number of times a person is paid in a year. 8) Why there is tag of MARITALSTATUS in spouse section? If a person is someones spouse then it is understood that it is married?
– A person me be treated as a spouse but not legally married. 9) A general question suppose XML structure has one field let say X and that X doesn't have any value in our system so how to handle such scenario?
– Place a tag in the XML with no data. Some of the fields are optional and those can be left out. 10) How to receive the response from TexasLife after user made Enrollment in your system?
– At the end of the Texas Life enrollment process data will be posted back to the url provided in the entry XML under the tag <EXIT>. The format of the xml is defined in the DTD.
Aditya Vishwakarma (Inactive)
added a comment - As per Scott Lee :
Queries
1) The URL https://www.empben.com/WKTest/WebConnect/FrameDemo.py is common for all developer or we (Workterra ) will have separate URL to test or devlop our cases.
– It is a common example site. It is meant to show examples of how to connect and to test the xml structure if need be.
2) The XML format is changed now on above url. As per our another email thread clean up is needed.Can you please cleanup or share the steps to clear it by our self
Sharing steps with us will useful if, we messed it up we can reset it again that will save time for both of us.
– I can reset it back to the original
+
XML section queries based on XML structure we had seen at the time of demo+
3) Can we have concrete structure of XML so that we can implement it as I see some of get completely changed.
– I can provide the DTD that the XML structure is configured from. The XML is dynamic based on the number of people being passed to Texas Life. It is attached to this email.
4) Currently we have three scenario – there should be 7.
-Employee
-Employee and Spouse
-Employee Spouse and Child
-Employee and Child
-Spouse and Child
-Spouse Only
-Child Only
What will be the case if Employee has Child but no spouse ( divorce , deceased etc)?
5) Beneficiary section of Employee: What will be the structure if Employee has multiple beneficiaries?
– the beneficiary section is a list of the beneficiaries. it is defined in the dtd.
6) What is LOCATION, CITY, STATE at the end of employee section as we can see these fields already in Address section?
– This is the physical location that the application is completed at. The application is based on the state the person is completing it in.
– For a SELF SERVICE application (no agent present) - you can use the address city and state of the employee.
7) What is paymode? it is like ( by Cash ,Cheque) or ( biweekly , monthly etc).
– The is an integer for the number of times a person is paid in a year.
8) Why there is tag of MARITALSTATUS in spouse section? If a person is someones spouse then it is understood that it is married?
– A person me be treated as a spouse but not legally married.
9) A general question suppose XML structure has one field let say X and that X doesn't have any value in our system so how to handle such scenario?
– Place a tag in the XML with no data. Some of the fields are optional and those can be left out.
10) How to receive the response from TexasLife after user made Enrollment in your system?
– At the end of the Texas Life enrollment process data will be posted back to the url provided in the entry XML under the tag <EXIT>. The format of the xml is defined in the DTD.
Following point discussed: 1) We are not going to syn-cup any changes in Worktera to TexasLife through code once enrollment is made. 2) This all should be handled through EDI. 3) There is no change in policy of TexasLife once the user bought it. The user has option to either continue with policy or cancel it or can buy additional new policy. 4) No changes is made to TexasLife policy at any point of time like age band, eligibility, cost reduction. 5) Scenario like core plan allocation, Termination of Plan etc will all done through EDI , however our system will run as usual.
Aditya Vishwakarma (Inactive)
added a comment - - edited Following point discussed:
1) We are not going to syn-cup any changes in Worktera to TexasLife through code once enrollment is made.
2) This all should be handled through EDI.
3) There is no change in policy of TexasLife once the user bought it. The user has option to either continue with policy or cancel it or can buy additional new policy.
4) No changes is made to TexasLife policy at any point of time like age band, eligibility, cost reduction.
5) Scenario like core plan allocation, Termination of Plan etc will all done through EDI , however our system will run as usual.
.
Prasad Pise (Inactive)
added a comment - HI Aditya Vishwakarma
We need discussion on this task before we start testing. Points to be discussed
What changes are done?
Which environment to test?
Which company to test?
Impacted Areas
Any known issues
Testing Scope
Samir We will start testing once we have the clear idea about what to test?
Thanks
-Prasad
We have tested this change on Stage for "Symphony For HSPL", as most of the scenarios are working as expected. We can deploy this change to production.
We will attach the list of executed scenarios later, as most of the things will be get cleared in today's demo.
Kunal Kedari (Inactive)
added a comment - We have tested this change on Stage for "Symphony For HSPL", as most of the scenarios are working as expected. We can deploy this change to production.
We will attach the list of executed scenarios later, as most of the things will be get cleared in today's demo.
We are done with testing of this item on Production using "Optimum For HSPL". All issues linked to this ticket are closed. Now this change is working as expected. Test scenarios are there in TestLink. Closing the ticket.
Kunal Kedari (Inactive)
added a comment - We are done with testing of this item on Production using "Optimum For HSPL". All issues linked to this ticket are closed. Now this change is working as expected. Test scenarios are there in TestLink. Closing the ticket.
-Plan set up for "Optimum for HSPL" on Production
-Plan set up for "Affco for HSPL" on Production
-Testing TexasLife Integration for "Affco For HSPL"
-Testing TexasLife Integration for "Optimum For HSPL"
Enhancement
Medium
WT-11742 TexasLife-> Coverage String Correction for multiple Member Enrollment.
WT-11792 TexasLife-> Send all the Member to TexasPortal by default while enrollment.
WT-11420 SSO>TexasLife>Internal Server error at TexasLife side, after clicking on "See Options" button
Vinanti Yadav (Inactive)
logged work - 19/Jul/17 09:22 AM 
Khandu Kshirsagar (Inactive)
made changes -
Kunal Kedari (Inactive)
made changes -
Queries discussed on the call (25-May-2017):
1) While enrolling will employee each time will be redirected to Texaslife web site , because it is possible the EE will enroll in one of Texas life plan and another for other plan not of TexasLife and again in paln of Texas life.
=> No, All enrolled plan information by EE, we will keep in memory in WT application and will post all request in one go.
2) What about EOI scenario?
=> They have their own EOI processing unit for which we have post the request only. After their process they will send response back . If we have to catch response. For response tentatively we need to wait for 2-5 or more minutes as it may take time. Mean while either we have to keep waiting the user or find any other way to display processed result to user without keeping them idle.
3) Do we need to implement all Enrollment Services Mentioned in document?
=> Its completely optional and depends on the need.
4) What kind of Implementation is preferable as it seems like XML-RPC and HTTP POST are alternate of Embedding the Texas Life Enrollment system or vice-versa.
=> The implementation can be done in either way. we will decide only after seeing and analysis of demo.
5) Will it be possible to share any implementation demo apart from Mentioned Demo in the document. Any screen-shot will also be helpful.
=> Yes they are agree to show us demo ,need to scheduled a call with them.
.