Vergleichsreport

In HR-Expert können Einträge eines Mitarbeiters in einer Zeitlinie historisiert gespeichert werden. Einige grundlegende Dinge sind hierfür allerdings zu beachten, damit keine Datensätze versehentlich überschrieben werden. HR-Expert bietet dem Administrator einiges an automatischer Unterstützung, stellt aber die Richtigkeit eingegebener Daten nicht immer in Frage. Es gilt der Grundsatz: “Der Administrator hat (fast) immer Recht.“

Regel Nr. 1:

Es wird empfohlen immer einen neuen Datensatz mit klicken auf „Neu“ anzulegen, anstatt einen bestehenden zu bearbeiten. 

• „Bearbeiten“ verändert die Daten eines bestehenden Datensatzes 
• „Neu“ legt einen neuen Datensatz an.

Regel Nr. 2:

Die Daten „Gültig von“ und „Gültig bis“ sind entscheidend für die Speicherung eines Datensatzes wie z.B. Gruppenzuweisung, Gehaltseinträge, Bankkonten, Primäre Wohnadresse, Beschäftigungseinträge, etc. 

Muss HR-Expert aufgrund einer zeitlichen Überschneidung (Konflikt) eine Abgrenzung vornehmen, so wird grundsätzlich immer der zuletzt eingegebene Datensatz bevorzugt. Zum besseren Verständnis, beschreibt nachfolgende Grafik das Vorrangprinzip.

Auf dieser Grafik ist zu sehen, wie sich Einträge mit unterschiedlicher Gültigkeitsdauer zueinander verhalten.

Wichtig! Absolut nichts kann vor dem Gültigkeitsbeginn des Mitarbeiteraktes gespeichert werden, definiert im Datum „Gültig von“ im Reiter Stammdaten. Jeder Eintrag mit einem früherem Gültigkeitsbeginn wird automatisch auf dieses Datum korrigiert (Eintrag D in der Grafik). 

Beim Speichern löst nun das System die zeitlichen Überlappungen der beiden Datensätze automatisch auf. Nach dem Prinzip der Bevorrangung neuerer Datensätze wird somit der ursprüngliche Eintrag A zeitlich verkürzt, so dass dieser mit dem Beginn von B endet.

Wiederum bestehen zeitliche Überlappungen, die nicht zulässig sind und vom System beim Speichern nach dem Prinzip der Bevorrangung neuerer Datensätze automatisch aufgelöst werden.

Zustand 6: Der HR-Admin erstellt Eintrag D mit einem Datum vor dem Gültigkeitsdatum des Mitarbeiterstammsatzes. 

Dies resultiert neben den zeitlicher Überlappung mit allen bisherigen Einträgen auch noch in der Fehlersituation, dass die Gültigkeit vor der Gültigkeit des Mitarbeiters beginnt.Das System korrigiert die Situation beim Speichern folgendermaßen:

• Der Gültigkeitsstart des neuen Eintrags wird auf den Gültigkeitsstart des Mitarbeiters gesetzt. 
• Der neue Eintrag überschreibt (löscht) alle zuvor erstellten Einträge, da diese zeitlich mit dem neueren „kollidieren“.

Das Resultat ist ein einziger Eintrag D, welcher sich über die gesamte Gültigkeit erstreckt und alle bisherigen Eingaben auslöscht.

Zusammenfassung

, employee entries can be historically stored in a timeline. However, there are a few basic things to keep in mind so that no data records are accidentally overwritten. HR-Expert offers the administrator some automatic support, but does not always question the accuracy of the data entered. The principle is: "The administrator is (almost) always right". I

Rule Nr. 1:

It is always recommended to create a new record by clicking on "New" instead of editing an existing one.  

• "Edit" changes the data of an existing dataset. 
• "New" creates a new record.

Rule Nr. 2:

The data "Valid from" and "Valid to" are essential for the storage of a dataset such as group assignment, salary entries, bank accounts, primary residential address, employment entries, etc. 

If HR-Expert has to make a delimitation due to a time overlap (conflict), the last data record entered is always preferred. For a better understanding, the following graphic describes the priority principle. 

This graphic shows how entries with different validity periods relate to each other. 

Important! Absolutely nothing can be saved before the start of validity of the employee file, defined in the date "Valid from" in the master data tab. Each entry with an earlier start of validity is automatically corrected to this date (entry D in the graphic).  

State 1: Entry A begins, for example, with the "Valid from" of the master data.
State 2: The HR admin creates B with a "Valid from" during the validity period of A. A and B both have a "Valid to" infinity.

When you save, the system automatically breaks down the overlaps between the two data records. In accordance with the principle of prioritizing newer data records, the original entry A is shortened so that it ends with the start of B. The system then saves the new data records automatically.

State 3: Displays the result after automatic correction by the system.
State 4: The HR admin creates C with a validity before that of B. B and C both have a "Valid to" infinity.

 Again, there are temporal overlaps that are not allowed and are automatically resolved by the system when you save according to the principle of prioritizing new data records.

State 5: Displays the result after saving. The system has corrected the "valid to" from A to one day before the "valid from" from C. Entry C is valid until further notice ("Valid to" infinite).

State 6: The HR admin creates entry D with a date before the validity date of the employee master record.

 In addition to the time overlap with all previous entries, this also results in the error situation that the validity begins before the employee's validity. The system corrects the situation as follows when saving:

• The validity start date of the new entry is set to the employee's validity start date. 
• The new entry overwrites (deletes) all previously created entries, since they collide with the newer entry.

The result is a single entry D that extends over the entire validity period and deletes all previous entries.

Summarization

• The "Valid from" date in the employee's master data is the earliest possible validity start date for all data records contained in the master data. 
• "Edit" changes an existing data record! The previous contents are not saved! 
• "New" creates a data record, optimal for the historical storage of the data. 
• Last entered data are prioritized. "The administrator is right", therefore the correct input of the data "Valid from" and "Valid to" is particularly important. 
• At any one time, only one entry can exist per historicized entry type (e.g. only one primary residential address per validity period).