Zum Hauptinhalt springen

Mitarbeiter-Ingest API Leitfaden

Dieses Dokument erklärt die Felder des Mitarbeiter-Ingests aus der Sicht eines kunden- oder partnerseitigen Integrationsteams. Im Vordergrund steht, was jedes Feld bedeutet, wie es codeto plan und codeto report beeinflusst und welche Werte bei der Datenaufbereitung besondere Aufmerksamkeit erfordern.

Der Ingest legt Mitarbeiter und ihre Verträge an oder aktualisiert sie. Vertragsbezogene Felder können zeitabhängig sein: Wenn sich ein Wert über die Zeit ändert, sollte er mit dem korrekten Gültigkeitszeitraum geliefert werden, damit codeto plan und codeto report den richtigen Wert für die jeweiligen Wochen, Rapporte, Saldi und Planungsansichten anwenden können.

DTO-Übersicht​

Der Mitarbeiter-Ingest akzeptiert einen oder mehrere Mitarbeiter. Jeder Mitarbeiter besitzt Felder auf oberster Ebene sowie einen oder mehrere Verträge darunter. Felder, die als VersionableProperty<T> gekennzeichnet sind, bestehen aus einer Liste von Werten mit Gültigkeitszeiträumen, wie im nächsten Abschnitt beschrieben.

type VersionedValue<T> = {
  value: T;
  validFrom: string;
};

type VersionableProperty<T> = VersionedValue<T>[];

type EmployeeIngestPayload = CreateEmployeeDto[];

type CreateEmployeeDto = {
  employeeId: string;
  contracts: CreateContractDto[];
  firstName: VersionableProperty<string>;
  lastName: VersionableProperty<string>;
  username: VersionableProperty<string>;
  language: VersionableProperty<string>;
};

type CreateContractDto = {
  contractId: string;
  subsidiaryId: string;
  costCenterIds: VersionableProperty<string[]>;
  employmentLevel: VersionableProperty<number>;
  apprenticeshipYear: VersionableProperty<string>;
  salaryType: VersionableProperty<string>;
  roleId: VersionableProperty<string>;
  employeeCategory: VersionableProperty<string>;
  workingPattern: WorkingPattern;
  workingPeriods: WorkingPeriod[];
  salaryComponents: SalaryComponents;
};

type WorkingPattern = {
  monday: VersionableProperty<number>;
  tuesday: VersionableProperty<number>;
  wednesday: VersionableProperty<number>;
  thursday: VersionableProperty<number>;
  friday: VersionableProperty<number>;
  saturday: VersionableProperty<number>;
  sunday: VersionableProperty<number>;
};

type WorkingPeriod = {
  startDate: string;
  endDate: string;
};

type SalaryComponents = {
  controllingCode: VersionableProperty<string>;
  billingRate: VersionableProperty<number>;
  overtimePayCode: VersionableProperty<number>;
  billingRateMileage: VersionableProperty<number>;
  vehicleBillingType: VersionableProperty<number>;
  dailyAllowance: VersionableProperty<number>;
  vacationBalanceLastPayRun: number;
  overtimeBalanceLastPayRun: number;
  gavBalanceLastPayRun: number;
  vacationMonthlyAllowance: number;
};

Versionierbare Attribute​

Einige Felder sind versionierbar, das heisst, ihr Wert kann sich über die Zeit ändern, und codeto plan oder codeto report müssen unter Umständen wissen, welcher Wert an einem bestimmten Datum gültig war. Ein versionierbares Feld sollte deshalb mit dem korrekten Gültigkeitszeitraum übermittelt werden, sofern das Quellsystem historische oder zukünftig datierte Änderungen unterstützt.

Jede Version wird durch ihr validFrom-Datum identifiziert. Dieses Datum definiert den ersten Tag, ab dem der Wert gilt. Das System berechnet die Gültigkeitsgrenzen automatisch aus der Reihenfolge der validFrom-Daten: Eine Version ist gültig ab ihrem validFrom bis zum Tag vor dem validFrom der nächsten Version oder unbegrenzt, falls keine spätere Version vorhanden ist.

