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 constrained 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 BuildExpression is active so that case field build actions are evaluated.
• 12-14: The case field build action Limit(min, max) is applied.

The following adjustments have been made for case validation:

• 06: The case ValidateExpression is active so that case field validate actions are evaluated.
• 15-17: The case field validation action ValueBetween(min, max) is applied.

Build actions improve usability, but validate actions are more important as they enforce data validity.

In addition to the large number of predefined actions, custom actions are also possible — for example, to format and validate a policy number. The Payroll Console can list all actions of a regulation assembly using the command ActionReport.

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

Scripting

The runtime behavior of cases, payruns and reports is controlled by scripts. Scripts are written in C# and provide the following capabilities:

• Access to backend data such as regulation lookups, case values and payroll results.
• Use of time data calculations.
• Implementation of custom actions (see above).
• Querying webhook data within scripts.
• Central management and reuse of business functions via the regulation object Script.
• Compilation at object creation time (POST/PUT) for good runtime performance.
• Development and debugging in modern IDEs (debug support for case and report scripts).

Scripting Functions

A function is a programmed sequence invoked by an engine process at a specific point. The available scripting functions are:

Object	Function	Description	Type	Override
Case	Available	Test whether a case is available	bool?	Top-Down
Case	Build	Build a case	bool?	Top-Down
Case	Validate	Test whether a case is valid	bool?	Top-Down
CaseRelation	Build	Build a case relation	bool?	Top-Down
CaseRelation	Validate	Test whether a case relation is valid	bool?	Top-Down
Payrun	Start	Payrun start	bool?	—
Payrun	EmployeeAvailable	Test whether the employee is available	bool?	—
Payrun	EmployeeStart	Payrun employee start	bool?	—
Payrun	WageTypeAvailable	Test whether a wage type is available	bool?	—
Payrun	EmployeeEnd	Payrun employee end	—	—
Payrun	End	Payrun end	—	—
Collector	Start	Collector start	—	Top-Down
Collector	Apply	Apply wage type value to collector	decimal?	Top-Down
Collector	End	Collector end	—	Top-Down
WageType	Value	Calculate wage type value	decimal?	Top-Down
WageType	Result	Determine wage type results	—	Bottom-Up
Report	Build	Build report	bool?	—
Report	Start	Start of report generation	—	—
Report	End	End of report generation	—	—

Top-Down override: the first function that returns a non-null value is used. When null is returned, the function from the next underlying regulation layer is executed.

Bottom-Up override: values are merged starting from the lowest regulation layer, with higher-level regulations able to override individual entries.

The built-in functions can be extended via scripts using C# Extension Methods or Partial Classes.

Case Scripting

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

• Determine case availability: Case Available.
• Build and update the case: Case Build and Case Relation Build
  The case is initially built and re-evaluated whenever data changes.
• Validate the case: Case Validate and Case Relation Validate.

Payrun Scripting

Payrun scripts are integrated into the payroll processing sequence:

• Determine employee availability: 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: Wage Type Available
    • Calculate the wage type value: 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 apply to payrun scripts:

• All scripts except Wage Type Value are optional.
• Collectors consolidate wage type results, e.g. for wage bases.
• Processing data can be accumulated per payrun (PayrunRuntime) or per employee (EmployeeRuntime) and saved at the end of the sequence as attributes or results (PayrunResult).
• Payruns can be restarted so that a wage type is calculated more than once.
• Payruns can be triggered automatically (via case value start date) or explicitly via scripting.

Report Scripting

The report scripts are:

• Create and update report parameters: Report Build
  Report parameters are initially created and re-evaluated with every data change.
• Start report generation: Report Start
• Finalize report generation: Report End

Regulation Sharing

Regulation sharing enables regulations to be shared between tenants.

The Regulation Share contains the following values:

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

A consumer tenant can reference a shared regulation as a layer in its payroll.

Changes to shared regulations are critical and should be introduced with 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

A regulation contains a validity date ValidFrom from which the data becomes effective. Future updates can set a validity date in the future using the same regulation name. This validity history ensures correct time data for retroactive payroll calculations.

The validity date of the regulation must align with the payroll Calendar Periods. See Regulation Design for versioning guidelines.

See also

• Regulations
• Regulation Design
• Extended Functions
• Resources with documents, blogs, tests and examples