| Siebel Open UI > Siebel Open UI LOV errors
Siebel OpenUI LOV Lists Not Rendering Properly In IE11 Browser
ACTUAL BEHAVIOR
------------------------
LOV list jumps to the top of the screen in the Persons view in Siebel OpenUI on IE11 browser.
EXPECTED BEHAVIOR
-----------------------------
LOV list should work as expected.
STEPS
-----------------------
The issue can be reproduced ONLY in customer environment at will with the following steps:
1. Open call center application with IE11
2. Navigate to Site Map >> Administration - User >> Persons view
3. Scroll to the bottom of the form applet and adjust the browser so that you can see 3 records in the top 3 list applet.
4. Open the timezone LOV on form applet and check to see how the LOV list shows up.
BUSINESS IMPACT
-----------------------
The issue has the following business impact:
Due to this issue, users cannot see this properly in IE11 and this was causing a setback.
CAUSE
The cause of the issue was determined to be with a new bug in IP2016 on OpenUI IE11 browser. The cause of the issue is justified as the below bug was opened after testing this issue in-house and it has been identified as a code bug:
Bug 25684091 - LOV LIST FROM PERSONS VIEW FORM APPLET DOES NOT RENDER PROPERLY IN IE 11 BROWSER
SOLUTION
The solution action plan for the issue was as below:
1. Apply PS14 Patch set on top of IP2016
2. Make sure that the patch set is applied successfully.
3. Test LOV views on the views and check to see if the LOVs render properly.
Siebel CRM Desktop Delete (or inactivate) the Existing LOV
CRM Desktop 3.8.16.29 integrated with Siebel FINS Open UI 8.1.1.11.14
While synching Emails and appointments with Status being set as 'Done', we see the below errors being thrown. After about 2-3 synchs, the records pass through.
Either the status value you have selected is not applicable to this activity type, or you must submit this activity using the Submit button.(SBL-SIS-00181)"(SBL-EAI-04451))
As we saw in a related metalink document, we tried setting few vanilla EVENT_STATUS LOV's to active, but now the issue is that these extra values show up on the Siebel UI as well as
on the CRM Desktop field, which is not wanted for the users.
What is the actual root cause and reason for this issue and how can it be fixed permanentaly rather than with LOV changes.
again, would the issue only occur for Status when set as 'Done' or would it occur for other status' as well.
- What I need to know is , what is the actual root cause for the issue.
- If we go ahead and activate the LOV's, the Business would not like the solution as they are forced to see multiple records in the LOV.
- What are the other solutions available for this ? Is the issue only present when the Status of Done is presented.
SOLUTION
1. There are default values for many fields within Siebel. This has nothing to do with CRM Desktop--it is just normal behavior. For example, a new activity record might have a default status value of "In Progress". If Customers delete (or inactivate) the "In Progress" LOV, then they can no longer create activities because the default value is still on the BusComp definition but is not in the LOV list, so you would get an error.
To make matter worse, it is not as simply resolved as changing the default on the BusComp definition because the Action BusComp is used for myriad uses throughout Siebel and all these other areas will possibly assume that this (or some other) status value exists. For example, Email Response will expect it to be there, along with "Done", "New", and others.
For these reasons, our best recommendation is *don't inactivate these basic LOVs". These are all basic status values, like "New", "In Progress", "Done", etc. Any reasonable task /calendar management system needs these basic status values, so there is no reason to change them.
When Customers apply this CRM Desktop, it is just another possible place that this can happen. The client application has default values as well (all of which are defined in package_res in the metadata package). For obvious reasons, these match the defaults defined in the Siebel Repository. This is yet another reason not to mess with the Siebel values.
In summary, the right solution is to restore the native LOVs that are currently inactivated. If you want to do it the other ways, then Customers can change the default values as defined as the top of package_res, but you will probably continue to see problems in other product areas. It is not the right thing to do.
LOV Values Not Getting Fetched Based On Language - Siebel 8.1.1.11 and later Open UI
APPLIES TO:
Siebel CRM - Version 8.1.1.11 [IP2013] and later
Information in this document applies to any platform.
SYMPTOMS
On : 8.1.1.11 SIA [23030] version, Client Functionality
ACTUAL BEHAVIOR
------------------------
The LOV value is not being filtered based on the Language Code.
EXPECTED BEHAVIOR
---------------------------
The LOV value should be filtered based on the Language Code.
STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Login to application
2. Navigate to Administration Data -> List Of Values
3. Query for "ACCOUNT_STATUS" as LOV TYPE
4. Add a new value for English American
5. Add another value for French
6. Now, navigate to Accounts screen -> Account List View
7. For an existing record, click on the "Status" dropdown
Observe that both the newly added values are visible although the second value added was for a different language code
BUSINESS IMPACT
-----------------------
The issue has the following business impact:
Due to this issue, users are confused
CAUSE
After internal testing this is confirmed to be an expected behavior
For different language codes, multilingual set up needs to be done, which is not done in this case
SOLUTION
This is expected behavior if you do not have Multilingual set up.
If you need to use multiple language codes, then you will need to have a MLOV set up.
For more details on MLOV please refer to bookshelf.
Configuring Siebel Business Applications > Localizing Siebel Business Applications
| 