Wechselt ein Mitarbeiter zum Beispiel am 2026-04-01 die Kostenstelle, sende die alte Kostenstelle als Version mit ihrem ursprünglichen validFrom und die neue Kostenstelle als zweite Version mit validFrom: "2026-04-01". Das System behandelt den alten Wert dann als gültig bis und mit 2026-03-31 und den neuen Wert ab dem 2026-04-01. So verwenden ältere Rapporte, Saldi, Planungseinträge und Archivdokumente weiterhin den Wert, der zum jeweiligen Zeitpunkt korrekt war.

Hinweis zu Datumskonventionen

Gültigkeitszeiträume versionierbarer Felder werden wie oben beschrieben aus den validFrom-Daten abgeleitet (der Gültigkeitszeitraum der vorherigen Version endet am Tag vor dem nächsten validFrom). Dies ist nicht dieselbe Konvention wie bei workingPeriods, wo das endDate inklusiv ist, siehe dazu den Abschnitt zu workingPeriods.

Mitarbeiter-Felder​

employeeId​

Eindeutige Kennung des Mitarbeiters im Quellsystem.

Verwende einen stabilen Wert, der sich über den Lebenszyklus des Mitarbeiters nicht ändert. codeto plan und codeto report erkennen denselben Mitarbeiter in späteren Ingests anhand dieses Bezeichners.

Der Wert muss in der gesamten Kundenumgebung global eindeutig sein.

Beispiele:

  • Verwende die Personalnummer aus den HR-Stammdaten, sofern sie auch nach Namens-, Abteilungs- oder Vertragsänderungen stabil bleibt.
  • E-Mail-Adressen eignen sich meist weniger gut, da sie sich nach Heirat, Rebranding oder Konto-Migrationen ändern können.

firstName​

Vorname des Mitarbeiters laut Rechtsdokumenten oder Quellsystem.

Dieser Name wird für Anzeige, Suche und Mitarbeiteridentifikation verwendet. In codeto plan können Benutzer einen separaten Anzeigenamen pflegen, der in einigen Ansichten stattdessen angezeigt wird. In codeto report bleibt der ingestete Vorname die massgebliche Quelle für Mitarbeiteranzeige und Rapporte.

firstName ist versionierbar: Sende jeden historischen Namen als eigene Version mit dem Datum, ab dem er wirksam wurde, sofern das Quellsystem Namensänderungen über die Zeit erfasst. Eine einzelne Version mit dem aktuellen Namen genügt, wenn keine Historie vorhanden ist.

Beispiele:

  • Wenn das Quellsystem den firstName am 2026-03-01 von Jon zu Jonathan ändert, sende den alten Wert mit seinem ursprünglichen validFrom und eine zweite Version mit value: "Jonathan" und validFrom: "2026-03-01".
  • Wenn codeto plan einen Anzeigenamen wie John pflegt, erscheint dieser Anzeigename in Planungsansichten, während codeto report weiterhin den ingesteten Vornamen verwendet.

lastName​

Nachname des Mitarbeiters laut Rechtsdokumenten oder Quellsystem.

Dieser Name wird zusammen mit dem Vornamen für Anzeige, Suche, Rapportansichten und archivierte Dokumente verwendet. Wie bei firstName kann codeto plan einen separaten Anzeigenamen unterstützen, während codeto report primär den ingesteten Wert verwendet.

lastName ist auf dieselbe Weise versionierbar wie firstName: Sende jeden historischen Nachnamen mit dem passenden validFrom, sofern das Quellsystem Namensänderungen erfasst (z. B. nach Heirat).

Beispiele:

  • Wenn sich der Nachname eines Mitarbeiters ändert, aktualisiere dieses Feld, damit zukünftige Rapportansichten und Archivdokumente den neuen Namen verwenden.
  • Halte historische Mitarbeiteridentifikatoren bei Namensänderungen stabil; lege keinen neuen Mitarbeiter an, nur weil sich der Nachname ändert.

username​

Login- oder Konto-Name des Mitarbeiters, falls vorhanden.

