Beispiele für die Beibehaltung der Beschäftigungsänderungen bei Änderung des Gültigkeitsdatums
Das folgende Beispiel zeigt, wie beim Ändern des Gültigkeitsdatums die Beschäftigungsänderungen in Beschäftigungsabläufen beibehalten werden.
Neues Gültigkeitsdatum muss zwischen Gültigkeitsdatum des vorherigen und nächsten Datensatzes liegen
Wenn Sie die Arbeitsstellenzeile mit dem Gültigkeitsdatum 1. März 2019 hinzugefügt haben, werden die Änderungen nur beibehalten, wenn das Datum zwischen dem 1. Februar 2019 und dem 1. Juni 2019 geändert wird.
| Datum |
Aktion |
Geschäftseinheit |
Standort |
Tätigkeit |
Abteilung |
Gehaltsgruppe |
Weitere Informationen |
|---|---|---|---|---|---|---|---|
| 1. Januar 2019 |
Einstellen |
Geschäftseinheit 1 |
Standort 1 |
Tätigkeit 1 |
Abteilung 1 |
Gehaltsgruppe 1 |
Historischer Datensatz |
| 1. Februar 2019 |
Versetzen |
Geschäftseinheit 1 |
Standort 1 |
Tätigkeit 1 |
Abteilung 2 |
Gehaltsgruppe 1 |
Historischer Datensatz |
| 1. März 2019 |
Standort ändern |
Geschäftseinheit 1 |
Standort 2 |
Tätigkeit 1 |
Abteilung 2 |
Gehaltsgruppe 1 |
Neu hinzugefügter Datensatz |
| 1. Juni 2019 |
Beförderung |
Geschäftseinheit 1 |
Standort 1 |
Tätigkeit 1 |
Abteilung 2 |
Gehaltsgruppe 1 |
Zukünftiger Datensatz |
Wert wird ungültig, wenn das Gültigkeitsdatum geändert wird
Wenn Sie einen Wert eingeben, der am neu geänderten Datum nicht gültig ist, wird er auf den alten Wert zurückgesetzt. Dies wird im folgenden Beispiel veranschaulicht:
Gehaltsgruppe 1 ist ab 1. Januar 1951 und Gehaltsgruppe 11 ab 1. Juni 2019 aktiv.
| Datum |
Aktion |
Geschäftseinheit |
Standort |
Tätigkeit |
Abteilung |
Gehaltsgruppe |
Weitere Informationen |
|---|---|---|---|---|---|---|---|
| 1. Januar 2019 |
Einstellen |
Geschäftseinheit 1 |
Standort 1 |
Tätigkeit 1 |
Abteilung 1 |
Gehaltsgruppe 1 |
N/V |
| 1. Juni 2019 |
Beförderung |
Geschäftseinheit 1 |
Standort 1 |
Tätigkeit 1 |
Abteilung 2 |
Gehaltsgruppe 11 |
Neu hinzugefügter Datensatz |
Wenn Sie das Datum des neu hinzugefügten Datensatzes vom 1. Juni 2019 in den 1. Mai 2019 ändern, wird der Gehaltsgruppenwert wieder auf die Gehaltsgruppe 1 zurückgesetzt, weil Gehaltsgruppe 11 am neuen Datum nicht gültig ist.
Beschäftigungsänderungen bei Standardvorgabe abhängiger Felder beibehalten
Betrachten wir ein Anwendungssetup, bei dem der Standort standardmäßig aus der Abteilung vorgegeben wird. Im folgenden Beispiel ändert der Benutzer die Abteilung von "Vertrieb" in "Finanzen", und als Standort wird "Trivandrum" vorgegeben. Der Benutzer löscht dann diesen vorgegebenen Wert.
| Vorgang | Gültigkeitsdatum | Abteilungsattribut | Standortattribut (abhängiges Attribut) | Benutzeränderung | Anwendungsverhalten |
|---|---|---|---|---|---|
| Einstellen | 1. Januar 2010 | Vertrieb | Hyderabad | Nicht anwendbar | Nicht anwendbar |
| Versetzen | 1. März 2010 | Finanzen | Null | Standort "Trivandrum" löschen | Standort "Trivandrum" wird gelöscht |
| Versetzen | 15. März 2010 | Finanzen | Null | Gültigkeitsdatum ändern | Zeigt die Finanzabteilung und keinen Wert für den Standort an |
- Der ursprüngliche Wert des abhängigen Attributs ist "Null", und Sie haben den Standardwert im abhängigen Attribut während der Transaktion manuell gelöscht.
- Sie haben das Gültigkeitsdatum einer Beschäftigungstransaktion geändert.
Das folgende Beispiel zeigt einen Mitarbeiter, dessen Abteilung und Standort während der Einstellung nicht aufgefüllt werden. Der Benutzer gibt bei der Versetzung als Wert für die Abteilung "Human Resources" ein.
| Vorgang | Gültigkeitsdatum | Abteilungsattribut | Standortattribut (abhängiges Attribut) | Benutzeränderung | Anwendungsverhalten |
|---|---|---|---|---|---|
| Einstellen | 1. Januar 2010 | Kein Wert | Kein Wert | Nicht anwendbar | Nicht anwendbar |
| Versetzen | 10. Januar 2010 | Human Resources | Null |
|
Standort "Bangalore" wird gelöscht |
| Versetzen | 1. Februar 2010 | Human Resources | Bangalore |
|
Standort "Bangalore" wird standardmäßig vorgegeben |
In diesem Beispiel wählt der Benutzer bei der Versetzung eines Mitarbeiters als Abteilung "Human Resources" aus, und der Standort "Bangalore" wird standardmäßig vorgegeben. Der Benutzer löscht dann den Standort "Bangalore", sodass kein Wert angezeigt wird. Wenn der Benutzer jetzt das Gültigkeitsdatum der Versetzungstransaktion ändert, wird Bangalore erneut standardmäßig vorgegeben, obwohl der Benutzer diesen Standort gelöscht hat. Der Benutzer muss den Standort "Bangalore" erneut manuell löschen. Dieses Verhalten tritt auf, weil zunächst kein Standort vorhanden war und der Benutzer später den vorgegebenen Standort löscht. Da in diesem Szenario keine Änderung zwischen dem ursprünglichen Wert und dem Wert nach der Benutzeränderung des Attributs "Standort" erfolgt ist, betrachtet es die Anwendung nicht als Benutzeränderung und behält den Wert nicht bei.