Working Contracts Parameters – User Manual

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 (Annual Vacation Entitlement)

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: (individually defined per Working Contract)

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: No

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

Example:
If set to Yes, remaining vacation can be taken during the defined carryover period.
If set to No, unused vacation expires at the end of the year.

---

Start of Carryover Phase (Beginning of Carryover Phase)

Technical Name: A_CO_PHASE_START
Type: Date
Default Value: (individually defined per Working Contract)

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: (individually defined per Working Contract)

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: No

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

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

---

Min Number of Vacation Days (Minimum Number of Vacation Days)

Technical Name: A_MIN_VACATION_DURATION
Type: Number (days)
Default Value: (individually defined per Working Contract)

Description:
Defines the minimum number of working days that must be taken as vacation.

Example:
Value 2 → Vacation must be at least 2 days long.

_______________________________________________________________________________

Min Days to Apply for Vacation (Minimum Advance Notice for Vacation Requests)

Technical Name: A_MIN_DAYS_BEFORE_VACATION_APPLY
Type: Number (days)
Default Value: (individually defined per Working Contract)

Description:
Defines how many working days in advance an employee must submit a vacation request.
This prevents spontaneous vacation requests that could lead to short-term staffing shortages

Example:
Value 10 → Vacation can only be requested at least 10 working days in advance.

_________________________________________________________

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

Technical Name: A_MAX_VACATION_DURATION
Type: Number (days)
Default Value: (individually defined per Working Contract)

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.

_______________________________________________________________________________

Can Take Absence Without Approval (Vacation without approval)

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

Description:
Defines whether an employee can take vacation without requiring approval.

Example:
If Yes → the employee can take vacation without approval.

_______________________________________________________________________________

Department Leader Direct Absence Input (Vacation Input from Departement Leader)

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

Description:
Defines whether a department leader is allowed to directly enter absences for employees.
(This applies to all types of absences.)

Example:
If Yes → the department leader can enter absences for employees.

______________________________________________________________________

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: No

Description:

Defines whether a reason from a predefined list must be selected when recording a sick day.

Example:
If set to Yes → the employee must specify a reason, e.g., cold or accident.
If set to No → selecting a reason is optional.

_______________________________________________________________________________

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: No

Description:

Defines whether a reason from a predefined list must be provided when requesting special leave.

Example:
If set to Yes → specifying a reason is required (e.g., wedding, birth of a child, relocation).
If set to No → the request can be submitted without a reason.

_______________________________________________________________________________

Minimum Number of Special Leave Days (Minimum Number of Days for Special Leave request)

Technical Name: A_MIN_SPECIAL_ABSENCE_DURATION
Type: Days
Default Value: (individually defined per Working Contract)

Description:
Defines the minimum number of consecutive days that must be requested for special leave.

Example:
Value 2 → At least 2 days must be requested.

_______________________________________________________________________________

Maximum Number of Special Leave Days (Maximum Number of Days for Special Leave request)

Technical Name: A_MAX_SPECIAL_ABSENCE_DURATION
Type: Days
Default Value: 0

Description:
Defines the maximum number of consecutive days that may be requested for special leave.

Example:
Value 2 → Maximum of 2 days may be requested at once.

_______________________________________________________________________________

Minimum Number of Days Ahead to Take Special Leave (Minimum Number of Days ahead for Special Leave request)

Technical Name: A_MIN_DAYS_BEFORE_SPECIAL_ABSENCE_APPLY
Type: Days
Default Value: 0

Description:
Defines how many days in advance special leave must be requested.

Example:
Value 10 → The request for special leave must be submitted at least 10 days in advance.

---

Special Leave Approval Process Required

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

Description:
This parameter defines whether special leave requests require a multi-step approval process.
When set to “Yes”, 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 “No”, 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.