Dieses Feld wird zur Identifikation und für mögliche nachgelagerte Verwendung gespeichert. Es beeinflusst aktuell weder Planung, Reporting, Saldi noch Freigaben.

username ist versionierbar: Sende jedes historische Login als eigene Version mit dem Datum, ab dem es wirksam wurde, sofern das Quellsystem Login-Änderungen erfasst. Andernfalls genügt eine einzelne Version mit dem aktuellen Wert.

language​

Bevorzugte Sprache des Mitarbeiters.

Dieses Feld beeinflusst die mitarbeiterseitige Kommunikation, beispielsweise Benachrichtigungen. In codeto report steuert es zusätzlich die Sprache der Mitarbeiter-Archivdokumente. Liefere einen Wert, der zur Sprache passt, in der der Mitarbeiter offizielle oder operative Kommunikation erhalten soll.

Zulässige Werte sind de (Deutsch), fr (Französisch), it (Italienisch) und en (Englisch), gemäss der ISO-639-Konvention in Kleinbuchstaben.

Beispiele:

  • Verwende de für einen Mitarbeiter, der deutsche Benachrichtigungen und deutsche codeto report-Archivdokumente erhalten soll.
  • Verwende fr für einen Mitarbeiter in einer französischsprachigen Niederlassung, dessen offizielle Kommunikation auf Französisch erfolgen soll.

contracts​

Liste der Verträge des Mitarbeiters.

Damit ein Mitarbeiter in codeto plan und codeto report erscheint, benötigt er mindestens einen gültigen Vertrag. Verträge legen fest, wo der Mitarbeiter organisatorisch eingeordnet ist, wann er aktiv ist, wie die Arbeitszeit berechnet wird, welche Reporting-Regeln gelten und welche Saldi angezeigt werden.

Beispiele:

  • Ein Mitarbeiter mit einem laufenden Vertrag hat üblicherweise einen Vertragseintrag mit aktiver Arbeitsperiode.
  • Ein Mitarbeiter, der von einer Niederlassung in eine andere wechselte, kann zwei Verträge haben, jeweils mit eigener Niederlassung und Arbeitsperiode.
  • Ein Mitarbeiter, der das Unternehmen verlassen hat und später wieder eingetreten ist, kann separate Arbeitsperioden oder Verträge haben, je nachdem, wie das HR-System des Kunden den Wiedereintritt abbildet.

Vertragsfelder​

contractId​

Eindeutige Kennung des Vertrags.

Verwende einen stabilen Wert, der über alle Ingests desselben Vertrags hinweg gleich bleibt. codeto plan und codeto report nutzen die Vertragskennung, um Planungseinträge, Buchungen, Rapporte, Saldi, Freigaben und Archivdokumente dem korrekten Vertrag zuzuordnen. Eine Änderung koppelt neue Daten von der bisherigen Planungs- oder Reporting-Historie ab.

Der Wert muss in der gesamten Kundenumgebung global eindeutig sein, nicht nur pro Mitarbeiter.

Beispiele:

  • Verwende die HR-Vertragsnummer, sofern sie eindeutig ist und über Lohn- und Organisationsänderungen hinweg stabil bleibt.
  • Verwende dieselbe contractId nicht erneut für einen erneuerten Vertrag, wenn alter und neuer Vertrag separate Reporting- oder Saldo-Historien behalten sollen.

subsidiaryId​

Kennung der Niederlassung oder Geschäftseinheit, zu der der Vertrag gehört.

Dieses Feld ist eines der wichtigsten Scoping-Felder. Es bestimmt, welche Firmenkonfiguration für den Vertrag gilt, einschliesslich Arbeitszeitregeln, Feiertagskalendern, Rapporteinstellungen, Rundungsverhalten und Berechtigungsgrenzen.

In codeto plan beeinflusst die Niederlassung, wer den Mitarbeiter sehen oder bearbeiten kann und welcher organisatorische Arbeitszeitkontext verwendet wird. In codeto report steuert sie, wann der Mitarbeiter im Reporting erscheint, welche Regeln auf die Rapporte angewendet werden und welche Firmeninformationen auf Archivdokumenten erscheinen.

