Closed GoogleCodeExporter closed 9 years ago
Issue has been shared with HighRoads team and is being reviewed.
Original comment by Tim.at.H...@gmail.com
on 11 Jun 2015 at 3:15
I do not see this plan design when I search in the Configurator with that
criteria. I searched in pclient5 directly in Search for this plan design name
and it doesn't come up.
Unfortunately I don't want to leave it at this and have another defect
resubmitted when and if the issue is seen again, but I cannot troubleshoot if I
cannot recreate.
Original comment by michelle...@gmail.com
on 11 Jun 2015 at 5:42
BCBS will look to demo this issue at today's meeting.
Original comment by Patrick.C.Commander
on 11 Jun 2015 at 6:11
3416171 can be used as a reference.
Original comment by Tim.at.H...@gmail.com
on 11 Jun 2015 at 8:02
Retested with original plan used to create 3416171, 600353, as Will is locked
in that plan. I created a new custom plan from this one to test how the values
were brought over (the '#N/A' is in the Other Practitioner Office Visit Lowest
Cost Share field of 3416171). The value was brought over to the new plan,
3421168, correctly and the SBC generated correctly. I don't know what edits
were made to the former custom plan, as it's locked. But when a user sees a
value like this in the plan design, they should correct it and then
Save/Generate the SBC.
Cannot recreate issue without manually adding in #N/A and the system is working
as expected if it finds this value as it's not a valid value. Please retest.
Thank you.
Original comment by michelle...@gmail.com
on 12 Jun 2015 at 2:16
HR still cannot reproduce this item. Did not discuss in detail during
yesterday's defect meeting due to time. Assigning to Gaurang. We should look
to verify that this issue is still reproducible and then look to demo at our 3.
Original comment by Patrick.C.Commander
on 12 Jun 2015 at 5:55
HR to look for occurances of 'junk value' issues prior to push to prod. see
also: 175, 176, 181
Original comment by Patrick.C.Commander
on 12 Jun 2015 at 9:34
assigning to HR as part of the junk value update
Original comment by Patrick.C.Commander
on 15 Jun 2015 at 7:48
Priority has been set as showstopper level 2. This issue is part of the junk
value workstream that HR owns.
Original comment by Patrick.C.Commander
on 16 Jun 2015 at 2:12
Regarding our issues with “junk values” and/or values of N/A… it appears
to mainly caused by a workbook formula that had a misspelling within it. We are
doing a thorough review of the workbooks to ensure there are no others.
Original comment by Tim.at.H...@gmail.com
on 16 Jun 2015 at 2:19
fixes to be bundled by HR. Aim is for HR to deliver tomorrow afternoon.
Original comment by Patrick.C.Commander
on 16 Jun 2015 at 7:18
All workbooks have been reviewed and fixed where needed. Tested and confirmed
no junk values appear. Ready for retest.
Original comment by Tim.at.H...@gmail.com
on 17 Jun 2015 at 3:34
BCBS will retest this item.
Original comment by Patrick.C.Commander
on 17 Jun 2015 at 7:38
testing to continue through EOD.
Original comment by Patrick.C.Commander
on 18 Jun 2015 at 6:53
I have been unable to reproduce this one so far. Can be closed.
Original comment by g4gaur...@gmail.com
on 19 Jun 2015 at 5:27
closing per above.
Original comment by Patrick.C.Commander
on 19 Jun 2015 at 5:43
A BE user experienced a situation where when she entered text appending an existing L&E value/text for Imaging on the interface and save it, it turned into a junk value (#value!)
Plan design is 3459290_Stratus Technologies_Network_Blue_NE_Ded_154799BS
This may or may not be reproducible immediately when you try to replicate it on Pclient5/Prod. but we would like you to review and fix the capture file formula for invalid references and ensure this does not happen again.
Gaurang,
Can you offer more detail as to what the text was that the BE entered?
Thanks,
Tim
Here it is Deductible applies first; copayment applies per category of test / day; copayment limited to $375 per member per calendar year; pre-authorization required for certain services
Guarang, We have tested out the values in multiple workbooks with the Limitations string you sent and we are not seeing any errors in PClient5. Please retest at your convenience. Thank you, Tim
Tim, as I indicated above, you may or may not be able to reproduce the defect immediately but the fact is it has occurred on the said plan in production. The question is can you investigate and/or tweak your cell reference formula for that field appropriately so that the #value! does not show up again unexpectedly or do you do nothing and just wait for another recurrence of a similar issue in the future ?
Hi Guarang. I don't think our intention is to do nothing on this. What would really help us is to have the text string which caused the issue. Having that data would allow us to reproduce the issue and then take decisive action on tweaking the formula. What I'll do is carve out some time tomorrow to see if I can reproduce the issue. If I cannot, we can close this issue for now as not reproducible. If it does happen again, lets try and get the exact text string.
Here it is Deductible applies first; copayment applies per category of test / day; copayment limited to $375 per member per calendar year; pre-authorization required for certain services
This is the exact string that the BE provided.
Can you put in a IFERROR(value, value_if_error) error handling mechanism for this service to ensure such error messages do not leak out to the UI/document ?
The BE users are running into this same issue on the same plan again as they finalize the plan to send to the account. I am attaching the draft SBC here. copy the Imaging L&E from the SBC document as is and paste it in the Imaging L&E field on the UI and click save. Notice the #value! tag re-appear.
Plan design is 3459290_Stratus Technologies_Network_Blue_NE_Ded_154799BS
the BE user recreated this issue a few times.
Thanks, Gaurang - this seems to happen after 2 or more saves, but not one. We're investigating the issue.
Guarang, We have updated the logic if an error (junk value) is encountered, the original text in the field will remain. It has been tested in PClient5 and confirmed working. Please retest at your convenience. Thank you, Tim
Tim, can you tell us what you changed in the logic ?
Guarang, The original Imaging Limitations logic is still in place and will work as intended. If, for some reason, it errors out on the back end, whatever the user has entered will be kept and will appear correctly. Same thing if the user selects “No cascade” for Imaging Cascade. It allows the user to enter whatever string into limitations they want without the preset logic interfering, as was the intention with it.
Essentially, in addition to fixing what was causing the error in the first place, there’s an overarching IFERROR() around it that will keep whatever the user entered if the Imaging formula errors out. Thanks, Tim
Changes look good on Pclient5. Please move to production.
Guarang, Thank you for testing. We will move to Production and let you know when it is ready for retest. Tim
Guarang, The changes have been moved to Production and are ready for retest. After approval/confirmation please close the issue. Thanks, Tim
Looks good in production.
Original issue reported on code.google.com by
g4gaur...@gmail.com
on 11 Jun 2015 at 3:01Attachments: