Algunos ejemplos de recuperaci´ on de la fase

With the migration of FOs to MDF FOs (GOs) the HRIS elements of the migrated objects are no longer available in the Corporate Data Model XML as an association destination. Instead, associations from the GOs to another FO or GO are now defined in MDF. For associations from a GO to a FO, associations cannot be directly defined. Instead, a wrapper GO is used. A wrapper is not required for associations to custom FOs as these are considered to be GOs.

The table below describes the different associations possible. Here mFO refers to the MDF FO; cGO refers to a custom FO; FO refers to Foundation Objects defined in the Corporate Data Model.

Association before Migration

Is defined in Association after migration

Is defined in Details

mFO – cGO Corporate Data Model mGO – cGO MDF

mFO – FO Corporate Data Model mGO – FO using WrapperGO

MDF Here you cannot have a

direct association. external code is set to GO.

FO – mFO Corporate Data Model FO – mGO Corporate Data Model Here FO is changed to GO in the association definition.

mFO – mFO Corporate Data Model mGO – mGO MDF Defined in Configure

Object Definitions page. The association type is valid-when.

mGO - mFO using wrapper GO

MDF mGO - mGO MDF The association using

the wrapper GO is replaced by a direct association between the two GOs .

Example

Association from FO costCenter to an FO or GO defined in the Corporate Data Model before the migration:

<hris-associations>

After the migration, the association to FO Location is migrated to the MDF association with name

cust_toFOWLocation and destination object type FOWLocation. Here, FOWLocation is the wrapper GO for the FO Location. The association to the wrapper GO is modeled as Type "Composite" and Multiplicity "One To Many". The association to the custom FO Sub Division (GOSubDivision) will be modeled as an association of Type "Valid When" and Multiplicity "One To Many".

Example

Association from FO to FO costCenter defined in CDM before the migration:

<hris-associations>

<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geozone"

required="false"/>

<association id="id" multiplicity="ONE_TO_MANY" destination-entity="company"

required="false" />

<association id="id" multiplicity="ONE_TO_MANY" destination-entity="costCenter"

required="false" />

</hris-associations>

Association from FO to GO CostCenter defined in the Corporate Data Model after the migration:

<hris-associations>

<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geozone"

required="false" />

<association id="id" multiplicity="ONE_TO_MANY" destination-entity="LegalEntity" required="false" />

<association id="id" multiplicity="ONE_TO_MANY" destination-entity="CostCenter"

required="false" />

</hris-associations>

Example

If you have implemented a GO with composite association to cost center, you must define an association from the GO to costCenter FO. For that you must implement a wrapper GO as proxy for the costCenter FO. After the migration, the wrapper GO will be the proxy for the GO CostCenter. If the wrapper GO is not used for other purposes, we recommend that you change the association definition at the GO and have GO CostCenter as the association destination instead of the wrapper GO.

Before the migration, cost center was an FO, and it is now a GO. If you want to maintain the GO CostCenter assignments, you can use the Manage Data page.

All the filtering on Job Information and Position works as before. Now you have a new element called Field Criteria:

Earlier, the value help on custom-defined fields would automatically filter out associated Generic Objects. After migration, the field criteria can be used to change the value help behavior as to which field shall be filtered as child field.

You can restrict the value list of the GO source depending on the GO/FO destination selection, while associating GO source to a GO/FO destination. If FO is the association destination, you perform this task using a GO Wrapper.

If you want to filter an FO-related field by a GO-related field, you define a One-to-Many association at the FO HRIS element type in the Corporate Data Model and enter the GO type as the association destination.

You must add field criteria in Job Info at the field that is filtered. Earlier, the element Field Criteria was not required, and the parent/child field relationship was reversed.

Example

On Job Info, the cost center field is filtered by business unit and a custom field custom-string2 referring to GO cust_GCC:

<hris-field max-length="256" id="cost-center" visibility="both">

<label>Cost Center Account</label>

<label xml:lang="de-DE">Kostenstellenkonto</label>

<field-criteria sourceFieldName="cust_toBusinessUnit.internalId"

destinationFieldValue="business-unit" />

<field-criteria

sourceFieldName="cust_tocust_GCC.mdfSystemInternalCode"

destinationFieldValue="custom-string2" />

</hris-field>

Example

On Job Info, location field is filtered by cost center field:

<hris-field max-length="128" id="location" visibility="both">

<label>Location</label>

<field-criteria sourceFieldName="CostCenter" destinationFieldValue="cost-center"/>

</hris-field>

For the migrated FOs Business Unit, Division, Department and Legal Entity, FO Wrapper types are now deprecated. You must not use them any more. If Cost Center has an association to an FO Wrapper, it will be migrated to the mapped GO and association type will be changed to valid-when. This is applicable for associations to Business Unit, Division, Department and Legal Entity only.

A few scenarios are explained below.

Example

If the Department is restricted, the field criteria is always defined at the restricted field, The field criteria in this case will be as follows:

The source field name must be in the format <association name>.internalId and destinationFieldValue will be in the format <business-unit. The destination field will be the field name in the Succession Data Model.

Example

If there is an association from Business Unit to Location, a wrapper will be required for the association.

Additionally, if there is an association from Business Unit to Cost Center, it will be a direct association since this is an mGO - mGO association: