Automation

Payroll Automation

---

Case Actions (No-Code)

Case Actions sind vergleichbar mit Excel-Funktionen und bieten diverse Funktionen zu Steuerung der Benutzereingaben und zur Datenvalidierung.

Im Beispiel Basic Payroll soll der Lohnwert zwischen 500 und 25'000 eingegrenzt werden:

01  "cases": [
02    {
03      "name": "Salary",
04      "caseType": "Employee",
05      "buildExpression": "true",
06      "validateExpression": "true",
07      "fields": [
08        {
09          "name": "Salary",
10          "valueType": "Money",
11          "timeType": "CalendarPeriod",
12          "buildActions": [
13            "Limit(500, 25000)"
14          ],
15          "validateActions": [
16            "ValueBetween(500, 25000)"
17          ]
18        }
19      ]
20    }
21  ]

Für die Steuerung der Dateneingabe wurden folgende Erweiterungen eingeführt:

• 05: Die Case BuildExpression ist aktiv damit Case Field Build Actions berücksichtigt werden
• 12-14: Die Case Field Build Action Limit(min,max) verwendet

Für die Steuerung der Validierung des Case wurden folgende Anpassungen gemacht:

• 06: Die Case ValidateExpression ist aktiv damit Case Field Validate Actions berücksichtigt werden
• 15-17: Die Case Field Validation Action ValueBetween(min,max) verwendet

Die Build-Actions steigern die Benutzerfreundlichkeit, jedoch sind die Validate-Actions wichtiger, da sie gültige Daten gewährleisten.

Neben einer Vielzahl vordefinierter Actions sind auch benutzerdefinierte Actions möglich wie z.B. für das Format und Validierung einer Versicherungsnummer. Die Payroll Konsole bietet mit dem Kommando ActionReport die Möglichkeit, die Actions eines Regulation-Assemblies zu listen.

Read the Blog No-code/low-code development platform for Payroll Providers

---

Scripting

Das Laufzeitverhalten von Cases, Payruns und Reports wird mit Scripts gesteuert. Scripts werden in C# geschrieben und bieten folgende Features:

• Zugriff auf die Backend-Daten wie Regulation-Lookups, Case-Values und Payroll-Results
• Nutzung von Zeitdaten-Berechnungen
• Scripts für benutzerdefinierte Actions (siehe oben)
• Scripts sind in der Lage die Daten eines Webhooks abzurufen
• Mit dem Regulierungs-Objekt Script werden Business-Funktionen zentralisiert geführt und geteilt
• Scripts werden bei der Objekterstellung (POST/PUT) compiliert und bieten ein gute Laufzeitperformance
• Scripts können in modernen Entwicklungsumgebungen codiert und gestetet werden (Debug-Support für Case- und Report-Scripts)

Case Scripting

Die Case Scripts steuern die Benutzeriengabe und Validieren die Falldaten bevor diese im Backend gespeichert werden:

• Die Case Verfügbarkeit bereitstellen: Case Available
• Den Case aufbauen und aktualisieren: Case Build und Case Relation Build
  Der Case wird initial erstellt und bei jeder Datenänderung aktualisiert
• Den Case überprüfen und bestätigen: Case Validate und Case Relation Validate

Payrun Scripting

Die Payrun Scripts werden in der Sequenz der Lohnverarbeitung eingebunden:

• Mitarbeiter Verfügbarkeit bestimmen: Employee Available
• Start des Lohnlaufes: Payrun Start
• Für jeden Mitarbeiter
  • Start des Mitarbeiter: Employee Start
  • Collector Start: Collector Start
  • Für jede Lohnart:
    • Lohnart Verfügbarkeit für den Mitarbeiter bestimmen: Wage Type Available
    • Wert der Lohnart berechnen: Wage Type Value*
    • Lohnart Zusatzergebnisse bestimmen: Wage Type Result
    • Lohnart Wert konsolieren: Collector Apply
  • Collector Ende: Collector End
  • Ende des Mitarbeiters: Employee End
• Ende des Lohnlaufes: Payrun End

Bei den Payrun-Scripts sind folgende Aspekte zu beachten:

• Mit Ausnahme vom Script Wage Type Value sind alle Scripts optional
• Kollektoren dienen der Konsolidierung der Wage Type Results, z.B. für Lohnbasen
• Vearbeitungsdaten können für den Lohlauf (PayrunRuntime) oder Mitarbeiter (EmplyeooRuntime) bestimmt und am Sequenzende als Attribute oder Resultate (PayrunTesult) gespeichert werden
• Lohnläufe können neu gestartet werden, so dass eine Lohnart mehrmals berechnet werden kann
• Lohn-Rückläufe können automatisch (Statdatum Case Value) oder explizit (Scripting) erfolgen

Report Scripting

Die Report Scripts sind:

• Reportparameter aufbereiten und aktualisieren: Report Build
  Die Report-Parammeter werden initial erstellt und bei jeder Datenänderung aktualisiert
• Beginn der Reporterstellung: Report Start
• Ende der Reporterstellung: Report End

---

Regulation Sharing

Mit dem Regulation Sharing werden Regulierungen zwischen Tenants geteilt:

Der Regulation Regulation Share beinhaltet folgende Werte:

• Provider Tenant: Der Anbieter der Regulation
• Provider Regulation: Die geteilte Regulation des Anbieters (muss als SharedRegulation markiert sein)
• Consumer Tenant: Der Anwender der Regulierung
• Consumer Division: Die Division des Anwenders (optionale Eingrenzung)

Der Anwender der Regulierung kann die geteilte Regulierung in einem Payroll Layer referenzieren.

Änderungen an geteilten Regulierungen sind kritisch und sollten ein neues Gültigkeitsdatum besitzen (siehe Regulation Versioning).

Beispiel Regulation Share:

01  "regulationShares": [
02    {
03      "providerTenantIdentifier": "StartTenant",
04      "providerRegulationName": "InsuranceRegulation",
05      "consumerTenantIdentifier": "OtherTenant"
06    }
07  ]

---

Regulation Versioning

Die Regulierung ist ein Container für externe Geschäftsdaten mit einem Gültigkeitsdatum ValidFrom, ab welchen Zeitpunkt die Daten gelten. Zukünftige Updates können mit dem selben Regulationnamen ein in der Zukunft liegendes Gültigkeitsdatum setzen. Diese Gültigkeitshistorie gewährt bei Lohnlauf-Rückrechnungen die korrekten Zeitdaten.

Das Gültigkeitsdatum der Regulierung muss mit dem Payroll Kalenderperioden übereinstimmen.

---

See also

• Payroll Engine Resources