Staff, shifts & working time

HR enters a contract once. The planning team and employee then automatically receive the up-to-date view each needs.

Employee profile, employment, contract version, assignment, competence evidence, delegation and rule profile must be separate objects managed over time. Joining and leaving, employment-percentage changes, multiple locations and multiple simultaneous contracts can be represented.

Staff numbers and external payroll system identifiers are attributes with provenance; they do not replace a UUID. Assignment to the platform identity follows a controlled process. There is no automatic merging based on matching email addresses or similar names.

Qualifications record type, evidence reference, issuing body, validity interval and reviewer. Status: submitted → checked → valid; rejected, expired and revoked remain distinguishable. Only the responsible professional owners confirm competencies.

Contract and rule profiles specify the time zone, basis for contracted hours, calendar, employment percentage, annual leave account type, permitted shifts, rest and working time rules, minimum staffing and soft objectives, with units and sources. Rules may apply to a person, contract, location and period. Conflicts or missing precedence rules must be visible and block processing.

Rule versions follow draft → professionally reviewed → approved → superseded. Retrospective changes create a new version and an impact preview; historical approvals retain the rules applicable at the time.

A person's aggregate availability over time must be verifiable across contracts where those employments are managed within this tenant. External work is considered only through necessary, lawfully collected availability information; the product does not claim knowledge of other employers' data.

Approved staffing needs, capacity checking and the shared capacity-check port must provide the common capacity and qualification checking core. It processes approved demand, available competencies, confirmed restrictions and the known published roster version, transactionally protects the area and period revision and does not pass a check when demand foundations are missing. Changes from B/C/D update the same revision; past decision foundations are preserved.

Manage education and further training, task competence, location-specific shift authorisation and experience separately. Shift type, shift authorisation and deployment scope define permissible shifts and work locations; M06-D templates reference the shift type. Actual shift experience uses the M06-G source contract defined early on, but does not grant authorisation. The shared port for checking shift eligibility processes current authorised source snapshots; active provisional protective blocks from C are as binding as confirmed blocks.

Responsibility

Self-service reads the employee's own approved information and submits evidence. HR manages contracts. Professional leads approve competences. Rule approvers must be authorised for the scope. An HR administrator cannot grant themselves clinical competence.

Automation & AI

Expiry alerts for evidence and contracts include responsibility and escalation. AI can suggest fields from documents uploaded with authorisation; the original, extracted values and human confirmation remain connected. A qualification is never recognised automatically. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Every employee can request leave themselves and trace how the request and decision affect their available balance.

Annual leave accounts, account entries, leave requests, leave decisions and leave cancellations record entitlement, carry-over, approved corrections, reservations and consumption in a traceable way. Balances are reproducible from versioned entries; a total field cannot be overwritten without a record.

The personal view separates accrued or rule-compliant projected entitlement, already approved leave, provisional requests, leave taken and the remaining balance. Future forecasts must be identifiable as such. The same event must never produce a balance entry twice.

A request supports full days, contractually permitted half-days or hours, multiple time periods, multiple contracts, comments with restricted visibility and representation. Weekends, public holidays, part-time work, irregular deployment patterns and year changes are assessed using the valid profile.

Status: draft → submitted → under review → approved | rejected; submitted requests can be withdrawn. Approved requests are changed only through a separate, justified cancellation or amendment process. The original decision is retained.

Approval atomically checks the current balance, overlapping requests, effects on capacity and qualifications, and the current rules. If a decision relevant to planning is missing, the request remains open. A request is never approved merely because a deadline expires.

Approved leave is passed to planning as hard unavailability. A new solver run or short-term understaffing must not silently override it. Necessary later changes require the separate professionally permissible process.

Joining, leaving, changes in employment percentage, carry-over and expiry have versioned rules with professional approval. A missing rule or unclear balance leads to review by responsible staff, not an AI estimate.

Responsibility

Employees manage their own drafts and requests and see their balance. Named approvers see only necessary capacity and account data. Adjustment entries require separate permissions and independent approval according to the risk profile. Colleagues see at most the approved absence, not request reasons or balances.

Automation & AI

Pre-check completeness, conflicts and balance; provide reminders and escalation to a substitute; suggest alternative periods based on approved capacity. AI can translate ‘three days in the first week of July’ into a date draft requiring confirmation. Ambiguous language prompts clarification; entitlement or approval is never decided automatically. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Employees maintain their own availability. Planning immediately recognises what is bindingly blocked and which preferences should be accommodated where possible.

Availability rules, exceptions, preferences and availability decisions explicitly distinguish: a non-binding preference (for example, preferring a day off), reported unavailability (still to be reviewed), a provisionally binding protected status, a confirmed mandatory restriction and contractually fixed availability. An arbitrary self-entry does not automatically acquire the status of a statutory restriction. For a report of “night shift not possible”, the binding protection and clarification process for fixed shift restrictions applies once server receipt is confirmed; unresolved clarification does not permit assignment to a night shift.

Employees must be able to record, change or submit changes to one-off and recurring availability, time-off preferences, preferred shifts and blocked time windows themselves. Acute incapacity for work follows process M06-F and must not be treated as a rejected time-off preference.

Time windows support days, partial intervals, recurring patterns, exceptions, time limits and personal time zones. The server view translates them unambiguously into the planning time zone. Ambiguous or nonexistent local times require explicit resolution.

Preference status: draft → submitted → accommodated | partially accommodated | not accommodated | withdrawn. Block status: reported → provisionally protected where appropriate → reviewed → confirmed | lifted or rejected with reasons; changes to confirmed blocks are separately traceable. Objectively mandatory unavailability remains protected under the applicable rule process even without preference approval.

Submission deadlines, amendment deadlines and responsible approval are versioned for each planning period. After roster publication, an amendment request shows the affected shifts; it does not automatically overwrite their assignments.

Priorities and objective weights for preferences are defined transparently. The person sees which of their own preferences were considered and an understandable rule-based explanation. Other people's private reasons or personal comparative rankings are not disclosed.

Conflicts between contracts, approved leave, blocks and preferences require defined precedence rules. ‘Available’ must not override approved leave. Recurrences must be evaluated within finite planning windows; unlimited expansion must not block the service.

Personal shift favourites specify date or weekday, shift type, ranking, optional location, time limit and exceptions. Date exceptions take precedence over recurring patterns; hard blocks take precedence over every preference. ‘Prefer not to work nights’ and ‘Cannot work nights’ are separate entry types with different consequences. An active night block is not overridden by available night-shift experience, an old favourite or staff shortages.

Responsibility

Employees manage their own data; planning reviews it within the relevant area. Private reasons are optional or can be recorded only where professionally necessary, and are separately protected. The system does not require free-text medical information to report a restriction.

Automation & AI

Recurring rules save monthly entry work. Reminders before deadlines and conflict display during entry. AI can structure a spoken preference and explain how it differs from a mandatory restriction; the employee confirms the type and period. The solver receives verified structured data, not freely interpreted preference text. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Needs, competences and availability produce a permissible schedule proposal; the responsible planning team reviews and publishes clearly understandable changes.

Planning period, shift template, shift, shift assignment, schedule revision, rule status and calculation run maintain the schedule and its decision basis. Approved staffing requirements and the shared capacity revision come from M06-A; D does not own a second competing requirements basis. Minimum staffing and the qualification mix are recorded by time interval, not just as a daily headcount.

Status: draft → calculated → reviewed → published → superseded/closed. A solver result is a versioned proposal. Changes to published rosters create a new revision requiring approval, with a visible difference and notification to affected people.

The separate planning calculation receives minimal structured data that is pseudonymous where possible. It provides assignments, rule and objective versions, run configuration, seed where supported, result status and verifiable conflicts. “Optimal”, “feasible within the time limit”, “unsolvable” and “no result” are distinguished.

The domain core rechecks every proposed or manually entered assignment against binding hard rules. Manipulated, outdated or rule-breaking calculation results are rejected. The solver and UI cannot grant permission for exceptions.

Preferences, fair distribution of demanding shifts, continuity and few changes are managed as approved soft objectives with traceable weighting. Fairness is checked against defined criteria and periods; private health reasons or protected characteristics are not improvised optimisation objectives.

Before publication, the entire affected period, rest windows spanning periods, the same person's other contracts, competence validity, leave, restrictions and current revisions are checked. Violation of a mandatory rule blocks publication. An unsolvable roster leads to a specifically described staffing need, not silently weakened rules.

Publication saves a consistent roster revision and assignments in one transaction. The shared change process for exchanges and replacements must offer atomic multiple changes with expected shift, assignment and rule revisions.

Previews must show which people and shifts change and which notifications are generated. A sent push notification is not proof of receipt. Required acknowledgements have their own status and escalation.

Responsibility

Planning manages assigned areas; publication requires a separate action. Employees see their own shifts and the approved team view. The solver service has no publication or HR document rights.

Automation & AI

Rule-based planning, incremental replanning after availability changes, conflict explanations and notifications. AI can express an explanation that has already been calculated in clear language; the binding cause and figures still come from the rule checker. Manual planning remains available if AI or the solver fails and is subject to the same checks. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Employees find a permitted shift exchange themselves or offer to help with open shifts without planning having to transfer information repeatedly.

Swap offers, consent, open shifts, applications and swap decisions distinguish reciprocal swaps, offered shift handovers and applications for an open shift. Willingness alone is not a binding assignment.

Swap status: draft → offered → mutually agreed → review → approved/executed | rejected | expired | withdrawn. For open shifts: open → applications → selection/review → bindingly assigned | closed. Withdrawal after execution requires a new change.

Both people affected agree to the specific pair of shifts and revision. Changes to a shift, person or period invalidate previous consent. Any required management approval follows the versioned operating profile.

Final execution must check both assignments against the current working and rest times, competencies, overlaps and minimum staffing, and change them in one transaction. Either all affected assignments are saved with audit and outbox entries, or none are.

Multiple offers or applications must not bind the same person or the same open shift more than once. A definitive acceptance invalidates competing offers with a traceable status and notification.

Suggestions consider only people with the required competence and published contact or offer visibility. Employees see neither private reasons for blocks nor complete personnel files of potential swap partners.

Responsibility

Employees offer only their own shifts eligible for exchange and confirm only for themselves. Temporary representation must explicitly permit the relevant action and remain identifiable. Planning decides within its assigned area; employees cannot approve their own exchange.

Automation & AI

Rule-checked partner and shift suggestions, automatic rechecking, reminders before offers expire and closure of completed offers. AI explains permitted alternatives from authorised data. No automatic binding application or assignment is made on the employee's behalf. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Reported staff unavailability immediately becomes visible to the correct responsible people and initiates a controlled search for cover and handover of open tasks.

Absence reports, confidential absence information, affected shifts, cover cases and staffing decisions separate the absence period, confidential details, affected shifts and the cover decision. Status: reported → receipt confirmed → professionally handled → closed; cover status is independent: need open → being handled → staffed | unstaffed/escalated.

Employees must be able to report and update a short-notice absence for themselves; an authorised representative can document a telephone report with the actual reporting time and the person entering it. Processing a report is not a medical assessment of fitness for work.

The operational view immediately shows which published shifts and minimum staffing or competence requirements may be affected. Confirmed unavailability is not ignored simply because no replacement exists yet. Unconfirmed information retains a visible review status.

The responsible party confirms handling; if no acknowledgement is received, the case escalates to a substitute after a versioned deadline. Sending a push notification alone does not close the case. Without a connection, the app points to the approved operational reporting channel and must not display a local draft as a delivered sickness report.

Cover suggestions must consider competences, rest periods, other shifts and confirmed absences. Reassignment uses the schedule contract from D with a current check, necessary consent and approval. No cover case automatically unblocks annual leave or changes fixed blocks.

The interface to task and handover modules supplies only the absence reference, validity and necessary responsibility. Professional tasks that cannot be delegated are escalated; they are not blindly assigned to an arbitrary substitute. Handover and replacement shifts have separate completion evidence.

Return, extension and correction of an error create traceable new revisions. A replacement shift is not automatically cancelled on return; the affected planning team reviews the change.

Responsibility

The employee submits their own report; planning receives the period and staffing need. Confidential causes and evidence are restricted to specifically authorised HR functions. Medical documents appear neither in the shift schedule nor in task handovers.

Automation & AI

Find affected shifts, check rules, offer suitable cover candidates, and prepare escalation and authorised handover tasks. AI can create a handover overview from permitted tasks; it makes no illness forecast or credibility assessment. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Employees document their actual working time in a few steps; discrepancies are reviewed traceably without presenting scheduled shifts as time actually worked.

Time entries, breaks, time corrections, timesheets, time approval and allowance foundations record actual time, breaks, roster reference and exportable time attributes. Presence, working time, on-call availability and leave are assessed as different categories only according to the approved profile.

Start and stop recording are available through approved channels when the organisation's policy permits; approved retrospective entry remains available. Entry time, actual period, source and author remain separate. Work performed is never asserted automatically solely because of a shift schedule, a push acknowledgement or an opened app.

