External Absences Katarina Feature

Overview

External Absences is an Absence Management feature for using absence information received from an external system in AristoTelos.

The feature associates an externally received absence with the relevant employee and employee contract, and uses that information to create or update the related period time-off in the shift plan.

This documentation describes the business capability in general terms. The currently documented external source is the Czech eNeschopenka source. Source-specific behavior is identified explicitly as Czech eNeschopenka behavior and does not define the behavior of every possible external source.

Business purpose

External Absences provides the business process for receiving externally maintained absence information and reflecting it in employee absence management and shift planning.

The feature covers the relationship between:

an external absence record;
the employee and employee contract;
the related period time-off;
the shift plan;
attendance closing;
employee contract changes; and
downstream export processes.

When to use the feature

Use External Absences when absence information is received from an external system and must be reflected in the employee’s period time-off and shift plan.

The documented implementation applies to an external sickness-absence source. The source is currently eNeschopenka in the Czech implementation.

Business scenarios

An external absence is received

An external source provides a new absence record. AristoTelos stores the record, tries to identify the relevant employee contract, and creates the related period time-off when the documented conditions are met.

An external absence changes

An external source provides changed absence information. AristoTelos updates the stored external absence and evaluates whether the related period time-off must also change.

The employee cannot be identified

An external absence can be received before the relevant employee is available in AristoTelos. The absence remains available for later processing, and employee association is retried during later synchronization.

An Administrator can change the start, end, or absence type of a period time-off that originated from an external absence. A later automatic update does not overwrite the manually changed component.

Business process

An external source provides new or changed absence information.
AristoTelos identifies the external absence and tries to associate it with the relevant employee contract.
AristoTelos determines the related period time-off type.
AristoTelos creates or updates the external absence record.
AristoTelos creates, links, or updates the related period time-off where the documented rules allow it.
The shift plan reflects the resulting period time-off.
Changes that cannot be applied automatically remain available for review.

Business rules

An external absence belongs to the employee contract identified by the external employee identifier.
A person can have more than one employee contract. An absence associated with one contract does not automatically apply to another contract.
Changes to employee association, absence interval, and absence type can affect the related period time-off.
A manual Administrator change takes precedence over later automatic synchronization of the same component.
External absence information can be retained when the employee cannot yet be identified and can be processed later.

Preconditions and dependencies

External Absences depends on:

external absence information being available;
employee contracts being available for matching;
a corresponding period time-off type being available;
the employee shift plan being available for synchronization; and
employee-contract processing when the employee contract ends or is extended.

Inputs and outputs

Inputs

external absence identification;
employee or employee-contract identifier;
absence start and end information;
absence-category information; and
information used to determine the related period time-off type.

Outputs

created or updated external absence record;
employee association where the employee can be identified;
created or updated period time-off;
change in the shift plan; and
information, warning, or error about the processing result.

Impact on other business processes

Shift plan

A period time-off linked to an external absence is distinguishable in the shift plan.

Attendance closing

An absence without a supporting document can remain in attendance. During attendance closing, the Manager is informed that the absence will be exported as unpaid sickness.

Employee contract lifecycle

A period time-off linked to an external absence can end when the relevant employee contract ends. It can be extended again after an employee-contract extension where the documented synchronization conditions are met.

Shift-plan publishing

A period time-off linked to an external absence is not connected with an overlapping period time-off during shift-plan publishing.

Export

The documented implementation includes an adjustment of SAP export for the affected absence process.

Exceptions and special cases

The employee cannot be identified.
The absence interval is invalid.
The absence cannot be associated with a period time-off type.
A manually changed component is no longer available for automatic synchronization.

Limitations and considerations

The current documentation describes the behavior of one external source. A different external source may provide different information, including different identification, update, or deletion behavior.

The source-specific sections below must not be interpreted as requirements for every external-absence source.

Czech eNeschopenka-specific behavior

The currently documented Czech external source is eNeschopenka, provided through ORDS.

For this source:

ORDS provides eNeschopenka records in which a change occurred during the previous seven days, regardless of when the eNeschopenka was originally created;
ORDS provides complete eNeschopenka data, not only changed values;
AristoTelos can create and update eNeschopenka records;
ORDS does not provide information about deleted eNeschopenka records, so AristoTelos does not delete an eNeschopenka merely because it is missing from a later import;
eNeschopenka is associated with an employee contract through the employee personnel number;
a person can have more than one personnel number, and an eNeschopenka for one personnel number does not automatically apply to another personnel number;
the imported scope does not include stay addresses or information about permitted walks;
eNeschopenka information typically arrives one to two days late and can arrive up to five days late after a weekend combined with a month boundary;
an eNeschopenka that lies entirely in the past can still be added when it does not affect shifts in a finished roster period;
an eNeschopenka change that would hide or reveal shifts in a finished roster period is not applied automatically and requires manual resolution.

Open business questions

The source documentation contains open questions about:

notification of the end of an external sickness absence;
notification recipients when an illness is deleted;
notification of absence without a supporting document;
ownership of removing absences without a supporting document;
visibility of external-absence information; and
required reporting.

Implementation and configuration

For configuration, administration, source processing, shift-plan behavior, employee-contract processing, and SAP-export details, see the related Application Documentation.

External Absences implementation (obsolete)

External Absences are implemented as a controlled synchronization flow between an external absence source and the employee absence records used by AristoTelos.

The import job can run automatically at configured times or be started manually. Before processing records, it validates its connection, parameters, and absence-type mapping. If this setup is invalid, the run stops without applying partial updates.

During processing, AristoTelos:

Retrieves and retains the input data needed for troubleshooting.
Matches an external absence to an employee using the employee's personal identifier.
Creates a new external absence or updates an existing one.
Maps the external illness type and work-accident indicator to an AristoTelos Time Off Type.
Creates or updates the linked employee absence when the change is permitted.
Respects manual overrides through the separate start, end, and type synchronization controls.
Records unsuccessful updates and retries unresolved employee assignments up to the configured limit.
Prevents changes that would affect a closed attendance interval and records the reason for the rejected update.

All changes to external absence records are written to the audit log, while changes to linked roster records are captured in shift history. The job produces user-readable processing logs and sends a completion notification for both successful and failed runs.

Business impact

This implementation reduces repeated manual entry of externally managed absences and keeps planning data aligned with the external source. Separate synchronization controls preserve HR and administrator decisions, while statuses, retries, logs, and audit history make exceptions visible and traceable.

The source-specific retrieval is separated from the synchronization behavior, allowing the same business flow to be adapted to another external source without redesigning how absences are represented and applied in AristoTelos.

External Absences delivered results (obsolete)

The documented implementation is intended to provide the following tangible results once delivered and configured.

Synchronized planning data

External absence records are linked to the correct employee where a match is available.
Corresponding employee absences are created or updated in the shift plan.
Roster users can distinguish absences originating from an external record.
Manual overrides remain visible through the start, end, and type synchronization indicators.

Operational control

HR and administrators can search and filter imported records in one administration view.
Synchronization status, last-change date, and failed-attempt count expose records that require attention.
Authorized users can start synchronization from the web application.
Changes that cannot safely be applied, including changes affecting closed attendance, are retained as explicit exceptions.

Traceability and support outputs

A user-readable CSV log records created and updated records, skipped changes, input problems, and failures.
Job-run information shows the outcome of data retrieval, external-record updates, and linked-absence updates.
Completion email is sent for successful and failed runs and links authorized users to the job-run administration.
External absence changes are available in the audit log, and linked roster changes are available in shift history.

Attendance and payroll handoff

Attendance closure warns managers when an unconfirmed sickness absence will be treated as unpaid sickness.
Imported absences linked to a contract ending in the closing period can be ended at the contract end by the employee-import process.
The documented payroll outcome is based on the resulting employee absence in attendance. The available Wiki does not define a new general-purpose External Absences report or a standalone export format, so neither is presented here as a delivered result.

Integration result

The external source record, employee, mapped Time Off Type, and linked roster absence form a traceable chain. This allows external absence data to become operational planning and attendance data while retaining the external identifiers and processing history needed for reconciliation and support.

Synchronization with external systems

The source-specific behavior on this page applies to the currently documented Czech eNeschopenka integration.

Incoming absence information

eNeschopenka information is received from ORDS.

ORDS provides eNeschopenka records in which a change occurred during the previous seven days. A record can therefore concern an eNeschopenka created recently or one created much earlier.

Each supplied record contains complete eNeschopenka information, not only the values that changed. The source can provide information about the beginning of incapacity, the end of incapacity, or both.

ORS does not provide information about deleted eNeschopenka records. AristoTelos can therefore create and update eNeschopenka records, but does not delete one merely because it is missing from a later import.

The imported scope does not include stay addresses or information about permitted walks.

Identifying the external absence

An eNeschopenka is identified by its decision number and personnel number.

AristoTelos expects the decision number to be unique. The personnel number identifies the employee contract to which the eNeschopenka belongs.

A person can have more than one personnel number. An eNeschopenka associated with one personnel number does not automatically apply to another personnel number of the same person.

A personnel-number change for an existing eNeschopenka is treated as an error.

Creating and updating eNeschopenka records

When an eNeschopenka received from ORDS does not exist in AristoTelos, AristoTelos creates it.

When it already exists:

no update is made if the supplied information is unchanged;
the stored information is updated if the supplied information differs; and
changes affecting employee association, absence interval, or absence type are passed to synchronization to the shift plan.

Associating eNeschopenka with an employee

AristoTelos associates eNeschopenka with the employee contract through the personnel number.

If the employee cannot be found, the eNeschopenka is still created. The employee association and the related period time-off cannot be completed at that point.

Later import runs try again to associate eligible unassigned eNeschopenka records with an employee. Once the employee is found, the related period time-off can be synchronized.

Determining the period time-off type

Illness information and work-accident information from eNeschopenka determine the related period time-off type.

If the information cannot be associated with a period time-off type, the related period time-off is not created or updated.

If the eNeschopenka interval is invalid, the related period time-off is not created or updated.

Processing outcomes

The processing result records whether eNeschopenka information was created, updated, unchanged, or could not be processed.

The result also records situations in which:

the employee could not be identified;
the employee identifier changed;
the period time-off type could not be determined;
the interval was invalid; or
the source information could not be processed.

Changes to eNeschopenka information are recorded in the audit log. The import result is available for review after processing.

Synchronization to shift plan

The source-specific behavior on this page applies to the currently documented Czech eNeschopenka integration.

Creating and updating period time-off

A newly created or changed eNeschopenka can create or update the related period time-off.

The synchronization considers changes to:

employee association;
the start of the period time-off;
the end of the period time-off; and
the period time-off type.

A period time-off created from eNeschopenka remains linked to that eNeschopenka.

Administrator changes

An Administrator can change the start, end, or period time-off type of a linked period time-off.

When the Administrator changes one of these components, subsequent eNeschopenka updates no longer automatically update that same component:

a changed start is no longer synchronized automatically;
a changed end is no longer synchronized automatically; and
a changed period time-off type is no longer synchronized automatically.

The three components are handled independently. A manual change to one component does not itself stop synchronization of the other components.

The Administrator can enable synchronization again in eNeschopenka administration.

Compatible period time-off

Before creating or updating the eNeschopenka period time-off, AristoTelos checks whether a compatible period time-off already exists.

Compatible period time-off starts on the same date and at the same time

The compatible period time-off is removed and a period time-off linked to eNeschopenka is created.

Compatible period time-off starts on the same date at a different time

When the compatible period time-off covers shifts, the start time of the eNeschopenka period time-off is adjusted to the compatible period time-off start time.

Automatic synchronization of the start is then disabled for the eNeschopenka.

Compatible period time-off starts earlier

When the compatible period time-off starts earlier and protects shifts before the eNeschopenka start, the earlier part remains in the shift plan and is shortened to cover those shifts.

When it does not protect shifts, the compatible period time-off is removed.

Compatible period time-off starts later

In an open roster period, the compatible period time-off is removed and the eNeschopenka period time-off is created.

If the gap before the compatible period time-off contains shifts, the result is recorded as a warning.

No compatible period time-off

When no compatible period time-off exists, the eNeschopenka period time-off is created in an open roster period.

If shifts are present, the result is recorded as a warning.

Finished roster periods

An eNeschopenka change that would hide or reveal shifts in a finished roster period is not applied automatically and requires manual resolution.

When no compatible period time-off exists and shifts are present in the affected finished roster period, the eNeschopenka period time-off is not created automatically.

When no shifts are affected, the eNeschopenka period time-off can still be created even if it overlaps a finished roster period.

An end-date change in a finished roster period can be applied when no shifts are affected by the changed part of the interval. If shifts are affected, the end-date change is not applied automatically.

An eNeschopenka that lies entirely in the past can still be added when it does not affect shifts in a finished roster period.

Shift-plan display

A period time-off linked to eNeschopenka is identified in the shift plan by an icon before the absence abbreviation.

Users with the required right can see the eNeschopenka number in the shift tooltip. The tooltip also shows whether the start, end, or period time-off type is not automatically synchronized.

Attendance closing

During attendance closing, the Manager is informed when the employee has sickness absence without a supporting document.

The message explains that the absence will be exported as unpaid sickness. Attendance can then be closed.

Employee contract end and extension

When an employee contract ends, linked period time-offs are ended with the employee contract.

When an existing employee contract is extended, a linked period time-off can be extended again if:

it was previously ended with the employee contract;
it is linked to eNeschopenka;
the eNeschopenka ends after the original employee-contract end date; and
synchronization of the period time-off end remains enabled.

If end synchronization is disabled, the linked period time-off is not extended automatically.

Shift-plan publishing and history

During shift-plan publishing, overlapping period time-offs are normally connected. This connection is not performed if one of the period time-offs is linked to eNeschopenka.

Changes to period time-offs create standard shift history. Changes to eNeschopenka information are recorded in the audit log.

Was this helpful?