Automation

Payroll Automation

Case Actions (No-Code)

Case Actions are comparable to Excel functions and offer various functions to control user input and validate data.

In the example Basic Payroll the wage value is to be narrowed down between 500 and 25'000:

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  ]

The following enhancements have been introduced to control data entry:

• 05: The case field build Action BuildExpression is active so that Case Field Build Actions are considered.
• 12-14: The case field build Action Limit(min,max) is used.

The following adjustments have been made for case validation:

• 06: The case ValidateExpression is active so that Case Field Validate Actions are taken into account.
• 15-17: The case field validation action ValueBetween(min,max) is used.

The build actions increase usability, but the validate actions are more important as they ensure the validity of the data.

In addition to a large number of predefined actions, user-defined actions are also possible, e.g. for formatting and validating a policy number. The Payroll Console offers the possibility to list the actions of a regulation assembly with the command ActionReport.

Read the article No-code and low-code development for payroll providers.

Scripting

The runtime behaviour of cases, payruns and reports is controlled by scripts. The scripts are written in C# and offer the following functionalities:

• Access to backend data such as reguaktion lookup, case values and payroll results.
• Use of time data calculations.
• Scripts for user-defined actions (see above).
• Scripts are able to query the data of a webhook.
• With the regulation object Script, business functions are centrally managed and shared.
• Scripts are compiled during object creation (POST/PUT) and offer good runtime performance.
• Scripts can be programmed and tested in modern development environments (debug support for case and report scripts).

Case Scripting

Case scripts control user input and validate case data before it is stored in the backend:

• Provide case availability: Case Available.
• Build and update the case: Case Build and Case Relation Build
  The case is initially built and updated whenever data changes.
• Check and validate the case: Case Validate and Case Relation Validate.

Payrun Scripting

Payrun Scripts are integrated into the payroll processing sequence:

• Determine availability of employee: Employee Available.
• Start payrun: Payrun Start.
• For each employee
  • Start employee: Employee Start
  • Start collector: Collector Start.
  • For each wage type
    • Determine wage type availability for the employee: Wage Type Availability
    • Calculate the value of the wage type: Wage Type Value
    • Determine additional wage type results: Wage Type Result
    • Consolidate wage type value: Collector Apply
  • End collector: Collector End
  • End employee: Employee End
• End payrun: Payrun End

The following aspects must be considered for the payrun scripts:

• With the exception of the Wage Type Value script, all scripts are optional.
• Collectors are used to consolidate the Wage Type Results, e.g. for wage bases.
• Processing data can be determined for the payroll run (PayrunRuntime) or employee (EmplyoRuntime) and saved at the end of the sequence as attributes or results (PayrunTesult).
• Payruns can be restarted so that a wage type can be calculated more than once.
• Payruns can be performed automatically (case value start date) or explicitly (Scripting).

Report Scripting

The report scripts are:

• Create and update report parameters: Report Build
  The report parameters are initially created and updated with every data change.
• Start of report generation: Report Start
• End of report generation: Report End.

Regulation Sharing

Regulation sharing is the sharing of regulations between tenants.

The Regulation Share contains the following values:

• Provider Tenant: The provider of the regulation.
• Provider Regulation The shared regulation of the provider (must be marked as SharedRegulation).
• Consumer Tenant: The user of the regulation.
• Consumer Division: The division of the user (optional restriction).

The user of the settlement can reference the split settlement in a payroll layer.

Changes to shared regulations are critical and should have a new effective date (see Regulation Versioning).

Example regulation share:

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

Regulation Versioning

The regulation is a container for external business data with a validity date ValidFrom, from which time the data is valid. Future updates can set a validity date in the future with the same regulation name. This validity history grants the correct time data for retrospective payroll calculations.

The validity date of the regulation must correspond to the Payroll Calendar Periods.

See also

• Resources with documents, blogs, tests and examples