Working Contracts Parameters – User Manual

This prompt automatically generates structured and clearly written manual entries for all parameters used in the Working Contracts within Can Do.

General Introduction

In Can Do, individual employees or entire groups can have specific agreements related to topics such as vacation, special leave, or sickness.
To represent these different regulations, each person is assigned a so-called Working Contract.

A Working Contract consists of a set of parameters that define exactly how the software behaves in specific situations — for example, when calculating vacation entitlements, handling sick days, or recording working hours.

These parameters are called Working Contracts Parameters.
They define the concrete conditions and rules according to which Can Do operates for an employee.

 

Vacation Days Per Year (Jahresurlaubsanspruch)

Technical Name: A_ANNUAL_VACATION_DAYS
Category: Absences – Regular Vacation
Type: Number (days)
Default Value: (individually defined per Working Contract)

Description:
This parameter defines how many vacation days an employee is entitled to per year.
The value is expressed in days and serves as the basis for calculating the annual vacation entitlement within the software.
The parameter determines how many days the employee can request as regular vacation within a calendar year.
Changes to this value directly affect the calculation of remaining vacation, carryover periods, and planning horizons.

Example:
An employee with 30 annual vacation days receives the value 30 in the parameter A_ANNUAL_VACATION_DAYS.

---

Number of Years Creating Annual Planning (Vacation Planning Horizon)

Technical Name: A_YEARS_TO_INITIALIZE
Type: Number (years)
Default Value: 3

Description:
Specifies how many years in advance the vacation planning is automatically generated.

Example:
Value 3 → planning includes the current year plus two subsequent years.

---

Carry-Over Phases Exist (Enable Carryover Phases)

Technical Name: A_CARRY_OVER_PHASES
Type: Boolean (Yes/No)
Default Value: True

Description:
Controls whether remaining vacation can be carried over into the new year.

Example:
True → remaining vacation can be taken until the end of the defined carryover phase.

---

Start of Carryover Phase (Beginning of Carryover Phase)

Technical Name: A_CO_PHASE_START
Type: Date
Default Value: 01.01.

Description:
Specifies when the period starts in which remaining vacation from the previous year can be used.

Example:
An employee can start using the previous year’s remaining vacation from January 1st.

---

End of Carryover Phase (End of Carryover Phase)

Technical Name: A_CO_PHASE_END
Type: Date
Default Value: 31.03.

Description:
Marks the end of the carryover phase. After this date, unused vacation from the previous year expires.

Example:
After March 31st, unused vacation from the previous year can no longer be requested.

---

Allow Absence Overbooking (Allow Vacation Overbooking)

Technical Name: A_ALLOW_ABSENCE_OVERBOOKING
Type: Boolean (Yes/No)
Default Value: False

Description:
Allows employees to request more vacation days than are available. When activated, a warning dialog with confirmation appears.

Example:
True → the employee can request more vacation days than available but will receive a warning message.

---

Min Number of Vacation Days (Minimum Lead Time for Vacation Requests)

Technical Name: A_MIN_VACATION_DURATION
Type: Number (days)
Default Value: 10

Description:
Defines the minimum number of working days that must be observed as lead time before submitting a vacation request.

Example:
If the minimum lead time is 10 days, a vacation request made only 5 days in advance will be rejected.

---

Maximum Vacation Duration in a Single Apply (Maximum Vacation Length per Request)

Technical Name: A_MAX_VACATION_DURATION
Type: Number (days)
Default Value: 15

Description:
Determines how many consecutive working days can be requested in a single vacation request.

Example:
If the value is 15, an employee can request a maximum of 15 consecutive working days of vacation.

---

Absences – Sickness

Sick Leave Reason Mandatory (Mandatory Sickness Reason)

Technical Name: A_SICK_LEAVE_REASON_MANDATORY
Category: Absences – Sickness
Type: Boolean (Yes/No)
Default Value: (e.g., False)

Description:
This parameter defines whether employees are required to select a sickness reason from a predefined list when entering a sick day.

If set to 'Yes' (True), the employee must choose an appropriate reason (e.g., cold, accident, medical appointment) from the predefined list before saving the sickness record.
The entry cannot be completed without a selected reason.

If set to 'No' (False), selecting a sickness reason is optional, and employees can record sick days without providing a reason.

Example:
When A_SICK_LEAVE_REASON_MANDATORY is set to True, an employee cannot save a sickness entry without selecting a reason from the list.
When False, the entry can be saved without any reason.

---

Absences – Special Leave

Special Leave Reason Mandatory (Mandatory Special Leave Reason)

Technical Name: A_SPECIAL_ABSENCE_REASON_MANDATORY
Category: Absences – Special Leave
Type: Boolean (Yes/No)
Default Value: (e.g., False)