Beispiele:

  • Wechselt ein Mitarbeiter von Niederlassung CH01 zu CH02, ist dafür ein neuer Vertrag mit Bezug auf CH02 erforderlich. subsidiaryId ist nicht versionierbar, weshalb ein Niederlassungswechsel nicht als neue Version auf dem bestehenden Vertrag abgebildet werden kann.
  • Werden niederlassungsbasierte Berechtigungen verwendet, ist die zugewiesene Niederlassung Teil des Berechtigungskontexts.

costCenterIds​

Dem Vertrag zugewiesene Kostenstellen.

Verwende dieses Feld, um den Mitarbeiter oder den Vertrag einer oder mehreren Kostenstellen zuzuordnen. Diese Werte werden für Filter, kostenstellenspezifische Ansichten, Rapport-Auswertungen, Exporte und Archivdokumente verwendet.

Beispiele:

  • Weise eine einzelne Kostenstelle zu, wenn die Arbeit des Mitarbeiters einer einzigen Verrechnungseinheit zugeordnet ist.
  • Weise mehrere Kostenstellen zu, wenn das Reporting-Setup des Kunden den Vertrag in mehr als einem Kostenstellenfilter sichtbar erwartet.
  • Aktualisiere den Wert, wenn der Mitarbeiter in eine andere Verrechnungseinheit wechselt, damit zukünftige Rapporte und Exporte die korrekte Zuordnung verwenden.

employmentLevel​

Beschäftigungsgrad des Vertrags, üblicherweise von 0 bis 100.

Dieser Wert wird als Vertragsmetadatum angezeigt und kann zum Filtern oder Gruppieren von Mitarbeitern verwendet werden. Er repräsentiert den vereinbarten Beschäftigungsgrad. Für Arbeitszeit- und Reporting-Berechnungen sind die tatsächlich erwarteten Stunden je Wochentag in workingPattern zu liefern. Das übermittelte Arbeitsmuster wird nicht anhand des Beschäftigungsgrads normalisiert.

Beispiele:

  • Ein Vollzeit-Mitarbeiter wird typischerweise mit 100 übermittelt.
  • Ein 60%-Mitarbeiter wird typischerweise mit 60 übermittelt, während workingPattern weiterhin die tatsächlich erwarteten Stunden je Wochentag enthalten soll.

apprenticeshipYear​

Lehrjahr des Mitarbeiters, sofern relevant.

Dieses Feld wird als Vertragsmetadatum gespeichert. Es beeinflusst aktuell weder das Verhalten von codeto plan noch von codeto report, kann aber für Anzeige, Exporte oder zukünftige Integrationen nützlich sein.

salaryType​

Lohnkategorie des Vertrags.

Zulässige Werte sind S für Stundenlohnempfänger und M für Monatslohnempfänger.

Das Feld unterscheidet zwischen Stunden- und Monatslohnempfängern. Es ist vor allem in codeto report relevant:

  • Stundenlohnempfänger können bei Feiertagen, Saldi und Absenzvalidierung unterschiedlich behandelt werden;
  • Monatslohnempfänger sollen in der Regel den konfigurierten Sollstunden und Reporting-Regeln folgen.

Das Planungsverhalten von codeto plan wird durch dieses Feld aktuell nicht verändert.

Beispiele:

  • Verwende S für Mitarbeiter, deren Feiertage und Saldi den Regeln für Stundenlohnempfänger folgen sollen.
  • Verwende M für Mitarbeiter, deren Rapporte gegen reguläre Sollstunden geprüft werden sollen.

roleId​

Dem Vertrag zugewiesene Rolle.

In codeto plan hilft die Rolle bei der Klassifizierung von Mitarbeitern in Planungsansichten und kann beeinflussen, welche Mitarbeiter in rollenbasierten Auswahlen erscheinen. In codeto report wird die Rolle als Vertragsinformation in rapportbezogenen Ansichten und Dokumenten angezeigt.

Dieses Feld bestimmt nicht für sich alleine das Routing der Rapport-Freigaben. Das Freigabeverhalten hängt von den konfigurierten Reporting- und Projektverantwortlichkeiten des Kunden ab.

