CaseModel

Case Model

The Payroll Engine categorizes cases into one of four categories.

1. Employees
2. Companies
3. National
4. Global

Each area has its own API endpoints and database tables. The procedure for determining company and employee cases is outlined below.

Case Fields

The Case object is used to capture case data. The CaseField object represents an input field within a case. The CaseRelation object defines the relationship (availability and value transfer) between two cases.

When capturing the case value, its validity period is set with a date range (start/end). This enables the representation of complex business scenarios, such as the cancellation of prior mutations or the scheduling of salary adjustments (see Time Types). This property distinguishes the Payroll Engine fundamentally from conventional software solutions that typically overwrite existing data.

The engine offers several approaches for composing cases and their fields:

• Local Case Fields — Fields declared directly within the case as an integral part
• Derived Case Fields — Fields inherited from a base case
• Explicit Case Fields — Fields explicitly included from reference cases

The following overview shows possible case field compositions, which can also be combined:

Case Slots

To store multiple records for a single case (e.g. children or addresses), each variant is assigned to a case slot with a unique name. Case slots enable the same case structure to be reused for multiple independent data records.

Case Data

For each case field, a value (Case Value) can be recorded through a case change (Case Change). Case data is stored physically separated by scope:

Object	Description
Global Case Value	Global data
Global Case Document	Global documents
National Case Value	National data
National Case Document	National documents
Company Case Value	Company data
Company Case Document	Company documents
Employee Case Value	Employee data
Employee Case Document	Employee documents

A case value can optionally be available for all divisions or restricted to a specific division. The definition is done in the case field of the regulation.

Case data is immutable and is supplemented by case changes. Based on this change history, the data for any payroll period can be determined.

The case types can be used in regulations as follows:

Regulation \ Case Type	Global	National	Company	Employee
Tenant	✓	✓	✓	✓
Business	✓	✓	✓	✓
National	✓	✓
Global	✓

Canceling Case Data

For cases that allow cancellations, the reset behavior for numeric case values is controlled by the cancellation type:

• Restore previous value
• Initialize value to default
• Invert the value
• Retain the value

Company Cases

The cases assigned to a company must be identified.

• Legally required company data
• Data shared across employees
• Data related to business partners (insurance conditions, etc.)
• Subdivide use cases, e.g., by
  • Actor
  • Business partners
  • Company regulations
• Per case
  • Determine case fields with data type and time type
  • Determine rules for availability and validation

The following example shows two business cases:

"regulations": [
  {
    "name": "RegulationName",
    "updateMode": "NoUpdate",
    "cases": [
      {
        "name": "Company",
        "caseType": "Company",
        "fields": [
          {
            "name": "CompanyId",
            "valueType": "String",
            "timeType": "Calendar"
          }
        ]
      },
      {
        "name": "CompanyInsurance",
        "caseType": "Company",
        "fields": [
          {
            "name": "CompanyInsurancePlan",
            "valueType": "Integer",
            "timeType": "Calendar"
          }
        ]
      }
    ]
  }
]

Case availability and validation is performed using Actions.

Employee Cases

The employee's cases during his time of employment should be identified.

• Legally required employee data
• Wage-related cases
• Subdivide use cases, e.g., by
  • Partner
  • Children
  • Pension plan
  • Benefits
• Per case
  • Determine case fields with data type and time type
  • Determine rules for availability and validation

The following example shows the cases for the employee and his partner:

"regulations": [
  {
    "name": "RegulationName",
    "updateMode": "NoUpdate",
    "cases": [
      {
        "name": "Employee",
        "caseType": "Employee",
        "fields": [
          {
            "name": "EmployeeIdentifier",
            "valueType": "String",
            "timeType": "Calendar"
          },
          {
            "name": "EmployeeFirstName",
            "valueType": "String",
            "timeType": "Calendar"
          },
          {
            "name": "EmployeeLastName",
            "valueType": "String",
            "timeType": "Calendar"
          },
          {
            "name": "EmployeeSalary",
            "valueType": "Money",
            "timeType": "Calendar"
          }
        ]
      },
      {
        "name": "EmployeeAddress",
        "caseType": "Employee",
        "fields": [
          {
            "name": "EmployeeAddressCity",
            "valueType": "String",
            "timeType": "Calendar"
          }
        ]
      },
      {
        "name": "EmployeePartner",
        "caseType": "Employee",
        "fields": [
          {
            "name": "EmployeePartnerFirstName",
            "valueType": "String",
            "timeType": "Calendar"
          },
          {
            "name": "EmployeePartnerLastName",
            "valueType": "String",
            "timeType": "Calendar"
          }
        ]
      },
      {
        "name": "EmployeePartnerAddress",
        "caseType": "Employee",
        "fields": [
          {
            "name": "EmployeePartnerAddressCity",
            "valueType": "String",
            "timeType": "Calendar"
          }
        ]
      }
    ]
  }
]

Next Steps

• Regulation Design guidelines
• Lookups design guidelines
• Payrun Model design guidelines