Description:
This parameter defines whether employees must select a reason from a predefined list when applying for special leave.

If set to 'Yes' (True), providing a special leave reason is mandatory.
In that case, the employee must choose a predefined reason — for example, wedding, birth of a child, or relocation — before the application can be saved.

If set to 'No' (False), providing a reason is optional, and the application can be submitted without selecting one.

Example:
When A_SPECIAL_ABSENCE_REASON_MANDATORY is set to True, the employee must select a reason (e.g., "wedding") before saving the request.
When False, the request can be submitted without specifying a reason.

---

Special Leave Approval Process Required

Technical Name: A_SPECIAL_ABSENCE_APPROVAL_PROCESS_REQUIRED
Category: Absences – Special Leave
Type: Boolean (True/False)
Default Value: False

Description:
This parameter defines whether special leave requests require a multi-step approval process.
When set to “True”, the system activates the two-step approval workflow between the line manager and the HR department.
In this mode, the approval process for special leave differs from the standard approval process used for regular vacation requests.

If the parameter is set to “False”, special leave requests follow the same process as regular leave – with a single approval and no separation between HR and management roles.

When multi-step approval is enabled (“True”), the detailed behavior is defined by the following parameters:

• A_SPECIAL_ABSENCE_APPROVAL_OPERATOR → specifies the type of approval logic (Steps / AND / OR).

• A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1 and A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2 → define the approval sequence when the operator is set to Steps.

This parameter serves as the central switch determining whether special leave requires a simplified or an extended approval process, depending on data protection policies and internal procedures.

Example:
A company requires that special leave requests involving personal documents (e.g., a marriage certificate) go through a two-step approval process for data protection reasons.
Therefore, A_SPECIAL_ABSENCE_APPROVAL_PROCESS_REQUIRED is set to True, and the system applies the subsequent parameters to define the approval logic and sequence between HR and the line manager.

---

Special Leave Approval Operator

Technical Name: A_SPECIAL_ABSENCE_APPROVAL_OPERATOR
Category: Absences – Special Leave
Type: Selection (Steps | AND | OR)
Default Value: company-specific

Description:
This parameter defines how special leave requests are approved, particularly in companies that require a multi-step approval process for data protection reasons.

In some organizations, employees must attach personal documents when applying for special leave – for example, a marriage certificate or proof of relocation.
According to internal data protection policies, such documents may only be viewed by the HR department, not by the line manager.
To meet these requirements, the parameter allows for different approval logics.

Available Options:

• Steps (two-step process):
  The request is approved in two consecutive steps.
  First, one of the two instances (HR team or line manager) approves; then, the other one follows.
  The sequence of approvals (who approves first) is defined in another setting.
  This option is typically used when personal documents are involved that cannot be shared with all approvers.

• AND (both must approve):
  The request is considered fully approved only when both – the HR team and the line manager – have approved it.
  This ensures that both administrative and organizational checks are completed.

• OR (one approval is sufficient):
  The request is approved immediately once either the HR team or the line manager approves it.
  This option is suitable for organizations with simple approval processes where no sensitive data is handled.

Example:
An employee applies for special leave to get married and uploads their marriage certificate.

• With Steps: First, one instance (e.g., HR) approves; then, the other (e.g., manager). The request is confirmed only after both approvals.

• With AND: Both must approve; the request remains pending until both have confirmed.

• With OR: One approval is enough – the request is immediately approved.

---

Special Leave Approval Group Setting 1 / 2 (Approval Sequence for Special Leave)

Technical Name:
A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1
A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2

Category: Absences – Special Leave
Type: Number (1 = Line Manager, 2 = HR Department)
Default Value: company-specific

Description:
These two parameters define the order of approval for special leave requests when the operator is set to Steps (see parameter Special Leave Approval Operator).

In this two-step approval process, the request is reviewed consecutively by two parties – the line manager and the HR department.
The parameters A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1 and A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2 specify which group approves first and which one follows.

Functionality:

• The value 1 represents the line manager.

• The value 2 represents the HR department.

Both parameters must be configured to form a clear approval sequence:

• Example 1:

  • A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1 = 2

  • A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2 = 1
    → HR approves first, then the line manager.

• Example 2:

  • A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1 = 1

  • A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2 = 2
    → Line manager approves first, then the HR department.

This configuration allows each organization to tailor the approval workflow according to its internal processes or data protection requirements.

Example:
An employee applies for special leave for a wedding.
The system is set to operator Steps, and the parameters are configured as follows:

• A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_1 = 2

• A_SPECIAL_ABSENCE_APPROVAL_GROUP_SETTING_2 = 1
  → The request is first sent to the HR department for document verification, and then to the line manager for final approval.