Beispiele:

  • Weise eine Rolle wie Projektleiter oder Bauführer zu, wenn codeto plan den Mitarbeiter in rollenbasierten Planungsauswahlen berücksichtigen soll.
  • Aktualisiere die Rolle ab dem Stichtag, wenn ein Mitarbeiter die Funktion wechselt, damit Planungs- und Rapportansichten die korrekte aktuelle Rolle anzeigen.

employeeCategory​

Kundenspezifische Mitarbeiterkategorie.

Dieses Feld wird als Vertragsmetadatum gespeichert. Es ändert aktuell weder das Verhalten von codeto plan noch von codeto report direkt, kann aber für Exporte, Klassifizierung oder zukünftige Filter nützlich sein.

workingPattern.monday bis workingPattern.sunday​

Erwartete Arbeitsstunden je Wochentag.

Dies ist die zentrale Feldgruppe für die Berechnung der Sollstunden. Liefere die tatsächlich erwartete Arbeitszeit je Wochentag für diesen Vertrag, also den vereinbarten Plan, wie er Tag für Tag erscheinen soll. Skaliere diese Werte nicht mit employmentLevel; sie werden so verwendet, wie sie geliefert werden, und nicht normalisiert. Arbeitet ein Teilzeit-Mitarbeiter zum Beispiel vier Stunden am Montag, soll der Montagswert vier Stunden betragen, nicht der Vollzeit-Standardwert des Unternehmens.

In codeto plan beeinflusst das Arbeitsmuster die Auslastung und richtlinienbezogene Berechnungen. Es verändert nicht zwingend jede Planungskalender-Ansicht visuell, da einige Kalenderdarstellungen auf den Arbeitszeit-Einstellungen der Niederlassung basieren.

In codeto report bestimmt das Arbeitsmuster die erwarteten Stunden, Rapport-Auswertungen, Freigabewarnungen, Überzeit- oder GAV-bezogene Prüfungen, Summen in Archivdokumenten und ob Tage als Arbeitstage gelten.

Beispiele:

  • Ein Vollzeit-Wochenmuster könnte Montag bis Freitag 8, Samstag 0, Sonntag 0 lauten.
  • Ein 60%-Mitarbeiter, der Montag, Dienstag und Donnerstag arbeitet, könnte als 8, 8, 0, 8, 0, 0, 0 übermittelt werden.
  • Bei einem Mitarbeiter, der nie mittwochs arbeitet, kann der Mittwoch auf 0 gesetzt werden.

workingPeriods​

Zeiträume, in denen der Vertrag aktiv ist.

Jede Arbeitsperiode hat ein startDate und ein inklusives endDate. Die Perioden definieren, wann der Mitarbeiter geplant werden kann, wann Rapporte erwartet werden und welcher Vertrag für ein bestimmtes Datum gilt.

In codeto plan legen Arbeitsperioden die Datumsbereiche fest, in denen der Mitarbeiter auf der Planungs-Timeline verfügbar ist und Buchungen erhalten kann.

In codeto report bestimmen Arbeitsperioden, ob Rapporte für eine Woche erstellt oder angezeigt werden, welcher Vertrag den Rapport erhält, welche Niederlassungs-Konfiguration gilt und welche Firmeninformationen in Archivdokumenten erscheinen.

Verwende separate Perioden, wenn der Mitarbeiter zwischen zwei aktiven Vertragsphasen inaktiv sein soll.

Beispiele:

  • Ein laufender Vertrag kann ein startDate und kein sinnvolles Ende jenseits des aktiven Beschäftigungsverhältnisses haben, abhängig vom mit dem Kunden vereinbarten Ingest-Format.
  • Ein Vertrag, der vom 2026-01-01 bis 2026-06-30 aktiv ist, soll den Mitarbeiter nur innerhalb dieses Zeitraums planbar und rapportierbar machen.
  • Pausiert das Beschäftigungsverhältnis für einen unbezahlten Urlaub, verwende separate Perioden nur dann, wenn der Mitarbeiter während der Lücke nicht geplant oder zur Rapportierung erwartet werden soll.

