Exemples de conservation de vos changements d'emploi tandis que la date d'effet évolue
Voici un exemple illustrant la façon dont vos changements d'emploi sont conservés dans les flux d'emploi lorsque vous modifiez la date d'effet.
La nouvelle date d'effet doit être comprise entre la date d'effet de l'enregistrement précédent et la date d'effet de l'enregistrement suivant.
Si vous avez ajouté la ligne d'affectation à date d'entrée en vigueur le 1er mars 2019, les modifications ne seront préservées que si la nouvelle date est comprise entre le 1er février 2019 et le 1er juin 2019.
| Date |
Action |
Unité opérationnelle |
Lieu |
Emploi |
Service |
Grade |
Informations supplémentaires |
|---|---|---|---|---|---|---|---|
| 1er janvier 2019 |
Embauche |
Unité opérationnelle 1 |
Lieu de travail 1 |
Emploi 1 |
Service 1 |
Grade 1 |
Enregistrement historique |
| 1er février 2019 |
Transfert |
Unité opérationnelle 1 |
Lieu de travail 1 |
Emploi 1 |
Service 2 |
Grade 1 |
Enregistrement historique |
| 1er mars 2019 |
Changer de lieu de travail |
Unité opérationnelle 1 |
Lieu de travail 2 |
Emploi 1 |
Service 2 |
Grade 1 |
Enregistrement nouvellement ajouté |
| 1er juin 2019 |
Promotion |
Unité opérationnelle 1 |
Lieu de travail 1 |
Emploi 1 |
Service 2 |
Grade 1 |
Enregistrement futur |
La valeur devient non valide lorsque vous modifiez la date d'effet
Si vous saisissez une valeur qui n'est pas valide à la date récemment modifiée, l'ancienne valeur est restaurée. Prenons l'exemple suivant à titre d'illustration :
Le grade 1 est actif à partir du 1er janvier 1951 et le grade 11 à partir du 1er juin 2019.
| Date |
Action |
Unité opérationnelle |
Lieu |
Emploi |
Service |
Grade |
Informations supplémentaires |
|---|---|---|---|---|---|---|---|
| 1er janvier 2019 |
Embauche |
Unité opérationnelle 1 |
Lieu de travail 1 |
Emploi 1 |
Service 1 |
Grade 1 |
N/A |
| 1er juin 2019 |
Promotion |
Unité opérationnelle 1 |
Lieu de travail 1 |
Emploi 1 |
Service 2 |
Grade 11 |
Enregistrement nouvellement ajouté |
Si vous modifiez la date de l'enregistrement nouvellement ajouté du 1er juin 2019 au 1er mai 2019, le grade sera redéfini sur la valeur Grade 1 car le grade 11 n'est pas valide à la nouvelle date.
Valeurs par défaut des champs dépendants lors de la conservation de vos changements d'emploi
Considérez la configuration de l'application dans laquelle le lieu est défini par défaut à partir du service. Dans l'exemple ci-dessous, l'utilisateur remplace le service Ventes par le service Finance et le lieu est défini par défaut sur Delhi, valeur qui est effacée par la suite par l'utilisateur.
| Action | Date d'effet | Attribut Service | Attribut Lieu (attribut dépendant) | Modification de l'utilisateur | Comportement de l'application |
|---|---|---|---|---|---|
| Embauche | 1er janvier 2010 | Ventes | Hyderabad | Non applicable | Non applicable |
| Transfert | 1er mars 2010 | Finance | NULL | Effacer le lieu Delhi | Le lieu Delhi est effacé |
| Transfert | 15 mars 2010 | Finance | NULL | Modifier la date d'effet | Afficher le service Finance et laisser le champ Lieu à blanc |
- La valeur initiale de l'attribut dépendant est nulle et vous avez effacé manuellement la valeur de l'attribut dépendant définie par défaut lors de la transaction.
- Vous avez modifié la date d'effet d'une transaction d'emploi.
Dans l'exemple ci-dessous, aucune valeur de service et de lieu n'est renseignée pour un employé lors de son embauche et l'utilisateur renseigne la valeur Ressources Humaines en tant que service lors de son transfert.
| Action | Date d'effet | Attribut Service | Attribut Lieu (attribut dépendant) | Modification de l'utilisateur | Comportement de l'application |
|---|---|---|---|---|---|
| Embauche | 1er janvier 2010 | Aucune valeur | Aucune valeur | Non applicable | Non applicable |
| Transfert | 10 janvier 2010 | Ressources humaines | NULL |
|
Le lieu Bangalore est effacé |
| Transfert | 1er février 2010 | Ressources humaines | Bangalore |
|
Le lieu Bangalore est défini par défaut |
Dans cet exemple, lors du transfert d'un salarié, l'utilisateur sélectionne le service Ressources Humaines et le lieu Bangalore est défini par défaut. L'utilisateur efface ensuite la valeur Bangalore pour avoir un champ à blanc. A présent, lorsque l'utilisateur modifie la date d'effet de la transaction de transfert, la valeur Bangalore est redéfinie par défaut même si l'utilisateur avait effacé ce lieu auparavant. L'utilisateur doit effacer à nouveau manuellement la valeur Bangalore. Ce comportement est dû à l'absence de lieu au départ et à la suppression ultérieure du lieu défini par défaut. Dans ce scénario, dans la mesure où la valeur initiale de l'attribut Lieu est identique à la valeur après modification de l'utilisateur, l'application ne la considère pas comme une modification de l'utilisateur et ne retient pas la valeur.