SAP Knowledge Base Article - Public

2632305 - Dependents Management: Person Type UI Layer Configuration Constraints added in 1802

Symptom

  • 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.

Environment

  • Employee Central – Dependents
  • Employee Central – Manage Business Configuration

Reproducing the Issue

v12 UI

  1. Search for a user with dependent information
  2. Go to the Dependents Portlet
  3. 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)
  4. By clicking on “Edit” the misaligned information overwrites the correct one.

PP3 UI

  1. Scroll down the page to the Dependents Portlet
  2. As soon as the UI starts to load the Depednents Block > An Application Error has occurred (with no fingerprintId or errorId)

Cause

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 properly 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

Resolution

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.

Solution:

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:

  1. 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.
  2. Create a UI layer for Person Type “Dependent” for personalInfo hris-element – here you can then make fields Disabled, Read-only or mandatory.
  3. 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.

person-id-external date-of-birth country-of-birth region-of-birth place-of-birth date-of-death attachment-id
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
Base (personInfo) Y view Y Y both N Y both N Y both N Y both N Y both N Y both N
Dependent (personInfo_dependent) Y view Y N none N N none N N none N N none N N none N N none N
Employee (personInfo_employee) Y view Y Y both Y Y both Y Y both N Y N N Y both N Y both N
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

See Also

2632306 - 1802: Business Rules no Longer Triggering when using Person Type UI Layers in Manage Business Configuration (BCUI) - ARCHIVED

Keywords

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 , Manage Business Configuration (BCUI) & Data Models (XML) , Bug Filed

Product

SAP SuccessFactors HCM Core 1802