Lohnkomponenten-Felder​

salaryComponents.controllingCode​

Controlling- oder Buchhaltungs-Code des Vertrags.

Dieses Feld wird für nachgelagerte Finanz-, Buchhaltungs-, Export- oder Integrationszwecke gespeichert. Es ändert aktuell weder das Verhalten von codeto plan noch von codeto report. Es kann ausgehende Payloads beeinflussen, die Finanz- oder Controlling-Informationen enthalten.

Beispiele:

  • Verwende den Controlling-Code, den der Lohn-, ERP- oder Finanzexport des Kunden erwartet.
  • Aktualisiere den Wert, wenn sich die Finanz-Zuordnung ändert und zukünftige Exporte den neuen Code verwenden sollen.

salaryComponents.billingRate​

Verrechnungssatz des Vertrags.

Dieses Feld wird für nachgelagerte Verrechnungs-, Buchhaltungs-, Export- oder Integrationszwecke gespeichert. Es ändert aktuell weder das Verhalten von codeto plan noch von codeto report. Es kann ausgehende Payloads beeinflussen, die Verrechnungs- oder Tarifinformationen enthalten.

Beispiele:

  • Liefere den Stunden- oder Vertragssatz, den nachgelagerte Verrechnungs-Exporte erhalten sollen.
  • Aktualisiere den Wert ab dem Stichtag einer Tarifänderung.

salaryComponents.overtimePayCode​

Code, der angibt, ob die Überzeitbehandlung für den Vertrag aktiviert ist. Numerische Werte kleiner als 5 aktivieren die Überzeitbehandlung; Werte von 5 oder grösser deaktivieren sie.

codeto report nutzt diese Information, um zu entscheiden, ob überzeitbezogene automatische Zuschläge, Warnungen oder Saldoverhalten angewendet werden. Ein Wert, der die Überzeit deaktiviert, kann den Mitarbeiter in einen anderen Reporting-Modus überführen, in dem Abweichungen von den Sollstunden anders behandelt werden.

Das Planungsverhalten von codeto plan wird durch dieses Feld aktuell nicht verändert.

Beispiele:

  • Verwende einen Wert kleiner als 5 für Mitarbeiter, deren zusätzliche anrechenbare Arbeit zur Überzeitbehandlung in codeto report beitragen soll.
  • Verwende einen Wert von 5 oder grösser für Mitarbeiter, deren Sollstunden-Abweichungen nach den Nicht-Überzeit- oder Profit-Sharing-Regeln des Kunden behandelt werden sollen.

salaryComponents.billingRateMileage​

Kilometer-Verrechnungssatz des Vertrags.

Dieses Feld wird für nachgelagerte Verrechnungs-, Buchhaltungs-, Export- oder Integrationszwecke gespeichert. Es ändert aktuell weder das Verhalten von codeto plan noch von codeto report. Es kann ausgehende Payloads beeinflussen, die Kilometer-Verrechnung oder Spesen-Erstattung enthalten.

Beispiele:

  • Liefere den Kilometersatz, den der Verrechnungs- oder Spesen-Export des Kunden erwartet.
  • Aktualisiere den Wert, wenn sich der erstattete Kilometersatz ändert.

salaryComponents.vehicleBillingType​

Fahrzeug-Verrechnungskategorie. Zulässige numerische Werte sind:

  • 0: keine Fahrzeugverrechnung
  • 1: Verrechnung Privatfahrzeug
  • 2: Verrechnung Geschäftsfahrzeug

Dieses Feld wird für nachgelagerte Verrechnungs-, Buchhaltungs-, Export- oder Integrationszwecke gespeichert. Es ändert aktuell weder das Verhalten von codeto plan noch von codeto report.

Beispiele:

  • Verwende 1, wenn die Kilometer einem Privatfahrzeug zugeordnet werden sollen.
  • Verwende 2, wenn die Kilometer einem Geschäftsfahrzeug zugeordnet werden sollen.
  • Verwende 0, wenn keine Fahrzeugverrechnung angewendet werden soll.