Status: draft → submitted → under review → approved | for correction; correcting already approved time creates a new revision with a reason and renewed approval. The original and its approval at the time are preserved.

The server checks overlapping entries, negative or excessively long intervals, breaks, permitted categories, work across midnight, multiple contracts, time zone and changed employment percentage. Professionally necessary retrospective entries remain possible and are clearly marked as such.

Allowance foundations record time windows and approved categories with the rule version; monetary amounts and payroll calculations belong in the external payroll system. Rounding and boundaries follow the approved profile and are traceable through an example.

Employees can review their own hours, differences between scheduled and actual time, review comments and approval status, and request corrections. Binding time changes by supervisors must be recognisable and must not silently disadvantage employees.

Responsibility

Record and correct own time; responsible approvers review it. No self-approval. A location or supervisor change does not automatically revoke necessary historical review access; it requires explicitly time-limited review permission. Continuous location surveillance is not a prerequisite for time recording.

Automation & AI

Reminders for outstanding entries, rule-based discrepancy detection and suggestions for assignment to a scheduled shift. The employee confirms what actually happened. AI may formulate a correction explanation, but must not invent time or secretly adjust it to a target. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Staff administration transfers fully checked time foundations to the payroll system once and can handle rejections or corrections specifically.

Payroll export periods, locked export states, export mappings, export packages, delivery records and export corrections maintain immutable states of approved data, including contract, rule, mapping and approval revisions.

Status: open → reviewed → locked → export created → delivered → confirmed | partially rejected | rejected. ‘File created’ means neither successful delivery nor acceptance by the payroll system.

Closing checks missing approvals, contradictory time intervals, unassigned external employee or contract identifiers and mapping versions. Incomplete person or contract periods must not silently be exported as complete. Supported partial closings must be explicitly identified and professionally approved.

Exports contain only approved time, absence and allowance foundations according to the partner contract. No resident data, diagnoses, medical certificates or free-text HR comments. Purpose, recipient, encryption and minimal retention of the export artefact are defined.

Retries use the same batch identity and snapshot. Recipients without technical idempotency require a controlled manual delivery and reconciliation process; blind automatic retries must not cause duplicate processing.

Later corrections create a new correction export referencing the original. Historical export files, acknowledgements and approvals remain unchanged. Reopening a period requires separate permission, a reason and renewed review of affected records.

M06 is responsible for the professional snapshot and mapping approval; the actual partner interface uses the M17 integration contract. A generic CSV or API adapter is not an approved payroll connection without a specific partner specification and acceptance. Character encoding, decimal format, time format and required fields follow the versioned partner contract, not the exporting user's UI language.

Responsibility

Separate actions for closing, export, download, delivery and reopening. Export rights are bound to recipients and areas; downloads are auditable. Employees see their own approved time and any corrections, not the complete batch.

Automation & AI

Completeness checks, comparison of changes and totals, controlled delivery, reminders for missing acknowledgements and assignment of technical errors to cases requiring handling. AI can explain an authorised error message; mapping changes, approval and correction remain human responsibilities. No AI-generated amount or unauthorised dispatch. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Contract content, signing and effectiveness form a shared process with HR.

Employment contracts reference the employment and contract version already maintained. Employment percentage, job changes, attachments, approved clauses, templates and previous versions remain accessible together in the personnel file. No second staff record is created alongside M06-A.

Internal content review, invitation to sign, complete evidence checking and actual effectiveness are separate steps. All required employer and employee signatures are obtained according to the approved signing rule. A signature still missing remains visible as an incomplete agreement.

Employees receive only their own approved contract documents; HR works within its assigned scope. Signing authority is checked separately. The contract language and user interface language may differ, while the signed original remains unchanged.

A change to employment percentage or content during signing requires a new review of the affected document. Signatures already given are not transferred to changed clauses. Rejection, withdrawal and superseded agreements remain traceable.

Paper agreements use the same process with verified scans, signatory information and storage of the original. The shared document and signature function in M12 handles signing steps and evidence; M06 is responsible for the employment contract and its effective status.

Responsibility

HR prepares documents, authorised employer representatives sign, and employees review and sign their own documents.

Automation & AI

AI can summarise changes, flag missing information and assign approved clauses. Binding clause changes and acceptance require a responsible decision. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Connection & offline use

Drafts may be prepared within the permitted scope. Approval, signing and confirmation of effectiveness take place online.