- While selecting randomly a user who has more than one dependent, the data is not displayed correctly, but the first row of each record is misaligned.
- The scroll bar on the portlet no longer appears either
- Customer can no longer set enabled fields on Personal Information to be disabled on the Dependent Person Type. If they try to update Manage Business Configuration they receive the below error:
1. As the field country-of-birth is set to required it needs to have visibility "Edit".
2. DEPENDENT Data Model is not consistent: The field date-of-birth should be enabled and mandatory in personInfo_dependent, as the field in personInfo is enabled and mandatory.
- Employee Central – Dependents
- Employee Central – Manage Business Configuration
Reproducing the Issue
- Search for a user with dependent information
- Go to the Dependents Portlet
- In the preview page of the portlet, we only see some of the information stored and the first row is not correct, the content is misaligned (by clicking on details it seems to be correct)
- By clicking on “Edit” the misaligned information overwrites the correct one.
- Scroll down the page to the Dependents Portlet
- As soon as the UI starts to load the Depednents Block > An Application Error has occurred (with no fingerprintId or errorId)
In the 1802 release – Configuration Constraints were added for the new Dependents UI layer to prevent invalid configurations from being maintained – which has now caused some issues with customers who were early adopters of these new UI layers for Dependents Management and have implemented UI configurations incorrectly (due to the relaxed constraints) - such as making mandatory fields disabled for Dependents. Now the system preperly prevents such invalid configuration - but now the UI's configurations also need correcting.
NOTE: Any field that is set as mandatory yes in the parent (base) element, like personInfo element or personalInfo element, must be the same as the parent element.
Example incorrect/invalid configuration:
- personalInfo (base) element - field "salutation" is configured as Editable, Required and Enabled - configuration is constrained at base level to be an editable and required field
- personalInfo "Dependents" UI - field "salutation" is configured as Disabled - Field is disabled for Dependents - this is invalid configuration and will cause issues in import - field is required at base level
- personalInfo "Employee" UI - field "salutation" is configured as Editable and Enabled - Field is enabled for Employees but not required - when importing data the value will still be required
The root cause of this issue is a configuration issue. It is not supported to configure constrained fields (Required/Visibility) for any Person Type UI to be less constrained than the base configuration. Meaning you cannot Disable a field in the Dependents UI that is required in the base configuration. This is simply not the correct configuration.
Since 1802 release, constraints have been added to the configuration of these Person Type UI's to prevent such invaid configuration. If you are now impacted by wrong UI behaviour or error message in Manage Business Configuration, then you need to correct the configuration.
Please read the below carefully, as the correct solution to this configuration issue is given below in the Solution note, but also there is a code defect blocking the proper implementation/use of this configuration (see the SPECIAL NOTE below), and the work-around that you can imply in the interim.
To resolve the issue for the time being, the configuration must be corrected in the following fashion, to ensure the base configuration is unconstrained. Once the base config for that element is no longer constrained, UI Layers for Person Types “Dependent” and “Employees” can then be created to then constrain fields based on the Person Type.
Let’s take Personal Information (personalInfo) element as an example for how the UI layers should be configured:
- Configure “personalInfo” hris-element in BCUI, so that all fields used by the customer (for all Person Types) are present, and the fields are defined as Editable and NOT mandatory.
- Create a UI layer for Person Type “Dependent” for personalInfo hris-element – here you can then make fields Disabled, Read-only or mandatory.
- Create a UI layer for Person Type “Employee” for personalInfo hris-element – here you can then make fields Disabled, Read-only or mandatory.
So the rule of thumb here is – the “base” configuration is not constrained (every field the customer uses for all person types is enabled and editable) and then you further constrain what fields each different Person Type will see or be required to fill in based on customer requirement. This is the same logic we apply when creating Business Rules to make fields Mandatory (you always use a rule to make a field Mandatory – not make a mandatory field NOT mandatory).
Example correct configuration:
- personalInfo (base) element - field "salutation" is configured as Editable and Enabled - configuration is not constrained, field is available to all
- personalInfo "Dependents" UI - field "salutation" is configured as Disabled - Field is disabled for Dependents
- personalInfo "Employee" UI - field "salutation" is configured as Editable, Required and Enabled - Field is Required for Employees
Make a work-plan:
It is a good idea to create a mini-work plan to realize how the configuration will look. As explained above, the "base" configuration (that of the HRIS Element "personInfo" in the below example) should be open / un-constrained. Then for each Person Type that is implemented, you must constrain the fields from the Person Type level. The below is an example, where some fields (date-of-brith for example) is not needed for Dependents, but is needed for Employee's and Contingent Workers.
|HRIS Element / UI Layer||Enabled||Visibility||Required||Enabled||Visibility||Required||Enabled||Visibility||Required||Enabled||Visibility||Required||Enabled||Visibility||Required||Enabled||Visibility||Required||Enabled||Visibility||Required|
|Contingent Worker (personInfo_contingent worker)||Y||view||Y||Y||both||Y||N||none||N||N||none||N||N||none||N||N||none||N||N||none||N|
Please be aware that currently if you configure "Employee" Person Type UI's, this will cause Business Rules to no longer trigger in Hire UI's (such as Add New Employee / Add Contingent Worker ). Please refer to article 2632306 - 1802: Business Rules no Longer Triggering when using Person Type UI Layers in Manage Business Configuration (BCUI). Please review the work-around below if you need to implement the "Employee" Person Type UI as per the Solution mentioned above, but are blocked due to the issue mentioned in article 2632306.
Therefore it is currently recommended to correct your configuration as per the above, but not to implement any "Employee" Person Type UI's until the issue is resolved.
If you are unable to implement steps 1 and 2 from the solution above because you need to constraing "Employee" Person Type fields, then the work-around for now is to disable the "Dependent" and "Employee" UI's until the issue mentioned in article 2632306 is resolved with the release of 1805 on May 5th.
2632306 - 1802: Business Rules no Longer Triggering when using Person Type UI Layers in Manage Business Configuration (BCUI)
ECT-95660, ECT-96897, Dependent Information, Dependent UI Layer, 1802, scroll bar, DEPENDENT Data Model is not consistent, Person Type , KBA , LOD-SF-EC-DPD , Dependents Management , LOD-SF-EC-BCI , BCUI & DM Config(XML) , Bug Filed