salaryComponents.dailyAllowance​

Indikator, ob Tagespauschalen-Regeln für den Vertrag gelten.

codeto report verwendet diesen Wert, um zu entscheiden, ob tagespauschalenabhängige Zuschläge für diesen Vertrag generiert werden sollen.

Das Planungsverhalten von codeto plan wird durch dieses Feld aktuell nicht verändert.

Beispiele:

  • Aktiviere dieses Feld für Mitarbeiter, die tagespauschalenabhängige Zuschläge erhalten sollen, wenn ihre Rapporte die konfigurierten Bedingungen erfüllen.
  • Deaktiviere es für Mitarbeiter, die diese Zuschläge nie erhalten sollen, selbst wenn andere rapportierte Arbeitsbedingungen zutreffen.

salaryComponents.vacationBalanceLastPayRun​

Aus dem letzten Lohnlauf übernommener Feriensaldo, ausgedrückt in Stunden.

Dies ist der Ausgangspunkt für die Feriensaldo-Berechnungen in codeto report. codeto report fügt spätere Ferienbezüge, Korrekturen und Ansprüche auf diesen Basiswert hinzu.

codeto plan zeigt oder berechnet aktuell keine Feriensaldi.

Beispiele:

  • Wenn der Lohnlauf mit 42 verbleibenden Ferienstunden abgeschlossen wurde, sende 42 als Übertrag, damit codeto report mit diesem Saldo startet.
  • Falls vor dem Cutover bereits eine Korrektur im Lohn angewendet wurde, sende den korrigierten Reststand und nicht den Wert vor der Korrektur.

salaryComponents.overtimeBalanceLastPayRun​

Aus dem letzten Lohnlauf übernommener Überzeitsaldo, ausgedrückt in Stunden.

Dies ist der Ausgangspunkt für die Überzeitsaldo-Berechnungen in codeto report. Spätere rapportierte Arbeit, Kompensationen und Anpassungen werden relativ zu diesem Basiswert berechnet.

codeto plan zeigt oder berechnet aktuell keine Überzeitsaldi.

Beispiele:

  • Wenn der Lohnlauf mit 10.5 Überzeitstunden abgeschlossen wurde, sende 10.5 als Start-Überzeitsaldo.
  • Wenn der Mitarbeiter vor dem Cutover die gesamte Überzeit kompensiert hatte, sende 0.

salaryComponents.gavBalanceLastPayRun​

Aus dem letzten Lohnlauf übernommener GAV-Saldo, ausgedrückt in Stunden.

Dies ist der Ausgangspunkt für die GAV-Saldo-Berechnungen in codeto report, sofern eine GAV-Verfolgung gilt. Spätere relevante Ereignisse und Anpassungen werden relativ zu diesem Basiswert berechnet.

codeto plan zeigt oder berechnet aktuell keine GAV-Saldi.

Beispiele:

  • Sende den GAV-Saldo aus dem letzten Lohnlauf, wenn der Mitarbeiter der GAV-Verfolgung unterliegt.
  • Sende 0, wenn der Lohnlauf zum Cutover-Zeitpunkt keinen verbleibenden GAV-Saldo aufweist.

salaryComponents.vacationMonthlyAllowance​

Monatlicher Ferienanspruch, ausgedrückt in Stunden.

codeto report verwendet diesen Wert zur Berechnung des Ferienanspruchs über die Zeit, einschliesslich pro-rata-Hochrechnungen für den verbleibenden Jahresverlauf basierend auf den aktiven Arbeitsperioden des Mitarbeiters. Falsche Werte beeinflussen Feriensaldi, projizierten Ferienanspruch, Saldo-Auswertungen und Feriendetails in codeto report.

codeto plan zeigt oder berechnet aktuell keine Ferienansprüche.

Beispiele:

  • Wenn der Mitarbeiter 14 Ferienstunden pro Monat erwirbt, sende 14.
  • Sende für einen Teilzeit-Mitarbeiter den bereits pro-rata berechneten monatlichen Anspruch, sofern das Lohnsystem des Kunden den Anspruch so berechnet.
Letztes Update am