13 december 2024
Service description for the provision of an
overall system for
the processing of remuneration (LEBE.Bezüge)
29.11.2024
13 December 2024 Page 1 of 366
13 december 2024
I.
Table of contents
I.
Table of contents
2
II.
List of figures and tables
11
III.
List of abbreviations
12
IV.
Glossary
21
1
Introduction
36
2
Initial situation and objectives
38
2.1 Initial situation 38
2.1.1 Allocation of tasks in the LAF in relation to the remuneration procedure 39
2.1.1.1 Quantity structure 39
2.1.1.2 The LAF payment centre 39
2.1.1.3 The LAF control centre for the remuneration procedure 40
2.1.2 Current remuneration procedure FABEA 40
2.1.2.1 Data of the departments 40
2.1.2.2 Data from personnel cases 40
2.1.2.3 Cover processing 40
2.1.2.4 Sampling control procedure 41
2.1.2.5 Data preparation and output 41
2.1.2.6 Actuation 41
2.1.3 Subject of the tender 42
2.1.4 Time and project planning 42
2.2 Objective 45
2.3 Stakeholders 46
2.3.1 Mecklenburg-Western Pomerania State Office of Finance 46
2.3.2 Ministry of the Interior, Building and Digitalisation 47
2.3.3 Personnel departments 47
2.3.4 Ministry of Finance 47
2.3.5 Data Processing Centre MV GmbH 47
2.3.6 State Court of Audit 47
2.3.7 Commissioner for Data Protection and Freedom of Information of the State of Mecklenburg-Vorpommern
48
2.3.8 Data Protection Officer of the LAF 48
2.3.9 Equal Opportunities Officer Working Group 48
2.3.10 Staff representation 48
13 December 2024 Page 2 of 366
13 december 2024
2.3.10.1 Working group of the main staff councils 48
2.3.10.2 Working group of the local staff councils 48
2.3.10.3 Representative body for severely disabled persons 49
2.4 Legal framework 49
3 General system description 52
3.1 System architecture 52
3.1.1 Overview of target system 52
3.1.2 Grid connection 55
3.1.3 Provision/installation 55
3.1.3.1 On-premise operating model 55
3.1.3.2 SaaS operating model 56
3.1.3.3 Surroundings 56
3.1.4 Quantity structure 57
3.2 Description of use cases of the global specialised process 57
3.2.1 Communication platform (KP) (self-service) 59
3.2.2 Input management 60
3.2.3 Cover processing 61
3.3 Role description 64
3.3.1 System administration 64
3.3.2 Centralised specialist administration 64
3.3.3 Department-specific specialised administration (ePAePV) 65
3.3.4 Application support for the departments 66
3.3.5 Application support for the communication platform 67
3.3.6 Data protection audit 67
3.3.7 Internal audit LAF 68
3.3.8 Internal Audit Departments 68
3.3.9 Revision of communication platform 68
3.3.10 Head of Legal Department LAF MV 69
3.3.11 Seizure processing 69
3.3.12 Objection processing 69
3.3.13 Head of the Remuneration Department 69
3.3.14 Head of processing in the personnel department 70
3.3.15 Head of department Remuneration and personnel 70
3.3.16 Head of department 71
3.3.17 Sample inspection (inspection group) 71
13 December 2024 Page 3 of 366
13 december 2024
3.3.18 Authorised signatory departments
72
3.3.19 Processing for special tasks LAF
72
3.3.20 LAF processing
73
3.3.21 Processing departments
74
3.3.22 Organisation processing
74
3.3.23 Processing of the personnel budget
75
3.3.24 Processing 4-eyes principle
75
3.3.25 Processing signatory authorisation
75
3.3.26 Processing of investigation and disciplinary matters
76
3.3.27 Processing of 4-eyes principle and signing authority for investigative and disciplinary matters
76
3.3.28 Staff unit - Complaints to supervisory authorities
77
3.3.29 Users of the communication platform
77
3.3.30 Authorised users of the communication platform
77
4
Functional system components
79
4.1 Overarching requirements for payment calculation and ePA/ePV
79
4.1.1 Data collection
79
4.1.2 Catalogues
83
4.1.3 Four-eyes principle
83
4.1.4 Curriculum vitae data
84
4.1.5 Plausibility checks
86
4.1.6 Document creation
87
4.1.7 Acting/document management system
90
4.1.8 Qualified electronic signature and seal
93
4.1.9 Workflow management
94
4.2 Communication platform (self-service)
106
4.3 Input management
116
4.3.1 Document content capture (OCR/ICR)
116
4.3.2 Connection to existing system
118
4.4 Analyses
119
4.4.1 Statutory and standard analyses
120
4.4.2 Further, own analyses
123
4.5 Output management
126
4.6 Roles and authorisations
128
4.7 Payroll accounting
131
13 December 2024 Page 4 of 366
13 december 2024
4.7.1 Legal requirements and HR system catalogues 132
4.7.2 Workflow management 134
4.7.3 Data acquisition 136
4.7.4 Multiple legal relationships and claims with the same and different employers/employers 137
4.7.5 Curriculum vitae data 138
4.7.6 Dark processing 139
4.7.7 Requirements Remuneration 140
4.7.7.1 Gross calculation 140
4.7.7.1.1 Basic references 140
4.7.7.1.2 Separate employment relationships and types 145
4.7.7.1.3 Other cover components 147
4.7.7.1.4 Reductions/reduction of remuneration 147
4.7.7.1.5 One-off and special payments, death benefit 148
4.7.7.1.6 Special working time regulations 150
4.7.7.1.7 Further requirements 150
4.7.7.2 Net calculation 152
4.7.7.2.1 Social security 152
4.7.7.2.2 Tax deductions 156
4.7.7.2.3 Contributions to the supplementary pension scheme 156
4.7.7.2.4 Withholdings and deductions 157
4.7.7.2.5 Advances and employer loans 157
4.7.7.2.6 Capital-forming benefits 157
4.7.8 Salary requirements 158
4.7.8.1 Gross calculation 158
4.7.8.1.1 General calculation of salary 158
4.7.8.1.2 Special working time regulations 161
4.7.8.1.3 Benefits 162
4.7.8.1.4 Family-related benefits 162
4.7.8.1.5 Other cover components 162
4.7.8.1.6 Salaries abroad 164
4.7.8.1.7 Candidate remuneration 164
4.7.8.1.8 One-off and special payments 166
4.7.8.1.9 Official salaries 166
4.7.8.1.10 Reductions/reduction of remuneration 167
13 December 2024 Page 5 of 366
4.7.8.1.11 Supply surcharge 169
4.7.8.1.12 Further requirements 171
13 december 2024
4.7.8.2 Net calculation 172
4.7.8.2.1 Tax deductions 172
4.7.8.2.2 Riester pension scheme 172
4.7.8.2.3 Retentions 172
4.7.8.2.4 Advances 173
4.7.8.2.5 Capital-forming benefits 174
4.7.8.2.6 Subsequent insurance 174
4.7.9 Supply requirements 177
4.7.9.1 Gross calculation - supply 177
4.7.9.1.1 Determination of supply data 178
4.7.9.1.2 Determination of the pension rate 179
4.7.9.1.3 Death benefit 182
4.7.9.1.4 Survivors' benefits 182
4.7.9.1.5 Supply according to the LMinG 186
4.7.9.1.6 Supply information and other information 187
4.7.9.1.7 Supply calculation 189
4.7.9.1.8 Accident insurance 193
4.7.9.1.9 Transitional allowance and compensation 197
4.7.9.1.10 Reductions/recognisations of pension payments 198
4.7.9.1.11 Suspension regulations 200
4.7.9.1.12 Gross calculation of retirement benefit 205
4.7.9.2 Net calculation of pension and retirement benefit 212
4.7.9.2.1 Social security pension and retirement benefits 212
4.7.9.2.3 Pension recipient and old-age pension recipient card 214
4.7.9.4 Supply burden sharing 215
4.7.9.5 Pension equalisation 219
4.7.10 Overarching technical requirements 223
4.7.10.1 Gross calculation - general remuneration calculation 223
4.7.10.2 Gross calculation - benefits 224
4.7.10.3 Gross calculation - family-related benefits 225
4.7.10.4 Gross calculation - Other pay components 228
4.7.10.5 Gross calculation - one-off and special payments 230
4.7.10.6 Gross calculation - death benefit 231
13 December 2024 Page 6 of 366
4.7.10.7 Gross calculation - Sabbatical 232
4.7.10.8 Net calculation - social insurance 234
4.7.10.9 Net calculation - tax deductions 234
13 december 2024
4.7.10.10 Net calculation - contributions to the supplementary pension scheme 236
4.7.10.11 Net calculation - Riester pension scheme 239
4.7.10.12 Net calculation - advances 239
4.7.10.13 Net calculation - capital-forming benefits 240
4.7.11 Fictitious calculations and settlement runs 241
4.7.12 Sampling control procedure 243
4.7.13 Creation of documents - Remuneration notice 244
4.7.14 Payment/making payment 245
4.7.14.1 Requirements for the creation of the payment transaction file (payment transaction procedure PPM) 245
4.7.14.2 Requirements for the creation of the accounting file (HKR procedure) 246
4.7.14.3 Overarching requirements for making payments (posting and payment) of emoluments 247
4.7.15 Tax treatment 248
4.7.15.1 Wage tax treatment 248
4.7.15.2 Wage tax registration 249
4.7.16 Attachments, assignments and offsetting 250
4.7.17 Objection handling 257
4.7.18 Reclaiming remuneration 262
4.8 Electronic Personalakt/Electronic Personnel Administration 267
4.8.1 Overarching requirements 267
4.8.1.1
General requirements 267
4.8.1.1.1 Document preview 268
4.8.1.1.2 Centralised mass data change 269
4.8.1.2
Workspace structuring - General information 269
4.8.1.2.1 Distinctiveness 269
4.8.1.2.2 Show 269
4.8.1.2.3 Customised configuration 269
4.8.1.3
Metadata 270
4.8.1.3.1 Sort using metadata 270
4.8.1.3.2 Metadata display setting 270
4.8.1.3.3 Configure metadata 271
13 December 2024 Page 7 of 366
4.8.1.4
Logging 271
4.8.1.4.1 Logging cases 271
4.8.1.5
Print 271
4.8.1.5.1 General requirements for printing 271
4.8.1.6
Deleting data 272
13 december 2024
4.8.1.6.1 Residue-free deletion 272
4.8.1.6.2 Delete and destroy 272
4.8.2 Filing-specific requirements (Electronic Personalakt) 273
4.8.2.1
Personalakt 273
4.8.2.1.1 Structure of the Personalakt 273
4.8.2.1.2 Create Personalakt 273
4.8.2.1.3 View Personalakt 273
4.8.2.1.4 Transfer / take over Personalakt 274
4.8.2.1.5 Bookmark 274
4.8.2.1.6 Close Akt 275
4.8.2.2
Documents 275
4.8.2.2.1 Document groups 275
4.8.2.2.2 View documents 275
4.8.2.2.3 Filing documents 276
4.8.2.2.4 Pagination/numbering of documents 276
4.8.2.2.5 Move documents 276
4.8.3 Personnel administration-specific requirements (electronic personnel administration) 276
4.8.3.1
Process: Recruitment 276
4.8.3.1.1 Carry out recruitment 276
4.8.3.2
Process: Assessment procedure 277
4.8.3.2.1 Comparison groups 277
4.8.3.2.2 Carry out assessment procedures 279
4.8.3.3
Process: Applying for special leave 280
4.8.3.3.1 Apply for special leave 280
4.8.3.4
Process: Staff budget 281
4.8.3.4.1 Business allocation plan / organisation chart 281
4.8.3.4.2 Job plan number 282
4.8.3.4.3 Budget centre 282
5 Non-functional requirements for the overall system 285
5.1 Requirements for the user interface 285
13 December 2024 Page 8 of 366
5.2 Quality requirements for changeability, expandability, maintainability 287
5.3 Safety requirements 289
5.3.1 Deletion periods and data protection 289
5.3.2 IT security 292
5.4 Technical requirements 294
5.5 Requirements for interfaces 300
13 december 2024
5.6 Accessibility 310
5.6.1 Requirements for the overall system 311
5.6.2 Requirements for proof of accessibility 313
5.6.3 Requirements for the software development process 316
5.7 Requirements for system environment, documentation and training 316
5.7.1 Requirements for the system environments 316
5.7.2 Documentation 318
5.7.3 Training courses 319
5.7.4 Migration 322
5.8 Requirements for acceptance and establishment of operational readiness 325
5.8.1 Initiating and carrying out acceptance 325
5.8.2 Auditing 327
5.9 Requirements for ensuring the cash register security and audit security of the overall system and the authorisation
procedure of the State Court of Auditors 328
5.10 Auditability of the overall system 329
5.11 Software as a Service 330
6 Requirements for project realisation/implementation 334
6.1 General information 334
6.2 Project language and documentation 334
6.3 Project management and implementation, roles 335
6.3.1 Support and operational monitoring 342
6.4 Project team and personnel continuity of the contractor 344
6.5 Confidentiality 345
6.6 Place of work and core working hours 345
6.7 Co-operation by the client 346
6.8 Test, quality and error management 346
7 Offer contents, delivery items and project results 351
7.1 Offer contents 351
7.2 Delivery items in project work 358
13 December 2024 Page 9 of 366
8 Attachments 365
13 december 2024
13 December 2024 Page 10 of 366
13 december 2024
II. List of figures and tables
The following illustrations are shown in the service description:
Numbering
Title
Figure 1
Rough project plan for the introduction of the overall system
Figure 2
Architecture of the new overall system of the LAF MV
Figure 3
Global specialised process - life cycle review
Figure 4
Global specialised process - data view
Figure 5
Global specialised process - time view
Figure 6
Environments DVZ. The training environment is not included in this illustration as it is not
part of the regular deployment procedure.
Figure 7
Programme structure LEBE.digital
Figure 8
Project structure LEBE.references
In addition to the requirements, the following tables appear in the service description:
Numbering
Title
Number of pages
Table 1
Forecasted user figures for new HR system
58
Table 2
Capacities
377
13. December 2024 Page 11 of 366
13 december 2024
III. List of abbreviations
The following abbreviations are used in the service description:
Abbreviation
Meaning
AAG
Equalisation of Expenses Act
AdB change
Change of grade
AES
Advanced Encryption Standard
AG
Client
A criterion
Exclusion criterion
ALG
Unemployment benefit
AN
Contractor
AO
Fiscal Code
API
Application Programming Interface
App
Application
ATAG
Authoring Tool Accessibility Guidelines
ATV
Collective agreement on the company pension scheme for public sector employees
AV
Unemployment insurance
BA-BEA
Submit certificate electronically (BEA) to the Federal Employment Agency (BA)
BAG
Federal Labour Court
BAV
Company pension scheme
BBesG
Federal Salaries Act
BBG
Contribution assessment ceiling
BBG KV
Contribution assessment ceiling for health insurance
BBG RV
Pension insurance contribution assessment ceiling
BDSG
Federal Data Protection Act
BeamtStG
Civil Servant Status Act
BeamtVG
Civil Service Pension Act
BEATA
Payments-inventory procedure (electronically instructing, transporting and
store)
BeBPo
Special electronic mailbox for public authorities
BetrAVG
Company Pension Act (Act on the Improvement of Company Pension Schemes)
13. December 2024 Page 12 of 366
13 december 2024
Abbreviation
Meaning
BFDG
Federal Voluntary Service Act
GERMAN CIVIL CODE
Civil Code
BGH
Federal Court of Justice
BI
Business Intelligence
BIC
Bank identification code
BITV 2.0
Ordinance on the creation of barrier-free information technology in accordance with the Disability Equality
Act
BITVO MV
Ordinance on the creation of barrier-free information technology in accordance with the Mecklenburg-
Vorpommern Equal Opportunities Act (Mecklenburg-Vorpommern)
B criterion
Evaluation criterion
BPMN
Business Process Model and Notation
BSI
Federal Office for Information Security
BTHG
Federal Participation Act
BV
Professional pension schemes
BVL
IT procedure for payroll accounting as part of FABEA
BVY
Name of the existing (previous) IT system for processing aid (aid accounting system) as part of FABEA
Regarding
Regarding
Or.
Or rather
CVE
Common Vulnerabilities and Exposures
I.e.
That means
DB
Database
DBBG
Data module reporting facts Contribution assessment ceiling
DBGZ
Data module "Reporting circumstances for the flexitime zone
DBMM
Data module reporting facts GKV monthly report
DEUEV
Data Collection and Transmission Ordinance
RDT agreement
Agreement on the remote data transfer between customer and credit institution
DJubV
Service Anniversary Ordinance
DM
German mark
DMS
Document management system for the personnel case file
13 December 2024 Page 13 of 366
13 december 2024
Abbreviation
Meaning
DOMEA
Document management system and electronic archiving in the IT-supported business processes of the state
of Mecklenburg-Vorpommern
DSG MV
Mecklenburg-Western Pomerania State Data Protection Act
GDPR
EU General Data Protection Regulation
DSME
Data record confirmation of the insurance number
DSP
Office portal
DuZ
Service at unfavourable times
DVD
Digital Video Disc
DVZ
Datenverarbeitungszentrum MV GmbH, IT service provider for the state of MV
DVZG MV
Data Processing Centre Act MV
eAU
Electronic certificate of incapacity for work
DFA
Experience seniority
EEL
Benefits in lieu of remuneration
Incl.
Including
ELStAM
Electronic wage tax deduction features
ELSTER
Electronic tax return
EltZLVO MV
Parental leave state ordinance (Mecklenburg-Western Pomerania)
RemunerationU
Deferred compensation
EOM
End date of maintenance
EOS
End date of support
ePA/ePV
Electronic Personalakt/Electronic Personnel Administration
ER
Entity Relationship
Income Tax Act
Income Tax Act
Etc.
Et cetera
ETL
Extraction, transformation, loading
euBP
Electronically supported tax audit
EUrlV (Federal
Government)
Ordinance on holiday leave for federal civil servants and judges
EVB-IT
Supplementary contractual conditions for the procurement of IT services
EEA
European Economic Area
13 December 2024 Page 14 of 366
13 december 2024
Abbreviation
Meaning
FA
Tax office
FABEA
Specialist application for payroll accounting. Platform (Solaris) on which BVL and BVY are operated
FM
Ministry of Finance Mecklenburg-Western Pomerania
FSJ/FÖJ
Voluntary Social Year/Voluntary Ecological Year
FV
Specialised procedures
If applicable.
If necessary
SHI
Statutory health insurance
GMBl.
Joint Ministerial Gazette
GoBIT-HKR
Principles of proper accounting when using automated procedures in the federal budget, cash and
accounting system
GS
Complete system
GUI
Graphical User Interface
GVP
Business distribution plan
h
Hours
HKR procedure
Automated procedures for the federal budget, cash and accounting system
HPR
Main Staff Council, supreme representative body for staff in the Ministry of Finance
HsLeistbVO MV
University Remuneration Ordinance
HStruktG
Act to improve the budget structure
in the amount of
In the amount of
in conjunction with.
In conjunction with
IBAN
International bank account number
ICR
Intelligent Character Recognition
IDM
Identity Management
ID number
Identification number
IdP
Identity provider
IfSG
Infection Protection Act
IK
Institution identifier
ICT
Information and communication technologies
13 December 2024 Page 15 of 366
13 december 2024
Abbreviation
Meaning
IM
Ministry of the Interior, Building and Digitalisation
Incl.
Included
InsO
Insolvency Code
IT
Information technology
ITIL
Information Technology Infrastructure Library
ITSG
Information technology service centre of the statutory health insurance
JBeitrG
Judicial Collection Act
JFDG
Youth Volunteer Services Act (Act on the Promotion of Youth Volunteer Services)
Chap.
Chapter
KiSt
Church tax
KLR
Cost and activity accounting
KP
Communication platform for references consisting of a web portal and app solution
KTG
Daily sickness allowance
CT
Health insurance
LAF
State Office of Finance
LAltGG MV
Mecklenburg-Western Pomerania State Retirement Benefits Act
LBeamtVG MV
Mecklenburg-Western Pomerania State Civil Servants' Pension Act
LBesG MV
Mecklenburg-Western Pomerania State Salary Act
LBG MV
Mecklenburg-Western Pomerania Civil Service Act
LBGG MV
Act on Equality, Equal Participation and Integration of People with Disabilities
LDG MV
Mecklenburg-Western Pomerania State Disciplinary Act
LehVDVO MV
Ordinance on the Preparatory Service and the Second State Examination for Teaching Qualifications at
Schools in the State of Mecklenburg-Vorpommern
LeistbVO FHöVPR MV
Ordinance on performance-related pay and research and teaching allowances for professors in grade W2 at
the University of Applied Sciences for Public Administration, Police and Administration of Justice of the State
of Mecklenburg-Western Pomerania
Lfd.
Ongoing
LHA
State Main Archive (Schwerin)
LHG MV
Mecklenburg-Western Pomerania State Higher Education Act
LHO MV
Mecklenburg-Western Pomerania State Budget Code
13 December 2024 Page 16 of 366
13 december 2024
Abbreviation
Meaning
LMinG
Mecklenburg-Western Pomerania State Ministerial Act
LParlG
Act on the Legal Relationships of Parliamentary State Secretaries
LSt
Wage tax
According to
According to
LTO
Linear Tape Open
LuP
Load and performance tests
MAE
Additional expense allowance
MAP
Employee portal of the state of Mecklenburg-Vorpommern
Max.
Maximum
MFA
Multi-factor authentication
Mon.-Fri.
Monday to Friday
MTW
Collective labour agreement for forestry workers of the federal states and municipalities
MV= MV
Mecklenburg-Western Pomerania
MV Network CN LAVINE
National network (corporate network), operated by DVZ
MV service portal
Application platform of the state of Mecklenburg-Vorpommern for citizens
MVP
Minimum Viable Product
NAnpG MV
Mecklenburg-Western Pomerania Salary and Remuneration Non-Adjustment Act
No.
Number
O. ä.
Or something similar
OAuth
Open Authorisation
OCR
Optical Character Recognition
OEH
Organisational unit
OLG
Higher Regional Court
OSCI
Online Services Computer Interface
PAJA
Annual analysis of personnel expenses
P-File
Personalakt
PAMA
Monthly analysis of personnel expenses
PAN
Postal billing number
PIN
Personal identification number
13 December 2024 Page 17 of 366
13 december 2024
Abbreviation
Meaning
PKH
Personnel cost extrapolation
Car driver TV-L
Collective agreement on the working conditions of car drivers in the federal states
PNR
Personnel number
PPM
Name of the payment procedure
PRINCE2
Projects in Controlled Environments
ProFiscal
Name of the HKR IT procedure at the time of the tender, specialised procedure renewal currently being
planned
PV
Long-term care insurance
QA
Quality assurance
RAV
Pension information procedure
RBK
Role and authorisation concept
Ref.
Unit
REST
Representational State Transfer
RiA
Pensioners abroad
RRefUBeihV MV
Regulation governing the maintenance allowance for legal trainees
RTF
Rich Text Format
RV
Pension insurance
rvBEA
Request pension insurance certificate electronically
RZK
Role and responsibility concept
Sat. + Sun.
Saturday and Sunday
SaaS
Software-as-a-Service
SAML
Security Assertion Markup Language
SBOM
Software Bill of Materials
SCL
Structured Control Language
SG
Soldiers Act
SGB
Social Code
SOAP
Simple Object Access Protocol
SolZ
Solidarity surcharge
SSO
Single Sign on
SST
Interface
13 December 2024 Page 18 of 366
13 december 2024
Abbreviation
Meaning
SSV
Records management service of the LAF
Tax PAP
Control programme flowcharts
SUrlV
Special leave ordinance
SV
Social security
SvEV
Social Security Remuneration Ordinance
SZG MV
Special Payment Act MV
TAN
Transaction number
TBL
Budgetary authority
TdL
Collective Labour Agreement of the German Federal States
TR
Technical guideline
TR-ESOR
Long-term storage to preserve evidence
TV Prakt-L
Collective agreement on the regulation of working conditions for interns in the federal states
TVA-L-Forest
Collective agreement for forestry trainees in forestry administrations, institutions and companies of the
federal states
TVA-L BBIG
Collective agreement for trainees of the federal states in training occupations under the Vocational Training
Act
TVdS-L
Collective agreement for dual students of the federal states in training-integrated dual study programmes
TV-Entgelt-U-B/L
Collective agreement on deferred compensation for federal and state employees
TVF
Collective agreement forestry
TV-Forst
Annex to the TV-L-Forst, which acts as a "reading version" of the latter
TV-L
Collective agreement for the public service of the federal states
TV-L-Forestry
Collective agreement regulating the working conditions of employees in forestry administrations, institutions
and companies of the federal states
TVÜ-Forestry
Collective agreement on the transfer of state employees from the scope of application of the MTW/MTW-O
to the TV-Forst and on the regulation of transitional law
TVÜ-L
Collective agreement on the transition of state employees to TV-L
Among others.
Among other things
Etc.
And so on
UV
Accident insurance
v.H.
From the hundred
13 December 2024 Page 19 of 366
13 december 2024
Abbreviation
Meaning
VBL
Federal and state pension scheme
VBS
Transaction processing system
VerfRi-IT-HKR
Procedural guideline for the use of IT procedures in the budgetary, cash and accounting system in the state
of MV
VermBG
Fifth Capital Accumulation Act
VersAusglG
Pension Equalisation Act
VLTG MV
Supply Burden Sharing Act Mecklenburg-Western Pomerania
VLT-StV
State treaty on burden sharing
VM
Virtual machines
VS
Classified information
VV
Administrative regulations
VwVfG MV
State Administrative Procedure Act
FTE
Full-time equivalent
WCAG
Web Content Accessibility Guidelines
XÖV
XML in public administration
z. B.
For example
ZDG
Civilian Service Act
ZfA
Central Allowance Centre for Retirement Assets
ZIA
Central information and enquiry centre
ZMV
Paying agent notification procedure
ZPO
Code of Civil Procedure
zSDV
Central master data management
ZUSY
Allowance system
ZV
Supplementary pension
ZV-KapANA
Contribution-free converted current remuneration
13 December 2024 Page 20 of 366
13 december 2024
IV. Glossary
The terms used are clearly defined in the glossary:
Term
Definition of
24/7 operation
The specialised application can be used 24 hours a day, 7 days a week, provided there is no
malfunction preventing operation.
Billing tables/billing-specific tables
Tabular representation of payroll objects, which are available at the client in the form of pay
tables, salary tables, allowance tables, time allowance tables, among others.
Downward compatibility
Interoperability with an older system version or with inputs that were developed for such an older
version.
Deviation
Identification of a difference between the application and the specification or test case.
Acceptance arrangement
Physical or electronic order instructing a cash register to accept and post a payment.
Entitled persons
Persons with an entitlement to administrative services.
Application
Programme for IT systems such as computers, smartphones or similar, which fulfils a specific, non-
system-related function (e.g. word processing, image processing, database) for the user.
Work basket
Serves as a central virtual overview and entry point for processing relevant processes and the
associated tasks.
ArchiSafe module
Abbreviation for the TR-ESOR-M.1 module, which comprises all functions that serve to realise the
input interface of the TR-ESOR middleware and to control and monitor access to the ECM/long-
term storage by external, upstream IT applications. The primary purpose of the ArchiSafe module
is the implementation of a reliable security gateway for communication - and thus also the
decoupling of external applications - with an ECM/long-term storage system, the regulation of the
information flow in the TR-ESOR middleware and the control of the functions provided by the TR-
ESOR middleware for the long-term preservation of the evidential value of cryptographically
signed documents
Audit trail
Audit-proof documentation of all data changes.
Task
Process step, part of a process.
Offsetting
In the case of offsetting, the employer's/principal's claims from overpayments to the employee
are offset against the employee's claims for remuneration. The employer's/principal's claim is
offset against future salary payments, taking into account the garnishment exemption limits.
The offsetting (declaration) is a unilateral declaration of intent by the employer/principal that
does not require the consent of the employee.
13. December 2024 Page 21 of 366
13 december 2024
Term
Definition of
Consumption and distribution
model
In the depletion model, allocations are tax-free until the tax-free lump sum is reached. The
alternative to the consumption model is the distribution model. Here, the tax-free amount is
divided into equal monthly instalments over the available months.
Exclusion criterion
In short: A criterion. The requirements relevant to an award are referred to as criteria. These
criteria are divided into different groups for the purpose of prioritisation. The exclusion criteria, or
A-criteria for short, refer to requirements that lead to the exclusion of the respective bidder if
they are not met.
Disbursement order
Instruction to make a payment.
Batch job
Collection of similar tasks that are processed automatically.
Batch mode
Automatic processing of batch jobs.
Tree structure
Hierarchical representation of data in computer science in which, starting from a root element,
each element is hierarchically linked to (usually two other) elements.
Users
Persons with application rights. By assigning an application right, users gain access to the relevant
applications or application functions.
Special electronic mailbox for public
authorities
In short: BeBPo. Mailbox in accordance with Section 6 of the Electronic Legal Transactions
Ordinance, by means of which authorities can communicate digitally in a technically secure
manner; for example, for the transmission of documents to courts.
Inventory system
The LAF software currently used for the purpose of salary processing consists of the FABEA
software, the office portal, the DMS "Domea", a scanning solution based on the KOFAX Capture
software for input/output management and the employee portal.
Company pension Pension scheme
Refers to all financial benefits that an employer promises its employees for old-age provision,
provision for surviving dependants in the event of death or for disability or incapacity for work.
Operational hindrance
This is the case when the utilisation of the overall system is significantly restricted.
Operational readiness
The usability of the overall system in accordance with the service description with regard to
system provision, functionality and non-functional requirements.
Operating manual
An operations manual describes all relevant measures and data required to maintain operations
for each IT component.
Defect preventing operation
This is the case when the use of the entire system or a significant part of it is impossible or severely
restricted.
13 December 2024 Page 22 of 366
13 december 2024
Term
Definition of
Evaluation criterion
In short: B criterion. The requirements relevant to an award are referred to as criteria. These
criteria are divided into different groups for the purpose of prioritisation. Non-fulfilment of
evaluation criteria does not lead to the exclusion of the respective bidder. If evaluation criteria (B
criteria) are fulfilled, the bidder collects evaluation points, which have a positive effect on the
bidder evaluation.
Rating points
Points that are collected with the (partial) fulfilment of B criteria and increase the chance of being
awarded the contract. B-criteria can be assessed in binary form (0 or 10 points) or in a staggered
manner, e.g. 0, 3, 6, 10 points for different degrees of fulfilment.
References
Remuneration is a generic term for benefits paid by the employer to its current or former
employees, which are to be settled using the HR system. Remuneration includes pay, salary,
pension and retirement benefits.
Payments processing
Application for and processing of benefits.
Cover component
The remuneration of a personnel case is made up of various components, such as basic salary,
performance-related pay, family allowance, bonuses, etc.
Relevant data
Data required for applying for and processing benefits.
Reference key
Scheme for calculating and distributing remuneration.
Reference value
The reference figure is a dynamic calculation parameter from which other values are derived that
are significant in the individual social insurance branches. The reference figure is based on the
average salary of all pensioners in the old federal states in the previous year.
BIC Directory
Directory of registered BICs including associated names and addresses.
Blended learning
Refers to a learning approach in which different training formats are combined in order to convey
content adequately.
Build pipeline
Standardised process for the (at least partially automated) compilation, provision, testing and
integration of software packages in the application environment, including the tools used.
BundID
Central federal account for identification for many public administration online applications.
Business Intelligence
In short: BI. Business intelligence describes business analytics, i.e. the procedures and processes
for systematically analysing the organisation. This includes the collection, evaluation and
presentation of data in electronic form.
13 December 2024 Page 23 of 366
13 december 2024
Term
Definition of
Business Process Model and
Notation 2.0
In short: BPMN 2.0. The Business Process Model and Notation (BPMN) is an industry standard of
the Object Management Group (OMG), is used for the graphical representation and modelling of
business processes and is used to model processes. BPMN 2.0 is the most widely used modelling
standard in public administration.
Client-Server
Description of the relationship between two computer programmes. In this relationship, one
programme, the client, requests a service from the other programme, the server, as a result of
which the latter provides the service.
Common Vulnerabilities and
Exposures
In short: CVE. Naming convention for security vulnerabilities and other weaknesses in computer
systems, the aim of which is to avoid multiple naming of the same threats.
Corporate Design
Visual appearance of an organisation.
Customising
See definition in EVB-IT System GTC. See also Configuration and Modification.
DAKOTA
Communication server currently used in the DVZ.
Data migration
Transfer of data from one storage system or data processing environment to another.
DEUEV-A1 application
Proof of social insurance in the home country to be provided by the employee in the event of
temporary employment in another European country. The Data Collection and Transmission
Ordinance serves as the legal basis.
Office
Users of the system from offices in the MV state administration and other employers for whom the
LAF provides services. These access
The system accesses the entire system, in some cases via a technically separate software module
for the transmission of relevant documents.
Direct departmental access
The offices of the state of Mecklenburg-Vorpommern can access the HR system directly via a role.
Office portal
Software module that is technically separate from the HR system for the transmission of relevant
documents from the departments to the HR system.
Length of service
-
Total length of service from recruitment to termination of employment
-
Duration of daily working hours.
Document type
Classification of documents based on technical and organisational characteristics.
Document storage location
Document storage path.
Document management system
In short: DMS. Database-supported management of electronic documents in which the
documents are fully text-indexed, i.e. searchable, e.g. as PDF files.
Dark processing
Business processes that run completely automatically in the background without human
intervention.
13 December 2024 Page 24 of 366
13 december 2024
Term
Definition of
Electronic Akt
eFile for short. A digital data collection that is modelled on conventional files (on paper). The
structure of electronic files follows that of physical files: File cover sheets, tabs and registers are
provided for eFiles in most applications.
Electronic signature
Data in electronic form that is attached to or logically associated with other data and ensures the
identification of the signatory.
End of Life
Refers to the point in time at which the manufacturer ceases development or, later, support for a
product. It is synonymous with the end of maintenance (EOM).
End date of support
In short: EOS. Refers to the point in time from which support services are no longer provided for a
product.
End-to-end test
Checking workflows from the end user's perspective. This involves checking the processes from
the start, through all the programmes involved, to completion.
Deferred compensation
A portion of the gross remuneration is converted into a company pension entitlement of equal value.
Development principle
It is not based on the emoluments actually paid, but on the emoluments to be claimed.
Error
A defect can be an unfavourable deviation from the intended or normal state in the specification
of the application or the test case. In the event of a programme error, a defect is recorded.
Fictitious calculation
Fictitious calculation of the remuneration of a personnel case based on the existing calculation-
relevant data. Calculation takes place parallel to the productive system so that productive data is
not changed.
Free text field
Input field that can accept and display any character string input.
Functional requirement
Specification of a function or the behaviour of an application
Function test
See definition in EVB-IT System-AGB.
Monetary advantage
Benefit in kind from the employer/principal that the employee/civil servant receives in addition to
the salary/salary.
Complete system
See definition in EVB-IT System-AGB.
The described components of the overall system and their interaction are illustrated in Chapter
3.1.1 in Figure 2.
Transaction note
A business transaction note is a work/sight note or processing note with an indication of the
sequence mark and the current date on a document.
Business process
The business process (workflow) defines the time-logical sequence of activities (tasks) that serve a
specific purpose and are directly related.
13 December 2024 Page 25 of 366
13 december 2024
Term
Definition of
Business distribution plan
A business allocation plan is a set of rules that determines which internal organisational unit of the body
is responsible for processing a specific matter in the case of collegial bodies.
Business transaction
A business transaction is an event that influences the company's asset situation, not only in terms
of increases and decreases, but also changes (transfers). Every business transaction is the reason
for a posting.
Go-live support
After acceptance of the overall system, ongoing professional and technical support for the
administration and operation of the overall system in addition to the system service.
Graphical User Interface
In short: GUI. Graphical user interface that makes application software operable using graphical
symbols or control elements.
Basic data
Personal master data for a data record (e.g. the name of a partner).
Principles of proper accounting
In short: GoB. These are written (HGB and UGB) and unwritten (case law, science and
recommendations from associations) rules for bookkeeping and accounting.
Budget, cash and
accounting
In short: HKR. In the automated procedure for the budget, cash and accounting system of the
state of Mecklenburg-Vorpommern (HKR procedure), all measures for implementing the budget
are to be posted in a hierarchical system of interlinked posting centres.
Budgetary burden
Sum of the postings that record when payments are made or owed.
Budget centre
The budget centre is made up of the sub-identifiers section, chapter, title and sub-account.
Budget title
The lowest level of government budget organisation in the grouping plan.
Heuristic testing
Testing user interfaces for usability problems.
HKR procedure
Automated procedure for the budget, cash and accounting system of the state of Mecklenburg-
Vorpommern.
Housing
Variant of SaaS in which the Contractor uses "appliances" provided by it for the operation of the
overall system, consisting of hardware and software of the overall system, which are housed in the
Client's data centre.
HR system
system as part of the overall system for checking entitlements, calculating and authorising income
payments, the HR system also includes functionalities for the electronic Personalakt, to support
personnel management processes and job budget planning.
Hypervisor
Software for creating and running virtual machines.
Information Technology
Infrastructure Library
In short: ITIL. A collection of best practices for managing IT services and improving IT support.
13 December 2024 Page 26 of 366
13 december 2024
Term
Definition of
Inline commenting
Natural language explanation in the source code of an application
Input management
Procedure for the digital recording and processing of incoming data using ICR/OCR software that is
connected to the HR system via interfaces.
Integrity
In the context of information security, the term refers to ensuring the correctness, completeness
and consistency of data as well as the correct functioning of systems.
Intelligent Character Recog- nition
In short: ICR. Automatic text recognition that can also process handwriting.
IT service management
The set of measures and methods required to ensure the best possible support for business
processes through the use of modern ICT. At the LAF and DVZ, IT service management is aligned
with ITIL.
IT services
Services in the field of information technology.
Cash code
Key with 13 digits for unambiguous assignment to transactions (change cash register codes are
related to the original cash register code).
Causality test
Causality describes the relationship between cause and effect. As part of the causality test, the
extent to which an achieved effect can actually be attributed to the assumed cause is checked.
Child-related shares
Part of the remuneration of a personnel case, which is based on the number of children entitled to
child benefit.
Collaboration tool
Applications for communication and collaboration between the contractor, client and any other
project participants.
Communication platform
In short: KP. As part of the overall system (for benefits), consists of a web portal and an app
solution for submitting applications and documents and receiving notifications, as well as for
communicating with personnel cases and their authorised representatives or proxies.
ComServer
Data acceptance and distribution centres of the statutory health insurance and occupational
pension schemes.
Configuration
Settings via the application interface by the client
Account assignment
In accounting, account assignment refers to the definition of a posting record. During account
assignment, the accounts, the amounts to be posted and, if necessary, the cost centres are noted
on the posting document.
Cost and performance accounting
In short: KLR. This is a quick and rough overview of an organisation's financial situation. It does
not include any external performance processes, for example income from possible share trading.
Financial accounting is much more accurate here. In administration, the KLR functions primarily as
an instrument for budget modernisation.
Criterion
Mandatory exclusion criterion to be fulfilled (A criterion) or optional evaluation criterion to be
fulfilled (B criterion)
13 December 2024 Page 27 of 366
13 december 2024
Term
Definition of
LEBE.digital
LAF programme to modernise the digital processes for internal administration and accounting in
the state of Mecklenburg-Vorpommern.
Life cycle
Also known as the software lifecycle. As a rule, the cycle begins with a customer-side problem and
its analysis and ends on the customer side with the replacement of the software by a successor.
Slight defect
Is present when the use of the overall system is possible without or with insignificant restrictions.
See also Defect.
Right to read
With read access, a user or process can view the contents of a file or directory. Users with read
access can open and read the file, but cannot make any changes to it.
Linear Tape Open
Technology for backing up data on magnetic tape, which was developed according to open
standards.
Logging
Interfaces log their activities in a log file. This is known as logging.
Multi-client capability
Several clients can use a single instance (installed copy) of the process at the same time and must
not be able to view each other's data (completely independent from a functional and technical
point of view).
Deficiency
Failure to fulfil a requirement in relation to an intended or specified use [ISO 9000:2000]. The
defect can be categorised as preventing operation, hindering operation or minor. An error
constitutes a defect.
Manual intervention option
Manual intervention is understood to mean an action by the administrator, unless expressly
described otherwise in the respective request (e.g. intervention by centralised specialist
administration).
Mapping
Mapping is the process of mapping data elements in different data models. This also includes the
data transformation between data source and data target.
Mass supply source
Automated creation of supply information for a large number of people.
Media break-free
Data is transferred without having to change the source medium. Freedom from media
discontinuity is also guaranteed in part by electronic interfaces.
Multiple employment
A personnel case has several legal relationships and/or claims in parallel,
z. e.g. an employment relationship and a civil servant relationship.
Milestone
Designate specific sub-goals or interim results, the expected achievement of which is reported
regularly and on an event-driven basis during the course of the project
Message object
Message that is transmitted for a personnel case via an interface.
Metadata
Additional information contained in electronic documents about features that describe the
location, date or security-relevant attributes.
13 December 2024 Page 28 of 366
13 december 2024
Term
Definition of
Minimum Viable Product
In short: MVP. The first minimum viable version of a product, which is used to learn from user
feedback and thus avoid undesirable developments.
Employee portal
Platform for electronic communication between the State Office of Finance MV and the personnel
cases of the State of MV.
Mitigation
Reduction of risks.
Co-taxation
Joint taxation of several taxable emoluments.
Co-operation services
All contractually agreed services provided by the client to the contractor during the project period
and also during operation.
Modification
Customisation at source code level as in EVB-IT System GTC.
Module
A module is a building block of a software system that is created during modularisation,
represents a functionally closed unit and provides a specific service.
Monitoring
The purpose of monitoring an interface is to obtain an overview of the activity of an interface. This
is, for example, the number of processed data records, error cases and performance values.
[Operational monitoring].
Net method
With the net method, the non-garnishable salary components are first deducted from the total
gross salary. The tax deductions and social security contributions are then notionally calculated
and deducted from the remaining amount. The remaining amount is the garnishable income from
which the garnishment amount is determined.
Non-functional
requireme
nts
In short: NfA. These are requirements that describe the way in which a system fulfils a specific task.
NfAs concern various areas, on the one hand the actual use of the programme, and on the other
also special aspects such as accessibility (BITV 2.09), or load and performance behaviour of the
software. On the other hand, there are the functional requirements, which are also defined in the
glossary.
Non-disclosure agreement
NDA for short. Refers to a confidentiality agreement between the client and contractor regarding
all written or verbal information relating to an order/project. The contractor undertakes to treat
all confidential information brought to its attention as strictly confidential, even after completion
of the order/project. Furthermore, the contract shall stipulate any exceptions to confidentiality,
the transferability of rights and obligations and contractual penalties.
Once-only principle
Data required for applying for benefits should only have to be transmitted once (single-entry
multiple use).
Optical Character Recognition
OCR for short. Refers to a process in which an image is converted from text into a machine-
readable text format.
Compliance concept
Part of the roles and rights concept, which defines the areas of responsibility of the persons and
bodies involved in the process and sets them out in relation to each other.
from one another.
13 December 2024 Page 29 of 366
13 december 2024
Term
Definition of
Organisation chart
Diagram in the form of a family tree that shows the structure of an (economic, political or similar)
organisation and provides information on the division of work or the assignment of certain tasks to
certain persons
Organisational unit
An element of the organisational structure shown in the organisational chart, such as a
department.
Output management
Creation, generation, control and distribution of electronic or physical documents to recipients.
Penetration test
Controlled attempt to penetrate a computer system or network from "outside" in order to identify
weak points.
Performance
Performance, efficiency.
Personnel case
Employees of offices in the MV state administration and other employers for whom the LAF
provides services, e.g. salary recipients, pension recipients or recipients of retirement benefits.
Personnel case type
Defines for each personnel case which master data is included in the HR system for a specific
personnel case.
Personnel
departm
ent
A personnel department is a department that manages the personnel, including the associated
Personalakt of the personnel cases.
Personalised calculation basis
All data of a natural person that is relevant for determining a value in the context of payments.
Personal property file
An independent structural element at the same organisational level as the Personalakt. Personal
documents that are not assigned to the Personalakt are filed here.
Person/contribution group key
Number combination (person group key = three digits; contribution group key = four digits), which
is made up of the contribution obligation of a personnel case in health, pension, unemployment
and long-term care insurance.
Plausibility check
Checking data/values/results for traceability/appropriateness.
Prince2
Projects in Controlled Environments -
Framework rules for project management in the currently valid version
Process follows system
Principle according to which the design of processes is aligned with the system used.
ProFiscal
Current HKR procedure of the state of MV.
Programming/Scripting
Automated sequence of different commands that can be executed by programmes to perform
recurring tasks without the involvement of personnel.
Progressive
Chronological progression.
13 December 2024 Page 30 of 366
13 december 2024
Term
Definition of
Project documentation
Compilation of selected, essential data on the configuration, organisation, use of resources,
solutions, process and goals achieved by the project.
Test tasks
Tasks that include a test order.
Response time
Period within which the contractor confirms a reported error and begins to rectify the error.
Regular operation
Intended use.
Release
See definition in EVB-IT System-AGB.
Reports
General term for all systematically prepared reports containing information relevant to decision-
making and management to meet the information needs of report recipients (in particular for the
creation of transparency and the preparation and monitoring of decisions).
Representational State
Transfer
In short: REST. Architecture style for the development of web services.
Resource
A resource is defined as all file types and content that can be created or ablegen in the BI
repository, including standard BI reports, ad hoc reports, domains, topics, XLSX files, PDF files, etc.
Retrograde
Chronologically regressive.
Revision security
The verifiability of the integrity of (often digital) data and the traceability of its changes over time.
Risk
A risk is an event or a group of events whose occurrence is uncertain, but whose occurrence will
have an impact on the achievement of objectives. It is made up of the probability that the
recognised threat or opportunity will occur and the extent of the impact on the objectives.
Role
A role in the environment of IT systems is generally used for technical abstraction, in particular for
grouping users with the same properties, functions and tasks and for bundling authorisations so
that not every user has to be granted the individual authorisations to resources required to
perform their functions or tasks.
Roles and rights concept
Document for defining access, entry and editing rules for users and user groups.
Recalculation depth
Period in the past that is taken into account in the corresponding transaction.
Sabbatical
Temporary form of part-time employment with an accumulation phase/work phase and a release
phase. The release phase is "saved up" over a longer period of time by continuing to work the
previous working hours during the work phase with a proportionately reduced salary.
Key number
By entering/selecting a key number, an associated entry is to be called up via a catalogue.
13 December 2024 Page 31 of 366
13 december 2024
Term
Definition of
Writing right
With write authorisation, a user or process can change the content of a file or directory. This
includes editing existing data, adding new data or deleting existing data. In the case of directories,
write permission allows the user to create, delete and rename files within the directory.
SCL Directory
Directory of payment service providers used for the automated processing of SEPA payments.
Self-customising
The client independently customises a product of the contractor.
Self-service
The personnel case, authorised representative or authorised representative is provided with resources
to solve problems themselves without the need for interaction with the client or the personnel
department.
SharePoint
Web application from Microsoft that enables data to be saved, structured and shared, among
other things.
Shell script
Executable text file with commands for the computer, used for "Programming/Scripting".
Signature
Cf. electronic signature.
Simple Object Access Proto- col
In short: SOAP. Message protocol that enables communication between the distributed elements
of an application.
Single sign-on
In short: SSO. Identity solution in which multiple applications use the same authentication session
and login data does not have to be entered multiple times.
Software Bill of Materials
In short: SBOM. Formal recording of the components of a software product and their relationship
to each other.
Software-as-a-Service
In short: SaaS. Licence and sales model in which the customer can use software via a cloud, while
the hardware and software support remains with the provider.
Special service contract
Contract under which a higher classification is made than formally provided for.
Master data
Data that contain basic information that may be required by several users.
applications could be used🡪 Master data management.
13 December 2024 Page 32 of 366
13 december 2024
Term
Definition of
Master data sheet
The master data sheet is a document that generally contains the following information:
Surname, first name, gender, job title, organisational unit, BVL grade, EG / BE, personnel number,
birth name, place of birth, date of birth, nationality, marital status, severely disabled status, child
Surname, first name, child date of birth, address, telephone, type of employment (incl. hours per
week), e-mail
When a person is hired, the complete master data sheet must be issued to the respective person; a
complete master data sheet must be issued at the request of the employee; staff councils can
request master data sheets - but possibly only with currently valid contracts.
Only relevant contracts and scopes of employment as well as remuneration/salary are handed over
to co-determination bodies.
Master data management
Holds shared personal master data as part of the overall system,
Standard
Standard means that the bidder can implement the respective requirements without
customisation at source code level. The standard is also fulfilled if a bidder has implemented the
same functionality, e.g. in accordance with a different national law.
Standard and customised software
See definition in EVB-IT System-AGB.
Vacancy list
The instrument for monitoring compliance with the establishment plan is described in VV No. 3.1
This is called the "statement on position monitoring". In practice, this is referred to as the staffing list.
Every department that manages posts is obliged to keep staffing lists, separately for civil servants and
employees.
Sampling control procedure
Method in which a representative selection of a test quantity is tested.
Stored procedures
Command with which a sequence of stored commands is executed.
Incident
Event in which the intended function of a system is (in)directly jeopardised.
Malfunction
See definition in EVB-IT System-AGB.
Syntactic and semantic
testing
Checking the correct use and connection of words.
System component
The system components include the HR system, the communication platform, the office portal
and the document management system (DMS).
System parameters
System parameters can be used to customise certain software functions to the customer's
requirements. They can be either cross-client or client-specific.
Tolerances
Acceptable level of deviation.
Separation requirement
Specifies that different environments can be defined separately.
13 December 2024 Page 33 of 366
13 december 2024
Term
Definition of
Overpayment
A payment made without legal grounds, which must be reclaimed.
Usability test
Checking the usability of software or hardware.
Acting / Ablage
Storage of documents in the (electronic) Akt.
Net comparison
Current net pay subject to contributions prior to the claim for social benefits, which the employer
transmits to the statutory social insurance institutions in the form of a certificate of remuneration
for the calculation of social benefits.
Settlement notice
Overview of the payment of family-related benefits.
Offsetting
In the case of offsetting, the employer's/principal's claims and the personnel case are offset
against each other. The claim of the employer/service provider is offset against
existing/retroactive salary payments without taking into account the garnishment exemption
limits after the consent of the personnel case.
Beneficiary statement
Document that is issued when a civil servant/judge retires and receives retirement benefits and is
similar to a pension certificate.
Four-eyes principle
Form of control in which activities and decisions must be confirmed by two people.
Prior service
Activities that were performed before the start of the employment or service relationship and are
taken into account in the pension.
Transaction processing
Timely and logically coordinated activities from the creation to the completion of several tasks.
Web Content Accessibility
Guidelines
In short: WCAG. Standard for the accessible design of websites.
Web server
"Intermediary", which transmits content and documents from websites to clients such as a
web browser.
Web service
A web service enables machine-to-machine communication based on HTTP or HTTPS via computer
networks such as the Internet. Data is exchanged and functions are called up on external
computers.
Recovery time
See definition in EVB-IT System-AGB.
Resubmission
A pre-defined date on which a task is to be displayed again by the system to the user for further
processing.
Effectiveness data
Information about the time of a data change.
Knowledge database
A knowledge database is a central online library of further links to information on a product, a
service, a department or a topic created in the KP of the LAF, which can be accessed by all
personnel cases and is expanded by the Central Specialist Administration.
Workflow
Description of the individual activities within a process.
Workflow management
Definition and control of workflows and the associated processes for processing operations
[operation control].
13 December 2024 Page 34 of 366
13 december 2024
Term
Definition of
Workflow modelling engine
Program for modelling workflows.
XML in public administration
In short: XÖV. Describes the technical standards for the electronic transfer of information between
authorities in Germany.
Payment realisation
Payment realisation includes the creation of the payment transaction file and the associated
posting file for salary payments and salary postings by the HR system and transfer of the files to
the payment transaction system and the posting system. Payment processing also includes the
processing of confirmations from the booking or payment system by the HR system.
Payment-relevant
docum
ents
All documents relevant to the authorisation of payments and the payment process.
Drawing process
Refers to the sequence of documentation of individual processing steps in administrative action as
defined in Article 20 (3) of the Basic Law.
Time month
Covers a period of 30 calendar days.
Centralised specialist administration
IT control centre (specialist administration) to carry out and manage access and authorisations for
employees as well as specialist configurations of the application.
Conclusion of aggregation
Court order for the aggregation of all of a person's income. All of a person's income is totalled in
order to determine, for example, an attachable amount or the amount of maintenance.
Additional component
Additional programmes or programme parts that extend the existing software with optional
functions.
13 December 2024 Page 35 of 366
13 december 2024
1 Introduction
The Mecklenburg-Vorpommern State Office of Finance (hereinafter referred to as LAF) is responsible for, among other things:
- the remuneration of employees, trainees and interns,
- the salaries and emoluments of civil servants (including judges, members of the state government, candidates) and
- the pensions of retired civil servants/judges and former members of the state government and their surviving dependants
- the old-age pension for those entitled to it
of the employers of the Federal State of Mecklenburg-Vorpommern listed in Annex 1.1 (Offices).
The LAF's Pay Department is responsible for fulfilling these tasks and is therefore also the direct point of contact for all HR
departments of these employers. The Pay Department uses FABEA as the main specialist procedure for the fulfilment of its tasks.
This main subject procedure must be replaced.
Chapter 2 of the terms of reference provides an overview of the project. It outlines the initial situation for the tender and
presents the LAF as the procurement office and the procurement system currently in use. Based on this, the subject of the
tender, the objective of the process modernisation, the legal framework conditions and a rough time and project plan are
described and the stakeholders to be considered are named.
Chapter 3 presents the modular target system. This is followed by a description of the process-related interaction of the system
components of the overall system and their functionalities based on the presentation of the global specialised process for the
processing of payments.
Chapter 4 lists the functional requirements. The requirements are grouped thematically. Requirements labelled as exclusion
criteria (A criteria) must be fulfilled by the contractor; failure to confirm fulfilment of even just one A criterion will result in the
bidder being excluded from the award procedure. Requirements labelled as evaluation criteria (B criteria) must be fulfilled.
Failure to fulfil an evaluation criterion does not lead to the exclusion of a bidder, but influences the performance evaluation of
the bidder's offer by the contracting authority (client).
Chapter 5 contains the non-functional requirements for the overall system and the system components. With regard to the
requirements in Chapters 5.1 to 5.8, it should be noted that these are formulated against the background of on-premise
operation of the overall system by the state's IT service provider, Datenverarbeitungszent- rum Mecklenburg-Vorpommern GmbH
(hereinafter referred to as DVZ), on behalf of the client. If the contractor is able to provide a SaaS operating model, this operating
model can be offered instead or in addition (by submitting two main offers). The requirements of the chapter
5.1 to 5.8 for a SaaS operating model accordingly, unless expressly stipulated otherwise. Chapter 5.9 also contains
supplementary, SaaS-specific requirements.
Chapter 6 describes the requirements for project implementation and realisation.
Chapter 7 describes the scope of the delivery items to be submitted by the contractor at the time of submission of the tender as
well as supplementary delivery items within the scope of the project work.
13 December 2024 Page 36 of 366
13 december 2024
Chapter 8 provides an overview of the annexes to the service description.
13 December 2024 Page 37 of 366
13 december 2024
2 Initial situation and objectives
2.1
Initial situation
Payments procedure
The LAF has launched the "LEBE.digital" programme to modernise financial processes. This includes the projects for the future
calculation of allowances, business trip accounting and the replacement of the existing specialised remuneration process. The aim
of this tender is to procure a modern and future-orientated overall system for the processing of remuneration. As part of the
programme, the LAF is also pursuing the introduction of IT service management in accordance with the Information Technology
Infrastructure Library (ITIL) and the highest standards in terms of data protection and information security.
The LAF currently uses the FABEA IT procedure to process payment transactions. The IT operation and development of this
procedure is carried out by the IT service provider of the public administration in Mecklenburg-Vorpommern, the DVZ. Originally
developed more than 40 years ago with Adabas/Na- tural for a mainframe host, the process has since been adapted many times
and transferred to server-based operation. Due to the now outdated technological basis and the expiry of support for individual
modules in 2028, there is an urgent need to replace the process completely. There is also a need to redesign technical processes
and replace parts of the system landscape (document management system (DMS), employee portal (MAP), departmental portal
(DSP)) that frame the procedure.
Salary benefits are based on the Salary Act for the State of Mecklenburg-Vorpommern (LBesG MV). Pension benefits are based on
the State Civil Servants' Pension Act MV (LBeamtVG MV). Remuneration benefits are based on various collective agreements, in
particular the collective agreement for the public service of the federal states (TV-L). In addition, a large number of other relevant
legal bases must be taken into account (see section 2.4).
ePAePV
The administrative regulation "Guidelines on the Management of Personalakts" was the normative basis for proper personnel file
management in the state administration. This was repealed in 2004 in the course of deregulation and the reduction of
bureaucracy. In "Part 1 - State Financial Report 2018" of the annual report of the Mecklenburg-Vorpommern State Court of Audit,
the Court recommends on page 233 et seq. that centralised regulations for personnel file management be drawn up and issued in
a timely manner, as the current lack of regulations has already led to findings by the State Court of Audit in the past for personnel
files in paper form. In accordance with the recommendations of the State Court of Auditors, standardised and legally compliant
personnel file management should be ensured before the introduction of an electronic Personalakt.
The aim of the "Introduction of ePA/ePV" project is to implement an electronic Personalakt and an electronic personnel
administration system throughout the state administration of Mecklenburg-Vorpommern. This will avoid or eliminate media
discontinuities with existing systems. Searching for information will be considerably speeded up by technical aids compared to
paper files. Furthermore, the logistical effort for storage and sorting is minimised.
13 December 2024 Page 38 of 366
13 december 2024
The ePA/ePV is intended to provide an interface to the electronic payroll and benefits procedure (LEBE.digital). Personnel
administration data is to be processed centrally in future. Data that is required by both the personnel administration departments
and the LAF, e.g. for payroll purposes, only needs to be entered once, at the personnel administration department. It should also
be examined whether interfaces to other digital processes of the state administration can be ensured.
As part of the introduction of an ePA/ePV, the business processes in personnel administration are to be optimised and
standardised. While existing Personalakts in paper form are to be transferred to the electronic Personalakt as far as possible, it is
desirable that the data from EPOS 2.0 is migrated to the new electronic personnel administration in an automated process.
Furthermore, the digitalisation of Personalakts can make a significant contribution to increasing data protection, for example
through greater transparency, traceability, integrity and deletability of data and by taking digital sovereignty into account.
The two projects are to be merged on the basis of the knowledge gained during the negotiation procedure for references (highly
integrated systems, same group of bidders, etc.).
2.1.1
Allocation of tasks in the LAF in relation to the remuneration procedure
The implementation and supervision of the procedure are organisationally separated in the LAF into a reference office and a
control centre. The judicial office and, in particular, supervisory bodies may also use the procedure.
2.1.1.1
Quantity structure
It is assumed that the number of active civil servants in the state of Mecklenburg-Vorpommern will remain roughly the same from
18,638 in 2023 to 2028. In 2023, 9,251 pension recipients were registered. According to current calculations, this number will
increase to around 13,000 in 2028. The 25,598 recipients in 2023 are expected to fall to around 24,600 in 2028. As a result, this
means that around 57,000 personnel cases are expected to be settled in 2028. The personnel cases will be managed by approx.
650 personnel administrators in the respective departments of the state administration.
2.1.1.2
The LAF payment centre
A total of 84 clerks, including three examiners, work in Department 2 (Remuneration) with one department head to process
remuneration, salary and pension benefits. Of these, department group 20 (salaries, pensions, allowances) has one department
group manager, 42 administrators and department group 21 (remuneration) has 40 administrators.
In Departments 200 and 201 (civil servants' salaries), 18 clerks calculate the salaries, one the supplementary insurance and two
the area of principle - special tasks. They are supervised by two heads of department. Department 203 (pensions) is staffed by a
head of department, 12 clerks, one clerk for the state treaty and burden sharing, one clerk for the area of basic rates - special
tasks and two clerks for the administrative office.
13 December 2024 Page 39 of 366
13 december 2024
The remuneration services are processed by the department group with two clerks in the area of basic rates and one clerk for the
office with three departments (210, 211, 212) with three department heads of 30 clerks and three clerks in the area of basic rates
- special tasks. (See Annex 1.2 (organisation chart))
Around 5,500 new personnel case files are created each year and a total of around 17,000 personnel case file tasks are processed.
2.1.1.3
The LAF control centre for the remuneration procedure
In the LAF's IT control centre for remuneration procedures (Department 61) (specialist administration), 2 policy officers and 13
administrators are responsible for the FABEA remuneration system and the peripheral systems (DMS, DSP, MAP) grouped under
the title BEATA. Their tasks relate to support and policy matters (including the creation and maintenance of work instructions) in
the preparation, development and application of the IT pay procedures, the DMS, the departmental portal and the employee
portal.
2.1.2
Current remuneration procedure FABEA
The current data processing in the DSP and LAF is explained below.
2.1.2.1
Data of the departments
In the offices, the personnel data (master data) is entered by the administrative staff using forms in the office portal (DSP)
currently in use and transmitted to the LAF. In some cases, depending on the rights assigned by the DSP, the dual control check is
carried out in the department in charge of personnel. Plausibility checks are carried out automatically for the respective forms.
The reported data is transferred manually at the LAF.
The DSP is also used to transfer monthly payroll statements (e.g. unpaid remuneration) via CSV files to the FABEA remuneration
system for dark processing (automated processing of business processes).
2.1.2.2
Data from personnel cases
Personnel cases must report certain changes to their personal data in order to keep their master data up to date. For this
purpose, forms must be used which can be provided with attachments (supporting documents). These can be submitted via the
current MAP or by post (fax, e-mail). The reported data is transferred manually to the LAF.
2.1.2.3
Cover processing
Documents with notifications of changes to data that form the basis for the pay calculation are created by personnel cases and
their departments using forms. These can be submitted by personnel cases by post, e-mail or fax, as well as via the employee
portal. The departments send the new entries by courier or post. Subsequently, the employee portal is used to notify changes to
the data (a personnel number is required).
Documents sent by post are scanned in the Service Centre for Document Management (SSV) and then made available in the DMS
as an inbox folder in the same way as emails or faxes. The portals provide the transmitted documents directly as an inbox folder
in the DMS.
13 December 2024 Page 40 of 366
13 december 2024
Applications and other documents arrive in electronic form or as centrally scanned paper documents via digital mail folders in the
work baskets of the DMS for processing. Furthermore, the clerical staff can manually import digital documents into the DMS.
The assignment of the incoming mail folder to the responsible processing department is done by reading out the personnel
number of the personnel cases.
The processing department checks the information and the necessary documents supporting the application. The relevant data or
changes to it are entered manually into the accounting programme via screen masks.
The programme calculates the emoluments taking other (master) data into account. Some calculations (e.g. pension
determination before pension payments are made) cannot be carried out in FABEA. The administrative staff carry out these
calculations in Excel solutions programmed for this purpose or manually. They then enter the results manually in FABEA.
2.1.2.4
Sampling control procedure
The audit group carries out a randomised cross-sectional audit before the remuneration is paid out. The scope of this cross-
sectional review is determined by internal instructions.
2.1.2.5
Data preparation and output
Once the remuneration has been calculated, the processed transactions are prepared for payment, in some cases with
verification. Payment-relevant documents (e.g. payment notifications, EDA notifications, payroll lists) are created.
Depending on the dispatch channel selected in FABEA, the documents for the personnel cases are sent to the MAP for
transmission via an interface or they are printed by the data processing centre from FABEA and sent to the personnel cases. It is
also possible to send them internally or to transfer them for printing and external dispatch to the LAF's document management
service (SSV).
Budget postings are transferred to the IT procedure for budget, cash and accounting (HKR procedure) via an interface.
Personnel case-related documents are made available in the accounts of personnel cases that use the MAP. Postal dispatch is
also automated if the receiving person does not retrieve a notification that triggers a deadline via the MAP within 10 days.
2.1.2.6
Actuation
The document management system (DMS) from the modular BEATA
1
is used, which is a reference system-specific development
spin-off from the national master DOMEA
2
. It uses personnel numbers as identifiers and central metadata and maps the
electronic remuneration file as a personnel case file. A personnel case file is created for each pay type for each personnel case.
The DMS contains work baskets that serve as virtual desks for the day-to-day work of clerical staff. These documents can be
sorted from the worklist into the personnel case file.
1
BEATA stands for "Electronic instruction, transport and storage of payment data"
2
DOMEA stands for "Document management system and electronic archiving in IT-supported business processes"
13 December 2024 Page 41 of 366
13 december 2024
Some of the documents created, such as the remuneration notifications, are automatically ablated in the personnel case file.
2.1.3
Subject of the tender
The tender comprises the creation of an overall system for salary processing, digital personnel management and digital personnel
file management.
- from the receipt of relevant data and documents for the personnel management of personnel cases and departments,
- about their processing
- and the payment calculation
- through to the audit-proof storage of output data and documents
- and their transfer to output management,
- the fulfilment of reporting obligations,
- the option of creating a wide range of analyses and
- the output management itself, if applicable.
Chapter 3 provides an overview of the target system.
With regard to the creation of the overall system, the subject of the tender also includes the following services, among others:
- Preparation and submission of the required concepts in accordance with chapter 7.2
- Connection of the OCR/ICR software used for the specialised aid procedure.
- Contribution to the LAF's data protection and IT security concept, taking into account the need to protect personnel and
payroll data.
- Advice on adapting the client's existing business processes to the procedural requirements of the new overall system.
- Implementation of interfaces in accordance with the defined requirements (chapter 5.5).
- Making the entire system ready for operation, including installation and configuration of the supplied software components,
including customising for productive, reference and test environments as well as training environments (see section 5.7).
- Provision of comprehensive and target-group-specific training documents for the use and administration of the overall
system and the organisation of corresponding training courses.
- System service (in particular troubleshooting and regular provision of all new programme versions) for the entire system. In
the case of a SaaS operating model, the operation of the entire system is added.
- Carrying out or supporting data preparation and transfer (data migration).
2.1.4
Time and project planning
Figure 1 below shows a draft framework for the implementation of the overall system. It contains the key milestones.
The Contractor must submit a detailed project schedule with the offer (Section 7.1), which shows the time schedule for the
implementation of the individual system components and their integration into the overall system. Depending on the respective
product launch strategy and personnel deployment planning, the Contractor may also submit alternative proposals for the
sequence of milestones in the implementation schedule.
13 December 2024 Page 42 of 366
13 december 2024
phase and, if necessary, propose further milestones. It must be ensured that the time of the (partial) acceptance test of the
overall system is planned in such a way that without postponing the agreed milestones M01, M4 and M7 (provision for (partial)
acceptance of the overall system) and taking into account the client's resource availability (see chapter 6), sufficient time is
available for the client to test the system components individually (including re-test cycles) as part of the client's functional tests.
Figure 1: Project plan for the introduction of the overall system
Key milestones in project realisation
13 December 2024 Page 43 of 366
13 december 2024
No.
Milestone
Date (latest time points)
M01
Provision for partial acceptance Complete system Prio 1
The milestone is reached when the Contractor has provided the overall system ready for acceptance
by fulfilling at least the following requirements:
1.
Implementation of all A and B criteria with priority 1 according to the catalogue of
requirements
2.
Successful connection of the archive system including access to all existing documents of the
recipients (currently in TR-ESOR)
3.
Successful connection of the HKR and PPM, business trip and allowance processes to the HR
system.
4.
Successful connection of the relevant departments of the state of MV to the HR system
5.
Successful connection of the OCR/ICR software in use at the LAF to the HR system and
integration of the relevant functionalities into the overall system
01.08.2027
M02
Partial acceptance of entire system Prio 1
The milestone is reached when, after
1.
ready for acceptance by the contractor (see M01) and performance of a corresponding
functional test and
2.
The partial acceptance for Go-Live Prio 1 was granted by the client following the successful
implementation of trial migrations of all data required for the complete calculation of the
remuneration of all active personnel cases into the HR system by the contractor.
01.12.2027
M03
Go Live overall system Prio 1
The milestone is reached when
1.
the overall system has been successfully transferred to productive operation with regard to the
Prio 1 requirements and
2.
the migration of all data required for the complete calculation of the remuneration of all active
personnel cases into the HR system has been carried out by the contractor.
01.01.2028
M04
Provision for partial acceptance Complete system Prio 2
The milestone is reached when the contractor provides the overall system with priority 2 in
accordance with the catalogue of requirements, fulfilling all A and B criteria.
01.08.2028
M05
Partial acceptance of complete system Prio 2
The milestone is reached when the partial acceptance for the go-live of the overall system Prio 2 has
been issued by the client after provision by the contractor ready for acceptance (see M04) and
performance of a corresponding functional test.
01.12.2028
M06
Go Live overall system Prio 2
The milestone is reached when the overall system has been optimised with regard to Prio 2
requirements was successfully transferred to productive operation.
01.01.2029
13 December 2024 Page 44 of 366
13 december 2024
No.
Milestone
Date (latest time points)
M07
Provision for acceptance of the overall system Prio 3
The milestone is reached when the Contractor has provided the overall system ready for acceptance
by fulfilling at least the following requirements:
1. Implementation of all A and B criteria with priority 3 according to the catalogue of
requirements
1. Successful migration of master data from EPOS to the HR system
01.08.2029
M08
Acceptance of entire system Prio 3
The milestone is reached when the go-live of the overall system Prio 3 has been accepted by the
client after the contractor has provided the system ready for acceptance (see M07) and a
corresponding functional test has been carried out.
01.12.2029
M09
Go Live overall system Prio 3
The milestone is reached when the overall system has been successfully transferred to productive
operation with regard to the Prio 2 requirements.
01.01.2030
2.2
Objective
The overriding aim of the tender and the subsequent awarding of the contract is to ensure that the remuneration processing and
personnel management systems are fit for the future. Among other things, the focus is on the integration of the overall system
and its compatibility and efficient division of labour with other IT modernisation projects of the state of Mecklenburg-
Vorpommern and the LAF as part of the LEBE.digital programme. The objectives are more efficient and effective administrative
action, exemplary compliance with data protection and IT security requirements and an increase in user-friendliness in personnel
management in general and in the application and processing of benefits in particular. In addition, the aim is to reuse a
modernised input management system that is already provided in the aid process. With the help of the OCR/ICR software to be
connected, the documents submitted by post are to be made available to the HR system as validated data records for direct entry
and further processing.
In future, the expandability, connectivity and integration of the overall system in interaction with other personnel-related and
financial processes should be made possible, particularly with regard to standardised access (single sign-on) and central master
data management in accordance with the once-only principle.
The aim of modernising the procedure for processing payments is to automate the underlying processes as far as possible (dark
processing). By reducing manual activities, the aim is to relieve the workload on clerical staff, reduce errors and free up time for
qualified activities.
The aim is to provide a modern, high-performance and ergonomic overall system that brings digitalisation to life in the workplace.
Media disruptions are to be avoided in future.
13 December 2024 Page 45 of 366
13 december 2024
The departments are to be connected directly to the HR system. As end users, personnel cases should benefit from intuitive and
modern access channels for salary processing, personnel administration, short processing times and the prospect of networked
data (once-only principle).
With the introduction of the new procedure, the state of MV aims to take data protection and IT security requirements into
account to a special degree and thus act as a "beacon" for future projects. Among other things, it should be noted that the
personal and financial data transmitted requires a high level of protection in accordance with the GDPR and has a high level of BSI
trust. Finally, the introduction, maintenance and operation should take place within the framework of IT processes that have a
high degree of standardisation in accordance with ITIL.
During project implementation, the state of Mecklenburg-Vorpommern strives to optimise the use of resources (personnel,
technical, economic) through the overarching coordination of tasks, specialist knowledge and structures. These goals are to be
achieved through a positive management culture, joint iterative learning, transparency, communication and standardisation.
2.3
Stakeholders
Various stakeholders must be taken into account when designing and introducing the future overall system. These are described
below. As part of a roles and rights concept to be created, some of these stakeholders must be assigned corresponding roles (see
section 3.3).
2.3.1
Mecklenburg-Western Pomerania State Office of Finance
The LAF is an upper state authority within the remit of the Ministry of Finance of Mecklenburg-Vorpommern (hereinafter referred
to as the FM) with around 290 employees. Department 2 of the LAF is responsible for calculating and paying the salaries of
employees (remuneration), civil servants/judges (salaries) and pension recipients (pensions). Department 2 also calculates and
authorises the payment of benefits for employees in the event of illness and occupational accidents in the state of Mecklenburg-
Vorpommern. Furthermore, the tasks for the state administration in connection with central payment transactions, bookkeeping,
the function as a deposit fund and the processing of centralised travel expense processing for the state administration of
Mecklenburg-Vorpommern (LAF Department 4) are processed. Tasks as an enforcement authority in accordance with the Judicial
Debt Collection Act (JBeitrG) and for other public-law monetary claims of the state of Mecklenburg-Vorpommern (except taxes)
are also performed (LAF Department 5).
Division 2 is made up of the "Salaries, pensions, allowances" department group, the "Salaries, pensions, allowances" department group and the
"Salaries, pensions, allowances" department group.
"Remuneration" and the review group for the existing spot check procedure for specialised remuneration processing. Within the
departmental groups, pay applications, procedures and appeals are processed according to the assignment of responsibilities via
the personnel numbers of the personnel cases.
Appeals that cannot be fully resolved are processed by the legal department.
The IT department (LAF department 6) is responsible for the preparation, development and application of the IT procedures for
state aid and salary payments as well as the HKR and PPM procedures, for which the state administration of Mecklenburg-
Vorpommern is centrally responsible. The entire support of the existing payment system at IT level, including
13 December 2024 Page 46 of 366
13 december 2024
administrative, operational and strategic IT issues, takes place here. The information security officer is attached to this
department. Project management for the replacement of the procurement system is also the responsibility of this department.
2.3.2
Ministry of the Interior, Building and Digitalisation
The Ministry of the Interior, Building and Digitalisation of Mecklenburg-Vorpommern (IM) is responsible for digitalisation and
therefore the state's IT standards. The Ministry is a central player in the initiation of interdepartmental and inter-agency IT
projects and programmes. It must be involved in the design and follow-up of individual projects, such as the modernisation of pay
processing, by the management level.
According to the E-Government Act of MV (see Section 15 (3)), basic services must be used and state standards (in particular in
accordance with the IT Directive) must be complied with. These are usually financed centrally. If the aim is to deviate from these
standards, the ministry must be consulted.
The IM is responsible for amending the specialised personnel management procedure and introducing an electronic personnel
file.
2.3.3
Personnel departments
The LAF handles salary processing for the departments of the state of Mecklenburg-Vorpommern. The information required for
this, which contains official and in some cases personal data, is transmitted to the LAF by 109 personnel departments.
2.3.4
Ministry of Finance
The Mecklenburg-Vorpommern Ministry of Finance (FM) exercises official and technical supervision over the LAF. The FM is
involved within the framework of the project control structures. For projects, the LAF has coordination and information
obligations towards the FM. Furthermore, the approval procedure is carried out here in accordance with the LHO.
2.3.5
Data Processing Centre MV GmbH
The DVZ is the IT service provider of the MV state administration and is based in Schwerin. The shareholder of the independent
limited company is the state of MV. The DVZ provides the services assigned to it in the public interest for the state administration
in accordance with the "Act on the Legal Status of the Mecklenburg-Vorpommern Data Processing Centre (Data Processing Centre
Act - DVZG MV)" of 1 November 2000. The existing reference system and personnel management system EPOS2.0 is operated by
the DVZ.
2.3.6
State Court of Audit
The State Court of Audit is a supreme state authority and, as an independent body of financial control, is subject only to the law.
The State Court of Audit monitors the entire budgetary and economic management of the state and thus also the economic
implementation of the replacement of the existing remuneration system.
13 December 2024 Page 47 of 366
13 december 2024
2.3.7
Commissioner for Data Protection and Freedom of Information of the State of Mecklenburg-
Western Pomerania
The State Commissioner for Data Protection monitors and advises the state's public bodies on data protection issues on the basis
of Section 7 of the Federal Data Protection Act (BDSG), as the data used in the overall system is subject to a high level of
protection. The State Commissioner for Data Protection is informed about the status of the replacement of the payroll database
procedure in regular meetings by the head of the IT department of the LAF.
2.3.8
Data Protection Officer of the LAF
In addition to the State Data Protection Officer, the person responsible for data protection in the LAF and in the project
management team must be involved in data protection-related issues with regard to the future overall system.
2.3.9
Equal Opportunities Officer Working Group
The Working Group of Equal Opportunities Officers is a committee of equal opportunities officers from the ministries and the
State Chancellery. This body discusses current equality issues and provides assistance and information. The working group offers
participants a platform for exchanging experiences, expanding and deepening expertise and also a basis for networking. The
Equal Opportunities Officers are bound to secrecy and are not subject to directives in their function. They report directly to the
head of the department, which means that they have a direct right of subpoena but also a duty to report to the head of the
authority. They monitor and promote the implementation of the Federal Equal Opportunities Act (BGleiG) and the agreements in
the equal opportunities plan. They are involved in all personnel, organisational and social measures of their department in the
following areas from the outset:
•
Equality between women and men,
•
Compatibility of family and employment and
•
Protection against sexual harassment in the workplace,
•
Protection against discrimination and sexual harassment
2.3.10
Staff representation
2.3.10.1
Working group of the main staff councils
The main staff councils in the state administration form the Working Group of the Main Staff Councils (AG HPR). They represent
their members in matters that are of general importance and extend beyond the remit of a supreme state authority.
Personal data relating to personnel cases is processed in the overall system. The HPR working group must therefore be involved
in the modernisation and introduction of the system.
2.3.10.2
Working group of the local staff councils
The AG öPR is a committee made up of the local staff councils (AG öPR) of the ministries and the State Chancellery. The local staff
councils are to be informed and involved accordingly with regard to changes in the organisation of work resulting from the
introduction of the overall system.
13 December 2024 Page 48 of 366
13 december 2024
2.3.10.3
Representative body for severely disabled persons
When developing the future overall system, great importance is attached to ensuring that it is barrier-free. The Working Group
of Representatives for Severely Disabled Employees (AG SBV) is to be informed accordingly about the introduction of the system
and involved appropriately.
2.4
Legal framework conditions
The Contractor shall be responsible for ensuring that the future procedure enables the Client to process and
-accounting on the basis of the respective current
- federal and state regulations as well as directly applicable EU law,
- Administrative regulations and decrees (in particular anticipatory regulations) and
- Fundamental decisions of the ECJ, the supreme courts of the federal government and the supreme courts of the federal
states
(hereinafter collectively referred to as "regulations"). The same applies to personnel management. Changes to regulations shall
be implemented by the Contractor in the system on an ongoing basis until acceptance of the overall system as part of the project
service. Even after acceptance, the Contractor shall be responsible for incorporating the regulations and their amendments as
part of the system services. The transition periods must be taken into account in each case, e.g. the processing of applications
before a cut-off date under the old law.
The future contractor must take into account all relevant regulations, in particular the following:
1. Fifth Capital Accumulation Act (5. VermBG)
2. Equalisation of Expenses Act (AAG)
3. MPs Act MV (AbgG MV)
4. Fiscal Code (AO)
5. Occupational Health and Safety Act (ArbPlSchG)
6. Federal Remuneration Act (BBesG 2006+ Section 5)
7. Federal Data Protection Act (BDSG)
8. Civil Servant Status Act (BeamtStG)
9. Administrative regulations on the BeamtVG (BeamtVGVwV)
10. Federal Voluntary Service Act (BFDG)
11. German Civil Code (BGB)
12. Overtime Remuneration Ordinance (MVergV 2006)
13. Federal Statistics Act (BStatG)
14. Data Collection and Transmission Ordinance (DEÜV)
15. Service Anniversary Ordinance (DJubV)
16. German Judges Act (DRiG)
17. State Data Protection Act (DSG MV)
18. EU General Data Protection Regulation (GDPR)
19. Data Processing Centre Act (DVZG MV)
20. Parental Leave Ordinance (EltZLVO MV)
21. Continued Remuneration Act (EntgFG)
22. Income Tax Act (EStG)
23. Recreational Leave Ordinance (EUrlV)
24. Hardship Allowance Ordinance (EZulV MV)
25. E-Government Act Mecklenburg-Western Pomerania (EGovG MV)
26. Finance and Personnel Statistics Act (FPStatG)
27. Bailiff's Office Costs Ordinance (GVBkVO)
13. December 2024 Page 49 of 366
13 december 2024
28. Act on the Transition in the Salary Scales and Other Transitional Provisions of 4 July 2011 (Section 1)
29. Administrative regulation of the Ministry of Justice on the granting of advance salary payments to bailiffs for the
establishment of a business room (2017 - III 121c/2343 - 15 SH - VV Meckl.- Vorp. Gl. No. 2032 - 34)
30. Budgetary Principles Act (HGrG)
31. University Remuneration Ordinance (HsLeistbVO MV)
32. University Management Allowances Ordinance (HstZulV 2002)
33. Freedom of Information Act (IFG MV)
34. Information Costs Ordinance (IFGKostVO MV)
35. Youth Volunteer Services Act (JFDG)
36. State Old Age Pensions Act (LAltGG MV)
37. State Civil Servants' Pension Act MV (LBeamtVG MV)
38. State Remuneration Act MV (LBesG MV)
39. State Civil Servants Act MV (LBG MV)
40. MV State Disciplinary Act (LDG MV)
41. State Higher Education Act (LHG MV)
42. State Budget Code (LHO MV)
43. State Ministers Act (LMinG)
44. State Travel Expenses Act (LRKG MV)
45. Wage Tax Implementation Ordinance (LStDV)
46. State Relocation Costs Act (LUKG MV)
47. Minimum Wage Act (MiLoG)
48. 3rd Minimum Wage Adjustment Ordinance (MiLoV3)
49. Maternity Protection Ordinance MV (MuSchVO MV)
50. Online Access Act (OZG)
51. State Judges Act (RiG MV)
52. School Act (SchulG MV)
53. Soldiers Act (SG)
54. Third Book of the German Social Code (SGB III)
55. Fourth Book of the German Social Code (SGB IV)
56. Fifth Book of the Social Code - SHI (SGB V)
57. Sixth Book of the Social Code - GRV (SGB VI)
58. Special Leave Ordinance (SUrlV)
59. Special Payments Act MV (SZG MV)
60. Separation Allowance Ordinance (TGVO MV)
61. TV Apprentices (TVA-L BBiG)
62. Collective agreement for the public service of the federal states incl. Annexes A-G (TV-L)
63. Collective agreement regulating the working conditions of employees in the forestry sector (TV-L-Forst)
64. Collective agreement on the working conditions of car drivers in the federal states (TV-L car drivers)
65. Collective agreement on the transition of state employees to the TV-L including Annexes 1-5 (TVÜ-L)
66. Pension Equalisation Reimbursement Ordinance (VAErstV)
67. Earnings Statistics Act (VerdStatG)
68. Procedural guideline for the use of IT procedures in budget, cash and accounting in the state of Mecklenburg-
Vorpommern (VerfRi-IT-HKR)
69. Pension Equalisation Act (VersAusglG)
70. Pension Fund Act (VersFondsG MV)
71. Ordinance on the Determination of Percentages for Regular Additions to Special Assets
"Pension Fund of the State of Mecklenburg-Vorpommern"
72. Pension Burden Sharing Act (VLTG MV)
13. December 2024 Page 50 of 366
13 december 2024
73. State Treaty on the Sharing of Pension Burdens (Vlt-StV)
74. State Treaty on the Sharing of Pension Burdens - Implementation Instructions (Vlt-StV)
75. Pension Reserve Act (VersRücklG MV)
76. Enforcement Remuneration Ordinance (VollstrVergV MV)
77. Code of Administrative Court Procedure (VwGO)
78. State Administrative Procedure Act (VwVfG MV)
79. Civilian Service Act (ZDG)
80. Code of Civil Procedure (ZPO)
81. DIN ISO 15489-1 Guidelines for quality-assured file management
82. LeistbVO FHöVPR MV
83. LParlG
84. NAnpG MV
85. General administrative regulations on state official residences
86. TV EntgO teacher
87. BVG - Federal Pension Act
88. Ordinance on the Certification of Charges
89. Pension Equalisation Reimbursement Ordinance
90. Church Tax Act of the State of Mecklenburg-Western Pomerania
91. Church tax resolutions
92. Church Tax Ordinance of the State of Mecklenburg-Western Pomerania
13. December 2024 Page 51 of 366
13 december 2024
3 General system description
The following chapter describes the various components of the overall system and their purpose.
Chapter 3.1 provides an overview of the system architecture. In addition to an outline of the target system, the network
connection, provision and installation as well as the system's quantity structure are defined.
Chapter 3.2 describes the use cases of the global specialised process.
Chapter 3.3 describes the different roles of the actors who are to access the system, each with different authorisations.
3.1
System architecture
3.1.1
Overview target system
Pay processing (salaries, pensions, remuneration and retirement benefits) is to be supported by a new, modern, efficient and
future-proof HR system.
The Personalakt is to be managed exclusively digitally in future. Personnel data should form the basis of personnel management
and must also be managed in the HR system.
The new overall system is characterised in particular by end-to-end digital personnel management and remuneration processing,
including
-
Processing of personnel transactions by all parties involved
-
Processing of payment transactions by all parties involved
-
access options for the various user groups in the departments, for payroll processing and personnel cases
-
Personnel case self-service, including inboxes and outboxes as well as an upload/download function for documents
-
Changing locations (i.e. switching between the office and home office) and using the system on different end devices
(desktop computer, smart phone and tablet computer) are supported in compliance with software ergonomic requirements
and without functional restrictions.
-
Consistent use of plausibility checks and default values, supported by queries from internal and external databases, among
other things
-
Provision of comprehensive import and export functions
-
Measurable reduction of paper processing in input and output
-
Functions for integrating a qualified electronic signature
-
Support for centralised master data management
-
Support of workflows (e.g. for approvals, authorisations, etc.) that can be defined and monitored/controlled depending on
rights
The overall system includes all functional components and modules that are relevant for testing, processing, simulation (e.g.
testing the effects of changes) and determining references. This includes in particular
-
Control of data input and output
-
Task and workflow management
13 December 2024 Page 52 of 366
13 december 2024
-
Workflow-based processing (including support for postal processes)
-
Management and Ablage of documents and processes in an integrated electronic file (DMS)
-
Pay processing (salaries, pensions and remuneration as well as retirement benefits) by the pay clerks and the administrative
staff in the departments
-
Review of transactions and documents (in particular formal review, plausibility check, random checks, dual control)
-
Preparation of communications and notifications
-
Analyses and statistics
-
Interfaces and reports to LAF systems, as well as authorities and organisations in the state of Mecklenburg-Vorpommern and
beyond.
The Contractor must ensure that the overall system to be delivered or its system components are connected to the neighbouring
IT systems via interfaces, insofar as this is necessary to fulfil the requirements from the service description. A detailed description
of the interfaces can be found in section 5.5. Existing interface functionalities of neighbouring IT systems should be used as a
matter of preference. In the event that interface functionalities cannot be used or are missing, the Contractor shall be obliged to
notify the Client of the steps required to rectify the situation by implementing, adapting and quality assuring the interfaces to be
created in the neighbouring IT systems. The Client shall then identify solutions together with the Contractor and the
manufacturers/operators of the neighbouring IT systems. In addition, the Contractor shall prepare interface documentation for
each interface between the overall system (or its system components) and the neighbouring IT systems in accordance with the
state of the art (e.g. component diagrams, interoperability model, etc.) and make it available to the Client.
As shown in the diagram below, the overall system is made up of the following main system components.
13 December 2024 Page 53 of 366
13 december 2024
Figure 2: Architecture of new overall system for remuneration processing and personnel management
-
Communication platform (KP) with self-service functions: This type of access is only possible via a login to the MV service
portal with the BundID. The personnel cases log in to the communication platform and can use the personnel and
remuneration self-service (online forms) and the mailbox.
-
Powerful user and rights management to be able to grant customised rights to people in different user groups. User groups
are system administration, central specialist administration, application support, auditing, authorised signatories, processing
and user personnel cases at KP.
-
Integration of the module for generating qualified electronic signatures and seals (e.g. for electronically sent documents,
scanned documents and for signing). The connection of the qualified electronic signature and the seal must be ensured.
-
Interface for transferring control files to the printing line ("SST Druck und Kuvertierung") of the DVZ or the LAF (LAF service
area for document management - SSV). Mass documents that are generated in the new HR system are printed at the DVZ
and handed over to a postal service provider of the LAF. It is also necessary for documents to be sent to the LAF's SSV for
printing. In the case of a SaaS solution, the mass printing and dispatch of documents is carried out by the contractor.
-
13 December 2024 Page 54 of 366
13 december 2024
-
Master data management
Provision of centralised master data management and maintenance in the HR system's integrated database. Consideration
of the HR system as the leading system with centralised master data management with the following features:
•
Centralised master data system for personnel management including payroll accounting.
•
Master data from other leading specialised procedures is included in the HR system's integrated database. The data is
maintained and updated via the respective specialised procedures.
-
Document management system. The data must be entered into the DMS in the form of an electronic file for each personal
case.
-
Import and export APIs for relationship-specific system and master data. The contractor shall ensure that the overall
system provides APIs for importing data from the previous FABEA and EPOS2.0 payroll system into the new HR system and
freely configurable options for ad hoc data export from the overall system in common file formats.
-
Evaluation component (BI tool) for creating configurable analyses based on existing data. Such analyses include, for
example, lists of fixed-term employment relationships with information on the end of the fixed term and the reason for the
fixed term, analyses of absences of all kinds (illnesses, leave of absence, parental leave, etc.), analyses of current part-time
employment relationships.
3.1.2
Network connection
The connection of the various users of the departments as well as the LAF and personnel cases takes place via the state-wide
public authority network CN-LAVINE of the state of MV as well as via the (public) Internet via VPN tunnel to the public
authority network.
While authorised users from the departments and the LAF can access the HR system directly via a login, it is planned to
provide personnel cases with access to the documents and data relating to them via a separate communication platform (KP
for Pay).
1. Access to the HR system
a. for offices and salary processing with the office PC via CN-LAVINE directly (application on site in the offices) or
via the Internet/VPN in CN-LAVINE (mobile working)
b. with the service PC for departments located in a separate network (e.g. LAPIS) by means of a transition to the
CN-LAVINE network provided there.
2. The communication platform is accessed from the CN-Lavine network and the Internet.
3.1.3
Provision/installation
Two operating models are possible: SaaS and on-premise.
3.1.3.1
On-premise operating model
In this operating model, the new procurement system is set up and operated in the form of virtual machines (VM) in data centres
of the DVZ MV. The virtualisation should use container technologies wherever possible.
13 December 2024 Page 55 of 366
13 december 2024
use. If no container solution is used, but operation based on VMs in the data centre is pursued, the virtual machines of the
virtualisation environment (hypervisor) must be based on VMWare ESXI. The virtualisation basis must be designed by the
contractor in such a way that, in the event of a VM instance being unavailable (e.g. failure of a physical or virtual server), a hot-
standby VM instance can take over the reference service without any restrictions on availability or functionality and without any
loss of data. Once the contract has been awarded, the contractor must draw up an architecture concept that demonstrates the
following:
1. Rough conception of the interfaces
2. Distribution of components and modules to servers and the communication relationships between the
servers.
3. Sizing the server
The contractor shall ensure the operational readiness of the overall system with the co-operation of the DVZ (see number
2.3 Annex 1.3 EVB-IT System Contract (Variant on Premise)).
3.1.3.2
SaaS operating model
The overall system, including the DMS and central master data management, must be set up and operated in the SaaS operating
model as data protection and cyber security-compliant systems with high availability at the contractor. The required benchmarks
for determining the availability of the software can be found in the non-functional requirements. The required availability of the
productive system is currently defined in chapter 6.3.1 (requirement DT02.05
3
). (See also Annex 1.4 EVB-IT System Contract (SaaS
variant).
In the "Housing" SaaS variant, the Contractor shall provide "appliances" that are operated by it in the data centre of DVZ GmbH.
For the definition of this operating model and the related co-operation services and provisions of the DVZ, see Annex - Housing
co-operation services.
To enable a network connection to the country's basic components, the HR system should have access to the federal network
(NDB).
3.1.3.3
Surroundings
The overall system must be provided in the following environments:
- Productive environment
- Reference environment
- Test environment
- Training environment
3
VK2 according to BSI
13 December 2024 Page 56 of 366
13 december 2024
3.1.4
Quantity structure
Currently, around 90 administrators in the "Remuneration" area are responsible for calculating salaries, wages and pensions and
around 650 HR administrators are responsible for personnel administration for 18,638 civil servants, 25,598 employees and 9,251
pension recipients (values as at 31 December 2023). Based on the current user numbers, the following table shows the order of
magnitude for the user groups of the overall system.
User group
Direct access to
HR system
Access to the communication
platform
Number of
users
Persons
Maximum simultaneous
number of users
nes
Processing in the departments,
including supervisors, interest
representatives and other process
managers
involved
x
1.500
800
Payments processing head
office
Specialist administration (LAF)
x
200
180
Process support (DVZ)
x
x
20
5
Personnel cases
x
57.000
15.000
Table 1: Forecasted user figures for the new overall system
3.2
Description of use cases of the global specialised process
The global specialised process of the overall system is presented and described below. This is viewed from three perspectives:
- CV supervision (entry of the personnel case into the state administration, changes to the employment relationship (with
effects for the LAF) and departure of the personnel case)
- Data view (data enters the HR system, is processed and leaves the HR system)
- Time perspective (time dependencies and cycles of technical inputs and outputs)
The process descriptions illustrate the sequence of higher-level process steps for remuneration calculation and how the overall
system with its central system components (KP, OCR/ICR software (provision), HR system, etc.) ensures their realisation. Due to
the abstract nature and the mapping of similar process components, no distinction is deliberately made between the specialist
areas of pay, benefits and remuneration. The strategic goal is to standardise processes as far as possible whenever analogous
processes between the departments are appropriate.
The following descriptions are intended to provide an overarching understanding of the CO for the respective processes. In the
event of contradictions or ambiguities, the underlying specific requirements in chapter 4 are decisive.
13 December 2024 Page 57 of 366
13 december 2024
Figure 3: Global specialised process - CV view
Figure 4: Global specialised process - data view
13 December 2024 Page 58 of 366
13 december 2024
Figure 5: Global specialised process - time view
3.2.1
Communication platform (KP) (self-service)
The process-triggering event is the request of a personnel case, for example to change their data or to create and/or process one
or more applications/declarations. For this purpose, the KP is to be provided as a functional platform. The necessary data should
be entered step by step via this platform. Documents created in the HR system, such as salary notifications and tax certificates,
are made available in the communication platform. For the time being, the possibility of submitting applications/declarations by
post with the associated attachments and the provision of documents in paper form via the LAF pay office or the HR centre is still
planned in parallel.
When using digital document transmission, the personnel case logs in to the KP web portal or app with their valid registration
data. They start a new process or call up a (temporarily) saved application or the notification from the payroll or personnel
centre. Additional documents/receipts must be uploaded to the KP web portal or photographed using the app and digitised in
PDF/TIFF/JPG format. The documents are read out for further processing as part of input management (see section 3.2.2).
13 December 2024 Page 59 of 366
13 december 2024
3.2.2
Input management
Input management includes the receipt of incoming postal or electronic documents, the scanning of incoming postal documents,
content capture using OCR/ICR software from incoming postal and electronic documents, the manual validation of the captured
content and finally the transfer of data records to the HR system.
The process steps required for input management are carried out in the LAF. To support greater automation, existing OCR/ICR
software is used, which has so far primarily been used in conjunction with the specialised aid procedure. With the help of this
software, document recognition, the assignment of documents to document types and the recording of relevant data, which is
transferred to the HR system for further processing, are largely automated.
Incoming forms and forms plus attachments - Incoming mail (mainly paper and KP for references)
Forms and forms and other documents relevant to the HR system reach the LAF both by post and electronically via the KP. Mail
received by post is processed by the SSV clerical staff. They open the incoming mail and prepare the documents for scanning (e.g.
documents are unstapled, unstapled and flattened).
Scanning
Scanning should also take place in the SSV. High-performance scanners are used to scan all incoming postal documents relating to
payroll accounting, Personalakt or personnel administration immediately after they are received. Replacement scanning in the
LAF provides for a retention period of 6 months for paper-based documents. Once this period has expired, the documents are to
be destroyed. This replacement scanning process in the SSV is based on the technical guideline
"BSI TR 03138" from the Federal Office for Information Security (TR-RESISCAN).
The SSV uses scanning software. Successfully scanned batches of documents are sent to the OCR software.
/ICR software. Accompanying metadata, such as the image files created during the scanning process, are signed and exported in a
qualified manner.
Content capture
The documents sent in by post are scanned in the client's scanning line and the data is made available to the OCR/ICR software.
The OCR/ICR software automatically carries out document typing and reads out the relevant content. This also applies to the
documents sent via the KP. The OCR/ICR software provides the recognised content in XML files or files in alternative text file
formats, which it attaches to the respective image files.
Validation or subsequent correction
In addition to the incoming mail and scanning, the validation and correction of the documents received by the OCR system is also carried out.
/ICR software in the LAF.
The OCR/ICR software flags results that it classifies as relatively uncertain. The flagged results are viewed manually during
validation and, if necessary, adjusted based in part on suggestions provided by the OCR/ICR software. It is also possible to
manually adjust all other results from the OCR/ICR software in connection with a submission.
Handover
13 December 2024 Page 60 of 366
13 december 2024
Following validation, the data records are transferred from the OCR/ICR software to the HR system. One data record is
transmitted per submission, which includes image files and XML files or files in alternative text file formats.
3.2.3
Cover processing
Pay processing is described below based on the rough procedural sequence of processing and the involved and supporting
functional components. A prerequisite for the determination of remuneration in manual system-supported and automated
procedures (dark processing) is the involvement of personnel processing in the departments and the reading of data from
submitted personnel case documents into input management. The process steps and business transactions shown (the title of
each subsection refers to the requirement categories listed in Figure 2) describe the general procedure. The resulting specific
requirements with regard to individual process steps for verification and calculation are taken into account in the respective
requirement categories (see Chapter 4).
Distribution
Assignment to individual work baskets is automated by the task management rules based on criteria defined by the central
specialised administration (e.g. responsibility for certain personnel numbers) or manually from an inbox. The aim of the
distribution is to assign tasks for manual processing to the administrator. The worklist serves as a central overview for clerical
staff and is also the entry point for processing relevant processes and associated tasks. In addition to the distribution of tasks to
individual task areas, it is also possible to define and trigger workflows for the dark processing of applications and declarations as
part of task control.
Data entry and check for completeness/form-compliant application
Data must be recorded in the HR system in order to process remuneration. Data is entered via various input channels (OCR/ICR
software, communication platform (self-service) and data import via other interfaces) as well as by entering data by the HR
departments (direct departmental access) or by the LAF processing department. Selection/key/reference directories, among
other things, support the input process to enable further processing of the data. It is expected that the majority of data will be
entered via the self-service of the communication platform or the departments in future.
Plausibility check
In the next step, the HR system supports processing with an automated plausibility check on several levels. The plausibility check
is designed to avoid input errors, particularly when entering data. The processing department is notified of any anomalies
together with the corresponding reference. The plausibility checks increase the quality of the data for further processing.
Calculation
If there are no objections to the check steps, the HR system uses the relevant data to automatically calculate the various
remuneration, salary, pension and retirement benefits using rules based on the statutory and collectively agreed regulations. The
processing department checks the following
13 December 2024 Page 61 of 366
13 december 2024
The LAF checks the (interim) results as required and corrects the relevant data manually if necessary, for example by overwriting
the data entered in the system. It should be emphasised that a double check of data entries (both in the respective department
and in the LAF) is not provided for. Personnel data is regularly checked and corrected in the organisational unit in which it was
entered. If manual corrections are made to the input data, a new plausibility check is carried out. It must also be possible to
manually correct the master data recorded for remuneration (e.g. number of years of service, number of children, bank details).
Document creation
Documents are created for various calculation steps and for results. These should preferably be provided with standardised text
modules and can be supplemented with free text fields for individual formulations. Among other things, the remuneration
notification in accordance with the Remuneration Certification Ordinance is automatically created as a document as a result of
the remuneration calculation. This should also contain text modules.
Four-eyes check
In accordance with VV No. 1.1.2 §§ 70-80 LHO MV, transactions justifying payments are subject to a dual control check.
The HR system must ensure that certain payment-related tasks are checked by a second person. These include, for example, new
hires, revival cases, rate changes The tasks to be checked must be configurable by the Central Specialist Administration in the HR
system according to task type and amount limits.
The dual control principle must be integrated into the HR system by means of a workflow, taking into account all exceptions in
the LHO VV. It must be ensured that transactions to be checked only justify a payment after confirmation by a second person
responsible for this.
In the event of a complaint, the task is sent back to the processing department for correction using the workflow in the HR system
and a note is made of any necessary corrections. After a new check or a check without objections, the clerk releases the process.
If the HR system processes an operation in dark processing (criteria are configured by the system taking into account the above-
mentioned administrative requirements), no dual control check is carried out, subject to the risk analysis.
Dark processing
The strategic aim of dark processing is to automate task management, where permitted by law and where it makes sense in
terms of content. It is therefore possible to initiate dark processing on the basis of configurable criteria as part of task
management. The dark processing process can be regarded as an automated process of system-supported remuneration
processing without clerical processing, from the order to the creation of the remuneration notification. The HR system performs
all the functions autonomously in the context of dark processing that are assigned to clerical processing in the context of manual
system-supported task processing. The necessary prerequisites for dark processing are high-quality data digitised by input
management and interfaces, complete (master) data and plausibility checks carried out without any anomalies. The dark
processing process can be defined and modelled as far as possible as part of a workflow. Further manual processing of tasks by
the clerk is possible, for example if data is missing or anomalies occur during processing.
13 December 2024 Page 62 of 366
13 december 2024
Sampling control procedure
The HR system must establish the implementation of a random sample control procedure in accordance with LHO §§ 70 to 80:
No. 6.4. It must enable a targeted cross-sectional check of processed but not yet released transactions. The HR system selects the
processes using check criteria to be defined. The person carrying out the check checks the processes, documents this in the
processes and releases the processes or returns them to the department with a note about necessary corrections. After
correction, requests for which changes have been made are automatically checked again.
Payment/making payment
The process of paying and posting remuneration takes place outside the HR system. The HR system prepares this process by
providing the data relevant to payment and posting. Payments are posted to the designated budget items in the state budget
using the HKR procedure. There is no individual posting, but a total posting across all data records generated for payment. For the
bank-relevant payment, an individual payment transaction file must be generated for the salary payments to be made (PPM
procedure).
Acting
Within the scope of the lactation, the letters and documents created (including salary notifications, notices, cover letters) are
stored in a DMS as part of the overall system to be delivered. In the DMS, the applications, receipts, notifications and other
documents must be filed in the Akt assigned to the personnel cases. In accordance with Section 84 para. 2 sentence 3 LBG MV,
each stored electronic document must be provided with a qualified electronic signature in accordance with the Signature Act of
16 May 2001 (BGBl. I p. 876), last amended by Article 4 of the Act of 26 February 2007 (BGBl. I p. 179), as the file, which is
equated with a fully electronically managed Personalakt, does not require a paper form.
Output management
The documents created (including remuneration notifications, notices and letters) are forwarded as data records to the KP for
remuneration for dispatch by post to the DVZ printing line. There, the documents are printed centrally, enveloped and sent to the
addressees by an external service provider. Documents that trigger a deadline and are made available are sent by post if they are
not called up in the KP for payments within 10 days. A delivery note with a date is recorded when the documents are sent by post
or opened in the KP for Payments.
Objection handling
The objection handling processes must be mapped as downstream processes in the HR system. Personnel cases can lodge an
objection (only salary, pension, retirement benefit) or submit change requests with reference to the pay calculation. A complaint
can then be lodged (or in the case of remuneration). At the same time, costs for the various administrative procedures are
determined on application.
Objections and requests for amendments are examined by the department's administrative department. Appeals that are to be
rejected or that are to be partially remedied are further processed in the HR system by the legal department. Complaints and cost
assessments are also processed in the legal department.
13 December 2024 Page 63 of 366
13 december 2024
The result of the objection handling decision must be implemented in the HR system, including payment or reclaim.
3.3
Role description
This chapter describes the roles within the overall system. This is a rough description of roles and activities, which must be further
differentiated in the implementation phase in cooperation with the provider with regard to the design of the respective system
components in the new overall system.
3.3.1
System administration
Responsibility:
- System operator (DVZ)
Tasks:
- User administration of the centralised specialist administration (see 3.2.2)
•
Setting up, configuring and deleting user accounts
•
Setting up, configuring and cancelling restricted administration rights (e.g. user administration only, specialist
administration only, certain system settings only)
- Technical administration of the overall system
o Manage instances
o Create and manage clients according to the client concept
o Ensure the function of the interfaces
- Ensuring and monitoring ongoing operations
o Monitoring
o Patch management
o Service management
Rights:
- Read and write authorisation with regard to the above-mentioned configurations or configuration files.
3.3.2
Centralised specialist administration
Responsibility:
- LAF MV (Department 61) and other position(s) - set up by the system administrator
- Specialist administration per department
- Technical administration Communication platform
- Cross-departmental user administration of application support
- User administration within the LAF
Tasks:
Interdepartmental specialist and user administration
- Specialist administration
•
Administration of calculation constants (e.g. pay groups) and categories (e.g. inspection categories)
•
Configuration of the department's system settings
•
Administration of master data (e.g. office numbers)
13 December 2024 Page 64 of 366
13 december 2024
•
Administration of forms/templates (if still required)
•
Administration of catalogues
•
Administration of the data fields released for departments (e.g. definition of default values)
•
Inclusion of new data fields in the specialised procedure
•
Coordination with interest groups on new data fields
•
Administration of technical plausibility checks
•
Execution of batch jobs and direct functions (e.g. holiday transfer)
•
Change of responsibilities (e.g. in the case of departmental reorganisations)
- User administration of application support in the departments and the LAF (see 3.3.4)
•
Set-up, configuration and deletion of user accounts including representation rights
•
Setting up, configuring and deleting rights to objects (e.g. personnel cases, service units) depending on organisational
responsibility
- Support/application support
•
1st level support LAF,
•
2nd level support LAF
•
2nd level support services
•
2nd level support communication platform
•
Coordination of troubleshooting in cooperation with system administration and, if necessary, software manufacturer
•
Possibility to rectify simple application problems (e.g. reset password, unlock blocked accounts)
Rights:
- Specialist administration:
•
Read and write access to all system areas relevant for technical administration (e.g. catalogues, forms, office master
data, etc.)
- User administration:
•
Read and write authorisation (set up, configure, change, delete) with regard to the administration of the above-
mentioned user accounts
3.3.3
Department-specific specialised administration (ePAePV)
Responsibility:
- Personnel administration in the departments - set up by system administration
- Technical administration per department
- Technical administration Communication platform
- Departmental user administration for application support
- User administration within the department
Tasks:
- User administration of application support for the department
- Specialised administration (objective: to ensure compliance with the minimum standards of uniform working methods for
personnel administration in the departments).
•
Administration of department-specific catalogue content
•
Configuration of department-specific system settings
•
Administration of department-specific master data (creation of departments)
13 December 2024 Page 65 of 366
13 december 2024
•
Administration of department-specific forms/templates
•
Coordination with interest groups on new data fields
•
Request new department-specific data fields in the specialised procedure from the central specialist administrator
•
Release of department-specific data fields
- Implement organisational features of the respective departments
- Support/application support
•
Recording of errors reported by the departments' application support.
•
Troubleshooting or forwarding to the central specialised administration
•
Acceptance of new requirements from the departments' application support and forwarding to the central
specialised administration department
- If necessary, coordination with official data protection officers and responsible interest groups (department-specific)
Rights:
- Department-specific specialised administration:
•
Read and write access to all system areas relevant for technical administration (e.g. catalogues, forms, office master
data, etc.)
- User administration:
•
Read and write authorisation (set up, configure, change, delete) with regard to the administration of the above-
mentioned department-specific user accounts
3.3.4
Application support for the departments
Responsibility:
- Personnel departments - set up by the central specialised administration (remuneration) or
Department-specific specialised administration (ePAePV)
- At least one application manager per department
Tasks:
- Department-specific or service-specific user administration of auditing, authorised signatories and processing within the
assigned departments
•
Set-up, configuration and deletion of user accounts for auditing, authorised signatories and processing
•
Setting up, configuring and cancelling user rights and responsibilities (functional and object rights) depending on the
respective responsibility according to the business allocation plan or other responsibility regulations (e.g. responsibility
decrees)
▪
Object rights (which personnel case can be accessed):
o User number, office number(s), employment or legal relationship, occupation
salary and pay grades, career groups, law enforcement service, allocation of special PNR, etc.
▪
Functional rights (what the user can do):
o are covered by the role of processing or authorised signatory (write permission,
Read authorisation, save, release)
o additionally upload analyses, files if necessary
13 December 2024 Page 66 of 366
13 december 2024
•
Setup, configuration and deletion of user groups (hierarchies and dependencies of authorised signatories and
processing - dual control principle)
•
Setting up, configuring and deleting substitution assignments
o Preconfiguration according to GVP
- Application support in the sense of the 1st service level
•
Support (decentralised) within the departments or services for troubleshooting and, if necessary, contacting application
support/support LAF
•
Fixing simple application problems (e.g . resetting passwords, unlocking blocked accounts)
- Recording of requirements and change requests and forwarding to the departmental specialist administrator (ePAePV) or
central specialist administration (remuneration)
- If necessary, coordination with official data protection officers and relevant interest groups
Rights:
- Read and write authorisation with regard to the administration of the above-mentioned accounts
- Read and write rights with regard to the administration of the departments assigned by the central specialist administration
(department catalogue) and the associated processing.
3.3.5
Application support for the communication platform
Responsibility:
- Central information and enquiry centre
Tasks:
- Application support in the sense of the 1st service level
- Support with troubleshooting and, if necessary, contacting the central specialised administration
- Troubleshooting simple application problems (e.g. resetting passwords, unlocking blocked accounts)
- Recording of requirements and change requests and forwarding to the central specialised administration
Rights:
- Read authorisation and, with regard to the above-mentioned tasks, limited write authorisation with regard to the
registration of all user accounts on the communication platform
3.3.6
Data protection check
Responsibility:
- Data protection officer, IT data protection officer
Tasks:
- Occasion-related review of compliance with data protection
- Reporting
Rights:
- Temporary read authorisation according to a specific check request (e.g. user accounts and personnel cases to be checked)
13 December 2024 Page 67 of 366
13 december 2024
3.3.7
Internal audit LAF
Responsibility:
- Internal audit of the LAF set up by the central specialised administration
Tasks:
- Checking all LAF organisational units connected to the HR system for compliance with the applicable legal and administrative
regulations and collective agreement requirements
- Examination of economic efficiency
- Checking the appropriateness and safety of the procedural and structural organisational regulations of individual
organisational units or work processes
- Checking the formal and material correctness of task processing
- Topic and process-specific checks of the processing procedures
- Assessment of technical processes and the tracking of sending and editing processes of the communication platform for
references
- Checking and analysing the log data
- Reporting
Rights:
- Right to read with regard to the specific test order
3.3.8
Internal Audit Departments
Responsibility:
- Human resources departments - set up by application support of the departments
Tasks:
- Checking compliance with the applicable legal and administrative provisions
- Assessing technical processes and reproducing transmission and work processes
- Examination and evaluation of departmental and service-specific log data
- Checking the expediency and safety of the procedural and structural organisational regulations work processes
- Reporting
Rights:
- Right to read the departmental or service-specific log data of the authorised signatories and processing of the assigned
departments
3.3.9
Revision of communication platform
Responsibility:
- Selected personnel cases - set up by central specialised administration
Tasks:
- Assessment of technical processes and the tracking of transmission and editing processes
- Checking and analysing the log data
- Reporting
Rights:
13 December 2024 Page 68 of 366
13 december 2024
- Right to read log data of KP users
3.3.10
Head of the Legal Department LAF MV
Responsibility:
- Legal department - set up by the central specialised administration
Tasks:
- Processing of legal matters and individual legal questions of the LAF MV
- Representation of the LAF in remuneration matters before the courts
Rights:
- Read and write authorisation for seizure/assignment/offsetting/insolvency/objection/complaint processes
- Right to read personnel case files in objection proceedings
- Task assignment
3.3.11
Seizure processing
Responsibility:
- Legal department - set up by the central specialised administration
Tasks:
- Processing of seizures/assignments/offsetting/insolvency
Rights:
- Read and write authorisation for seizure/assignment/offsetting/insolvency processes
3.3.12
Objection processing
Responsibility:
- Legal department - set up by the central specialised administration
Tasks:
- Processing of objections
Rights:
- Read and write authorisation for objection processes
3.3.13
Head of the Remuneration department
Responsibility:
- Management of the department - set up by the central specialised administration
Tasks:
- Managing the workload in the organisational unit
- Authorisation to sign - release of data
•
Checking the submitter's data from the LAF
•
Final release (payment authorisation, report creation, etc.) unless dual control is required).
13 December 2024 Page 69 of 366
13 december 2024
•
Release in the context of exercising the dual control principle
•
Refusal of release with the possibility:
▪
Request correction from the submitters from the LAF
- Independent creation of evaluations for the organisational unit
Rights:
- Creating documents (cover letters, notifications, etc.)
- Read permission for all tasks/operations of the organisational unit
- Write authorisation for the processes submitted for approval
- Right of signature for the transactions submitted for approval
- Task assignment
- Creating analyses
- Internal statistics retrieval
3.3.14
Head of processing in the personnel department
Responsibility:
- Management of the personnel department - set up by the central specialised administration department
Tasks:
- Managing the workload in the organisational unit
- Authorisation to sign - release of data
- Audit of the submitter's data (see auditor)
- Release in the context of exercising the dual control principle
•
Refusal of release with the possibility:
▪
Request correction from the presenter
Rights:
- Read permission for all tasks/operations of the organisational unit
- Write authorisation for the processes submitted for approval
- Right of signature for the transactions submitted for approval
- Task assignment
- Rights of the auditor, the SB signatory authority, SB 4-eye principle and SB4 eyes EUndDiszi
3.3.15
Head of department Remuneration and personnel
Responsibility:
- Management of the departmental groups - set up by the central specialised administration
Tasks:
- Management of the departmental group
- Managing the workload in the organisational unit
- Authorisation to sign - release of data
•
Checking the data of the submitters from the LAF
•
Final release (payment authorisation, report creation, etc.) unless dual control is required).
•
Release in the context of exercising the dual control principle
13 December 2024 Page 70 of 366
13 december 2024
•
Refusal of release with the possibility:
▪
Request correction from the submitters from the LAF
- Independent creation of evaluations for the organisational unit
Rights
- Creating documents (cover letters, notifications, etc.)
- Read permission for all tasks/operations of the organisational unit
- Write authorisation for the processes submitted for approval
- Right of signature for the transactions submitted for approval
- Task assignment
- Creating analyses
3.3.16
Head of department
Responsibility:
- Management of the department - set up by the central specialised administration
Tasks:
- Management of the department
- Managing the workload in the organisational unit
- Authorisation to sign - release of data
•
Checking the processing data from the LAF
•
Final release (payment authorisation, report creation, etc.) unless dual control is required).
•
Release in the context of exercising the dual control principle
•
Refusal of release with the possibility:
▪
Request correction for processing from the LAF
- Independent creation of evaluations for the assigned organisational unit
Rights
- Creating documents (cover letters, notifications, etc.)
- Read permission for all tasks/operations of the organisational unit
- Write authorisation for the processes submitted as part of the release process
- Right of signature for the transactions submitted for approval
- Task assignment
- Creating analyses
3.3.17
Sample inspection (inspection group)
Responsibility:
- Review group - set up by the central specialised administration
Tasks:
- Audit within the scope of the specified audit assignments and legal requirements
Rights:
- Right to read
- Authorisation to sign for submitted transactions
- Comment function for submitted cases
13 December 2024 Page 71 of 366
13 december 2024
3.3.18
Authorised signatory departments
Responsibility:
- Personnel departments - set up by the departments' application support or the central specialised administration
department
Tasks:
- Processing tasks (see Processing departments)
- Additional: Authorisation to sign - release of data (dual control principle)
•
Checking the entries of the assigned processing department
•
Release of data (is always required)
•
Also release of deletion notes in the investigation and disciplinary matters sub-file
•
Refusal of release with the possibility:
▪
Request correction from the processing department
Signatory authority within investigative and disciplinary matters
Rights:
- Access as for processing (see 3.3.21 Processing departments)
- Right of signature for the release of the submitted transactions
- Creating analyses
3.3.19
Processing for special tasks LAF
Responsibility:
- LAF processing for special tasks - set up by the central specialised administration
Tasks:
- Recording, maintenance, checking and processing of relevant data
•
Addition of the new recording
•
Changes/cancellations
•
Closure of personnel cases
•
Processing errors and processing obstacles
- Authorisation to sign - release of data
•
Examination of the submissions from the departments and from the communication portal
•
Final release (payment authorisation, report creation, etc.) unless dual control is required).
•
Release in the context of exercising the dual control principle
•
Refusal of release with the possibility:
▪
Request correction during processing from the office or the user of the communication platform.
▪
Carry out the correction independently (if necessary, with information to the processing department from the
office or with information to users of the communication platform.
13 December 2024 Page 72 of 366
13 december 2024
- Viewing standard analyses (e.g. budget burden)
- Independent creation of analyses for the assigned area
Rights:
- Creating documents (cover letters, notifications, etc.)
- Full access to the personnel cases of the associated organisational unit and the released data fields
•
Write (enter, change, delete)
•
Read
•
Save
•
Print
•
Upload attachments
- Creating analyses
- Right of signature for the release of transactions
3.3.20
LAF processing
Responsibility:
- LAF processing - set up by the central specialised administration
Tasks:
- Recording, maintenance, checking and processing of relevant data (manually or interfaces from previous
procedures/uploading of files)
•
Addition of the new recording
•
Changes/cancellations
•
Closure of personnel cases
•
Processing errors and processing obstacles
- Authorisation to sign - release of data
•
Checking the entries from the administrative departments and the personnel cases from the communication portal
•
Final release (payment authorisation, report creation, etc.) unless dual control is required).
•
Release in the context of exercising the dual control principle
•
Refusal of release with the possibility:
▪
Request correction during processing from the office or the user of the communication platform
▪
Carry out the correction independently (if necessary, with information to the processing department from the
office or the user of the communication platform)
- Viewing standard analyses (e.g. budget burden)
Rights:
- Creating documents (cover letters, notifications, etc.)
- Only full access to the assigned personnel cases and the released data fields
•
Write (enter, change, delete)
•
Read
•
Save
•
Print
13 December 2024 Page 73 of 366
13 december 2024
•
Upload attachments
- Right of signature for the release of transactions
3.3.21
Processing departments
Responsibility:
- Personnel processing departments - set up by application support of the departments
Tasks:
- Recording and maintaining data relevant to remuneration and personnel files
•
New admission of personnel cases
•
Changes/cancellations
•
Closure of personnel cases
•
Carry out personnel administration processes
•
Processing errors and processing obstacles
- Does not have the right to sign (recorded or deleted data that has already been signed must be released by the authorised
signatory)
- View the processing status of personnel administration processes
- Inspection of personnel cases that would fall under the responsibility of a deputy
- Maintaining the link from the personnel position to the budget centre
- Connection between person and post
- View the history of personnel administration processes
- Execute existing analyses
- Customise evaluation queries
- Transmission/release of data for the assigned personnel cases to the LAF
- Viewing the processing status (drawing process, processing in the LAF, payment initiated)
- Viewing the standard analyses (e.g. budget burden)
- Independent creation and saving of analyses for the assigned area
o Tasks in the ePA
o Create Personalakts/partial files
o Edit Personalakt files/partial files
o Add documents
Rights:
- Full access to the assigned personnel cases and the released data fields
•
Write (enter, change, delete)
•
Read
•
Save
•
Print
•
Upload attachments
- Creating analyses
3.3.22
Organisation processing
Responsibility:
- Organisational work
13 December 2024 Page 74 of 366
13 december 2024
Task:
- Creating and maintaining tasks of a duty station
- Creating and maintaining the organisational structure (workstations, organisational units, posts)
- Activity evaluations
Rights:
- Read authorisation for log data for assigned objects
3.3.23
Processing of job budget
Responsibility:
- Staff budget
Task:
- Planning and management of the personnel budget
Rights:
- Read authorisation for log data for assigned objects
- Read authorisation for master data in the ePAePV
- Read authorisation for data of retired employees in the ePAePV
- Read and write authorisation for budget and staffing
- Right to read for the Organisation, Headcount, Personnel Development and Severe Disabilities department
3.3.24
Processing 4-eyes principle
Responsibility:
- Drawing according to the 4-eyes principle
Task:
- Release of deletion notes in the ePA (except for sub-files on investigation and disciplinary matters) that were not made
by the same person
- Release of relevant personal data that has not been processed by the same person
Rights:
- Read authorisation for log data for assigned objects
- Right to read personnel and partial files in the ePA (except for investigation and disciplinary matters)
- Execution right for releases according to tasks
3.3.25
Processing of signature authorisation
Responsibility:
13 December 2024 Page 75 of 366
13 december 2024
- Drawing within personnel administration processes
Task:
- Authorised to sign within personnel administration processes except for remuneration and investigation and disciplinary
matters
Rights:
- Read authorisation for log data for assigned objects
- Right to read personnel and partial files in the ePA (except for investigation and disciplinary matters)
- Execution right for drawings according to task
3.3.26
Processing of investigation and disciplinary matters
Responsibility:
- Investigation and disciplinary matters
Task:
- Authorised to handle personnel administration processes in investigative and disciplinary matters
Rights:
- Read authorisation for log data and master data for assigned objects
- Read and write authorisation for sub-files on investigation and disciplinary matters
- Execution right for cancellation notices according to task
3.3.27
Processing 4-eyes principle and signatory authority Investigation and disciplinary matters
Responsibility:
- Approvals and drawings in investigation and disciplinary matters
Task:
- Release of deletion notes in the partial file in investigation and disciplinary matters
- Authorisation to sign within investigation and disciplinary matters
Rights:
- Read authorisation for log data and master data for assigned objects
- Right to read sub-files for investigation and disciplinary matters
- Execution authorisation for the release of deletion notes in the investigation and disciplinary matters sub-file
- Right of execution for drawings in investigation and disciplinary matters
13 December 2024 Page 76 of 366
13 december 2024
-
3.3.28
Staff unit - Complaints about official supervision
Responsibility:
- Processing of complaints about official supervision - set up by the central specialised administration department
Task:
- Informing the relevant bodies about corresponding processes
- Obtaining opinions on the transactions
- Examination of the facts and the legal situation
- Preparation of response letters
Rights:
- Right to read supervisory complaint process and corresponding personnel case file
- Write authorisation for LAF processing procedures and for reply letters/notes, marking documents, processing notes
- Forwarding of documents as part of the complaints procedure
3.3.29
Users of the communication platform
Responsibility:
- Communication platform user - (self-registered and logged in)
Tasks:
- Use of the functions in the web portal/app (e.g. application, retrieval, creation, import, export and dispatch of documents
from or to the LAF and the responsible office)
- Processing of selected own data
- Viewing the processing status (processing status of declarations in the HR system)
- Viewing documents sent by the LAF/offices
- Setting up an authorisation for the personal account
Rights:
- Access to the released data of your own personnel case
•
Write authorisation (enter, change, delete)
•
Read rights
•
Save
•
Print, if necessary also as a file for local storage
•
Upload attachments
3.3.30
Authorised users of the communication platform
Responsibility:
13 December 2024 Page 77 of 366
13 december 2024
- Authorised users of the communication platform - set up by the personnel case (authorising party) or the central specialist
administration
Tasks:
- Use of the functions in the web portal/app (e.g. application, retrieval, creation, import, export and sending of documents
from or to the LAF/offices)
- Processing of released data of the assigned personnel case (authorising party)
- Viewing the processing status (processing status of declarations in the HR system)
- Viewing documents sent by the LAF or the departments
Rights:
- Full access to the data of the principal.
•
Write authorisations (enter, change, delete)
•
Read rights
•
Save
•
Print
•
Upload attachments
13 December 2024 Page 78 of 366
13 december 2024
4 Functional system components
This chapter lists the functional requirements for the central system components. In detail, these are the requirements for:
1. Communication platform, consisting of web portal and mobile application (app), see chapter 4.2
2. Input management, see chapter 4.3
3. HR system for salary processing and personnel administration (incl. electronic personnel file and functionalities for
automated document verification), see chapter 4.4
A significant proportion of these requirements result from mandatory legal framework conditions.
The aim of the HR system is to enable processing and calculation to be as fully automated as possible. Fully automated calculation
means that activities and calculations are mapped within the HR system so that no manual calculations or manual data transfers
are required in or into the HR system (dark processing, avoidance of shadow IT). Furthermore, the Personalakt must be kept
electronically in the HR system and personnel administration must be processed electronically. All parts of the overall system
must have access to standardised master data.
Requirement
labelling
Requirement
Criterion
BS01.01
Comprehensive coverage of the requirements of the overall system in the standard The overall system
should cover all functional requirements of the overall system in the standard at the time of tender
submission. The term standard is defined in the glossary. The evaluation is calculated from the
proportion of the requirements already included in the standard.
requirements on the basis of the information provided by the bidder.
B
4.1
Overarching requirements for payment calculation and ePA/ePV
4.1.1
Data acquisition
The overall system must enable personnel cases to be recorded and processed. When processing personnel cases, master data
and person-related calculation bases are recorded, changed and deleted. It must be possible to generate a personnel number and
a personnel case type must be selectable. There are different mandatory master data fields for each personnel case type. By
selecting the personnel case type, only the master data that is required for the task must be recorded.
Data can be captured by manually entering or transferring electronic data to the overall system (e.g. OCR/ICR software, see
chapter 4.3.1 (Document content capture (OCR/ICR))).
Data collection in the overall system is subject to various checks:
- Plausibility checks (see chapter Plausibility checks 4.1.5)
- 4-eyes principle (see chapter 4-eyes principle 4.1.3)
- Sampling control procedure (see chapter Sampling control procedure 4.7.12)
13 December 2024 Page 79 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DE01.01
New admission of personnel cases
The HR system must enable new personnel cases to be recorded with their master data and an
associated legal relationship or entitlement. Recording must take place independently of payment
processing. When a new entry is made, the HR system must inform the administrator if there is
already a personnel case with identical master data (e.g. combination of surname, first name, date of
birth, personnel number). The master data currently used can be found in Appendix 5.6.
A
DE01.02
Similarity check for new personnel cases
When adding a new employee, the HR system must inform the administrator if there is already a
personnel case with largely identical master data.
Example: After an employee has given notice, she is re-employed as a civil servant with a temporary
interruption. As she has married in the meantime and her surname has changed as a result, the
master data is not identical. As a result, the processing department does not receive any information
when the new personnel case is entered. Based on the combination of e.g. first name, date of birth
and place of birth, the HR system recognises the similarity of the master data and informs the case
handler of this.
A
DE01.03
New entry of personnel cases with mandatory master data for each personnel case type The HR
system must enable the central specialised administration to create and edit personnel case types. The
HR system must enable the Central Administrator to define different mandatory fields for each
personnel case type. When selecting or changing the personnel case type, the respective mandatory
fields for the personnel case type must be used in the corresponding input mask.
Example: A person is seconded to the state of Mecklenburg-Vorpommern. The LAF must pay the
remuneration to the employer/principal for the secondment period. In return, the person is recorded
as a personnel case with less mandatory master data. If the person is transferred to the state of
Mecklenburg-Vorpommern, the task changes, which is why more master data must be recorded.
Example: A person who is not yet employed by the state of Mecklenburg-Vorpommern would like to
receive pension information before changing employer. In this case, the IBAN, for example, does not
need to be included.
A
DE01.04
Configuration of the order of data fields
The HR system must enable the central specialised administration to change the sequence of data
fields for each personnel case type.
A
DE01.05
Personnel number generation
The HR system must be able to generate a unique personnel number for each client for each
personnel case.
A
DE01.06
Permanent personnel number for change of specialised procedure
The HR system must ensure that, in the event of a change in the legal relationship and entitlement,
the personnel case, including the personnel number, is stored in the HR system.
be continued in the future.
A
13 December 2024 Page 80 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DE01.07
Transfer of external personnel numbers
The HR system must automatically store personnel numbers that are transferred to the HR system
by the payroll data interface SS01.40 in the personnel case.
A
EN01.10
Recording/changing/deleting data
The HR system must enable the manual entry, modification and deletion of master data, employee
characteristics, personal calculation bases and calculated data at any time in accordance with the role
concept (3.3).
A
EN01.11
Effectiveness data in data collection
The HR system must enable changes to master data and personal calculation bases based on the reporting
date and with retroactive effect. In addition, the HR system must make it possible to differentiate
between the effective date and the payment date. In particular, the following entries must be possible:
-
Changes to the current processing month
-
Changes to data from the past (depth of retroactive accounting)
-
Changes to data that take effect on a key date in the future Changes to data that are currently
entered and that are implemented in the calculation with a time delay for the payments (effective date
with deferred payment realisation)
A
EN01.12
Display of the catalogue
The HR system must be able to offer catalogues as a basis for selecting data. For a catalogue field, the key
number as well as the short title and the description text of the individual selection options must be
displayed to the clerk.
When entering data, it must be possible to search the displayed selection options.
A
EN01.13
Limitation when selecting the catalogue fields
During data entry, the HR system must only display values for selection that are logically and legally
permissible based on the underlying data and previous entries.
A
EN01.15
Automated data completion, preallocation and dependency check
The HR system must be able to automatically add data using rules (in particular based on certain "if -
then" conditions defined by the centralised specialist administration). It must be possible for the
centralised specialist administration to determine for which fields which value should be used for a pre-
assignment. It must also be possible to take into account dependencies on existing entries. The centralised
specialist administration must also be able to determine whether the clerk must also be informed of the
automated data addition when the respective rules are triggered.
Example: The office administrator enters the period of parental leave for a personnel case. When the
period begins, the status is automatically changed to "Parental leave". The LAF case handler receives a
separate notification about the status change.
Example: The clerk enters the postcode for a data record and receives possible suggestions for a city.
A
13 December 2024 Page 81 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EN01.16
Extended display
The input masks of the HR system must be dynamically expandable by the administrator, i.e. definable
data fields should only be displayed when they are required.
Example: The administrator adds the first child with the master data. By selecting the clerk, the display is
expanded and the clerk can then enter the second child.
EN01.17
Intermediate storage of data acquisition
The HR system must offer the option of interrupting data entry and saving the interim status manually
after the mandatory fields have been entered, so that subsequent processing is possible from the last
interim status. In the event that not all mandatory fields have been filled in, the overall system must point
this out to the case handler when the personnel case is saved. The HR system must ensure that only fully
recorded personnel cases are payable.
Example: The administrator starts to enter data for a personnel case. However, she has to interrupt this
due to another activity and wants to finalise this personnel case later.
Example: The administrator starts to enter data for a personnel case. The computer crashes during input.
Processing can continue later at the same point.
DE01.19
Data linking with documents
The HR system must enable data records or data fields to be linked to documents within input
screens so that the documents linked to the field can be called up directly from the input screen.
Example: The clerk can call up the corresponding certificate next to the date field of the birth or
marriage, as this is linked.
A
DE01.21
Data exchange with communication platform
The overall system must ensure the exchange of data with the communication platform. In particular, it
must accept and process the user data transmitted in accordance with KP02.07. The processing
department must be notified of data changes, in particular due to certain conditions defined by the central
specialised administration, if - then, on the basis of certain rules.
Example: A user logs into the KP. He makes changes to his address and saves them. The HR system adopts
the changed data. The processing department does not receive a notification as the rule is not fulfilled.
DE01.22
Request for paper Personalakts
The HR system must support the LAF and Personalakt processing department in requesting paper
personnel files from departments by means of a notification in the system or by e-mail.
ePAePV-A0995
Historical data on severe disability
The HR system should enable information on severe disabilities to be recorded multiple times for each
personnel case and stored historically.
B
13 December 2024 Page 82 of 366
13 december 2024
4.1.2
Catalogues
The HR system must contain various catalogues. The catalogues must be maintainable by the central specialist administration. In
addition to the usual entries, it should also be possible to include an "Other" selection field in catalogues.
Requirement
labelling
Requirement
Criterion
GV01.19
Service catalogue
The HR system must hold all of the country's departments as a catalogue for processing.
A
GV01.20
Adaptation of the service catalogue
The HR system must enable the central specialised administration to maintain the necessary data (e.g.
house address, P.O. Box address, contact person, SI company number) for the departments.
A
GV01.21
Health insurance catalogue
The HR system must have all health insurance funds available as a catalogue for processing.
A
GV01.22
Adaptation of the health insurance catalogue
The HR system must offer the Central Specialist Administration the option of maintaining the data on the
health insurance funds required for processing (e.g. home address, P.O. Box address).
A
ePAePV-A1181
Selection field in catalogues 1/2
The HR system should enable the central specialist administration to create an "Other" selection field in
catalogues and to use this as a
•
Free text field
•
Mandatory field
•
to define an
optional field.
B
ePAePV-A1159
Selection field in catalogues 2/2
The HR system should make it possible for the administrative department to select an "Other" entry in
the catalogue selection list.
B
4.1.3
Four-eyes principle
In accordance with VV No. 1.1.2 §§ 70-80 LHO MV, all orders are subject to a dual control check. In the HR system, the process for
dual control must be supported by a suitable workflow as part of process control. Rules and criteria can be defined, taking into
account the budgetary requirements, which allow a deviation from the dual control principle for the purpose of dark processing.
To control tasks that are not subject to dual control, a sampling control procedure appropriate to the resulting risk must be
established in the HR system (see section 4.7.12)
Requirement
labelling
Requirement
Criterion
AP01.01
Compliance with the dual control principle General
For certain types of actions, the HR system must enable the four-eyes principle, i.e. the mandatory
manual approval of an action approved by the clerk, to be applied.
A
13 December 2024 Page 83 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
The task being worked on can be checked by another person. The actions for which a dual control check
is mandatory, unless exceptions are specified, include in particular
-
New hires
-
Revival case
-
Tariff change
-
AdB change/change of pay group
-
Recording an allowance
-
Determination of experience and jubilee seniority
-
Manual synchronisation
-
Overpayment
-
Change in transfer amount compared to previous month from certain amount limits including or
excluding remuneration components (e.g. special payment, DUZ, MAE) and recipients (e.g. retired
civil servants, family funds, widows and widowers)
-
Manual entry of a special payment
-
Deletion of data, documents and files
The HR system must ensure that transactions to be checked are only authorised for payment after
confirmation by a second person responsible for this.
AP01.02
Dual control principle for maintaining process master data
The configuration and entry of process master data, e.g. rate tables, should be carried out using the dual
control principle.
B
AP01.03
Four-eyes principle workflow
The HR system must provide a suitable workflow for implementing the dual control principle, e.g. by
generating/sending a (release) task in the checking person's work area for the respective process step. It
must then be possible to either release the task or send it back to the processing work area (with a note).
A
AP01.04
Examination as a proxy
The HR system must prevent the initial processing and approval from being carried out by the same
person as part of the dual control check. This is also the case if the person is acting as a deputy for
another processing department.
A
AP01.05
Four-eyes principle
The HR system must ensure that data relating to the case handler's own personnel case cannot be
checked by the same person.
nesses.
A
4.1.4
Curriculum vitae data
The CV of a personnel case must be legally assessed. This assessment involves checking whether a period can be recognised as
indirectly increasing remuneration, for example. This requires the CV data to be available in a suitable manner in order to ensure
efficient processing.
The CV data is further processed for different legal evaluations (e.g. seniority, pensionable service and previous service periods as
well as jubilee seniority). It must be possible to use a CV of the personnel case, which has been legally assessed and thus
processed for the length of service (salary), for other areas of the pay system, e.g. to assess the length of service (salary).
13 December 2024 Page 84 of 366
13 december 2024
pensionable periods of service and previous periods of service. To this end, the CV must be continuously and automatically
updated in the event of changes to the personnel case (e.g. change from full-time to part-time).
Requirement
labelling
Requirement
Criterion
LD01.01
Manual recording
The HR system must enable the manual entry of CV data. The data to be entered manually must include
at least
-
exact day validity period from/to incl. overlapping times,
-
Type of prior service, period of service or interruption (e.g. civil servant on parental leave, not
employed, civil servant on sabbatical, employment relationship, voluntary military service (SG),
military exercise, civilian service (ZDG), federal voluntary service (BFDG), FSJ/FÖJ (JFDG), (un)paid
leave of absence, secondments),
-
Scope of the activity (depending on the type as a numerator-denominator combination or as a
percentage).
A
LD01.04
Provision within the HR system
In the event of a change of legal relationship or entitlement (e.g. a person with an employment contract
becomes a civil servant or an active civil servant retires), the HR system must be able to access all
available data on the CV of this personnel case (in particular the data listed in ) for
(automated) further processing (e.g. seniority based on experience, pensionable periods of previous
service when determining pensions, see ) by another processing department (e.g. change of
pay to salary).
A
LD01.05
Automated calculation of the duration of activity in years/days
The HR system must automatically calculate the duration of the activity based on the validity period,
taking into account the scope of the activity in years/days.
A
LD01.06
Change in the duration of activity
The HR system must allow the duration of the activity to be changed manually.
A
LD01.07
Partial secondments
The HR system must be able to map partial secondments, including the scope of the secondment.
A
LD01.10
Automated update
The HR system must automatically update the CV data when new manual entries are made by the
administrator (e.g. when changing from full-time to part-time employment).
A
LD01.11
Amendment and cancellation
The HR system must enable the manual amendment and complete deletion of manually created CV data.
A
LD01.12
Automated sorting
The HR system must automatically sort CV data chronologically when new CV data is added (in particular
via the SS01.40 interface and via manual entries by the administrator) and when CV data is changed.
A
LD01.13
Manual sorting
The HR system must enable the administrator to manually change the chronological order of CV data
(e.g. moving a newly added employment relationship to the existing database).
to the chronologically correct position).
A
13 December 2024 Page 85 of 366
13 december 2024
LD01.14
Data provision of information
The HR system must be able to retrieve CV data from CVs created in the HR system module.
The data is made available for further processing as CV data in accordance with LD01.01 ff.
A
4.1.5
Plausibility checks
The overall system supports users in checking the plausibility of incoming data. In the event of check anomalies, a message is
displayed indicating which check anomalies have been detected.
The checks take place at several levels and begin as early as the data input stage. Comprehensive automatic plausibility checks
ensure that a process is only forwarded to a subsequent process step when the process has reached the required data quality.
All plausibility checks described in this section relate to both manual and automated data collection as well as to data transferred
from connected third-party systems (in particular the CP and the OCR/ICR system).
Requirement
labelling
Requirement
Criterion
PP01.01
Levels of the plausibility check (1/3)
In the overall system, the data entries in the masks must be checked for formal correctness within a data
field and across the entire database (syntactic check, e.g. date format, fixed terms).
A
PP01.02
Levels of the plausibility check (2/3)
In the overall system, the logical correctness of data entries, including data transferred via interfaces,
must be checked within a data field and across the entire database (semantic check). The check for
logical correctness includes the check for legal admissibility and compatibility with previous entries (e.g.
entry of additional allowances). The following aspects must be taken into account during the plausibility
check in the HR system module, for example (not an exhaustive list):
-
Minority threshold
-
Short-term nature of employment cases
-
Pension insurance obligation/exemption
-
Transition area
-
Annual earnings limits
-
Child benefit suspension from dunning proceedings
-
Supplement to maternity benefit for certain statuses
-
hourly calculation of allowances if more than 99 hours are specified
-
Mini-job relationships without entering a health insurance fund
A comparison must also be made with entries whose effective dates are in the past and in the future.
A
PP01.03
Levels of the plausibility check (3/3)
Fields marked as mandatory (mandatory fields) must be checked for entry in the overall system.
A
PP01.04
Checking instructions for the processing department
In the HR system, the specific inspection anomalies must be indicated in the inspection notes.
be named for processing.
A
13 December 2024 Page 86 of 366
13 december 2024
PP01.05
Consequences of plausibility checks
In the HR system, the plausibility checks must reference the conspicuous check fields by means of a note
for processing and, depending on the error category, have consequences of varying severity:
In the case of errors in the red error category, a correction must be ensured during data entry; the data
must not be saved. The termination of the respective workflow must be prevented (in the pay
calculation: production-preventing error).
In the case of errors in the yellow error category, the workflow/production run may only take place after
confirmation of correctness by the processing department.
In the case of errors in the green error category, the workflow/production run must also take place
without further action by the clerk, e.g. payment limitation. This means that no confirmation of
correctness is required from the processing department, only a notification to the processing
department before processing is finalised.
The processing department must be able to justify its decision in a free text field if adjustments are made
as a result of a recognised plausibility error.
Which types of errors fall under which of the error categories mentioned will be agreed with the client
during the implementation phase. In addition, the error categories must be configurable as part of the
centralised specialist administration (in particular designation and information texts).
The HR system must ensure that critical entries (red, yellow error category) are error-free and
recognised plausibility deficiencies are corrected before the workflow and thus the payment justification
are completed.
The processing of other masks and workflows in the HR system must not be inhibited if the error
detected does not affect the fields contained there.
PP01.06
Definition and configuration of the check criteria by the central specialist administration The overall
system must offer the central specialist administration the option of managing and editing the underlying
check rules for all plausibility checks as part of self-customising. It must be possible to switch rules on and
off (legally binding exception plausibilities are not affected by this).
PP01.07
Logging (documentation) of troubleshooting
In the overall system, the actions must be documented according to error categories as part of the
logging process, which includes who has processed the error.
has made and when.
4.1.6
Document creation
In addition to processing existing documents, new documents are also created in payroll accounting and personnel
administration, such as remuneration notifications, certificates, notices, replies or information. The creation of documents is
partly automated by the overall system, but is also carried out manually by the administrator.
The processing department usually creates documents on the basis of document templates, which are maintained in particular by
the central specialised administration and department-specific specialised administration.
13 December 2024 Page 87 of 366
13 december 2024
be created. In particular, it must be possible to create these document templates with modifiable and unmodifiable fields and
catalogues and it must be possible to assign keywords to the document templates.
Requirement
labelling
Requirement
Criterion
DK01.01
Automatic document creation
The HR system must be able to create documents automatically from the data collected. This includes all
documents to be created automatically in accordance with this service description as well as all notices,
certificates, reply letters and information comparable to the samples in Appendix 3.4 List
Evaluations_Documents_Protocols. The documents must be automatically pre-filled with data from the
HR system. The documents must be available for further processing and be customisable. The contractor
must provide the above-mentioned documents.
A
DK01.02
Formatting
The overall system must enable standard formatting (in particular bold, underlined, italics, bullets,
numbering, tick boxes) for documents and their components (e.g. text modules and free text fields).
A
DK01.03
Grammar and spell checker
The HR system must offer the option of carrying out a comprehensive automated grammar and spell check.
A
DK01.04
File naming convention
The overall system should automatically name documents according to a file naming convention specified
by the client.
The configuration of the file naming convention is to be carried out by the central specialised
administration.
B
DK01.05
Customisation of the file format
The overall system must allow the centralised specialist administration to adapt the file format (at least
DOCX and PDF) for exporting the documents created.
A
DK01.06
Versioning of document templates
The overall system must offer the option of versioning document templates, assigning validity periods
and accessing old versions as required.
A
DK01.07
Storage, maintenance and deletion of document templates and text modules (1/2)
The overall system must offer the possibility of centralised specialist administration and department-
specific specialist administration,
-
Document templates (e.g. notices, letters, general legal information, forms) provided by the
contractor (DK01.01Automatic document creation) and
-
Text modules that cannot be individually customised by the administrator
to adapt the text and create new document templates and text modules as part of self-customising.
A
DK01.08
Storage, maintenance and deletion of document templates and text modules (2/2)
The document templates and text modules must be approved by the Central Specialist Admi
nistration and department-specific specialised administration can be created in a differentiated manner
A
13 December 2024 Page 88 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
(e.g. differentiation according to salary/remuneration/pensions/retirement benefits/personnel
administration nationwide, within authorities and business areas) so that the clerk only sees the
document templates and text modules relevant to the task.
ePAePV-A1190
Setting up fields
The HR system must enable the Centralised Specialist Administration to view document templates and
documents based on templates by users.
•
changeable and
•
to set up
unchangeable field contents.
A
ePAePV-A1107
Use of catalogues
The HR system must enable the central specialist administration to use catalogues in document
templates.
A
ePAePV-A1186
Conditional logic for showing and hiding fields
The HR system must enable the centralised specialist administration to implement conditional logic for
showing and hiding fields in the template based on previous entries in other fields.
A
ePAePV-A1192
Keywords for document templates
The HR system must enable the centralised specialist administration to assign keywords to document
templates.
A
ePAePV-A1178
Customisation of text modules
The HR system must enable specialist administrators to create text modules that can be individually
customised by the departmental administrators.
A
DK01.10
Use of text modules
The HR system must offer the clerk the option of setting text modules specified by the client when
creating documents.
A
DK01.11
Text modules - individually prioritised text module list
The HR system should offer the administrator the option of setting a prioritisation for text modules (e.g.
as a favourites list). The setting should be saved for future meetings (only) of the respective
administrator and can be changed by them at any time.
B
DK01.12
Text modules - multiple selection and sequence
The HR system must offer the clerk the option of selecting several text modules, defining their sequence
and setting them in the document at the same time.
A
DK01.13
Text modules - combination of several text modules
The HR system must enable the administrator to use several text modules as a standard package. The
standard packages as a combination of several text modules should be able to be created and edited by
the central specialised administration.
A
DK01.14
Text modules - unlimited number and length
The HR system does not have to limit the number of characters for text modules and free text entries.
A
DK01.15
Versioning of text modules
B
13 December 2024 Page 89 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
The HR system should offer the option of versioning text modules, assigning validity periods and
accessing old versions as required.
DK01.16
Mail merge
The HR system must allow documents (e.g. reminders, information letters) to be created and sent to a
configurable group of people (in the case of mass mailing).
The selection of the group of persons should be configurable by the central specialised administration.
A
4.1.7
Acting/document management system
The document management system (DMS) is to replace the "BEATA" DMS currently used for remuneration. In future, the DMS
will be an integral part of the overall system and will also enable electronic personnel administration. The HR system will
therefore be used for the Ablage or indexing of the documents used and generated in the overall system. Ablage must take the
form of an electronic personnel file for each personnel case. All documents belonging to a Personalakt are automatically assigned
to an Akt using metadata. The retention period of the documents depends on the document type. The specific retention period
depends on the statutory retention periods for the file.
The documents from the file repository are required for transaction processing in the HR system. This means that the case
handler must be able to view the relevant documents in the HR system. The HR system must support the retrieval of the relevant
documents for case processing.
In future, it must also be possible to access documents that have been sent to or by users from the communication platform.
Requirement
labelling
Requirement
Criterion
VA01.01
Document management
The HR system must have a document repository that represents the reference process of the personnel
case file.
A
VA01.02
Personnel case file
The HR system must automatically create and manage document storage locations for each personnel
case. All documents assigned to the personnel case must be stored here in accordance with VA01.04. It
must be possible to retrieve the documents.
A
VA01.03
Transaction file
The HR system must offer the option of creating and managing non-employee-related document storage
locations (e.g. for letters for feedback).
of overpaid social security contributions).
A
13 December 2024 Page 90 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VA01.04
Attachment of file number
The HR system must make it possible to assign a file number to each Akt in accordance with a predefined
formation rule.
A
VA01.05
Assignment of file numbers (1/2)
The HR system must support the automatic assignment of file numbers in accordance with VA01.04.
A
VA01.06
Assignment of file numbers (2/2)
The education rule in accordance with VA01.04 must be configurable by the central specialised
administration.
A
VA01.07
Automated document storage
The HR system must automatically ablegen created documents for each personnel case.
A
VA01.08
Clear structure of the document storage for administration
In the HR system, the document storage must be structured in a clear form (e.g. tree structure or
structured dialogue view). The structure must include at least the following structural elements:
-
Personnel number/ID number,
-
departments (including remuneration, salaries and pensions),
-
Document classes (grouping of documents in an Akt),
-
Documents.
A
VA01.09
Creating, configuring and deleting tree structure elements
The central specialised administration must be able to create, configure and delete the tree structure
elements of the document management.
A
VA01.10
Sorting the documents
By default, the HR system must sort documents according to the date they were changed. Other sorting
criteria should be possible, e.g. name or creation date.
A
VA01.11
Ablage of documents according to the retention concept
The HR system must be able to automatically store, archive and delete the documents filed in
accordance with VA01.02VA01.02 in accordance with the statutory retention periods.
A
VA01.12
Configuration of the retention periods
The legal retention periods stored in the HR system must be configurable by the central specialised
administration.
A
VA01.13
Summary of documents
The HR system should offer the option of summarising documents and processing notes in a separate
PDF file, whereby individual documents/contents (contents of filled input masks, comments on persons,
comments on processes, processing notes; see WF01.12) should be selectable and deselectable and the
order should be definable before creation. The PDF file created should be exportable and printable and
be able to be sent as an attachment to an e-mail.
B
VA01.14
Document history
The HR system must maintain a document history for all documents stored in Akt.
create a deletion log. This also includes a log of deletions.
A
13 December 2024 Page 91 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VA01.15
Status of an Akt (1/2)
The HR system must be able to display the status of an Akt (e.g. open, locked, closed, etc.).
A
VA01.16
Status of an Akt (2/2)
The statuses of an Akt (VA01.15VA01.15) must be definable and configurable by the centralised specialist
administration.
A
VA01.17
Moving documents
The HR system must enable clerical staff to move documents between Akt.
A
VA01.18
Manual deletion of documents (1/2)
It must be possible to manually delete documents in a file in the HR system. Centralised specialist
administration must be able to exclude certain documents and document types from manual deletion.
A
VA01.19
Manual deletion of documents (2/2)
The HR system must use suitable security measures (e.g. dual control principle, multiple queries, etc.) to
prevent the accidental deletion of documents and files.
The manual deletion of documents before the retention period expires must be confirmed by the dual
control check and only then made possible.
A
VA01.20
Requirements for long-term storage
Storage must be ensured in the HR system in accordance with TR-ESOR BSI -Bund (see
https://www.ecsec.de/fileadmin/Ecsec-files/pub/2012_DACH_TRs.pdf).
The contractor connects the HR system to the country component for long-term storage (TR-ESOR basic
service - SS01.42) via an interface.
A
VA01.21
Read confirmation
In the overall system, the first time a transmitted document is opened by the receiving person in the
communication platform, a mark must be automatically set as a read confirmation on this document
(see also WF04.03).
A
VA01.22
Search function (1/2)
The overall system must contain context-related search functions. The search must be parameterisable
for the entire database. All fields in the database can be used as search criteria.
A
VA01.25
Search function (2/2)
The system must allow users to search through specific metadata.
A
VA01.23
Document display
The overall system must allow the documents to be displayed while the process is being processed.
A
VA01.24
View documents via the communication platform
Document types selected from the overall system (documents sent or received by the personnel cases)
must be made available to the CP as a read view by the central specialised administration.
A
13 December 2024 Page 92 of 366
13 december 2024
4.1.8
Qualified electronic signature and seal
The HR system must affix a qualified electronic signature to documents and offer the option of reading and verifying this if
necessary. The signature requirement must be configurable at document and process level. The signature requirement applies to
the scanning of incoming documents, the processing and electronic dispatch of documents. The legal basis for this is in particular
the eIDAS Regulation (EU) No. 910/2014 as well as Section 84 (2) LBG MV, Sections 3a and 37 VwVfG M-V and the basis of the
technical guideline "BSI TR 03138". In addition, the HR system must affix a qualified electronic seal to documents and offer the
option of reading and checking this if necessary. The seal requirement must be configurable at document and process level.
Requirement
labelling
Requirement
Liability
ES01.01
Signing documents to be filed
The HR system must offer the option of providing documents with a qualified electronic signature before
they are stored in the file (document storage location) (see Section 84 (2) LBG MV). For technical
implementation, see requirement SS01.24.
A
ES01.02
Signing of documents to be sent externally
The HR system must also offer the option of adding a qualified electronic signature or a qualified
electronic seal (see ES01.01, SS01.24) to documents already in the file for external transmission, in
particular via the KP (see Sections 3a and 37 VwVfG M- V).
A
ES01.03
Signing/sealing of incoming documents
Incoming documents that are processed by the replacement scanning process are scanned in the scan
path in accordance with the technical guideline
"BSI TR 03138" from the German Federal Office for Information Security (TR- RESISCAN). The HR system
must be able to receive the corresponding scan files including metadata from the OCR/ICR software via
the SS01.25 interface and process them including the qualified electronic signatures or seals (see section
4.3 Input management).
A
ES01.04
Sealing of documents
In accordance with eIDAS Regulation (EU) No. 910/2014, the HR system must offer the option of providing
documents with a qualified electronic seal. For technical implementation, see SS01.24.
A
ES01.05
Verification of signatures and seals
The HR system must offer the option of reading qualified electronic signatures and qualified electronic
seals if necessary and checking their validity and authenticity using methods and signature/seal tools for
documents (e.g. based on PGP-Pretty Good Privacy, GnuPG, S/MIME, Open-SSL, JWT, SSL/TLS certificates
for various other purposes).
A
ES01.06
Selection of seal and signature requirement
The signature and seal requirement must be met at document and workflow level.
be configurable.
A
13 December 2024 Page 93 of 366
13 december 2024
4.1.9
Workflow management
Workflow management is used to define workflows for processing tasks and the associated processes in the system based on
certain rules and to control processing in this way.
Tasks are work steps to be checked by the LAF and the departments or the personnel department for the calculation of
remuneration or the administration of personnel matters.
Tasks are processed in the specialist departments. These are subdivided according to the benefits to be granted: remuneration,
salaries and pensions as well as personnel administration. Responsibilities for personnel cases within the areas of remuneration
and salary as well as personnel administration are mapped via the job affiliation of the personnel cases.
Tasks result from changes to personnel and other relevant data. The changes are made in the departments and through
notifications of personnel cases as part of the changes to personnel data. While the changes are entered directly by the clerical
staff in the departments, the notifications of personnel cases are either made via the communication platform or, if sent by other
means (paper, fax, e-mail), are read into the overall system via input management and assigned to the corresponding tasks.
Personnel and payroll processing is divided into different areas of responsibility, which are brought together by workflow
management.
The central task area is used in relation to the organisational unit, i.e. it is used by the management of the organisational unit for
the central distribution of tasks to individual task areas.
The individual task area serves as a virtual desk for clerical staff as an entry point for managing and processing the assigned
processes and the associated tasks.
General requirements for workflows
Requirement labelling
Requirement
Criterion
WF01.01
Definition of workflows
The HR system must offer the centralised specialist administration the option of defining/creating
workflows that define a sequence of processing steps and the responsible clerical tasks. In the event of
sequential further processing, the HR system must enable automated forwarding of the task to the next
processing step stored in the workflow. The HR system must enable the creation of workflows which
allow parallel processing of the same task by different clerks.
A
13 December 2024 Page 94 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
ePAePV-A0129
Customisability of workflows
If workflows were provided by the contractor and created by the client, these must be adaptable by the
client's creating organisational units (in particular central specialist administration, department-specific
specialist administration, departmental processing).
This applies in particular:
•
the change of workflow participants
•
Customisation of the workflow steps (incl. changing the sequence of workflow steps)
•
the addition of workflow steps
•
the removal of workflow steps
A
WF01.02
Selection of additional clerks
For workflows in which tasks are to be processed sequentially by several clerks, the HR system must
enable the management of the organisational unit to select the specific clerks (e.g. via drop-down fields).
The HR system must historicise the selection.
A
WF01.03
Drawing process
The completion of workflows must be traceable in the HR system (drawing history).
A
WF01.04
Release workflow
In a release workflow, it must be possible for the releasing party (authorised signatory) to do so after
initial processing by the administrator,
to approve the changes made by the processing department or to refuse approval and return them with a
comment.
A
WF01.05
Supplementary notes on workflows
The HR system must make it possible to store additional notes on individual workflows as free text.
A
WF01.06
Workflow overview (1/2)
The overall system must provide an overview of the defined workflows.
A
WF01.07
Workflow overview (2/2)
The overall system must provide the centralised specialist administration with the option of adjusting the
workflow overview in accordance with WF01.06, i.e.
in particular showing and hiding individual workflows, changing the sequence.
A
13 December 2024 Page 95 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
WF01.08
Audit-compliant documentation (audit trail) of all data recording, changes and calculations with
mapping of the history
In order to ensure the traceability of data processing, the overall system must, among other things:
-
all activities in the overall system, such as the recording, storage, modification, deletion,
transmission and transfer (e.g. transfer protocol) of data in the system
-
Search queries and opening documents
-
the uniqueness of the labelled business transaction
-
the system-supported creation of analyses, reports and documents, including the selection criteria
used
-
recording, changing and deleting roles and authorisations
-
certain read accesses
-
the individual steps of workflows
-
Each change in the database with input channel, user ID, edited data record, field name, field
content old/new as well as date and time
-
Settlement runs and fictitious calculations
-
Transfer or transfer of data from interfaces
-
the type of activity in the overall system and the data fields affected
-
the old and new value of the affected data field
-
the processor
-
Date and time of the activity
with a history in the system in a clear, permanent and unalterable way. The log data must be able to be
viewed by specially authorised users (role and rights concept). Filter functions must be available for
targeted selection.
A
WF01.09
Central user interface for getting started (1/2)
The overall system must offer a central user interface as a start page from which the user can navigate to
the task areas.
A
WF01.10
Central user interface for getting started (2/2)
The overall system must enable the central specialised administration to display and configure
information on the central user interface in accordance with WF01.09, e.g. on maintenance,
substitutions and upcoming test and billing runs.
A
WF01.11
Link to the knowledge database
The HR system must provide links to further topics on the LAF's knowledge database and the ePAePV. It
must be possible to set and maintain the links as part of the centralised specialist administration (see
Annex 2.4 Knowledge database).
A
WF01.12
Processing notes
The HR system must offer the clerk the option of entering processing notes at the meta level in free text
and catalogue-based for individual documents and tasks. It must be possible to call up the processing
notes when the document or task is displayed.
A
ePAePV-A1195
Prioritisation of workflows
The HR system is designed to enable the HR department and the head of HR to mark workflows as
prioritised.
The HR system must offer the option of displaying prioritised workflows separately in the task area (e.g.
with a red exclamation mark or red background).
B
13 December 2024 Page 96 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
WF01.13
Display of notices
In the HR system, references to incomplete data (e.g. child's date of birth missing) and missing
documents must be displayed as attachments (e.g. missing document supporting the application -
marriage certificate) for tasks received in the work area.
A
WF01.14
Configuration of notices
It must be possible for the HR system to configure the conditions under which notices are issued in
accordance with WF01.13 and the specific textual content of the notices by the central specialised
administration.
A
WF01.15
Help functions (1/5)
The overall system must provide help functions that facilitate the use of the system from a technical
point of view. These include context-related online help at input screen level and information at field
level. They should be formulated with as few anglicisms as possible.
A
WF01.16
Help functions (2/5)
The overall system must make it possible for the help function (WF01.15) to be supplemented with
additional content as part of self-customising by the central specialist administration and for the existing
content to be adapted by the central specialist administration.
A
WF01.17
Help functions (3/5)
During task processing, the HR system should display the appropriate excerpts from the relevant legal
bases for the respective processing step of a task as part of a help function. The required content on
relevant legal bases (at least the legal bases listed in chapter 2.4) is provided by the client.
With regard to this help function, further content can be added by the central specialist administration
as part of self-customising and the existing content can be adapted by the central specialist
administration.
B
WF01.37
Help functions (4/5)
The HR system should be able to have a "Help" button integrated into the system so that the user
documentation can be called up at any time. The button can also be given a different name.
B
WF01.38
Help functions (5/5)
The HR system should offer users the option of using the help function independently of the current
processing.
B
WF01.18
Search functions (1/2)
The HR system must provide a cross-mask search function for tasks, personnel cases, personnel case files
and individual documents using at least the following search criteria:
-
Surname and first name of the personnel case and its relatives
-
Personnel number
-
Date of receipt (including application and objection date)
-
Task number
-
Date of birth of the employee and their dependants
The HR system must allow the personnel case, file or document to be opened.
from the search function.
A
13 December 2024 Page 97 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
WF01.19
Search functions (2/2)
The HR system must offer the option of searching for metadata, cata- log data, keywords, subject
headings, document types and list entries.
A
WF01.20
Display of search results according to access rights
The administrator may only open search results for which the respective users have access rights.
A
ePAePV-A0609
Display of search results
The HR system must be able to display the search results in an orderly manner, in particular in ascending
and descending order, organised by date, surname, first name and personnel number.
A
WF01.21
Search function - full text search
The HR system must support a full-text search across all documents in a file, but also across all files, taking
access rights into account.
A
WF01.22
Search function - Text modules
The HR system must enable the search function for relevant text modules when processing a task.
A
WF01.23
Search function - Search combinations
The HR system must enable a combined search function according to different criteria (search
combinations).
A
WF01.24
Search function - time periods
The HR system should enable the search function within certain time periods (e.g. from month infinity to
a key date, from key date to key date, from date to today).
B
WF01.25
Search function - Date
The HR system must enable the search function for a specific date.
A
WF01.26
Search function - similarity search
The HR system should support a similarity search (e.g. Meier/Maier) in documents and Akt.
B
WF01.27
Search function - Storage
The HR system should support the saving of search queries and the loading of saved search functions.
B
WF01.28
Search function - Preview function
The HR system must support a preview function (thumbnail preview) for a hit list.
A
WF01.29
Search function - Export
The HR system must enable the export of hit lists.
A
WF01.30
Filtering search results (1/2)
The HR system must offer the option of filtering search result lists according to the following criteria in
particular:
-
Personnel number
-
Application date
-
Clerk
-
Surname and first name of the personnel case
-
Date of birth
A
13 December 2024 Page 98 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
ePAePV-A0616
Filtering search results (2/2)
The HR system must be capable of filtering the search by multiple criteria.
The criteria must be provided in the form of more linked criteria '(in particular "and", "less than").
A
WF01.31
Operation of the search function in the current editing process
The HR system must offer the option of calling up, operating and executing the search and displaying the
search results without interrupting the current editing process.
A
WF01.32
Display of search results without access rights
The HR system should be able to display the person responsible for queries for search results for tasks,
Personalakts/files for which the user is not authorised.
B
WF01.33
Simultaneous access to personnel cases
In the HR system, it must be possible for several users to access a personnel case at the same time.
A
ePAePV-A0615
Cancel search
The HR system must make it possible to cancel a search.
A
ePAePV-A0617
Reset search data
The HR system must make it possible to reset the entries in the search fields all at once.
A
WF01.36
Workflow deadlines
When creating workflows, the HR system must enable the central specialist administration to define
deadlines for completing workflow steps based on a catalogue. The deadlines must be able to be changed
by the departmental administrator when going through the workflow.
Deadlines are required, for example, for the involvement of the staff council and equal opportunities
officer.
A
Workflows for task areas and tasks
Requirement
labelling
Requirement
Criterion
WF02.01
Specialist and organisational areas of responsibility
The HR system must be able to set up central task areas for the departments or organisational units. For
example, cases that cannot be assigned individually are filed in the central task areas. It must be possible to
distribute tasks from the centralised task areas to other task areas.
In addition, the respective task area must display an overview list for displaying and managing assigned
tasks with processing status and date received.
It must be possible for the central specialised administration to configure the setup of task areas and the
assignment of tasks to task areas.
A
WF02.02
Individual task areas for processing
The HR system must provide individual task areas for processing tasks. These must have an overview list
that can be sorted and filtered via the
the tasks assigned to the respective department.
A
13 December 2024 Page 99 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF02.03
Configuration of task areas
The HR system must enable the configuration of central and individual task areas, in particular with regard
to the sorting of tasks and the column sequence, using mask, dialogue or list-oriented interfaces.
A
WF02.04
Notes from automatic processes in the task area (1/2)
The HR system must enable the centralised specialist administration to generate notes on individual
workflows and payroll runs. These must be displayed to the administrator.
A
WF02.05
Notes from automatic processes in the task area (2/2)
The notes must be logged in the HR system in accordance with WF02.04.
A
WF02.07
Identification of task creator
The HR system must make it possible to identify the task creator or the origin of the task (e.g. interface).
A
WF02.08
Filtering, sorting and searching for tasks
The overall system should enable filtering, sorting, searching and displaying tasks in the central and
individual task areas, in particular according to the following criteria
-
Personnel number
-
Resubmission
-
Application type/subject (e.g. family allowance)
-
Created on
-
Date of receipt and creation
-
Keywords e.g. surname, first name or partial entry with placeholders
-
Placeholder search
-
Evaluation
-
Search for the priority
-
Processing status
-
of current editors.
B
ePAePV-A0118
Information on the assignment of tasks
The HR system must be able to inform users in the HR system about assigned tasks. The users must be
able to configure for themselves whether they are informed by the HR system.
A
WF02.09
Configuration of search and filter criteria
The Central Specialist Administration should use the search and filter criteria in accordance with WF02.08
can adapt.
B
13 December 2024 Page 100 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF02.10
Automatic distribution of tasks
The HR system must automatically allocate tasks to the central and individual task areas based on certain
criteria, in particular
-
Personnel number
-
Number of applications/tasks per person
-
Date of receipt
-
Type of application (e.g. family allowance)
-
Filling in data fields (e.g. "cross" for police enforcement service, "professor"
as official title)
-
Employment relationship
-
Alphabetical names of the personnel case
The criteria for distributing tasks must be configurable by the central specialist administration.
A
WF02.11
Manual distribution of tasks (1/2)
The HR system must allow manual distribution and forwarding of tasks to the individual and centralised task
areas.
A
WF02.12
Manual distribution of tasks (2/2)
In the HR system, it should be possible to manually add and increase the priority of the respective task.
B
WF02.15
Direct call of tasks
In the HR system, it should be possible to open the corresponding processes directly from the tasks for
processing.
B
WF02.16
Processing status of tasks (1/3)
The overall system should automatically set the respective processing status of a task based on the actual
processing status. In particular, the overall system must set the following processing status values
automatically:
-
delivered
-
in progress
-
on resubmission
-
Processing completed
B
WF02.17
Processing status of tasks (2/3)
The overall system should offer the centralised specialist administration the option of configuring the
processing statuses from WF02.16. In addition to configuring the labelling of the respective status value, it
should also be possible to adapt the underlying automation for each status value.
B
WF02.18
Processing status of tasks (3/3)
The overall system is intended to minimise the manual status setting "on resubmission" by the
Allow the processor.
B
WF02.19
Resubmission of tasks
The overall system should support the resubmission function in the individual task area. For this purpose, it
must be possible to define a resubmission date and reason for resubmission for a task, a document or each
object directly from the individual task area.
When the resubmission deadline is reached, the respective task, document or object must be
automatically displayed in the individual task area. In the task list in accordance with WF02.02, the
resubmission date must also be displayed.
the resubmission date and the reason for resubmission are displayed.
B
13 December 2024 Page 101 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF02.21
Automated resubmissions of tasks
The overall system should automatically set resubmissions under conditions that can be defined by the
central specialised administration. The period of the resubmission should also be definable by the central
specialised administration.
For example, when a document is created with a specific document template (e.g. hearing letter) and the
document is sent for processing, a resubmission of 1 month should be set automatically.
B
ePAePV-A0564
Resubmissions in task areas
A resubmission that has been set should be linked to the administrator's area of responsibility and therefore
remain in place even if the administrator changes.
B
ePAePV-A0481
Resubmissions for substitutions
The HR system must automatically display all resubmissions to the responsible administrator when a
substitution is made.
A
WF02.24
Manual creation of tasks
In the HR system, it must be possible for the administrator to manually enter tasks that contain a check
request. This check task must be processed by the person authorised to receive it by means of an approval
or rejection stating the reason.
A
WF02.25
Automatic deletion of tasks
The HR system must automatically hide tasks or show them as completed when they have been fully
processed.
A
Workflows for document processing
Requirement
labelling
Requirement
Criterion
WF03.01
Separating documents (1/2)
The HR system should enable the manual separation of documents (e.g. PDF) by the clerk so that the
documents can be assigned to several users.
B
WF03.02
Separating documents (2/2)
When separating documents, the HR system must inherit the original metadata from the original document to
the separated documents.
A
WF03.03
Automated dispatch of documents (1/4)
It must be possible to send documents automatically in the HR system.
A
WF03.04
Automated dispatch of documents (2/4)
It should be possible to configure automated dispatch in accordance with WF03.03 to determine which
documents should be sent automatically by default and which should only be sent after confirmation by the
administrator. This configuration must be able to be carried out by the central specialised administration.
B
WF03.05
Automated dispatch of documents (3/4)
In the HR system, it must be possible to configure a time offset for dispatch in accordance with WF03.03 by
the central specialist administration. The possible offsets are minutes, hours and days.
A
WF03.06
Automated dispatch of documents (4/4)
The dispatch must be logged in the HR system in accordance with WF03.03.
A
13 December 2024 Page 102 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF03.07
Deleting data and documents
The HR system must take into account the deletion deadlines for the automated deletion of documents and
data.
-
Calculation data within the recalculation depth
-
Master data (including CV) until the end of the retention period
-
documents until the expiry of the applicable statutory retention period
differentiate.
A
ePAePV-A1111
Information on status transitions
The HR system should be able to inform workflow participants of status transitions. The workflow participants
must be able to configure for themselves whether they are informed by the HR system.
B
ePAePV-A0155
Interruption of workflow steps
The HR system must offer those involved in the workflow the option of interrupting the processing of a
workflow step and continuing it at a later point in time without any loss of information.
A
ePAePV-A1112
Transfer of results to the electronic Personalakt
The HR system must be able to turn workflows into
-
(structured) data into the electronic personnel administration and
-
documents into the electronic Personalakt.
A
ePAePV-A0941
Personalised subject file
The HR system must offer departments the option of filing documents that are not relevant to personnel files
in a personal file.
A
ePAePV-A0536
Form creation in connection with workflows
The HR system should offer the administrative departments the option of creating a form from a document
template, which can be brought into the workflow via the workflow management system. The form brought
into the workflow must be able to be changed in the workflow.
B
ePAePV-A0590
Parallel processing of multiple documents
The HR system is designed to offer departments the option of processing several different documents in
parallel.
B
ePAePV-A0114
Checklists (1/4)
The HR system should enable the centralised provision of checklists as input masks.
•
nationwide
•
within the authorities
•
in a business division
enable. Several different checklists must be possible for each workflow. The checklists must be configured by
the central specialised administration and by the department-specific specialised administration.
B
ePAePV-A0117
Checklists (2/4)
The HR system is intended to enable the departmental administration to create customised checklists. The
individually created checklists should be shared with other departments via the HR system by the
departmental clerical staff and used as a basis for the creation of checklists.
the same checklist can be worked through together.
B
13 December 2024 Page 103 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0122
Checklists (3/4)
The HR system should enable the checklist to be assigned to a workflow step when it is created.
B
ePAePV-A0126
Checklists (4/4)
It should be possible to define the processing of a checklist by the administrative departments as a step in a
workflow (e.g. checklist with tasks "career check" and "arrange appointment with the medical officer").
B
ePAePV-A0501
Information about changes
The HR system should offer personnel administrators the option of configuring which changes they would
like to be informed about and how, e.g. by e-mail or within the system.
B
ePAePV-A0503
Observation of data fields
The HR system can offer the personnel administrator the option of monitoring data fields and being
automatically informed of changes in monitored data fields.
tised information.
B
Special workflows
Requirement
labelling
Requirement
Criterion
WF04.01
Utilisation of the CP (1/2)
The overall system must enable the centralised specialist administration to set an attribute in the
communication platform when an account has an active status, for example, so that documents can be
sent and received electronically via this channel of the communication platform.
A
WF04.02
Utilisation of CP (2/2)
If there is no active account or if the account has been blocked or cancelled, the overall system must
arrange for it to be sent by post.
A
WF04.03
Receipt of delivery and read confirmation from the CP in the HR system and triggering of dispatch
The status (retrieved / not retrieved) of documents provided in accordance with DE01.21 must be made
visible within the HR system. If there is no retrieval in administrative files within a period of time defined
by the central specialised administration after delivery of the notification in the KP, a postal dispatch of
this notification must be triggered automatically.
A
WF04.04
Transfer of the processing status to the communication platform
The HR system must transmit the processing status (in accordance with WF02.16WF02.16) of a task that
was created based on a document receipt from the CP to the CP in accordance with CP03.12.
A
WF04.08
Inspection of files (1/3)
The HR system must make it possible to summarise documents and processing notes for a personnel
case in a separate PDF file, whereby individual documents/contents (contents of filled input masks,
comments on processes, comments on persons, processing notes (see WF01.12) must be selectable and
deselectable and the order must be definable before creation. The PDF file created should be exportable,
printable and sent as an attachment to an e-mail.
can be sent.
A
13 December 2024 Page 104 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF04.09
Inspection of files (2/3)
The HR system should make it possible to summarise documents and processing notes for a personnel
case in an encrypted ZIP file, whereby individual documents can be selected and deselected before
creation. The created file should be exportable, compressible (ZIP) and able to be sent as an attachment
to an e-mail.
B
WF04.10
Inspection of files (3/3)
The HR system must make personnel case files available to KP users for export and printing after
approval by the administrator.
A
WF04.11
Request for eAU data via eAU reporting procedure
The HR system must support the request for eAU data via the eAU reporting procedure (ITSG certified).
For this purpose, it must be possible for the processing department and the personnel department to
manually enter the basic data required for the respective request, in addition to the existing master
data required for the eAU registration procedure (e.g. surname, first name, date of birth). The basic
data includes in particular
-
Start of AU
-
Confirmation that an employee has reported sick
-
AU Reason
The eAU data entered by the personnel departments must be able to be checked and authorised by the
LAF processing department (4-eye principle).
A
WF04.12
Plausibility check when entering/importing into the HR system
The HR system must check the basic data for the request for the eAU reporting procedure in accordance
with WF04.11 for plausibility immediately when it is entered/imported into the HR system by the HR
departments. Corresponding processing instructions must be reported back to the HR departments in a
suitable form. These are the following in particular:
-
Input processed
-
Petition rejected, no legally insured person
-
Submission rejected, inadmissible date
-
Entry rejected, recording in case of absence not equal to "sick" inadmissible
-
Submission rejected, recording inadmissible on final disposal
A
WF04.13
Plausibility check immediately before requesting the eAU data via the reporting procedure
The HR system must check the plausibility of the basic data recorded in the system for the request for
the eAU reporting procedure immediately before the start of the eAU reporting procedure (compliance
with the criteria according to the ITSG specifications) and report any incorrect reports (e.g. other
absence already present at the start of the AU) back to the HR departments in an appropriate manner
so that they can correct the basic data recorded. The LAF must then re-check and approve the data.
A
WF04.14
Acceptance of the data provided via the eAU reporting procedure
The HR system must accept the eAU data provided via the eAU reporting procedure (ITSG certified) and
enable the processing department to record these as absences.
A
WF04.15
Recording the eAU data provided via the eAU reporting procedure
The HR system must use the eAU data provided via the eAU reporting procedure.
automatically as absences.
A
13 December 2024 Page 105 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WF04.16
Logging eAU
The HR system must be able to ablegen the eAU data provided by the health insurance companies in a
suitable form for each personnel case in the personnel case file (e.g. PDF format per personnel case).
A
ePAePV-A0207
Attachment of digital documents
The HR system must offer those involved in the workflow the option of attaching documents.
A
ePAePV-A0083
Visual status overview of documents in workflows
The HR system should be able to provide a visual status overview of the current status of documents in
workflows (in particular, sent, opened/read, forwarded, processed, completed, cancelled, withdrawn,
rejected, returned, documents checked for completeness).
B
ePAePV-A0743
Visual identification
The HR system should enable the identification of documents in circulation based on visual
characteristics.
B
ePAePV-A1114
Resetting workflows
The HR system should enable all workflow participants to set up a workflow at
to set "back to start".
B
4.2
Communication platform (self-service)
Since April 2018, the LAF - Remuneration Department - has provided an employee portal (MAP) for staff cases, which is operated
by DVZ. The MAP can be used via the Edge, Safari, Opera, Firefox Chrome and Internet Explorer browsers, among others.
However, it does not offer a seamless connection to the existing specialised procedure. It is not optimised for mobile devices. To
date, approx. 14,000 of approx. 53,000 personnel cases (25 %) use it. Around 250 new registrations are made every month. In
2022, a total of 6,500 applications and declarations in the area of remuneration were forwarded to the LAF via the MAP. Most
accesses were registered during the working week (Monday - Friday) from 9.00 am to 2.00 pm.
In future, the use of electronic communication should become the rule. To this end, communication between the personnel cases
managed by the LAF and the personnel administrations (in particular personnel cases of offices in the state administration of
Mecklenburg-Vorpommern and other employers for which the LAF provides services; pension recipients; recipients of retirement
benefits) and the LAF or the personnel administration must be made possible via a separate self-service online portal
(communication platform, "KP" for short) to be provided by the contractor.
The reciprocal transmission of documents (e.g. forms, applications, declarations, notifications) and messages between HR
administration, the LAF and the personnel cases must take place in electronic form. The central functionalities of the KP must not
only be operable via a web portal, but also via a corresponding app, thus also enabling mobile access for users.
The KP is supported by OCR/ICR software provided by the client from the aid sector, which supports the automated reading of
uploaded documents and must be connected to the KP. Overall, the CP must provide a collaborative framework for cooperation
between the personnel cases and the processing department.
13 December 2024 Page 106 of 366
13 december 2024
Overarching requirements
Requirement
labelling
Requirement
Criterion
KP02.01
Provision of a communication platform (1/3)
The KP must be made available to personnel cases as a self-service online portal. Access must be
guaranteed both from the intranet of the Mecklenburg-Vorpommern state administration and from the
Internet. It must not be necessary to install local client software.
A
KP02.02
Provision of a communication platform (2/3)
The CP must consist of a web portal and an app (native or web app) for mobile devices. If native apps are
provided, the Contractor shall also be responsible for the provision and ongoing updating in the App Store
or Play Store. The system service also extends to these apps.
A
KP02.03
Provision of a communication platform (3/3)
The CP must include precautions to prevent unauthorised access at user level or unauthorised access
due to attack scenarios. In particular, an automated logout in case of inactivity that can be configured by
the central specialist administration must be provided.
A
KP02.04
Connection to the BundID
The AG intends to enable registration for access to the KP using the BundID. This means that users will
be redirected to the CP by opening a link or a search in the MV service portal. The MV service portal
provides the head office as a central service. The head office handles authentication with the BundID.
The head office is also linked to the KP. Once the BundID app has been called up and the user has
entered the already registered BundID, authentication is carried out with the BundID. The KP must
support such a connection using the BundID (Annex 2.1 / Connection of online services and specialised
procedures to the MV service platform V1.0). It must be possible to use other additional factors.
A
KP02.06
Information according to the Telemedia Act
In the CP, the information according to §5 of the Telemedia Act must be provided in order to fulfil the
information obligations.
A
KP02.07
Data synchronisation between KP and HR system
Changes to data made from the KP by the user and sent to the HR system must be directly available in the
HR system. The synchronisation
is described in ST01.08.
A
Basic functions
The communication platform provides users with a centralised access point to enable communication with the HR departments,
the LAF and the HR system. The functions range from logging in and logging out to context-supported applications, uploading
accompanying documents and the subsequent dispatch of documents. The KP serves as a comprehensive medium that
accompanies the entire process (initial registration, application, document dispatch and receipt).
13 December 2024 Page 107 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP03.01
Self-service (1/4)
The CP must allow selectable data (e.g. address, telephone number, e-mail, bank details) to be viewed
and changed. It must be possible for the central specialised administration to select the data.
The CP must accept feedback from the HR system as part of the plausibility check and display it to the
users
The HR system must check the plausibility of the entries and send a corresponding response to the CP in
the event of an error.
A
KP03.02
Self-service (2/4)
It must be possible to configure which data requires verification as part of the centralised specialist
administration. This evidence can then be sent as an attachment to the web form. The option of
uploading files is described in the requirements for document upload (KP05.09 (document upload) -
KP05.17 (document upload app)).
A
KP03.03
Self-service (3/4)
The CP must enable the application for payments or services and transfer them to the HR system. The
type and scope of the applications or services to be provided via the CP must at least correspond to the
scope of the system to be replaced https://www.mitarbeiterportal-mv.de/ at the time of submission of
the offer plus the processes required in the service description for the CP.
A
KP03.04
Self-service (4/4)
The CP must be able to receive documents from the HR system (e.g. salary notifications, annual
statements such as wage tax statements, social security statements, administrative files, additional
information on salary statements, etc.) and save them to the corresponding user account. In addition,
manual and rule-based deletion (for deletion periods, see Appendix 3.12 Statutory retention periods) of
documents from the mailbox must be possible.
A
KP03.05
Information for users on the homepage
The CP should offer users an area on the start page for current general information from the HR
department and the LAF, which is administered by the Central Specialist Administration.
The current general information must be listed by date. In addition, it should be possible to maintain the
current general information via the central specialised administration. It should also be possible to
format the text of the information entries at least in RTF format.
It should be possible to store entries as links in the information
B
KP03.06
Personal profile
In particular, pursuant to Art. 15 para. 3 GDPR, employees are entitled to be provided with a copy of
their stored data that is the subject of processing. In accordance with Art. 20 para. 1 GDPR, the data
must be provided in a structured, commonly used and machine-readable format.
The CP must show users the data stored about them in the overall system. The possibility of exporting
personal data is described in SA01.03 (Export of personal data), SA01.04 (Overview of personal data) and
requires the provision of this data as an overview in tabular form.
A
KP03.07
P.O. Box (1/3)
The CP must provide users with a mailbox from which they can access the
Access to the documents in accordance with KP03.04.
A
13 December 2024 Page 108 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP03.08
P.O. Box (2/3)
In the KP mailbox, the labelling of the documents as
-
Incoming or outgoing document with date of receipt/creation and status (processing status in the
HR system), as well as the subject of the document (name)
-
Deadline cancellation
-
Number of systems
-
the fuse
-
the deletion date is
displayed.
The mailbox must be sortable and filterable.
B
KP03.09
P.O. Box (3/3)
The CP must highlight received documents in the mailbox until they have been opened.
After opening the documents
-
automatically mark the message as read,
-
automatically report the status to the HR system
-
and remove the highlighting.
A
KP03.10
Document download
When downloading one or more documents at the same time, this must be done in a ZIP folder with the
correspondingly named files in it, which is named at least with the date of creation.
A
KP03.11
Automated notifications
The CP must send automated notifications to the user as a message outside the CP when new
documents are made available. The option of setting a notification path is described in KP04.01
(Settings).
A
KP03.12
Changes to the document status
The HR system must provide information on changes to the processing status via workflow management
(WF02.16 Processing status of tasks (1/3), WF04.04 (Transfer of the processing status to the
communication platform)). The CP must make this information available to the users automatically.
A
KP03.13
Documents - Archiving (1/5)
The CP must display the documents labelled "Release for CP" in the HR system. In addition, the user
must be able to call up the documents stored in the archive system (all documents transmitted to and
from the user). For this purpose, a personalised call against the TR-ESOR adapter in accordance with
interface description ST01.49 must be provided via the client's TR-ESOR archive system.
A
KP03.14
Documents - Archiving (2/5)
The documents displayed in the KP in accordance with KP03.13 must be downloadable by the users.
A
KP03.15
Documents - Archiving (3/5)
The period for which the documents in accordance with KP03.13 are displayed in the KP and can
therefore be downloaded must be configurable by the central specialised administration.
be.
A
13 December 2024 Page 109 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP03.16
Documents - Archiving (4/5)
The KP must provide a web form with which users can request that documents be made available again in
the KP.
A
KP03.17
Documents - Archiving (5/5)
In the KP, user-side document deletions must be excluded as part of access in accordance with KP03.13
due to the legal retention periods in accordance with the GDPR and the requirement for audit-proof
documentation in the DMS.
A
KP03.18
Search function
In the KP, a search function should make it easier to find web forms.
The CP should provide the search function as a full text, keyword search, phonetic search and wildcard
search.
-
Full text search
The contents (field names, descriptions and texts) of the forms available in the system are searched
for the text entered
-
Keyword search
-
The web forms available in the system are analysed according to the keywords stored for the
forms
-
Phonetic Search
The search function is designed to recognise errors when entering search terms and suggest
alternative results similar to the search term entered.
-
Placeholder search
-
The usual wildcards for any character (?), any number of characters (*), numeric character (#) can
be entered in the search.
B
KP03.19
Display of relevant web forms
Users must have the web forms relevant to their personnel case highlighted. The relevance is
determined by the benefit type (pension, pay, remuneration, Personalakt) assigned to the personnel
case.
A
KP03.20
Retrieval of information sheets
The CP must offer users the option of retrieving and printing out information sheets on various topics
(PDF format) provided by the Central Specialist Administration.
A
KP03.21
Link to the knowledge database
The CP must provide links to further topics on the knowledge database (external websites).
It must be possible to set and maintain the links as part of the centralised specialist administration.
An exemplary list of external websites can be found in Appendix 2.4 Knowledge .database
A
KP03.22
Customised GUI
In the KP, buttons that are not available to users due to their rights must be completely hidden (not only
visible without radio buttons).
tion).
A
13 December 2024 Page 110 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP03.23
Contact the KP application support team
The CP should provide contact details for the LAF and the relevant HR department on all pages of the
application that can be configured by the Central Specialist Administration (e.g. via a link to the email
address), e.g. the contact details listed under
3.3.5 described above and the Central Information and Enquiry Office (ZIA).
B
KP03.24
Contact the billing office
The CP must enable contact with the billing or processing centre via a contact form (free text field with
length limit) (SS01.26).
A
KP03.25
Contact to the personnel office
The CP should enable contact with the HR and payroll centre via a contact form (free text field with length
limit). The responsible personnel management office is to be determined from the organisational data of
the HR system.
and the users.
B
Account processing
Requirement
labelling
Requirement
Criterion
KP04.01
Settings
In the KP, it must be possible for the user to change usage options, in particular the delivery of
information (KP03.11(Automated notifications)) and the notification option (KP03.12(Changes to
document status)), when they first log in.
A
KP04.02
Deactivation of the account (1/4)
In the KP, users must be able to manually deactivate their access themselves, with the result that access
to personal documents is prevented. If redundant personal documents are stored in the KP, deactivation
must trigger the deletion of these documents.
A
KP04.03
Deactivation of the account (2/4)
In the KP, the central specialised administration must be able to deactivate a user account manually.
A
KP04.04
Deactivation of the account (3/4)
If a user's access is deactivated, the CP must automatically trigger postal dispatch in the HR system for
unclaimed and future documents.
A
KP04.05
Blocking the account in the event of death
The CP must automatically block the account upon notification of the death of a user by the HR system.
A
KP04.06
Deactivation of the account on death (1/2)
The CP must automatically deactivate access in the event of the death of a user after the configured time
limit has expired. The time limit must be configurable by the centralised specialist administration.
A
KP04.07
Deactivation of the account on death (2/2)
If access is deactivated due to death, the CP must send a notification to the task area of the responsible
processing department if documents are still available.
were not called up.
A
13 December 2024 Page 111 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP04.08
Automatic account deactivation (1/2)
The CP must automatically deactivate the account after a configured transition period when the legal
relationship of the user is terminated. The period must be configurable by the Central Administration.
A
KP04.09
Automatic account deactivation (2/2)
The CP must inform the user of the pending automatic account deactivation in accordance with KP04.08
(Automatic account deactivation (1/2)) within a period that can be configured by the Central
Administration prior to deactivation (e.g. by e-mail).
A
KP04.10
Access control and logging (1/4)
In order to ensure the traceability of the use of the KP and data processing, the KP must automatically
log the activities of the users (registration, login, etc.) as well as the storage, modification, deletion and
transmission of the data
in the
system
in an audit-proof manner
. In doing so, it
must show when, by whom and in what way data was processed.
A
KP04.11
Access control and logging (2/4)
The CP must be able to call up and display the logging in the system.
A
KP04.12
Access control and logging (3/4)
The log files may only be viewed by users who have been assigned a special role for this purpose in the
roles and rights concept due to their supervisory responsibility.
A
KP04.13
Access control and logging (4/4)
The CP must provide selection functions for analysing the log files.
to the market.
A
Form processing by the user
Requirement
labelling
Requirement
Criterion
KP05.01
Provision of web forms
The CP must provide web forms (input masks and fields) based on all LAF forms that can be found on the
LAF website at the time the bid is submitted:
-
For salary: https://www.laf-mv.de/bezuege/Besoldung/Formulare/
-
For a fee: https://www.laf-mv.de/bezuege/Entgelt/Formulare/
-
For supplies: https://www.laf-mv.de/bezuege/Versorgung/Formulare/
New forms or changes to forms must be entered by the contractor within two weeks of notification to
the contractor. Payment shall be made on a time and material basis.
A
KP05.02
Input in and configuration of web forms
The data required to complete the forms must be entered in the input fields of the web forms in the KP
interface
can.
A
13 December 2024 Page 112 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP05.03
Automated data setting in web forms
Data already available in the HR system and/or information supplied by the system (e.g. identification
features of the user) must be automatically inserted into the web forms. These cannot be changed.
A
KP05.04
Pre-filling of web forms
When reapplying for the same benefit, the fields should be pre-filled with the data from the previous
application.
B
KP05.05
Web form processing (1/3)
In the CP, users must be able to edit, temporarily save and delete the content of a web form. Users must
be able to preview the document after completing the web form.
A
KP05.06
Web form processing (2/3)
Once a web form has been processed, the relevant data and any attachments must be transmitted to the
HR system by the CP.
A
KP05.07
Web form editing (3/3)
In the KP, users must be able to access, edit and delete cached web forms at a later date.
A
KP05.08
Free text field
In web forms, users must be able to enter notes/comments as free text at the end of the form.
The central specialised administration must be able to determine which web forms allow free text and
the limit on the number of characters in the free text field.
A
KP05.09
Document upload (1/6)
Documents (formats in particular PDF, TIFF, JPG, PNG, HEIC, DOC) must be uploaded in the CP and
attached to the web forms after automated system conversion into a PDF.
A
KP05.10
Document upload (2/6)
KP must perform an automated virus scan for files that are uploaded.
A
KP05.11
Document upload (3/6)
The KP should display uploaded documents to the user after the automated conversion to PDF (see
KP05.09). The user should be able to confirm the correct conversion or cancel the addition of this file to
the respective process.
B
KP05.12
Document upload (4/6)
The CP must reject password-protected files.
A
KP05.14
Document upload (5/6)
In the KP, documents must be able to be uploaded individually or several at the same time.
A
KP05.15
Document upload (6/6)
In the CP, the Central Specialist Administration must specify the size of the documents to be uploaded per
file and the number of documents to be uploaded simultaneously.
can be limited.
A
13 December 2024 Page 113 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP05.16
Document upload app (1/2)
Users must be able to digitise and import documents as attachments in the app using the mobile device's
camera.
A
KP05.17
Document upload app (2/2)
The app should offer measures to ensure and improve photo quality. These include at least a check of
the photos for sharpness, brightness and contrast, automatic edge detection, blur prevention, skew
tolerance and distortion correction.
B
KP05.18
Action cancellation (1/3)
In the event of a technical cancellation when completing web forms, the CP must provide the changes
made, if these have already been saved, for later continuation of processing.
A
KP05.19
Action cancellation (2/3)
If form processing is cancelled manually, the CP must discard the changes made and the automatic
temporary storage.
A
KP05.20
Action cancellation (3/3)
In the CP, the user must expressly confirm the cancellation with reference to the final rejection of the
changes made.
A
KP05.21
Reference to unsent documents
When logging out of the meeting, a note must be made in the KP about unsent digital forms or
documents.
A
Requesting and providing information
Requirement
labelling
Requirement
Criterion
KP06.01
Unchecked supply information in the CP (1/3)
The CP should provide users with immediate access to current, unchecked benefit information without
involving the LAF processing department. The result transmitted by the HR system should be displayed
to the user. It must be possible to fictitiously supplement the professional career and future pensionable
pay for the period up to retirement.
B
KP06.02
Unchecked supply information in the CP (2/3)
The KP is intended to enable users to save the generated calculations of the unchecked supply
information (see KP06.01) as a PDF document.
B
KP06.03
Unchecked supply information in the CP (3/3)
The users should be able to save the data of the unchecked supply information generated from KP06.01
so that they can be used again later for adjustments.
can access it.
B
13 December 2024 Page 114 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
KP06.04
Unchecked remuneration information in the CP (remuneration calculator) (1/2)
The KP is intended to enable users to immediately retrieve current pay information for remuneration
and salaries without involving the LAF's processing department. Where necessary and available, the data
for the calculation should be retrieved from the HR system and used to enable manual adjustments to be
made using an input form.
All factors relevant to the calculation of remuneration should be individually adjustable by the user (e.g.
number of hours, family allowance, type of health insurance or church tax).
The amount should be stated in both net and gross terms.
The VBL-Ost should be taken into account. After being sent by the user, the request with all data should
be transmitted to the HR system and the result determined according to the request ID should be
received by the HR system and displayed to the user.
It should be possible to save the unchecked salary information generated as a PDF document.
B
KP06.05
Unchecked salary information in the KP (salary calculator) (2/2)
Users must be able to save the data of the generated unchecked salary information from KP06.04 in the
HR system so that they can be used later for adjustments such as
who can access it.
B
Administration
Requirement
labelling
Requirement
Criterion
KP07.01
General administration
For the CP, the general administration of the masks/fields and the configuration of the rights of the
various roles, including revision, must be able to be carried out by the client as part of the centralised
specialist administration.
A
KP07.02
Specialist administration - Portal configuration
The portal configuration parameters for the CP must be customisable by the central administration. The
parameters to be implemented by the Contractor and the associated default values for the go-live of the
CP can be found in Annex 2.2 Standard configuration. Insofar as the parameters in Annex 2.2 refer to
redundant data storage in the CP, they do not apply to an integrated solution without redundant data
storage.
It must be possible for the central specialised administration to assign differentiated rights with regard
to functions and data fields in accordance with the role description (chapter 3.3).
It must be possible to assign several roles to one user.
A
13 December 2024 Page 115 of 366
13 december 2024
KP07.03
Blocking and unblocking of accounts
In the KP, user accounts must be created manually by the Central Specialist Administration.
can be locked and unlocked.
A
Authentication
Requirement
labelling
Requirement
Criterion
KP08.04
Multiple requests for multi-factor authentication
It must be possible to repeat the authentication of KP users for particularly critical transactions (see
SA02.05).
A
KP08.09
Issue safety notice to users
The user must be informed by e-mail about possible unauthorised logins to the KP in the following cases:
-
Registration was made with a different geolocation
-
Login was made from an unknown device
A
4.3
Input management
Data must be able to enter the overall system via various input channels. They are delivered by post, e-mail, digital fax, via the KP
and via input from the processing department of the service units, digital public authority mailbox or other interfaces (e.g. legal
and other reporting systems). All analogue documents are read in from a scan line of the client.
At present, the processing department transfers the data manually to the input masks of the procurement system (media break).
In future, new data records are to be transferred directly to the overall system so that the need for manual input is significantly
reduced.
For this purpose, an OCR/ICR solution will be used that automatically recognises documents based on the image files supplied by
the scanning process in particular, assigns documents to document types and records the relevant content of the documents in
order to then transfer the image files enriched with metadata with the collected information to the HR system for direct further
processing.
The LAF is currently implementing an OCR/ICR solution as part of the introduction of a specialised aid procedure (hereinafter
"OCR/ICR software"). The contractor must connect the OCR/ICR software to read out all data for the overall system.
4.3.1
Document content capture (OCR/ICR)
Requirement
labelling
Requirement
Criterion
IM01.01
Automated data and document import - General
The HR system must support the automated import from the OCR/ICR system. When importing files,
different formats (at least JPG, TIFF, PNG, PDF, msg) including their metadata (e.g. the location data at
the time of creation for image files or the signature data of a PDF) must be supported. are
supported.
It is assumed that the process in the previous processing (OCR/ICR-
software) was carried out without errors.
A
13 December 2024 Page 116 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
IM01.02
Document import - signature/seal
When importing documents, the HR system must retain the electronic signatures/seals, in particular the
signature/seal of the document recogniser (OCR/ICR software) and S/MIME signatures/seals of the
sender.
A
IM01.03
Document import - Metadata
When importing documents, the HR system must generate metadata and save it for the document, in
particular
-
Origin (input channel)
-
Date and time of receipt in the system
-
Unique identification: Entry number/letter number
-
Personnel number (if provided)
-
a subject (using the form code, if provided)
It must not be possible to change the metadata manually. However, it must be possible to add and adjust
the personnel number and subject manually.
A
IM01.09
Automated document import - metadata
The HR system should be able to automatically insert the following metadata when importing from
the OCR/ICR system:
-
Surname of the applicant
-
First name of the applicant
B
ePAePV-A1172
Marking the indices
The HR system should be able to mark the indices of imported documents with the mouse to enrich the
metadata.
B
IM01.04
Document import - Manual (1/3)
The HR system must enable the manual import of PDF documents from the user's client PC (e.g. using
drag & drop).
A
IM01.05
Document import - Manual (2/3)
The HR system should also enable the manual import of other file types (at least JPG, TIFF, PNG, msg,
doc). These must be automatically converted into PDF documents during import.
B
IM01.06
Document import - Manual (3/3)
For manually imported documents, the HR system must request the manual addition of metadata in
accordance with IM01.03 (Document import - Metadata) if required.
A
ePAePV-A0810
Documents from a third-party application
It should be possible to file documents from a third-party application directly in an employee's electronic
Personalakt using the print function.
B
IM01.07
Misdirected documents
The HR system must offer the clerk the option of transferring documents (e.g. in the event of incorrect
system assignment) to the relevant central task area (pay, remuneration, pensions, personnel
administration) (see also chapter
4.7.9.1.1 (Determination of supply data)). Applied electrical
nical signatures/seals must be retained.
A
13 December 2024 Page 117 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
IM01.08
Encrypted e-mails
The HR system may only import encrypted e-mails in unencrypted form.
form. Encrypted e-mails must be rejected.
A
4.3.2
Connection to existing system
Requirements for the interfaces are defined in more detail in chapter 5.5 Interfaces.
Requirement
labelling
Requirement
Criterion
IM02.01
Utilisation of the client's existing solution
The bidder must connect the OCR/ICR solutions (ST01.06) provided by the client to the HR system. Two
connections are required: the connection to the e-Akt and the help system.
A
IM02.02
Data extraction from forms
The HR system must accept the data provided by the OCR/ICR software. The OCR/ICR software is multi-
client capable and only forwards the data to the HR system that is intended for this purpose.
The applicant's details relevant to the HR system comprise the data fields listed in Annex 5.6 (Master
data).
The type of structuring of the extracted data must be agreed with the provider of the OCR/ICR software.
The original documents used and scanned for extraction are stored in an audit-proof, signed form in a TR-
ESOR-compliant data repository provided by the client.
A
IM02.03
Assignment of data from the OCR/ICR software
The HR system must be able to clearly assign the validated data from the OCR
/ICR software.
The data transferred from the OCR/ICR software in accordance with IM02.02 must be transferred to the
corresponding predefined fields of the underlying workflow.
A
IM02.04
Extension of the data fields taken into account
As part of the system service, the contractor must, at the request of the client, expand the data fields
supported in accordance with the IM02.02 requirement to include additional data fields, including the
automated assignment to the respective predefined fields of the underlying workflow in accordance with
IM02.03. This will be remunerated on a time and material basis according to the daily rates specified in
the price sheet.
A
ePAePV-A0198
Import of holiday data 1/2
The HR system should have the ability to import data exports in csv format for requested and authorised
leave from a time recording system (e.g. ZEUS) by the departmental administrator and save them in the
master data.
B
ePAePV-A0241
Import of holiday data 2/2
The imported data from a time recording system (see ePAePV-A0198) should be matched by the system in
the HR system to the corresponding personnel number.
employees can be assigned.
B
13 December 2024 Page 118 of 366
13 december 2024
4.4
Analyses
Operational reporting is an important part of the overall system. It includes the provision of meaningful evaluations for the
central specialist administration, managers and decision-makers, both within the client's organisation and for all downstream
departments.
The new overall system is organised in the following categories with regard to operational reporting.
Classification of reports and reporting Analyses
- from legal norms and standards
This refers to content that must be created and made available to authorised persons on the basis of legal norms (e.g.
salary law) or technically necessary standards (e.g. accounting and cameralistic standards, double-entry accounting
standards). By way of example, the following types are mentioned here:
•
Payroll accounting
•
Tax, social security and year-end reports
•
Contribution statements for pension funds
•
Annual analysis of personnel expenses
•
Data protection and data security
•
Equality and non-discrimination reports
•
Compliance reports
•
Budget and cost analyses,
•
Audit trails and logs, e.g.
- for own use
This includes all content in reporting that is used for internal management, analysis and strategic planning and does not
belong to the first category. The following analyses are examples of this
•
Allowance evaluation for waterway police
•
Alternative payee
•
Set future entries
The following evaluation areas must be provided for the personnel administration area:
•
Severe disability
•
Headcount
•
Personnel development
•
Departures/leavers
•
Anniversaries and birthdays
•
Diseases
•
Further training
•
Absences
•
Judgements
13 December 2024 Page 119 of 366
13 december 2024
•
Organisation
•
HH - Budget and staffing
A distinction is made between the following user roles in the "Analyses" topic area:
- Designer:
The designer initially designs and creates the evaluation logic of a report together with the user (usually the client's specialist
department or downstream departments).
- Producer:
The producer shall prepare the reports in accordance with the specifications and make them available to the authorised
recipients.
- Addressee or addressee:
The authorised addressee is provided with the reports for further use in accordance with the specifications.
By using the analysis tool, the central specialist administration creates, edits, deletes and saves its own analyses and queries.
4.4.1
Statutory and standard analyses
Within the overall system, the analysis tool is understood to be the evaluation function that generates the legally prescribed and
standardised evaluations that the contractor must create and provide as part of the classic evaluations.
13 December 2024 Page 120 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BA01.01
Integration of analyses from legal norms and standards
All evaluations from legal norms and standards (according to Appendix 3.4 List
Evaluations_Documents_Protocols/Tab Evaluation/Column E filtered by legal, standard) must be
integrated into the new overall system and ready for use as soon as data from the client is available.
These include the following analyses:
-
Headcount analyses for each managed department,
-
Automated monthly evaluations of personnel costs and headcount per organisational unit (OEH)
and summarised for the budget-managing departments (TBL),
-
Automated monthly or regular analyses:
•
Children
•
Case numbers per work area
•
Part-time
•
Absences
•
Employment relationships (probationary period)
•
Age structures of employees
•
Sabbath cases
•
Secondary activities
•
Headcount of individual departments by name
-
Overpayments with details of the reason for and period of recovery, outstanding legal remedies.
The following analyses of all existing data records according to various date elements (year, half-
year, quarter, month, day) must be available for the personnel administration area:
•
Severe disability
•
Headcount
•
Personnel development
•
Departures/leavers
•
Anniversaries and birthdays
•
Diseases
•
Further training
•
Judgements
•
Organisation
•
HH - Budget and staffing
Automated means that the analyses are created on a monthly or regular basis without manual
intervention or triggering.
In the event of changes to the underlying legal provisions within the scope of the system service, the
Contractor must adapt the analyses in coordination with the Client in good time before the respective
change comes into force. If further analyses are required due to new or adapted legal provisions, these
must also be carried out by the Contractor in good time before the respective legal provision or
amendment comes into force.
implement the change.
A
13 December 2024 Page 121 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BA01.02
Configuration options
By using the integrated analysis tool, authorised users must be able to add further data fields to
evaluations in accordance with BA01.01, including
•
Processing status, number of processes and time periods
•
Display open test orders
•
Support with appraisal management, including the option of accessing the appraisal history
after special approval
•
Support for training management (e.g. regular training courses)
•
Evaluations and organisation of working hours
•
Display of budget overviews
•
Allowance management
A
BA01.03
Automated creation of evaluations from legal norms and standards It must be ensured in the overall
system that all evaluations from legal norms and standards (according to Appendix 3.4 List
Evaluations_Documents_Protocols/Tab Evaluation/Column E filtered by legal, standard) with reference
to the overall system are created without manual intervention or triggering on the respective legally and
organisationally defined key dates, with the data valid at these times.
This also applies to analyses that have been adapted or newly created due to new or amended
legislation (see BA01.01). It must also be possible to save and export all analyses created in standard file
formats (PDF, XLSX) that are suitable for the respective purpose of the analysis.
A
BA01.04
Creating analyses
In the overall system, it must be possible to sort and filter the analyses in accordance with BA01.01
according to the data fields used.
It must be possible for authorised users to save the selected sorting and filter settings in the long term
and to select and execute them for themselves and other users as required.
A
BA01.05
Mass processing
The overall system must enable analyses to be carried out as mass processing, i.e. the simultaneous
processing and evaluation of data for a large number of data/entries must be possible. These functions
must be able to be carried out efficiently and error-free both as batch and real-time processing
operations.
A
BA01.06
Power loss
It must be possible to carry out the analyses in real time and during the runtime of the calculation
without any loss of performance of the overall system.
A
BA01.07
Standardised catalogue of evaluations
A catalogue of evaluations in accordance with
must be retrievable, searchable and able to be used to call up/execute the analyses.
A
BA01.08
Visualisation of evaluations
The authorised users must be able to visualise the evaluations in accordance with BA01.01, BA01.03 as
required (e.g. pie chart, balance sheet, etc.).
kendiagram, etc.).
A
13 December 2024 Page 122 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BA01.09
Option for the AG:
Access to external BI tool for personnel and pay data
Access to the personnel and payroll data must be possible for the connection of an external BI tool. For
this purpose, a description of the data fields is also provided by the contractor.
A
ePAePV-A0991
Analyses on key dates
The analysis tool must be capable of evaluating and displaying data by authorised persons on freely
selectable key dates.
A
ePAePV-A0992
Analyses of time periods
The analysis tool must be capable of evaluating and displaying data at freely selectable times by
authorised persons.
A
ePAePV-A0994
Comparison of analyses
The analysis tool should enable authorised persons to compare changes in data from a current period to
a comparison period in absolute figures and as a percentage.
B
ePAePV-A0997
Preview with time reference
The analysis tool should enable analyses with a preview of future months and years. The preview must
be based on an extrapolation.
B
ePAePV-A0998
Analyses by age group
The analysis tool should enable analyses of age by age group. The analysis tool must enable the
authorised persons to
to configure.
B
4.4.2
Further, own analyses
The overall system must have an analysis tool for creating complex analyses. The analysis tool must be able to generate further
analyses from the data of the overall system in addition to the legally prescribed and standard analyses. These do not necessarily
have to be generated on the basis of legal standards, but can be used for evaluation purposes as required by the client (e.g. in
accordance with Annex 3.4 List Evaluations_Documents_Protocols/Tab Evaluation/Column E filtered by own requirements). The
analysis tool enables modern methods for data extraction, data processing and visualisation for the users within the LAF
(designer, producer, addressee) and the personnel administration, but also the provision of these results for addressees outside
the LAF and the personnel administration.
The following requirements apply:
Requirement
labelling
Requirement
Liability
BA02.01
Creating analyses
Authorised users (designers) must be able to use the Anaylse tool to create, edit, delete and save
evaluations from scratch as required, taking into account the entire database of the overall system and
building on the evaluations in accordance with BA01.01.
to be able to save.
A
13 December 2024 Page 123 of 366
13 december 2024
Requirement
labelling
Requirement
Liability
BA02.02
Cataloguing of self-created evaluations
It must be possible to include and maintain evaluations created by the client for its own use in a standard
catalogue.
A
BA02.03
Data integration
The analysis tool must be able to import data from various sources in different file formats (in particular CSV,
XLSX, XML) for analyses.
A
BA02.06
Adaptability
The analysis tool itself must be adapted to the client's specific needs and processes during the
implementation phase through parameterisation and configuration by the contractor. This requires at least
the creation of client-specific tables and fields together with field properties as well as the creation of client-
specific analyses including the use of certain diagram types and calculation formulas as specified by the client.
A
BA02.08
Reporting and analytics
The analysis tool must provide comprehensive functionalities for analyses, including
-
Basic data specification of the evaluation (at least name of the evaluation, date of
creation/modification),
-
Page characteristics (e.g. header and footer, especially with numbering, date of creation, page
numbers, etc.)
-
Data fields to be included,
-
Totals, subtotals,
-
Filter and sorting options
-
different chart types (at least bar, pie and line charts)
A
BA02.09
Performance/scalability
The analysis tool must be powerful enough to cope with the growth of the AG's organisation and the
increase in data volumes.
A
BA02.10
Stability and reliability
The analysis tool must be able to recognise and report errors or incorrect entries by the user and offer
correction options without impairing the core functionality.
A
BA02.13
Release stability
When importing new programme versions of the analysis tool, it must still be possible to adopt and use all
evaluations, displays and calculation formulas developed up to that point.
A
BA02.14
Export - File-based
The analysis tool must offer the option of exporting all analyses in common standard file formats (at least
PDF, XLSX).
A
BA02.15
Export - API-based
The analysis tool should offer the option of querying all analyses via an API interface using API commands.
This includes, for example, querying technical data, analyses, configuration data and calculation formulas,
layout information, user information, etc.).
B
13 December 2024 Page 124 of 366
13 december 2024
Requirement
labelling
Requirement
Liability
BA02.17
Automated creation of own analyses Within the analysis tool, it must be possible to automate one-off and
recurring tasks, such as the creation and distribution of analyses, data integrations, data exports, etc., by
separately authorised users. Automated means that the analyses are created on a monthly or quarterly
basis without manual intervention or triggering.
A
BA02.18
Distribution
The automated distribution of results via e-mail should be possible within the analysis tool. Automated
means that the results are sent by e-mail to the respective group of recipients on a monthly or regular basis
without manual intervention or triggering.
B
BA02.19
Historicisation
It must be possible to save individual results of analyses within the analysis tool. If necessary, it must be
possible to reuse the original data basis of an analysis for further analyses.
A
BA02.20
Sorting
The analysis tool must allow the analysed data to be sorted (ascending and descending, alphabetically,
date).
A
BA02.21
Formula calculation
The Anaylse tool must enable mathematical formula calculations via data fields and the output of
calculation results via new columns and rows.
A
BA02.22
Dashboard
The analysis tool must provide a functionality with which the addressees can visualise dashboards and
distribute results in any number and scope.
A
BA02.23
Filter function
The analysis tool is designed to enable filters to be set on the results database after the analysis has been
carried out.
A
BA02.24
Roles and rights
Particularly authorised users (designers) must be able to ablegen and release the evaluations configured in
the Anaylse tool as templates so that they can be called up or executed by other authorised users
(producers).
A
BA02.25
Keywords
The analysis tool should enable the client to store keywords for templates/standard analyses and then
create analyses. The templates/standard analyses should be searchable according to the stored keywords.
B
BA02.26
Analyses - Revision
The Anaylse tool must provide authorised users with overviews of the use of Anaylse tools, the recipients of
content (dashboards and output) and the use of the Anaylse tool.
evaluations) and the contents of the analyses.
A
13 December 2024 Page 125 of 366
13 december 2024
4.5
Output management
In the HR system, a distinction must be made between postal and electronic dispatch channels. For postal dispatch, the
documents must be transferred to the printing line at the DVZ. Printing and enveloping take place there. It should also be possible
for documents to be printed by the SSV and on the LAF's electronic printer and then sent.
As part of the electronic delivery process, the addressees are informed about the KP for payments. For legal reasons, certain
documents (e.g. notices of objection) must always be delivered by post. If notices in the KP for benefits (administrative file) are not
opened by the user within 10 days, the HR system also triggers a postal dispatch via the DVZ print route.
Requirement labelling
Requirement
Criterion
OM01.01
Requirements for sending documents (1/2)
The HR system must provide all documents intended for postal dispatch by file transfer (individual and
mass printing) as PDF via the print interface (ST01.04). To do this, the HR system must convert the
documents to be printed into PDF/A-1b format.
A
OM01.02
Requirements for sending documents (2/2)
The dispatch of documents in accordance with OM01.01 (Requirements for the dispatch of documents
(1/2)) must also be made possible from the HR system in a time-controlled manner (manually and
automatically on the basis of sets of rules).
A
OM01.03
Integrity check
The HR system must support the cryptographic hash function "SHA-256" to ensure the integrity of PDF
files. The requirements in section 4.1.8 "Qualified electronic signature and seal" apply to the signing and
sealing of documents.
A
OM01.04
Completeness check
The HR system must support a completeness check of several PDF files transmitted in accordance with
OM01.01.
A
OM01.05
Print jobs (1/2)
The HR system must provide a function for creating print jobs for transmission in accordance with
OM01.01 (Requirements for sending documents (1/2)).
A
OM01.06
Print jobs (2/2)
The HR system must provide a function for intervening in the processing of print jobs. The print jobs
must only be configurable by authorised roles/persons. All changes to print jobs must be changed.
be logged in a tamper-proof manner.
A
13 December 2024 Page 126 from 366
13 december 2024
Requirement labelling
Requirement
Criterion
OM01.08
Automated dispatch control of the individual letters
By default, letters must be sent by post (transfer to the print interface in accordance with OM01.01
(Requirements for sending documents (1/2)). If the personnel case is registered in the CP and access is
active, the dispatch must be automated via the CP instead. The case handler must have the option of
selecting a different dispatch type until the dispatch is triggered.
In particular, the following options must be available:
-
Dispatch by e-mail,
-
Dispatch to estate
-
Prevent dispatch to
BeBPo dispatch
A
OM01.09
Dispatch of documents in the event of death
In the event of the death of an employee, the HR system should trigger the automatic dispatch of the
documents intended for dispatch to the legal successor if a legal successor exists. If no legal successor is
known, the documents must be sent instead.
B
OM01.10
Customised printing (1/2)
The HR system must enable manually executed print jobs to the printer drivers stored in the system
(individual printing).
A
OM01.11
Customised printing (2/2)
In the HR system, the central specialised administration should be able to define standard settings for
each document template for individual printing (e.g. printing via SSV, only complete printing or
selection of individual pages, duplex or simplex).
B
OM01.12
Repetition of the print through individual printing
The HR system must support a manual repeat option for print jobs at all times (e.g. in the event of
faulty printing processes such as paper jams, no ink/toner).
A
OM01.13
Logging (1/2)
The HR system must log the dispatch of each document and display this log to the auditing department
or centralised specialist administration on request. The log must at least list
-
when,
-
by whom and
-
which channel was used
for the dispatch.
A
OM01.14
Logging (2/2)
The HR system should log the retrieval of these documents by the respective user (cf. OM01. .(receipt
of confirmation of assignment and read confirmation and triggering of dispatch)) with the time of
retrieval when the documents are entered in the KP for remuneration
B
OM01.15
Sending emails and notifications to the CP for payments
The HR system must enable notifications to be sent to personnel cases via an interface using the KP for
Pay (ST01.08) and by e-mail.
A
13 December 2024 Page 127 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
OM01.16
Mass printing - data transfer
The HR system must also create a "request file" in the target directory for each print job after the print
file has been transferred. The request can be for a single print file or for all transferred files
("Filename.request" or "Daily.request").
A
OM01.18
Option for the AG:
Creation of interface specifications for printing and enveloping
During the implementation phase, the Contractor must develop the target interface specification for
the connection to the DVZ printing line with the Client at the request of the Client and enable a
connection of the printing line to the HR system on this basis. A technical description of the interface in
the form of a BetaUX manual is attached (see SS01.23).
A
ePAePV-A0978
Export of created tables
The HR system should be able to export tables, including their layout and set filters, in the same way as
they were created by the departmental administration.
B
ePAePV-A0506
Information on personnel changes
The HR system is intended to enable the administrative departments to transmit information about
personnel changes to other organisational units within the department.
B
4.6
Roles and authorisations
A distinction must be made between different roles and rights in the overall system, which can be approved by the head of
department and configured by the IT administration (user and authorisation management). Taking into account the
circumstances and specifics, the roles and rights concept depicts the working methods of the LAF's administration and personnel
administration and explains which accesses are and are not permitted for which roles at which levels (processes, functions, fields,
etc.).
Requirement
labelling
Requirement
Criterion
RB01.01
Delimitation of areas of responsibility (1/2)
In the overall system, it must be ensured that the areas of responsibility of the persons and bodies
involved in the process can be defined and delimited from one another (compliance concept).
A
RB01.02
Delimitation of areas of responsibility (2/2)
In the overall system, it must be ensured that it is possible to determine at any time which users,
including administrators and other system administrators, were equipped with which authorisations at
which time.
A
ePAePV-A1213
Assignment of roles
The HR system must enable the assignment of several roles to one user.
people.
A
13 December 2024 Page 128 of 366
13 december 2024
Requirement
labelling
Requirement
ePAePV-A1216
Assignment of object and function rights
The HR system must offer the option of restricting the object and function rights of a role to certain
personnel cases via criteria when assigning it to a user. Criteria must be freely combinable and in
particular the following:
-
Career,
-
Organisational unit,
-
Age,
-
Name (e.g. from A-M and N-Z).
RB01.03
Central user administration (1/4)
Central user administration must be made possible for the administration of roles so that authorisations
can be assigned in a user-friendly manner.
RB01.04
Central user administration (2/4)
The roles must be able to be defined and configured by the central specialised administration.
RB01.05
Central user administration (3/4)
The central specialist administration must be provided with simple handling for assigning, restricting and
managing write, read and delete authorisations.
RB01.06
Central user administration (4/4)
It must be automatically documented in an audit-proof manner who had which authorisations within the
application and when, and who granted these authorisations.
RB01.07
General authorisation control
Any read or change access to data is only permitted after passing a prior authorisation check. For this
purpose, the user must be authenticated before using the application.
RB01.08
Effectiveness of authorisations
Each role may only act for the authorisations assigned to it. For example, the central specialist
administration and application support of the service units may not assign administrative authorisations
other than those assigned to them.
RB01.09
Detailed assignment of rights (1/2)
In accordance with the rights and roles concept, it must be possible to restrict access to the system and to
individual files and tasks, i.e. documents must be
be hidden for unauthorised persons or unauthorised user groups.
13 December 2024 Page 129 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
RB01.10
Detailed assignment of rights (2/2)
It must be possible to assign rights both to roles and to individual users. As a minimum, it must be
possible to assign the following rights in the following different constellations:
-
Read authorisation (read access to files and/or metadata of the written documents)
-
Write authorisation for editing tasks
-
Create new instances (files, tasks)
-
Saving documents and files
-
Changing data
-
Release of data (dual control principle)
-
Deletion (deletion of documents or files) (dual control principle)
-
Assigning rights (administration rights)
-
Assignment of tasks
-
Set and delete manual authorisations
A
RB01.11
Central specialised administration (1/2)
The central specialised administration must be able to configure system settings (e.g. password rules,
rules for the automatic logout of users).
A
RB01.12
Central specialised administration (2/2)
The central specialised administration must be able to administer master data (e.g. office numbers).
A
RB01.13
Substitute roles
It must be possible to set up and configure substitution roles, whereby rights are transferred.
A
RB01.14
Temporary limitation of roles
It must be possible to grant rights for a limited period of time.
A
RB01.15
Temporary deactivation of user accounts
User accounts should be able to be temporarily deactivated for later reactivation (e.g. during parental
leave).
B
RB01.16
Assignment of the processing of tasks
It must be possible to assign the processing of tasks to predefined groups of people and/or individual
users.
A
RB01.17
Representation (1/4)
The HR system must offer users the option of hiring people or groups of people as substitutes. Only the
object rights (responsibilities), not the functional rights, are transferred to the deputy. The assumption of
the deputisation must be recorded and documented.
A
ePAePV-A0634
Representation (2/4)
The HR system must offer users the option of deputising for several users.
A
ePAePV-A0636
Representation (3/4)
The HR system should offer users the option of authorising as
The right to withdraw the proxy at any time.
B
13 December 2024 Page 130 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0637
Representation (4/4)
The HR system should offer users the option of creating a deputy for a specific period of time.
B
RB01.18
Deposit of a representation concept
It should be possible to store a substitution concept with rules for automated substitution.
B
RB01.19
Temporary transfer of responsibility (1/3)
The HR system must enable the processing department to temporarily assign read and/or write access
rights to objects assigned to it to other users and/or task areas (e.g. in the event of an appeal or seizure).
A
RB01.20
Temporary transfer of responsibility (2/3)
In defined cases, the HR system should automatically grant object rights with the transfer of tasks. It
should be possible to link the end of the transfer of responsibility to specific processing steps.
B
RB01.21
Temporary transfer of responsibility (3/3)
When setting up the temporary transfer of responsibility, it should be possible to limit the intended
duration.
B
RB01.22
Preventing the processing of personal data
In the HR system, users must be blocked from editing and changing data for their own person (e.g.
blocking their own PNR and assigning the PNR to another user).
A
RB01.23
Access to personnel cases
The HR system must allow several users from different departments to be granted (parallel) access rights
for personnel cases.
A
RB01.24
Assignment of rights to roles
Rights that are assigned to roles by the central specialist administration (RB01.10 (Detailed assignment
of rights (2/2)) must include the multiple request for multi-factor authentication described in KP08.04
(Multiple request for multi-factor authentication) for particularly critical or sensitive transactions and
dialogues.
support factor authentication.
A
4.7
Payroll accounting
The following chapter contains the functional and technical requirements for payroll accounting, which are implemented by the
payroll, remuneration and pensions departments. They thus form the basis of the system behaviour requirements to be met by
the procedure to be created.
A significant proportion of these requirements result from mandatory legal framework conditions of the state of Mecklenburg-
Vorpommern (MV) or the federal government. The legal framework conditions are listed in chapter 2.4.
13 December 2024 Page 131 of 366
13 december 2024
When considering functional payroll accounting, in addition to the overarching functional requirements, which have a decisive
impact on the use of the HR system, the requirements of the general specialised processes and business transactions also play a
major role.
The technical requirements initially relate to the overarching requirements of active beneficiaries and pension recipients, before
going into more detail on the specific requirements of calculating the remuneration of active beneficiaries on the one hand and
the special features of calculating the remuneration of pension recipients on the other.
Where the administrative processes are described in great detail, this serves to guide bidders when submitting indicative bids.
The functional requirements for the future HR system relating to payroll accounting are briefly summarised and tabulated in the
following subsections.
4.7.1
Legal requirements and HR system catalogues
To ensure that all data can be processed in the HR system (e.g. calculation of remuneration), the HR system must map the
relevant laws and regulations of at least the laws and regulations listed in 2.4. This also includes the payroll-specific tables (in
particular pay tables and salary tables). In addition, various catalogues for payroll accounting, such as contribution rates and
percentages, which are specified by the health insurance funds and the VBL, must be maintained in the HR system in addition to
those catalogues from chapter 4.1.2.
Requirement
labelling
Requirement
GV01.01
Legal requirements
The HR system must be capable of calculating remuneration, managing personnel and recording,
processing and checking related tasks in accordance with the regulations relevant to remuneration
processing as defined in section 2.4, in particular in accordance with the following requirements
-
of the LBG MV,
-
of the LBeamtVG MV,
-
of the LBesG MV,
-
the relevant collective agreements
and the associated laws and regulations (in particular those listed in 2.4).
GV01.02
Updating legal requirements/legal regulations
In the HR system, the Contractor must make a corresponding adjustment as part of the system service
no later than the effective date in the event of changes to the regulations relevant to remuneration
processing that have an impact on the requirements and rules stored in the HR system, so that
processing in the HR system complies with the applicable remuneration law for the state of
Mecklenburg-Vorpommern.
GV01.03
Historisation of legal requirements/legal regulations
The HR system must historicise stored requirements and rules on the basis of the legal bases listed in
GV01.01 (Legal requirements) and make previous versions available to the user even after updates (e.g. due
to changes in the law).
the processing of the covers.
13 December 2024 Page 132 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
GV01.04
Application of historicised previous versions of the legal requirements/legal regulations
In the HR system, clerical staff must be able to select the historicised previous versions of the legal
requirements/legal regulations for application to specific processes.
A
GV01.05
Maintenance of billing tables
The Contractor must keep all tables on which the calculations are based (in particular pay tables, salary
tables, foreign salaries, allowance tables, time supplement tables, data from banks, supplementary
pension funds, health insurance funds, accident insurance funds, occupational pension schemes) in the
latest version in the HR system and adapt them accordingly as part of the system service in the event of
changes at the latest when the respective updated table comes into force.
A
GV01.06
Display of previous versions of the billing-specific tables
The HR system should offer the option of viewing previous versions of the tables on which the
calculations are based.
B
GV01.07
Catalogues of supplementary pensions (1/4)
The HR system must hold the percentage of the employer's supplementary pension contribution for the
supplementary pension.
A
GV01.08
Catalogues of supplementary pensions (2/4)
The HR system must provide the employee and employer contributions to the capital cover system for
the supplementary pension scheme.
A
GV01.09
Catalogues of supplementary pensions (3/4)
The HR system must provide the employee and employer contributions for voluntary insurance of
scientific employees for each supplementary pension fund.
A
GV01.10
Catalogues of supplementary pensions (4/4)
The HR system must provide the maximum limit of the remuneration subject to supplementary insurance
per supplementary pension fund VBL East and West.
A
GV01.11
Supplementary pension catalogues - maintenance by the central specialist administration The HR
system must enable the central specialist administration to maintain the percentage rates of the
supplementary pension contribution and the limit amounts and maximum amounts of the
supplementary pension.
A
GV01.12
Maintaining catalogues - Tax and social security treatment of contributions and levies
In particular, the contractor must calculate the limit amounts according to
-
§ 3 No. 56 EStG,
-
§ 40 b EStG,
-
§ 3 No. 63 EStG,
-
§ 100 EStG
-
§ Section 1 (1) sentence 1 no. 9 SvEV and Section 1 (1) sentence 3 SvEV
as part of the system service in the HR system.
A
13 December 2024 Page 133 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
GV01.13
Social security catalogues (1/3)
The employee must keep the contribution rates for health, long-term care, pension and unemployment
insurance historicised in the HR system in accordance with the applicable legal situation (e.g. with regard
to health insurance):
-
general/increased/reduced contribution rate,
-
Individual supplementary contribution according to § 242 SGB V,
-
average additional contribution according to § 242a SGB V,
-
Contribution rate for pension payments (KVdR),
-
Allocation rate for maternity protection expenses (U2),
-
individual contribution rates in accordance with the PUEG).
A
GV01.14
Social security catalogues (2/3)
The contractor must keep the contribution rates of the agricultural health insurance funds historicised in
the HR system.
A
GV01.16
Social security catalogues (3/3)
The HR system must provide the contribution for voluntary insurance for all statutory health insurance
funds and a different pay-as-you-go fund for members of an agricultural health insurance fund in
historicised form.
A
GV01.17
Annual adjustment of the garnishment exemption limit notice
The HR system must hold the amounts of the annual garnishment exemption limit notification.
A
GV01.18
Base interest rate
The HR system must provide the current base interest rate in accordance with Section 247 (2) BGB.
A
GV01.23
Statutory values for pensionable remuneration
The HR system must include all pensionable remuneration whose value is determined by
the LBesG MV or its annexes.
A
4.7.2
Workflow management
In addition to the requirements for the HR system set out in section 4.1, which only relate to payroll accounting, these
requirements are set out below.
General requirements for workflow HR system
Requirement labelling
Requirement
Criterion
WF01.34
Minimum recalculation depth
The HR system must map a retroactive accounting depth of 4 years plus the current year.
A
WF01.35
Extended recalculation depth
The HR system should have a retroactive accounting depth of 6 years plus the current year.
map.
B
13 December 2024 Page 134 of 366
13 december 2024
Workflows for task areas and tasks in the HR system
Requirement
labelling
Requirement
Criterion
WF02.06
Generation of tasks
The HR system must generate a task in the relevant central task area (remuneration/payment/benefits)
when the departments enter data relevant to remuneration calculation.
A
WF02.13
Processing tasks from the departments (1/2)
In the HR system, changes to data that initially originate from the departments must be displayed for
release, correction and referral back to the areas of responsibility of the respective departments.
A
WF02.14
Processing tasks from the departments (2/2)
The HR system must enable the LAF processing department to make immediate changes to data initially
originating from the departments (especially in the case of simple typing errors). In this case, only a note
must be sent to the relevant department.
A
WF02.20
Resubmission of tasks with condition
The HR system must allow resubmissions for tasks to be assigned conditions (defined technical
requirements). If the resubmission deadline expires and the condition is fulfilled, the task must be
displayed again with a pre-selectable notification text.
A condition may be, for example, that an amount to be offset could not be offset in full.
The HR system must make it possible for the centralised specialist administration to be able to formulate
the information texts for tasks with conditions.
A
WF02.22
Prioritisation of tasks
The HR system should prioritise tasks that are identified as errors due to the plausibility check of a data entry
in the categories according to
the error categories in requirements PP01.05.
B
Special workflows
Requirement
labelling
Requirement
Criterion
WF04.05
SCL Directory and BIC Directory
The HR system must receive and read the updated data from the SCL Directory and the BIC Directory
(SS01.29) and use it to update the HR system's bank master data. The data transfer and the completed data
update (incl. any data updates) must be recorded.
error events) must be logged.
A
WF04.06
Processing DEÜV-A1
The overall system must enable the departments to send DEÜV-A1 applications to the GKV for confirmation
(SS01.04). The decision of the responsible health insurance fund must in turn be made available as a task in
the department's area of responsibility.
A
WF04.07
Notification to the department after completion of the pension benefits
The overall system should send automated information to the last department to which the personnel case
belonged if no pension benefits have been paid for this case.
The benefits are no longer granted to employees and their surviving dependants.
B
13 December 2024 Page 135 of 366
13 december 2024
4.7.3
Data acquisition
In addition to the requirements set out in section 4.1.1, the following section sets out requirements for the HR system that only
relate to payroll accounting.
Requirement
labelling
Requirement
DE01.08
Enter personnel case status
The HR system must allow the administrator to enter a personnel case status for each personnel case. It
must be possible for the case handler to change this status manually.
Example: The administrator records a new personnel case and enters the status manually.
DE01.09
Select personnel case status from personnel case status catalogue
The HR system must enable the administrator to select and assign a personnel case status from a
personnel case status catalogue for each personnel case. The catalogue containing the personnel case
statuses must be modifiable and expandable by the central specialist administration. The current
personnel case statuses as of 30 November 2023 are listed in Appendix 3.1 (Personnel case status).
Example: The processing department takes on a new personnel case and sets the
Status based on the stored catalogue on "New entry - payment acceptance".
EN01.14
Limiting the number of digits
The overall system must allow a euro amount of up to 7 digits before the decimal point. The limitation of
the number of digits should be configurable by the central specialised administration.
EN01.18
Linking of personnel cases
The HR system must enable the administrator to link and display related personnel cases. When a
personnel case is called up, the linked personnel cases must be displayed and it must be possible for the
administrator to call up these personnel cases directly.
Example: The administrator opens a personnel case (orphan). It is shown that there are linked personnel
cases (deceased civil servant, widow). Selecting a linked personnel case (deceased civil servant) opens it.
DE01.20
Automated master data transfer
The HR system must make it possible to automatically transfer necessary, already recorded master data of
spouses, life partners and children (e.g. surname, first name, date of birth, date of marriage), especially for
survivors' pensions and survivors' old-age benefits, to separate, new personnel cases. At the discretion of
the administrator, other master data such as the address and bank details of the original personnel case
(e.g. deceased civil servant) should also be transferred with the transfer.
EN01.23
Assignment of a personnel case to departments and booking centres
In the HR system, it must be possible to assign several booking centres (up to 5 booking centres) and
several departments (up to 3 departments) to a personnel case. These booking centres affect all pay
components. It must be possible to allocate the allocation on a percentage basis to different booking
centres and departments.
different departments if necessary.
13 December 2024 Page 136 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EN01.24
Assignment of different booking centres for all payment components
The HR system must take the allocation of remuneration components into account.
The system allows the creation of different booking centres for each pay component.
A
4.7.4
Multiple legal relationships and claims with the same and different employers/employers
As a service provider, the LAF accounts for various types of remuneration. These include
- Remuneration, e.g. for employment relationships, training relationships and internship relationships,
- Remuneration, e.g. for civil servants, judges and officials,
- Pension payments for retired persons and their surviving dependants with pension entitlements, and
- Retirement benefits for persons entitled to retirement benefits and their survivors entitled to retirement benefits.
It can happen that a person works in parallel, for example
- may have several employment contracts with different pay-related master data (e.g. pay group, level) with one employer
(e.g. 20 h University of Rostock + 20 h University of Applied Sciences Neubrandenburg), which must be accounted for via one
employment relationship/one personnel number.
- can have several employment contracts with different employers (e.g. 20 h University of Rostock + 20 h Leibniz Institute of
Atmospheric Physics e.V.). In this case, an employment relationship with the respective employer is entered into with each
employment contract, which must be accounted for separately, as each employer requires a separate personnel number.
- can have an employment relationship with the same employer in addition to a training relationship under private or public
law (e.g. trainee teachers+ employed as part-time teachers). Different legal relationships are entered into here, which must
be assessed separately under social security law but considered together for tax purposes because they involve the same
employer. Payroll accounting via a personnel number would be desirable.
- pension recipient including surviving dependants and is in a service/employment/training relationship with the same
employer (one personnel number),
- is a pension recipient including surviving dependants and is in a service/employment relationship with another employer
(one personnel number per employer).
The various legal relationships and entitlements must each be separately categorised by the HR system. The legal relationships
and claims include in particular
- Employment and training relationships,
- Pension or retirement benefit claims,
- employment relationships (civil servants/judges) or official relationships and
- Pension or retirement benefit claims.
If necessary, they are processed in the HR system by various clerks in the Remuneration, Salaries and Benefits departments.
13 December 2024 Page 137 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
MR01.01
Multiple legal relationships and claims with the same employer
The overall system must offer the possibility of recording several legal relationships and entitlements to
the same employer/principal for each personnel case, even overlapping in time, regardless of the
relevant tax, social security and supplementary pension law requirements.
Where regulated by law or collective agreement, the various relationships and entitlements must be
assessed separately, but a standardised report must be submitted in the reporting procedures (see
SS01.04).
The settlement of parallel relationships and claims must be presented accordingly in documents (e.g. the
remuneration statement).
A
MR01.02
Multiple legal relationships and claims with the same employer within one personnel number
The overall system must be within a personnel number according to the specifications of MR01.01
cover several legal relationships and claims to the same employer/principal.
A
MR01.03
Multiple legal relationships and claims with different employers/service providers
The overall system must offer the possibility of recording several legal relationships and entitlements of
different employers/principals for each personnel case, even overlapping in time. Different
employers/principals require the allocation of different personnel numbers for the same natural person.
Person.
A
4.7.5
Curriculum vitae data
In addition to the requirements for the HR system set out in section 4.1, which only relate to payroll accounting, these
requirements are set out below.
Requirement
labelling
Requirement
Criterion
LD01.02
Manual recording for fictitious calculation
For fictitious calculations (e.g. pension information), the HR system must enable the temporary manual
entry of CV data for periods in the future.
A
LD01.03
Provision from the Personnel Management module
The Remuneration module must be able to transfer all existing data on the CV of a personnel case (in
particular the data listed in LD01.01.) from the Personnel Management module, insofar as this data is
available there (see Remuneration data module)
interface SS01.40).
A
13 December 2024 Page 138 of 366
13 december 2024
LD01.08
Supply surcharge
In the case of leaves of absence without pay and secondment cases without the intention of transfer, the
overall system must enable the processing department to document, in particular with regard to Section
6 (1) sentence 2 no. 5 letter b LBeamtVG MV, whether
-
the leave of absence serves public/official interests,
-
the pension supplement is still payable and or, exceptionally, is not raised,
-
the pension supplement has been paid in full,
-
the extent to which the pension supplement was paid in the event of only partial payment.
A
LD01.09
Pensionability
The HR system must enable leaves of absence without pay to be manually marked as part-time and fully
pensionable.
tions.
A
4.7.6
Dark processing
As part of process control, it is possible to trigger dark processing on the basis of configurable criteria. The dark processing
process can be viewed as an automated process of system-supported remuneration processing without clerical processing, from
the request to the creation of the remuneration notification. The HR system performs all functions autonomously in the context
of dark processing that are the responsibility of the clerks in the context of manual system-supported transaction processing. The
necessary prerequisites for dark processing are high-quality digitised data from input management and the interfaces, complete
(master) data and plausibility checks carried out without any anomalies. The dark processing process can be defined and
modelled as part of a workflow. Further manual processing of tasks by the clerk is possible, for example if data is missing or
anomalies occur during processing.
Requirement
labelling
Requirement
Criterion
DV01.01
Criteria-led dark processing
The HR system must offer the option of processing workflows and data fields in a fully automated
process without user intervention, from receipt of the application to the creation or payment of the
notification.
A
DV01.02
Configuration of criteria-driven dark processing
The selection of workflows and data fields for dark processing must be configurable by the central
specialised administration.
A
DV01.03
Internal labelling
The HR system must be able to ensure that all letters and notifications created by dark processing are
labelled internally.
A
DV01.04
Manual processing for inspection anomalies
The HR system must be able to remove tasks that have been assigned to dark processing from dark
processing when the applied rules and plausibility checks are triggered and transfer them to a manual
processing procedure.
A
13 December 2024 Page 139 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DV01.05
Documentation of the dark processing steps
The HR system should be able to record at least all the steps involved in the gross calculation of the dark
processing of a task in a comprehensible manner in a database created by the
and to document and historicise them in an overview that can be viewed by the processing department.
B
4.7.7
Requirements Remuneration
Remuneration is only specified by the employment relationship in the public sector. Employees and trainees of the state of
Mecklenburg-Vorpommern are entitled to remuneration from their employment/training relationship. This is based on collective
labour agreement regulations.
4.7.7.1
Gross calculation
The Gross calculation chapter and its sub-chapters describe how gross pay is calculated in the HR system. The calculation is
carried out for all pay components and concerns both "normal" employees and specially described cases and special employment
relationships. If necessary, gross pay is reduced or minimised or adjusted according to the scope of employment. One-off and
special payments are also granted.
4.7.7.1.1 Basic references
The HR system must determine or calculate all remuneration components (incl. e.g. steps, continued remuneration) in
compliance with collective bargaining and legal standards and enable posting to one or, if necessary, several posting centres.
For the calculation of fees in this chapter, the overarching requirements from the chapters
4.7.10.1 (General technical requirements: Gross calculation - general pay calculation) and
4.7.10.2 (General technical requirements: gross calculation - benefits) Application.
Requirement
labelling
Requirement
Criterion
EG01.01
Calculation of the basic components Remuneration (1/6)
The HR system must enable the calculation of remuneration in compliance with all collective bargaining
and other federal and state regulations as well as the corresponding administrative regulations, in
particular §§ 16, 17, 24, 28, 29, 37 TV-L, EStG, administrative regulations (VV), decrees, implementation
instructions of the TdL, TV-Forst, TVA-Forst, TV-L PKW Fahrer, TVA-LBBiG, TVdS-L.
A
EG01.02
Calculation of the basic components of remuneration (2/6)
The HR system must take partial months and other remuneration components for parts of a month into
account when calculating remuneration.
A
EG01.03
Calculation of the basic components of remuneration (3/6)
When calculating the remuneration, the HR system must take into account the payment of the portion of
the table remuneration attributable to one hour as well as the other remuneration components specified in
the monthly remuneration, if only for part of a calendar day.
entitlement to remuneration exists.
A
13 December 2024 Page 140 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG01.04
Calculation of the basic components of remuneration (4/6)
When calculating the fee, the HR system must ensure the entry and correct allocation of costs for several
booking centres (see section 4.7.14 Payment/payment) with regard to a person for
-
current payments,
-
One-off payments,
-
Employer costs for social security and
-
company pension scheme
(e.g. for employees in various projects).
A
EG01.05
Calculation of the basic components of remuneration (5/6)
When calculating the remuneration, the HR system must offer the input and correct allocation of costs in
the event of a different booking centre for one or more other remuneration components.
A
EG01.06
Calculation of the basic components of remuneration (6/6)
When calculating pay, the HR system must enable the recording of job characteristics (e.g. sections,
subsections, etc. of the pay scales and classification guidelines) in addition to the pay group and level.
A
EG01.07
Creation of groups of people
The HR system must enable the assignment of personnel cases to groups of persons (e.g. see Appendix 3.2
(Groups of persons)).
A
EG01.08
Configuration of groups of people
The HR system must enable the central specialised administration to configure the personnel groups (i.e.
the assignment of personnel cases to personnel groups).
A
EG01.09
Automated calculation of tariff specifications (1/6)
The HR system must enable the automated calculation, including the level, on the basis of the pay group
entered/adopted in which the employee is categorised.
A
EG01.10
Automated calculation of tariff specifications (2/6)
The HR system must allow a different level to be specified manually.
A
EG01.11
Automated calculation of tariff specifications (3/6)
The HR system must
-
Determination of the level for new hires,
-
the calculation of the subsequent stages,
-
the recalculation of levels in the event of a change in the initial prerequisite (e.g. higher or lower
grouping, continued employment after detrimental interruptions, change in the legal relationship)
automatically based on the current pay group.
It must be possible to manually enter/accept the remaining time/periods in the preparatory service that can
be credited to the teaching profession as a stage duration.
stand.
A
13 December 2024 Page 141 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG01.12
Automated calculation of tariff specifications (4/6)
The HR system must offer the option of automatically monitoring the step duration in the respective pay
group in accordance with Section 16 (3) TV-L in conjunction with the respective grouping regulations (e.g.
the pay scales), taking into account any creditable remaining periods etc., so that step increases (e.g.
Section 16 TV-L) can also be automated, taking into account any interruption periods (Section 17 (3) TV-L).
It must be possible for the administrator to deactivate the extension of the step duration for individual
employees if required.
The increased table salaries (e.g. in accordance with Section 19 (2) sentences 2 and 3 TVÜ-L) must be taken
into account automatically.
A
EG01.13
Automated calculation of tariff specifications (5/6)
The HR system must allow manual intervention in the step duration so that step duration reductions or
inhibitions and extensions (Section 17 (2) TV-L) can be implemented after notification by the HR
departments.
A
EG01.14
Automated calculation of tariff specifications (6/6)
The HR system must automatically implement a collectively agreed extension of the step duration and the
delay of the corresponding step advancement (§ 17 TV-L) in the event of recorded absences, in particular
child sickness, parental leave, leave of absence.
A
EG01.15
Calculation of basic components - general (1/2)
In particular, the HR system must enable data for payroll accounting to be accurately recorded and
calculated on a daily basis in accordance with Section 24 (4) TV-L/TV-Forst. The statutory rounding rules
must be taken into account in the calculations. The pay-relevant data (pay groups and pay grades) must be
able to change on a monthly basis (if necessary also within the payroll period) and be converted with effect
for the past (up to the maximum retroactive accounting depth) or future payments.
A
EG01.16
Calculation of basic components - general (2/2)
In particular, the HR system must, in accordance with Sections 24 (2) and (3), 28, 29 TV-L, offer the
possibility of reducing the remuneration of part-time employees in the same proportion as the working
hours, subject to deviating provisions. The statutory rounding rules pursuant to Section 24 (4) TV-L must be
taken into account in the calculations.
When calculating the remuneration, the
-
Special leave regulations (§ 28 TV-L) and time off work (§29 TV-L) with/without pay and
-
Reductions by the day and by the hour (Section 24 (3) TV-L, e.g. disciplinary proceedings, entitlement
to remuneration for part of the month or strikes)
can be taken into account.
A
EG01.17
Upgrading and downgrading in pay calculation (1/2)
In accordance with Sections 16, 17 (4), 52 TV-L, the HR system must enable the table pay to be determined
automatically from the higher or lower pay group and the level to be determined (with the option of
manual correction) as well as any guarantee amount to be determined.
A
EG01.18
Upgrading and downgrading in pay calculation (2/2)
The HR system must automatically check the respective higher/ lower grouping for table changes and
automatically set a guaranteed amount to be paid.
lenges.
A
13 December 2024 Page 142 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG01.19
Continued payment of remuneration (1/2)
The HR system must automate the continued payment of remuneration in accordance with § 21 TV-L/TV-
Forst and the Continued Remuneration Act, in particular in the case of
-
Incapacity for work,
-
Holidays,
-
on public holidays and
-
on days with time off/special leave with continued payment of remuneration, both for the table
remuneration and the other remuneration components specified in monthly amounts, as well as for
the average amounts for non-permanent remuneration components (§ 21 sentences 2 and 3 TV-
L/TVF)
enable.
A
EG01.20
Continued payment of remuneration (2/2)
The HR system must ensure automated monitoring of continued remuneration periods for incapacity for
work.
A
EG01.21
Automated determination of continued remuneration period
The HR system must be able to transfer the data on previous periods of sickness from the EEL notification
procedure to the associated personnel case. The HR system must use this data to calculate the continued
remuneration period.
A
EG01.22
Suspension of payment at the end of the continued remuneration period
Once the continued remuneration period has been determined, the HR system must automatically stop
payment at the end of the determined period.
A
EG01.23
Calculation of holiday pay (continued remuneration)
The HR system should automatically calculate the holiday pay at the time it is actually taken. The HR
system must comply with the TdL's implementation instructions of 26 October 2020 on holiday entitlement
in the event of a change in the scope of employment/employment model during the holiday year.
B
EG01.24
Structural equalisation
In accordance with Section 12 TVÜ-L, the HR system must enable the non-dynamic structural compensation
currently paid. The distinction between structural compensation to be reduced and not to be reduced in
the case of part-time work must be maintained. The offsetting of gains from upward grouping against the
structural compensation and the continued payment in the event of downgrading must be carried out in
accordance with the current regulations.
A
EG01.25
Foreign remuneration
The HR system should also offer the option of applying the relevant provisions of state pay law to pay-scale
employees in foreign offices of the state in accordance with §§ 2, 75 LBesG MV and §§ 52-57 BBesG,
provided that the assignment abroad is for at least 12 months.
This enables the automated calculation and payment of foreign allowances and purchasing power
adjustments, taking into account the relevant indexing (to be provided by the contractor) and the zone key.
For this purpose, the possibility of manual recording of foreign use and the amount of rent as well as the
possibility of recording and making payments for foreign use allowances must be provided.
proposal required.
B
13 December 2024 Page 143 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG01.26
Manual entry of the budget charge and automated calculation of the gross payment
The HR system should automatically calculate the gross pay (employee gross pay) as the maximum amount
(employer gross pay) for the total pay or individual pay components after manual entry of the budgetary
charge. The calculation must
also be fictitiously possible.
B
The requirements for basic pay in special cases according to TV-L are listed below.
Requirement labelling
Requirement
Criterion
EG01.27
Employees in social and educational services
The HR system must also automatically calculate the pay for employees in the social and educational
services in accordance with Section 52 TV-L. This includes
-
in accordance with § 52 number 2 TV-L, the table remuneration in Appendix G of the TV-L,
-
in accordance with § 52 number 3 TV-L, the step durations specified there,
-
in accordance with § 52 number 4 TV-L, the pay groups named there.
A
EG01.28
Trainee remuneration (1/2)
The HR system must take into account the fact that the monthly trainee salary is based on the
professions and amounts specified in Section 8 of the TV Prakt-L. The monthly intern remuneration
must be automatically determined, maintained and further developed after the interns have been
entered or taken on.
A
EG01.29
Trainee remuneration (2/2)
The HR system must enable the recording of individually agreed internship remuneration in accordance
with §§ 7 and 8 of the TdL Internship Directive.
A
EG01.30
Training allowance (1/4)
The HR system must be able to calculate the monthly training allowance. It is based on the respective
training year and the amounts specified in § 8 of the respective collective agreement.
A
EG01.31
Training allowance (2/4)
The HR system must automatically determine and maintain the monthly training allowance after the
entry or transfer of trainees in accordance with TVA-L BBiG or TVA-L-Forst on the basis of the saved
training year.
A
EG01.32
Training allowance (3/4)
The HR system must enable part-time training to be accounted for.
A
EG01.33
Training allowance (4/4)
The HR system must also enable manual intervention with regard to the monthly training allowance so
that extensions and reductions of training years can be implemented after notification by the HR
departments.
A
EG01.34
Tuition fees
The HR system must calculate the monthly tuition fee in accordance with the respective training areas
and the criteria set out in Section I No. 6, Section II No. 6 and Section III No. 3 of the Guideline for Dual
Study Programmes and Master's Degree Programmes or in Section 8 TVdS-
L including the amounts stated therein.
A
13 December 2024 Page 144 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
EG01.35
Flat-rate charges for car drivers (1/2)
The HR system must automatically calculate the flat-rate pay for drivers in accordance with Section 4
of the TV-L for car drivers, which is used to calculate the table pay (Section 15 TV-L) and the pay for
overtime and time bonuses for overtime (Section 8 (1) sentence 2 letter a TV-L).
It is calculated on the basis of pay group 4, the flat-rate group applicable to the driver and the level
entered or transferred (Section 16 TV- L or Section 7 TVÜ-L). The amounts of the lump-sum payment
can be found in Appendix 3 to the Car Driver TV-L.
A
EG01.36
Flat-rate charges for car drivers (2/2)
The HR system must automatically monitor the step duration in the respective flat-rate group in
accordance with Annex 3 to the Car Drivers' TV-L, taking into account creditable remaining periods,
etc., so that step increases (Annex 3 Car Drivers' TV-L) also take into account any interruption periods
(Section 17 (3) TV-L).
can be automated.
A
4.7.7.1.2 Separate employment relationships and types
In addition to ordinary employment relationships, which are dealt with in chapter 4.7.7.1.1, there are special employment
relationships. There are additional regulations for these. Special employment relationships relate in particular to trainees, trainee
lawyers and trainee teachers, trainee lawyers in a public law training relationship, academic and student assistants, and non-pay-
scale and above-pay-scale employees.
In the area of remuneration, family-related benefits are only paid for special service contracts, trainee teachers and trainee
lawyers. In this respect, the overarching requirements from section 4.7.10.3 "Overarching professional requirements: Gross
calculation - family-related benefits" apply.
Requirement
labelling
Requirement
EG02.01
Volunteers (1/3)
The HR system must automatically calculate a salary of 50% of the respective salary of pay group 13 level
1 TV-L for volunteers.
EG02.02
Volunteers (2/3)
The HR system must automatically calculate a salary of 50% of the respective salary of pay group 13 level
2 TV-L for volunteers who have completed their academic higher education from the second year of
training.
EG02.03
Volunteers (3/3)
The amount of the fee must be entered automatically after entering the "payment key".
be determinable and maintainable.
13. December 2024 Page 145 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG02.04
Legal trainees
The HR system must automatically calculate the maintenance allowance for legal trainees in a public law
training relationship in accordance with the RRefUBeihV MV. The maintenance allowance consists of
-
the basic amount in accordance with § 1 (1) No. 1 RRefUBeihV MV, whereby it must be possible to
manually enter a reduction amount (deduction of remuneration from secondary employment), and
-
the family allowance in accordance with § 1 (1) No. 2 RRefUBeihV MV, whereby the corresponding
amounts of the family allowance are to be held automatically.
A
EG02.05
Creating cover letters for special employment relationships
The HR system must be able to automatically create letters for special employment relationships (at
least a letter for regular review of family allowance, reminder).
A
EG02.06
Trainee teachers
The HR system must automatically calculate training allowances for trainee teachers in a public-law
training relationship in accordance with §§ 5b, 7 LehVDVO MV. The training allowances consist of
-
the basic amount according to § 7 (1) sentence 2 no. 1 LehVDVO MV and
-
the family allowance according to § 7 (1) sentence 2 no. 2 LehDVO MV.
A
EG02.07
Monthly and hourly salaries for academic and student assistants and other employees (1/2)
The HR system must be able to transfer monthly and hourly pay (hours and minutes) for academic and
student assistants and other employees from a future HR management process (electronic Personalakt)
(see pay data interface SS01.40).
A
EG02.08
Monthly and hourly salaries for academic and student assistants and other employees (2/2)
The HR system must manually record the monthly and hourly pay (hours and minutes) for academic and
student assistants and other employees in accordance with the TdL guideline on the working conditions
of academic and student assistants dated 23 June 2008, as amended.
A
EG02.09
Non-tariff and above-tariff employees and trainees (1/2)
The HR system must be used for non-tariff and above-tariff employees and trainees who are paid in
accordance with the agreements in their employment contracts/training contracts, e.g.
-
based on a collective labour agreement,
-
Flat-rate remuneration,
-
according to officials/judges/state secretaries
The HR system must provide a corresponding manual entry option and the resulting pay calculation for
the employees who are to be paid. The HR system must offer the option of variably selecting all
remuneration or training remuneration/salary components.
A
EG02.10
Non-tariff and above-tariff employees and trainees (2/2)
The HR system must offer the option of specifying maximum amounts for remuneration.
In addition, the clerk must be given the option of selecting a manually entered time sheet for other non-
pay-scale and above-pay-scale employees or trainees.
the fixed amount, alternatively dynamic or non-dynamic.
A
13 December 2024 Page 146 of 366
13 december 2024
4.7.7.1.3 Other cover components
In addition to the usual remuneration components, there are other remuneration components such as allowances, supplements,
bonuses, compensation, expense allowances and premiums. These must be able to be entered by the administrator as an amount
or percentage and configured by the central specialised administration.
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.4 (General functional requirements: Gross calculation - Other pay components) Application.
Requirement
labelling
Requirement
EG03.01
Statutory compensation in accordance with Section 56 of the Infection Protection Act
The HR system must automatically calculate statutory compensation in accordance with Section 56 of the
Infection Protection Act.
EG03.02
Sickness benefit subsidy
The HR system must automatically calculate the sick pay allowance in accordance with Section 22 (2) TV-L.
EG03.03
Monitoring the sick pay subsidy
The HR system must enable the automated monitoring of entitlement periods for sick pay subsidies.
EG03.04
Cessation of payments at the end of the sick pay subsidy period
Once the period of entitlement to sick pay has been determined, the HR system must automatically stop
payment at the end of the determined period.
EG03.05
hardship allowances
The HR system must also automatically calculate aggravation allowances in accordance with Section 19
TV-L in conjunction with EZulV MV for part-time employment with an uneven distribution of working
hours and for periods when employment is prohibited.
EG03.06
Maternity protection pay
The HR system must calculate remuneration in the event of a ban on employment (maternity protection
wage § 18 MuSchG) automatically.
4.7.7.1.4 Reductions/reduction in remuneration
Once all remuneration components for the personnel case have been determined in the HR system, the HR system must enable
deductions, reductions and interruptions.
Requirement
labelling
Requirement
EG04.01
Cuts (1/2)
In accordance with §§ 24 and 28 TV-L, § 56 IfSG, the HR system must be capable of automatically
calculating the reductions and reductions in remuneration components regulated by law and collective
agreements. The HR system must be able to manually record the following reduction options
-
days and hours of absence,
-
of a reduction amount,
-
of a reduction percentage,
-
a maximum limit and
-
of a fixed amount
provide.
13. December 2024 Page 147 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG04.02
Cuts (2/2)
The HR system must allow for multiple changes of all reduction criteria per month in the event of
reductions and reductions in pay components.
A
EG04.03
Reductions due to absences according to ITSG
The HR system must enable the detailed recording of absences in accordance with Annex 3 of the ITSG's
system analysis specifications. The HR system must enable the resulting reductions.
A
EG04.04
Reduction in candidate salaries
In accordance with § 5b LehVDVO MV and § 81 LBesG MV, the HR system must enable manual recording
of the reduction amount or a percentage of the remuneration in the public-law training relationship.
A
EG04.05
Interruptions in the payment of remuneration (1/4)
The HR system must allow the following interruptions in order to stop payment of remuneration:
-
generally legal interruptions,
-
tariff interruptions,
-
non-standard and above-standard interruptions,
-
Special leave,
-
Care time and
-
Parental leave.
A
EG04.06
Interruptions in the payment of remuneration (2/4)
The HR system must enable automated monthly, daily or even hourly reductions in pay in accordance
with Section 24 (3) TV-L/TV-Forst.
A
EG04.07
Interruptions in the payment of remuneration (3/4)
The HR system must label the different types of interruption in EG04.05 (Interruptions in the payment of
remuneration (1/4)) accordingly.
A
EG04.08
Interruptions in the payment of remuneration (4/4)
The HR system must automatically take into account interruptions that are equivalent to uninterrupted
employment within the meaning of § 16 Para. 3 Sentence 1 TV-L or that are not detrimental according to
§ 17 Para. 3 Sentence 2 TV-L when determining the step in accordance with the regulations of § 17 TV-L.
For individual interruptions (also beyond the turn of the year), which only add up to a total period of at
least 30 days, § 17 Para. 3 Sentence 2 TV-L applies accordingly, whereby whole months are to be
regarded as 30 days and otherwise the step duration is suspended to the day. In the case of detrimental
interruptions, an allocation is made to
one step in accordance with § 17 (3) sentence 3 TV-L.
A
4.7.7.1.5 One-off and special payments, death benefit
In addition to monthly salaries, the HR system must allow for one-off payments such as those based on a collective agreement,
severance pay, holiday pay as a termination bonus and anniversary bonus, and calculate the annual bonus.
Furthermore, surviving dependants receive a death grant in accordance with Section 23 (3) TV-L if a member of staff dies.
The overarching requirements ÜF05.01 and ÜF05.02 from chapter 4.7.10.5 (Overarching technical requirements: Gross
calculation - One-off
13. December 2024 Page 148 of 366
13 december 2024
and special payments) and the overarching requirements from section 4.7.10.6 (Overarching technical requirements: Gross
calculation - death benefit) apply.
Requirement
labelling
Requirement
Criterion
EG05.01
Anniversary bonus
The HR system must pay the anniversary bonus in accordance with TV-L § 23 Para. 2 in conjunction with
§Section 34 (3) TV-L can be determined automatically. For this purpose, it must be possible to manually
record the start of the employment period.
A
EG05.02
Severance payments - transfer from the Personnel Management specialised procedure
The HR system must offer the option of transferring severance pay from a future specialised HR
management procedure (see pay data interface SS01.40).
A
EG05.03
Severance payments - manual entry
The HR system must offer the option of recording a severance payment with its manually determined
value, e.g. based on court judgements and out-of-court settlements.
A
EG05.04
Holiday pay - termination of the employment relationship
The HR system must be capable of calculating the leave compensation due upon termination of the
employee's employment relationship.
A
EG05.05
Holiday pay in lieu - automated notification
The HR system must be able to automatically send a corresponding letter (including free text fields for
completion by the administrator) to the employee or heir informing them of the calculated amount once
the leave compensation to be paid has been automatically calculated.
A
EG05.06
Closing premium
The HR system must automatically determine the final bonus for trainees who successfully ablegen the
final examination in accordance with § 20 TVA-L BBiG/TV-A Forst. The data required for this must be able
to be entered manually and transferred from a future HR management process (see pay data interface
SS01.40).
A
EG05.07
Special annual payment (1/2)
The HR system must automatically calculate the annual special payment in accordance with the currently
valid version of the TdL implementation instructions for the annual special payment pursuant to § 20 TV-
L, including state-specific regulations, § 20 TV-Forst, § 16 TVA-Forst, § 16 TAV- L BBiG.
A
EG05.08
Special annual payment (2/2)
The HR system must take into account the offsetting of the special payment of comparable benefits paid
on the basis of regulations other than civil service law in accordance with Section 7 (5) of the Special
Payments Act MV.
A
EG05.09
Special payment for trainee teachers
When calculating the special payment for teaching assistants in accordance with Section 5b LehVDVO MV
in conjunction with the SZG MV, the HR system must take the annual special payment into account.
automatically in accordance with § 7 (5) SZG MV.
A
13 December 2024 Page 149 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG05.10
Annual special payment - several employment contracts
The HR system must offer the administrator the option of selecting several employment contracts for
the annual special payment according to factual contexts. Different employment contracts with activities
that are directly related to each other should be processed as a single employment relationship with
regard to the annual bonus payment. If there is no material connection between the agreed activities,
each employment relationship must be considered separately for the calculation of the annual bonus
payment. Periods of employment that began earlier and for which there is also an entitlement to a special
annual payment are not taken into account.
annual bonus payment must be made.
A
4.7.7.1.6 Special working time regulations
If an employee works part-time, the HR system must be able to map the scope of employment. The HR system must also be able
to do this for special forms of part-time work such as sabbaticals.
The overarching requirements for sabbaticals from section 4.7.10.7 (Overarching technical requirements: Gross calculation -
Sabbatical) also apply to the calculation of remuneration in this section.
Requirement
labelling
Requirement
EG06.01
Consideration of different scopes of employment (1/2)
The HR system must offer the option of automated consideration of part-time entries of any kind
(especially sabbaticals).
The HR system must automatically calculate the part-time pay in accordance with Section 24 (2) TV-L/TV-
Forst.
EG06.02
Consideration of different scopes of employment (2/2)
The HR system must make it possible for the different part-time models to b e labelled differently so that
the work phase or leisure time phase can be identified.
phase and analyse them for statistical purposes.
4.7.7.1.7 Further requirements
In addition to the usual calculation of gross pay in the previous chapters, this chapter contains further requirements. These
include
- the calculation of claims for damages against third parties,
- the calculation of the budgetary burden in the event of secondment/assignment or provision of personnel to another
employer outside the service provider LAF and
- the determination of the non-cash benefit.
Requirement
labelling
Requirement
Criterion
EG07.01
Calculation of claims for damages against third parties
In the event of loss of earnings due to accidents caused by third parties, the HR system must
automatically calculate the amount of the loss (loss of earnings) and report it in the form of a
The certificate requesting the funds must be issued.
A
13 December 2024 Page 150 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG07.02
Calculation of the budgetary burden in the event of secondment/assignment or secondment to another
employer (1/4)
The HR system must make it easier for the clerk to enter the data.
-
Period (e.g. secondment period),
-
Scope (e.g. partial secondment),
-
Employer outside the service provider LAF
for the secondment/assignment/staffing of an employee to another employer.
A
EG07.03
Calculation of the budgetary burden in the event of secondment/assignment or personnel assignment
to another employer (2/4)
During the secondment/assignment/staff provision of an employed person to another employer, the HR
system must automatically calculate the budget charge paid in the form of remuneration. The HR system
must automatically calculate the remuneration paid plus the employer's social security benefits,
company pension scheme and the flat-rate tax and solidarity surcharge to be borne by the employer and
issue it in the form of a certificate to request the funds from the other employer (budget charge).
A
EG07.04
Calculation of the budgetary burden in the event of secondment/assignment or transfer of staff to
another employer (3/4)
When calculating the remuneration during the secondment/assignment/staff provision of an employee
to another employer in the case of a partial secondment, the HR system must automatically calculate the
budgetary charge required for accounting purposes on a pro rata basis according to the extent of the
partial secondment.
A
EG07.05
Calculation of the budgetary burden in the event of secondment/assignment or secondment to
another employer (4/4)
For accounting purposes, the HR system must automatically calculate the necessary budgetary charge
during the secondment/assignment/staff secondment of an employee to another employer in addition
to the share of the annual special payment attributable to the corresponding secondment/assignment
period.
A
EG07.06
Monetary benefit (1/2)
The HR system must enable the increase in remuneration due to benefits in kind/cash benefits (e.g.
provision of a car (1% rule), provision of meals) by manually recording the non-cash benefit (gross).
In the calculation, this non-cash benefit must be added to the total gross remuneration, the gross tax
amount and the gross social security amount.
A
EG07.07
Monetary advantage (2/2)
The HR system must allow the non-cash benefit to be withheld from the payment amount.
The HR system must make it possible for the household to be relieved of the same amount as the gross
amount of the non-cash benefit is charged to the household.
A
EG07.08
Reimbursement amounts for the AAG
The HR system must calculate all reimbursement amounts for the AAG.
A
13 December 2024 Page 151 of 366
13 december 2024
4.7.7.2
Net calculation
The chapter Net calculation and the associated chapters describe how net pay is calculated in the HR system. The calculation is
carried out for all remuneration components on the basis of the gross remuneration subject to social insurance, tax and
supplementary pension contributions and applies to employees as well as specially described cases in accordance with the TV-L
and special employment relationships.
If necessary, parts of the remuneration are seized, assigned or offset. In addition, advances and capital-
forming benefits are granted.
4.7.7.2.1 Social security
Social security contributions must be deducted from the gross salary subject to social security contributions. The annual earnings
limit is checked in this context. The payment of contributions is also necessary for special employment and training relationships
and in the case of several legal relationships and entitlements.
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.8 (Overarching technical requirements: net calculation - social insurance) Application.
Requirement
labelling
Requirement
Criterion
EG08.01
Comparison net
The HR system must automatically determine the "comparative net pay" (= current net pay subject to
contributions prior to the social benefit event, which the employer transmits to the statutory social
security institutions in the form of a remuneration certificate for the calculation of the social benefit) for
the contribution calculation in accordance with Section 23c SGB IV. The following must be taken into
account:
-
for voluntarily insured persons: Net pay = reduction by employer's contribution to KV/PV,
-
for those with private health insurance: as for those with voluntary statutory insurance, but
reduced by a maximum of the eligible amount in accordance with § 257 Para. 2 SGB V/§ 61 Para. 2
SGB XI,
-
Determination of comparative net amount in accordance with § 23c SGB IV for privately insured
persons is not applicable if they are insured without daily sickness allowance, injury allowance or
transitional allowance,
-
for members of occupational pension schemes: Determination of comparable net pay= as with
existing pension insurance obligation,
-
For employees in the transitional area: Determination of comparative net pay without application
of the transitional area regulation,
-
No consideration of non-contributory converted current remuneration (EntgeltU/ZV-KapANA).
A
EG08.02
Allowance according to § 3 No. 26 EStG
The HR system must take into account the allowance in accordance with Section 3 No. 26 EStG in monthly
instalments and/or as a consumption model.
A
EG08.03
Calculation of gross pay subject to social insurance contributions
The HR system must offer the processing department the option of recognising all remuneration
components in the HR system with regard to their treatment in the automated calculation of social
insurance amounts with corresponding characteristics.
(classification).
A
13 December 2024 Page 152 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG08.04
Contribution groups/person group key (1/2)
The HR system must be able to differentiate between the following status groups in particular for
contribution accounting:
-
Compulsory insurance,
-
Voluntary health insurance,
-
Employees with private health insurance,
-
Trainees,
-
Old-age pensioners,
-
Minijob and midijob employees,
-
Staff cases in occupational pension schemes (self and company payers, labelling),
-
Co-insurance cases,
-
Federal Volunteer Service and FSJ/FÖJ,
-
Students, interns and school pupils.
It must be possible to select several status groups per personnel case (multiple employment).
A
EG08.05
Contribution groups/person group key (2/2)
The HR system must be capable of taking into account the possibility of multiple employment for all
groups of persons from EG08.04 for the calculation of contributions.
A
EG08.06
Manual entry of person/contribution groups
The HR system must offer the option of manually specifying the person/contribution groups by the
administrator due to the required manual assessment by the administrator.
A
EG08.07
Employees with private health insurance and private long-term care insurance (1/6)
The HR system must automatically calculate the contribution to private health insurance (Section 257
SGB V) and long-term care insurance (Section 61 SGB XI) for employees with private health insurance.
A
EG08.08
Employees with private health insurance and private long-term care insurance (2/6)
For employees with private health insurance, the HR system should send a letter to the employee at the
end of the year and, if necessary, a reminder (e.g. after 2 months) to submit the certificate (Section 257
(2a) of the German Health Insurance Act).
S. 2 SGB V requirement for proof of health insurance contributions paid, § 61 Para. 6 SGB XI long-term
care insurance contributions).
B
EG08.09
Employees with private health insurance and private long-term care insurance (3/6)
The HR system must make it possible for employees with private health insurance to monitor the receipt
of the certificate (e.g. ticking of a checkbox by the administrator if the certificate has (already) been
received).
A
EG08.10
Employees with private health insurance and private long-term care insurance (4/6)
For employees with private health insurance, the HR system must enable the recording of the daily
sickness allowance entitlement (KTG) due to the verification of the continued existence of the insurance
relationship in accordance with Section 7 (3) SGB IV in the event of illness and the resulting different
DEÜV notifications (with KTG entitlement, interruption notification without KTG entitlement by month).
This is used for
the contribution calculation according to § 23c SGB IV.
A
13 December 2024 Page 153 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG08.11
Employees with private health insurance and private long-term care insurance (5/6)
For employees with private health insurance, the HR system must ensure that the SI gross amount of the
other insurance branches is multiplied by the contribution rates of the individual insurance branches
(contribution calculation) and paid.
A
EG08.12
Employees with private health insurance and private long-term care insurance (6/6)
For employees with private health insurance, the HR system must ensure that employer contributions
are automatically documented on the electronic wage tax statement and shown as follows:
-
AG subsidy Professional pension scheme,
-
AG subsidy for voluntary health insurance,
-
AG subsidy for private health insurance,
-
AG subsidy for long-term care insurance.
A
EG08.13
Voluntary health/nursing care insurance (1/2)
The HR system must automatically calculate the subsidy for voluntary health insurance (§ 257 SGB
V)/nursing care insurance (§ 61 SGB XI).
A
EG08.14
Voluntary health/nursing care insurance (2/2)
The HR system must pay the total contributions (employee and employer) relating to the social
insurance branches of pension and unemployment insurance, including the contributions for maternity
protection expenses, continued remuneration (U1) and the insolvency benefit contribution to the health
insurance fund.
A
EG08.15
Voluntary health/nursing care insurance - payment
The HR system must enable the payment of the subsidy for voluntary health/nursing care insurance to
the employee himself (self-payer) and to the voluntary health/nursing care insurance (company payer).
A
EG08.16
Federal Volunteer Service (Bufdi) and FSJ/FÖJ
The HR system must calculate the total social security contribution for Bufdi/FSJ/FÖJ and pay the total
social security contribution.
The HR system must bear in mind that if a compulsory insurance relationship existed immediately before
the start of the Federal Voluntary Service or FSJ/FÖJ, the assessment basis for unemployment insurance
is the monthly reference value, otherwise the actual remuneration.
The HR system must note that the regulations for marginal employees and the regulations for employees
in transitional employment do not apply to this group of persons.
A
EG08.17
Entry of further social security data
The HR system must enable the manual entry of additional social insurance data (e.g. duration of
employment, days, remuneration) for the social insurance assessment of students, interns, school pupils
and low-paid employees in accordance with pension insurance requirements, including exemption from
the pension insurance obligation.
tions. It must be possible to change the entries.
A
13 December 2024 Page 154 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG08.18
Students
The HR system must enable the processing department to record the manual assessment for students
under contribution law. This includes, in particular, whether the person employed is a student.
-
Short-term/low-income students in employment (plausibility check: limit of availability,
notification to the administrative department if exceeded),
-
Working students (plausibility check 20 hours/week, if exceeded, notification to administrative
department) or
-
Students in dual study programmes according to TVdS-L.
A
EG08.19
Interns and trainees
The HR system must make it possible to specify person/contribution group keys in accordance with the
differentiation made in advance with regard to the type of intern in accordance with TV-Prakt-L, the TdL
internship guideline and the state-specific regulations (e.g. Annex 7 to the 1st Management Decree
2021).
A
EG08.20
Pupils and students
The HR system must enable the manual assessment of students' contributions to be recorded by the
administration department.
A
EG08.21
Low-paid employees/mini-jobbers
The HR system must enable the manual assessment of whether an employee is in short-term or
marginally paid employment, including the manual specification of the corresponding person and
contribution group key (e.g. compulsory pension insurance or exemption from this).
A
EG08.22
Employees with wages subject to social security contributions in the transitional sector/mi-jobbers
The HR system must automatically check whether remuneration exists in the transitional area (Section 20
(2) SGB IV), taking into account the current version of the circular from the GKV umbrella organisation on
the treatment of employment relationships in the transitional area.
The HR system must inform the administrator accordingly if there is an over/underpayment of
remuneration in the transitional area.
A
EG08.23
Multiple employment
The HR system must enable the accounting of multiple employment in all areas (marginal employment,
transitional area, regular insurance obligation, BBG excess) in the case of multiple employment.
The HR system must enable the following processing sequence for multiple employment cases:
-
Automated acceptance of the health insurance notification data record (see SS01.04 and SS01.05),
manual checking by the clerk (e.g. using a checklist) including entry and correction (e.g. missing
feedback of KV/PV total remuneration),
-
the processing of information from health insurance funds for the pro rata calculation of total
social security contributions in the case of multiple employment (in accordance with the ITSG basic
module),
-
determining the contributions to the individual branches of social insurance and the levy based on
the total amount reported by the health insurance fund
remuneration.
A
13 December 2024 Page 155 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
EG08.24
Annual earnings limit check - automated check
The HR system must perform both the intra-year and annual review of the annual earnings limit in
accordance with Section 6 (6) and (7) SGB V
-
for new hires,
-
monthly to check whether the obligation to take out health insurance applies (e.g. due to
downgrading, change in working hours, deferred compensation)
-
at the turn of the year
automatically. The HR system must display the check result once the processing has been checked.
A
EG08.25
Annual earnings limit check - calculation protocol
The HR system should automatically create a calculation log as a document for each check of the annual
salary limit and file it with the process.
B
EG08.26
Annual income threshold check - automated letter
The HR system must automatically generate a letter (including a declaration form to the employee with
file copy) if it detects that the annual pay limit has been exceeded or not reached and any resulting
changes.
A
EG08.27
Treatment under insurance law (co-insurance)
The HR system should treat several employment relationships or several employment contracts as a
single employment relationship with regard to social security treatment. In doing so, it must
-
automatically summarise the remuneration subject to social insurance contributions,
-
determine the contributions to the individual social security branches on the basis of the total
remuneration with the same employer and
-
enable the reimbursement of only one DEUEV notification.
A
4.7.7.2.2 Tax deductions
Income tax, church tax and solidarity surcharge must be deducted from the gross taxable salary. This also applies to special
employment and training relationships and in the case of multiple legal relationships and entitlements. When determining the
gross taxable income, the HR system must take into account the tax-free income.
The HR system must also carry out the annual wage tax equalisation.
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.9 (Overarching technical requirements: net calculation - tax deductions) Application.
4.7.7.2.3 Contributions to the supplementary pension scheme
Supplementary pension contributions must be paid to the Versorgungsanstalt des Bundes und der Länder (VBL) from the gross
remuneration subject to supplementary pension contributions. The VBL's eastern payroll group is applied. As an exception,
employees are settled according to the West tariff. Contributions are calculated in accordance with § 25 TV-L, the VBL statutes,
the ATV and §§ 10a, 79-99 EStG. This also applies to special employment and training relationships and in the case of multiple
legal relationships and entitlements. In this context, it must be possible to monitor allowances and voluntary insurance and
deferred compensation must be possible.
13. December 2024 Page 156 of 366
13 december 2024
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.10 (General technical requirements: Net calculation - contributions to supplementary pension scheme) Application.
4.7.7.2.4 Withholdings and deductions
As part of the net calculation, it should be possible to withhold parts of the fee.
Requirement
labelling
Requirement
Criterion
EG09.01
Other deductions
The HR system should enable the withholding of other pay deductions (e.g. for subsistence allowance,
job ticket, car park management, telephone charges) with a freely selectable term. The other pay
deductions must be configurable by the central specialised administration and be available for selection
by the administrator.
be shown.
B
4.7.7.2.5 Advances and employer loans
In addition to remuneration, the HR system must allow advances. It must also enable employer loans. Subsequent repayments
should be processed via the HR system.
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.12 (Overarching technical requirements: Net calculation - Advances) Application.
Requirement
labelling
Requirement
Criterion
EG10.01
Granting of employer loans (1/2)
The HR system must enable the processing of employer loans for employees covered by collective
agreements.
A
EG10.02
Granting of employer loans (2/2)
The HR system must facilitate the settlement of employer loans in one lump sum and
in instalments.
A
4.7.7.2.6 Capital-forming benefits
In addition to the salary, capital-forming benefits must be made payable. The calculation of capital-forming benefits must take
into account part-time employment and interruptions. Furthermore, it must be possible to transfer to several forms of
investment.
For the calculation of fees in this chapter, the overarching requirements from chapter
4.7.10.13 (General technical requirements: Net calculation - Capital-forming benefits) Application.
13 December 2024 Page 157 from 366
13 december 2024
Requirement
labelling
Request for remuneration calculation
Criterion
EG11.01
Part-time employment and interruption
When making payments of capital-forming benefits, the HR system must determine the amount for part-
time employment and interruptions as well as the admissibility according to
§ 23 Para. 1 TV-L/TV-Forst/§15 TVA-L BBiG/§15 TVA-Forst in conjunction with the 5th VermBG.
A
EG11.02
Limitation to EUR 40
The HR system must also limit the contribution transfer to a total of EUR 40 for several capital-forming
investments.
A
EG11.03
Notification to processing department if limit amount has been exceeded
The HR system must inform the clerk if, for example, the amount to be entered would exceed EUR 40.
A
EG11.04
Capital-forming benefits when receiving a sick pay subsidy
While receiving a sick pay supplement, the HR system must pay at least the amount stipulated in the
collective agreement in accordance with Section 23 (1) TV-L (in the case of full-time employment in the
amount of 6.65 euros, otherwise pro rata according to the amount of part-time work or the daily
entitlement), but no more than the available differential amount determined after deduction of the
employee contribution to the VBL, up to a maximum of 40 euros to the capital-forming investment. If the
sick pay supplement is not used to pay the employee's contribution to the VBL and the maximum amount
to the capital-forming investment, the employer is entitled to transfer the maximum amount to the capital-
forming investment.
If the information is not sufficient, this must be pointed out to the processing department.
A
4.7.8
Salary requirements
Remuneration is only specified by the employment relationship in the public sector. Persons in the civil service or judgeship of the
state of Mecklenburg-Vorpommern are entitled to remuneration from their employment. Requirements relating to civil servants
or the employment relationship also refer to persons in an official relationship in accordance with the MV State Ministers Act. The
basis is formed in particular by the Civil Servants Status Act, the State Civil Servants Act, the State Salaries Act and the State
Ministers Act.
4.7.8.1
Gross calculation
In the gross calculation, the remuneration is determined before deduction of taxes.
The gross calculation must also take into account other salary components, one-off and special payments, family-related benefits
as well as reductions in salary and special working time regulations.
4.7.8.1.1 General calculation of salary
The HR system maps the various types of remuneration in accordance with Section 2 LBesG MV. This centrally includes the basic
salary. In order to determine this, the necessary data must be recorded. It is determined on the basis of the salary group or office
and, if necessary, according to seniority and is "read off" using the tables in the salary regulations.
13. December 2024 Page 158 of 366
13 december 2024
The overarching requirements from section 4.7.10.1 (Overarching professional requirements: Gross calculation - Pay calculation
in general) apply.
Requirement
labelling
Requirement
Criterion
BE01.01
Recording the data required for payroll accounting
The HR system must enable the manual recording of all data required for payroll accounting.
A
BE01.02
Daily calculation of salary
The HR system must automatically calculate the salary taking into account the start of the salary
entitlement in accordance with § 4 Para. 1 LBesG MV and § 49 Para. 2 LHO and the end of the salary
entitlement in accordance with § 4 Para. 2 LBesG MV to the exact day in compliance with § 4 Para. 3
LBesG MV.
A
BE01.03
Change of grade and step
The HR system must also enable the monthly change of grade and level within the payroll period.
A
BE01.04
Note on the consequences of grade and step changes
The HR system should inform the administrator if a change of pay grade or level leads to an automatic
adjustment of other pay components. The notification must be accepted or rejected by the
administrator.
For example, the structural allowance is cancelled for a promotion from A13 to A14.
B
BE01.05
Rounding rules
The HR system must automatically apply the rounding rules in accordance with Section 4 (6) LBesG MV
when calculating salaries.
A
BE01.06
Retroactive changes
It must be possible to calculate remuneration retroactively in the HR system. The changes apply
according to the retroactive calculation depth (see requirement WF01.34 and WF01.35).
A
BE01.07
Determination of the basic salary
In accordance with Section 23 LBesG MV, the HR system must use the recorded grade or office and
automatically determine the basic salary based on this and, if necessary, on seniority.
A
BE01.08
Salary regulations
The HR system must map all salary scales and the entry-level grades of the LBesG MV. These currently
include
-
Salary scale A with ascending salaries (§§ 25, 27, 28 LBesG MV),
-
Salary scale B with fixed salaries (Section 25 (2) LBesG MV),
-
salary scale C with ascending salaries (Section 88 (5) LBesG MV),
-
the salary scale R (§ 39 LBesG MV) with the ascending salaries for R1 and R2 and with the fixed
salaries from R3,
-
Salary scale W with fixed salaries (§ 32 LBesG MV).
A
13 December 2024 Page 159 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE01.09
Consideration of different input levels
When determining the basic salary, the HR system must take into account the fact that, according to
Annexes 5 and 8 to the LBesG MV, the various salary groups have different levels as entry levels.
A
BE01.10
Utilisation of the original basic salary in the event of a reduction in the basic salary
According to § 24 LBesG MV, the HR system must allow the original basic salary, the original official
allowance (if any) and the original structural allowance (if any) to continue to be used in the event of a
reduction in the basic salary, including the effects on official allowances and structural allowances.
A
BE01.11
Calculation of length of service - general
The HR system must enable the manual evaluation of CV data by the clerical department by means of
appropriate fields and the resulting automated calculation of the length of service, in particular in
accordance with Sections 29, 30, 31, 40, 93 LBesG MV.
A
BE01.12
Calculation of length of service - consideration/non-consideration of periods
In particular, the HR system must offer the options "take into account" and "do not take into account"
for the evaluation of times. In addition, it must be possible to include a proportionate amount (fraction
and percentage with 2 decimal places).
A
BE01.13
Calculation of experience seniority - logging of manual additions and changes
The HR system must log the manual additions and changes to the evaluation of periods of seniority in
terms of processing. The person who made the change must also be logged.
A
BE01.14
Calculation of length of service - text modules and free text fields
When assessing CV data, the HR system must enable the administrator to add text modules and other
comments in corresponding free text fields without a character limit for document creation for each
period to be assessed. The free text fields must be able to be written in parallel to the evaluation of the
respective CV data, i.e. not only after the evaluation of the CV data as a whole has been completed.
A
BE01.15
Calculation of the length of service based on experience - Notification
The HR system must be able to automatically generate notifications on the length of service including
the recorded previous periods of service as an attachment to the notification in accordance with § 29
Para. 6 and 40 Sentence 2 LBesG MV by triggering the processing.
A
BE01.16
Recalculation of the step increase in seniority based on experience
The HR system must enable the administrator to make changes (including retrospective changes) to the
assessment of periods of leave, in particular by deferring (full and half) in accordance with § 29 Para. 4
and 40 Sentence 3 LBesG MV. Based on this, the HR system must automatically recalculate the further
advancement in the experience levels.
A
BE01.17
Change in the length of service
The HR system must enable the manual change of experience seniority.
chen.
A
13 December 2024 Page 160 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE01.18
Consideration of years of experience in the basic salary
The HR system must automatically take into account the calculated length of service and the newly
calculated length of service due to changes when determining the basic salary.
A
BE01.19
Automated step advancement of experience seniority
The HR system must enable the automatic calculation of step advancement in accordance with §§ 29
Para. 3 and 40 Sentence 2 LBesG MV for salary groups with ascending salaries.
A
BE01.20
Automated step inhibition of seniority based on experience
In the case of salary groups with ascending salaries, the HR system must allow for promotion, e.g. in the
case of special leave without official interest in accordance with §§ 29 Para. 4
and 40 sentence 3 LBesG automatically.
A
4.7.8.1.2 Special working time regulations
If a staff member does not work full-time, their salary is reduced proportionately. Various part-time types must be implemented
in the HR system. If information is to be provided, a fictitious calculation taking into account part-time types is necessary.
The overarching requirements for sabbaticals from section 4.7.10.7 (Overarching professional requirements: Gross calculation -
Sabbatical) also apply to the salary calculation in this section.
Requirement
labelling
Requirement
Criterion
BE02.01
Consideration of part-time types
The HR system must automatically take all types of part-time work into account when calculating
remuneration.
A
BE02.02
Consideration of multiple/different types of part-time work
The HR system must be able to automatically process multiple and different part-time types of a
personnel case (e.g. several employment relationships) in parallel.
A
BE02.03
Labelling of part-time types for reports/evaluations
The HR system must identify the different part-time types for reports/analyses.
A
BE02.04
Calculation of salary for part-time employment
In the case of part-time employment, the HR system must reduce the salary in accordance with § 6
LBesG MV, taking into account special standards (e.g. § 42 LBesG MV family allowance) in line with the
scope of employment.
A
BE02.05
Calculation of salary in the event of limited fitness for duty
The HR system must ensure that salaries are paid in the event of limited
in accordance with § 7 sentence 1 LBesG MV on the basis of a part-time scope in accordance with § 6
LBesG MV and in accordance with § 7 sentences 2 and 3 LBesG MV with the addition of the supplement.
A
BE02.06
Part-time employment during a limited period of fitness for duty
According to Section 7 sentence 4 of the LBesG MV, the HR system must ensure that salaries are paid for
limited service.
The company's ability to adapt if the scope of employment changes.
A
13. December 2024 Page 161 of 366
13 december 2024
BE02.07
Fictitious calculation for part-time employment
The HR system must enable the processing department to make a fictitious calculation of remuneration
taking part-time types into account, e.g. for information purposes.
BE02.08
Statistics on part-time/working time models
The HR system must provide the labelling of the different part-time/part-time working models for
statistical purposes.
4.7.8.1.3 Benefits
Professors receive their salary according to the so-called W salary scale. Performance-related pay is added to the basic salary. The
HR system must take these variable salaries into account in accordance with §§ 2, 33-37 LBesG MV in conjunction with the
HsLeistbVO MV (C salary) and characterise their scope of application, e.g. with regard to a salary adjustment or pension eligibility.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.2 (General technical requirements: gross calculation - benefits) Application.
4.7.8.1.4 Family-related benefits
If, for example, employees are married and/or entitled to child benefit, they receive the family allowance. This is divided into
several stages. The HR system must be able to automatically calculate the family allowance and map competitive regulations.
Comparative analyses must be created. The personnel cases must submit a declaration on the family allowance after the expiry of
adjustable review times so that the processing department can check the entitlement to the family allowance and the data up-to-
dateness. The necessary data on child benefit is provided via the call-up procedure with the family benefits office.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.3 (Overarching technical requirements: Gross calculation - family-related benefits) Application.
4.7.8.1.5 Other cover components
Other pay components are entered via the department in the HR system (direct departmental access) or are transferred from the
electronic personnel administration system. These include bonuses, allowances, supplements and remuneration. Among other
things, the linear increase, tax liability and garnishability must be taken into account, the amounts and periods of which must be
adjusted and checked for plausibility.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.4 (General technical requirements: Gross calculation - Other pay components) Application.
Requirement
labelling
Requirement
BE03.01
Individual amount
The HR system must allow the entry of individualised data for other pay components.
The programme can also be used to provide financial assistance for small amounts (e.g. subsidy for
acquisition costs).
13 December 2024 Page 162 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE03.02
Pensionability
When calculating pension benefits, the HR system must automatically take into account other
pensionable salary components that have been granted for a specified period. These further pensionable
salary components are listed in Appendix 3.3 Further salary components as at 1 November 2022 ().
A
BE03.03
Dark processing of other covering components
The HR system should automatically check whether payment of additional remuneration components
can be granted in certain case constellations in an automated manner (in particular without prior,
separate entry of data). The HR system should use the existing workflow data for the check. If the
prerequisites are met, the further payment should be granted automatically (in particular without
separate approval) with the remuneration. The requirements for the case constellations should be
configurable by the central specialised administration. For example, the specialised procedure for police
officers should automatically grant an allowance in accordance with Section 48 (1) in conjunction with
Annex 12 LBesG MV if the requirements are met.
-
Police enforcement service,
-
Remuneration in accordance with salary scale A or trainee remuneration,
-
Service period of one year,
-
No security allowance according to § 47 LBesG MV,
cumulative.
B
BE03.04
Compensation for overtime (1/3)
The HR system must automatically calculate overtime pay for part-time employees until the regular
working hours are reached.
A
BE03.05
Compensation for overtime (2/3)
The HR system must take into account the automated consideration of the hourly rates depending on
the pay grade and activity that determine the amount of overtime pay for the remuneration of overtime
hours in addition to full-time hours.
A
BE03.06
Compensation for overtime (3/3)
When remunerating overtime hours, the HR system must take into account the automated check of the
maximum hours to be remunerated in the calendar year, taking into account the activity (e.g. police
service, school service).
A
BE03.07
Contribution to health and long-term care insurance (1/3)
The HR system must enable the manual entry of the individual health and long-term care insurance
amount and a reduction amount for the calculation of the health and long-term care insurance
allowance.
A
BE03.08
Contribution to health and long-term care insurance (2/3)
The HR system must enable the automated calculation of the subsidy for health and long-term care
insurance in accordance with Section 6 (6) SGB V and Section 7 EltZLVO MV.
A
BE03.09
Contribution to health and long-term care insurance (3/3)
The HR system must be able to automatically determine the allowance for health and long-term care
insurance in accordance with Section 7 of the MV Parental Leave Ordinance in conjunction with Section 6
of the MV Parental Leave Ordinance.
paragraph 6 SGB V. It must also be possible to enter the amounts manually.
A
13 December 2024 Page 163 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE03.10
Allowance for maternity benefit
The HR system must enable the automated calculation of the maternity allowance in accordance with
Section 6 of the Maternity Protection Ordinance MV.
A
BE03.11
Job bonuses
The HR system must automatically calculate differences, offsets and reductions (deductions) for job
allowances in accordance with Sections 46-60 LBesG MV.
A
BE03.12
Compensatory allowance in the event of discontinuation of job allowances
The HR system must automatically calculate the equalisation allowance in the event of the
discontinuation of job allowances in accordance with Section 61 (1) LBesG MV, including the annual
reduction (reduction) and the offsetting of other job allowances.
A
BE03.13
Equalisation allowance for change of employer
The HR system must automatically calculate the equalisation allowance in the event of a change of
employer in accordance with § 62 Para. 1 LBesG MV as the difference to the salary to be recorded in the
previous employment, including half and full reduction due to salary increases.
A
BE03.14
hardship allowances
The HR system must automatically calculate hardship allowances in accordance with Section 63 LBesG
MV in conjunction with EZulV MV, even in the case of part-time employment with an uneven distribution
of working hours and for periods of employment prohibition.
A
BE03.15
Visualisation of individual calculation steps
When calculating additional pay components, the HR system must be able to recognise the individual
calculation steps, e.g. in the case of differences, decreases or reductions.
represent the offsetting of an allowance.
A
4.7.8.1.6 Salary abroad
If staff are employed abroad, they receive remuneration abroad in accordance with the provisions of Sections 2 and 75 LBesG MV
in conjunction with Sections 52-57 BBesG. The HR system must implement the foreign salary in accordance with these
regulations.
Requirement
labelling
Requirement
Criterion
BE04.01
Illustration of salaries abroad
The HR system must map foreign salaries for personnel in foreign offices of the state in accordance with
the provisions of Sections 2 and 75 LBesG MV in conjunction with Sections 52-57 BBesG.
A
BE04.02
Determination of salary abroad
The HR system must enable the automated calculation of foreign salaries, in particular foreign
allowances, rent supplements and purchasing power equalisation, taking into account one of the
relevant indices (to be stored by the employee) and the zone key. Data to be recorded (e.g. rent amount)
must query the HR system during processing.
A
4.7.8.1.7 Candidate salaries
The HR system must make it possible to determine candidates' salaries. Candidates refers to persons in a revocable civil servant
relationship in the preparatory service.
13. December 2024 Page 164 of 366
13 december 2024
Candidate salaries include the basic candidate salary and the special candidate supplement. It must also be possible to grant a
teaching allowance. Under certain conditions, remuneration is offset against the candidate's remuneration and the candidate's
remuneration is reduced under certain conditions (see BE08.13 (Reduction of candidate's remuneration)).
Requirement
labelling
Requirement
Criterion
BE05.01
Determining the remuneration of candidates
The HR system must be able to automatically determine candidate salaries in accordance with §§ 2, 76-81
LBesG MV.
A
BE05.02
Recording a minimum period of service after the preparatory service
The HR system must enable the manual recording of a minimum period of service in accordance with
Section 76 (5) LBesG MV.
A
BE05.03
Termination of employment before the end of the minimum period of service
The HR system must inform the administrator when an employment relationship is terminated if the
minimum period of service pursuant to Section 76 (5) LBesG MV has not been fulfilled.
A
BE05.04
Recognition and consideration of special supplements for employees
The HR system must enable the recording and consideration of special supplements for candidates in
accordance with § 78 LBesG MV.
A
BE05.05
Method of recognising special supplements for candidates
The HR system must allow the entry of special supplements for candidates as an amount and as a
percentage of the candidate's basic salary.
A
BE05.06
Note for special candidate surcharge
The HR system must inform the administrator when special supplements for candidates are entered if
the special supplement for candidates exceeds the basic amount for candidates by 70 per cent.
A
BE05.07
Limitation for special supplement for candidates
The HR system must limit the entry of candidate bonuses to 100 per cent of the candidate's basic amount.
A
BE05.08
Calculation of the tuition fee
The HR system must enable the calculation of the teaching allowance in accordance with § 79 LBesG MV.
A
BE05.09
Maximum limit for tuition fees
The HR system must observe the maximum limit on the starting basic salary when determining the
teaching allowance.
A
BE05.10
Offsetting of remuneration
The HR system must take into account the offsetting of remuneration in accordance with Section 80
LBesG MV when calculating the candidate's remuneration. The differing offsetting regulations must be
observed. In the case of para. 2 (station pay), the HR system should enable the creation of a recovery
letter to the respective body outside the public service, together with fictitious pension insurance
amounts.
chen .
A
13 December 2024 Page 165 of 366
13 december 2024
4.7.8.1.8 One-off and special payments
One-off and special payments are calculated on an event-driven basis. These include, in particular, anniversary bonuses and
special payments in accordance with the SZG MV. The HR system must also automatically calculate holiday pay in accordance
with the EUrlV (federal government). In doing so, the HR system should comply with legal precedent.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.5 (General technical requirements: Gross calculation - one-off and special payments) Application.
Requirement
labelling
Requirement
Criterion
BE06.01
Amount of one-off payments
The HR system must make it possible to automatically determine one-off payments for specific groups of
people. The amount must be determined by the administrator.
A
BE06.02
Statutory one-off payments
The HR system must automatically take into account the statutory one-off payments.
A
BE06.03
Determination of long-service awards
The HR system must automatically determine and implement the long-service bonus in accordance with
Section 2 DJubV.
A
BE06.04
Payment due to (extra)judicial payments and settlements
The HR system must be able to record a severance payment with its manually determined value by the
processor (e.g. based on court judgements and out-of-court settlements) or transfer it from a future HR
management process (see remuneration data interface SS01.40).
A
BE06.05
Calculation of holiday pay in lieu according to the judgement of the Federal Administrative Court
In accordance with Section 10 EUrlV, the HR system should calculate the financial compensation for
leave not taken due to illness until the end of the civil servant's employment. The result must be
included in the payroll.
B
BE06.06
Holiday pay - plausibility check
The HR system should check the plausibility of recorded leave days with regard to the maximum number
of days.
limit of the minimum annual leave under EU law.
B
4.7.8.1.9 Official salaries
The members of the state government under the LMinG and the parliamentary state secretaries under the LParlG have a special
official relationship under public law. The HR system must determine the official remuneration of these personnel cases. This
includes the official salary or the salary, the family allowance and the allowance for official expenses. They also receive the special
payment.
Requirement
labelling
Requirement
BE07.01
Official salaries - general
The HR system must enable official salaries for persons in an official position in accordance with Section
1 LMinG and Section 1 LParlG.
13. December 2024 Page 166 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE07.02
Reference period for remuneration
When entering the exact start and end date of the term of office (including continuation of business),
the HR system must automatically determine the reference period of the official remuneration from the
start or end of the calendar month in accordance with Section 9 (1) and (2) LMinG and Section 5 LParlG.
A
BE07.03
Determination of the official salary
The HR system must determine the official salary in accordance with § 9 Para. 3 No. 1 LMinG in an
automated manner, taking into account the Official Salary and Non-adjustment of Salaries Act (NAnpG
MV).
A
BE07.04
Determination of the salary
The HR system must automatically determine the salary in accordance with Section 4 sentence 1 LParlG,
taking into account the Official Salaries and Non-Adjustment of Salaries Act (NAnpG MV).
A
BE07.05
Determination of the family allowance
The HR system must automatically determine the family allowance in accordance with § 9 Para. 3 No. 2
LMinG and § 4 LParlG.
A
BE07.06
Determination of the allowance
The HR system must automatically determine the service expense allowance in accordance with Section 9
(3) No. 3 LMinG.
A
BE07.07
Comparative calculation for multiple payments
The HR system must perform the comparative calculation in accordance with Section 9 (4) sentences 2
and 3 LMinG
and § 5 LParlG automatically.
A
4.7.8.1.10 Reductions/reduction in remuneration
The HR system must automatically make reductions and deductions from remuneration components. The necessary recording of
reduction percentages, maximum limits and fixed amounts must be possible. Where necessary, it must be possible to suspend
reduction periods.
Requirement
labelling
Requirement
Criterion
BE08.01
Periods without remuneration
The HR system must automatically adjust remuneration for periods without pay in accordance with
Sections 66, 67, 68 EUrlV, SUrlV (e.g. special leave in the event of a child's illness beyond periods with a
salary entitlement).
A
BE08.02
Reductions and reductions in accordance with the LBesG MV
The HR system must automatically implement the reductions and reductions in salary components in
accordance with §§ 11-13, 80, 81 LBesG MV.
A
BE08.03
General reductions
The HR system must provide for the following salary reduction options:
-
Manual entry of a reduction percentage,
-
manual recording of a maximum limit and
-
Manual entry of a fixed amount.
A
BE08.04
Change of reduction characteristics
The HR system must be able to handle multiple changes of all reduction characteristics in the
month.
A
13. December 2024 Page 167 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE08.05
Reduction in salary and remuneration due to the granting of a pension by an intergovernmental or
supranational organisation - general
The HR system must enable the manual recording of a reduction percentage and automated reduction of
salary and official remuneration by this rate in accordance with Section 10 LBesG MV when a pension is
received from employment in the public service of an intergovernmental or supranational organisation.
A
BE08.06
Reduction of salary and emoluments due to the granting of a pension by an intergovernmental or
supranational organisation - Monitoring of maximum reduction limits
The HR system must enable simultaneous monitoring of the maximum reduction limits when receiving a
pension from employment in the public service of an intergovernmental or supranational organisation
and reductions in accordance with Section 10 LBesG MV.
A
BE08.07
Offsetting of income and benefits in kind
In accordance with §§ 11 and 12 LBesG MV, the HR system must enable the manual recording of
income/income in kind and the calculation of the imputation/reduction amount. The HR system must
enable the recording of a minimum payment amount.
A
BE08.08
Labelling the reasons for interruption
The HR system must make it possible to identify the various reasons for interruptions. These are, in
particular, interruptions due to special leave, care leave, parental leave and unexcused absences (Section
13 LBesG MV).
A
BE08.09
Reduction in remuneration due to disciplinary measures
The HR system must take into account reductions in remuneration due to disciplinary measures in
accordance with § 10 and § 11 para. 5 LDG MV
-
as a fractional and percentage reduction in monthly remuneration and
-
automatically by specifying a time
period.
A
BE08.10
Inhibition of reductions
The HR system must enable reduction periods to be suspended, e.g. in accordance with Section 10 (4)
LDG MV.
A
BE08.11
Continuation of the reduction in salary due to disciplinary measures upon retirement
The HR system must enable the continuation of the reduction in remuneration in accordance with
Section 10 (3) LDG MV upon retirement.
A
BE08.12
Monitoring the maximum reduction limit and the reduction period of a disciplinary measure
When recording a disciplinary measure in accordance with BE08.09, the HR system should inform the
case handler that the statutory maximum reduction limit and the maximum reduction period have been
exceeded.
B
BE08.13
Reduction in candidate salaries
The HR system must calculate the reduction of candidates' salaries in accordance with Section 81 LBesG
MV after recording the amount of the reduction and a percentage of the candidates' salaries.
possible.
A
13 December 2024 Page 168 of 366
13 december 2024
4.7.8.1.11 Supply surcharge
In the case of a leave of absence without pay in accordance with Section 6 (1) sentence 2 no. 5 letter b LBeamtVG MV, it is
possible that the state of MV will be reimbursed a pension supplement. In addition, a pension supplement is levied in the event of
a secondment from the state of Mecklenburg-Vorpommern to another employer without the intention of a transfer. If, contrary
to expectations, a transfer takes place, the pension supplement would have to be refunded, as the pension burden is shared in
the event of a transfer. In addition, in the case of a secondment from the state of Mecklenburg-Vorpommern to another
employer with the intention of transfer, no pension supplement is initially levied. If, contrary to expectations, the employee is not
actually transferred, the pension supplement is levied retrospectively.
In these three constellations, the pension supplement is calculated as a gross amount in accordance with Section 6 (1) sentence 2
no. 5 letter b LBeamtVG MV. The pensionable salary is calculated in accordance with Section 5 LBeamtVG MV and the pro rata
special payment is calculated in accordance with SZG MV.
The procedure is described in the implementation regulations (https://www.landesrecht- mv.de/bsmv/document/VVMV-
VVMV000010706).
Requirement
labelling
Requirement
Criterion
BE09.01
Automated data collection (1/3)
The HR system must automatically determine the data required to calculate the pension supplement, in
particular the pensionable pay in accordance with Section 5 LBeamtVG MV including benefits and the
pro rata annual special payment in accordance with the SZG MV, which would be due in each case
without this leave of absence.
A
BE09.02
Automated data collection (2/3)
The HR system must take into account that the pension supplement is calculated on a pro rata basis in
the case of part-time employment and partial secondment. The basis for calculation is the full
remuneration in the event that reduced remuneration was received prior to the leave of
absence/secondment.
A
BE09.03
Automated data collection (3/3)
The HR system must take into account that remuneration that only becomes pensionable after a certain
reference period is to be taken as a basis for calculating the pension supplement even if the reference
period required for pensionability has not yet been fulfilled.
A
BE09.04
Data collection - selection of the personnel case
The HR system must make it possible to select the personnel case as the person liable for reimbursement.
A
BE09.05
Data collection - collection of the employer/principal
The HR system must make it possible to record the necessary data of the employer/service provider, the
department and the responsible salary office as the party liable for reimbursement. It must be possible
to record the reason for the reclaim, a deadline and, if necessary, several budget titles.
A
BE09.06
Data collection - Payment method
The HR system must record the payment methods on a monthly, quarterly basis,
semi-annually and annually.
A
13. December 2024 Page 169 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE09.07
Automated calculation
The HR system must enable the automated calculation of the pension supplement in accordance with
Section 6 (1) sentence 2 no. 5 letter b LBeamtVG MV and the monthly, quarterly, semi-annual and
annual deductions, taking into account any time limit recorded for each budget title.
A
BE09.08
Automated recalculation
The HR system must automatically recalculate the pension supplement and the monthly deductions if
the underlying data (e.g. remuneration) changes.
A
BE09.09
Change in the calculated supply surcharge
The HR system must allow the automatically calculated and recalculated pension supplement to be
changed manually.
A
BE09.10
Document creation
When creating documents, the HR system must automatically use the calculated request amount, its
composition and the associated cash register symbol.
A
BE09.11
Transfer to HKR process
The HR system must transfer the payment-relevant data for the payment of the pension surcharge,
including the cash reference number for payment authorisation. It should be possible to use different
budget titles.
A
BE09.12
Modification of the acceptance order
The HR system must be able to make manual changes to payment authorisation requests at any time (e.g.
in the event of recalculation and deadline changes).
A
BE09.13
Confirmation of incoming payments
The HR system should recognise incoming payments transmitted from the payment preparation and
assign them to the pension supplement to be paid in.
B
BE09.14
Default of payment
The HR system should inform the administrator if pension supplements to be paid in have not been
received on time.
B
BE09.15
Payment reminder
The HR system must automatically send a payment reminder to the personnel case after a payment
deadline has expired.
A
BE09.16
Payment reminder - Setting the deadline
The HR system must make it possible to set the payment deadline for the payment reminder as part of
the supply surcharge of the Central Specialised Administration.
A
BE09.17
Final evaluation
After the end of the leave of absence, the HR system should automatically summarise the extent to
which the pension supplements have been paid in (comparison of actual/ target). The result of this
summary should be displayed to the administrator and be available for document creation.
B
BE09.18
Delegation to the state of MV
The HR system must map the secondment from another employer to the state of Mecklenburg-
Vorpommern in accordance with Section 14 BeamtStG in conjunction with Section 28 LBG MV and the
associated reimbursement of the pension supplement to the other employer
can.
A
13 December 2024 Page 170 of 366
13 december 2024
Requirement
labelling
Requirement
BE09.19
Delegation from the state of MV
The HR system must be able to map the secondment from the state of MV to another employer in
accordance with Section 14 BeamtStG in conjunction with Section 28 LBG MV and the associated receipt
of the pension supplement from the other employer.
BE09.20
Reimbursement in secondment cases with later transfer
In cases of secondment to the state of Mecklenburg-Vorpommern and from the state of Mecklenburg-
Vorpommern in which the personnel case is nevertheless transferred after a secondment without the
intention of transfer, the HR system must map a reimbursement or subsequent payment of the pension
supplement
can.
4.7.8.1.12 Further requirements
This section contains further requirements for the reference calculation that cannot be assigned to any of the previous
subsections.
Requirement
labelling
Requirement
Criterion
BE10.01
Calculation of claims for damages against third parties
The HR system should automatically calculate the amount of damage in the event of continued
payment of salary despite incapacity to work due to accidents caused by third parties.
B
BE10.02
Monetary benefit (1/3)
The HR system must make it possible to increase salaries through non-cash benefits (e.g. e-bike,
company car) by manually recording the non-cash benefit (gross).
A
BE10.03
Monetary benefit (2/3)
The HR system must automatically calculate the non-cash benefit (gross) after the necessary entries
have been made by the administrator.
A
BE10.04
Monetary advantage (3/3)
The HR system must enable the budget to be credited via the interface to the HKR procedure in the
same amount as the gross amount of the non-cash benefit is charged to the budget.
A
BE10.05
Maintenance contributions
The HR system must enable the calculation of maintenance contributions in accordance with the LDG
MV, including the mapping of the effective period (e.g. 6 months).
A
BE10.06
Back payment of withheld remuneration in the event of disciplinary measures
The HR system must provide for the possibility of subsequent payment of the withheld remuneration
if a disciplinary measure is finalised in a manner other than in the cases of Section 41 (3) LDG MV.
A
BE10.07
Statutory values for pensionable remuneration
The HR system must include all pensionable remuneration, the value of which
by the LBesG MV or its annexes.
A
13. December 2024 Page 171 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE10.08
Manually specified values for pensionable pay
The HR system must enable the processing department to record pensionable remuneration as
pensionable, the value of which is not justified by law (e.g. performance-related remuneration for
professors), and keep this available for payroll accounting.
A
BE10.09
Refund requirements
The HR system must automatically calculate the reimbursement amount to be requested (including
subsequent invoicing if necessary), request the necessary missing data from the processing
department and then automatically trigger the request to the department. The amount should be
transmitted for payment. It should be possible to post to several budget accounts.
It is essential to differentiate between salary, allowance and, if applicable, pension supplement.
A
BE10.10
Reimbursement of ward charges and a flat-rate cost allowance
The HR system should automatically calculate the ward pay and a cost compensation package and
then automatically trigger the request to the department. The amount should be transmitted for
payment
be made. It should be possible to post to several budget accounts.
B
4.7.8.2
Net calculation
In the net calculation, the net remuneration is determined on the basis of the gross service and official salaries. This takes into
account, for example, tax deductions, any withholdings, advances and capital-forming benefits.
4.7.8.2.1 Tax deductions
Income tax, church tax and solidarity surcharge must be deducted from the gross taxable pay. The HR system must take tax-free
income into account when determining the gross taxable income.
The HR system must also carry out the annual wage tax equalisation.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.9 (Overarching technical requirements: Net calculation - Tax deductions) Application.
4.7.8.2.2 Riester pension scheme
The HR system must participate in electronic reporting with Deutsche Rentenversicherung Bund - Zent- rale Zulagenstelle für
Altersvermögen in fulfilment of the requirements of §§ 79 ff. EStG.
For the calculation of salaries in this chapter, the overarching requirements from chapter
4.7.10.11 (Overarching technical requirements: Net calculation - Riester pension scheme) Application.
4.7.8.2.3 Retentions
In various cases, remuneration must be withheld due to salary regulations.
13. December 2024 Page 172 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
BE11.01
Fines for disciplinary measures
The HR system must allow fines to be withheld in accordance with Section 9 LDG MV.
A
BE11.02
Withholding of remuneration in the event of provisional dismissal
In the event of provisional dismissal in accordance with Section 41 LDG MV, the HR system must
enable the withholding of a percentage of remuneration including the special payment in accordance
with Section 4 SZG MV. The HR system should observe the maximum limit. One-off payments are not
to be taken into account.
A
BE11.03
Withholding of remuneration in the event of an appeal against retirement
Pursuant to Section 46 (4) LBG MV, the HR system must enable the withholding of remuneration that
exceeds the calculated pension.
A
BE11.04
Monetary advantage
The HR system must enable the withholding of the non-cash benefit from the amount paid out in
accordance with the Social Security Remuneration Ordinance (EStG).
A
BE11.05
Withholding of payment components
The HR system must enable the withholding of remuneration components, e.g. for meals allowance,
job ticket, car park management, official housing in accordance with the general administrative
regulations on state official housing and official clothing advances with a freely selectable term.
A
BE11.06
Withholding of personal deductions
The HR system must allow private deductions based on work-related matters (e.g. car park rental,
telephone charges).
A
BE11.07
Other private deductions
The HR system must be capable of transferring unspecified other private deductions if required.
A
4.7.8.2.4 AdvancesThe HR system must enable the granting of salary advances and advances during care or family care leave in
accordance with Sections 64a, 64b LBG MV in conjunction with Section 8 LBesG MV.
The overarching requirements from section 4.7.10.12 (Overarching professional requirements: Net calculation - Advances) also
apply to the salary calculation in this chapter.
Requirement
labelling
Requirement
BE12.01
Instruction and implementation of salary advances
The HR system must enable the automated implementation of salary advances for civil servants and
judges in compliance with the guidelines for the granting of advances in special cases (Advance
Guidelines VR of 28 November 1975 (GMBl. p. 829)).
BE12.02
Manual recording of advance payments
The HR system must support the manual recording of advance payments that deviate from the guidelines
(see BE12.01 (Instruction and implementation of salary advances)).
B in their amount.
13. December 2024 Page 173 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BE12.03
Advance salary payments to bailiffs and interest on these advance payments
The HR system should enable advance salary payments to bailiffs in accordance with the administrative
regulation on "Granting advance salary payments to bailiffs to set up a business room"
(https://www.landesrecht- mv.de/bsmv/document/VVMV-VVMV000008905/part/F). The HR system
must automatically calculate the repayment instalments including interest (Sections 291 and 288 BGB). If
the base interest rate changes during the repayment period, the automated calculation must be carried
out again.
B
BE12.04
Advance payment when taking family care leave or care leave
In accordance with Sections 64a and 64b LBG MV in conjunction with Section 8 LBesG MV, the HR system
must grant salary recipients the monthly payment of advances during care or family care leave.
A
BE12.05
Granting of discounts
The HR system must allow daily deductions from the granting of benefits as a prepayment.
A
4.7.8.2.5 Capital-forming benefitsThe HR system must be able to make capital-forming benefits payable. A freely definable
payment rhythm should be made possible. Furthermore, part-time employment should be taken into account when determining
the amount.
The overarching requirements from section 4.7.10.13 (Overarching professional requirements: Net calculation - Capital-forming
benefits) apply.
Requirement
labelling
Requirement
Criterion
BE13.01
Interruption
When making payments of capital-forming benefits, the HR system must determine the amount in the
event of interruptions and the admissibility in accordance with Sections 83 and 84 LBesG MV in
In conjunction with the 5th VermBG for civil servants and judges.
A
4.7.8.2.6 Subsequent insurance
If the insurance-free service or employment relationship is terminated, subsequent insurance for periods of employment must be
carried out in accordance with §§ 8, 181 Para. 2, 182 to 186a SGB VI. The calculation and implementation must be made possible
by the HR system. The supplementary insurance register must be available for processing supplementary insurance transactions.
This is used to monitor the processes, document correspondence and record the status of the procedure.
To calculate the supplementary insurance contributions, the HR system must use the necessary existing data from the salary and
remuneration areas. The supplementary insurance contributions are calculated on this basis and displayed using the periods of
employment. In addition, the HR system must enable the deferral of supplementary insurance. As a result, supplementary
insurance certificates and certificates for the deferral of supplementary insurance are created. Both the calculation and the
certificates must be correctable.
Irrespective of this, the HR system must be able to create a fictitious subsequent insurance for certain processes.
13. December 2024 Page 174 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
BE14.01
Implementation of supplementary insurance
The HR system must enable the implementation and calculation of subsequent insurance, taking into
account all relevant standards, in particular in accordance with Sections 8, 181 (2), 182 to 186a SGB VI.
A
BE14.02
Subsequent insurance directory
The HR system should offer the LAF administrator, the head of department and the head of department
group the opportunity to view a central supplementary insurance directory with a filter and sorting
function in accordance with access authorisations. This directory must contain all remuneration tasks
with assigned open and completed supplementary insurance workflows, including the associated
documents.
B
BE14.03
Subsequent insurance directory - manual entry
The HR system should make it possible for each subsequent insurance task to be carried out manually.
-
the basic data of the task (in particular surname, first name, date of birth and personnel number),
-
the responsible person in charge,
-
comparing requested and incoming documents,
-
comparing requested and completed entries,
-
Completed partial checks by the processing department,
-
Resubmissions,
-
the status of the subsequent insurance application (in process, documents requested, subsequent
insurance postponed, completed) including its history,
-
letters of reclaim sent (letters to transfer supplementary insurance contributions back, e.g. from a
pension insurance provider to a pension scheme or to the LAF) and
-
The amounts to be recovered and interest
amounts can be recorded and adjusted.
B
BE14.04
Post-insurance directory - Automated logging of the procedural status
The HR system should be automated in the supplementary insurance directory for each supplementary
insurance task.
-
the basic data of the task,
-
the responsible person in charge,
-
comparing requested and incoming documents,
-
comparing requested and completed entries,
-
Completed partial checks by the processing department,
-
Resubmissions,
-
the status of the subsequent insurance application (in process, documents requested, subsequent
insurance postponed, completed) and its history,
-
letters of reclaim sent (letters to transfer supplementary insurance contributions back, e.g. from a
pension insurance provider to a pension scheme or to the LAF) and
-
Store and continuously update recovery amounts
and interest amounts.
B
BE14.05
Post-insurance directory - calling up tasks and documents
The HR system should make it possible to call up the subsequent insurance tasks, including the associated
documents, from the subsequent insurance directory.
B
13 December 2024 Page 175 from 366
13 december 2024
Requirement labelling
Requirement
Criterion
BE14.06
Subsequent insurance directory - selection of subsequent insurance tasks and their combination
The HR system should enable the clerk in the supplementary insurance directory to select (filter and
sort) the supplementary insurance tasks according to at least the following characteristics, including
their combination:
-
Periods,
-
Status of post-insurance cessation,
-
Type of settlement (in particular subsequent insurance, retirement benefit),
-
after resubmissions,
-
according to the basic data of the task (in particular surname, first name, date of birth and
personnel number) and
-
Recovery cases.
The HR system should save the individual user settings for the filter and sorting function for each case in
the post-insurance directory.
B
BE14.07
Subsequent insurance list - remarks field
The HR system should contain a free text field with no character limit for comments for each task in the
post-insurance list.
B
BE14.08
Subsequent insurance directory - editing the status of the subsequent insurance order
The HR system should enable the Central Specialist Administration to create, adjust and delete (edit) the
status of the supplementary insurance task for use in the supplementary insurance directory (e.g. as a
drop-down field).
B
BE14.09
Provision of references and times
The HR system must automatically transfer the remuneration subject to social insurance and the periods
of employment not subject to insurance from the salary or remuneration area to the subsequent
insurance process. For individual cases, it must be possible to enter the data completely manually.
A
BE14.10
Calculation of supplementary insurance contributions
The HR system must calculate the supplementary insurance contributions in accordance with § 181 Para.
2, 182 to 183 SGB VI. The calculation must take into account the social insurance obligation and the
contribution assessment ceiling (maximum limit). The HR system must take into account the statutory
regulations in force at the time of payment (particularly in the case of payment of supplementary
insurance contributions at the turn of the year).
A
BE14.11
Period-dependent display
The HR system must be able to display the periods to be re-insured and the corresponding re-insurance
contributions. The periods must be displayed on an annual basis (1 January - 31 December per calendar
year). Periods during the year must be shown on a daily basis for each calendar year. Certain periods (in
particular periods of training, parental leave, child sick days, leave of absence without pay) must also be
shown separately and labelled separately. Furthermore, all periods of interruption (e.g. due to interim
employment) must be listed equally.
A
BE14.12
Postponement of supplementary insurance
The HR system must allow a deferral of subsequent insurance. In particular, a one-year, two-year and
unlimited deferral must be possible as a deferral period.
be possible.
A
13 December 2024 Page 176 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
BE14.13
Resubmissions in the event of postponement of supplementary insurance
The HR system should automatically set resubmissions for a subsequent insurance process for one-year
and two-year deferrals based on the deferral period.
B
BE14.14
Automated creation of certificates
The HR system should automatically generate supplementary insurance certificates and certificates for
the deferral of supplementary insurance. In a certificate, the supplementary insurance amounts must be
shown in the currency valid in the period (DM or Euro).
B
BE14.15
Corrections
The HR system must calculate a correction amount (also retrospectively) with the result of
positive/negative (individual) amounts. The HR system must create corrected supplementary insurance
certificates based on this.
A
BE14.16
Interest calculation
The HR system must charge interest in accordance with § 27 SGB IV if overpayments of supplementary
insurance contributions are not refunded promptly.
A
BE14.17
Fictitious supplementary insurance
The HR system should create a fictitious subsequent insurance, e.g. for pension equalisation procedures
and old-age benefit procedures. For this purpose, it must be possible to specify the date of leaving the
employment relationship if required.
B
BE14.18
Statistics for pension insurance audit
The HR system must create an audit list for the external audit of the German Pension Insurance (Deutsche
Rentenversicherung) based on the available data on subsequent insurance transactions.
can create.
A
4.7.9
Supply requirements
The LAF calculates the remuneration for all personnel cases. This includes people who have worked as civil servants, judges, prime
ministers and state ministers in the past. Upon retirement, these persons receive various pension benefits. The entitlements to
pension payments continue to exist for the surviving dependants.
Pension equalisation and pension burden sharing are also associated with the pension.
4.7.9.1
Gross calculation - supply
In the gross calculation, the pension is determined before deduction of taxes and any social security contributions. To this end,
the necessary data for determining the pension is determined, the pension rate is calculated on the basis of the CV data (see
chapters 4.1.4 and 4.7.5 (CV data)) and the pension benefits are calculated. Accident benefits, transitional allowances and
pensions under the LMinG differ from the pensions of civil servants and judges. In the event of the death of the civil servant or
judge, the surviving dependants' pension is granted. The respective pension may be reduced under certain circumstances and the
suspension regulations must be applied.
13 December 2024 Page 177 from 366
13 december 2024
4.7.9.1.1 Determination of the supply data
Various data must be recorded in order to calculate the pension. This is partly carried out by the department's administration
department. Furthermore, data must be transferred when changing from an active civil servant or active civil servant/judge to a
retired civil servant. The pensionable pay is determined on this basis.
Requirement
labelling
Requirement
Criterion
VE01.01
Daily recording of data
The overall system must enable the data for the supply calculations to be recorded on a daily basis.
A
VE01.02
Collection of general supply data
In addition to the general data of the beneficiary (e.g. basic information data, (different) bank details,
marital status, tax characteristics, different address data, etc.), the overall system must enable the
collection of the following data in particular:
-
Start of retirement (at the end of ...),
-
Start of the pension payment,
-
Group of persons (e.g. teachers, professors, law enforcement officers, judges, other civil servants,
career) and job title, unless this is automatically determined by linking the salary payment data.
civil servants, career) and job title, unless this is automatically derived from the salary payment
data,
-
Reason for retirement (e.g. statutory age limit, special age limit, application age limit, incapacity to
work) in accordance with the relevant statutory regulations,
-
Existence of a severe disability within the meaning of Section 2 (2) SGB IX.
A
VE01.03
Determination and manual correction of pensionable pay
The HR system must automatically determine the pensionable pay in accordance with § 5 LBeamtVG MV
including the family allowance of level 1 in accordance with § 50 Para. 1 LBeamtVG MV. In particular, the
HR system must take into account the two-year period pursuant to § 5 para. 3 LBeamtVG MV (except in
the case of § 5 para. 2 LBeamtVG MV) and the adjustment of the experience level pursuant to § 5 para. 2
LBeamtVG MV. The HR system must enable the administrator to confirm/deny the two-year period.
The HR system must allow all data on which the calculation of pensionable pay is based to be changed
manually (additions, deletions and adjustments to amounts).
A
VE01.04
Pensionability of all salary components
The HR system must provide labelling with the characteristics
-
pensionable (yes/no),
-
Scope of pension eligibility,
-
Consideration when calculating the maximum limits of the respective suspension regulations
yes/no,
-
Consideration for death benefit payment (yes/no),
-
Linear increase (yes/no),
-
Depreciation for linear adjustments (yes/no),
-
is subject to seizure (yes/no),
-
Type of tax treatment and
-
Consideration when reporting to the Central Allowance Centre for Retirement Benefits (yes/no)
enable.
A
13. December 2024 Page 178 from 366
13 december 2024
VE01.05
Manual recording of pensionable pay
The HR system must support the manual recording of pensionable pay in accordance with Section 5
LBeamtVG MV, in particular the recording of deposited amounts (e.g.
B. Functional benefits which are not paid at the time the insured event occurs).
A
VE01.06
Change in pensionable remuneration
The HR system must enable the manual amendment of pensionable pay in accordance with § 5 LBeamtVG
MV.
A
VE01.07
Examination of the claim
The HR system must automatically check whether there is an entitlement to pension payments in
accordance with Section 4 (1) and (2) LBeamtVG MV in conjunction with the various statutory grounds
(in particular Section 26 BeamtStG) and age limits (in particular
§§ Sections 35, 36, 108, 114, 115 LBG MV and Section 70 (1) LHG MV) for retirement. If necessary, the
HR system must request any missing data from the processing department. The HR system must notify
the LAF administrator of the result of the check.
A
VE01.08
Currency converter - Conversion of foreign currencies
The HR system must automatically convert amounts in foreign currencies into EUR, whereby the
exchange rates must be updated monthly.
A
VE01.10
Manual entry for the elimination of the increased pension rate
The HR system must enable the manual recording of the characteristics for the cancellation of the
increased pension rate in accordance with Section 14a (3) sentence 2 LBeamtVG MV:
-
Receipt of a pension (discontinuation),
-
Receipt of earned income (discontinuation),
-
Cessation of incapacity to work (discontinuation) and
-
Receipt of an accident pension from the statutory accident insurance (no cancellation).
A
VE01.11
Manually specified values for pensionable pay
The HR system must be able to record pensionable pay, the value of which is not justified by law but is
recorded manually by the administrator (e.g. performance-related pay for professors), through the
and keep them available for payroll accounting.
A
4.7.9.1.2 Determination of the pension rate
In order to calculate the pension rate as a percentage, the pensionable service period is determined on the basis of the CV data
(see chapters 4.1.4 and 4.7.5 (CV data)). The pension rate and the increased pension rate are then calculated.
Requirement
labelling
Requirement
Criterion
VE02.01
Evaluation of CV data according to the law
The HR system must be able to evaluate the CV data, in particular in the context of pension
determination, pension information, pension equalisation, pension burden sharing and the recognition
of pensionable periods of service in accordance with §§ 6-13, 49 para. 2, 66, 67, 69g and 85 LBeamtVG
MV, § 13
Para. 2 LMinG and § 5 LParlG in the respective valid version.
A
13. December 2024 Page 179 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE02.02
Evaluation of CV data - selection options
The HR system must offer the following selection options in particular when evaluating times:
-
pensionable or non-pensionable,
-
pensionable due to restricted use due to limited fitness for duty in accordance with Section 6 (1)
sentence 4 LBeamtVG MV,
-
pensionable for temporary civil servants,
-
Member of the state government as pensionable,
-
The pensionable salary is deemed to be doubled in accordance with Section 13 (2) LBeamtVG MV,
-
Double crediting in the new federal states (reconstruction aid) as double pensionable salary,
-
Child rearing as pensionable according to §85 para. 7 LBeamtVG,
-
the assessment of overlapping periods (pensionable on a pro rata basis if applicable).
A
VE02.03
Evaluation of CV data - Automated determination of attribution times
When evaluating the CV data, the HR system must automatically determine credit periods in accordance
with Section 13 (1) LBeamtVG MV and add these to the pensionable service period.
A
VE02.04
Evaluation of CV data - observance of maximum limits
When evaluating the CV data, the HR system must automatically take into account statutory maximum
limits for the periods (e.g. limitation of technical college or university education, employment in the
public sector).
A
VE02.05
Evaluation of CV data - comparative calculation and limitation
When evaluating the CV data, the HR system must automatically implement a comparative calculation
and restriction of the consideration of periods for which there is an entitlement or claim to a retirement
pension benefit that are not subject to the provisions of § 55 LBeamtVG MV (§ 11 para. 2 and § 67 para.
2 sentence 4 LBeamtVG MV) by analogy.
A
VE02.06
Manual evaluation of CV data
The HR system must make it possible for the administrator to manually define periods as double, single,
pro rata (fraction and percentage) and not pensionable when evaluating CV data, e.g. for determining
the pension rate.
A
VE02.07
Manual justification for the evaluation of CV data
When assessing CV data, the HR system must enable the administrator to add text modules and a free
text field without a character limit for document creation for each time assessed. It should also be
possible to write in the free text field during the evaluation.
A
VE02.08
Evaluation of CV data - reference in text modules
The HR system must automatically summarise several identical text modules at different times and refer
to the respective times from this summary.
A
VE02.09
Evaluation of CV data - automated evaluation through rules
The HR system must automatically evaluate the CV data based on legal rules and rules specified by the
client and pre-assign the corresponding fields.
gen.
A
13 December 2024 Page 180 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE02.09a
Evaluation of CV data - configurability of evaluation rules The set of rules for evaluating CV data in
accordance with VE02.09 should be configurable by the central specialist administration (adaptation
of existing rules and creation of new rules - if/then).
B
VE02.10
Evaluation of CV data - automated justification through rules
The HR system must automatically assign text modules for each evaluated time to justify the
consideration or non-consideration.
A
VE02.11
Evaluation of CV data - manual change to automated evaluation
The HR system must enable the administrator to manually change times that were or were not taken
into account by the automated evaluation, including the text modules.
A
VE02.12
Manual entry and amendment of the pension rate
The HR system must allow manual entry and amendment of the pension rate.
A
VE02.13
Automated calculation of the pension rate
The HR system must automatically calculate the pension rate in accordance with Section 14 (1) and (5)
LBeamtVG MV on the basis of the pensionable service periods, taking into account the statutory
minimum and maximum pension rates.
A
VE02.14
Comparative calculation according to § 85 LBeamtVG MV
The HR system must perform the comparative calculation automatically in accordance with Section 85
LBeamtVG MV.
A
VE02.15
Examination of the requirements for the increased pension rate
The HR system should automatically check whether the requirements for the increased pension rate
pursuant to Section 14a (1) LBeamtVG MV are met. If necessary, the HR system should request any
missing data from the administrator. The HR system must display the result of the check as a notification
to the administrator.
B
VE02.16
Calculation of the increased pension rate
The HR system must automatically calculate the increased pension rate in accordance with § 14a Para. 2
LBeamtVG MV and additionally in accordance with § 36 Para. 3 LBeamtVG MV, taking into account the
maximum structural salary rates. If necessary, the HR system must request any missing data from the
processing department.
A
VE02.17
Manual entry and amendment of the increased pension rate
The HR system must enable the manual recording and amendment of the increased pension rate by
recording eligible compulsory contribution periods.
A
VE02.18
Recognition of the period of the temporary increase in the pension rate
The HR system must allow the period of the temporary increase in the pension rate to be entered
manually. Recording means entering the start and end dates or, alternatively, entering the period to be
used for the temporary increase.
months to be taken into account.
A
13 December 2024 Page 181 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE02.19
Automated cancellation of the increased pension rate
The HR system must
-
at the end of the fixed term,
-
on reaching the standard retirement age and
-
for submissions pursuant to § 14a para. 3 sentence 2 LBeamtVG MV
The HR system must point this out to the administrator. The HR system must inform the administrator of
this.
A
VE02.20
Changes to pensionable service periods
The HR system must automatically adjust the pension rate if the pensionable service periods change.
A
4.7.9.1.3 Death benefit
If a staff member (civil servant/judge/judge in office) dies (not just disappears), the surviving dependants receive a death grant.
This is calculated in accordance with § 18 Para. 1 LBeamtVG MV. In order for the death grant to be paid out, it is necessary to
register or select a new payee. Payment must be possible on a pro rata basis to several persons and at different times.
The overarching requirements from section 4.7.10.6 (Overarching technical requirements: Gross calculation - death benefit) also
apply to the pension calculation in this section.
Requirement
labelling
Requirement
Criterion
VE03.04
Determination of the death benefit
If there are no surviving dependants, the HR system must enable the manual entry of the data required to
calculate the death grant as a special case of the death grant and automate the calculation, taking into
account the
maximum amount in accordance with § 18 Para. 2 No. 2 LBeamtVG MV.
A
4.7.9.1.4 Survivors' benefits
If a member of staff dies or goes missing and their death is probable (Section 29 (1) LBeamtVG MV), the surviving dependants
receive survivors' benefits in accordance with Section 16 LBeamtVG MV. In addition to the death grant, which is shown in section
4.7.9.1.3, the survivor's pension to be calculated includes the widow's/widower's pension, the widow's/widower's settlement, the
orphan's pension and the maintenance contribution.
The necessary data of the surviving dependants to enable the payment of the surviving dependants' pension is recorded by the
administrative department. In this respect, these are new personnel cases that are linked to the deceased personnel case. If the
survivor's pension (in particular in accordance with § 17 Para. 2 and § 18 LBeamtVG MV) is to be paid to a personnel case (e.g.
widow) or third parties, these authorised persons must be selectable (ÜF06.01) or recordable (ÜF06.02).
13. December 2024 Page 182 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE04.01
Labelling of the remuneration for the month of death
The HR system must mark emoluments and expense allowances for the month in which a staff member
dies as emoluments for the month of death in accordance with Section 17 LBeamtVG MV.
These remain with the personnel case and are not reclaimed.
A
VE04.02
Retention of data on the determination of pension provision
The HR system must hold data on the (notional) pension determination for the calculation of a survivor's
pension.
A
VE04.03
Automated check of the requirements for widow's/widower's pension According to § 19 LBeamtVG MV,
the HR system must automatically check as part of a determination process whether
-
the deceased was a civil servant/judge for life,
-
the deceased employee was a civil servant/judge on probation and a service-related injury or
accident was recorded,
-
the requirements of Section 4 (1) LBeamtVG MV are met,
-
the deceased employee was a retired civil servant,
-
the marriage lasted at least 1 year and
-
the marriage of the retired civil servant was concluded before reaching the standard retirement
age pursuant to Section 35 (1) and (2) LBG MV.
The HR system must provide the processing department with concrete information in the determination
process.
A
VE04.04
Fictitious calculation for survivors' benefits
In the event that civil servants/judges die before receiving pension benefits, the HR system must
fictitiously calculate the pension benefits for the granting of survivors' benefits, taking into account the
actual circumstances, and document them in a way that can be viewed by the processing department.
A
VE04.05
Calculation of the widow's/widower's pension
The HR system must automatically calculate the widow's/widower's pension in accordance with § 20
LBeamtVG MV.
A
VE04.06
Comparative calculation for widow's/widower's pension
The HR system must compare the calculated widow's/widower's pension with the minimum
widow's/widower's pension pursuant to § 20 para. 1 sentences 2-4 LBeamtVG MV and use the higher
amount as the widow's/widower's pension, taking into account the supplement pursuant to § 50c
LBeamtVG MV.
A
VE04.07
Reduction of widow's/widower's pension in the event of a large age difference
According to § 20 Para. 2 LBeamtVG MV, the HR system must enable the percentage reduction of the
widow's/widower's pension in the event of a large age difference, taking into account the maximum
reduction percentage and the minimum widow's/widower's pension.
A
VE04.08
Automated check of the requirements for widow/widower's compensation
In accordance with § 21 Para. 1 LBeamtVG MV, the HR system must automatically check whether the
widow/widower is entitled to widow's/widower's pension/support contribution.
The HR system must display the check result to the administrator.
A
13 December 2024 Page 183 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE04.09
Calculation of the widow's/widower's settlement
The HR system should automatically calculate the widow's/widower's pension after recording a
remarriage in accordance with § 21 Para. 2 LBeamtVG MV. If necessary, the pay system must request any
missing data from the processing department.
B
VE04.10
Revival of widow's/widower's pension and maintenance contribution
After recording the dissolution of a marriage in accordance with § 21 Para. 2 LBeamtVG MV, the HR
system automatically informs the processing department of the revival of the entitlement to
widow's/widower's pension and maintenance contribution in accordance with § 21 Para. 3 LBeamtVG
MV.
B
VE04.11
Automated check of the requirements for orphan's benefit
In accordance with Section 23 (1) LBeamtVG MV, the HR system must automatically check as part of a
determination process whether
-
the deceased was a civil servant/judge for life,
-
the deceased employee was a civil servant/judge on probation and a service-related injury or
accident was recorded,
-
the requirements of Section 4 (1) LBeamtVG MV are met,
-
the deceased employee was a retired civil servant and
-
the child relationship, insofar as this was established by adoption as a child, existed before
reaching the standard retirement age pursuant to § 35 (1) and (2) LBG MV.
The HR system must provide the processing department with concrete information in the determination
process.
A
VE04.12
Selection of half-orphan or full orphan
The HR system must allow each child to manually select whether they are a half-orphan or a full orphan.
A
VE04.13
Review of the increase in orphan's benefit for half-orphans to the rate for full orphans
As part of the determination process, the HR system should automatically check whether the surviving
parent of the child is a personnel case and receives the widow's/widower's pension and a maintenance
contribution in accordance with § 24 Para. 2 LBeamtVG MV. The HR system should provide the case
handler with specific information in the determination process.
B
VE04.14
Calculation of the orphan's pension
The HR system must automatically calculate the orphan's pension in accordance with § 24 para. 1 and 2
LBeamtVG MV, taking into account the maximum amount required if necessary in accordance with § 24
para. 2 LBeamtVG MV.
A
VE04.15
Comparative calculation for orphan's pension
The HR system must compare the calculated orphan's pension with the minimum orphan's pension according
to
§ The orphan's pension is to be compared with the amount paid under Section 24 (1) LBeamtVG MV and
the higher amount used as orphan's pension.
A
VE04.16
One-off orphan's pension entitlement
The HR system should take into account that only the highest orphan's pension may be granted in
accordance with § 24 Para. 3 LBeamtVG MV. In addition, the HR system should automatically grant the
one-off orphan's pension entitlement if both deceased parents
are recorded in the HR system as civil servants in MV.
B
13 December 2024 Page 184 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE04.17
Calculation of the maintenance contribution on marriage after the standard age limit
The HR system must automatically calculate the maintenance contribution in accordance with § 22 Para.
1 LBeamtVG MV after manually recording the necessary data (e.g. earned income).
Reference is made to the special features of No. 22 BeamtVGVwV, which are applied accordingly.
A
VE04.18
Automated examination of the requirements for maintenance contributions for divorced persons
The HR system must carry out automated checks as part of a determination process in accordance with
Section 22 (2) LBeamtVG MV,
-
whether the divorced person is entitled to pension equalisation and
-
a reduction in earning capacity was recognised,
-
there is a child entitled to orphan's pension and
-
the divorced person has reached the age of 60.
The HR system must provide the processing department with concrete information in the determination
process.
A
VE04.19
Calculation of the maintenance contribution for divorced persons
The HR system must automatically calculate the maintenance contribution in accordance with § 22 Para.
2 LBeamtVG MV, taking into account the maximum amount in accordance with § 22 Para. 2 Sentence 4
LBeamtVG MV.
A
VE04.20
Calculation of the maintenance contribution instead of the orphan's pension
The HR system must automatically calculate the maintenance contribution instead of the orphan's
pension in accordance with § 23 para. 2 sentence 2 LBeamtVG MV.
A
VE04.21
Manual entry and amendment of survivors' benefits
The HR system must enable the manual entry and amendment of amounts for widow's/widower's
benefits, widow's/widower's compensation, orphan's benefits and maintenance allowances.
A
VE04.22
Coincidence of widow's/widower's pension, orphan's pension and maintenance allowances
In accordance with § 25 in conjunction with § 20 Para. 3 LBeamtVG MV and § 42 Sentence 3 LBeamtVG
MV, the HR system must observe the maximum limit and automatically reduce the individual
emoluments in the same proportion if several entitlements to widow's/widower's pension, orphan's
pension and maintenance contributions exist at the same time. This review and reduction must be
carried out automatically at least once a month.
A
VE04.23
Surviving dependants' pension on the basis of the accident pension
According to Section 39 (2) LBeamtVG MV, in cases where a retired civil servant receiving an accident
pension does not die as a result of an occupational accident, the HR system must provide for the
surviving dependants (remuneration for the month of death, death grant, widow's/widower's pension,
widow's/widower's
/widower's pension, orphan's pension and maintenance contribution) on the basis of the accident
pension in accordance with §§ 36 and 37 LBeamtVG MV.
A
VE04.24
Maintenance contribution for surviving dependants
The HR system must automatically calculate the maintenance contribution for surviving dependants in
accordance with § 26 LBeamtVG MV.
A
13 December 2024 Page 185 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE04.25
Survivors' pensions for members of the state government and parliamentary state secretaries (1/2)
The HR system must automatically calculate the survivors' pension in accordance with Section 15 (1)
LMinG and Section 5 LParlG for members of the state government who died during their term of office
and parliamentary state secretaries who died during their term of office.
A
VE04.26
Survivors' pensions for members of the state government and parliamentary state secretaries (2/2)
The HR system must automatically calculate the surviving dependants' pension in accordance with
Section 15 (2) LMinG and Section 5 LParlG for former members of the state government and former
parliamentary state secretaries.
A
VE04.27
Hardship survivors' benefits for members of the state government and parliamentary state secretaries
The HR system must provide survivors' benefits in cases of hardship in accordance with Section 16 LMinG
and § 5 LParlG after manual collection of the necessary data.
A
4.7.9.1.5 Supply according to the LMinG
Members of the state government under the LMinG and parliamentary state secretaries under the LParlG receive pensions in
accordance with Section 11 LMinG. In addition to the pension under Section 13 LMinG, they may be entitled to a transitional
allowance (Section 4.7.9.1.9 (Transitional allowance and compensation)) and accident benefits (Section 4.7.9.1.8 (Accident
benefits)). Surviving dependants may receive survivors' benefits (4.7.9.1.3 (Death benefit) and 4.7.9.1.4 (Survivors' benefits)).
Since Section 11 (2) sentence 1 LMinG states that the calculation of the pension under the LMinG is a variation of the regulations
applicable to civil servants, the requirements for these personnel cases are to be understood as a variation of the requirements
for civil servant pensions.
Requirement
labelling
Requirement
Criterion
VE05.01
Requirements for the pension
As part of a determination process, the HR system must automatically check whether the requirements
are met.
-
the five-year minimum period pursuant to Section 13 (1) and (8) LMinG and
-
the temporary holding of the office of Prime Minister and the six-year minimum period pursuant to
Section 13 (3) LMinG and Section 5 LParlG for the granting of a pension pursuant to Section 13
LMinG
and provide the processing department with a concrete indication of this in the
process.
A
13. December 2024 Page 186 from 366
13 december 2024
VE05.02
Calculation of the pension rate
The HR system must automatically calculate the pension rate in accordance with Section 13 (2) and (7)
LMinG and Section 5 LParlG, taking into account the minimum and maximum percentages.
A
VE05.03
Calculation of the pension
The HR system must automatically calculate the pension in accordance with Section 13 (2), (3) and (7)
LMinG and Section 5 LParlG.
A
VE05.04
Comparative calculations
The HR system must perform the comparative calculations according to
-
§ Section 13 (5) sentence 2 LMinG,
-
§ Section 13 (6) LMinG and
-
§ Section 13 (9) LMinG
-
and § 5 LParlG
automatically and continue the calculation of the remuneration with the higher result.
A
VE05.05
Suspension of the entitlement to a pension
The HR system must allow the entitlement to a pension to be suspended in accordance with Section 13
(4) LMinG and Section 5 LParlG.
A
VE05.06
Hardship pension
The HR system must determine the pension in cases of hardship in accordance with § 16 LMinG and § 5
LParlG, taking into account the maximum percentage rate after manual entry of the necessary data.
A
VE05.07
Transitional arrangements for existing cases
The HR system must enable the transitional regulations in accordance with Section 18 LMinG and Section
5 LParlG for existing cases. In particular, the pension rate should be entered manually.
to be available.
A
4.7.9.1.6 Supply information and further information
Employees are regularly interested in finding out how high their future pension entitlements will be. To find out, they submit an
application for pension information to the LAF. The application can be submitted both in paper form and via the KP for
remuneration (KP03.10 (document download) to KP03.13 (documents - archiving (1/5)). The HR system enables the administrator
to calculate the notional pension benefits.
All supply information, including mass supply information, is sent in accordance with 4.5 (Output management).
Furthermore, the HR system must enable information on periods of service and previous service to be provided to pension
insurance providers. In addition, certain amounts (such as the minimum pension) must be available for processing by telephone.
13. December 2024 Page 187 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE06.01
Calculation of supply information and data transfer for supply information
The HR system must enable the administrator to calculate notional pension payments (pension
information). The necessary data stored in the salary and pension task, in particular
-
pensionable remuneration,
-
pensionable periods of previous service and periods of service,
-
dynamised reduction amount in accordance with § 57 LBeamtVG MV,
-
Pension/supplementary pension amounts,
-
Other pension benefits § 54
in the supply information task.
A
VE06.02
Extrapolation of service times up to a point in time (1/3)
The HR system must be able to automatically fictitiously supplement (extrapolate) the periods of service
within the scope of the pension information (VE06.01) up to a selectable point in time.
A
VE06.03
Extrapolation of service times up to a point in time (2/3)
As part of the pension information (VE06.01), the HR system must enable the case handler to choose
between the standard retirement age of the personnel case and a manually entered date. If a date is
entered, the HR system must enable the case handler to enter the special features "incapacity for work",
"severe disability" and "application age limit" (pension deduction) and take these into account in the
calculation.
A
VE06.04
Extrapolation of service times up to a point in time (3/3)
The HR system must make it possible for the administrator to choose whether the periods of service are
to be supplemented according to the current scope of employment of the personnel case, in full-time or
in a partial time ratio (fraction, percentage, decimal number) as part of the pension information
(VE06.01).
A
VE06.05
Customisation of data (1/3)
The HR system must enable the administrator to change and supplement all fictitious data relevant for
the calculation in the pension information task. The real data on which the HR system is based must not
be changed by the fictitious calculation.
A
VE06.06
Customisation of data (2/3)
The HR system must make it possible for the person responsible for calculating the pension information
task to be able to manually change the scope of employment for definable periods (including sabbaticals)
and the remuneration.
A
VE06.07
Customisation of data (3/3)
The HR system must make it possible for the processing department to add further income and
pensions/supplementary benefits in addition to the notional pension payments when calculating the
pension information task.
A
VE06.08
Preparation of the supply information
When preparing the pension information, the HR system must include the necessary associated
appendices (in particular pensionable service and previous service and pension rate, temporary increase
in pension rate, pension increase and pension increase).
and attach them automatically.
A
13 December 2024 Page 188 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE06.09
Reuse of the data
The HR system must make it possible for all data relating to a pension information task (in particular the
pensionable service and previous periods of service) to be used as a data basis for a new pension
information task and for a pension determination.
A
VE06.10
Bulk supply information
The HR system should be able to create pension information for a large number of people (mass pension
information) automatically, regularly and without the involvement of the administrator in accordance
with VE06.01 (calculation of pension information and data transfer for pension information) and VE06.08
(creation of pension information).
In accordance with VE06.02(Extrapolation of periods of service up to a point in time (1/3)), VE06.02
(Extrapolation of periods of service up to a point in time (2/3)) and VE06.02 (Extrapolation of periods of
service up to a point in time (3/3)), the periods of service according to the 3 variants (standard
retirement age, application age limit, incapacity to work) must be supplemented with the scope of full-
time employment for each personnel case.
In addition, the HR system of the central specialised administration should offer the possibility of
restricting the group of recipients on the basis of certain characteristics (e.g. year of birth).
B
VE06.11
Information to pension insurance providers about periods of employment
The HR system must be able to provide information on periods that are taken into account as
pensionable service periods when determining pension payments.
A
VE06.12
Automated calculation and display of minimum amounts
The HR system must fulfil the minimum pension, the minimum accident benefit and the minimum
reduction limit pursuant to Section 53 LBeamtVG MV after recording
-
of the effective date (calculation from),
-
the group of persons and
-
of the existing supply case since/as of
automatically. The HR system must recognise the minimum pension, the minimum accident pension and
the minimum reduction limit in accordance with Section 53 LBeamtVG MV both during and outside the
pension determination and calculation process.
show.
A
4.7.9.1.7 Supply calculation
Once the pensionable salary and the pension rate have been determined, the pension benefits are calculated. These may be
reduced by the pension discount. This is followed by a comparative calculation with the minimum pensions. Furthermore, the
family allowance and the differential amount according to § 50 LBeamtVG MV for children to be taken into account are
calculated. The supplements in accordance with Sections 50a-50e LBeamtVG MV (child-raising supplement, child-raising
supplement, child supplement to widow's allowance, nursing and child-care supplement) are then determined. As a result, the
pension assessment is finalised with a decision and the associated annexes.
The overarching requirements from chapters 4.7.10.1 (Overarching technical requirements: Gross calculation - General
calculation of benefits), 4.7.10.30 (General technical requirements: Gross calculation - Family-related benefits), 4.7.10.40
(General functional requirements: Gross calculation - Other pay components)
13. December 2024 Page 189 from 366
13 december 2024
and 4.7.10.50 (General technical requirements: Gross calculation - one-off and special payments) apply.
Requirement
labelling
Requirement
Criterion
VE07.01
Calculation of pension benefits
The HR system must automatically calculate the pension benefits by applying the pension rate to the
pensionable salary.
A
VE07.02
Fixed supply reference
The HR system must enable manual recording for all types of pension benefits.
-
of a fixed amount,
-
an associated designation and
-
of an associated legal basis.
A
VE07.03
Daily calculation of the supply
The HR system must make it possible to calculate the supply on a daily basis.
A
VE07.04
Retirement not on the first of the month
The HR system must automatically adjust the calculation of pension benefits for this month if retirement
does not take place on the first of the month (calculation to the day).
A
VE07.05
Retroactive granting of benefits
The HR system must notify the case handler if benefits are granted more than 3 months after the
requirements of Section 14a (4) sentence 2 LBe amtVG MV have been met.
A
VE07.06
Dynamisation
The HR system must ensure that pension payments are automatically adjusted when the salary tables are
adjusted.
A
VE07.07
Temporary retirement
The HR system must observe § 14 Para. 6 LBeamtVG MV when calculating the pension for a person who
has been placed on temporary retirement.
A
VE07.08
Determination for the calculation of the pension discount
Pursuant to Section 14 (3) LBeamtVG MV and Section 14a (2) sentence 3 LBeamtVG MV, the HR system
must be used to calculate the pension discount.
-
the minimum period of pensionable service and eligible compulsory contribution periods,
-
periods according to § 50d LBeamtVG MV and
-
Automatically determine periods of child-raising attributable to the civil servant.
A
VE07.09
Automated calculation of the pension discount
The HR system must automatically calculate the pension deduction in accordance with Section 14 (3)
LBeamtVG MV and Section 14a (2) sentence 3 LBeamtVG MV, taking into account the maximum limits,
after the reasons for entry (e.g. in the event of incapacity to work, staggered age limit with and without
severe disability, staggered application age limit with and without severe disability) have been recorded
by the processing department. The HR system must take into account the legal differences with regard
to the various groups of people (e.g. judges, other civil servants, law enforcement officers). The HR
system
system must observe the transitional regulation pursuant to § 69f LBeamtVG MV.
A
13 December 2024 Page 190 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE07.10
Automated exclusion of the pension discount calculation
The HR system must support the calculation of the pension discount.
-
in the event of early retirement due to incapacity for work as a result of an occupational accident,
-
in the event of retirement due to incapacity for work, if the civil servant has reached the age of 63
at the time of retirement and has completed a minimum period of 40 years,
-
in the case of retirement on application before reaching the standard retirement age, if the civil
servant has reached the age of 65 at the time of retirement and has completed a minimum period
of 45 years,
automatically prevent/exclude. If necessary, the HR system must request any missing data from the
processing department.
A
VE07.11
Exclusion of the pension discount
The HR system must enable the processing department to manually exclude the pension deduction.
A
VE07.12
Comparative calculation with minimum supply
In accordance with § 14 Para. 4 LBeamtVG MV, the HR system must automate the calculated pension
payments.
-
with the office-based minimum pension and
-
with the office-independent minimum pension plus the increase amount and continue processing
with the highest of the three amounts (calculated pension amount, office-dependent minimum pension,
office-independent minimum pension).
A
VE07.13
Exclusion of minimum amounts
The HR system must enable the administrator to decide that the minimum amounts (e.g. minimum
pension) are not taken into account when calculating the pension payments.
A
VE07.14
Calculation of the difference for children to be taken into account
The HR system must calculate the difference for children to be taken into account according to
§ 50 LBeamtVG MV automatically.
A
VE07.15
Recognition of the difference for children to be taken into account
The HR system must enable the manual recording of the difference for children to be taken into account
in accordance with § 50 LBeamtVG MV.
A
VE07.16
Determination of the surcharge to maintain the distance to basic security
The HR system must automatically determine the supplement to maintain the distance to the basic
pension in accordance with Section 50 (2) LBeamtVG MV.
A
VE07.17
Determination of the equalisation amount
The HR system must automatically calculate the compensation amount in accordance with Section 50 (3)
LBeamtVG MV.
A
VE07.18
Recognition and consideration of the equalisation amount
The HR system must enable the manual recording of the equalisation amount, which must be taken into
account in addition to the orphan's pension in accordance with § 50 Para. 3 LBeamtVG MV.
is.
A
13 December 2024 Page 191 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE07.19
Data collection for supplements according to §§ 50a-50e LBeamtVG MV
The HR system must enable the manual recording of data on children (surname, first name, date of birth)
for supplements in accordance with Sections 50a-50e LBeamtVG MV (child-raising supplement,
supplementary child-raising supplement, child supplement to widow's allowance, nursing and
supplementary child-care supplement).
A
VE07.20
Consideration of allocated child-raising periods
When determining supplements in accordance with Sections 50a-50e LBe amtVG MV, the HR system
must automatically take into account the allocated child-raising periods based on the child data entered.
A
VE07.21
Recording of periods to be deducted from the automatically determined child-raising periods
The HR system must enable the manual recording of periods that are to be deducted from the
automatically calculated child-raising periods (e.g. periods that are to be allocated to the other parent).
A
VE07.22
Determination of the child-raising supplement
The HR system must automatically calculate the child-raising allowance in accordance with § 50a
LBeamtVG MV, taking into account the maximum statutory salary rate.
A
VE07.23
Determination of the supplementary child-raising allowance
The HR system must automatically calculate the supplementary child-raising allowance in accordance
with Section 50b LBe amtVG MV, taking into account the maximum statutory salary rate.
A
VE07.24
Determination of the child supplement for widow's benefit
The HR system must automatically determine the child supplement to the widow's allowance in
accordance with § 50c LBeamtVG MV.
A
VE07.25
Determination of the supplementary care and childcare allowance
The HR system must automatically calculate the supplementary care and childcare allowance in
accordance with Section 50d LBeamtVG MV, taking into account the maximum statutory salary rate.
A
VE07.26
Temporary granting of supplements
The HR system must automatically determine the temporary granting of supplements in accordance with
Section 50e LBeamtVG MV, taking into account the maximum statutory salary rate.
A
VE07.27
Maintenance contribution for dismissed civil servants
The HR system must automatically determine the maintenance contribution for dismissed civil servants in
accordance with § 15 LBeamtVG MV.
A
VE07.28
Payments in the event of disappearance
In accordance with Section 29 LBeamtVG MV, the HR system must enable the automated calculation of
remuneration in the event of absence for personnel cases. The status "Missing" must be selectable for
personnel cases.
A
VE07.29
Transitional regulation
The HR system must observe the transitional provisions of Section 69e LBeamtVG MV when calculating all
pension payments.
A
VE07.30
Granting of discounts
The HR system must offer the processing department the option of daily deductions
on the supply as an advance payment.
A
13 December 2024 Page 192 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE07.31
Pension payments in accordance with the BeamtVG (federal law)
The HR system must support the automated calculation of pension benefits according to
§ 2 BeamtVG. All data required for these individual cases and relevant to accounting, in particular
-
Basic salary,
-
Level 1 family allowance,
-
other pensionable remuneration in accordance with salary law and
-
Benefits
must be able to be entered manually by the processing department.
A
VE07.32
Document creation for supply
The HR system must enable the processing department to prepare notifications for all pension payments
and for the increased pension rate, including the presentation of the calculation method and the
comparative calculations, including the creation of attachments.
-
on the determination of pensionable periods of service/office,
-
to the pension rate,
-
to the pension discount,
-
on the family allowance and differential amount in accordance with § 50 LBeamtVG MV (also as a
separate notification at the discretion of the processing department),
-
on the supplements in accordance with §§ 50a-50e LBeamtVG MV (also as a separate notification
at the discretion of the processing department),
-
on pension equalisation,
-
to the dormant amounts,
-
for surviving dependants' pensions and
-
for supply according to § 11 LMinG
make this possible. The notifications and attachments must be created after initial preparation by the
be customisable.
A
4.7.9.1.8 Accident insurance
If a member of staff suffers an occupational accident, they and their surviving dependants receive accident benefits in accordance
with Section 30 LBeamtVG MV. The HR system comprises
- the helplessness supplement (Section 34 (2) LBeamtVG MV)
- accident compensation,
- the accident pension,
- the maintenance contribution,
- accident survivors' benefits (accident widow's/widower's pension, accident widow's/widower's settlement, accident
orphan's pension and maintenance contribution),
- accident compensation and
- compensation in special cases.
The HR system does not include the reimbursement of material damage (§ 32 LBeamtVG MV) and medical procedures (§§ 33 and
34 Para. 1 LBeamtVG MV), as these are mapped via the LAF's specialised aid procedure.
The department in charge of personnel decides whether an occupational accident has occurred. It must therefore be possible to
record in the HR system for payroll accounting purposes that an occupational accident has occurred so that accident benefits can
be paid.
13 December 2024 Page 193 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE08.01
Recording of the occupational accident
The HR system must be able to handle the manual recording of
-
occupational accidents,
-
disability,
-
a particular danger to life (for § 37 LBeamtVG MV),
-
full disability (for § 38 LBeamtVG MV),
-
a percentage reduction in earning capacity (for § 38 LBeamtVG MV) and
-
the necessary data for relatives in the ascending line, e.g. name, address, bank details (for § 40
LBeamtVG MV)
enable.
A
VE08.02
Helplessness supplement
The HR system must be able to grant the helplessness supplement in accordance with § 34 Para. 2
LBeamtVG MV after the amount of the supplement has been recorded.
A
VE08.03
Calculation of accident compensation
The HR system must automatically calculate the accident compensation in accordance with Section 35
(1) LBeamtVG MV in addition to the salary and pension after manually recording the degree of the
consequences of the injury.
A
VE08.04
Allowance period for accident pension
In the event of incapacity to work as a result of a service accident, the HR system must automatically
determine the additional period in accordance with Section 36 (2) LBeamtVG MV and add this to the
pensionable service period.
A
VE08.05
Calculation of the accident pension
The HR system must automatically calculate the accident pension in accordance with § 36 Para. 3
LBeamtVG MV in conjunction with § 14a LBeamtVG MV, taking into account the minimum and maximum
percentage and the comparative calculation with the minimum pension.
A
VE08.06
Calculation of the increased accident pension
The HR system must automatically calculate the increased accident pension in accordance with § 37
LBeamtVG MV, taking into account the minimum salary groups.
A
VE08.07
Calculation of the maintenance contribution in the event of full disability
The HR system must pay the maintenance contribution in the event of full disability.
-
for a former civil servant/judge pursuant to section 38 para.
1 LBeamtVG MV and
-
for a former retired civil servant pursuant to section 38 para.
7 LBeamtVG MV
in accordance with § 38 Para. 2 No. 1 and Para. 4 LBeamtVG MV with a comparative calculation with the
minimum pension in accordance with § 38 Para. 5 LBeamtVG MV.
A
VE08.08
Calculation of the maintenance contribution in the event of a percentage reduction in earning capacity
The HR system must calculate the maintenance contribution in the event of a percentage reduction in
earning capacity.
-
for a former civil servant/judge pursuant to section 38 para.
1 LBeamtVG MV and
-
for a former retired civil servant pursuant to section 38 para.
7 LBeamtVG MV
in accordance with Section 38 (2) Nos. 1 and 2 and (4) LBeamtVG MV.
A
13 December 2024 Page 194 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE08.09
Exclusion of the maintenance contribution through the granting of retirement benefits
The HR system must automatically take into account that, in accordance with § 38 Para. 1 Sentence 2
LBeamtVG MV, no maintenance contribution is possible in accordance with § 38 LBeamtVG MV from the
time of receipt of retirement benefits in accordance with the LAltGG MV.
A
VE08.10
Calculation of the maintenance contribution for damage to an unborn child in the event of full
disability of the mother
The HR system must automatically calculate the maintenance contribution for injury to an unborn child
in the event of full disability of the mother in the amount of the minimum accident orphan's pension in
accordance with § 38a Para. 1 No. 1 LBeamtVG MV and depending on the age of the child in conjunction
with § 38a Para. 3 LBeamtVG MV.
A
VE08.11
Calculation of the maintenance contribution for damage to an unborn child in the event of a
percentage reduction in the mother's earning capacity
The HR system should calculate the maintenance contribution for damage to an unborn child in the
event of a percentage reduction in the mother's earning capacity in accordance with § 38a Para. 1 Nos. 1
and 2 LBeamtVG MV and depending on the age of the child in conjunction with § 38a Para. 3 LBeamtVG
MV.
B
VE08.12
Calculation of the maintenance contribution for damage to an unborn child The HR system should
calculate the partial and full suspension of the maintenance contribution in accordance with § 38a Para. 4
LBeamtVG MV after recording care costs in accordance with § 34 Para. 1 LBeamtVG MV.
B
VE08.13
Comparative calculation of maintenance contribution and orphan's benefit
According to § 38a Para. 5 LBeamtVG MV, the HR system should automatically carry out a comparative
calculation between the maintenance contributions according to § 38a LBeamtVG MV and the orphan's
pension according to § 24 LBeamtVG MV and use the higher amount.
B
VE08.14
Accident widow's/widower's pension based on the accident pension
The HR system must automatically calculate the accident widow's/widower's pension in accordance with
§ 39 Para. 1 Sentence 2 No. 1 LBeamtVG MV in conjunction with § 36 LBeamtVG MV, taking into account
the maximum limit in accordance with § 42 LBeamtVG MV.
A
VE08.15
Accident widow's/widower's pension on the basis of the increased accident retirement pension
The HR system must automatically calculate the accident widow's/widower's pension in accordance with
§ 39 Para. 1 Sentence 2 No. 1 LBeamtVG MV in conjunction with § 37 LBeamtVG MV, taking into account
the maximum limit in accordance with § 42 LBeamtVG MV.
A
VE08.16
Accident orphan's pension on the basis of the accident pension
The HR system must automatically calculate the accident orphan's pension in accordance with § 39 Para.
1 Sentence 2 No. 2 LBeamtVG MV in conjunction with §§ 36, 37 LBeamtVG MV, taking into account the
maximum limit in accordance with § 42 LBeamtVG MV.
A
VE08.17
Maintenance contribution for a relative in the ascending line
According to § 40 LBeamtVG MV, the HR system must automatically calculate the maintenance
contribution for a relative in the ascending line, taking into account the maximum limit according to § 42
LBeamtVG MV.
A
VE08.18
Maintenance contribution for several relatives in the ascending line
In accordance with § 40 LBeamtVG MV, the HR system is to distribute the maintenance contribution to
several relatives in the ascending line as personnel cases, taking into account the priority rule (parents
before grandparents) and the maximum limit in accordance with § 42 LBeamtVG
Split MV automatically.
B
13 December 2024 Page 195 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE08.19
Maintenance contribution in the amount of the widow's/widower's pension
In accordance with § 41 Para. 1 LBeamtVG MV, the HR system must automatically calculate the
maintenance contribution in the amount of the widow's/widower's pension.
A
VE08.20
Maintenance contribution in the amount of the orphan's allowance
In accordance with § 41 Para. 1 LBeamtVG MV, the HR system must automatically calculate the
maintenance contribution in the amount of the orphan's pension.
A
VE08.21
One-off accident compensation for civil servants/judges
The HR system must be able to determine the one-off accident compensation for civil servants/judges in
accordance with Section 43 (1) sentence 1 LBe amtVG MV.
A
VE08.22
One-off accident compensation to surviving dependants
The HR system must be able to determine the one-off accident compensation in accordance with § 43
Para. 2 LBeamtVG MV for the order of precedence of the surviving dependants specified in the standard.
A
VE08.23
One-off compensation for civil servants/judges The HR system must be able to determine the one-off
compensation for civil servants/judges in accordance with Section 43 (1) sentence 1 and (5) LBeamtVG
MV.
A
VE08.24
One-off compensation to surviving dependants
The HR system must be able to determine the one-off compensation in accordance with Section 43 (2) and
(6) LBeamtVG MV for the order of precedence of the surviving dependants specified in the standard.
A
VE08.25
Examination of the simultaneous existence of accident compensation and indemnification
According to § 43 Para. 7 LBeamtVG MV, the HR system should automatically check whether
compensation is to be determined in addition to accident compensation. In the case of a simultaneous
existence, the HR system only has to determine the compensation.
B
VE08.26
Offsetting of cash benefits from third parties
The HR system must enable the automated crediting of a recorded cash benefit from third parties in
accordance with § 46 Para. 4 LBeamtVG MV.
A
VE08.27
Offsetting compensation from accident insurance
In accordance with § 43 Para. 8 LBeamtVG MV, the HR system must enable the automated offsetting of a
recorded compensation from an accident insurance against the accident compensation.
A
VE08.28
Damage compensation
According to § 43a LBeamtVG MV, the HR system must enable compensation for material damage.
A
VE08.29
Accident pension for members of the state government and parliamentary state secretaries
The HR system must automatically calculate the accident pension in accordance with § 14 Para. 2 No. 2
LMinG and § 5 LParlG.
A
VE08.30
Accident survivors' benefits for members of the state government and parliamentary state secretaries
The HR system must provide accident survivors' benefits in accordance with § 14 para. 2 no. 3
LMinG and § 5 LParlG automatically.
A
13 December 2024 Page 196 from 366
13 december 2024
4.7.9.1.9 Transitional allowance and compensation
If civil servants, judges, members of the state government and parliamentary state secretaries leave the service or office, they
may receive a temporary transitional allowance. The HR system must be able to map and calculate these various transitional
allowances and make them payable for the temporary period.
Requirement
labelling
Requirement
Criterion
VE09.01
Calculation of the transitional allowance
The HR system must pay the transitional allowance in accordance with § 47 LBeamtVG MV in conjunction
with
§ The pension is calculated automatically in accordance with Section 67 (4) LBeamtVG MV, including the
period of employment/service and taking into account the maximum limit.
A
VE09.02
Payment of the transitional allowance
The HR system must enable the payment of the transitional allowance in accordance with § 47 Para. 4
LBeamtVG MV.
A
VE09.03
Exclusion of the transitional allowance
The HR system must take into account the exclusion of the transitional allowance in accordance with §
47 Para. 3 LBeamtVG MV and inform the processing department of this, e.g. when granting a
maintenance contribution in accordance with § 15 LBeamtVG MV.
A
VE09.04
Calculation of the transitional allowance for dismissed political civil servants
The HR system must automatically calculate the transitional allowance for dismissed political civil
servants in accordance with Section 47a LBeamtVG MV.
A
VE09.05
Payment of the transitional allowance for dismissed political civil servants
The HR system must enable the payment of the transitional allowance for dismissed civil servants in
accordance with §§ 47a Para. 2 and 3 LBeamtVG MV in conjunction with § 47 Para. 4 LBeamtVG MV.
A
VE09.06
Exclusion of the transitional allowance
The HR system must observe the exclusion of the transitional allowance in accordance with § 47a Para. 3
LBeamtVG MV in conjunction with § 47 Para. 3 LBeamtVG MV and inform the processing department of
this, e.g. when granting a maintenance contribution in accordance with § 15 LBeamtVG MV.
A
VE09.07
Calculation of compensation for special age limits
The HR system must be able to manually record the compensation for special age limits in accordance
with Section 48 (1) LBeamtVG MV.
A
VE09.08
Compensation for special age limits in addition to accident compensation and indemnity
The HR system should automatically take into account the exclusion of compensation in the case of
special age limits in accordance with § 48 Para. 1 Sentence 4 and Para. 3 LBeamtVG MV and inform the
processing department of this, e.g. when granting accident compensation in accordance with § 43
LBeamtVG MV during the determination process.
B
VE09.09
Calculation of the transitional allowance on the basis of official salaries
The HR system must calculate the transitional allowance in accordance with Section 12 LMinG, Section 5d
LMinG and Section 5 LParlG, including the period of employment/service and taking into account the
maximum
limit automatically.
A
13. December 2024 Page 197 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE09.10
Comparative calculation of transitional allowance on the basis of official salaries
The HR system must enable the comparative calculation of the transitional allowance in accordance with
Section 5d LMinG.
A
VE09.11
Payment of the transitional allowance on the basis of official salaries
The HR system must enable the payment of the transitional allowance in accordance with § 12 LMinG, §
5d LMinG and § 5 LParlG.
A
4.7.9.1.10 Reductions/recognisations of pension payments
The HR system must automate reductions and cancellations of pension payments. It must be possible to record the necessary
reduction amounts, maximum limits and fixed amounts. Where necessary, it must be possible to suspend reduction periods.
Requirement
labelling
Requirement
Criterion
VE10.01
Automated dynamisation of the reduction amount for pension equalisation - active civil servants/judges
The HR system must automatically calculate the reduction amount for active civil servants/judges in
accordance with Section 57 (2) LBeamtVG MV (for information purposes only, without deduction from the
salary). The HR system must hold the reduction amount for processing (in particular for the pension
information and for entry into the pension scheme).
A
VE10.02
Automated dynamisation of the reduction amount for pension equalisation - pension recipients
The HR system must automatically calculate the reduction amount in accordance with § 57 Para. 2
LBeamtVG MV for pension recipients. The HR system must take the reduction amount into account when
calculating remuneration.
A
VE10.03
Suspension of the reduction amount
The HR system must enable the full and partial manual suspension of the reduction amount. The reason
for suspension must be selectable by the administrator. The reasons for suspension must be provided with
keywords and result in particular from the exemplary list of legal bases from Chapter 2.4 (e.g. application
under § 35 VersAusglG, application under § 37 VersAusglG, lump sum payment under § 58 LBeamtVG MV).
A
VE10.04
Suspension of the reduction
The HR system must allow the administrator to fully or partially suspend the reduction in accordance with
§ 33 VersAusglG (static amount) and § 35 VersAusglG (discontinuation upon reaching the standard
retirement age; automated adjustment of the amount analogue to the statutory retirement age).
pension adjustment).
A
13. December 2024 Page 198 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE10.05
Disclosure of pension equalisation on the salary notification
The HR system must
-
the reduction amount pursuant to Section 57 (2) LBeamtVG MV,
-
the suspension of the reduction amount and
-
the suspension of the reduction
on the remuneration statement.
A
VE10.06
Calculation of the capital amount
The HR system must manually record the capital amount to avoid the reduction in pension benefits in
accordance with Section 58 LBeamtVG MV.
-
of the end of the marriage,
-
the date of retirement and
-
of the amount to be capitalised
and automatically calculated taking into account the dynamisation in accordance with § 70 LBeamtVG MV.
A
VE10.07
Reduction of pension payments due to culpable breach of the duty of disclosure (§ 62 LBeamtVG MV)
According to § 62 Para. 3 LBeamtVG MV, the HR system must enable the manual recording of a reduction
percentage and a reduction amount in the event of a culpable breach of the notification obligation. The
HR system must then automatically reduce the pension payments by the corresponding amount.
A
VE10.08
Reduction of pension according to § 13 LDG MV
In accordance with Section 13 LDG MV, the HR system must automatically reduce the pension to the
appropriate extent on the basis of a manually calculated reduction percentage, taking into account the
maximum reduction percentage.
A
VE10.09
Limitation of the reduction of the pension according to § 13 LDG MV
In accordance with Section 13 LDG MV, the HR system must allow the reduction of the pension to be
limited by manually entering a period (taking into account the maximum period). The reduction must end
automatically at the end of the fixed-term period.
A
VE10.10
Maintenance contribution until a pension is granted
The HR system must automatically calculate the maintenance contribution until a pension is granted in
accordance with Section 14 (2) LDG MV. The basis for the calculation is the pension at the time the
decision becomes final (static amount).
A
VE10.11
Limitation of the maintenance contribution until a pension is granted
The HR system must automatically limit the maintenance contribution to 6 months until a pension is
granted in accordance with § 14 Para. 2 LDG MV. Payment of the maintenance contribution must end
automatically at the end of the time limit period. The HR system must make it possible for the processing
department to manually terminate the payment of the maintenance contribution early.
A
VE10.12
Retention of pension in the event of prospective withdrawal of pension
The HR system must enable the automated withholding of the pension in accordance with Section 41 LDG
MV after manual entry of a percentage and amount (taking into account the
the maximum percentage rate).
A
13 December 2024 Page 199 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE10.13
Back payment of withheld remuneration
In accordance with Section 41 (4) LDG MV, the HR system must deduct withheld remuneration after
automatically offsetting income and deducting costs for disciplinary proceedings.
and pay back fines.
A
4.7.9.1.11 Suspension regulations
Various other incomes may have to be taken into account when calculating pension payments. Income that can be offset against
pension payments in accordance with the LBeamtVG MV and the LMinG MV is as follows:
- other pension benefits,
- Retirement benefits,
- Pensions,
- Income from employment in the public sector or equivalent income,
- Earned income from employment or activity outside the public sector,
- earned and replacement income and
- Supply from intergovernmental and supranational use.
As a result, the pension payments are partially suspended. In this context, it is possible that several incomes are to be taken into account and
several suspension regulations apply simultaneously.
Requirement
labelling
Requirement
Criterion
VE11.01
Recording of dormant amounts
The HR system must enable the recording of suspension amounts for all suspension regulations.
A
VE11.02
Multiple pensions - classification
The HR system must implement the classification of pension payments to be credited in accordance with
Section 54 (1) and (4) LBeamtVG MV.
A
VE11.03
Multiple pension payments - linking
The HR system must enable the manual linking of the various pension benefits in the case of Section 54
(1) and (4) LBeamtVG MV by the administrator.
A
VE11.04
Multiple pension payments - calculation of the retirement amount
The HR system must automatically calculate the suspension amount for several pension payments in
accordance with Section 54 LBeamtVG MV, taking into account the minimum authorisation.
A
VE11.05
Multiple pension payments - Recording of pension payments
The HR system must enable the manual recording of pension benefits to be credited in accordance with
Section 54 (1) sentence 1 nos. 1-4 LBeamtVG MV.
A
VE11.06
Multiple pension payments - recording the maximum limit
The HR system must facilitate the manual recording of percentages and amounts.
maximum limit and the percentage pension reduction.
A
13 December 2024 Page 200 from 366
13 december 2024
Requirements
labelling
Requirement
Criterion
VE11.07
Multiple pension payments - calculation of the maximum limit pursuant to Section 54 (2) LBe amtVG
MV
The HR system must automatically calculate the maximum limit in accordance with Section 54 (2)
LBeamtVG MV, taking into account the pension deduction.
A
VE11.08
Multiple pensions - calculation of the maximum limit and the minimum allowance
The HR system must be set up in the event of a combination of pension and widow's pension.
-
the maximum limit pursuant to Section 54 (4) LBeamtVG MV, taking into account the pension
discount,
-
the minimum authorisation pursuant to Section 54 (4) sentence 2 LBeamtVG MV and
-
automatically determine the minimum authorisation in accordance
with Section 54 (5) LBeamtVG MV.
A
VE11.09
Pension - Recording of the pension amount
The HR system must enable the manual recording of the existence of pension entitlements and pension
amounts.
A
VE11.10
Pensions - Calculation of the pensionable amount
The HR system must automatically calculate the suspension amount when pension payments coincide
with a pension to be credited and several pensions to be credited in accordance with Section 55
LBeamtVG MV, taking into account the minimum authorisation in accordance with Section 55 (7)
LBeamtVG MV and the maximum limit (including consideration of periods in accordance with Section
12a LBeamtVG MV).
A
VE11.11
Pensions - Extended suspension scheme
The HR system must automatically implement the extended suspension regulation in accordance with
Section 14 (5) LBeamtVG MV.
A
VE11.12
Pensions - Recording of a maximum limit
The HR system must make it possible to record a maximum pension limit.
A
VE11.13
Pensions - participation in the automated pension information procedure
The HR system must enable a decision to be made by the processing department on participation in the
automated pension information procedure for each personnel case.
The prerequisite for participation in the automated pension exchange procedure is the manual entry of
the postal account number (PAN) including the social security number of the beneficiary.
A
VE11.14
Pensions - Recognition of pension increases/decreases due to pension equalisation
The HR system must enable pension increases/decreases due to pension equalisation to be recorded.
A
VE11.15
Pensions - deduction of non-creditable pension components
When calculating the suspended amount, the HR system must automatically determine the deduction of
non-creditable pension components (e.g. voluntary contributions, pension component from higher
insurance, child allowance for orphan's pension).
A
VE11.16
Pensions - accident compensation for pensions from statutory accident insurance
When calculating the suspension amount, the HR system must take into account that after
§ 55 para. 1 sentence 2 no. 3 LBeamtVG MV, accident compensation for pensions from the statutory
statutory accident insurance is not taken into account.
A
13 December 2024 Page 201 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE11.17
Pensions - Determination of capital amounts (1/2)
The HR system must automatically determine the annuitisation of the severance payment, the
reimbursement of contributions and other capital amounts when calculating the suspended amount.
A
VE11.18
Pensions - Determination of capital amounts (2/2)
The HR system must automatically reduce the total amount of the pension by 40% if the requirements of
Art. 2 § 2 Para. 3 HStruktG are met.
A
VE11.19
Income from employment and income replacement - Recording of income
The HR system must enable the manual recording of earned and replacement income.
A
VE11.20
Earned and replacement income - classification of the type of income The HR system must enable the
classification of the type of income (e.g. utilisation income, other earned income, replacement income,
combination of utilisation and earned (replacement) income).
A
VE11.21
Earned income and income in lieu of earnings - Recognition of an income-related expense allowance
The HR system must enable the manual recording of a lump sum for income-related expenses as well as
the amount of income without deducting the lump sum for income-related expenses. In addition, it must
be possible to manually deduct the lump sum for income-related expenses when recognising earned
income.
A
VE11.22
Income from gainful employment and income in lieu of earnings - calculation of the suspended amount
The HR system must calculate the amount to be suspended if pension payments coincide with earned
income and income in lieu of earnings in accordance with § 53 LBeamtVG MV
-
with deduction of the flat-rate income-related expense allowance (including automated
adjustment of the flat-rate income-related expense allowance in the event of changes to the law),
-
Observance of the maximum limit (different maximum limit depending on the reason for
disability),
-
the minimum authorisation pursuant to § 53 (5) and (6) LBeamtVG MV and
-
The special regulations pursuant to Section 53 (9) and (10) LBeamtVG MV are
calculated automatically.
A
VE11.23
Income from gainful employment and income in lieu of gainful employment - elimination of income
imputation The HR system must automatically eliminate income imputation (except in the case of
income from employment) upon reaching the gradually increased standard retirement age (Section 53
(8) LBeamtVG MV).
A
VE11.24
Income from gainful employment and income in lieu of gainful employment - recording of a maximum
limit
The HR system must enable the manual recording of a maximum limit in accordance with Section 107a
LBe amtVG MV.
A
VE11.25
Assumption of income for dormancy arrangements
The HR system must automatically transfer income from another process area (e.g. salary/remuneration)
to the benefits process area.
A
13 December 2024 Page 202 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE11.26
Earned and replacement income - same employer, same accounting system
The HR system must take income into account automatically by linking the various entitlements through
the HR system if the income entitlement is based on a legal relationship with the same
employer/principal and the income to be taken into account is calculated via the HR system.
A
VE11.27
Earned and replacement income - different employer, same accounting system
The HR system must enable the manual recording and subsequent automated consideration of
chargeable income, insofar as the income claim is based on a legal relationship with another
employer/service provider that is also calculated via the HR system. The amount of income must be
notified in an appropriate manner (e.g. by means of settlement notifications) when it is recorded for the
first time and whenever the amount is changed.
A
VE11.28
Earned and replacement income - different employer, different accounting system
The HR system must enable the manual recording and subsequent automated consideration of
chargeable income in cases where the entitlement to income is based on a legal relationship with
another employer/service provider that is not accounted for via the same system.
A
VE11.29
Crediting of old-age pension and surviving dependants' pension
The HR system must
-
on the basis of the automated transfer of data available in the HR system for retirement benefits
or survivors' pensions and
-
calculate the suspension amount on the basis of the manual recording of comparable retirement
benefits in accordance with § 53a LBeamtVG MV.
A
VE11.30
Coincidence of transitional allowance with income from employment and income compensation
Pursuant to § 47 (5) and § 47a (4) LBeamtVG MV, the HR system must ensure the transfer
The amount of income from gainful employment and income in lieu of earnings may be suspended.
A
13 December 2024 Page 203 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE11.31
Coincidence of transitional allowance and pension with other income according to the LMinG MV
In the event of a combination of transitional allowance pursuant to Section 12 LMinG MV and pension
pursuant to Section 13 LMinG MV with other income pursuant to Section 17 LMinG MV, the HR system
must be notified to the administrative office.
-
the recognition of imputed income,
-
the classification of the type of income, in particular
•
Income from employment in the public service within the meaning of § 53 LBeamtVG MV,
remuneration from another official position,
•
Earned income from employment or activity outside and within the public service (§ 17 Para.
2 LMinG MV, only for transfer payments),
•
Pension based on an employment relationship as a civil servant or judge or a similar pension
or a pension based on another official relationship (Section 17 (7) LMinG MV)
-
and the recording of a maximum limit.
The HR system must automatically calculate the suspension amount on the basis of this data.
A
VE11.32
Coincidence of pension payments under the LMinG MV with pensions
The HR system must automatically calculate the suspension amount when pension payments coincide
with pensions in accordance with § 17 Para. 9 LMinG MV by applying § 55 LBeamtVG MV accordingly.
A
VE11.33
Coincidence of pension under the LMinG MV with income from employment
The HR system must be set up in the event of a combination of pension pursuant to Section 13 LMinG MV
and income from employment pursuant to Section 17 (3) and (4) LMinG MV.
-
enable the income to be recognised,
-
enable the classification of the type of income, in particular
•
Income from employment in the public sector within the meaning of the
§ 53 LBeamtVG MV,
•
Remuneration from another official relationship,
-
enable the recording of a maximum limit,
-
Calculate the maximum limit automatically
and automatically calculate the income to be credited.
A
VE11.34
Coincidence of pension under the LMinG MV with earned income from an activity outside the public
sector
The HR system must be set up in accordance with Section 17 (5) LMinG MV if a pension pursuant to
Section 13 LMinG MV coincides with earned income from an activity outside the public sector.
-
enable the income to be recognised,
-
enable the classification of the type of income, in particular
•
Income from self-employment,
•
Income from employment,
•
Income from commercial operations,
•
Income from agriculture and forestry,
-
enable the recording of a maximum limit,
-
Calculate the maximum limit automatically
and automatically calculate the income to be credited. The HR system must
automatically terminate the crediting at the end of the month in which the standard retirement age
according to §§ 35, 235 SGB VI is reached.
A
13 December 2024 Page 204 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE11.35
Coincidence of pension under the LMinG MV with other pension benefits
The HR system must be set up in accordance with Section 17 (7) LMinG MV when a pension pursuant to
Section 13 LMinG MV coincides with other pension benefits.
-
enable the pension/benefit to be recognised,
-
enable classification, in particular
•
Pension based on employment as a civil servant or judge,
•
similar supply,
•
Pension on the basis of another official relationship,
-
enable the recording of a maximum limit,
-
Calculate the maximum limit automatically
and automatically calculate the income to be credited. The HR system must automatically terminate the
imputation at the end of the month in which the standard retirement age pursuant to Sections 35, 235
SGB VI is reached.
A
VE11.36
Coincidence of surviving dependants' pensions under the LMinG MV with other income
The HR system must ensure that survivors' benefits are paid in accordance with
§ Section 15 LMinG MV with other income pursuant to Section 17 (11) LMinG MV
-
enable the pension/benefit to be recognised,
-
enable classification, in particular
•
Pension based on employment as a civil servant or judge,
•
similar supply,
•
Pension on the basis of another official relationship,
•
Survivors' benefits,
•
Pensions,
-
enable the recording of a maximum limit,
-
Calculate the maximum limit automatically
and automatically calculate the income to be credited. The HR system must automatically terminate the
imputation at the end of the month in which the standard retirement age pursuant to Sections 35, 235
SGB VI is reached.
A
VE11.37
Multiple rest regulations
In accordance with Sections 53, 53a, 54, 55 and 57 LBeamtVG MV in conjunction with Section 14 (5)
LBeamtVG MV and Section 17 LMinG MV, the HR system must automatically calculate the multiple
retirement regulations and automatically determine the retirement amount.
A
VE11.38
Supplements according to §§ 50a-50e LBeamtVG MV
The HR system must automatically take into account the supplements according to §§ 50a-50e LBeamtVG
MV in the suspension regulations.
A
4.7.9.1.12 Gross calculation of retirement benefit
If a civil servant or judge is dismissed at their own request, they have the option of declaring that they wish to receive retirement
benefits under the LAltGG MV instead of supplementary insurance. The declaration is submitted by the employee to the LAF via
the department in charge of personnel. The LAF checks whether there is an entitlement to old-age benefit or whether subsequent
insurance is required. As a result, the claim to retirement benefit is rejected or, if the requirements are met, the retirement
benefit-eligible remuneration and the retirement benefit-eligible periods of service are determined.
If a person entitled to an old-age pension reaches a special age limit or the standard age limit, they are entitled to apply for an
old-age pension. In this respect, the HR system must
13. December 2024 Page 205 of 366
13 december 2024
Calculation and documentation of the age limits. The calculation of the age-eligible remuneration is generally based on the
determination, whereby a manual correction must be possible. The retirement benefits are then dynamised. The calculation of
the period of service eligible for the old-age pension is based on the CV data (see chapters 4.1.4 and 4.7.5 (CV data)). The old-age
pension rate is determined on this basis. The HR system must calculate the gross amount of the old-age pension, taking into
account any supplements for bringing up children and care, the possible coincidence of old-age pension with various other
incomes and any pension equalisation. As a result, the HR system must issue an optional old-age allowance recipient's certificate
in addition to notifications of the amount of the allowance and enable the payment of the allowance both retrospectively and for
a limited period and, if necessary, with payment on account. It must be possible to enter a later loss of entitlement to retirement
benefits.
If the person entitled to an old-age pension dies, any surviving dependants are entitled to a survivor's pension. The calculation is
based on the calculation of the old-age pension. If no old-age pension was granted before the survivor's pension was awarded,
the HR system must calculate this fictitiously in each case. If necessary, it must be possible to include descendants who are born
after death, for example, in the HR system.
Irrespective of this, it should be possible to provide information on retirement benefits. The data required for this must, if
possible, be taken from the salary, pension and retirement benefit task and be customisable. The HR system must be able to
extrapolate the periods of service. The HR system must be able to generate retirement benefit information from the results. It
must be possible to reuse this for further retirement benefit information and for granting benefits. If civil servants and judges
wish to make a comparison between possible pension and retirement benefit payments, the HR system must be able to provide a
combined pension and retirement benefit statement.
The calculation of the old-age pension and the surviving dependants' pension is modelled on the basis for calculating the civil
servants' pension, which is why the requirements in this chapter are to be understood as a variation of the requirements for the
civil servants' pension.
As the LAltGG MV has only been in place since 1 June 2021, few cases are currently being processed. By 11 March 2024, 27
applications for old-age benefits had been submitted. In 21 cases, an entitlement to old-age benefit was established. In addition,
two appeals and one lawsuit are pending. Old-age pension or survivor's pension is not yet being granted/paid.
The overarching requirements from Chapters 4.7.10.1 (Overarching technical requirements: Gross calculation - General
calculation of remuneration) and 4.7.10.4 (General technical requirements: Gross calculation - Other reference components)
apply.
13 December 2024 Page 206 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.01
Determination of the retirement pension - data collection
In addition to the general data of the person entitled to the old-age pension (e.g. basic information data),
the HR system must make the following data in particular available for the determination of the old-age
pension:
-
Start of the retirement pension entitlement according to § 3 para. 2 LAltGG MV
-
Start of the possible granting of old-age pension and surviving dependants' old-age pension from the
standard retirement age pursuant to Section 3 (3) sentence 1 LAltGG MV
-
Group of persons (e.g. teachers, professors, law enforcement officers, judges, other civil servants,
career) and job title, unless this is automatically determined by linking the salary payment data. civil
servants, career path) and job title, unless this is automatically derived from the salary payment data
by means of a link
-
different address data.
A
VE12.02
Granting of the old-age pension - data collection
In addition to the general data of the person entitled to the old-age pension and survivors' pension (e.g.
basic information data, bank details, marital status, tax characteristics, etc.), the HR system must be able to
record the following data in particular:
-
Start of the retirement pension entitlement according to § 3 para. 2 LAltGG MV
-
Start of the granting of old-age pension and survivor's pension
-
Group of persons (e.g. teachers, professors, law enforcement officers, judges, other civil servants,
career) and job title, unless this is automatically determined by linking the salary payment data. civil
servants, career) and job title, unless this is automatically derived from the salary payment data by
means of a link
-
Existence of a reason for a special age limit with designation of the reason
-
different address data
-
different bank details.
A
VE12.03
Calculation of the retirement pension
TheHR system must make it possible to determine the pensionable pay, the pensionable service period and
the granting of benefits in accordance with the LAltGG MV.
A
VE12.04
Examination of the claim
As part of a determination process, the HR system must automatically check whether there is an
entitlement to old-age pension or survivors' old-age pension pursuant to Section 1 (1) and (5) and Section 3
(1) LAltGG MV. If necessary, the HR system must request any missing information from the LAF case
handler or from the office case handler (e.g. fulfilment of the requirements under § 1 para. 1 sentence 2
LAltGG MV). The HR system must provide the case handler with a corresponding specific indication during
the determination process.
A
VE12.05
Transfer for subsequent insurance (1/2)
The HR system should enable information to be passed on to the person responsible for subsequent
insurance, irrespective of the decision to reject/recognise an old-age benefit claim.
B
VE12.06
Passing on for subsequent insurance (2/2)
The HR system should automatically pass on the task for subsequent insurance via task control if the
employee is not entitled to retirement benefits.
B
13 December 2024 Page 207 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.07
Determination of the pensionable salary
The HR system must use the available data to automatically calculate the remuneration subject to
retirement benefits on the basis of
-
of the basic salary under salary law,
-
the other pensionable remuneration and
-
of the benefits under salary law in accordance with § 5
LAltGG MV.
In particular, the HR system must
-
take into account the full remuneration, even if, for example, part-time employment exists and
-
take the penultimate salary group into account if the relevant salary group does not correspond to
the starting salary group and has not been received for at least two years.
A
VE12.08
Dynamisation of remuneration eligible for retirement benefits
The HR system must dynamise the retirement benefits in accordance with Section 7 (4) LAltGG MV.
A
VE12.09
Manual correction of remuneration eligible for age-related benefits
The HR system must make it possible for the administrator to manually change the remuneration eligible
for the old-age pension. Changing means, in particular, adding and removing data and the option of
adjusting the amount.
A
VE12.10
Examination of the period of service eligible for retirement benefits
The HR system must make it easier for the administrator to evaluate the CV data.
z. For example, for the determination of the retirement pension rate, it is possible that in accordance with
Section 6 LAltGG MV
-
the working hours,
-
Times that are equivalent to working hours and
-
Periods that qualify as age-eligible
can be manually defined as single, pro rata (fraction and percentage) and not eligible for age-related
benefits.
The HR system must enable the LAF clerk and the department clerk to enter missing data.
A
VE12.11
Examination of the period of service eligible for old-age pension - rules (1/2)
The HR system must automatically evaluate the periods of service eligible for age-related pay on the basis
of statutory rules and rules specified by the employer and pre-assign the corresponding fields; this
automated evaluation of the periods must be able to be changed manually by the administrator.
A
VE12.11a
Examination of the period of service eligible for old-age pension - rules (2/2)
It should be possible for the centralised specialist administration to adapt the set of rules for the
valuation of service eligible for retirement benefits in accordance with VE12.11.
B
VE12.12
Calculation and documentation of age limits
The HR system must support the calculation and documentation of the various age limits in accordance with
Section 3 (3) LAltGG MV.
In particular, the HR system must allow the entry of a severe disability, a partial/full reduction in earning
capacity or an occupational disability through
enable processing.
A
13 December 2024 Page 208 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.13
Task management in the event of full/partial reduction in earning capacity or occupational disability The HR
system should support the determination in accordance with Section 3 (4) in conjunction with (3) sentence
2 no. 3-5 LAltGG MV as to whether there is a full/partial reduction in earning capacity or occupational
disability, e.g. by means of a checklist.
B
VE12.14
Recording and changing the retirement benefit rate
The HR system must make it possible to record and change the retirement benefit rate.
A
VE12.15
Determination of the old-age pension rate
The HR system must automatically determine the retirement pension rate in accordance with § 7 LAltGG
MV. In particular, the HR system must
-
The amount pursuant to § 7 para. 1 LAltGG MV,
-
the reduction pursuant to Section 7 (2) and (3) LAltGG MV and
-
the settlement pursuant to Section 7 (5) LAltGG MV
and document and observe the maximum old-age pension rate in accordance with § 7 Para. 1 LAltGG MV.
If necessary, the HR system must request any missing information from the processing department (e.g.
pension entitlement).
A
VE12.16
Increase in retirement benefit
The HR system must take account of the increase in retirement and survivors' pensions by
-
Child-rearing allowances,
-
Supplementary child-raising allowances,
-
Child supplements to widow's allowance,
-
Supplementary care allowances and
-
Supplementary childcare allowances
in accordance with § 8 LAltGG MV.
A
VE12.17
Coincidence of old-age pension, widow's pension and widower's pension with earned or replacement
income (1/2)
The HR system must be able to automatically calculate the maximum limits in accordance with Section 11
(2) LAltGG MV.
A
VE12.18
Coincidence of old-age pension, widow's pension and widower's pension with earned or replacement
income (2/2)
The HR system must automatically calculate the suspension amount when old-age pension, widow's old-
age allowance and widower's old-age allowance coincide with income from employment or income
replacement in accordance with Section 11 (1) LAltGG MV if income from employment or income
replacement is entered manually, including the type of income and any relevant income-related expenses
by the LAF processing function.
A
VE12.19
Coincidence of old-age and survivors' pensions with pensions (1/2) The HR system must be able to
automatically calculate the maximum limits in accordance with Section 12 (1) LAltGG MV in conjunction
with Section 55 (1) to (5) and (8) LBeamtVG MV.
A
VE12.20
Coincidence of old-age pension and survivors' old-age pension with pensions (2/2) If pensions are entered
manually by the LAF processing department, the HR system must automatically calculate the suspension
amount when old-age pension and survivors' old-age pension coincide with pensions in accordance with §
12 Para. 1 LAltGG MV in conjunction with § 55 Para. 1 to 5 and 8 LBeamtVG MV, taking into account § 12
Para. 2 LAltGG MV. Pension entitlements that were only acquired after the dismissal from the employment
relationship justifying the entitlement to a retirement pension are to be calculated in accordance with § 12 para.
2 LAltGG MV.
§ Section 12 (1) no. 1 LAltGG MV is exempt from offsetting.
A
13 December 2024 Page 209 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.21
Coincidence of old-age pension and survivors' pension with pensions - pension information procedure
The HR system must enable the automated processing of the pension data provided and its amendment via
the pension information procedure using the ST01.09 interface (see SS01.05) for the calculation of the
suspension amount when old-age pension and survivors' old-age pension coincide with pensions.
A
VE12.22
Coincidence of old-age pension and survivor's pension with pension from interstate or supranational use
(1/2)
The HR system must be able to automatically calculate the maximum limits in accordance with Section 13
LAltGG MV in conjunction with Section 56 LBeamtVG MV.
A
VE12.23
Coincidence of old-age pension and survivor's pension with pension from interstate or supranational use
(2/2)
If pension entitlements from interstate or supranational use are entered manually by the LAF processing
department, the HR system must automatically calculate the amount to be suspended when old-age
pension and survivors' pension coincide with pension entitlements from interstate or supranational use in
accordance with § 13 LAltGG MV in conjunction with § 56 LBeamtVG MV, taking into account § 13 sentence
2 LAltGG MV. Pursuant to Section 13 LAltGG MV, pension entitlements that were only acquired after the
dismissal from the employment relationship giving rise to the entitlement to a retirement pension are
excluded from the calculation.
A
VE12.24
Fixed retirement benefit
The HR system must enable the manual recording of all types of retirement benefits.
-
of a fixed amount,
-
an associated designation and
-
of an associated legal basis.
A
VE12.25
Automated decision creation
The HR system must enable the processing department to prepare notifications of benefits in accordance
with the LAltGG MV, including the presentation of the calculation method and the comparative
calculations, including the relevant annexes. Relevant attachments are in particular the attachment
-
on the determination of the periods of service eligible for retirement benefits, including justification,
-
on the old-age pension rate,
-
on the reduction in accordance with Section 7 (2) and (3) LAltGG MV,
-
on supplements for child-raising and care,
-
on pension equalisation,
-
on dormancy amounts and
-
on the surviving dependants' pension.
The notices and attachments must be customisable after initial creation by the administrator.
A
VE12.26
Loss of entitlement to retirement benefit
The HR system must enable the LAF processing department to enter the partial or full loss of entitlement to
retirement benefits in accordance with Section 4 LAltGG MV.
A
VE12.27
Verification of receipt of the application for benefits
Upon receipt of an application for retirement benefits, the HR system should automatically carry out a
comparison with the requirements under Section 3 (3) sentence 1 or sentence 2 LAltGG MV.
and inform the processing department of the inspection result.
B
13 December 2024 Page 210 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.28
Retroactive granting of benefits (1/2)
The HR system must allow benefits to be granted retroactively in accordance with Section 10 (3) sentence 2
LAltGG MV within the retroactive calculation depth.
A
VE12.29
Retroactive granting of benefits (2/2)
The HR system must notify the LAF case processing department if benefits are granted more than 3 months
after the conditions under Section 3 (3) sentence 1 or sentence 2 LAltGG MV have been met.
A
VE12.30
Survivor's pension for the month of death
The HR system must enable the granting of survivor's pension for the month of death in accordance with § 9
Para. 2 LAltGG MV.
A
VE12.31
Calculation of survivor's pension
The HR system must provide the surviving dependants' pension
-
Widow's pension/widower's pension in accordance with § 9 para. 3 LAltGG MV,
-
Widow's/widower's settlement in accordance with § 9 para. 4 LAltGG MV and
-
Orphan's pension in accordance with § 9 para. 5 LAltGG MV
automatically in accordance with Section 9 (6) and (7) LAltGG MV. The HR system must request the
necessary missing information from the processing department (e.g. existence of a pension marriage).
A
VE12.32
Fictitious calculation for survivor's pension
In the event that the person entitled to old-age benefit dies before old-age benefit is paid, the HR system
must notionally calculate the old-age benefit taking into account the actual circumstances and document it
for the granting of survivors' old-age benefit.
A
VE12.33
Retirement benefit information - data transfer and calculation (1/2)
The HR system must enable the processing department to calculate notional retirement benefits (retirement
benefit information).
A
VE12.34
Retirement benefit information - data transfer and calculation (2/2)
The HR system must use the necessary data stored in the salary, pension and retirement benefit task when
providing retirement benefit information, in particular
-
the pensionable or old-age pensionable remuneration,
-
the pensionable periods of previous service and periods of service or periods of service eligible for
retirement benefits,
-
the dynamised reduction amount pursuant to § 57 LBeamtVG MV or § 14 LAltGG MV and
-
take over the pension/supplementary pension
amounts for the information.
A
VE12.35
Combined preparation of pension and old-age benefit information
The HR system must enable the processing department to create a combined pension and retirement
benefit statement.
A
VE12.36
Retirement benefit information - extrapolation of periods of service up to a point in time (1/2)
The HR system must automatically record the periods of service for retirement benefit information up to
at a time of your choice (day of discharge).
A
13 December 2024 Page 211 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE12.37
Retirement benefit information - extrapolation of periods of service up to a point in time (2/2) The HR
system must allow the administrator to choose whether the periods of service are to be supplemented
according to the current scope of employment of the employee, full-time or at a part-time ratio that can be
entered (fraction, percentage, decimal number).
A
VE12.38
Retirement benefit information - adjustment of data
The HR system must enable the case handler to change and supplement all data relevant to the calculation
in the old-age allowance task when providing information on old-age allowance.
The HR system must make it possible to change the scope of employment for definable periods and
remuneration in particular.
The HR system must enable the manual addition of further income and pensions/supplementary benefits
in addition to the notional retirement benefits.
A
VE12.39
Old-age benefit information - Preparation of old-age benefit information
The HR system must automatically attach the relevant documents (in particular remuneration eligible for
retirement benefit, periods of service and retirement benefit rate) when the retirement benefit
information is created.
A
VE12.40
Retirement benefit information - reuse of data
The HR system must make it possible for all data relating to an old-age allowance claim (in particular the
periods of service eligible for old-age allowance) to be used as a data basis for a new old-age allowance
claim and for the granting of benefits.
A
VE12.41
Consideration of pension equalisation
The HR system must automatically recognise reductions in retirement and survivors' pensions due to pension
equalisation in accordance with Section 14 LAltGG MV.
matised.
A
4.7.9.2
Net calculation of pension and retirement benefit
The overarching requirements from sections 4.7.10.9 (Overarching technical requirements: Net calculation - Tax deductions),
4.7.10.100 (Overarching technical requirements: Net calculation - Contributions to supplementary pension schemes), 4.7.10.110
(Cross-cutting functional requirements: Net calculation - Riester pension scheme) and 4.7.10.120 (General technical
requirements: Net calculation - Advances) apply.
4.7.9.2.1 Social security pension and retirement benefits
Social security contributions must be deducted from the gross salary subject to social security contributions, e.g. for surviving
dependants. Contributions are paid via the paying agent notification procedure.
The overarching requirements from section 4.7.10.8 (Overarching technical requirements: Net calculation - social insurance)
apply.
13. December 2024 Page 212 from 366
13 december 2024
Requirement labelling
Requirement
Criterion
VE13.01
Collection of necessary data for the imprest reporting procedure
The HR system must be able to record the data required for the imprest reporting procedure, in
particular
-
of the contribution groups for health/nursing care insurance stored in the HR system,
-
the health insurance companies via the key,
-
the premium surcharge or premium discount for long-term care insurance,
-
the national insurance number,
-
the membership number of the health insurance fund,
-
the file number,
-
the maximum pension or old-age pension that is subject to contributions (VBmax),
-
the adjustments to VBmax,
-
the change notifications of the paying agent and
-
enable multiple
purchases.
A
VE13.02
Classification
The HR system must offer the central specialist administration the option of labelling all pay
components in the HR system with corresponding characteristics with regard to their treatment in
the automated calculation of social security contributions (classification).
A
VE13.03
Status groups
The HR system should be able to differentiate between the following status groups in particular for the
calculation:
-
non-contributory pension/retirement benefit recipient (no contribution deduction notification
of the KV/PV gross amount to the health insurance fund via the paying agent notification
procedure),
-
Obligatory pension/retirement benefit recipient, full contribution without checking the lower
contribution limit,
-
Obligatory pension/retirement benefit recipient, full contribution with review of the lower
contribution limit,
-
non-contributory pension/retirement benefit recipient,
-
Insurance obligation not yet checked - no contribution,
-
Multiple purchases.
A
VE13.04
Data traffic in the direction of the health insurance company
The HR system must enable data transfer to the health insurance fund via the ITSG-certified interface
ST01.43 Paying agent reporting procedure (ZMV) (see SS01.04), e.g. for the electronic contribution
statement, the contribution statement, the paying agent, notification of changes in the amount of
pension/retirement benefits.
A
VE13.05
Data traffic from the direction of the health insurance company
The HR system must enable data traffic from the health insurance fund via the ITSG-certified interface
ST01.43 Paying agency reporting procedure (ZMV) (see SS01.04), e.g. the confirmation or change of
contribution groups, the specification of the VBmax in the pension/retirement benefit case. The HR
system must automatically store the incoming data in the personnel case.
A
VE13.06
Calculation of statutory health and long-term care insurance contributions The HR system must
calculate the statutory health and long-term care insurance contributions for compulsorily insured
pension/retirement benefit recipients.
A
13 December 2024 Page 213 from 366
13 december 2024
Requirement labelling
Requirement
Criterion
VE13.07
Observance of the minimum lower limit in the calculation
The HR system must automatically observe the monthly minimum threshold in accordance with
Section 229 SGB V when calculating contributions to statutory health and long-term care insurance
for compulsorily insured pension/retirement benefit recipients.
A
VE13.08
Observance of the maximum pension/retirement benefit payment subject to contributions in the
calculation
When calculating the statutory health and long-term care insurance contributions for compulsorily
insured pension/retirement benefit recipients, the HR system must automatically take into account
the maximum pension/retirement benefit amount subject to contributions.
A
VE13.09
Payment of contributions per health insurance fund in one sum
The HR system must be able to pay the contributions in one lump sum on the respective due date
using the electronic contribution statements for each health insurance fund.
A
VE13.10
Payment of contributions via ZMV
The HR system must enable the payment of contributions to statutory health and long-term care
insurance for compulsorily insured recipients of pension/alimony including the contribution groups
via the ITSG-certified interface ST01.43 Paying agent reporting procedure (ZMV) (see SS01.04).
A
VE13.11
Subsequent demand for contributions
The HR system must enable the subsequent claiming of health insurance/nursing care insurance
contributions within the scope of the retroactive accounting depth.
A
VE13.12
Subsequent demand for contributions - Preparation of the cover letter
The HR system must enable the automated creation of the letter for the return of overpaid health
and long-term care insurance contributions to the health insurance funds.
A
VE13.13
Ablage in the document management system
The HR system must ensure the separate Ablage of the letter for recovery and all lists created from the
imprest reporting procedure in the docu-
management system (not in individual personnel case files).
A
4.7.9.2.3 Pension recipient and old-age pension recipient card
When a civil servant/judge retires and receives retirement benefits, it is regularly necessary to provide pension and retirement
benefit recipients with a recipient ID card similar to a pension ID card.
Requirement labelling
Requirement
Criterion
VE14.01
Printing the recipient ID card
The HR system must be able to print the recipient ID card for pension and retirement benefit
recipients on paper with the data to be inserted automatically by the system.
-
Salutation and title,
-
Name affix,
-
Surname and first name,
-
Date of birth,
-
Authority designation,
A
13 December 2024 Page 214 of 366
13 december 2024
Requirement labelling
Requirement
Criterion
-
Type of service,
-
Validity period,
-
Personnel number
enable. The HR system must enable the administrator to change the data.
VE14.02
Re-creation of the recipient ID card
The HR system must enable the processing department to recreate the recipient ID.
A
4.7.9.4 Sharing the supply burden
If a civil servant or judge changes employer, the pension burden must be shared. Depending on the case, the LAF can take on the
role of the receiving and transferring employer. All pension burden sharing tasks must be editable in the pension burden sharing
directory. In the role of the transferring employer, the HR system must calculate the settlement amount.
Requirement
labelling
Requirement
VE15.01
Legislation
The HR system must automatically implement all legal provisions of the VLT-StV and the VLTG MV in the
respective applicable version when sharing the supply burden.
VE15.02
Mapping of roles in supply load sharing
The HR system must reflect both the role of the receiving employer and the role of the transferring
employer.
VE15.03
Calculation of the severance payment amount as the transferring employer
The HR system must automatically calculate the severance payment amount for the former employee
and surviving dependants when acting as the transferring employer. In particular, the following cases
must be provided for when automatically calculating the severance payment amount:
-
New case,
-
Suspense with and without quotas for periods of service and
-
Combination case.
13 December 2024 Page 215 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE15.04
Automated calculation of the severance payment amount as the transferring employer The HR system
must automatically calculate the severance payment amount in accordance with Section 4 (2) VLT-StV.
The calculation is carried out in particular on the basis of
-
the data to be automatically transferred from the salary task, in particular the following:
•
Surname and first name of the retired official/judge,
•
Date of birth,
•
Change of employer with effect from,
•
Professor: (yes/no),
-
the pensionable remuneration to be automatically taken into account at the time of the change of
employer at the transferring employer, whereby
•
salary increases must be taken into account automatically and
•
the actual and legal circumstances of the departing employer at the time of departure
(retroactive salary increases are not taken into account) are decisive, i.e. the possibility of
manual amendment must be given
-
the (pensionable) periods of service to be automatically transferred from the salary or pension task
or from any existing pension burden-sharing task (previous change of employer) and the manual
addition of the pensionable periods of service
-
the consideration of pensionable service periods in accordance with § 6 VLT-StV,
•
whereby crediting must be possible to the full extent, to a partial extent to be entered or
without consideration, and
•
the periods of service expressed in full months are taken into account.
-
the assessment rate to be calculated automatically, depending on the age of the transferring
person at the time of leaving the transferring employer, in accordance with § 4 para. 2 sentence 2
VLT-StV (exception: professors - the assessment rate here is statically 25 per cent, cf. § 4 para. 2
sentence 3 VLT-StV)
A
VE15.05
Reimbursement of the severance payment as the transferring employer
The HR system must enable the reimbursement of the settlement amount for the former employee and
surviving dependants when acting as the transferring employer.
A
VE15.06
Correction of the calculation as transferring employer
The HR system must enable recalculations with reference to the previous calculation and determination
of the difference amount for necessary corrections by the administrator.
A
VE15.07
Cover letter with attachment
The HR system must enable a cover letter to be created with the attachment belonging to the severance
payment (§ 8 Vlt-StV).
A
13 December 2024 Page 216 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE15.08
Data collection as receiving employer
The HR system must enable the recording of the necessary data for the receipt of the severance
payment for the newly employed person and the surviving dependants when a civil servant/judge joins
the company due to a change of employer within the meaning of the VLT-StV, in particular
-
the transferring employer,
-
the settlement amount transferred,
-
the date of receipt of payment,
-
the budget title and
-
the legal basis.
A
VE15.09
Forwarding of the severance payment amount as the receiving employer in the event of a further
change of employer
In the event of a further change of employer without the requirements of Section 3 VLT-StV being met,
the HR system must hold the severance payment amount received for transfer to the new employer and
for interest calculation.
A
VE15.10
Reimbursement cases according to § 107b BeamtVG
The HR system must map the calculation of annual reimbursements in accordance with Sections 10, 11
and 12 VLT-StV in conjunction with Section 107b BeamtVG for both the role of the receiving employer
and the role of the transferring employer.
A
VE15.11
Reimbursement cases according to § 107b BeamtVG as transferring employer
The HR system must automatically make the adjustments in accordance with Section 10 (1) No. 2 and
No. 3 VLT-StV for the role as the transferring employer in order to automatically have the possibly new
initial value available in the following year.
A
VE15.12
Reimbursement cases according to § 107b BeamtVG as receiving employer
After manual entry of the initial value, the HR system must automatically make the adjustments in
accordance with Section 10 (1) No. 2 and No. 3 VLT-StV for the role as the receiving employer in order to
automatically have the possibly new initial value available in the following year.
A
VE15.13
Supply burden sharing schedule
The HR system must enable the LAF administrator, the head of department and the head of department
group to view a central supply load directory in accordance with the access authorisations. This directory
must all current and completed
The programme contains supply load sharing tasks including associated documents.
A
13 December 2024 Page 217 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE15.14
Supply load distribution list - manual entry
The HR system must make it possible for each supply load sharing task to be performed manually.
-
the basic data of the task (in particular surname, first name, date of birth and personnel number)
-
the responsible clerks and the historical clerks,
-
Resubmissions,
-
the type of procedure (e.g. first change of employer, second change of employer or, in the case of
Section 107b LBeamtVG MV, payment 2023, payment 2024),
-
the role of the LAF as the transferring or receiving employer,
-
transferring or receiving employer (e.g. federal, state, local authority)
-
Case according to § 107b LBeamtVG MV
-
the status of the pension burden sharing task (in particular settlement calculation pending, in
progress, documents requested, correction requested, payment instruction issued, awaiting
receipt of payment, completed) including its history,
-
the date of any reminders,
-
the date of death of the former employee,
-
the date of death of surviving dependants,
-
the date of the payment order,
-
the date of receipt of payment and
-
Budget title
can be recorded and customised.
A
VE15.15
Supply load sharing directory - calling up tasks and documents The HR system must make it possible to
call up the supply load sharing tasks, including the associated documents, from the supply load sharing
directory.
A
VE15.16
Supply load sharing directory - Automated logging of the process status
The HR system must be automated in the supply burden sharing directory for each supply burden sharing
task.
-
the basic data of the task,
-
the responsible clerks and the historical clerks,
-
Partial resubmissions (e.g. 6-month period),
-
the role of the LAF as a transferring or, in some cases, receiving employer,
-
the status of the supply load sharing task and its history,
-
the date of the payment order and
-
store the date of receipt of payment and
update it continuously.
A
VE15.17
Supply burden sharing directory - comments field
The HR system must contain a free text field without character limit for comments for each task in the
supply load distribution list.
A
13 December 2024 Page 218 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE15.18
Supply burden sharing directory - selection of supply burden sharing tasks and their combination
The HR system must enable the administrator to select (filter and sort) the supply burden sharing tasks
in the supply burden sharing directory according to the following characteristics, including their
combination:
-
the basic data of the task
-
the person in charge,
-
periods (in particular date of receipt, date of change of employer, date of issue),
-
transferring or receiving employer (e.g. federal, state, local authority)
-
Resubmissions
-
the role of the LAF as the transferring or receiving employer and
-
the status of the supply burden sharing task.
The HR system must save the individual user settings for the filter and sorting function for each
processing task in the supply workload distribution directory.
A
VE15.19
The HR system must enable the centralised specialist administration to create, adapt and delete (edit) the
procedure type and status of the supply burden sharing task for use in the supply burden sharing
directory (e.g. as a drop-down field).
A
VE15.20
Supply burden sharing directory - highlighting of data fields
The HR system should enable the central specialist administration to highlight data fields in the supply
burden sharing directory in several colours (e.g. different coloured marking of the responsible clerks).
B
VE15.21
Budgetary burden
The HR system must allow all incoming and outgoing payments to be posted to different budget items in
the HKR procedure when splitting pension costs.
A
VE15.22
Reimbursement cases in accordance with § 11 VLT-StV in conjunction with § 107b BeamtVG as the
transferring employer
The HR system should calculate the severance payment amount for the role of the transferring employer.
automatically in accordance with § 11 VLT-StV.
B
4.7.9.5 Pension equalisation
If a court requests information on pension equalisation from the LAF, the LAF is obliged to carry out a pension equalisation
procedure. Pension equalisation is carried out for active civil servants, judges, pension recipients, old-age and survivors' pension
beneficiaries.
Correspondence with the court takes place via the special public authority mailbox (SS01.43), whereby the letters and
information must be created in accordance with sections 4.1.6 (document creation) and 4.7.13 (document creation -
remuneration notification).
Pension equalisation tasks are processed using the pension equalisation directory. The directory provides the case handler with
an overview of the procedure, which is characterised by regular interruptions.
The calculations and the preparation of the information for the court are largely automated. The appeal proceedings and
amendment proceedings workflows take place downstream.
13 December 2024 Page 219 from 366
13 december 2024
The verification and payment of refunds should be largely automated.
Requirement
labelling
Requirement
Criterion
VE16.01
Pension equalisation register
The HR system must enable the LAF administrator, the department head and the department group head
to view a central pension equalisation directory in accordance with the access authorisations. This
directory must contain all current and completed pension equalisation tasks including associated
documents.
A
VE16.02
Pension equalisation register - manual entry
The HR system must make it possible for each pension equalisation task to be performed manually.
-
the basic data of the task (in particular surname, first name, date of birth and personnel number),
-
the responsible processing department and the historical processing department,
-
comparing requested and incoming documents,
-
comparing requested and completed entries,
-
Completed partial checks by the processing department,
-
Resubmissions,
-
the type of proceedings (e.g. first divorce, second divorce, first information on a possible divorce),
-
the area of law (LBeamtVG MV, LAltGG MV),
-
the status of the pension equalisation task (in particular in progress, documents requested,
correction, proceedings suspended, proceedings continued under the law of the LAltGG MV,
proceedings continued under the law of the LBe amtVG MV, appeal proceedings, amendment
proceedings, cancelled) including its history and
-
the type of settlement (in particular information provided to the court, information provided to
the person employed, proceedings discontinued due to the death of the person employed,
proceedings discontinued due to the dismissal of the person employed with details of the
organisation taking over the proceedings)
can be recorded and customised.
A
VE16.03
Pension equalisation directory - Calling up tasks and documents
The HR system must enable the pension equalisation tasks, including the associated documents, to be
called up from the pension equalisation directory.
A
VE16.04
Pension equalisation register - link between married/partnered persons
The HR system must enable the administrator to call up the pension equalisation task of the
wife/husband or partner from the pension equalisation register, provided that this is possible.
are also managed in the HR system.
A
13 December 2024 Page 220 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE16.05
Pension equalisation register - Automated logging of the status of proceedings
The HR system must be automated in the pension equalisation directory for each pension equalisation
task.
-
the basic data of the task,
-
the responsible processing department and the historical processing department,
-
comparing requested and incoming documents,
-
comparing requested and completed entries,
-
Completed partial checks by the processing department,
-
Resubmissions and
-
store and continuously update the status of the pension equalisation task and its
history.
A
VE16.06
Pension equalisation register - comments field
The HR system must contain a free text field without a character limit for comments in the pension
equalisation directory for each task.
A
VE16.07
Pension equalisation directory - selection of pension equalisation tasks and their combination
The HR system must enable the clerk in the pension equalisation directory to select (filter and sort) the
pension equalisation tasks according to the following characteristics, including their combination:
-
the basic data of the task
-
the person in charge,
-
Time periods (e.g. date of receipt or date of completion),
-
Resubmissions,
-
the legal field,
-
the type of procedure,
-
the status of the pension equalisation task and
-
the type of fulfilment.
The HR system must save the individual user settings for the filter and sorting function for each case in
the pension equalisation directory.
A
VE16.08
Pension equalisation register - editing of procedure type, status and type of settlement
The HR system must enable the Central Specialist Administration to create, adjust and delete (edit) the
type of procedure, status of the pension equalisation task and type of settlement for use in the pension
equalisation register (e.g. as a drop-down field).
A
VE16.09
Pension equalisation directory - highlighting of data fields
The HR system must enable the central specialist administration to highlight data fields in the pension
equalisation directory in multiple colours (e.g. different colour coding of the responsible administrator).
A
VE16.10
Suspension of the proceedings
The HR system must make it possible for a pension equalisation task to be suspended without result until
there is a change in definable data (e.g. change of status from civil servant on recall to civil servant on
probation). If the change occurs due to the entry of new data or a data change, the HR system must
automatically send a notification of the change of status to the case processor.
to continue the pension equalisation task.
A
13 December 2024 Page 221 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
VE16.11
Task completion without result
The HR system must make it possible for a pension equalisation task (e.g. in the event of the death of the
employee) to be completed without the need to provide information.
A
VE16.12
Calculation for the information
The HR system must calculate the equalisation value pursuant to Section 1 (2) VersAusglG for employed
persons with service or official salaries and for persons entitled to old-age and survivors' benefits with
entitlement to old-age benefits on the basis of
-
of the calculated pensionable service periods, previous service periods and credit periods,
-
the pensionable periods of service, previous periods of service and additional periods during the
marriage,
-
the pensionable periods of service, previous periods of service and additional periods of service
after the marriage until retirement in accordance with the standard retirement age,
-
of the pensionable remuneration at the time of the marriage,
-
of the pension/retirement benefit rate,
-
of pension/retirement benefits,
-
child-raising periods and
-
of the suspension regulations according to §§ 54, 55 and 57 LBeamtVG MV and according to the
§§ Sections 11, 12, 13 LAltGG MV
can be calculated. It should be possible to change the end of the marriage and the equalisation value
manually.
On the basis of the calculation for the information, it must be able to prepare a pension equalisation
information (recipient: court) and a fictitious pension equalisation information (recipient: employed
person), stating the relevant valuation date, the marriage period share, the equalisation value and the
corresponding capital value. This must also contain the interim results of the calculations as an
attachment.
A
VE16.13
Preparation of a new pension equalisation statement
The HR system must (e.g. in the event of retroactive changes to the calculation basis) enable the pension
equalisation information to be created again in accordance with VE16.14.
A
VE16.14
Refund procedure (1/5)
The HR system should enable the verification of reimbursement requests (including corrections) in
accordance with the Pension Equalisation Reimbursement Ordinance, which are received via the SS01.46
interface, by the processing department. For this purpose, the task-independent list of the pension
insurance provider should be able to be automatically split up by task for the purpose of individual
checking of all pension equalisation tasks. Past reimbursements should be listed for the processing
department for the purpose of checking reimbursement requests.
B
VE16.15
Refund procedure (2/5)
The HR system should inform the processing department if, for an individual pension equalisation task for
the specific calendar year (previous year or before
years) a claim for reimbursement has already been settled.
B
13 December 2024 Page 222 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
VE16.16
Refund procedure (3/5)
The HR system should automatically assign the task-independent list with the total claim to the head of
department for manual release after all individual claims have been processed by the administrator. The
administrator should be able to delete or separate individual claims from the list (total claim).
B
VE16.17
Refund procedure (4/5)
The HR system should enable the automated payment of refunds in accordance with the requirements
ZZ02.01 (generation of a booking file), ZZ01.01 (generation of a payment transaction file) and ZZ03.05
(cancellation of order release (recall)).
B
VE16.18
Refund procedure (5/5)
The HR system should enable the reclaiming of overpaid refunds in accordance with the requirements
ZZ01.01 (generation of a payment transaction file), ZZ02.01 (generation of a posting file) and ZZ03.05
(cancellation of order release (recall)). The reimbursement value in the HR system should be
context can be changed manually.
B
4.7.10
Overarching technical requirements
The following section presents overarching technical requirements that are relevant for the calculation of remuneration, salaries,
pensions and retirement benefits in accordance with the individual chapter descriptions.
4.7.10.1
Gross calculation - general pay calculation
The requirements of this chapter apply to the calculation of remuneration, salaries, pensions and retirement benefits.
Requirement
labelling
Requirement
ÜF01.01
Consideration of characteristics in the remuneration calculation
When calculating remuneration, the HR system must in particular take into account the
-
Tax liability,
-
Social insurance liability,
-
Supplementary pension obligation,
-
linear increase,
-
Seizability,
-
Competitions and credits,
-
Reductions and
-
Ability to add premiums (§ 21 sentences 2 and 3 TV-L/TVF)
of all pay components including the other pay components and take this into account accordingly in the
calculation. The HR system must also take into account when calculating all pay components, including
the other pay components, whether the pay component
-
is paid on an unpaid basis,
-
is included in the basis for calculating the special payment/annual special payment and
-
is to be taken into account when determining the annual earnings limit.
13 December 2024 Page 223 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF01.02
Configuration of features
The HR system must allow the Central Specialist Administration to configure the characteristics of all pay
components in the system settings, in particular
-
Tax liability,
-
Social insurance liability,
-
Obligation to provide supplementary benefits,
-
Linear increase,
-
Seizability,
-
Competitions and credits,
-
Cuts,
-
Impact capacity
-
services,
-
Special payment and annual special payment and
-
Annual earnings limit.
A
ÜF01.03
Effective period - Recruitment by LAF processing department
The HR system must offer the LAF administrator the option of setting effective periods (from/to) for
remuneration components.
A
ÜF01.04
Effective period - Recruitment by processing department
The HR system must offer the office administrator the option of setting effective periods (from/to) for pay
components.
A
ÜF01.05
Further use of data in the event of a change of legal relationship and claim
When a legal relationship and entitlement changes, the HR system must automatically transfer the data
required for payroll accounting for further use.
A
ÜF01.06
Temporary granting of remuneration
The HR system must enable the administrator to set a time limit on the granting of remuneration. Once
the time limit has expired, the payment must be automatically cancelled.
A
ÜF01.07
Granting of discounts
The HR system must offer the option of making daily deductions from the grant.
of remuneration benefits as an advance payment.
A
4.7.10.2
Gross calculation - benefits
The requirements of this chapter apply to the calculation of remuneration and salaries.
Requirement
labelling
Requirement
Criterion
ÜF02.01
Consideration of variable performance-related remuneration
The HR system must take into account variable performance-related pay in addition to the basic salary in
accordance with Sections 2, 33-37 LBesG MV in conjunction with the HsLeistbVO MV
(C salary).
A
13 December 2024 Page 224 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF02.02
Recording multiple benefits
The HR system must facilitate the manual recording of multiple similar and dissimilar benefits.
-
in fixed amounts,
-
as a percentage of the basic salary and
-
as a one-off payment.
A
ÜF02.03
Maximum limit for benefits
The HR system must observe the maximum limit in accordance with Section 33 (2) sentence 1 LBesG MV
in the case of performance-related pay and inform the administrator if the maximum limit is exceeded.
A
ÜF02.04
Temporary/permanent consideration of benefits and consideration as a one-off payment
The HR system must enable the temporary and permanent recognition of benefits and recognition as a
one-off payment in accordance with Section 34 (1) sentence 1 LBesG MV and Section 35 (1) sentences 3
and 4 LBesG MV.
A
ÜF02.05
Participation of benefits in salary adjustments
The HR system must enable the participation of performance-related pay in salary adjustments in
accordance with § 34 para. 1 sentence 2 LBesG MV, § 35 para. 2 LBesG MV and § 36 para. 3 LBesG MV.
A
ÜF02.06
Competition rules for performance-related pay
The HR system must observe the competition regulation in Section 35 (1) sentence 2 LBesG MV for
performance-related pay.
A
ÜF02.07
Labelling of benefits - Participation in salary adjustments
The HR system must distinguish between performance-related pay participating in the salary adjustment
and performance-related pay not participating in the salary adjustment.
A
ÜF02.08
Labelling of benefits - eligibility for retirement pension
The HR system must
-
pensionable and non-pensionable and
-
Employees subject to supplementary pension contributions and those not subject to supplementary
pension contributions
characterise benefits differently.
A
4.7.10.3
Gross calculation - family-related benefits
The requirements of this chapter apply to the calculation of remuneration, salaries and pensions. Section 50 LBeamtVG MV is
decisive for the calculation of pension payments.
Requirement
labelling
Requirement
Criterion
ÜF03.01
Illustration of the family allowance
The HR system must reflect the family allowance and the levels according to §§ 41-43 LBesG MV.
A
ÜF03.02
Calculation of the family allowance
The HR system must calculate the family allowance taking into account the family status, including child-
related components and persons in need of assistance.
The calculation is automated for all household members.
A
13 December 2024 Page 225 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF03.03
Calculation of the family allowance for part-time employment
When calculating the family allowance, the HR system must take into account the special regulations on
part-time reduction of the family allowance.
A
ÜF03.04
Monthly calculation of the family allowance
The HR system must automatically calculate the family allowance and the levels taking into account the
start of the entitlement in accordance with Section 43 sentence 1 LBesG MV and the end of the
entitlement in accordance with Section 43 sentence 2 LBesG MV on a monthly basis in compliance with
Section 43 sentence 3 LBesG MV.
A
ÜF03.05
Competing regulations for family allowance
The HR system must reflect the competing provisions of Section 42 LBesG MV for the family allowance.
A
ÜF03.06
Calculation of the family allowance in the case of competition regulations
The HR system must automatically calculate the family allowance and the levels, taking into account
competitive regulations.
A
ÜF03.07
Allocation of the amounts to the beneficiaries
The HR system must automatically allocate the amounts of the different levels of the family allowance
for the children of the beneficiaries if there are several beneficiaries. The following aspects in particular
must be taken into account for the allocation:
-
the marital status in the actual sense, as well as competing claims to family allowances or
corresponding benefits, and
-
the number and ranking of the children to be taken into account, in particular also in the case of
competing entitlements to further family allowances or differential amounts or comparable
benefits.
A
ÜF03.08
Labelling the children
The HR system must characterise the children in the personnel case according to their type of inclusion
(counted child, paying child).
A
ÜF03.09
Calculation of the family allowance for level 2 and the following levels
The HR system must automatically calculate the family allowance for level 2 and the following levels
based on the order of birth of the children and the type of consideration (counted child, paying child).
A
ÜF03.10
Increase amounts
When calculating the family allowance, the HR system must take into account the increase amounts and
the difference amount specified in Annex 10 of the LBesG MV
automatically.
A
13 December 2024 Page 226 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF03.11
Settlement notice
-
The HR system should enable the automated creation of both internal (as a data record within the
pay system) and external (as a document) comparison notifications, in particular the following
(triggered by the administrator): Settlement notification for level 1 family allowance
(spouse/registered civil partnership)
•
New employment with wife/spouse or civil partner in public service,
•
Ongoing personnel case and wife/spouse new to the civil service,
•
Change in marital status,
•
Cessation of salary payment (e.g. special leave without salary) and resumption of salary
payment
•
Resignation, change of legal relationship or entitlement (from civil servant to pension
recipient), death,
-
Settlement notification family allowance level 1 (admitted child/person in need of assistance)
•
Payment acceptance level 1 for a child/person in need of assistance,
•
End of payment level 1 for an admitted child/dependent person and
-
Comparative notification of child-related family allowance level 2 and the following levels, split if
there are several beneficiaries
•
Payment of the child-related family allowance,
•
End of payment of the child-related family allowance
B
ÜF03.12
Automated creation of settlement notifications
The HR system should enable the automated creation of internal and external comparison notifications
when changes are made to data that have an impact on the payment of the family allowance (without
the separate triggering of the comparison notification by the administrator).
B
ÜF03.13
Automatic adjustment of the family allowance for two or more personnel cases within the payroll
system
In cases where two or more personnel cases are entitled to a family allowance in accordance with
Section 42 LBesG MV, the HR system must automatically convert and log the effects on the other
personnel cases when entering data that affect the payment of the family allowance.
A
ÜF03.14
Automated implementation of the level 1 family allowance
The HR system must automatically implement half of the benefit in accordance with Section 42 (4) LBesG
MV for family allowance level 1 if both persons are HR cases in the HR system (salary, pension,
remuneration).
A
ÜF03.15
Automated request for the family allowance declaration when a review date is reached
When a review date is reached, the HR system must automatically transmit a document to the KP for Pay
for provision to the personnel case depending on the marital status and child characteristics, requesting
the employee to submit a declaration on the family allowance.
A
ÜF03.16
Setting of review times by the central specialised administration The HR system must enable the central
specialised administration to set review times (also client-related).
A
13 December 2024 Page 227 of 366
13 december 2024
Requirement
labelling
Requirement
ÜF03.17
Suspension of payment after declaration not received
The HR system must enable the suspension of payment of the family allowance after the expiry of a
deadline and a subsequent release by the administrator in the event that the declaration has not been
submitted by the employee.
ÜF03.18
Automated determination of the following review time
The HR system must automatically determine the next review date after the review by the
administrative department and after confirmation or change of the family allowance by the
administrative department.
ÜF03.19
Call-off procedure with family benefits office
The HR system must use the interface in accordance with ST01.15 (see SS01.05) to automatically retrieve
the data from the Federal Employment Agency (family benefit offices) in accordance with Section 68 (4)
EStG and the relevant ordinance (Ordinance on the Automated Retrieval of Child Benefit Data by the
Public Service Benefit Offices) and make it available to the HR system on a case-by-case basis.
ÜF03.20
Manual query
In accordance with §§ 41-43 LBesG MV and §§ 5 Para. 1, 14 Para. 3, 50 Para. 1 LBeamtVG MV, the HR
system must enable a manual query to a person entitled to child benefit or their spouse or partner as
well as to family funds.
ÜF03.21
Offsetting against the basic salary
The HR system must enable the automatic deduction of the relevant amount from the basic salary in
accordance with section 41(2) sentence 1 LBesG MV.
4.7.10.4
Gross calculation - Other pay components
The requirements of this chapter apply to the calculation of remuneration, salaries, pensions and retirement benefits. The
requirement ÜF04.06 only applies to salary and pension calculations.
Requirement
labelling
Requirement
ÜF04.01
Consideration of other pay components
In particular, the HR system must include the other reference components
-
Allowances,
-
Grants,
-
Surcharges,
-
Compensation,
-
Expense allowances,
-
Premiums
can be automatically taken into account when calculating remuneration. These additional remuneration
components are listed in Annex 3.3 (Additional remuneration components) as at 1 November 2022.
ÜF04.02
Numerical limitation of additional pay components
The HR system must include the other remuneration components specified in ÜF04.01 (Consideration of
other remuneration components) without numerical limits.
per personnel case.
13 December 2024 Page 228 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF04.03
Amount or percentage
The HR system must allow differentiated calculation according to a fixed amount or a percentage rate,
depending on the further remuneration component. The amount or the percentage rate for the other
remuneration components are listed in Appendix 3.3 (other remuneration components) as at 1
November 2022.
A
ÜF04.04
Configuration of additional cover components
The HR system must offer the Central Specialist Administration the option of configuring the other
reference components, adding new ones and deleting existing ones.
A
ÜF04.05
Setting the period of validity via centralised specialist administration
The HR system must offer the Central Specialist Administration the option of setting validity periods
(from/to) for additional pay components. The validity periods of the additional pay components are
listed in Appendix 3.3 (additional pay components) as of 01 November 2022.
A
ÜF04.06
Consideration according to transaction type
The HR system must automatically take other pay components into account when calculating pay,
provided that the other pay components are intended for the transaction type. Transaction type
categories include in particular
-
Salary and pension cases,
-
Salary cases,
-
Supply cases
are considered. The allocation of further remuneration components is categorised in Appendix 3.3 as at
01.11.2022 (further remuneration components).
A
ÜF04.07
Different booking centre
When taking additional pay components into account, the HR system must automatically use the posting
centre that is used for the underlying pay (standard posting centre). Deviating from this, the HR system
must allow the manual selection of different booking centres. The use of the respective booking office for
the other pay components is listed in Appendix 3.3 (Other pay components) as at 01.11.2022.
A
ÜF04.08
Selection of alternative booking centres
For other pay components, the HR system must provide a list of all booking centres when deviating
booking centres are entered, from which the clerk selects the relevant booking centre. It should also be
possible to enter deviating booking centres manually.
A
ÜF04.09
Plausibility check when entering additional reference components
When additional remuneration components are entered by the LAF administrator and the department
administrator, the HR system must automatically check whether the inclusion is plausible. To do this, it
compares the conditions of the additional pay component with the existing data in the process (e.g. job
title, employment department, period of service, career, identical existing allowance in the effective
period). If the consideration is not
is plausible, the HR system points this out to the processing department.
A
13 December 2024 Page 229 of 366
13 december 2024
4.7.10.5
Gross calculation - one-off and special payments
The requirements ÜF05.01 (mapping, maintenance and calculation of one-off and special payments) and ÜF05.02 (mapping of
one-off and special payments in addition to and without ongoing payments) of this chapter apply to the calculation of
remuneration, salaries and pensions.
The requirements ÜF05.03 (Automated determination of special payments) to ÜF05.13 (Automated application of suspension,
reduction and crediting rules) of this chapter apply to the calculation of salaries and pensions.
The requirements ÜF05.14 (holiday pay) to ÜF05.16 (holiday pay - automated notification) of this chapter apply to the calculation
of pay and salaries.
Requirement
labelling
Requirement
Criterion
ÜF05.01
Illustration, maintenance and calculation of one-off and special payments
The HR system must make it possible for one-off and special payments to be mapped, maintained by the
administrator and calculated automatically.
A
ÜF05.02
Mapping of one-off and special payments alongside and without ongoing payments The HR system
must map one-off and special payments in periods both alongside and without ongoing payments.
A
ÜF05.03
Automated determination of special payment
The HR system must enable the automated calculation of the special payment in accordance with SZG
MV, §§ 9 Para. 5, 11 Para. 2 Sentence 2 LMinG and § 5 LParlG. This also includes the offsetting of benefits
comparable to the special payment in accordance with Section 7 (5) SZG MV, which are paid on the basis
of regulations other than civil service law.
A
ÜF05.04
Automated identification of beneficiaries
The HR system must automatically check the requirements of Section 2 (1) and (3) and Section 3 SZG MV
and thus automatically identify those entitled to a special payment and take this into account in further
processing.
A
ÜF05.05
Automated check of the exclusion criteria
The HR system must automatically check the exclusion criteria in accordance with Section 4 SZG MV and
automatically identify excluded persons and exclude them from payment.
A
ÜF05.06
Visualisation of the calculation steps
When calculating special payments, the HR system must show the individual calculation steps, e.g. when
calculating the basic amount and when calculating the special amount for children.
A
ÜF05.07
Automated calculation of the special payment
The HR system must automatically calculate the amount of the special payment in accordance with §§ 5,
6, 7, 8, 9, 10, 11 SZG MV.
A
ÜF05.08
Automated determination of remuneration for a special payment
The HR system must record the remuneration of those entitled to a special payment.
automatically in accordance with Section 7 (1), (2) and (3), Section 8 and Section 13 SZG MV.
A
13 December 2024 Page 230 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF05.09
Automated reduction of the basic amount
The HR system must automatically calculate the reduction in the basic amount in accordance with Section
7 (4) SZG MV.
A
ÜF05.10
Calculation of the basic amount
The HR system must automatically calculate the basic amount of the special payment in accordance with
§ 6 SZG MV.
A
ÜF05.11
Automated calculation of the special amount for children
The HR system must automatically calculate the special amount for children in accordance with § 9 Para.
1 SZG MV.
A
ÜF05.12
Automated consideration of comparable services
The HR system must automatically take into account comparable benefits in accordance with Section 7
(5) and Section 9 (2) SZG MV.
A
ÜF05.13
Automated application of the suspension, reduction and crediting provisions According to § 10 SZG
MV, the HR system must automatically take into account the suspension, reduction and crediting
provisions of the LBeamtVG MV when determining the special payment.
A
ÜF05.14
Holiday pay
In accordance with the applicable regulations (§ 26 TV-L; § 10 EU- rlV(Bund); Circular GKV
Spitzenverband of 29.08.19), the HR system must be capable of automatically calculating holiday pay
based on:
-
the manual entry of the amount,
-
the leave days to be recorded manually, and
-
leave days to be compensated transferred from a future HR management process (see pay
interface SS01.40).
A
ÜF05.15
Holiday pay - death of the employee
In the event of the death of the employee, the HR system must allow the application-related leave
compensation to be transferred to heirs by allowing heirs to be entered manually (including tax
characteristics, bank details and the data for the wage tax certificate to be transmitted if the heir is not
an employee) and the leave compensation to be settled via this. This includes payment to the heir's
account after taking into account the obligation to pay social security contributions.
A
ÜF05.16
Holiday pay in lieu - automated notification
The HR system must be able to automatically send a corresponding letter (including free text fields for
completion by the administrator) to the employee or heir informing them of the calculated amount once
the leave compensation to be paid has been automatically calculated. If the heir is also an employee, the
HR system should automatically generate the wage tax certificate.
matised.
A
4.7.10.6
Gross calculation - death benefit
The requirements of this chapter apply to the calculation of remuneration and pensions.
Requirement
labelling
Requirement
Criterion
13 December 2024 Page 231 from 366
13 december 2024
ÜF06.01
Selection of a personnel case for payment of the death benefit
The HR system must make it possible to select an existing personnel case in the HR system as the
authorised person for the payment of the death benefit and survivor's pension.
A
ÜF06.02
Data collection for payment to authorised person
The HR system must enable the manual entry of data required for the payment of death benefits and
survivors' benefits to an authorised natural and legal person. In particular, this includes the address, tax
details and bank details of the person receiving the payment.
A
ÜF06.03
Automated calculation of the death benefit
The HR system must be based on
-
of the table remuneration,
-
of remuneration (excluding foreign child allowances and allowances),
-
of the candidate's remuneration (excluding foreign child supplements and allowances),
-
of the pension plus the difference pursuant to Section 50 (1) LBe amtVG MV,
-
the maintenance contribution plus the difference in accordance with § 50 Para. 1 LBeamtVG MV
and
-
of the widow's/widower's pension
automatically calculate the death benefit in accordance with Section 18 (1) LBeamtVG MV and Section 23
(3) TV-L.
A
ÜF06.04
Manual entry and amendment of the death benefit
The HR system must enable the death benefit to be entered and changed manually.
A
ÜF06.05
Payment of the death benefit
The HR system must enable automated payment to the authorised person, including checking that the
pension allowance has been exhausted.
A
ÜF06.06
Pro rata payment of the death benefit
The HR system must allow the death benefit to be paid out pro rata to several entitled persons and at
different times.
A
ÜF06.07
Document creation
The HR system must provide a representation of the underlying calculation steps for the death benefit,
including the amount of the death benefit for the document replacement.
(e.g. as an appendix to the pension provision).
A
4.7.10.7
Gross calculation - Sabbatical
The requirements of this chapter apply to the calculation of remuneration and salaries.
13 December 2024 Page 232 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF07.01
Determination of remuneration for sabbaticals
In the case of sabbaticals, the HR system must determine in particular the agreed scope of employment in
accordance with Section 24 (2) TV-L and Section 6 LBesG MV:
-
the table pay/salary,
-
all other trim components,
-
payment of the child-related grandfathering bonus in accordance with § 11 (2) TVÜ- Länder,
-
the payment of structural compensation in accordance with § 12 TVÜ-Länder and
-
One-off payments.
The only exceptions to this are
-
the remuneration components that depend on the performance of certain activities and are limited
to a certain period of time from the outset,
-
Shift work and shift allowances and
-
non-permanent remuneration components.
These are to be paid during the work and release phases in accordance with the actual scope of
employment (i.e. payment during the work phase depending on actual work performance up to 100%,
discontinuation of payment of the corresponding remuneration components during the release phase).
A
ÜF07.02
Posting of personnel expenses
In the case of sabbaticals, the HR system must enable the posting of personnel expenses, including
posting to/from the provision title, both in the work phase and in the release phase.
A
ÜF07.03
Management of the credit balance
In the case of sabbaticals, the HR system must manage the credit balance as a time credit in accordance
with Section 116 (1) SGB IV.
A
ÜF07.04
Settlement of the credit balance
In the case of sabbaticals, the HR system must be able to process the (SI and AAG levy) credit balance in
cash.
A
ÜF07.05
Incident
In the event of a sabbatical, the HR system must enable automatic calculation in the event of an incident.
A
ÜF07.06
Incidents and credit balances
In the event of a sabbatical, the HR system must implement the value credit management and value
credit processing in accordance with the ITSG specifications and the circular dated 31 March 2009.
A
ÜF07.07
Premature termination of the legal relationship
The HR system must be set up for sabbaticals in the event of early termination of employment.
/The HR system should automatically determine the back payment amount from the hours saved and
the current hourly rate. In addition, the HR system should enable the manual entry of the back payment
amount by the administrator.
A
ÜF07.08
Evaluation letter on monetary value saved to the personnel case
The HR system must automatically record the cumulative monetary value saved from the entire
sabbatical model annually on 31 December of the year in a
Compile the document and send it automatically to the personnel case.
A
13 December 2024 Page 233 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF07.09
Evaluation letter on saved hours to the department
In the case of sabbaticals, the HR system must automatically compile the cumulative accrued time credit
(hours) from the entire sabbatical model in a document for each personnel case on 31 December of each
year and automatically transfer it to the HR department.
Send to other departments.
A
4.7.10.8
Net calculation - social insurance
The requirements of this chapter apply to the calculation of remuneration, pensions and retirement benefits.
Requirement
labelling
Requirement
Criterion
ÜF08.01
ITSG certificate
The contractor must provide evidence of the ITSG certificate with the offer with regard to the standard
software offered for payroll accounting.
A
ÜF08.02
SV messages
The HR system must create SI notifications.
A
ÜF08.03
Determination of social security contributions
The HR system must determine the contributions for all social security branches in accordance with the
ITSG specifications.
A
4.7.10.9
Net calculation - tax deductions
The requirements of this chapter apply to the calculation of remuneration, salaries, pensions and retirement benefits.
Requirement
labelling
Requirement
Criterion
ÜF09.01
Tax calculation
The HR system must automatically calculate and pay tax deductions (wage tax, church tax, solidarity
surcharge) in accordance with tax regulations on an annual, monthly and daily basis, taking into account
the tax characteristics. The retroactive roll-up of current remuneration is mandatory.
A
ÜF09.02
Calculation of gross taxable income (1/4)
The HR system must characterise all pay components with regard to their treatment in the automated
payroll tax calculation with corresponding features.
A
ÜF09.03
Calculation of gross taxable income (2/4)
The HR system must enable the co-taxation of benefits in kind, travel expenses and other items.
A
ÜF09.04
Calculation of gross taxable income (3/4)
The HR system must cover several legal relationships and claims of the same employee.
employer/employer for the calculation of gross taxable income.
A
13 December 2024 Page 234 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF09.05
Calculation of gross taxable income (4/4)
The HR system must take into account tax-free income (tax exemption in accordance with Section 3 EStG).
A
ÜF09.06
Calculation of the wage tax deduction (1/5)
The HR system must automatically determine the calculation period for payroll taxes (year, month or
day).
A
ÜF09.07
Calculation of wage tax deduction (2/5)
The HR system must automatically calculate payroll taxes, taking into account the tax class, child
allowances, allowances according to ELStAM and add-back amounts according to ELS- tAM, in
accordance with the requirements of the programme flow chart provided by the Federal Ministry of
Finance for determining payroll tax in accordance with Section 39b EStG.
-
the current monthly salary,
-
other emoluments and
-
Other income in accordance with Section 34 (1) and (2) nos. 2 and 4 EStG (fifths rule) with
automated review of the requirements (favourable tax treatment test, test for aggregation of
income)
calculate.
A
ÜF09.08
Calculation of wage tax deduction (3/5)
The HR system must automatically select the various pension lump sums and the associated tax rate
according to the formula in Section 32a EStG.
A
ÜF09.09
Calculation of wage tax deduction (4/5)
The HR system must automatically calculate the pension allowance, the supplement to the pension
allowance and the age relief amount.
A
ÜF09.10
Calculation of wage tax deduction (5/5)
The HR system must automatically take into account the fifths rule and the balancing with automated
favourable tax treatment in the calculation.
A
ÜF09.11
Calculation of flat-rate wage taxes
The HR system must calculate flat-rate payroll taxes.
A
ÜF09.12
Calculation of church taxes
The HR system must automatically calculate the church taxes in accordance with the Church Tax Act of
the state of Mecklenburg-Vorpommern and the church tax resolutions and church tax ordinances of the
state of Mecklenburg-Vorpommern. In Mecklenburg-Vorpommern, the simplification rule for calculating
church tax is not applied to the flat-rate wage tax.
A
ÜF09.13
Limited tax liability
The HR system must make it possible to take into account the limited tax liability and tax exemption of
remuneration in accordance with double taxation agreements and the Foreign Employment Decree.
A
ÜF09.14
Carrying out the annual wage tax equalisation
The HR system must carry out the annual wage tax adjustment in accordance with the provisions of §
42b EStG with an automated check of admissibility.
A
13 December 2024 Page 235 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF09.15
Tax treatment (co-taxation) (1/2)
If the HR system can settle different legal relationships and entitlements of an employee/official or civil
servant/judge of the same employer/principal via a personnel case (personnel number), the HR system
must add together both similar and different types of remuneration from different legal relationships
and entitlements on the basis of the principle of a uniform employment/service relationship with one
employer/principal. If it is not possible to calculate using a personnel number, the administrator must be
able to record the amounts to be taxed.
A
ÜF09.16
Tax treatment (co-taxation) (2/2)
The HR system must collect income tax for the remuneration of different legal relationships and
entitlements of the same employer/principal using the same ELStAM.
A
ÜF09.17
Statutory compensation in accordance with Section 56 of the Infection Protection Act - Tax
The HR system must ensure that statutory compensation is paid in accordance with
§ 56 Infection Protection Act are tax-free. They are subject to the progression proviso and must
therefore be entered in line 15 of the Elster statement (according to the BMF letter on issuing electronic
wage tax statements in the currently valid version).
A
ÜF09.18
Tax exemption of the death benefit
The HR system must take into account the tax exemption of the death benefit.
A
4.7.10.10
Net calculation - contributions to the supplementary pension scheme
The requirements of this chapter apply to the calculation of remuneration, pensions and retirement benefits.
Requirement
labelling
Requirement
ÜF10.01
Company pension scheme (1/6)
The HR system must be able to map the pension scheme regulations (§ 25 TV-L, VBL statutes, ATV, §§
10a, 79-99 EStG) and use these to calculate the supplementary pension.
ÜF10.02
Company pension scheme (2/6)
The HR system must automatically determine the supplementary pension obligation in accordance with
the ATV.
ÜF10.03
Company pension scheme (3/6)
The HR system must make it possible to change the supplementary pension obligation manually.
ÜF10.04
Company pension scheme (4/6)
The HR system must facilitate the manual entry of exceptions to the insurance obligation.
(Section 2 (2) and (3) ATV) with the consequence of voluntary insurance.
13 December 2024 Page 236 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF10.05
Company pension scheme (5/6)
The HR system must automatically determine contributions/allocations for the supplementary pension
scheme. The HR system must characterise all remuneration components in the system with regard to
their affiliation to the remuneration subject to supplementary pension provision with corresponding
characteristics (subject to supplementary pension provision or not subject to supplementary pension
provision according to the articles of association).
A
ÜF10.06
Company pension scheme (6/6)
The HR system must automatically decide whether an inflow principle or a roll-up principle applies in the
case of back payments or retroactive accounting for supplementary benefits for the previous year or
previous years.
A
ÜF10.07
Parallel processing
The HR system must enable the parallel processing of several insurance relationships of an employee
with several employment relationships of the same employer (but one insurance number).
A
ÜF10.08
Search for supplementary pension insurance numbers
The HR system must make it possible to search for supplementary pension insurance numbers.
A
ÜF10.09
Tax and social security treatment of contributions and levies
The HR system must automatically calculate and delimit the tax and social security contributions and
levies for the supplementary pension scheme. The HR system must
-
the tax exemption of the levy in accordance with § 3 No. 56 EStG,
-
the flat-rate taxation of the contribution in accordance with § 40 b EStG,
-
the individual taxation of employees, if applicable,
-
the tax exemption pursuant to § 3 No. 63 EStG of the contributions in the capital cover procedure,
-
Social security exemption in accordance with § 1 Para. 1 Sentence 1 No. 9 SvEV and § 1 Para. 1
Sentence
3 SvEV and
-
take into account the BAV subsidy amount in
accordance with § 100 EStG.
A
ÜF10.10
Tax and social security treatment of contributions
The HR system must take into account the tax- and social security-exempt annual amounts of
contributions in the capital cover procedure in accordance with Section 3 No. 63 EStG at the beginning of
the year until these have been fully utilised (depletion model).
A
ÜF10.11
Tax and social security treatment and allocations
The HR system must take into account the tax- and social security-exempt annual amounts of
contributions in accordance with Section 3 No. 56 EStG and Section 40b EStG in constant monthly
amounts (distribution model). At the end of the year (December production), the entire year must be
automatically analysed again and, if necessary, rolled up.
A
ÜF10.12
Monitoring of allowances (1/4)
The HR system must monitor whether the tax-free allowance under Section 3 No. 63 EStG or the resulting
allowance under Section 1 para. 1 sentence 1 No. 9 SvEV is exceeded and, if necessary, automatically re-
tax or re-insure the tax or social security gross amount exempted in previous months if the allowance is
exceeded.
is used.
A
13 December 2024 Page 237 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF10.13
Monitoring of allowances (2/4)
When monitoring the allowances, the HR system must allow the Central Administration to specify the
sequence of expenses (in particular levies, contributions to the capital cover procedure, voluntary
contributions) for the supplementary pension. It must be possible for the Central Administration to
change these manually.
A
ÜF10.14
Monitoring of allowances (3/4)
The HR system must allow the supplementary pension scheme administrator to choose whether to use
the allowance for employee contributions. The HR system must allow the decision to be changed at any
time.
A
ÜF10.15
Monitoring of allowances (4/4)
The HR system must allow for the utilisation of the allowance for employee contributions to
supplementary insurance in terms of amount and percentage.
A
ÜF10.16
Voluntary insurance
In the case of voluntary insurance, the HR system must enable the calculation and payment of
contributions for each contract and tariff variant (individual transfer).
A
ÜF10.17
Voluntary insurance for academic employees
The HR system must support the automated completion of the form for registering and deregistering
scientific employees for voluntary insurance with the VBL.
A
ÜF10.18
Deferred compensation (1/3)
The HR system must enable the automated processing of salary conversions in accordance with the
applicable provisions of the TV-Entgelt-U-B/L.
A
ÜF10.19
Deferred compensation (2/3)
The HR system must pass on the contributions for deferred compensation to the payment procedure.
A
ÜF10.20
Deferred compensation (3/3)
The HR system must enable the delimitation of the tax and social security treatment of deferred
compensation in accordance with Section 3 No. 63 EStG and SVEV.
A
ÜF10.21
Allowance for deferred compensation (1/4)
In the case of deferred compensation, the HR system must calculate and forward the employer subsidy in
accordance with Section 1a (1a) BetrAVG.
A
ÜF10.22
Subsidy for deferred compensation (2/4)
In the case of deferred compensation, the HR system must calculate the employer subsidy of 15% (can
be waived by collective agreement) of the contribution to deferred compensation in accordance with the
BBG RV (no employer subsidy for remuneration above BBG RV).
A
ÜF10.23
Subsidy for deferred compensation (3/4)
The HR system must calculate the savings in social insurance contributions (for salaries below the BBG
RV, but above the BBG KV, e.g. in 2018 only 10.8% (9.3% RV + 1.5% AV)) in the case of deferred
compensation.
A
ÜF10.24
Allowance for deferred compensation (4/4)
In the case of deferred compensation, the HR system must recognise the employer's contribution in the
event of
recalculate the changes to the salary.
A
13 December 2024 Page 238 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF10.25
BAV subsidy amount (§ 100 EstG)
The HR system must hold the supplementary pension contributions paid in 2016 as a reference for the
subsidy amount in accordance with Section 100 EstG.
A
ÜF10.26
Reclaiming supplementary pension contributions
The HR system must enable the reclaiming of supplementary pension contributions from the VBL and the
monitoring of reclaims.
A
ÜF10.27
Calculation of the social security contributions to be certified on the wage tax statement
The HR system must take account of the additional amount in accordance with Section 1 (1) sentence 3
SvEV
automatically calculate the social security contributions due.
A
4.7.10.11
Net calculation - Riester pension scheme
The requirements of this chapter apply to the calculation of salaries, pensions and retirement benefits.
Requirement
labelling
Requirement
Criterion
ÜF11.01
Riester pension scheme (1/6)
The HR system must implement participation in electronic reporting with the German Federal Pension
Insurance - Central Allowance Office for Retirement Assets (ZfA) for the granting of pension allowances
(§§ 79 ff EStG).
A
ÜF11.02
Riester pension scheme (2/6)
The HR system must make it possible to apply for allowance numbers.
A
ÜF11.03
Riester pension scheme (3/6)
The HR system must enable the transfer of issued allowance numbers into the procedure.
A
ÜF11.04
Riester pension scheme (4/6)
The HR system must make it possible to report the data required for calculating the allowance (in
particular the relevant gross amounts, period of employment).
A
ÜF11.05
Riester pension scheme (5/6)
The HR system must make it possible to determine the relevant gross amounts.
A
ÜF11.06
Riester pension scheme (6/6)
The HR system must enable the cancellation of notification records.
A
4.7.10.12
Net calculation - advances
The requirements of this chapter apply to the calculation of remuneration, salaries, pensions and retirement benefits.
Requirement
labelling
Requirement
Criterion
13 December 2024 Page 239 of 366
13 december 2024
ÜF12.01
Advance (1/6)
The HR system must enable the administrator to instruct the payment of an advance.
ÜF12.02
Advance (2/6)
The HR system must allow advance payments to be entered manually.
ÜF12.03
Advance (3/6)
The HR system must enable the advance/employee loan to be transferred automatically in a daily
payment procedure.
ÜF12.04
Advance (4/6)
The HR system should automatically create a repayment plan for the internal monitoring of repayments
for advances.
ÜF12.05
Advance (5/6)
The HR system must retain the repayment amount of an advance with the monthly payroll. If interest is
also withheld, this must be posted to a separate budget item.
ÜF12.06
Advance (6/6)
The HR system must be able to manually change the repayment amount for advances.
and runtime.
4.7.10.13
Net calculation - capital-forming benefits
The requirements of this chapter apply to the calculation of remuneration and salaries.
Requirement
labelling
Requirement
Criterion
ÜF13.01
Establishment of an investment institution
The HR system must enable the collection of the necessary data for setting up an investment institution.
The data includes in particular
-
Start of contribution payment,
-
Contract no,
-
IBAN,
-
Monthly contribution payment (instalment amount in euros),
-
Number of instalments,
-
Name for different recipient account
A
ÜF13.02
Payment realisation
The HR system must enable the automated payment of the amounts to be invested to the investment
institutions.
A
ÜF13.03
Plausibility check during payment authorisation
The HR system must enable a plausibility check when making payments of capital-forming benefits
(entitlement to capital-forming benefits only if the employment/service relationship lasts at least six
months). If there is no entitlement to capital-forming benefits, the HR system must point this out to the
processing department.
A
ÜF13.04
Manual specification of a capital-forming benefit
The HR system must support the manual specification of a capital-forming benefit by the
employer/employee when making payments of capital-forming benefits.
masters.
A
13 December 2024 Page 240 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ÜF13.05
Transfer to several forms of investment
The HR system must enable the transfer to at least two forms of investment. A differentiation should be
made for each contract, in particular according to the garnishable and non-garnishable parts of the
transfer amount, depending on whether an asset-creating investment exists prior to the garnishment.
A
ÜF13.06
Automated causality check
The HR system must enable an automated causality check between the payment of a capital-forming
benefit by the employer and the transfer to the capital-forming investment of the civil
servant/judge/employee (capital-forming investment ≥ capital-forming benefit).
A
ÜF13.07
Missing information
The HR system must indicate that the capital-forming benefit has not been entered when recording a
capital-forming investment.
A
ÜF13.08
Freely definable payment cycles
The HR system should enable the payment of several different capital-forming investments at freely
definable payment intervals.
B
ÜF13.09
Deviating time allocation
The HR system must support a different time allocation for the transfer of the capital-forming
investment. In the case of retroactive entries, the first instalment transfer must be automatically reduced
by the instalments of the retroactive months.
be increased.
A
4.7.11
Fictitious calculations and billing runs
The HR system must provide the option of fictitious calculation of the opened or processed personnel case during the entire case
processing. The fictitious calculation takes place parallel to the productive system, so that productive data must not be changed
by fictitious calculations. The use of the fictitious calculation functions is as low-threshold and intuitive as possible and provides
the users with information for their work in a reasonable time and to a reasonable extent (e.g. taxes, social insurance, VBL
contributions, garnishments, direct insurance). The exchange and export of data from the fictitious calculation must be integrated
into the overall system as described in the requirements without any loss of productivity.
The payroll runs include the specific calculation of monthly payments as well as the associated statistics, analyses and information
and document transfers. They are carried out on a monthly basis. Trial runs for these payroll runs must fulfil the same
requirements, but are carried out independently of time.
Fictitious calculations
13 December 2024 Page 241 of 366
13 december 2024
Requirement
labelling
Requirement
PB01.01
Individual fictitious calculation (1/2)
The HR system must
-
provide the option of fictitiously calculating the remuneration of a personnel case at any time on
the basis of the existing calculation-relevant data
-
ensure that the fictitious calculation, including the display of the result, is completed within 30
seconds of being triggered by the processing department
-
show all gross salaries and deductions (e.g. taxes, social insurance, VBL contributions,
garnishments, direct insurance) as the result of the fictitious calculation,
-
ensure that no productive data is changed by the fictitious calculations.
PB01.02
Individual fictitious calculation (2/2)
The HR system must ensure that the fictitious calculation can be opened directly from the open or
processed personnel case without the need for additional entries (e.g. personnel number, payroll
period). The fictitious calculation functions should be designed to be low-threshold and intuitive.
PB01.03
Fictitious calculation based on fictitious input data
The HR system must also enable a fictitious calculation on the basis of fictitious input data using the
existing data by the administrator. The requirements in PB01.01 apply accordingly.
PB01.04
Labelling Fictitious calculation
The HR system must identify the results of the fictitious calculations as fictitious calculations by suitable
means when displaying them and (e.g. watermarks) in documents and provide them with a note text yet
to be defined.
PB01.05
Storage of fictitious calculation
The HR system must allow the fictitious calculation to be printed out and saved in PDF format. PB01.04
applies to the created PDF documents accordingly.
ting.
Settlement runs
Requirement
labelling
Requirement
Criterion
PB02.01
Settlement runs
For each payroll run, the HR system must automatically generate the payroll-relevant documents for
remuneration, salary, pension and retirement benefits in different output classes (e.g. Ablage in the
personnel case file, transmission to the CP for payments, printing).
A
PB02.02
Separate fictitious billing and billing runs
The HR system must enable separate fictitious payroll and accounting runs according to remuneration,
salary and pension as well as according to employer (defined by tax number).
The conditions that specify how the fictitious and billing runs must be separated must be configurable by
the central specialised administration.
A
PB02.03
Carrying out the accounting runs
A
13 December 2024 Page 242 of 366
13 december 2024
During the execution of the settlement runs, no changes may be made to
data that was entered after the start of the payroll run can be taken into account. Changes during a
payroll run must be saved, but may only be taken into account for the next payroll run.
PB02.04
Test runs
It must be possible to carry out test runs for the payroll runs in the HR system. The same requirements
(PB02.01- PB02.04) apply to the test runs as to the payroll runs. In addition, they must be time-
independent
be carried out.
A
4.7.12
Sampling control procedure
The HR system must provide a suitable solution for carrying out cross-sectional audits, currently referred to in the LAF as a
sampling control procedure. The procedure used must be based on mathematical-statistical rules so that representative
transferability of the sample results to the population of transactions is guaranteed. The selection of samples must follow the
principle of randomisation. The randomly selected tasks should be checked against certain criteria. It must be possible to define
these criteria as part of the self-customising process.
Requirement
labelling
Requirement
Criterion
SK01.01
Sampling control procedure
The HR system must ensure the implementation of a sampling control procedure in accordance with the
§§ Sections 70 to 80: No. 6.4 LHO. The selection of samples must be randomised.
A
SK01.02
General requirements for the sampling control procedure (1/2)
The HR system must enable the random sample check to be carried out before the cases to be checked
are released for further processing. The HR system must technically ensure that further processing of the
data from the random sample is excluded until the check has been completed.
A
SK01.03
General requirements for the sampling control procedure (2/2)
The HR system must allow the central specialised administration to freely set the parameters that affect
the quantitative and qualitative composition of the sample. The parameters must be able to refer to
changes in specific data fields (e.g. family allowance, social security contribution groups, bank details,
overpayment).
A
SK01.04
Establishment of a sampling control procedure
It must be possible for the centralised specialist administration to define a percentage of the processes
that are assigned to random checks.
A
SK01.05
Check requests to the processing department
The determined sampling processes must be automatically converted into inspection orders for the
processing department responsible for the sampling inspection (hereinafter "sampling inspection
inspection group").
A
SK01.06
Rejection of a task after checking
The HR system must offer the "sample check inspection group" administrator the option of rejecting a
task selected for inspection by the sample check procedure with a reason - as a free text field without a
character limit - to the original processor. This person must have the opportunity to check the task again
and correct the processing if necessary.
A
13 December 2024 Page 243 of 366
13 december 2024
SK01.07
Data access and processing of the sample
The HR system must ensure that task data from the sample cannot be edited or changed by other users or
system interventions during the manual check by the "Sample check inspection group" administrator.
A
SK01.08
Documentation sampling
The HR system must document the sample checks. All parameters applied (e.g. percentage of the
sample, data basis) must be listed.
A
SK01.09
Error management and reporting
A reporting system (evaluation of random sample cases) must be set up in the HR system for
organisational error management in the random sample control procedure, in order to be able to
evaluate the effectiveness and economic efficiency of the HR system on the basis of the findings
obtained.
to draw any necessary consequences.
A
4.7.13
Document creation - Remuneration notification
In addition to the requirements set out in section 4.1.6, which only relate to payroll accounting, the requirements for the HR
system are set out below.
Requirement
labelling
Requirement
Criterion
DK01.18
Remuneration notice
The HR system must automatically generate the remuneration notifications (salary, pension, retirement
benefit and remuneration) in accordance with the provisions of the Remuneration Certification
Ordinance.
A
DK01.19
Presentation of changes affecting remuneration
The HR system must indicate any change in the data of the personnel cases affecting remuneration since
the last remuneration notification on the following remuneration notification.
A
DK01.20
Remuneration notification - requirements criteria
The HR system must offer the Central Specialist Administration the option of setting the frequency of the
creation of remuneration notifications centrally according to the requirements criteria.
-
monthly for all personnel cases (standard),
-
only in the event of changes in the personnel case (changes in gross, net, garnishments, etc.),
-
if special criteria are met, e.g. information on information texts.
-
to be set.
A
DK01.21
Remuneration notification - manual text modules
The HR system must offer the administrator the option of using free text fields and text modules for the
remuneration notification.
A
DK01.22
Reference notification - automatically inserted text modules
The HR system should make it possible to automatically use defined text modules in the notification of
remuneration for case constellations that can be defined by the central specialised administration. The
case constellation refers to the existing data in the HR system. For example, if the family allowance or a
bonus is granted, a specific text module should be included in the remuneration notification for as long
as the specific case constellation exists.
B
13 December 2024 Page 244 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DK01.23
Remuneration notification - attachment
The HR system must make it possible to send further documents with the remuneration notification to a
group of people that can be set by the central specialised administration.
A
DK01.24
Remuneration notification - reduction in salary and official remuneration due to the granting of a
pension by an intergovernmental or supranational organisation The HR system must automatically
create a change notification as an attachment to the remuneration notification if a pension is received
from employment in the public service of an intergovernmental or supranational organisation and in the
event of reductions in accordance with § 10 LBesG MV.
A
DK01.25
Offsetting income and benefits in kind against salary
The HR system must automatically create a change notification as an attachment to the remuneration
notification when income and benefits in kind are offset in accordance with Sections 11, 12 and 80 (1)
and (2) LBesG MV.
A
DK01.26
Change notification for payroll accounting
The HR system must automatically create a (change) notification as an attachment to the salary
notification when (parts of) pension benefits are suspended.
A
DK01.27
Advance notice of remuneration notification
If payments are already being made in anticipation of a statutory or collectively agreed regulation, the HR
system must include a corresponding reference to
of the remuneration notice.
A
4.7.14
Payment/making payment
Once the remuneration has been settled, the payment must be made. The authorisation of payments includes the payment and
the posting of the payment in the HKR procedure. For this purpose, both payment transaction files must be transferred to the
payment transaction procedure and posting files to the HKR procedure.
An interface to the state's future HKR procedure (procedure for budget, cash and accounting= booking procedure) is to be
implemented. This is a system based on SAP S/4 HANA. Further details on the technical characteristics of the interface can be
found in requirement SS01.49. The ProFiskal software from UNIT4 (hereinafter "HKR inventory procedure") is currently in use. At
the request of the client, an interface to the HKR inventory procedure must also be realised for a transitional period (see
requirement SS01.20).
4.7.14.1
Requirements for the creation of the payment transaction file (payment transaction procedure PPM)
One or more payment transaction files must be created from the HR system for the payment of remuneration and transferred to
the payment transaction procedure via an interface. The payment transaction files must be transferred to the payment
transaction procedure. A payment transaction file contains the individual case-related bank-relevant payments determined from
the HR system.
Payments must be made on the collectively agreed or statutory due dates (value date). In addition, payments must be possible on
working days, among other things.
The exact description can be found in the technical interface description ST01.03 .for PPM
13 December 2024 Page 245 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ZZ01.01
Generation of a payment transaction file
As a result of the regular processing of personnel cases, the HR system must be able to generate a monthly
automated payment transaction file for transfer to the payment transaction procedure (see ST01.03 for
PPM). The file must contain all salary payments per personnel case and must be automatically transferred
to the payment transaction procedure immediately after creation.
A
ZZ01.02
Definition of the generation period of the payment transaction file
The HR system must enable the centralised specialist administration to define any regular intervals (every
working day, several times a week, monthly) for the automated generation of the payment transaction file
in accordance with ZZ01.01 (see Annex ST01.03 to PPM) in order to enable the processing department to
make further payment runs in addition to the monthly payment run.
A
ZZ01.03
Payments within the SEPA area
The HR system must enable payment transactions within the SEPA area. The payment transaction file may
only contain data records from the SEPA area.
A
ZZ01.04
Double payment control
The HR system must ensure that each payment is only included once per payment transaction file.
A
ZZ01.05
Confirmation of successful transfer of the payment transaction file
Once the payment file has been successfully created, the HR system should be able to attach a status to
the personnel case (= file has been transferred to the payment transaction procedure).
B
ZZ01.06
Accompanying payment information
The HR system must provide accompanying payment information for each payment transaction file.
as a printable document (totals check).
A
4.7.14.2
Requirements for the creation of the accounting file (HKR procedure)
All personnel expenses must be properly accounted for in accordance with the budget regulations in the HKR procedure of the
federal state. Once the remuneration has been settled, the remuneration payments must be recorded as a total entry in the
designated accounting centres in the state budget. There is no individual posting, but a total posting. This is carried out according
to the specified order via the data records generated for payment by one or more posting files. For this purpose, the HR system
creates posting files that are transferred to the HKR procedure via an interface. The booking office is made up of the individual
plan, chapter, title, sub-account and organisational unit (OUH).
Further details on the technical characteristics of the interface can be found in requirement SS01.49.
Requirement
labelling
Requirement
Criterion
ZZ02.01
Generation of a booking file (1/2)
The HR system must be able to generate one posting file for cash and one posting file for non-cash pay
postings for transfer to the HKR procedure (see ST01.02 for HKR). The posting file must be automatically
transferred to the HKR procedure immediately after creation.
The gross amounts must be totalled according to booking centres.
A
13 December 2024 Page 246 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ZZ02.02
Generation of a booking file (2/2)
The HR system must be able to generate posting files for the following facts according to the budget order.
-
Social security contributions
-
Taxes
-
Apportionments and contributions
-
VBL contributions
The booking file must be automatically transferred to the HKR process immediately after creation.
A
ZZ02.03
Protection of personal and sensitive data for bookings (total booking)
When creating the booking file, the HR system must ensure that data relating to the personnel case and
sensitive data (name of personnel case/bank details/bank transfer order/...) are not transferred to the HKR
procedure.
A
ZZ02.04
Deposit of booking centres
The HR system must enable the import of the accounting centres according to the budget (Annex 3.5
Suteda_File) and the import of the organisational units as an *.xlsx file or *.csv file. An accounting unit
consists of "section - chapter - title - sub-account - organisational unit" and is valid for one year. It must also
be possible to update the system as an import or individually during the year. It must also be possible to
maintain organisational units manually.
A
ZZ02.05
Plausibility check booking centre
A plausibility check must be provided in the HR system with regard to the booking centre and department
assigned to a person's case on the basis of a set of rules specified by the client in the implementation phase.
A
ZZ02.06
Sabbatical booking
In the case of sabbaticals (see section 4.7.10.7), the HR system must enable the posting of personnel
expenses, including posting to the provision title in the work phase as in the leave of absence phase.
A
ZZ02.07
Booking confirmations
The HR system should receive and process processing confirmations (e.g. via acknowledgement file) from the
HKR procedure (= transferred file was transferred correctly and can be used in the HKR procedure) and send
them to the central specialised administration.
can show.
B
4.7.14.3
Overarching requirements for the payment authorisation (posting and payment) of payments
The requirements of this section of the overarching requirements for the payment of remuneration must be implemented for the
posting and payment of remuneration components.
Requirement
labelling
Requirement
Criterion
ZZ03.01
Client-related, differentiated summary of payment amounts through separate posting and payment
transaction files
The HR system must ensure that a separate posting file and a payment transaction file of the payment
amounts, differentiated by organisational unit, can be created for each client. The respective naming
conventions (name of the file) from the
Interface descriptions must be observed.
A
13 December 2024 Page 247 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ZZ03.02
Payment to third parties (1/2)
In the HR system, payout recipients must be able to be other natural persons (e.g. child) and legal entities (e.g.
youth welfare office) in addition to the beneficiaries.
A
ZZ03.03
Payments to third parties (2/2)
For payments to other natural persons (e.g. child) and legal entities (e.g. youth welfare office) in addition to the
beneficiaries, it must be possible in future to indicate the reason for the payment to third parties, e.g. diversion,
reimbursement, other account, free text or similar.
A
ZZ03.04
Payment of health insurance contributions in accordance with ITSG
The HR system must enable the payment of health insurance contributions on the respective due dates based
on the electronic contribution statements per health insurance fund according to individual main company
numbers in one sum in accordance with ITSG. Section 23 SGB IV is decisive for the respective due date,
whereby all state-specific public holidays must also be taken into account in addition to the national public
holidays.
A
ZZ03.05
Withdrawal of the order release (recall)
The HR system must enable a transfer recall for payments that have not yet been paid out. The call-back must
be communicated to the National Central Fund.
means.
A
4.7.15
Tax treatment
The chapter on tax treatment covers the topics of income tax treatment and income tax registration.
4.7.15.1
Wage tax treatment
The HR system must cumulate the payroll taxes calculated for each personnel case for each payroll unit (defined by the
employer's respective tax number) and transfer these totals electronically to the HKR procedure and to the Elster interface for
registration with the tax office.
Requirement
labelling
Requirement
Criterion
SB01.01
Determination (accumulation) of payroll taxes per payroll unit
The HR system must automatically assign the calculated payroll taxes to the corresponding payroll
units and cumulate them. Payroll taxes for n tax numbers are possible for a client.
A
SB01.02
Transfer of wage tax to the HKR procedure
The HR system must automatically transfer the payroll taxes calculated and accumulated for each payroll
unit, client and tax type to the HKR procedure (interface SS01.20).
A
13 December 2024 Page 248 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SB01.03
Transfer to income tax return
The HR system must be able to allocate the taxes determined for each payroll unit and transfer them to
the respective individual income tax returns (automatic ELSTER preparation also possible). An income tax
return must be created for each tax number of the employer. Furthermore, the HR system must
automatically create a completed document in accordance with the official model of the wage tax
return.
Multiple transfers without corrections to the original declarations, in particular in accordance with
Section 153 AO, are not possible (documentation required).
A
SB01.04
Control measures
The HR system must offer and implement control measures to maintain the dual control principle and to
ensure correct tax declarations (e.g. totals of payroll units, clients and tax types result in total taxes).
A
SB01.05
Payroll account
The HR system must enable the management of calendar-year payroll accounts, in particular in
accordance with the requirements of Sections 41 and 41b EStG in conjunction with Section 4 LStDV. In
particular
-
the relevant data from the certificate issued by the tax office in accordance with Section 41 (1)
sentence 2 EStG must be transferred to the payroll account,
-
The relevant data from the HR system must be automatically transferred to the payroll account in
accordance with Section 4 (1) and (2) LStDV,
-
the type and amount of wages paid, including tax-free payments and the wage tax withheld or
transferred, must be automatically entered in the payroll account in accordance with Section 41 (1)
sentence 3 EStG,
-
the benefits pursuant to § 41 para. 1 sentence 4 EStG must be automatically entered in the payroll
account,
-
automatic entries must be made in the payroll account in accordance with Section 41 (1) sentences
5 and 6 EStG,
-
the payroll account must be closed automatically on a calendar year basis or at the end of an
employment relationship in accordance with Section 41b (1) sentence 1 EStG.
A
SB01.06
Electronic tax audit
The HR system must enable electronic tax auditing by the tax office via the digital payroll interface (see
SS01.05).
A
4.7.15.2
Income tax registration
The HR system should enable automated payroll tax registration. To do this, the HR system must enable the use of ELSTER.
Requirement
labelling
Requirement
Criterion
SB02.01
Transparency and traceability in the preparation of the tax declaration The HR system must ensure that
the preparation of the payroll tax declaration is transparent and traceable. The HR system must
automatically determine the registration data for income tax registration via an interface (automatic
query of the insurance number at the pension insurance data centre, see SS01.04).
A
13 December 2024 Page 249 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SB02.02
Automation and media disruptions
The HR system must enable payroll tax registration to be carried out automatically. If necessary, the HR
system must request any missing data from the centralised specialist administration. It must be ensured
that the payroll tax registration process is transparent and traceable.
A
SB02.03
ELSTER certificate properties
The HR system must display the ELSTER certificate properties.
A
SB02.04
Use of ELSTER
The HR system must enable the use of ELSTER via interfaces (automatic query of the insurance number
at the pension insurance data centre and paying agent registration procedure, see SS01.04). It must be
possible to use this for several clients.
A
SB02.05
Registration and deregistration with ELStAM, retrieval of change lists
The HR system must be connected via the interface (accident insurance UV wage statement, see SS01.04).
-
Registration and deregistration in the ELStAM database, including the processing of the
corresponding confirmations,
-
the retrieval of the monthly change lists and
-
enable the import of the retrieved data into the monthly billing.
A
SB02.06
Transmission protocols
The HR system must transfer the transmission logs for the wage tax returns to the document
management system (DMS).
A
SB02.07
Timely transmission
The HR system must transmit the payroll tax returns automatically via the SB02.07 interface by the
deadline, i.e. by the 10th of the following month at the latest.
A
SB02.08
Printout of the wage tax certificate data
The HR system must be able to collate the wage tax certificate data in one document.
A
SB02.09
Printout of the transmitted wage tax certificate data
The HR system must also be able to compile the electronically transmitted wage tax statement data in a
single document during the year.
A
4.7.16
Garnishments, assignments and offsetting
As part of the calculation of charges, the processing of
- ordinary seizures,
- Maintenance seizures,
- Assignments,
- Offsetting and
- Insolvency cases
be possible. Insofar as only "seizures" are mentioned in the requirements, this refers to the usual seizures.
This refers to the seizures and maintenance seizures.
13 December 2024 Page 250 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.01
Processing of ordinary seizures
The HR system must enable the processing of ordinary seizures.
A
PF01.02
Processing of maintenance seizures
The HR system must enable the processing of maintenance seizures.
A
PF01.03
Processing of assignments, offsetting and insolvency cases
The HR system must facilitate the processing of
-
Assignments according to §§ 398 ff. BGB,
-
Offsetting in accordance with §§ 387 ff. BGB and
-
insolvency cases.
A
PF01.04
Types of seizure
In addition to the types of garnishment specified in PF01.01(Processing of ordinary garnishments) -
PF01.03(Processing of assignments, set-offs and insolvency cases), the HR system must also process the
following types of garnishment
-
Attachment of the payment amount and
-
Enable attachment of a manually specified amount for
special cases.
A
PF01.05
Recording of creditors
The HR system must enable the recording of creditor data. This includes in particular
-
Name,
-
First name,
-
Company
-
IBAN
-
Creditor file number
A
PF01.06
Historised status
The HR system must enable a status including its history for each garnishment task. The following statuses
must be enabled:
-
active: Garnishment must be taken into account when calculating the amount to be paid out,
-
Dormant: the creditor has suspended the attachment or insolvency proceedings have been opened
(to be set manually),
-
cancelled: the creditor has waived the assertion of the claim (to be set manually),
-
Done: Repayment plus ancillary benefits and interest has been made in full or after discharge of
residual debt in the event of insolvency,
-
settled by correspondence.
A
PF01.07
Display of attachment tasks and filtering by status
The HR system must display all garnishment tasks in an overview for processing. The HR system must
hide the garnishment tasks with the status "cancelled", "completed" and "completed by
correspondence" by default. It must be possible to show these garnishment tasks once the processing
has been selected.
It must be possible to call up the attachment tasks from the overview.
A
PF01.08
Automated deletion
The HR system must be able to recognise attachment tasks with the status "cancelled", "completed" and
"completed by correspondence" 5 years after the status change following release.
The individual tasks are deleted by the processing department.
A
13 December 2024 Page 251 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.09
Representation of the calculation
The HR system must present the calculation of seizures, assignments and set-offs, including partial
results, in a detailed and comprehensible manner.
A
PF01.10
Printout of the calculation
The HR system must be able to export the calculation of seizures, assignments and set-offs including
partial results in DOCX format.
A
PF01.11
Net method
The HR system must calculate the attachable amounts using the net method in accordance with the
judgement of the Federal Labour Court (BAG, judgement of 17.04.2013, 10AZR 59/12).
A
PF01.12
Development principle
The HR system must allocate subsequent payments/back payments to the payment section for which
they are subsequently paid in accordance with the accrual principle (BGH ruling of 24 January 2018, VII
ZB 21/17).
The HR system must perform a comparative calculation:
-
What should have been seized in the month of recalculation?
-
What has already been seized?
The HR system should transfer the difference as an attachable amount to the respective creditor.
An additional payment may not be added to the current month's salary for the purpose of checking the
garnishment limit.
A
PF01.13
Parallel, limited recording of active seizures
The HR system must be able to record a total of 50 active garnishments, assignments or offsets per
personnel case in parallel.
A
PF01.14
Parallel, unlimited recording of active seizures
The HR system must be able to record active garnishments, assignments and set-offs in parallel for each
personnel case without any numerical limits.
A
PF01.15
Parallel recording of cancelled and completed withholdings
The HR system must store cancelled and completed withholdings for each personnel case without a
numerical limit.
A
PF01.16
Manual determination of the order of priority of seizures, assignments and set-offs
The HR system must be able to manually determine the ranking of attachments, deductions and
and offsetting and to change this order of precedence.
A
13 December 2024 Page 252 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.17
Automated determination of the ranking of seizures, assignments and set-offs
The HR system must automatically determine the ranking of seizures, assignments, set-offs and
insolvencies in accordance with the legal requirements using the following data:
-
Access data for attachment and transfer orders (Section 804 (3) ZPO),
-
Access data of seizure and collection orders for public law claims (e.g. Section 309 AO),
-
Dates of signing assignments (§ 398 BGB),
-
dates on which the offsetting situation arises (§§ 387 ff BGB) and
-
Date of the opening decision.
The HR system must automatically determine attachments of the same rank using the access data (date
and time of delivery) and automatically flag them.
A
PF01.18
Calculation according to ranking
The HR system must calculate each garnishment, assignment or set-off according to the order of priority
with its special features. The HR system must make it possible to combine the types of garnishment for
each individual case.
A
PF01.19
Transfer to creditor
The HR system must enable the transfer to the respective creditor.
A
PF01.20
Seizure without transfer
The HR system must enable seizures without transfer, e.g. in accordance with Section 845 ZPO.
A
PF01.21
Garnishment of the annual wage tax equalisation
The HR system must enable the garnishment of the annual wage tax equalisation as part of each
withholding.
A
PF01.22
Annual adjustment of the garnishment exemption limit notice
The HR system must automatically implement the annual garnishment exemption limit announcement.
This also includes the adjustment of the garnishment allowances for the annual special payment and the
special payment.
A
PF01.23
Manual labelling of attachments of equal rank and automated allocation of the attachable amount
The HR system must enable the clerk to manually mark attachments of equal priority.
The HR system must automatically divide the attachable amount among the attachments of equal rank
based on the ratio of the debt of the individual attachment to the total debt.
A
PF01.24
Manual division of the attachable amount
The HR system must enable the clerk to manually divide the attachable amount among the attachments
of equal rank.
A
PF01.25
Automated determination of attachable earned income
The HR system must include the attachable earned income in accordance with Sections 850, 850a,
850c, 850e ZPO automatically.
A
13 December 2024 Page 253 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.26
Recognition of third-party labour income
The HR system must enable the recording of third-party labour income (aggregation decision) in
accordance with Section 850e Nos. 2 and 2a ZPO.
A
PF01.27
Recognition of emoluments withdrawn from garnishment
According to Section 850e No. 1 ZPO, the HR system must enable the recording of emoluments that are
exempt from garnishment (e.g. contributions to the private health insurance of civil servants).
A
PF01.28
Manual recording of the number of dependants
The HR system must allow the number of persons liable to pay maintenance to be entered manually
when calculating garnishments, assignments, set-offs and insolvency cases in accordance with Section
850c ZPO (according to the table).
A
PF01.29
Calculation of the partial non-inclusion of persons liable for maintenance The HR system must
automatically calculate the partial non-inclusion of persons liable for maintenance in accordance with the
decision of the OLG Oldenburg of 26 September 1994 - 2 W 95/94 or according to the garnishment
calculator, e.g. atwww.judis.info/downloads , when calculating the ordinary garnishment in accordance
with Section 850c (6) ZPO (according to the table).
A
PF01.30
Consideration of all seizure limits
The HR system must automatically take into account all garnishment limits (basic amount, allowance for
other dependants, maximum amount) when calculating the ordinary garnishment pursuant to Section
850c ZPO (in accordance with the table).
A
PF01.31
Recording of the attachable amount
The HR system must allow the garnishable amount to be entered when calculating the ordinary
garnishment pursuant to Section 850c ZPO (in accordance with the table).
A
PF01.32
Recording of a deductible
When calculating the ordinary garnishment in accordance with Section 850c ZPO (according to the
table), the HR system must enable the recording of a retention determined by the local court in
accordance with Section 850f ZPO as a fixed amount.
A
PF01.33
Recording of non-garnishable amounts
The HR system must be used when calculating the ordinary garnishment in accordance with Section 850c
ZPO (as per table)
-
the recording of an additional percentage of the excess amounts that are to remain unattachable
and additionally
-
the recording of a fixed amount, e.g. if maintenance actually paid is to be taken into account,
enable.
A
PF01.34
Calculation of the amount to be paid for the garnishment
The HR system must calculate the amount to be paid for the garnishment when calculating the ordinary
garnishment pursuant to Section 850c ZPO (in accordance with the table).
A
PF01.35
Attachment of maintenance - Recording of an unattachable amount
According to Section 850d ZPO, the HR system must enable the recording of an unattachable amount
determined by the local court in the context of maintenance seizures.
tions.
A
13 December 2024 Page 254 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.36
Maintenance garnishment - consideration of non-garnishable amounts
The HR system must determine the non-garnishable amounts in the case of a maintenance garnishment
according to
§ Section 850 d sentence 2 ZPO in conjunction with Section 850 a ZPO, in particular
-
¼ Compensation for overtime,
-
½ holiday pay and ½ anniversary bonus,
-
½ Consider Christmas
bonus.
A
PF01.37
Maintenance garnishment - Automated determination of attachable earned income
The HR system must automatically determine the attachable earned income in accordance with Section
850d ZPO.
A
PF01.38
Maintenance garnishment - Recording the earned income of third parties
The HR system must enable the recording of third-party earned income (aggregation order) in the event
of a maintenance attachment.
A
PF01.39
Maintenance garnishment - Recording of income withdrawn from garnishment
The HR system must make it possible to record payments withdrawn from garnishment (e.g.
contributions to the private health insurance of civil servants) in the event of a maintenance obligation.
A
PF01.40
Calculations in the context of maintenance seizure
The HR system should automatically calculate maintenance arrears and current maintenance as part of
maintenance garnishments. The payment of current maintenance and, if possible in terms of the
attachable amount, the reduction of the arrears should be taken into account. If the attachable amounts
are not sufficient for the payment of current maintenance, the arrears should be built up automatically.
It should also be possible to specify this manually.
B
PF01.41
Maintenance garnishments - recording of non-garnishable amounts
The HR system must allow for the recording of an additional percentage and fraction (e.g. 0.75 or 1.5 or
2/3) of the excess amounts that are to remain unattachable.
A
PF01.42
Comparison calculation between maintenance garnishment and ordinary garnishment According to
Section 850d (1) sentence 3 ZPO, the HR system must carry out a comparison calculation between
maintenance garnishment pursuant to Section 850d ZPO and ordinary garnishment pursuant to Section
850d ZPO.
§ Section 850c ZPO. The HR system must calculate the attachable amount in accordance with Section
850d ZPO on the one hand and Section 850c ZPO on the other. The HR system must then initiate the
transfer of the higher of the two amounts to the creditor.
A
PF01.43
Assignment and offsetting - recording the number of persons liable for maintenance The HR system
must enable the processing department to record the number of persons liable for maintenance in the
case of assignments and offsetting.
A
PF01.44
Assignment and offsetting - recording of emoluments withdrawn from the garnishment The HR system
must, in accordance with § 850e in conjunction with § 400 BGB (assignment) or in conjunction with § 394
BGB (offsetting), enable the processing department to record emoluments withdrawn from the
garnishment in the case of assignments and offsetting (e.g.
private health insurance for civil servants) can be recognised.
A
13 December 2024 Page 255 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PF01.45
Assignment and set-off - calculation of the amount to be paid to the creditor
The HR system must calculate the amount to be paid to the creditor for assignments and set-offs.
A
PF01.46
Assignment and set-off - calculation of the attachable amount
In the case of assignments and set-offs, the HR system must calculate the attachable amount of the
assignment or set-off in accordance with Section 850e ZPO Nos. 2 and 2a in conjunction with Section
850c ZPO.
A
PF01.47
Assignment and set-off - consideration of the seizure limits
The HR system must automatically take into account all garnishment limits (basic amount and
allowances for other dependants) for assignments and set-offs.
A
PF01.48
Insolvency cases and maintenance garnishments - End of payment
The HR system must enable the recording of the end date in insolvency cases in accordance with Section
287 (2) InsO and in the case of seizures of assets.
The HR system must automatically stop garnishment payments for insolvency cases and maintenance
garnishments once the end date has been reached.
A
PF01.49
Insolvency cases - ranking of the activation of existing seizures
In the event of insolvency, the HR system should reactivate seizures that exist after the end date
according to the order of priority.
B
PF01.50
Insolvency cases - calculation of the attachable amount
In the event of insolvency, the HR system must enable the garnishable amount to be calculated in the
same way as the usual calculation of the garnishable amount in the HR system.
A
PF01.51
Data collection, continuation and interest calculation
The HR system must enable the separate recording and continuation of the following for all seizures,
assignments and offsetting:
-
Principal debt with interest,
-
Principal debt without interest,
-
Costs with interest,
-
Costs without interest and
-
interest already recognised.
Furthermore, the HR system must be able to
-
of a manual interest rate,
-
different manual interest rates,
-
an interest rate above the current base interest rate and
-
an interest rate above the current base rate combined with additional specification of a manual
interest rate
enable.
The HR system must enable interest to be calculated for all attachments, assignments and set-offs from
a date specified in the decision and on a monthly basis.
A
PF01.52
Document creation - seizure sheets
The HR system must enable the creation of garnishment sheets in accordance with the model in Appendix
3.7 (model garnishment sheet) or a comparable monitoring option.
The monthly continued/removed garnishment amounts can also be used as a basis.
A
13 December 2024 Page 256 of 366
13 december 2024
Requirement
labelling
Requirement
PF01.53
Presentation of seizable amounts transferred
The HR system must clearly display the amounts subject to garnishment for each personnel case on a key
date determined by the administrator and make the overview exportable in DOCX format.
PF01.54
Presentation of garnishments/assignments/offsets to be serviced
The HR system must clearly display the garnishments/assignments/charges to be prioritised for each
personnel case on a specific key date
and make the overview exportable in DOCX format.
4.7.17
Objection handling
The objection handling processes are downstream processes in the remuneration procedure. Personnel cases can lodge an
objection in the Salaries and Benefits (incl. retirement benefits) departments in order to obtain full or partial relief if, for example,
there are doubts about the amount of the determined remuneration or a preparatory decision for this. The HR system must map
the objection handling processes.
Incoming letters are recorded in the HR system and automatically assigned to the associated remuneration tasks. The clerk must
be able to call up objections from the objection directory as a central overview for processing. As part of the processing, the
processing department decides on a remedy. If a partial remedy or rejection is considered, the task must be transferred to the
legal department. In this case, further processing takes place in the HR system by the legal department. When documents are
sent, automatic resubmissions should be set for processing (WF02.21 (Automated resubmissions of tasks)).
Administrative court and labour court complaints are also processed. File documents and letters are exchanged with the courts
via the special public authority mailbox (beBPo) (see SS01.43).
Irrespective of this, change requests are processed as amendments to previous decisions. In the specialist areas of salaries and
pensions (including retirement benefits), an amendment application is an application in accordance with Sections 32, 48, 49 and
51 of the MV State Administrative Procedure Act. In the area of remuneration, objections are made by means of a simple letter, if
necessary with reference to the preclusive period of § 37 TV-L.
In addition, costs, fees and expenses must be recorded in the HR system in accordance with the German Court Costs Act and the
German Lawyers' Fees Act and checked for plausibility on the basis of an application for the determination of costs.
Finally, the HR system must allow for the processing of complaints from supervisors.
Requirement
labelling
Requirement
Criterion
WS01.01
Objection processing
The HR system must facilitate the successive processing of appeals.
by several clerks.
A
13 December 2024 Page 257 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WS01.02
Process flow for handling objections
Objection processing must be implemented in the HR system in accordance with the specific flow chart in
Appendix 3.8 (Objection process).
A
WS01.03
Lawsuit processing
The HR system must enable the processing of complaints.
A
WS01.04
Change request processing
The HR system must enable the processing of change requests.
A
WS01.05
Contradiction - missing assignment
In the HR system, the case handler must be able to transfer the objection to the area of responsibility of
the departmental group manager if no initial decision or remuneration notification was found on the
basis of the data entered for the objection task.
A
WS01.06
Appeal - rejection notice
The HR system must be capable of recognising appeals that have not been received on time on the basis of
the input data recorded for the notification of receipt and the appeal and the applicable appeal deadlines,
and of notifying the processing department that the deadline has been exceeded.
Furthermore, the HR system must be capable of recognising formally invalid objections by means of non-
qualified signed e-mails with PDF attachments and indicating the formal invalidity to the processing
department.
In both cases, the HR system must automatically provide the processing department with a rejection
notice, using document templates and text modules that can be edited by the Central Specialist
Administration.
A
WS01.07
Objection - finalisation of the objection task at any time
The HR system must offer the clerk the option of finalising the objection task at any time - even without
issuing a decision - if
z. e.g. the objection has been withdrawn. The case handler must be able to select a reason for closure
from a list. The list of closure reasons must be editable by the central specialised administration.
A
WS01.08
Objection - forwarding to the Remuneration Department
The HR system must be capable of forwarding the objection task to several clerks via a route that can be
configured by the Central Administration. The current route, which the contractor must initially store in
the HR system, is summarised in Appendix 3.9 (Appeal route).
A
WS01.09
Delivery note
The HR system must make it possible to document the submission of the objection task (e.g. from the
remuneration department to the legal department). The date of submission must be recorded. If the
submission is not made via a document, a free text field without a character limit is required.
A
WS01.10
Objection - reading of postal delivery certificate and acknowledgement of receipt
The HR system should be able to automatically read out the electronic (KP for remuneration) or digitised
(input management) return of postal delivery certificates and receipts after delivery of the notice of
remedy/objection, monitor them with resubmissions and assign them to the person(s) responsible for the
notification.
to the relevant opposition proceedings.
B
13 December 2024 Page 258 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WS01.11
List of objections and complaints
The HR system must enable the LAF case handler, the head of department and the head of department
group to view a central list of appeals and complaints in accordance with the access authorisations. This
directory must contain all remuneration tasks with assigned open and completed objection and
complaint tasks, including the associated documents.
A
WS01.12
List of objections and complaints - manual entry
For each objection task, the HR system must make it possible to manually
-
the basic data of the task (in particular surname, first name, date of birth and personnel number),
-
the responsible clerks and the historical clerks,
-
the keyword as a thematic categorisation of contradictions (e.g. officially measured alimentation),
-
comparing requested and incoming documents,
-
Resubmissions,
-
the area of law (salaries, pensions, retirement benefits)
-
the status of the objection task (in process at the reference office, hearing at the reference office,
in process at the legal office, hearing at the legal office, suspended, decision issued and sent, task
completed (delivered)) and its history,
-
the date of submission and
-
the type of settlement (in particular remedy, partial remedy, rejection, withdrawal)
can be recorded and customised.
The HR system must continue to make it possible for each claim task to be manually
-
the court,
-
the file number of the court,
-
the date of receipt of the complaint and
-
the plaintiff/counterclaimant can be recorded and adjusted.
A
WS01.13
The HR system must make it possible to call up the appeal and complaint tasks, including the associated
documents, from the appeal and complaint directory.
A
WS01.14
List of objections and complaints - Automated logging of the status of proceedings
The HR system must be automated in the list of objections and complaints for each objection task.
-
the basic data of the task,
-
the responsible clerks and the historical clerks,
-
Status changes of the objection task,
-
the history of the status of the opposition task and
-
the submission date
and update them continuously.
A
WS01.15
List of objections and complaints - comments field
The HR system must include a free space for each task in the list of objections and complaints.
text field without character limit for comments.
A
13 December 2024 Page 259 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WS01.16
List of oppositions and actions - selection of opposition and action tasks and their combination
The HR system must enable the case handler to select (filter and sort) the objection and complaint tasks
in the objection and complaint directory according to the following characteristics, including their
combination:
-
the basic data of the task,
-
the person in charge,
-
Periods (in particular date of receipt, date of completion),
-
Keywords,
-
Resubmissions,
-
the legal field,
-
the status of the objection task,
-
the type of fulfilment,
-
the court,
-
the judicial branch,
-
the file number of the court,
-
the date of receipt of the complaint and
-
the plaintiff/counterclaimant.
The HR system must save the individual user settings for the filter and sorting function for each case in
the list of objections and complaints.
A
WS01.17
List of objections and complaints - editing of keywords, status, types of settlement and courts
The HR system should enable the central specialised administration to create, adapt and delete (edit)
keywords, status details of the appeal task, types of processing and courts, including the address for use
in the appeal and action directory (e.g. as a drop-down field).
B
WS01.18
List of objections and complaints - Highlighting of data fields
The HR system must enable the central specialist administration to highlight data fields in the list of appeals
and complaints in multiple colours (e.g. different colour coding of the responsible case handlers).
A
WS01.19
Compilation of the case file
The HR system must offer the clerk the option of entering the data relating to the objection.
-
Documents and
-
Contents from input overviews ("masks") and comment fields
in the form of an automatically generated, separate PDF file (divided into several separate PDF files if the
file size exceeds 30 MB). Individual documents/contents must be selectable, deselectable and sortable.
A
WS01.20
Cost assessment in opposition and appeal proceedings - data input The HR system must support the
processing of cost assessments. In particular, it must support the manual entry
-
the charge number,
-
of the amount in dispute,
-
costs, value fees, framework fees and expenses,
-
the rate of a fee and
-
of the euro amount
must be possible. It must also be possible to enter charge numbers and then automatically transfer the
euro amount. The recorded data
must be modifiable and available for document creation.
A
13 December 2024 Page 260 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WS01.21
Determination of costs in opposition and appeal proceedings - plausibility check The HR system must
check the plausibility of the data entered for the determination of costs. In particular, it must compare
the data entered with the tables for labour court and administrative court proceedings in the Court Costs
Act and the Lawyers' Fees Act and check the arithmetical accuracy of the amounts (incl. totals, VAT).
Furthermore, the HR system must check whether framework fees are within the limits specified by the
respective law. The HR system must check the processing for the result
of the plausibility check.
A
13 December 2024 Page 261 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
WS01.22
Supervisory complaints
The HR system must enable the processing of complaints and complaints about supervision (hereinafter
referred to as "complaints about supervision"). The processing of supervisory complaints must include
the following:
-
Manual assignment of documents from input management or by e-mail to the task of the official
complaint,
-
Automated pre-filling of the input mask (if available) and of documents with master data (name,
address, personnel number),
-
Ablage of complaints about official supervision in separate tasks; also separate ablage for an
objection task, insofar as an objection also contains a complaint about official supervision
(separate tasks),
-
Automated e-mail notification to users to inform them that an official complaint task has been
made available for further processing or decision. The group of recipients of the notifications
should be configurable by the central specialised administration. The group of recipients follows
the assignment of the supervisory complaint task to the personnel case (e.g. if the personnel case
receives pay, the notification is sent to the head of the departmental group for pay, among others)
-
process control to be implemented by the contractor:
1.
Input management
2.
Forwarding to the complaints department
3.
Forwarding to departmental group management
4.
Forwarding to head of department
5.
Forwarding to departmental group management
6.
Forwarding to the complaints department
7.
Forwarding to director
8.
Forwarding to the complaints department
9.
Output management,
-
Forwarding of the official complaint task to other users in the HR system for further processing and
approval,
-
Automated read/write authorisation assignment for the relevant tasks (e.g. previous
correspondence, telephone notes, applications, notifications, also for the appeal task (objection
and complaint)) after the assignment of the supervisory appeal task to the processing department,
-
Attach notes in the task (comments field),
-
Attach notes on the course of business to official supervisory complaint tasks (approval,
acknowledgement, consultation, rejection, other, free text),
-
Marking of individual documents of the personnel case, e.g. from the area of remuneration,
supply, pay or linking to the supervisory complaint task, so that these are shown as central
documents in the supervisory complaint task for further processing.
-
Preparation and Ablage of response letters within the supervisory authority task.
-
Additional Ablage of reply letters as copies in the tasks for perso
The following are examples of cases from the area of salaries, pensions and wages.
A
4.7.18
Reclaiming remuneration
In the event of an overpayment, e.g. due to incorrect entries, excess advance payments or unauthorised payment of
remuneration, a repayment is initiated in the HR system via the downstream repayment process. The reclaiming of overpaid
remuneration is based, among other things, on § 15 LBesG MV, § 10 Para. 5 LAltGG MV, § 52 LBeamtVG MV, § 48 BeamtStG, § 37
TV- L, § 59 LHO, §§ 387 ff. BGB and §§ 812 ff. BGB.
13 December 2024 Page 262 of 366
13 december 2024
Recovery tasks are processed in the Salaries and Pensions (incl. retirement benefits) departments using the same process. After
the recovery task has been checked by the administrative department and the personnel case has been heard, the administrative
department selects whether the overpayment is to be repaid by offsetting, offsetting or repayment.
Reclaim tasks are processed in the Remuneration department according to a modified process. After the recovery task has been
checked by the administrative department, the recovery letter is sent without a hearing. This letter informs the employee that
the overpayment must be paid in one lump sum. If the personnel case subsequently requests an offset, for example, this is
carried out.
The documents that are created as part of the processes in accordance with sections 4.1.6 and 4.7.13 (document creation and
document creation - remuneration notification) contain a cash register number. This is used to make payments in order to clearly
allocate the payment to the individual claim and is generated in the HR system. After the offsetting declaration/the offsetting
declaration/the reclaim notice/the reclaim letter, a transfer is made to the payment preparation department so that a TARGET
position is initiated there for budgetary purposes. Reclaims are processed and monitored using the reclaim list within the HR
system. The HR system monitors the offsetting/offsetting against the future remuneration claim and assigns an end date to it. If a
reclaim amount is outstanding after the end date, the administrator is informed that the end date has passed and is given the
opportunity to decide on the reclaim again (see WF02.20 Resubmission with condition). The payments made in the payment
authorisation (outside the HR system) are reported by the payment authorisation to the HR system, which assigns the
confirmation to the corresponding reclaim task.
Requirement
labelling
Requirement
Criterion
RF01.01
Determination of the overpayment amounts
The HR system must automatically determine the gross and net overpayment amount. It must be possible to
change the overpayment amounts manually.
A
RF01.02
Deduction of contributions and current taxes attributable to the overpayment The HR system must
automatically deduct the social security contributions, supplementary pension contributions and current
taxes attributable to the overpayment from the overpayment.
It must be possible to offset net overpayments that have arisen in the current year and are also repaid, as
decided by the administrative department. The gross method must be used for reclaims relating to the
previous year, older periods or other payments regardless of the period, i.e. a taxable overpayment must be
built up. The reduction of the taxable overpayment must be carried out manually and automatically
(different application in the departments) in the case of existing taxable income (indirect tax refund); a
negative certificate (ELSTER) must be generated in the case of leavers.
A
RF01.03
Reclaiming salary/pension/retirement benefits
The processing of salary, pension and retirement benefit reclaims in the HR system must be implemented in
accordance with the specific flowchart in Appendix 3.10 (Rückforderungsprozess_BE_VE_AG).
A
13 December 2024 Page 263 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
RF01.04
Reclaim process Remuneration
The processing of reclaims of remuneration in the HR system must be implemented in accordance with the
specific flow chart in Appendix 3.11 (Reclaim process_EG).
A
RF01.05
(Partial) redemption combined with reclaim
The HR system should enable the processing department to link a (partial) cancellation of a decision (e.g. on
the length of service) with a reclaim within a process flow.
B
RF01.06
Reduction of the overpayment
The HR system must enable the administrator to reduce an overpayment several times, each time selecting
a reason from a drop-down list. The reduction with the calculation on which it is based must be
-
in per cent,
-
as amount and
-
with a recorded date (limitation/exclusion period)
be possible. TheHR system must enable the centralised specialist administration to edit the selectable
reasons.
A
RF01.07
Manual entry of the cash register number
The HR system must offer the clerk the option of manually entering a new cash register reference for each
task, e.g. for the acceptance order and the various return letters, and storing it in the task. The HR system
must check the plausibility of the structure of the cash register number entered, which corresponds to the
following specifications:
-
The cash register symbol consists of 13 digits in the sequence XXXXHHHZZZZZZP.
-
The cash register symbol should be displayed with 4 characters per block: XXXX HHZZ ZZZZ P.
-
The first four digits (XXXX) stand for the organisational unit (OUH) used for the booking.
-
The following two digits (HH) represent the last two digits of the financial year.
-
The following six digits (ZZZZZZ) represent a consecutive number.
-
The last digit (P) is a check digit, which is calculated according to DIN ISO 7064, Mod 11.10.
The organisational unit results from the assignment of the payment case to the department.
A
RF01.08
Automated generation of the cash register code
The HR system must offer the option of automatically generating a new cash code for each task using a
defined cash code range in accordance with the following specifications and storing it in the task:
-
The cash register symbol consists of 13 digits in the sequence XXXXHHHZZZZZZP.
-
The cash register symbol should be displayed with 4 characters per block: XXXX HHZZ ZZZZ P.
-
The first four digits (XXXX) stand for the organisational unit (OUH) used for the booking.
-
The following two digits (HH) represent the last two digits of the financial year.
-
The following six digits (ZZZZZZ) represent a consecutive number.
-
The last digit (P) is a check digit, which is calculated according to DIN ISO 7064, Mod 11.10.
The organisational unit results from the assignment of the payment case to the department.
A
13 December 2024 Page 264 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
RF01.09
Automated check with decision template
In the event of an overpayment, the HR system should carry out automated checks, in particular on
-
Regularity of salary payments,
-
Possibility of offsetting the full overpayment amount within one year,
-
Reaching the end of the limitation period/exclusion period and
-
Exceeding a limit amount of the overpayment (e.g. small amount regulation, overpayments over
10,000 euros are not offset)
The possible recovery options (offsetting, offsetting, recovery) based on the audit results should be
displayed to the processing department for a decision. The HR system must enable the central specialised
administration to change the limit amounts of the overpayment.
B
RF01.10
Offsetting
In the event of an overpayment, the HR system must enable offsetting depending on the legal relationship
or entitlement. The HR system must enable the administrator to prevent offsetting.
A
RF01.11
Offsetting
In the event of an overpayment, the HR system must enable offsetting against future remuneration
depending on the legal relationship or entitlement. The HR system must make it possible for the
administrator to link offsetting with current payments and to enter an instalment recalculation.
A
RF01.12
Choice of payment methods
The HR system must enable processing,
-
the offsetting amounts,
-
the payments in monthly instalments and
-
the payment in one sum
to be recorded. In the case of offsetting and instalment payments, a repayment plan must be created
automatically for internal monitoring of the repayment of the overpayment. The repayment amount must
be changeable by the clerk.
A
RF01.13
Transfer of an acceptance request to the HKR procedure (target position in the HKR procedure)
The HR system must be able to transfer the repayment-relevant data, including the cash register symbol, as
an acceptance request (TARGET position in the HKR procedure) to the HKR procedure (see ST01.02) via an
interface. Data transfer must be possible both automatically after a document has been sent and by the
clerk.
A
RF01.14
Amendment of the acceptance order
The HR system should be able to transmit changes to the acceptance requests to the HKR procedure at any
time, both automatically after a document has been sent and by the clerk via the interface (see ST01.02).
e.g. in the case of subsequently agreed instalment payments, changes to deadlines, changes to the
overpayment amount).
B
RF01.15
Transfer to the HKR procedure for offsetting/offsetting (actual posting in HKR procedure to target
position)
The HR system should automatically transfer each individual offsetting/settlement that takes place within
the HR system to the HKR process via an interface (see
ST01.02) are handed over.
B
13 December 2024 Page 265 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
RF01.16
Interruption and continuation of the acceptance order
The HR system must interrupt and continue the acceptance request (TARGET position) in the HKR
procedure via an interface (see ST01.02) after selection by the clerk.
A
RF01.17
Confirmation of incoming payments
The HR system must be able to monitor incoming payments transmitted by the HKR procedure via an
interface (see ST01.02) and assign them to the corresponding recovery task.
A
RF01.18
Repayment of overpayments
The HR system must enable the amortisation of overpayment amounts (differentiated according to taxable
overpayment and net overpayment) per original budget title (e.g. remuneration or the respective
allowance).
A
RF01.19
Note on expiry of a deadline
The HR system must notify the processing department when a deadline specified in the reclaim task expires.
A
RF01.20
Continuation of a reclaim in the event of a change of legal relationship or claim
The HR system must make it possible to continue processing the overpayment in the event of a change of
legal relationship or entitlement (e.g. an employee becomes a civil servant or an active civil servant retires)
and the associated change in processing. The HR system must automatically make the postings to the
correct budget items when the change occurs.
A
RF01.21
Note on changes to payment-relevant data
The HR system should automatically notify the administrator of any changes to data that are relevant for
offsetting, settlement or repayment (e.g. cessation of payment of remuneration or change in the amount of
remuneration).
B
RF01.22
List of reclaims
The HR system must offer the option of viewing a centralised reclaim directory in accordance with the
access authorisations (rights and roles concept). This directory must contain all current and completed
overpayments and reclaims, including the associated documents.
A
RF01.23
Reclaim register - manual entry
The HR system must make it possible for each reclaim task to be performed manually.
-
the responsible clerks and the historical clerks,
-
Deadlines (incl. due date of the target position),
-
Resubmissions,
-
the legal area (salary, pension, retirement benefits, remuneration),
-
the interest rate after the deadline (yes/no) and
-
the status of the recovery task (open, in progress, completed) can be recorded and
adjusted.
A
RF01.24
Reclaim directory - Calling up tasks and documents
The HR system must be able to call up the recovery tasks directly, including the
The data can be retrieved from the recovery register using the corresponding documents.
A
13 December 2024 Page 266 of 366
13 december 2024
Requirement Request
Labelling
Criterion
Requirement
labelling
Requirement
Criterion
RF01.25
Reclaim register - Automated logging of the process status The HR system must automatically log the
status of each reclaim task in the reclaim register.
-
the basic data of the task (in particular surname, first name, date of birth and personnel number)
-
the responsible clerks and the historical clerks,
-
Deadlines,
-
Resubmissions based on the deadline and
-
store and continuously update the status of the recovery task and its
history.
A
RF01.26
List of reclaims - remarks field
The HR system must contain a free text field without a character limit for comments in the reclaim list for
each task.
A
RF01.27
Recovery list - selection of recovery tasks
The HR system must enable the clerk to select (filter and sort) the reclaim tasks in the reclaim directory
according to the following characteristics, including their combination:
-
the basic data of the task,
-
the person in charge,
-
periods,
-
Deadlines,
-
Resubmissions,
-
the legal field and
-
the status of the recovery task.
The HR system must save the individual user settings for the filter and sorting function for each case in the
reclaim directory.
A
RF01.28
Reclaim directory - editing the status
The HR system should enable the centralised specialist administration to create, adjust and delete (edit) the
status of the reclaim task (for use in the reclaim directory (e.g. as a drop-down field)).
B
RF01.29
Reclaim list - highlighting of data fields
The HR system should enable the central specialist administration to highlight data fields in the reclaim
directory in multiple colours (e.g. different colour coding of the responsible clerks and different colour
coding of the data fields).
Marking of the task according to the area of law).
B
4.8
Electronic Personalakt/Electronic Personnel Administration
The following chapter contains the functional and technical requirements for the HR system with regard to the "Electronic
Personalakt" and "Electronic Personnel Administration" functional areas.
4.8.1
Overarching requirements
4.8.1.1
General requirements
13 December 2024 Page 267 of 366
13 december 2024
ePAePV-A0983
Storage of data
The HR system is intended to enable the administrative departments to view retired personnel cases
without pension entitlements in the HR system for as long as the Personalakt as a whole may be retained in
accordance with the deletion concept.
B
ePAePV-A1160
Anonymisation of data
The HR system must be able to anonymise personal data instead of deleting it. The anonymised data must
continue to be available for statistical evaluations in particular.
A
ePAePV-A1164
Checking the input before data transfer
If a large amount of data is changed in the HR system by the departmental administrator (e.g. new creation
of a personnel case), the HR system must display the data to the same departmental administrator before it
is transferred to the HR system.
A
ePAePV-A1165
Transfer of entered data
Once the data from ePAePV-A1164 has been checked by the departmental administrator, it must be
released by the departmental administrator for transfer to the HR system.
A
ePAePV-A1197
Resubmissions on data fields
The HR system must enable the processing departments to make resubmissions to data fields.
A
ePAePV-A0017
Exchange of personnel data
The HR system is intended to enable the processing departments within the HR system to exchange
personnel files and personnel data nationwide and across all authorities.
B
ePAePV-A1132
Exchange of personnel data
The HR system is intended to enable the processing departments to exchange personnel data across the
entire country and across all authorities.
files and personal data.
B
4.8.1.1.1 Document preview
Requirement
labelling
Requirement
Criterion
ePAePV-A0728
Opening files from the document preview
The HR system should be able to offer document previews as jump points to the relevant documents so that
the document opens.
B
ePAePV-A0724
Display of file types
If the HR system offers a document preview for common documents directly in the HR system without the
need to call up separate software on the clients, it must be possible to display the PDF, xls, doc, htm and
jpg/jpeg formats in particular.
A
ePAePV-A0892
Simultaneous preview of several documents
The HR system should be able to allow users to preview several documents at the same time.
B
ePAePV-A0583
Document previews in application contexts
The HR system should be able to generate document previews for standard documents
(see chapter "Document preview") in all application contexts.
B
13. December 2024 Page 268 of 366
13 december 2024
4.8.1.1.2 Centralised mass data change
Requirement
labelling
Requirement
Criterion
ePAePV-A0641
Changing metadata for centralised mass data changes
The HR system must be able to allow the metadata of the objects to be changed in the event of a centralised
mass data change.
A
4.8.1.2
Workspace structuring - General
4.8.1.2.1 Distinctiveness
Requirement
labelling
Requirement
Criterion
ePAePV-A0574
Icons for object types
The HR system should be able to display different icons for different object types to help differentiate
between them.
B
ePAePV-A0575
Icons for functions
The HR system should be able to display different icons for different functions to help differentiate between
them.
B
ePAePV-A0576
Distinguishability of structures in work areas
The HR system must enable users to navigate within hierarchical structures, both in the areas of
responsibility and within an organisation.
Akt to recognise which level you are at.
A
4.8.1.2.2 Display
Requirement
labelling
Requirement
Criterion
ePAePV-A0581
Display multiple documents
The HR system must give users the option of displaying several documents at the same time.
A
ePAePV-A0584
Changeability of column sequences
The HR system should be able to offer the column sequences in structured results displays in a generally
changeable form.
B
ePAePV-A0586
Display of metadata
The HR system should be able to display metadata for objects stored in the HR system (e.g. files, documents,
etc.).
The HR system must be capable of displaying the metadata for objects stored in the HR system (e.g. files,
documents, etc.).
•
fade-in and
•
can be hidden.
B
4.8.1.2.3 Customised configuration
Requirement
labelling
Requirement
Liability
13. December 2024 Page 269 of 366
13 december 2024
ePAePV-A0578
Customised settings 1/9
The HR system should enable users to customise their own area of responsibility based on the default
settings (e.g. arrangement of windows, icons, masks, search function settings, etc.), which remain saved
for each user.
B
ePAePV-A0736
Customised settings 2/9
The HR system should enable users to customise a workspace individually in terms of window
arrangement (e.g. preferred left/right preview), which remains saved for each user.
B
ePAePV-A0737
Customised settings 3/9
The HR system should enable users to customise a workspace individually with regard to favourites
functions (e.g. frequently used workflows, etc.) / links, which remain saved for each user.
B
ePAePV-A0766
Customised settings 5/9
The HR system should be able to give the processing departments the option of creating different
layouts (e.g. colour differentiation, etc.) for different areas of responsibility, which remain saved for
each user.
B
ePAePV-A1103
Customised settings 6/9
The HR system should be able to allow the administrative departments to create different layouts for
different roles.
B
ePAePV-A0767
Individual settings 7/9
The HR system should be able to give the administrative departments the option of saving several
layouts for work areas, which remain saved for each user.
B
ePAePV-A0768
Individual settings 8/9
The HR system should be able to provide the processing departments with the option of
to share their layouts with other users, which remain saved for each user.
B
4.8.1.3
Metadata
4.8.1.3.1 Sort based on metadata
Requirement
labelling
Requirement
Criterion
ePAePV-A0601
Sotation of acts based on metadata
The HR system should offer users the opportunity to search for files in the search results.
sort them according to their metadata.
B
4.8.1.3.2 Metadata display setting
Requirement
labelling
Requirement
Criterion
ePAePV-A0602
Configuring the display of metadata
The HR system should offer users the option of structuring the display of metadata themselves and the
setting for each user should remain saved. The HR system must remember the last saved settings when the
user returns.
call can be loaded.
B
13. December 2024 Page 270 from 366
13 december 2024
4.8.1.3.3 Configure metadata
Requirement
labelling
Requirement
Criterion
ePAePV-A0587
Maintenance of the date of receipt
The HR system must be able to recognise the following when objects are received/created in the HR system
maintain a date of receipt or date of origin.
A
4.8.1.4
Logging
4.8.1.4.1 Logging cases
Requirement
labelling
Requirement
Criterion
ePAePV-A1134
Exceptions to logging
The HR system must be able to make exceptions to the logging of the disciplinary file and not log the
content of the data for which there is an obligation to erase. In this respect, no deletion log may be saved.
become.
A
4.8.1.5
Print
4.8.1.5.1 General requirements for printing
Requirement
labelling
Requirement
Criterion
ePAePV-A1094
Printer selection
The HR system must allow users to select printers when printing.
A
ePAePV-A1095
Selecting the default printer
If several printers are available, the HR system should be able to offer the default printer by default.
B
ePAePV-A1096
Print settings
If printing is to take place via the HR system, the HR system must allow the user to make printer settings.
A
ePAePV-A0563
Printing content 1/2
The HR system must enable the administrative departments to print documents.
A
ePAePV-A1129
Printing content 2/2
The HR system must make it possible for the processing department to create a group
of documents (selection of documents).
A
13. December 2024 Page 271 of 366
13 december 2024
4.8.1.6
Deleting data
4.8.1.6.1 Residue-free deletion
Requirement
labelling
Requirement
Criterion
ePAePV-A1069
Residue-free deletion of data
The HR system must enable the Investigation and Disciplinary Matters department to delete data from the
Investigation and Disciplinary Matters sub-files without leaving any residue.
A
ePAePV-A1071
Note before deletion without residue
The HR system must give the processing department a warning before deleting the backlog, e.g. by asking:
"Do you really want XYZ?
irrevocably delete?"
A
4.8.1.6.2 Delete and destroy
Requirement
labelling
Requirement
Criterion
ePAePV-A1074
Delete and destroy 1/5
It must not be possible to delete data fields, data groups or documents if they are still required for data
processing (e.g. calculations).
A
ePAePV-A1078
Delete and destroy 2/5
The HR system must make it possible to set deletion deadlines at document level.
A
ePAePV-A1080
Delete and destroy 3/5
The HR system must be able to provide for a four-eye principle for the final deletion.
A
ePAePV-A1081
Delete and destroy 4/5
The HR system must be able to allow deletions only if a corresponding user authorisation has been
configured.
A
ePAePV-A1084
Delete and destroy 5/5
The HR system must be able to ensure the final deletion of files and their in
to make this possible.
A
13. December 2024 Page 272 of 366
13 december 2024
4.8.2
Filing-specific requirements (Electronic Personalakt)
4.8.2.1
Personalakt
4.8.2.1.1 Structure of the Personalakt
Requirement
labelling
Requirement
Criterion
ePAePV-A0341
Structure of the Personalakt 1/5
The HR system must offer the administrative departments the option of creating personal files that can be
subdivided into sections and sub-files, for example.
A
ePAePV-A0342
Structure of the Personalakt 2/5
The HR system must be able to visually differentiate between the organisational levels.
A
ePAePV-A0872
Structure of the Personalakt 3/5
The HR system must enable the processing department to track the chronology of documents in the
Personalakt.
A
ePAePV-A0899
Structure of the Personalakt 4/5
The HR system should enable the processing departments to recognise in the overview of the ePA (e.g. in
the table of contents) for which subdivisions of the Personalakt documents are available.
B
ePAePV-A0900
Structure of the Personalakt 5/5
The HR system should enable the various structural elements (e.g. documents, tables) of the Personalakt to
be displayed visually in different ways
(e.g. through a clear colour scheme).
B
4.8.2.1.2 Create Personalakt
Requirement
labelling
Requirement
Criterion
ePAePV-A0874
Keywords for documents
The HR system should be capable of enabling uniform catalogue-based indexing of documents. The
keyword catalogues must be able to be maintained by the central specialist administration. The
departmental administrators must be able to select the keywords for each document from the catalogue.
When assigning keywords, free text must not be possible.
B
4.8.2.1.3 View Personalakt
Requirement
labelling
Requirement
Criterion
ePAePV-A0355
Parallel access to Personalakt
The HR system must be able to ensure that several users can have read access to the same Akt at the same
time.
A
ePAePV-A0685
Temporary access to files 1/2
The HR system must be able to allow other users who are not the responsible case handler to have
temporary access to the complete file and parts of it.
to make this possible.
A
13. December 2024 Page 273 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0864
Temporary access to files 2/2
The HR system must enable the processing departments to grant temporary access rights across
departments and clients.
A
ePAePV-A0866
Extension of the right to read
The HR system should be able to ensure that an extension of the read authorisation by the processing
departments is possible.
B
ePAePV- A0867
Communication about temporary right of inspection 1/2
The HR system should be capable of communicating the expiry of the temporary right of inspection to the
departments to which the right of inspection is granted.
B
ePAePV-A0873
Horizontal scrolling
The HR system is designed to enable the administrative departments to scroll horizontally through
documents in the Personalakt without having to open individual documents separately.
B
ePAePV-A1138
Vertical scrolling
The HR system is designed to enable the administrative departments to scroll vertically through documents
in the Personalakt without having to open individual documents separately.
B
ePAePV-A0923
Communication about temporary right of access 2/2
The HR system should be able to notify the departmental administrator to whom the right of inspection is
granted before the temporary right of inspection expires. The department that is granted the right of
inspection should be responsible for
can centrally determine the number of days before expiry.
B
4.8.2.1.4 Transfer / take over Personalakt
Requirement
labelling
Requirement
Criterion
ePAePV-A0876
Transfer of partial files
The HR system must be able to ensure that personnel and partial files, e.g. in the case of secondments from
other departments in res-
can be managed by external service centres.
A
4.8.2.1.5 Bookmark
Requirement
labelling
Requirement
Criterion
ePAePV-A0879
Set bookmark
The HR system should offer the processing departments the option of setting several bookmarks in a
document so that they can return to this point at a later time. In particular, it must be possible to set
bookmarks for sections, paragraphs and words within a page. The number of bookmarks should be
unlimited.
B
ePAePV-A0594
Set markers in documents
The HR system is intended to offer the processing departments the option of making mark-ups / highlights in
documents that can be used at a later date.
are also visible through other clerks.
B
13. December 2024 Page 274 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A1144
Deleting bookmarks
The HR system should offer the clerical departments the option of deleting read characters in a document.
B
ePAePV-A1145
Naming bookmarks
The HR system should offer the administrative staff the option of naming bookmarks in a document and
being able to search for the name. The HR system must make it possible for the department administrator
to then jump to the respective bookmark.
B
ePAePV-A1153
Colour coding of bookmarks
The HR system is intended to offer the processing departments the opportunity to read
characters in a document in different colours.
B
4.8.2.1.6 Close Akt
Requirement
labelling
Requirement
Criterion
ePAePV-A0643
Set status Akt closed 1/2
The HR system must offer the processing departments the option of closing files by setting the status of the
file to "File closed".
A
ePAePV-A0644
Set status Akt closed 2/2
The HR system must be able to link properties (in particular access rights, visibility of closed files) with the
status of the file (cf. ePAePV-A0643). Example: Closing a file cancels the user's write authorisation.
into a read authorisation.
A
4.8.2.2
Documents
4.8.2.2.1 Document groups
Requirement
labelling
Requirement
Criterion
ePAePV-A0327
Assignment to document groups
As there are different retention periods for different documents, the HR system must enable the processing
departments to assign documents to a document group accordingly.
A
ePAePV-A0328
Retention periods for document groups
The HR system should enable the centralised specialist administration to configure the various retention
periods for the document groups.
A
4.8.2.2.2 View documents
Requirement
labelling
Requirement
Criterion
ePAePV-A0354
Simultaneous read access
The HR system must be able to provide read access to several users simultaneously.
to the same document.
A
13. December 2024 Page 275 of 366
13 december 2024
Requirement Request
Labelling
Criterion
4.8.2.2.3 File documents
Requirement
labelling
Requirement
Criterion
ePAePV-A0021
Assignment of documents to a Personalakt
The departments must be able to assign documents directly to a specific Personalakt in the HR system.
A
ePAePV-A0929
Designation of documents to be ablegen
The HR system should be able to automatically name documents to be ablegen according to a standardised
formation rule to be agreed with the client.
The HR system is intended to enable the administrative departments to make individual changes to the
to make changes to the designation.
B
4.8.2.2.4 Pagination/numbering of documents
Requirement
labelling
Requirement
Criterion
ePAePV-A1098
Pagination/numbering of documents
The HR system must be able to ensure that all documents required by WF
04.08 are exported, are numbered consecutively, e.g. total pagi-
the file in the footer.
A
4.8.2.2.5 Move documents
Requirement
labelling
Requirement
Criterion
ePAePV-A0921
Move documents 1/3
The HR system must enable the processing departments to move documents between different levels of the
file structure (subdivisions of the file).
A
ePAePV-A0945
Move documents 2/3
The HR system should be able to display a message such as "Do you really want to move document XY to
Z?" before moving a document between different levels.
B
ePAePV-A0946
Move documents 3/3
Before moving a document between different Personalakts, the HR system should be able to display a
message such as "Do you really want document XY?
move to Personalakt Z?".
B
4.8.3
Personnel administration-specific requirements (electronic personnel administration)
4.8.3.1
Process: Recruitment
4.8.3.1.1 Carry out recruitment
13. December 2024 Page 276 of 366
13 december 2024
ePAePV-A0006
Different types of settings
The HR system must offer the administrative departments the option of choosing between the recruitment
types new recruitment and secondment/assignment.
A
ePAePV-A0005
Legal relationships
The HR system must be able to distinguish between different legal relationships (e.g. employment
relationships, civil servant relationships).
A
ePAePV-A0023
Preparation of certificates of appointment
The HR system should create the appointment certificate automatically if all requirements are met. The
prerequisites are met if the data fields to be defined are filled in.
The HR system should enable the Central Specialist Administration to change the selection of data fields for
the definition.
B
ePAePV-A0007
Career qualification
The HR system should be able to automatically check career eligibility in accordance with LaufbBALVO M-V.
B
ePAePV-A0019
Calculation of probationary period
The HR system should automatically pre-assign the duration of an employee's probationary period in the
electronic personnel administration system, depending on the legal relationship (e.g. employment
relationships, civil servant relationships), taking into account the legal requirements.
B
ePAePV-A0020
Adjustment of trial period
The HR system must enable manual adjustment of the probationary period by the departments.
A
ePAePV-A0128
Creation of an employment contract
The HR system should automatically create the employment contract if all the necessary data is available.
The existence of all necessary data is fulfilled if the data fields to be defined are filled in. The HR system
should enable the central specialised administration to change the selection of data fields for the
specification.
B
ePAePV-A0861
Master data sheet
The HR system should offer the Central Specialist Administration the option of configuring the contents of
the master data sheet. The contractor must configure the master data sheet
implement in the HR system after consultation with the client.
B
4.8.3.2
Process: Assessment procedure
4.8.3.2.1 Comparison groups
Various comparison groups are formed when assessing employees. Comparison groups for determining the guideline value of an
official appraisal consist of employees who are potentially in a competitive situation with one another. Employees in a
comparison group have similar or related characteristics, e.g. pay grade.see BefRL-Pol-MV dated 15 October 2019 (comparison of
overall assessments, no more than one point apart...Note: overall grade)
Requirement
labelling
Requirement
Criterion
ePAePV-A0142
Comparison groups 1/4
The HR system must enable the administrative departments to create, change and delete comparison
groups.
A
13. December 2024 Page 277 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0143
Comparison groups 2/4
The HR system must enable the assignment of employees to be assessed to comparison groups by the
departmental administration.
A
ePAePV-A0145
Comparison groups 4/4
The HR system must enable the processing department to assign a quota system to a comparison group.
A
ePAePV-A0947
Quota regulation 1/6
The HR system must be able to show a quota for the number of employees in the quota system.
A
ePAePV-A0948
Quota regulation 2/6
The HR system must enable departments to configure threshold values for quota regulations.
A
ePAePV-A0949
Quota regulation 3/6
The HR system must be able to ensure that the quota relates to the overall grades of the employees.
A
ePAePV-A0950
Quota regulation 4/6
With the quota system, the HR system must only carry out the evaluation according to quota automatically
once the grades have been entered manually by the appraiser. If, for example, an employee leaves the
comparison group, the HR system must automatically carry out a new assessment if possible.
A
ePAePV-A0952
Quota regulation 5/6
The HR system must be able to ensure that the benchmarks are the same for all peer groups when
regulating quotas.
A
ePAePV-A0146
Quota regulation 6/6
The HR system should automatically monitor compliance with the quota within the peer group. If there is a
deviation from the quota, the HR system must automatically notify the departments in charge of processing.
B
ePAePV-A0148
Notifications
If the composition of the comparison group does not fulfil certain criteria (e.g. number and/or gender of
employees), the HR system should notify the responsible department. The notification must include a list
of the violated criteria.
B
ePAePV-A0150
Consideration of authorities that have been notified
Employees of subordinate authorities who are to be assessed must also be able to be assigned to a
comparison group.
A
ePAePV-A0170
Involvement of the representative body for employees with severe disabilities If employees with severe
disabilities are assigned to a comparison group, the HR system should automatically ensure the involvement
of the representative body for employees with severe disabilities. Involvement includes participation in the
workflow with the attached list of severely disabled employees. Involvement takes place directly in the HR
system.
B
ePAePV-A0164
Departure of employees
If employees who are assigned to the comparison group leave the company (e.g. transfer, dismissal), the HR
system is to switch off the processing of departments.
inform you about this change in a computerised manner.
B
13 December 2024 Page 278 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0165
Updating a comparison group
When employees leave the company, the HR system should automatically offer a new version of the
comparison group without the employees who have left.
B
ePAePV-A0168
Historisation of a comparison group
The HR system should historicise changes (employees who have left and newly assigned employees) in the
comparison group.
The HR system should compare the individual versions of a comparison group.
can be made available.
B
4.8.3.2.2 Carry out assessment procedures
Requirement
labelling
Requirement
Criterion
ePAePV-A0162
Key date Assessment 1/2
The HR system should enable the administrative departments to allocate all activities that arise during the
appraisal procedure to the key date of the appraisal period.
B
ePAePV-A0163
Key date for appraisal 2/2 The HR system should enable the administrative departments to assign all
documents that are generated as part of the appraisal procedure to the key date of the appraisal period.
B
ePAePV-A0174
Compilation of documents
The compilation of all available appraisal contributions (documents) from the period when the first
appraiser and second appraiser were replaced should be carried out with the support of the HR system.
B
ePAePV-A0172
Allocation in the GVP
The HR system should automatically store the first and second appraisers for the appraisal procedure (e.g.
in the master data) from the business allocation plan.
B
ePAePV- A0175
Memos of conversation
For events that take place outside the HR system (e.g. discussions between the first appraiser and second
appraiser to carry out the standard appraisal), the HR system should offer the first appraiser and second
appraiser the option of filing notes of the discussion as a document in the appraisal file (part of the
personnel file).
B
ePAePV-A0176
Checkbox
The HR system should enable the first and second assessors to note the completion of interviews in the
workflow, e.g. with a checkbox.
B
ePAePV-A0180
Delegating tasks
The HR system must enable initial assessors to delegate their tasks within the reassessment workflow to
other users. Delegation means that the rights and activities of the first appraiser are transferred to
another user.
A
ePAePV-A0318
Reference to open contributions
If, for example, first/second appraisers change departments (change in business distribution), the HR system
should automatically trigger a reminder/request for the new appraiser to create appraisal contributions.
are.
B
13. December 2024 Page 279 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0181
Scheduling
It should be possible to make an appointment for the preliminary appraisal interview via the HR system.
B
ePAePV-A0184
Participation of interest representation 1/2
In the invitation to the appraisal opening, the employee should be informed of the opportunity to involve
the employee representatives. The invitation must be sent by e-mail.
B
ePAePV-A0186
Participation of interest representation 2/2
The employee's decision as to whether the employee representative body should be involved should be
recorded manually in the HR system.
B
ePAePV-A0183
Connection KP 1/2
The appraised employee should be able to view his/her appraisal in the CP in preparation for the appraisal
opening.
B
ePAePV-A0190
Connection KP 2/2
A copy of the signed opening note should be made available to the employee in the KP.
B
ePAePV-A0191
Assessment status
The HR system should provide an overview of the appraisal status of employees subject to appraisal
(appraisal pending, appraised, appraisal opened, etc.).
B
ePAePV-A0192
Creation of a score sheet
The HR system is intended to enable the departments' administrative staff to create an automated and time-
independent grade report (anonymised summary of grades).
by comparison group).
B
4.8.3.3
Process: Apply for special leave
4.8.3.3.1 Apply for special leave
Requirement
labelling
Requirement
Criterion
ePAePV-A0219
Special leave request
The information (structured data and documents when applications are received via the CP or manually
entered by the departmental processing department for paper applications) from (special) leave
applications must be able to be mapped in the HR system.
A
ePAePV-A0244
Adjustment of holiday dates
The HR system is intended to enable the administrative departments to make individual assignments and
adjustments to employees' leave data manually.
B
ePAePV-A0261
Entering holiday data
The HR system must enable data on requested and authorised special leave to be entered by the
departments responsible for processing.
A
13. December 2024 Page 280 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0251
•
Absence types (catalogue selection)
In addition to special leave, the HR system must also allow departments to record other types
of employee absences from a predefined catalogue. In particular, the catalogue must contain
the absence types
•
Employment ban
•
Maternity protection
•
Parental leave
•
Sabbaticals
•
Temporary relocations
•
Secondments
•
Business trip
•
Teleworking
•
Time equalisation
•
Holidays
•
Others
include.
A
ePAePV-A0358
Monitoring remaining leave
The HR system should be able to automatically monitor remaining leave entitlements and report them to
the service department within defined deadlines.
It should be possible for the central specialised administration to change the deadlines.
B
ePAePV-A0369
Consideration of working time models
The HR system should be able to process the data stored in the electronic personnel administration.
working time models for automated calculations.
B
4.8.3.4
Process: Staff budget
4.8.3.4.1 Business allocation plan / organisation chart
Requirement
labelling
Requirement
Criterion
ePAePV-A0010
Automated creation of the GVP
The HR system should be able to create the business distribution plan (GVP) automatically using the data
available in the HR system. Changes in comparison to the direct predecessor version should be historicised
and be visible for comparison by the departments.
B
ePAePV-A0542
Automated updating of the GVP
The HR system should automatically change the GVP when changes are made to the master data.
B
ePAePV-A1014
Automated creation of an organisation chart
The HR system should be based on structured data about the organisation and its employees.
employees can create organisational charts automatically.
B
13. December 2024 Page 281 of 366
13 december 2024
4.8.3.4.2 Job plan number
Requirement
labelling
Requirement
Criterion
ePAePV-A0391
Assignment of a job plan number
When a new job is created by the HR budget administrator in the position plan, the position plan number
must be assigned automatically by the HR system.
A
ePAePV-A0392
Consecutive job plan number
The number generated in ePAePV-A0391 must be consecutive.
A
ePAePV-A0393
No reallocation of job plan numbers
The number generated in ePAePV-A0391 may not be reissued once the position has been cancelled.
A
ePAePV-A0394
Possibility of depositing an education regulation
The number generated in ePAePV-A0391 must be generated in accordance with the formation rules stored
in the HR system.
A
ePAePV-A0395
Reallocation in the event of a change of department
If a position is transferred to another department (see ePAePV-A013 - Budget position chapter), a job plan
number must also be assigned by the HR system (see ePAePV-A0391).
A
ePAePV-A0396
Historisation of job plan numbers for new allocations
In the case of ePAePV-A0395, the previous position plan number must be saved as a historical date in the
(budget) position. The historical date must be re-
be researchable. The historical date must also be allowed to remain blank.
A
4.8.3.4.3 Budget centre
Requirement
labelling
Requirement
Criterion
ePAePV-A0399
Maintenance of a characteristic of a budget centre 1/5
The characteristic as of when the position can be assigned to an employee by the position budget
processing department ("valid from") must be defined at the (budget) entry point.
) position can be maintained in the HR system.
A
ePAePV-A0400
Maintenance of a characteristic of a budget centre 2/5
It must be possible for the budget chapter (department) to be maintained at the (budget) centre by the
budget position administrator.
A
ePAePV-A0401
Maintenance of a characteristic of a budget centre 3/5
It must be possible for the budget title to be maintained at the (budget) centre by the budget position
administrator.
A
ePAePV-A0402
Maintenance of a characteristic of a budget centre 4/5
The measure group must be maintainable at the (budget) centre by the budget centre
administrator.
A
ePAePV-A1148
Storing the status of a budget centre
The HR system should enable the administrative departments to store a status at each (housekeeping)
position.
B
13. December 2024 Page 282 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0403
Budget position in tender 1/3
At the (budget) position, the job budget administrator should be able to enter in the HR system when a
vacancy is currently being advertised.
B
ePAePV-A0404
Budget position in tender 2/3
As long as the job advertisement to fill the position is open, it should be possible to block the position at the
discretion of the administrative departments, so that no employee can be appointed to the position during
this advertisement period. It must be possible to change the choice, e.g. in the event of lengthy advertising
procedures.
B
ePAePV-A0406
Budget position in call for tenders 3/3
The HR system must allow a (budget) position to be divided among several employees.
A
ePAePV-A0407
Automated adoption of changes
The HR system must also automatically incorporate changes in the employee's scope of employment into
the staffing process.
A
ePAePV-A0408
Time limit
The HR system must enable departments to enter a time limit for the scope of employment.
A
ePAePV-A0409
Updating the list of vacancies
When an employee is assigned to a (budget) position, the job assignment list must be created/updated
automatically.
A
ePAePV-A0410
Transfer of positions to other departments
The HR system is intended to enable the job budget administrator to assign a job to a job budget
administrator in the subordinate area and another department for management purposes (staffing, job
advertisements).
B
ePAePV-A0414
Storage of changes
It must be possible to store a requested change for a (budget) position in this (budget) position in the HR
system.
The application itself is made outside the HR system.
A
ePAePV-A0415
Increase of a budget item
The HR system must enable the HR budget administrator to carry out the budget centre increase.
A
ePAePV-A0416
Reduction of a budget centre
The HR system must enable the HR budget administrator to carry out the reduction of a budget centre.
A
ePAePV-A0417
Conversion of a budget centre
The HR system must enable the HR budget administrator to carry out the conversion of a budget centre.
A
ePAePV-A0418
Attachment of job references
The HR system must enable the job budget administrator to participate in a
budget centre and maintain them.
A
13 December 2024 Page 283 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
ePAePV-A0428
Research option
The HR system must enable departments to search for future planned retirements (e.g. due to the
standard retirement age), e.g. in order to determine promotion opportunities and job replacements.
A
ePAePV-A0430
Reduction in job share
The HR system must enable the administrative departments to reduce the number of posts held by an
employee leaving the company for a fixed term to zero.
A
ePAePV-A0436
Percentage distribution of a job
The HR system must inform the administrative departments (warning message) if 100% or more of the
position is split when a position is split. The HR system must enable the administrative department to split
the position to a percentage of more than 100%.
A
ePAePV-A0512
Maintaining a characteristic of a budget centre The HR system must enable the functional budget to store a
"valid to" date in the budget centre.
This records how long it has been present.
A
ePAePV-A0530
Identification of vacancies
The HR system should automatically determine when which position will become vacant (e.g. due to
retirement, end of fixed-term employment contracts). The HR system must offer the administrative
departments the opportunity to view the data determined.
B
ePAePV-A0532
Release of jobs 1/2
The HR system must automatically separate a budget position from the employee as soon as an employee
leaves, so that the position is free again.
A
ePAePV-A0549
Release of jobs 2/2
The HR system should be able to automatically check for available positions and created lists (e.g. promotion
blocking lists) and provide the result to the job budget processing department.
B
ePAePV-A1005
Filter by job category
The HR system must be able to subdivide and filter the budget centres, in particular by:
-
AVD
-
AN
-
PVD-S (police protection)
-
PVD-K (criminal investigation department)
-
LS (blank)
The HR system must enable the central specialist administration to change this job category catalogue.
A
ePAePV-A0421
Search for usable job vacancies
The HR system must enable the HR budget administrator to search for usable vacancies within the existing
budget centres in the event of a transfer / recruitment and a non-existent budget centre
to be able to.
A
13 December 2024 Page 284 of 366
13 december 2024
5 Non-functional requirements for the overall system
The following chapter contains the overarching non-functional requirements. The requirements therefore refer to the overall
system in accordance with the EVB-IT System GTC, unless a system component (KP or HR system) is explicitly named.
In detail, these are requirements for:
- User interface,
- Modifiability, expandability and maintainability,
- Security,
- Technology,
- Interfaces,
- Accessibility,
- Documentation and training,
- Project realisation, acceptance and establishment of operational readiness
A significant proportion of these requirements result from mandatory legal framework conditions and the given framework for
the operation of state IT in Mecklenburg-Vorpommern (MV).
Requirement
labelling
Requirement
NA01.01
Complete coverage of the non-functional requirements for the overall system in the standard
The overall system should cover all non-functional requirements of the overall system in the standard at
the time of tender submission. The term standard is defined in the glossary. The evaluation is calculated
from the proportion of the requirements already included in the standard.
requirements on the basis of the information provided by the bidder.
5.1
Requirements for the user interface
The following requirements for the user interface are essentially based on DIN EN ISO 9241 on the ergonomics of human-system
interaction. These were supplemented in order to realise further project-specific requirements, for example to implement the
corporate design of the state of Mecklenburg-Vorpommern. With regard to the user interface, the accessibility requirements in
chapter 5.6 must also be observed.
13 December 2024 Page 285 of 366
13 december 2024
Requirement
labelling
Requirement
BO01.01
Quality of the user interface
The overall system should take into account the interaction principles of ISO 9241-110 for the creation of
effective, efficient and satisfactory software as comprehensively as possible; this is checked in the context
of a usability test by the client on the basis of a test version as part of the offer phase. The test setup does
not have to have any client-specific functionalities, but can be provided in the standard version of the
applications offered. Selected users carry out four use cases as part of the test provision (see below). For
each of these, the provider must store fictitious data in its test environment and provide access for a
certain period of time. Based on these use cases, the test subjects evaluate selected requirements of ISO
9241-110 "Ergonomics of human-system interaction - Part 110: Principles of interaction" on a scale from 0
to 5:
-
5 points: The requirement is completely fulfilled.
-
4 points: The requirement is fulfilled with minor restrictions.
-
3 points: The requirement is fulfilled with restrictions that do not significantly impair the overall
interaction.
-
2 points: The requirement is fulfilled with restrictions that impair interaction in specific use cases or
overall.
-
1 point: The requirement is met with significant restrictions that severely impair interaction in
specific use cases or overall.
-
0 points: The requirement is not fulfilled.
An average is calculated per use case (list of use cases in the following list) from the ratings of all users
across all requirements. A total of 20 points can therefore be achieved. The number of points achieved is
converted into evaluation points by a factor of 0.5 and rounded to whole numbers.
The use cases for checking the requirements are as follows:
-
Recording a new personnel case
-
Changes to an existing personnel case
-
Preparation of a payslip/notification
-
Data collection for determining the supply
In the use cases, different error situations are tested in particular, which are actively caused by the test
subjects, for example:
-
Violation of data formats (no date, no number in the corresponding input fields).
-
Violation of time periods (start date greater than end date).
-
Non-completion of mandatory fields or compulsory entries.
-
Entry of nonsensical values, overruns and underruns of value limits.
-
Professional errors:
•
Settlement of remuneration during reported parental leave
•
Entry of illness beyond the end of an employment relationship
BO01.03
Gender-neutral language
The overall system must consistently use gender-neutral language in accordance with the guidelines for
the equal treatment of women and men in official and legal language (Annex 5.1 Gender-neutral
language).
BO01.04
User interface language
The user interfaces of the overall system must be completely in German.
are provided.
13 December 2024 Page 286 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
BO01.05
English extensibility
The user interfaces of the HR system and the CP should be available in English for specific users through
configuration options.
B
BO01.06
Corporate design for the HR system
The HR system should be visually adapted to the corporate design of the state of Mecklenburg-Vor-
pommern. The guideline for the required customisation options guideline for the state
design can be retrieved be at: https://www.mecklenburg-
vorpommern.de/markenportal/landesmarke/marken- handbook
B
BO01.07
Corporate design for KP
The contractor must adapt the CP visually to the corporate design of the state of Mecklenburg-
Vorpommern. The guidelines for the state design relevant for the adaptation can be
retrieved be at:
https://www.mecklenburg-vorpommern.de/markenportal/landesmarke/marken- handbook
A
5.2
Quality requirements for changeability, expandability, maintainability
The quality requirements for changeability, expandability and maintainability ensure the future viability of the project so that the
overall system can be used over the planned life cycle and remains state of the art.
Requirement
labelling
Requirement
Criterion
QA01.01
Product strategy further development (1/2)
The contractor must submit a product release plan.
A
QA01.02
Product strategy further development (2/2)
The product strategy for further development should present the orientation, priorities and planned further
developments of the functionalities of the standard software as well as planned technical improvements to
the standard software over time.
B
QA01.03
Utilisation Framework ITIL
As part of the provision of the system service, the ITIL framework in version 3 or 4 must be observed. If the
framework differs between the Contractor and the Operator, the Contractor undertakes to provide
harmonised process chains.
A
QA01.04
Product life cycle of the components used
Over the entire period of use of the overall system, the contractor must ensure that only those components
are used for which neither the end date of
maintenance (EOM) and support (EOS).
A
13 December 2024 Page 287 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
QA01.05
Monitored life cycle
A version management system must be used for the development of software, both for customer-specific
changes and for the further development of the software that affects the client. Development progress must
be continuously and automatically integrated within build pipelines. Software artefacts (both self-created
releases and releases provided by suppliers) must be managed in a software registry and continuously
scanned for known vulnerabilities (CVEs). The vulnerability scan must be automated and include the libraries
used as well as the SBOM (SA02.27 (reliability and protection)).
A
QA01.06
Software update (1/3)
This requirement applies exclusively to on-premise operation. The installation of new programme versions
must be able to be carried out independently by the client or the contracted IT service provider. The
contractor must ensure that the software update is carried out without the loss of existing data (e.g. test
data in a test environment).
A
QA01.07
Software update (2/3)
The development concepts, methods and processes must be standardised for the entire development
process.
A
QA01.08
Software update (3/3)
All programme versions, including previous versions, must be clearly identifiable using suitable, modern
versioning concepts and code management solutions and must be able to be restored automatically and in
an executable form if required.
A
QA01.09
Performance
For each system component (KP and HR system), the overall system must fulfil the
5.2 (Performance requirements and measurement product supplier) defined in section 1.
The verification of target achievement is carried out using the measurement procedures defined in Section 2
of Annex 5.2 (Performance Requirements and Measurement Product Supplier). The Contractor shall provide
corresponding documentation of the load and performance tests to be carried out automatically for these
components in the form of protocols.
Deviations in target achievement are evaluated using the criteria defined in Section 3 of Annex 5.2
(Performance requirements and measurement of product suppliers).
A
QA01.10
Communication between the system components
For the technical implementation of communication between the system components, the Contractor
must use only common interface standards (SOAP, REST, web services, etc., but in particular non-
proprietary communication or interface protocols) that correspond to the state of the art.
A
QA01.11
Documentation of the interfaces - system components
The Contractor must provide complete documentation of the interfaces between the system components so
that a competent third party can use these interface(s) independently and to their full extent.
A
QA01.12
Documentation of the interfaces - supplies, external systems
The Contractor must provide complete documentation of the interfaces to provisions or external systems.
A
13 December 2024 Page 288 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
QA01.13
Release stability
The Contractor must ensure that the existing technical configuration (in particular workflows, sets of rules,
parameter settings and calculations) is retained and remains functional when new programme versions are
imported. Changes require the consent of the Client.
A
QA01.14
Downward compatibility
The downward compatibility of the system functions and components, in particular the technical interfaces in
the context of new programme versions, must be guaranteed.
be in place.
A
5.3
Safety requirements
The overall system must be created in compliance with the principles of data protection and IT security. The need for protection
is defined as high in terms of confidentiality, integrity and availability, as the system operates with personal financial information.
The basic principles are derived in particular from the GDPR, the Mecklenburg-Vorpommern State Data Protection Act (DSG MV),
the IT baseline protection compendium, the basic protection standards of the Federal Office for Information Security (BSI) and
the technical guidelines of the BSI. Documents are published on the BSI website
4
and the standard data protection model on the
website of the Mecklenburg-Vorpommern State Commissioner for Data Protection and Freedom of Information
5
.
5.3.1
Deletion periods and data protection
Requirements
labelling
Requirement
Criterion
SA01.01
Data protection check
The GDPR and, in addition, the DSG of the state of Mecklenburg-Vorpommern must be complied with. The
overall system must enable compliance with these regulations on the system side without the client having
to take any further configurative measures. Furthermore, all requirements of official and procedural data
protection must be implemented in the system in the latest version. The Contractor must provide the Client
with suitable evidence that the requirements are met. Appropriate proof must be provided before the start
of the authorisation process, approx. 6 months before the commissioning date specified in the project plan.
A
SA01.02
Third party contractor
The Contractor must ensure that, when using third-party software components, compliance with all data
protection requirements of the overall system is also ensured with
is completely fulfilled by these software components.
A
4
See https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzStandards/ITGrundschutzStandards_node.html
5
See www.datenschutz-mv.de
13 December 2024 Page 289 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SA01.03
Export of personal data
The contractor must provide functions that enable the export of all personal data stored about a person in a
machine-readable format (in particular for the right of access in accordance with Art. 15 GDPR). The technical
transfer of the data must be possible via REST-API, SOAP or via file-based export on digital media (e.g. DVDs,
LTO or other standard market methods).
A
SA01.04
Overview of personal data
The documentation of the overall system must contain a tabular overview of where which personal data is
stored. This must include information on the criteria (purpose limitation) under which the data is stored at
the respective location (Art. 30 GDPR).
A
SA01.05
Contractor appoints data protection officer
The contractor must name its expert data protection officer to the client as a contact person. This person
must help to clarify any unresolved issues relating to data protection.
A
SA01.06
Storage period of the data
The overall system must store all payroll-relevant data, payment-related documents and documents relevant
to personnel administration (including applications, notifications) for the duration of the life cycle of the
personnel case file so that they can be analysed. The different deadlines for "data for calculation",
"documents" and "master data (e.g. CV)" must be observed. When the process is completed, access rights
must be changed automatically and can be configured by the specialist administrator (e.g. only access rights
for certain evaluation roles).
A
SA01.07
Storage duration of all other data
The following points must be fulfilled by the contractor:
-
With regard to the log data of the audit-compliant documentation ("audit trail") in accordance with
requirement SA02.18 (Audit-compliant documentation (audit trail)), the storage period in accordance
with Section 76 (4) BDSG applies unless otherwise specified by the client.
-
Deletion rules for all other data are defined in the following requirement SA01.08 (Archiving and
deletion).
-
Other logging data that is not subject to data protection law must be deleted after 90 days in
accordance with the framework data protection concept, the logging and detection of cyber attacks on
the Federal Administration.
A
ePAePV-
A0937
Storage period for documents and Akt
The HR system must ensure that retention periods for
•
individual documents
•
the Akt as a whole are
applicable.
A
SA01.08
Archiving and deletion
The deadlines for archiving and deleting documents and data, including log data, must be parametrisable
in terms of categories, rules and service types. The start of the deletion period must be derived from the
creation date of the respective documents/data in the specialised procedure. The statutory
retention/deletion periods and the retention/deletion periods in accordance with SA01.07 (retention
period of all other data) must be mapped in the overall system and stored in the
can be adapted within the framework of centralised specialist administration.
A
13 December 2024 Page 290 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SA01.09
Extension of the retention period
The retention period must be updated automatically for processes that are currently being processed.
A
SA01.10
Advance notice of cancellation
The deletion after the retention period has expired should be announced in advance with a lead time by an
evaluation from the system to a central location. The lead time must be configurable depending on the data
category (either technical or nontechnical data). Non-technical data includes, for example, technical log
data.
B
SA01.11
Archiving and deletion concept
As part of the implementation phase, the Contractor must submit an archiving and deletion concept in
which it presents the implementation of the statutory retention/deletion periods and the relevant
requirements SA01.06 (data retention period) - SA01.10 (advance notice of deletion) in the HR system.
The Contractor must implement the archiving and deletion concept submitted in the overall system after
approval by the Client in a technical and data protection-compliant manner.
A
SA01.12
Suspension of the pending cancellation
It must be possible for authorised users to manually suspend pending deletions in justified cases (e.g. due to
ongoing proceedings). It must be possible to enter this justification in a corresponding mandatory field and
document it in the overall system.
A
SA01.13
Processing and storage of data
Processing and storage of data is only permitted in countries of the EEA
6
and Switzerland - the latter only if
there is an adequacy decision pursuant to Art. 45 GDPR that is effective at the time of processing/storage.
A
SA01.14
No disclosure of personal data to manufacturers or third parties
The Contractor must ensure that no personal data from the overall system is made available to
manufacturers or third parties. This also applies to crash reporters, analytics trackers, etc.
A
SA01.15
Rights and roles concept
To implement the rights and roles defined in Section 3.3 (Roles and authorisations) of the service
description, the Contractor must submit a suitable implementation concept in the implementation phase
that fully describes the technical implementation of the technical and data protection requirements and
implement this after approval by the Client. The concept must include both data rights (reading, changing,
creating and deleting certain data) and functional rights (authorisations for access to certain functions, e.g.
releasing payments).
A
SA01.16
Confidentiality by means of cryptography
The system must ensure confidentiality using cryptographic methods. These must be collision-proof at all
times. The data must be stored in encrypted form in accordance with the BSI's technical guidelines for
cryptographic methods (TR-02102 and TR-03116).
A
6
Countries of the European Economic Area
13 December 2024 Page 291 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SA01.17
Protection against unauthorised changes to data
The Contractor must ensure that loss and unauthorised modification (manipulation) of the stored data (files
and processing programs) cannot occur. Proof of the technical measures taken for this purpose must also be
provided.
measures in the implementation phase.
A
5.3.2
IT security
Requirement
labelling
Requirement
Criterion
SA02.01
BSI Standard 200-2
Personal data, in particular financial data, is processed in the overall system. This results in a high need
for protection in the areas of confidentiality, integrity and availability in accordance with Art. 9 GDPR.
The overall system must be designed in such a way that the requirements of IT baseline protection in
accordance with BSI Standard 200-2 are met, taking into account the high need for protection.
A
SA02.02
BSI standards for communication
All communication must be encrypted in accordance with the technical guidelines (TR-02102 and TR-
03161) of the BSI (e.g. client-server interface, web services for the HR system).
A
SA02.03
ISO 27001 certification
This requirement applies exclusively to SaaS operation. The Contractor must have certification of its ISMS
in accordance with ISO 27001 and enclose the certificate with the offer.
A
SA02.04
IT Security Officer AN
To ensure compliance with the requirements for IT baseline protection, the Contractor shall appoint an
expert IT security officer. This person must liaise closely with the client's IT security officer (LAF MV).
A
SA02.05
Multi-factor authentication
The contractor must ensure the connection of the overall system to the country's own multi-factor
authentication solution. The solution is described in detail in Annex 5.11. This may involve two instances
of multi-factor authentication for KP and HR system.
A
SA02.07
Multi-factor authentication concept
To connect the overall system to the country's own multi-factor authentication solution, the contractor
must submit a suitable implementation concept in the implementation phase, which discloses how the
use of the solution by the contractor will be organised.
is supported.
A
13 December 2024 Page 292 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SA02.17
Logging Login
A log file must be created and maintained for the HR system and the KP to log security-relevant actions
(access to password files, login and failed attempts, logout information, blocking and unblocking of user
accounts and neutralisation of passwords).
The log must comply with the BSI's minimum standard for logging and detecting cyber attacks (bund.de)
(www.bsi.bund.de🡪 Topics🡪 Government and administration🡪 Minimum federal standards🡪 Latest
updates) and the guidelines from the Federal Office for Information Security (BSI).
the Standard Data Protection Model (SDM) "Logging" (Annex 5.4
SDM_Logging). The log file must be able to be viewed and analysed by the client's central specialist
administration.
A
ePAePV-N318
Single Sign On (1/2)
The overall system must be capable of enabling users to access and use the components of the overall
system via SSO functions.
A
ePAePV-N154
Single Sign On (2/2)
The overall system must be capable of enabling authentication via single sign-on (standard client) in
Windows domains and Windows subdomains.
A
SA02.18
Audit-proof documentation (audit trail)
All access to data as well as changes and deletions of data must be fully logged in accordance with Section
76 of the German Federal Data Protection Act (BDSG) or from the standard data protection model (SDM)
"Logging" (Appendix 5.4 SDM_Logging) and recorded as an audit trail.
The protocol must
-
the clearly labelled business transaction,
-
the date, time and user ID of the user who made the entry, change or deletion, and
-
contain the recorded and changed data with old and new status.
-
be machine-readable
A
SA02.19
Encryption of documents
The uploading of encrypted files in the KP must be prevented, as these cannot be processed further.
A
SA02.20
Registration of a mobile phone number or e-mail address
When registering or changing the e-mail address in the KP, a verification regarding this action must be sent
to this e-mail address and the recipients must confirm the change.
A
SA02.21
Notification of changes to user account data in KP
A notification must be sent to the e-mail address provided whenever a user's profile data is changed in the
KP.
A
SA02.22
Authentication mechanism for web services and services
The overall system must protect access to services or web services, e.g. to aid or ePA/ePV, to prevent
unauthorised access through authentication. Reference is made here to the rights and roles concept as
per chapter 3.3. Communication must be encrypted.
A
SA02.23
Transport encryption of data
The latest version of TLS or the successor protocol at the time of implementation must be used for the
transport encryption of data.
A
13 December 2024 Page 293 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SA02.24
Separation requirement for operating environments
The overall system must ensure that the access and access authorisations for the different environments
(e.g. test, integration, training and production system) can be defined separately (separation
requirement). It must be possible to transfer the authorisation profiles to another environment.
A
SA02.26
Session timeout
If the user is inactive, the session is to be ended automatically after a defined period of time that can be
configured by the centralised specialist administration.
A
SA02.27
Reliability and protection
All components of the overall system, in particular third-party components, must come from a reliable
source and offer protection, for example through hardening, against malware. In order to assess the
reliability of the software, the contractor must provide a detailed software bill of materials (SBOM) in
accordance with TR 03183-02 of the BSI before the initial installation. The SBOM must be submitted for
the initial installation and with each release delivery in the latest version.
A
SA02.28
IT security concept and information on IT security aspects
The Contractor must fully support the preparation and regular review of an IT security concept by the
Client. To this end, the Contractor must immediately provide the Client with information on IT security
aspects and
to the company.
A
5.4
Technical requirements
This chapter contains the technical requirements for the overall system or for individual system components if these are explicitly
mentioned.
Requirement
labelling
Requirement
Criterion
TA01.02
Provision of configuration concept
The contractor must submit a configuration concept for the functional and system level as part of the
implementation. This contains and describes all configuration options.
In addition, the concept must contain supplementary explanations on the following aspects of the
configuration:
-
Avoidance of incorrect configurations through final plausibility checks on the configurations made.
-
Simple functional test option for the configuration and test support for testing the configuration
environment
-
Direct transfer of the configuration to the test and production environment ("deployment option")
-
Graphical representation of the programme and process logic
-
If available, tools for defining workflows and rules (section 4.1.9)
A
TA01.03
Plausibility check during configuration
A system-side plausibility check must be available for the configuration of the overall system in order to
prevent contradictory or incorrect configurations.
avoid.
A
13 December 2024 Page 294 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
TA01.04
Support with the initial configuration
The Contractor must support the Client in determining the technical and operational configuration
parameters at least in the initial configuration and configure the overall system in accordance with the
Client's specifications. The support in determining the technical parameters of the initial configuration as
well as the configuration according to the specifications of the Principal shall be provided independently of
the operating model offered. The support for the initial operational configuration applies exclusively to on-
premise and housing operation.
A
TA01.05
Efficiency
The overall system must provide at least the performance specified in Annex 5.2 under the specified
conditions in relation to the scope of the operating resources used. This characteristic of efficiency is made
up of the following sub-characteristics:
-
Time behaviour - The degree to which the response and processing times and throughput rates of a
product or system meet the requirements when performing its functions.
-
Resource utilisation - The degree to which the quantities and types of resources used by a product or
system to perform its functions meet the requirements.
-
Capacity - Degree to which the maximum limits of a product or system parameter meet the
requirements.
A
TA01.06
Calibration
The Contractor must carry out a calibration of the overall system before the start of production with the
aim of ensuring the performance of the overall system at the time of production. The specifications in
Annex 5.2 shall apply.
A
TA01.07
Load scalability
The overall system must be linearly scalable in terms of increasing the number of active users while
maintaining the response time (see Appendix 5.2).
A
TA01.08
Scaling quality
Horizontal scaling through parallel processing must be possible to absorb short-term load peaks. The
Contractor shall demonstrate scalability by means of appropriate architecture concepts and test results at
the latest upon provision for acceptance.
A
TA01.09
Volume scalability
The overall system must be scalable in terms of the main and mass storage in order to be able to handle
the predicted growth rate of processes (number of processes) (reference to number of processes in
chapter 2.1.1.1).
A
TA01.10
Structural scalability
The overall system must be scalable in terms of main and mass storage in order to be able to handle the
predicted growth rate in the volume of transactions (more extensive information within a transaction) (see
chapter 2.1.1).
A
TA01.11
Shift model
This requirement applies exclusively to on-premise operation. The overall system must guarantee a layer
model so that at least presentation layer, pro-
gramme logic and data are separated from each other (3-tier architecture).
A
13 December 2024 Page 295 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
TA01.12
Multi-client capability
The overall system must be both technically and functionally multi-client capable. The significance of multi-
client capability is explained in the requirements TA01.13 to TA01.16. (See also Appendix 5.8 Test criteria
for multi-client capability).
A
TA01.13
Organisation of transfers between clients
In the case of separate processing on a shared IT infrastructure, the processing of data from one client in
another client must be organised as a data transfer. In order to limit the transfers to what is permissible,
the selection of data for transfer may in any case only be linked to identity data (surname, first name, etc.)
and those attributes or characteristics of the data subjects for whose transfer there is a legal basis.
A
TA01.14
Completeness of transactions within a client
A client is considered "completed" if each transaction in a client transfers a valid dataset of a client into a
new valid dataset and neither depends on data from other clients nor accesses this data either read or
write due to technical measures. However, data storage must always be organised in such a way that each
instance of personal data is assigned to exactly one client. All access to personal
Data must take into account and enforce the assigned access authorisations and this assignment.
A
TA01.15
Independence of the configuration
Sufficient client separation requires that the access authorisations, processing functions and configuration
settings are defined independently for each client.
The independent assignment of access authorisations requires the creation of client-specific user IDs,
which can only be used to access your client's data.
If client-specific requirements are evident for the technical security and data protection measures on the
basis of a risk analysis or due to legal requirements, these requirements must be implemented at client
level and be configurable according to the specifications of the individual clients.
A
TA01.16
Restriction of cross-client management of data processing Cross-client functions for managing clients and
the shared infrastructure must not permit the processing of personal data of a client.
This does not apply to function holder data for the individual clients, which is used to set up the client-
specific authorisation system for the first time. The creation and deletion of clients within the system is
also one of the functions of cross-client administration. The organisation of data storage must ensure that
the applicable provisions for commissioned data processing can also be complied with for these
administrative functions.
A
TA01.17
Export of structured data
In the HR system, it must be possible to export processed data in a structured form in a standard exchange
format, taking into account the regulations on data protection and IT security (section 5.3).
It must be possible for users to restrict the specific scope of the data for export, such as in the context of the
search function (including the
Possibility of filtering the search results).
A
13 December 2024 Page 296 of 366
13 december 2024
Requirement
labelling
Requirement
TA01.18
Supported export formats
The following formats should be supported in the export of structured data (TA01.17 (Export of structured
data)):
-
XML or JSON (priority 1)
-
CSV (priority 2)
TA01.19
Open interface standards
The application should utilise existing XÖV standards (e.g. XDOMEA, XDATENFELDER, XFALL...). If no XÖV
standards are available, public administration standards (e.g. CMIS) should be used. For verification
purposes, a list of all interfaces of the overall system must be submitted with the tender, stating the
standards used.
TA01.20
Browser compatibility
The CP and the HR system (insofar as the latter is provided as a web application) must be fully executable
in the current version of the Chrome, Firefox, Edge and Safari browsers (when used on mobile devices) for
the duration of the system service. Previous programme versions must continue to be supported
(programme versions from the previous two years).
TA01.21
HTML 5
The CP must use the following elements for the structure, layout and design of websites:
-
Structuring of websites HTML from version 5.0 and higher
-
Layout and design of websites CSS from level 2.0 and higher
If the HR system is provided as a web application, this requirement applies accordingly.
TA01.22
UTF-8
The overall system must support UTF-8 (without limiting the character set, at least DIN Spec 91379)
throughout, so that diacritical characters, for example, can be processed.
13 December 2024 Page 297 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
TA01.23
Client hardware
The clients of the overall system must be able to run at least on the hardware specified below and the
required performance of the overall system (QA01.10) must be achieved with this hardware.
Hardware key figures of the APCs Desktop:
-Core i5-7500
-
8 GB DDR4
-
SSD SATA III 256 GB
-
DVD SuperMulti SATA
-
Intel® HD Graphics 630 (on-board)
-
Secure chip hardware (TPM 2.0)
Laptop:
-
Intel® CoreTi5-7300U
-
8 GB DDR4-2133 SoDimm
-
SSD PCIe-NVMe OPAL 2, 256 GB
-
Intel UHD Graphics620 Max.
-
Resolution 1980 x 1080 pixels
-
Wireless LAN
-
Intel Dual Band
-
Wireless-AC
-
Wireless WAN (Fibocom L830-EB 4G LTE)
-
Bluetooth version 4.1
-
Secure chip hardware (TPM 2.0)
A
TA01.24
Desktop client operating systems
It must be possible to use Microsoft Windows (currently version 11) as the client operating system on the
clients.
A
TA01.25
Use of active content in the client
The use of manufacturer-specific weaving techniques is not permitted.
Manufacturer-independent solutions must be used to display active content in the client, e.g. ECMAScript
from version 2017.
A
TA01.26
Use of standardised server operating systems
This requirement applies to on-premise operation. A current version of one of the following products must
be used as the server operating system:
-
Microsoft Windows Server
-
Red Hat Enterprise Linux
-
DEBIAN LINUX incl. derivatives
A
TA01.27
Use of standardised server virtualisation solutions
This requirement applies to on-premise operation. One of the following systems must be supported as the
system for the server virtualisation solutions (hypervisor) in the current version:
-
VMware ESX
-
HyperV
A
TA01.29
Standardised operation of container solutions
This requirement only applies to on-premise operation. If the solution is provided as a container solution,
Kubernetes must be used with the vanilla standard without proprietary extensions.
A
13 December 2024 Page 298 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
TA01.31
Web server
This requirement applies exclusively to on-premise operation. A current version of one of the following
products must be used as the web server:
-
Apache HTTP Server
-
Nginx
Web servers already embedded in the software solutions are not affected by this.
A
TA01.32
Runtime environments
This requirement applies exclusively to on-premise operation. For software solutions that require a
runtime environment, one of the following products must be used:
-
OpenJDK LTS
-
.NET LTS 5.0 or higher
-
NET Core LTS.
A
TA01.34
Access to relational databases
This requirement applies exclusively to on-premise operation. One of the following interfaces must be used
to access relational databases:
-
JDBC
-
ADO.NET
-
PHP Data Objects
A
TA01.35
Encryption at data field level
The DB system must also be able to encrypt the data fields if required.
A
TA01.36
Execution modes
The DB system should be able to execute the query commands both in line mode and, to improve
execution speed, in batch mode.
B
TA01.37
Stored procedures
The business logic of the overall system must be implemented exclusively in the application server, i.e. no
stored procedures for business logic.
A
TA01.38
Infrastructure
Users in the state offices are connected via the CN LAVINE state data network. The state authorities are
connected to the CN LAVINE with various bandwidths; the smallest bandwidth currently in operation is 8
Mbit/s. The load per office required to use the HR system must not exceed these 8 Mbit/s, depending on
the average usage figures in accordance with section 3.1.4.
A
TA01.39
Option for the AG:
MV own standard
The AG plans to develop a new specialised "references" interface. This will become the new standard for
the technical data exchange of the new overall system with the surrounding MV specialised procedures.
The interface will be developed in accordance with the concepts, methods and specifications of the XÖV.
The aim is not to certify the MV's own standard.
A
ePAePV-A0704
Data backup
The overall system must be able to back up data during operation.
without restrictions.
A
13 December 2024 Page 299 from 366
13 december 2024
5.5
Requirements for interfaces
As described in Chapter 3.1 System architecture, the overall system must be connected to various external IT components. This
includes information procedures, such as the child benefit retrieval procedure from the Federal Employment Agency/Family Fund
or IC data from the health insurance funds, or internal administrative procedures and databases, the MV service portal, the HKR
procedure, the payment procedure of the MV state administration and the interface to the printing and enveloping service of the
IT service provider of the AG (DVZ).
More detailed interface descriptions for previous interfaces are described in the respective appendices. Interfaces are listed in
the appendix under the numbering ST01 and the associated requirements here under SS01. An overview of all interfaces and
reporting procedures is attached as Annex 4.1 (Interfaces_reporting_procedures_overview). In addition, an outlook is given with
regard to the other interfaces that are likely to be required in the future.
It should be noted that network transitions (internal AG, internal AG-DVZ, internal AG-DVZ-AN, other third parties) always take
place in an on-premise, housing or SaaS solution and must be secured by appropriate measures (at least firewall rules,
certificates, etc.).
General interface requirements
Requirement
labelling
Requirement
Criterion
SS01.01
Error situations
The HR system must be able to deal with error situations at the interfaces (e.g. communication faults, technical
error messages from the interface partner, etc.). This includes in particular the automatic repetition of calls and
the provision of data once the error situation has been resolved. Within the HR system, the actual processing
must not be prevented by an error situation in the interfaces during data export for other (dependent) systems.
In the event of errors during data import, critical error messages must be generated for the specialist
administration.
A
SS01.02
Integrity checks Import
For file-based interfaces, the HR system must perform an integrity check on the files before importing them,
e.g. using MD5 hash values or similar procedures. The integrity check must be automated when the files are
imported.
It must be possible to (de)activate the integrity check as required as part of the technical administration. In the
explanation of the verification requirement, the contractor states
the self-assessment, the supported integrity check procedures.
A
13 December 2024 Page 300 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SS01.03
Export integrity checks
Before exporting files, the integrity and authenticity of the files must be ensured automatically by default or
manually if necessary by using the MD5 hash value procedure (or a comparable hash value procedure) via file-
based interfaces.
The file to be exported and the hash value must be made available to the recipient. It must be possible to
switch hash value creation on and off by configuration. The bidder shall specify the supported integrity check
procedures in the explanation of the requirement for verification of the self-assessment.
A
SS01.04
Support for reporting procedures
The HR system must cover legal and reporting procedures in connection with wage payments, social security,
company pension schemes and taxes (see Appendix 4.1 Interfaces_Reporting_Procedures_Overview).
Corresponding electronic reports must be created, retrieved and sent via the system.
Basic and additional modules of the social security reporting procedures must be supported in an ITSG-certified
manner. The reporting procedures currently include
Social security reporting procedures (basic and additional modules):
-
Data Collection and Transmission Ordinance (DEÜV) (ST01.37)
-
Institution identifier data (IK data) (ST01.11)
-
Income replacement benefits (EEL) (ST01.39)
-
Application procedure for employer expenses (AAG) (ST01.32)
-
Electronic certificate of incapacity for work (eAU) (ST01.38)
-
Request pension insurance provider certificate electronically (rvBEA) (ST01.40)
-
Accident insurance UV wage statement (ST01.41)
-
VBL supplementary pension scheme (ZV) (ST01.46)
-
Automatic query of the insurance number at the pension insurance data centre - (ST01.42)
-
Contribution rate file (ST01.13)
-
Paying agent notification procedure (ZMV) - (ST01.43)
-
BA-BEA (ALG) (ST01.33)
-
Contribution statement - employer (ST01.34)
-
Collection of contributions for occupational pension schemes (BV) (ST01.36)
-
Accident insurance data (UV data) (ST01.12)
-
Electronic application and certification procedure A1 (ST01.31)
-
Professional pension schemes (ST01.10)
-
Electronically assisted tax audit (euBP) (ST01.35)
A
13 December 2024 Page 301 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SS01.05
Support for legal and other interfaces
The HR system must have those interfaces that are required to fulfil the legal obligations of the client in the
context of payroll accounting. These currently include the following statutory interfaces:
Taxes:
-
Elster wage (electronic wage tax statement) (ST01.45)
-
Electronic wage tax deduction characteristics (ELStAM) (ST01.44)
-
DLS Digital Payroll Interface (ST01.17)
-
Interface to the Elster portal for income tax registration (ST01.56)
Other:
-
Allowance system for retirement provision - Central Allowance Centre for Retirement Assets (ZUSY/ZfA)
(ST01.47)
-
Monthly earnings survey statistics (ST01.21)
-
Labour cost survey statistics (ST01.26)
-
Personnel statistics Pension recipients (ST01.27)
-
Statistics Structure of Earnings Survey (ST01.28)
-
Child benefit call-off procedure (ST01.15)
-
Pension information procedure (RAV) (ST01.09)
-
Allowance system (ZUSY) (ST01.47)
A
SS01.06
MS Office applications
The contractor must implement an interface to the MS Office products currently used in the financial
administration for generating, displaying and editing files (in particular Word, Excel, Access, at least in the
version currently used by the state of Mecklenburg-Vorpommern (see Annex 4.2 (Standards)) from Microsoft.
The following information on the personnel case must be provided via the interface as required:
-
Basic personal data (personnel number, form of address, surname, first name, title, name suffix),
-
Basic data for processing (title, name, telephone, e-mail)
-
personal address data,
-
Details of the office (with full address),
-
Health insurance details (with full address).
A
SS01.07
Extended connection
The HR system should enable direct integration of the required MS Office products (in particular Word, Excel,
Access, at least in the version currently used by the state of Mecklenburg-Vorpommern (see Annex 4.2
(Standards)) in the HR system, i.e. direct provision of the respective software functionalities without having to
call up the Office products separately.
B
SS01.08
General requirement for processing
The HR system must be able to process, reset, create, delete and correct an automated overview of the
notifications for each personnel case (notification object). The notifications must be automatically filled with
the required master data for each notification object and made available for retrieval and dispatch by users.
A
SS01.09
Transmission and receipt of notifications of the reporting procedures
The transmission and receipt of messages from the reporting procedures must be automated and encrypted.
This can be done via the communication server currently in use (DAKOTA) or implemented by the contractor in
another way (see https://www.itsg.de/wp-content/uploads/2022/12/dakota.ag-Leistungsbeschrei-
bungung-V1.3.pdf).
A
13 December 2024 Page 302 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SS01.10
Reporting dialogue with the health insurance companies
The GKV monthly notifications to the health insurance funds as part of the DEÜV must be created automatically.
The following functionalities must be available:
-
The data is collected and returned from the KomServer (OSCI intermediary), decryption, automated
uploading and processing of the supplied data in particular:
•
Data record DSME confirmation of the insurance number,
•
Data module DBMM - Monthly GKV report,
•
Data module DBGZ - Reporting facts for the flexitime zone,
•
Data module DBBG - Contribution assessment ceiling.
The automated electronic notifications of income replacement benefits (EEL) in accordance with Section 23 SGB
IV must be triggered and feedback processed.
A
SS01.11
Logging
Tamper-proof logging of the most important data (trigger, call and parameters, content entry/title, start/end
times, hash values, sender/recipient, etc.) must be carried out in the overall system for all interface uses and
file movements (with the exception of administrators with the highest authorisation level).
A
SS01.12
OSCI protocol
The HR system must enable the OSCI protocol to be used if required.
A
SS01.13
Speaking file names
Documents must be given a meaningful, i.e. descriptive, file name when they are created, e.g. "2023-01
settlement sheet" for the 1st settlement sheet of 2023.
A
SS01.14
Mass data changes
The HR system must provide an option for changing mass data.
A
SS01.15
API for import and export data
The HR system must provide an API for importing and exporting data.
A
SS01.16
Acceptance of changes to own data from other sources Updates/changes to the HR system's existing master data
must be accepted at any time from other specialised processes via a web interface based on open standards
(e.g. REST or SOAP) and it must be possible to update them directly in the system's own database. The master
data to be transferred must be configurable as part of the administration of the HR system.
A
SS01.17
Transferring changes to your own data to other leading data sources It must be possible to transfer any master
data to other specialised processes via a web interface based on open standards (e.g. REST or SOAP). The data
to be transferred must be configurable as part of the administration of the HR system.
It must be possible to view the entire HR master data record at adjustable intervals.
system to the partner systems for further use.
A
13 December 2024 Page 303 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SS01.18
Push procedure for master data
Each time master data is created and updated, it must be possible to automatically transfer it to defined other
specialised procedures using the push procedure (see SS01.17 (Transferring changes to own data to other
leading data sources)).
The push procedure must be able to be activated/deactivated independently for each connected specialised
procedure.
A
SS01.19
Expandability of the master data fields
The structure of the master data fields must be able to be extended and adapted as required by customising
(without the need to change the standard software core, in particular without adjustments at source code
level).
It does not matter whether an extension or adjustment is made in an existing or additional data structure, as
long as the data can be handled and viewed in a coherent manner.
With regard to the adapted or supplemented data fields, it must also be possible to remove and transfer data
to other specialised procedures in accordance with SS01.16 (Removal of changes to own data from other
sources) - SS01.18 (Push procedure for master data). The extension and adaptation of master data fields are
remunerated on the basis of the specified daily rates for additional services in accordance with the price sheet.
A
SS01.20
Option for the AG:
Interface to ProFiskal (HKR inventory procedure) (ST01.02)
In the event of a delay in the introduction of the client's HKR system (see SS01.49), the contractor must
temporarily realise the connection of the HR system to the HKR inventory procedure ProFiskal at the request of
the client. The technical requirements for the transfer of the booking file and the acceptance of a file with the
incoming payments for the settlement of reclaims apply accordingly. The technical description of the interface
is provided as Annex ST01.02, see also Annex 3.6. The client undertakes to make a decision on whether to
exercise the option by 31 December 2025 at the latest.
A
SS01.21
Payment transaction procedure PPM (ST01.03) (1/2)
The HR system must generate payment transaction files (see 4.7.14.1 (Requirements for the creation of the
payment transaction file), which are to be used when delivering payment files to the payment transaction
procedure of the interface specification for the "Abkom-
(DFÜ Agreement) (https://www.ebics.de/de/datenformate) and fulfil the requirements of the Deutsche
Bundesbank.
This data must be transferred to the payment transaction procedure via an interface. The technical process
description for the interface as well as the content and format of this file are attached as Annex ST01.03.
A
SS01.22
Payment transaction procedure PPM (ST01.03) (2/2)
In the event of an announced adjustment by the Bundesbank, the XML structure payment transaction file in the
HR system must be adjusted in good time as part of the system service without separate remuneration before
the adjustment takes effect.
A
13 December 2024 Page 304 of 366
13 december 2024
SS01.23
Printing and enveloping (ST01.04)
As a rule, documents are printed and sent via the printing and enveloping system of the client's IT service
provider (DVZ). The HR system must provide the data for printing and enveloping via an interface. Documents
to be printed must be transferred via a secure transmission path (e.g. "FTP over TLS", "SFTP", "SCP", etc.) to a
directory at the DVZ on the Beta UX server. The technical description of the interface to the printing and
enveloping service is attached as Annex ST01.04.
A
SS01.24
Option for the client: Qualified signature and seal (ST01.05)
The HR system must be able to sign and seal documents in a qualified manner. To this end, the contractor must
offer the following options and implement them at the request of the client:
1.
The contractor uses the Governikus DATA Deneb Sign Service solution provided by the client and
integrates it into the overall system.
2.
The contractor uses its own solution and integrates it into the overall system. The technical principles of
integration are described in Annex ST01.05.
A
SS01.25
OCR/ICR software (ST01.06)
The HR system must automatically process the data provided by the client's existing OCR/ICR solutions (see 4.3
Input management). The interface is attached as Annex ST01.06.
A
SS01.26
Interface
Communication platform
for
the
HR system
(ST01.08) The CP must provide a
bidirectional interface (incoming and outgoing) that enables all interactions between the CP and the HR system
required in accordance with this service description. A description of the interface is attached as Annex ST01.08.
A
SS01.27
KP-MV service portal (ST01.57)
The CP must enable an interface based on open standards for the provision of documents, including metadata
such as date of receipt/creation, status, description, number of attachments and activity history.
A
SS01.28
Data synchronisation between KP and HR system
Changes to data made in the CP must be available immediately after transmission to the HR system (see also
requirement from chapter 4.2 "Communication platform"). The synchronisation is described in ST01.08.
A
SS01.29
BIC-SCL-Directory (ST01.14)
The receipt of bank master data for the automated processing of SEPA payments must be able to be
automatically imported into the HR system. It must be possible to set up a SEPA identifier for each
department. A description of the interface is attached as Annex ST01.14.
A
SS01.30
Logging BIC-SCL Directory
The HR system must log the data transfer and the data update (including any error events).
A
SS01.31
Configurability BIC-SCL Directory
The HR system must offer the option of configuring the parameters for importing the SCL file (in particular the
target directory, target file name, etc.) by the central specialised administration.
A
SS01.32
Processing the SCL file to be imported (1/2)
The HR system must process the importing SCL file.
A
13 December 2024 Page 305 of 366
13 december 2024
SS01.33
Processing the SCL file to be imported (2/2)
In the HR system, the central specialised administration must be able to configure the SCL files (i.e. selection
options for the scope and content of the BIC-SCL import files).
At least the following selection options should be available:
-
Customisation of the file format, e.g. at least the selection of the output formats CSV, XML
-
Customisation of the output structure, e.g. selection and sequence of the data columns to be output
-
Customisation and selection of the import method, e.g. setting up an automated import process or
manual, needs-based imports)
-
Filter by specific BICs; data from specific banks, e.g. all Volksbanks or savings banks
-
Geographical/regional criteria, e.g. all banks in MV or in Germany
-
By bank type e.g. only online banks without branches.
A
SS01.34
Data of the BIC-SCL Directory
The HR system must receive and read the updated data from the SCL Directory and the BIC Directory and use it
to update the HR system's bank master data.
A
SS01.35
Business travel management KIDICAP.Travel -
Tax-relevant and non-tax-relevant facts to payroll account (ST01.16) The HR system must enable the
acceptance of information from the business trip management system to the payroll account and process it
accordingly (Section 3 EStG). A description of the interface is attached as Annex ST01.16.
A
SS01.36
Annual analysis of personnel expenses, PAJA (ST01.22)
The HR system must use suitable methods to provide the Ministry of Finance (Ref. 250) with selected
personnel data at personnel case level for the purpose of analysing the total budget burden by cause
(monthly allocation) for public sector employees, civil servants and pension recipients on an annual basis.
The generation of the PAJA from the previous payroll system is described in Appendix ST01.22. The technical
information content of the analyses created by the HR system must correspond to the previous PAJA.
A
SS01.37
Monthly analysis of personnel expenses, PAMA (ST01.23)
The HR system must use suitable methods to provide selected personnel data at personnel case level (incl.
promotion history, pension history, death history) to the Ministry of Finance (Ref. 250) for the purpose of
evaluating the total budgetary burden not according to cause - expenditure is allocated to the month of
payment. The generation of PAMA from the previous payroll system is described in Annex ST01.23. The technical
information content of the analyses created by the HR system must correspond to the previous PAMA.
A
SS01.38
Personnel cost extrapolation, PKH (ST01.24)
The HR system must use suitable methods to provide calculations over several months or years on the basis of
the current headcount on the database of the specialised pay and remuneration procedures to the Ministry of
Finance, Ref. 250. The generation of PKH from the previous payroll system is described in Annex ST01.24. The
technical information content of the analyses created by the HR system must correspond to the previous PKH.
A
13 December 2024 Page 306 of 366
13 december 2024
SS01.39
Professor evaluation (ST01.25)
The HR system must provide various information (files) on the salaries and remuneration of all employed
professors and chair representatives at the University of Rostock and the University of Greifswald as well as the
affiliated clinics. The professors' evaluation of the previous salary system is described in Annex ST01.25. The
technical information content of the analyses created by the HR system must correspond to the previous
professorial evaluation.
A
SS01.40
Payment data interface (1/2)
The HR system must have a bidirectional interface for the transfer and acceptance of all relevant data in order to
enable the connection of third-party systems of the state administration, e.g. the future specialised HR
management procedure, time recording systems, the electronic state infrastructure information system (eLIAS)
or other office systems.
A
SS01.41
Payment data interface (2/2)
The interface in accordance with SS01.40 (reference data interface (1/2)) must be based on open standards.
A
SS01.42
TR-ESOR (ST01.49)
The HR system must be able to operate the ArchiSafe module in order to transfer documents to long-term
storage. The description of the interface is attached as Annex ST01.49.
A
SS01.43
Special electronic mailbox for public authorities (beBPo) (ST01.50)
The HR system should be able to communicate via the public authority mailbox. It should enable individual
users to receive messages and send documents in the XJustice standard via an interface (see
https://www.xoev.de/die-standards/uebersicht-aller-xoev-standards/xjustiz-11258).
The sending of documents via the special electronic public authority mailbox should be made possible via OSCI
or XTA (see https://www.xoev.de/osci-xta-3355). A description of the interface is attached as Annex ST01.50.
B
SS01.44
Document interface (ST01.52)
Documents that are intended for other specialised procedures are regularly misdirected into the inventory
system. The contractor's solution must support the transfer of these documents, including their metadata, to
the correct third-party procedure via an interface and thus relieve the processing workload.
A
SS01.45
Pension insurance link (pension equalisation) - General
The HR system must provide an interface for exchanging data with Deutsche Rentenversicherung Bund for the
pension equalisation reimbursement procedure. The HR system must support the current version of the
exchange format for data exchange at the time of implementation.
A
SS01.46
Pension insurance link (pension equalisation) - Registration
The contractor must apply for registration for the exchange of data with the German Federal Pension Insurance
Scheme for the HR system in good time. The deadline for this is 30 June of the previous year. The completed
application must be sent by e-mail to the following address: Kommunikation-Behoerden-Gerichte@DRV-Bund.de
Participation in the new specialist procedure then begins on 1 January of the following year.
A
SS01.47
Pension insurance link (pension equalisation) - adjustment
In the event that the examination for participation leads to the result that admission cannot take place, the
contractor must remedy the reasons found that led to the cancellation of participation, insofar as these are
within his sphere of influence.
A
13 December 2024 Page 307 of 366
13 december 2024
SS01.48
Inbox notification
When using the BundID to log in to the HR system, users should receive a notification in their mailbox in the
federal user account when messages from the HR system are available for them. Registration for the BundID is
required when using the HR system via the KP (chapter 4.2 "Communication platform").
B
ePAePV-A0040
Career portal MV
The HR system should be able to transfer all relevant applicant data from the MV career portal by importing a
csv data record.
It must be possible to transfer the following data from the HR system:
•
Salutation
•
Title
•
First name
•
Name
•
Date of birth
•
Address suffix
•
Street and house number
•
Postcode
•
Location
•
Telephone number
•
E-mail address
•
Severe disability / equalisation
•
Career
B
ePAePV-A1032
ZAED (central selection and recruitment service)
The HR system should be able to transfer information on a selected applicant from the ZAED MV (central
selection and recruitment service).
It should be possible to transfer the following data from the HR system:
•
Salutation
•
First name
•
Name
•
Street and house number
•
Postcode
•
Location
•
Federal state
•
Nationality
•
Phone Mobile phone
•
Telephone landline
•
E-mail address
•
Date of birth
•
Place of birth
•
Seminar group
•
Confirmation sent on
B
13 December 2024 Page 308 of 366
13 december 2024
SS01.49
Interface to the future HKR process
The HR system must be able to generate a posting file and transfer it to the client's future HKR process via an
interface for posting (for the technical requirements, see section 4.7.14 "Payment/payment authorisation").
The HKR process is a solution based on SAP S4/HANA. The HKR procedure will also provide a file with the
incoming payments for the settlement of reclaims. This must be read in by the HR system and processed as
part of the reclaim processes (see e.g. RF01.17). The data transfer will always take place in XML format. The
scope of the data to be transmitted corresponds to the HKR inventory procedure (see Appendix ST01.02). More
detailed information on the data structure is expected to be a v a i l a b l e from June 2025.
If the standard software offered for the transfer of booking data and/or the acceptance of incoming payments
for the settlement of reclaims already has a connection to a standard SAP interface that covers the technical
requirements in the same way, this can be used to connect the HKR procedure instead. In this case, detailed
information on the interface and data structure must be provided with the offer.
A
SS01.50
Option for the AG:
Service wheel leasing interface
At the request of the client, the contractor must implement an interface based on industry standards (e.g.
REST-API) of the HR system to connect the procedures of service bicycle providers of the state of Mecklenburg-
Vorpommern. The HR system must be able to automatically check the authorisation of requests transmitted via
the interface and approve or reject them. It must also be possible to automatically transfer the data for payroll
accounting. This requires interfaces for
•
an automated authorisation check and approval or rejection of company bike requests,
•
the provision of documents and information upon contract activation (licence agreement,
individual leasing contract, etc.) for the Personalakt and payroll,
•
a comparison of the quantities of contracts concluded with the company bike provider and the
contract data recorded in the HR system
•
to set up the reporting of
incidents.
The following data must be provided via an interface as part of the authorisation process:
•
Data on the applicant (employees)
•
Data on the leased object (price, brand, type, etc.)
•
Leasing data (leasing period, leasing instalment incl. insurance and maintenance rate, non-
cash benefit, etc.)
•
Dealer data (name, address, contact details, etc.)
•
Data individually defined by the client to be queried in the application process (e.g. department,
cost centre, etc.)
A
Outlook for future interfaces
There will be a need for further interfaces in the future. As part of the Register Modernisation Act (RegModG), an interface must
be created in future for the authority keeping the register in order to transmit personal data in accordance with §4 and §5
RegModG via automated data retrieval (§6 RegModG). A changeover between the HKR system and the specialised procedures
Personnel Management (ST01.55) and Benefits (ST01.52), which are to be connected to the HR system in future, is to be
expected. In order to transfer documents for long-term archiving to the
13 December 2024 Page 309 of 366
13 december 2024
Landeshauptarchiv (ST01.54), a connection to this is to be expected. The realisation of these interfaces is carried out as a change
request as required.
The client also reserves the right to request a transitional connection of the following systems as a change request:
- Employee portal (MAP), provides employees with access to the HR system and uses roles and rights from the HR system
for authentication.
- Service Portal (DSP), serves as an access point to the current HR system for some departments and provides the
departments with corresponding functionalities.
- Document Management System (DMS), manages incoming documents and ensures access to documents archived
there, taking into account roles and rights.
5.6
Accessibility
In accordance with the Federal Participation Act (BTHG), the legislator has obliged public organisations to provide barrier-free
workplaces, workstations and working environments for the participation of people with disabilities. This also includes the
accessibility of IT processes.
This obligation was concretised for IT procedures of public bodies of the state and local administration of Mecklenburg-
Vorpommern by the Law on Equality, Equal Participation and Integration of People with Disabilities (LBGG MV) and the Ordinance
on Barrier-free Information Technology in accordance with the State Disability Equality Act (BITVO MV).
As a subordinate state authority, the Mecklenburg-Vorpommern State Office of Finance expressly fulfils this statutory mandate.
In accordance with Section 6 LBGG MV, the overall system must be findable, accessible and usable for all users in the usual way,
without particular difficulty and without outside help. According to Section 5 (1) BITVO MV, this requires that it is perceptible,
operable, comprehensible and robust. The use of assistive technologies must be made possible without restriction via
appropriate interfaces.
The accessibility of the overall system aims to take into account the requirements of the following user groups, depending on the
context of use:
7
•
Use without vision: If the overall system provides visual modes of operation, some users rely on the overall system to provide
at least one mode of operation that does not require vision
.8
•
Use with impaired vision: If the overall system provides visual operating modes, some users depend on the overall system to
provide functions that make it easier for them to use their impaired vision.
•
Use without colour perception: If the overall system provides visual operating modes, some users are dependent on the
overall system providing functions that make it easier for them to use their impaired vision.
7
The explanation is identical in content to the explanations in section 4 of EN 301 549 V3.2.1
8
Alternative operating modes should only be provided if the ICT product cannot fulfil the requirements in terms of "basic functionality". The aim should be
for the ICT product to have an inclusive design, with one version for all user groups.
13 December 2024 Page 310 of 366
13 december 2024
•
Use without hearing: If the overall system provides auditory
11
modes of operation, some users rely on the overall system to
provide a visual mode of operation that does not require hearing.
•
Use with impaired hearing: If the overall system provides auditory operating modes, some users are dependent on the overall
system providing extended audio functions.
•
Use without voice capability: If the overall system requires voice input from the user, some users are dependent on the overall
system providing at least one operating mode that does not require voice output from them.
•
Use with limited handling or force: If the overall system requires manual actions, some users depend on the overall system to
provide functions that enable them to use the ICT via alternative actions that do not require handling or manual force.
•
Use with restricted range: If the entire system is free-standing or permanently installed, the controls must be within reach of
all users.
•
Reduction of seizure triggers for photosensitivity: If the overall system provides visual modes of operation, some users will
require that the overall system provide at least one mode of operation that reduces the potential for triggering seizures by light
stimuli (photosensitivity).
•
Use with cognitive limitations: Some users are dependent on the overall system providing functions to simplify and facilitate
use.
5.6.1
Requirements for the overall system
Requirements
labelling
Requirement
Criterion
BF01.01
Accessibility requirements for the overall system
The contractor must ensure that the requirements of Section 5 BITVO MV are consistently and comprehensively
observed and implemented in the overall system.
The individual requirements are prioritised with 1, 2 and 3 and specified in Annex 5.10 Criteria
catalogue_Accessibility The prioritisations have the following meaning:
-
Prio 1: All requirements classified as Prio 1 must be fulfilled by the overall system when the contract is
awarded or the contractor will adapt the overall system with M02 at the latest when the overall system is
provided so that the requirements are fulfilled.
-
Prio 2: All requirements categorised as Prio 2 must be fulfilled at the latest by the time of provision for
overall acceptance.
-
Prio 3: All requirements that have been classified as Prio 3 must be fulfilled in
must be fulfilled within 12 months of the start of productive operation.
A
11
The terms "auditory" and "auditory" are to be understood synonymously in this context
.
13 December 2024 Page 311 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
BF01.02
Requirements for the overall system in accordance with Section 5 (3) BITVO MV - state of the art
If components of the overall system are not covered by the requirements of harmonised standards, the contractor
must provide them barrier-free in accordance with the state of the art.
In the context of digital accessibility, the state of the art means that progressive technologies are used that have
proven themselves in practice and that ensure the best possible accessibility for people with disabilities without
impairing the functionality of the overall system.
The state of the art includes in particular
-
For content management systems: Authoring Tool Accessibility Guidelines (ATAG 2.0),
-
For PDF documents: PDF/UA standard according to DIN ISO 14289-1 (see requirement below),
-
DIN EN ISO 9241-171 Ergonomics of human-system interaction - Part 171: Guidelines for the accessibility of
software.
A
BF01.03
Maintaining accessibility over the entire term of the contract
The Contractor must ensure that the accessibility requirements listed in this section are fully met by the overall
system in the current version of the statutory regulations and standards during the entire term of the system
service without separate remuneration.
The contractor must implement changes to the legal regulations and standards on accessibility in the overall
system within 6 months of their respective entry into force at the latest.
A
BF01.04
Requirement for documents generated by the overall system
All documents provided by the overall system must fulfil the requirements of EN 301 549, section 10 (non-web
documents).
If these are PDF documents generated by the overall system, they must also comply with the PDF/UA standard in
accordance with DIN ISO 14289-1.
A
BF01.05
Requirement for help functions, user manuals, training documents, etc.
Help functions, user manuals and training documents must be accessible. Their design must comply with the
accessibility requirements listed in section 12 of EN 301 549. In particular, all shortcuts and all setting options for
accessibility (e.g. font and symbol size, colour and contrast settings, etc.) must be documented in full and in an
accessible form.
A
BF01.06
Requirements for electronic communication
Electronic communication via the overall system is to be guaranteed barrier-free in accordance with Section 6 LBGG
MV.
The following criteria should be met:
-
Electronic communication can be used without sight.
-
Electronic communication can be used with impaired vision.
-
Electronic communication can be used without colour perception.
-
Electronic communication can be used without hearing.
-
Electronic communication can be used without the ability to speak.
-
Electronic communication can be used with limited handling or power.
-
Electronic communication can be used with limited range.
-
Electronic communication can be used with cognitive limitations.
-
Electronic communication can be used with photosensitivity.
B
13 December 2024 Page 312 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
BF01.07
Requirements for documentation to be supplied (other delivery items)
All documents to be supplied must fulfil the requirements of EN 301 549, section 10 (non-web documents).
If the documents are PDF documents, they must also comply with the PDF/UA standard in accordance with DIN ISO
14289-1.
A
BF01.08
Provision of a feedback mechanism
If the overall system falls within the scope of § 4 BITVO MV, the overall system must provide a feedback mechanism
in accordance with § 9 BITVO MV.
A
BF01.09
Provision of the declaration on accessibility
If the overall system falls within the scope of § 4 BITVO MV, the overall system must provide a declaration of
accessibility in accordance with § 7 BITVO MV.
A
BF01.10
Explanations in easy language and German sign language
If the overall system falls within the scope of § 4 BITVO MV, the overall system must provide explanations in
German Sign Language and Easy Language in accordance with § 6 BITVO MV.
A
BF01.11
Requirements for PDF documents with long-term archiving
If the overall system generates PDF documents for long-term archiving, these must fulfil the requirements of the
PDF/UA standard in accordance with DIN ISO 14289-1 and the requirements of section 10 of EN 301 549 in
addition to the PDF/A standard in accordance with DIN ISO 19005-2a.
A
BF01.14
Additional requirements for the accessibility of the overall system
The overall system should also fulfil the WCAG success criteria of conformity level AAA- in accordance with section
9.5 of EN 301 549.
B
ePAePV-
A0004
Compatibility with technical assistants (sceen readers)
Within the overall system, texts and notes must be written continuously from left to right and not divided into two
block sentences next to each other in order to
to enable the use of technical assistants (screen readers).
A
5.6.2
Requirements for proof of accessibility
Requirement
labelling
Requirement
Liability
BF02.01
Expert test report
The contractor must demonstrate fulfilment of the requirements in accordance with BF01.01 (Prio 1, 2 and
3) by means of an independent, solution-related accessibility test with provision for acceptance of the
overall system. The documents created by the overall system must also be tested as part of this test. The
test must be carried out according to the following procedure:
The test report to be submitted must be the result of a heuristic test of a selected, representative sample of
the overall system by an independent external auditor commissioned by the contractor.
At a minimum, the following use cases must be considered in the accessibility test:
A
13 December 2024 Page 313 of 366
13 december 2024
-
Login dialogue,
-
the recording of a new entry,
-
Changes to an existing personnel case,
-
The preparation of a payslip,
-
The preparation of a decision,
-
Data collection for determining the supply,
-
Start website (possibly also page after login).
The test report must demonstrate conformity with the accessibility requirements in accordance with the
BITVO MV and must cover the following content:
-
Designation of the tested components and parts of the overall system (including version and date of
the tested development statuses),
-
Description of the test scope (tested dialogues or workflows)
-
Description of the test environment (test context, test devices and test tools)
-
Specification of the assistive technologies used (name and version),
-
Overall result with
-
Statement of conformity with the legal requirements
-
Overview of fulfilled, unfulfilled and non-applicable conformity criteria
-
Problem description
-
Problem title
-
Conformity relevance
-
Problem occurrence
-
Period and location of the test,
-
Name of the testers involved.
The evaluation for each individual requirement tested is provided in the results display: Requirement
"fulfilled", "not fulfilled", "not applicable" or
"not testable".
The test report may also contain the following information:
-
Usability statement in addition to the overall result
-
Problem description also contains
-
Impact on the users
-
Cause of problem
-
Problem weighting
-
Recommendation for action
The test report should be readable without barriers (compliance with the requirements of EN 301 549
section 10).
The client reserves the right, if necessary with the involvement of an external service provider, to carry out
its own barrier-free conformity test on the submitted conformity statement.
BF02.02
Proof of accessibility tests during development
As part of the further development of the overall system, the contractor must carry out accessibility tests
during development in order to be able to recognise structural deficiencies at an early stage and make
improvements.
The future contractor must provide evidence that the accessibility tests accompanying the development
have been carried out. The proof must be provided by the future contractor - at least for the modified
components. The underlying conformity test for accessibility can be carried out by a company's own
accessibility test centre,
qualified accessibility tester.
A
13 December 2024 Page 314 of 366
13 december 2024
If more extensive changes are made to the overall system that rule out a purely component-based test, a
selected, representative sample of the overall system is selected in consultation between the future
contractor and the client.
The proof must demonstrate conformity with the accessibility requirements according to BITVO MV and
must be structured in accordance with the "Expert test report" as per requirement N-Acc-A-13.
13 December 2024 Page 315 of 366
13 december 2024
5.6.3
Requirements for the software development process
Requirements
labelling
Requirement
Criterion
BF03.01
Process support "Accessibility expert"
The contractor must provide an "accessibility expert" as the client's contact person. The "accessibility expert" role
ensures compliance with the accessibility requirements of the overall system throughout the entire software
development process. The accessibility expert ensures that
the concept of anchoring accessibility is applied.
A
5.7
Requirements for system environment, documentation and training
Various other delivery components are to be provided as part of the order. This concerns:
•
The system environments to be provided,
•
comprehensive documentation,
•
Training programmes and documents
•
migration.
5.7.1
Requirements for the system environments
In preparation for productive operation, the operational readiness of the overall system is to be established by the contractor in
four system environments during the implementation phase (test environment, reference environment, training environment,
productive environment). The development of new programme versions and related tests by the Contractor shall take place
independently of this in a development environment operated by the Contractor.
In the case of an on-premise offer, the Bidder must prepare a corresponding binding dimensioning for the overall system in the
price sheet, there worksheet P4 ("Notional costs for operation of the data processing centre") with regard to all specified system
environments (see Section 3 Annex 1.5 EVB-IT System GTC). The performance requirements on which the information in P4 is to
be based can be found in Annex 5.2 (Performance requirements and measurement product supplier).
In the case of a SaaS offer, the environments are provided by the contractor during the implementation phase and maintained for
the entire agreed service period. In this case, price sheet P4 shall only contain information on provisions regarding the connection
of the environments to the national network. For further specific requirements in the case of a SaaS offer, see also Section 5.11.
Requirement
labelling
Requirement
Criterion
SL01.01
Separation of the environments
The test environment, training environment, reference environment and production environment must run
independently of each other and in parallel in different network areas.
can be operated in the same way.
A
13 December 2024 Page 316 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SL01.02
Test environment
The contractor must provide a test environment that represents an image of the production environment
but does not contain any real data. Production-relevant changes must be documented and quality-assured
via configuration management and transferred to the production environment via the test and reference
environment. In the case of an on-premise offer, provision is made on the test environment defined by the
contractor in the price sheet (spreadsheet "Fictitious costs for operation of data centre" (P4)).
A
SL01.03
Reference environment
The Contractor must provide a reference environment for acceptance tests. This environment corresponds
to the configuration status of the production environment and is used for final testing and acceptance,
both functional and non-functional. In the periods between deliveries by the Contractor, this environment
is available to the Client for configuration tasks. It is made available on the reference environment defined
by the Contractor in the price sheet (spreadsheet "Fictitious costs for operation of data processing centre"
(P4)).
A
SL01.04
Training system
The Contractor must provide a training system that represents an image of the productive environment but
does not contain any real data. In the case of an on-premise offer, provision shall be made on the training
environment defined by the Contractor in the price sheet (spreadsheet "fictitious costs for data centre
operation" (P4)).
A
SL01.05
Productive environment
The Contractor must provide a productive environment for the overall system that contains all system
components required for the processing steps of real data. In the case of an on-premise offer, provision shall
be made by the Contractor at the level specified in the price sheet (spreadsheet "Fictitious costs for data
centre operation" (P4)).
defined productive environment.
A
Figure 6: DVZ environments. The training environment is not included in this figure as it is not part of the regular deployment procedure.
13 December 2024 Page 317 of 366
13 december 2024
5.7.2
Documentation
In the following, the term documentation refers to both the technical and the functional documentation that is necessary to put
the overall system into an operational state and to be able to operate it in productive mode, as well as to enable the system to be
used without special prior knowledge. The documentation is to be handed over to the client by the contractor in the course of the
implementation phase.
Requirement
labelling
Requirement
Criterion
SL02.01
Documentaries in German language
The specialised documentation (SL02.04) and the technical documentation (SL02.03) must be written in
German throughout. Introduced and explained technical terms are excluded from this rule.
A
SL02.02
Provision of documentation
For the duration of the collaboration, all documentation must be made available electronically in the
current version at a central location defined by the client.
A
SL02.03
Technical documentation
The contractor must provide technical documentation electronically. This must fully describe the
installation/uninstallation, operating environments, parameterisation options, error handling and
configuration options.
The technical documentation includes in particular
-
Technical architecture model
-
Object and data model
-
Test concept including documentation of all test procedures used
-
Operating manual/maintenance documentation
-
Documentation of the operating conditions
-
Installation instructions
-
Documentation of the communication paths between the individual system components (e.g.
database, client, application server, interfaces)
-
Documentation of all interfaces for connection to external systems
-
Documentation of the interfaces between the system components
-
Guide to data backup
-
Release management
-
Release notes regarding the software components used in the overall system (which version with
which status is used in this release)
-
Documentation of the error corrections contained in the release notes and any resulting measures
required to correct the data sets
-
Software Bill of Materials - SBOM (see also SA02.27 (Reliability and
protection))
A
13 December 2024 Page 318 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SL02.04
Specialised documentation
The following minimum requirements must be met with regard to technical documentation:
-
The technical documentation must convey the basic working techniques with the overall system and
contain a description of all implemented functions. The documentation must fulfil the requirements
of Chapter 5.6 BITV 2.0 and the accessibility requirements of the state of MV.
-
The utilisation documentation must be specific to the target group (personnel case, administrator,
specialist administrators, etc.).
-
In the case of new programme versions that affect the operation of the overall system, updated
versions of the user documentation must be provided in electronic form as part of the system service.
-
For the overall system, documentation must be provided for the specialist administration that
comprehensively describes all the intended options for parameterisation and configuration (e.g.
setting up users, assigning user rights, etc.).
-
Documentation must be provided for the entire system for the specialised administration, which fully
describes the initial configuration of the entire system after successful commissioning.
-
Complete documentation of the rights and role concept of the overall system must be made
available.
A
ePAePV-A0710
Standardised glossary
All manuals and instructions must be subject to a standardised understanding of terms.
A
5.7.3
Training courses
Through the training courses, the Contractor must in particular ensure that the Client can build up the necessary expertise for the
use and administration of the overall system and its system components (in particular HR system and communication platform).
The training programme shall be provided by the Contractor in accordance with the
Design "blended learning" as a combination of the following three learning formats:
- Presence: The employees of the WG complete synchronised on-site training sessions accompanied by a trainer,
- Online: The employees of the AG complete synchronised virtual training courses accompanied by a trainer,
- Web-based training (WBT): The employees of the AG complete self-directed interactive virtual training courses without
the support of a trainer.
Appropriate training documents must be provided that contain all system components relevant to the respective training target
group. The training courses are to be conducted primarily in the training environment or a comparable environment.
13 December 2024 Page 319 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SL03.01
Training for system administrators
The Contractor must provide training for future IT administrators [approx. 5 - 10 participants] of the Client,
either in person or online, at the Client's discretion, so that they can then install, administer and operate
the system independently.
A
SL03.02
Training for centralised specialist administration
The Contractor must organise specialist training for future specialist administrators for the overall system in
person or online, at the Client's discretion.
Please note:
The future specialist administrators of the AG [approx. 20-30 people] must be trained in a suitable form so
that they can carry out the specialist administration of the overall system independently.
A
SL03.03
Basic training
The contractor must provide the project staff of the respective system components, approx. 30 people in
total, in groups of up to 15 people, with the basics of the individual system components in the form of basic
training at the start of the project, so that they are familiar with the existing functionality, in particular its
interrelationships and dependencies. Furthermore, the basic technical principles and existing limitations of
the system components must be covered in the training. The basic training courses must be conducted
either in person or online, at the client's discretion.
A
SL03.04
Multiplier training
The contractor must offer multiplier training courses for the future multipliers of the client in the LAF
[approx. 20 persons] in groups of up to 15 persons, so that these persons are familiar with the training
documents and the use of the overall system in order to be able to train and support the clerks
independently. The multiplier training courses must be conducted either in person or online, at the
discretion of the client.
A
SL03.05
Employee training LAF
The contractor must offer training for future users in the LAF [approx. 150 people] in groups of up to 15
people, so that these people can master the use of the HR system in particular and have a basic
understanding of the functionality of the CP. The training courses are to be focussed on specific target
groups for supply, pay and remuneration, each lasting four training days (separate specialist training
courses for each specialist area, including training on overarching basic functionalities). The employee
training courses must be conducted either in person or online, at the discretion of the client.
A
SL03.06
Training for managers
LAF and IM managers must be trained separately in the functionalities of the overall system corresponding
to their role and competences in groups of up to 15 people (approx. 50 people). The training courses for
LAF managers must be held either in person or online, at the discretion of the client.
A
SL03.07
Training for users in the departments
The contractor must provide training for future users
in the departments (Chapter 3.3.21) [approx. 800 people] in groups of up to 15 people so that they can
master the department-specific use of the HR system and have a basic understanding of the functionality of
the CP. The training courses for users in the departments must be organised by choice.
of the AG either in presence or online.
A
13 December 2024 Page 320 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SL03.08
Application support in the departments
The Contractor must provide training courses for application support as future multipliers of the Client in
the departments [approx. 110 persons] in groups of up to 15 persons, so that they are familiar with the
training documents, the use of the functionalities of the HR system relevant for the departments and the
use of the CP, in order to be able to train and support the clerks independently. The training courses for
application support in the departments must be conducted either in person or online, at the discretion of
the client.
A
SL03.09
Option for the AG:
Support for the client in user training during ongoing operations User training can be carried out by the
client's specialist department in person or online. The Contractor must support the Client on call in the
preparation and execution of the training courses. The services shall be remunerated on the basis of the
specified daily rates for additional services in accordance with the price sheet (see also No. 6.1, 2nd
checkbox EVB-IT System Contract; No. 7 EVB-IT System GTC). In addition, the Contractor must carry out
further training courses independently on call.
A
SL03.10
Training for employees who use the BI tool as a designer
The Contractor must provide training that enables employees who use the BI tool as designers to configure
reports independently (approx. 42 people). The training courses for employees who use the BI tool as
designers must be conducted either in person or online, at the client's discretion.
A
SL03.11
Training for employees who use the BI tool as producers
The Contractor must provide training that enables employees who use the BI tool as producers to generate
reports (approx. 500 people). The training courses for employees who use the BI tool as producers must be
conducted either in person or online, at the client's discretion.
A
SL03.12
Supplementary training material for the use of CP by staff cases
The contractor must provide the client with supplementary training material for self-study that enables the
users of the CP to learn and use all relevant functionalities and workflows independently. It should be noted
that the users of the communication platform do not necessarily have an affinity for IT (target group-
orientated topic preparation).
A
SL03.14
Training documents
All training documents for all training courses must be made available to the Client at least in electronic form
and in German.
A
SL03.15
Training data
The Contractor must provide the data for the training examples for the associated training example cases.
A
SL03.16
Role-orientation of the training courses
The training to be provided must be orientated towards the roles of the HR system.
A
13 December 2024 Page 321 from 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SL03.17
Web-based training for the LEON MV training platform
For the target group of multipliers (SL03.04), LAF employees (SL03.05), users in the departments (SL03.07)
and application support (SL03.08), web-based training (WBT) for self-study must also be provided. The WBT
must enable the respective target group to learn and use the functionalities and workflows relevant to them
independently. The following content quality criteria apply to WBT:
-
Clear learning objectives are defined, which serve as a structural element for the respective
training.
-
Content is regularly interactive and motivates users to apply what they have learnt.
-
The design is user-friendly and intuitive.
-
Multimedia sequences such as videos, screenshots, animations or audio explanations are used
-
Users receive immediate and detailed feedback on exercises.
-
Regular tests and knowledge checks are integrated.
-
It can be used on both desktop and mobile devices.
The Contractor must make the WBT available in such a way that it can be used on the LEON MV training
platform (for further information on the specified training platform, see Annexes 5.12 and 5.13). To this end,
the Contractor must offer the following implementation variants (alternative items) and implement them at
the Client's request:
1.
The contractor makes the WBT available on the platform using the excelerate authoring tool.
2.
The Contractor shall make the WBT available on the platform in xAPi format. The Client
undertakes to make a decision in favour of one of the implementation options no later than three
months after the award of the contract.
A
5.7.4
Migration
The contractor is to migrate the master data of the active personnel cases, the documents assigned to them (PDF, DOCX, e-mail)
and their metadata from the remuneration inventory system (FABEA and BEATA) and the EPOS 2.0 personnel administration
system. The data volume from the remuneration process amounts to approx. 930,000 data fields, which are necessary for the
complete payroll accounting and payment authorisation for all personnel cases, as well as approx. 15,000,000 documents (see
Appendix 5.6 Master data).
Subsequently, a delta migration of the structured data from the EPOS2.0 system is required for the ministries.
The state administration's Personalakts are digitised on a department-by-department basis by the client or a service provider
commissioned by the client and fed into the HR system via corresponding import functionalities.
In accordance with SL04.04, the contractor must submit a migration concept within three months of being awarded the contract.
The migration concept is a detailed version of the migration strategy concept submitted with the tender. Further migration-
relevant content must be explained in detail in this concept. The contents result in particular from the following requirements. A
parallel operation of 12 months after the go-live of each module is planned in order to enable recalculations.
13 December 2024 Page 322 of 366
13 december 2024
Parallel operation describes the phase in which the remuneration module is already being settled in the new system and the
remuneration/pension modules are still being settled in the existing remuneration system. In addition, a parallel operation of 12
months is planned after the go-live of the respective module, during which the existing remuneration system is still available for
recalculations.notifications for social security and pension insurance are reported from the payroll HR system. For retroactive
accounting beyond the migration date, notifications must be created from both the payroll system and the HR system. Messages
and confirmations to and from other systems, e.g. ELSTAM, are mapped in the respective payroll system. The messages for the
electronic data exchange for variable remuneration components (see SS01.23) are also processed in parallel.
Requirements
labelling
Requirement
Criterion
SL04.01
Data migration in general
The Contractor must carry out a data migration from the existing payroll system (FABEA and BEATA), a delta
migration of personnel data from EPOS 2.0 and the tests in accordance with the data migration concept
(SL04. (Data migration concept)). The Contractor must provide the necessary tools for this. The data
migration must be reproducible at any time.
A
SL04.02
Minimum scope of data migration
The migration includes the transfer of all data required for complete payroll accounting and payment
processing as well as for personnel administration for all personnel cases at the time of implementation in
accordance with the data migration concept.
A
ePAePV-
N0377
Data migration of personnel data
The Contractor must include a delta migration for the personnel data from EPOS 2.0 in its data migration
concept after the data transfer from the remuneration procedure. The Client shall support the migration with
a data export tool for EPOS 2.0. Migration and formats must be agreed jointly.
A
SL04.03
Minimum scope of document migration
As part of the migration, all documents (PDF, DOCX, e-mail, Word) of the personnel case files including their
metadata (see Appendix 5.7 Metadata) must be transferred to the document management system of the
overall system in an audit-proof manner in accordance with legal retention periods and assigned to the
respective personnel cases.
A
13 December 2024 Page 323 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SL04.04
Data migration concept
The contractor must submit a migration concept within 3 months of being awarded the contract, which is
based on the content of the migration strategy concept (AI04.01) and details this in more detail. In this
concept, the contractor must address at least the following points:
-
List of all migration requirements (incl. reference, e.g. requirement ID of the service description) with a
brief description of the fulfilment of each requirement
-
Presentation of the migration phases "Extraction", "Transformation" and "Load" (ETL) with respective
activities and responsibilities in the form of a RACI matrix (taking into account the Contractor's overall
responsibility for the migration and the scope of participation of the Client communicated with the offer
with regard to the migration)
-
Visualisation of the relevant system environments per migration phase
-
The concretisation of the migration steps in accordance with reference SL04 (step-by-step migration)
and technical activities. The following minimum steps, among others, must be observed:
•
Data cleansing (incl. data quality requirements)
•
Export of the data to files or provision in an SQL database by the client
•
Transformation of the data into the target structure by the contractor
•
Import and automatic correction by the contractor
•
Quality assurance by the contractor
•
Approval of the contractor's corrections by the client
•
Implementation of the complete migration by the contractor
•
Acceptance of the migration by the client in the production environment
-
The detailed scheduling of the migration steps in compliance with the overall project planning (Figure
1).
-
The mapping table(s)
-
The test strategy and reference to the migration test cases
-
The procedure for logging the migration and tests
-
Rough outline of the activities of the actual cut-over (will be detailed in the course of the project as a
migration script)
-
The transfer and integration of personnel files digitised by a third party
A
SL04.05
Interface description for the data import for the migration
Together with the data migration concept, the contractor shall prepare and submit a detailed interface
description of the import interface for the data migration, including the detailed data structure of the HR
system with field description.
B
SL04.07
Transfer of reference amounts
The reference amounts from 2016 in accordance with EG10.26 (BAV subsidy amount (§100 EstG)) must be
transferred to the new HR system as part of the migration.
A
13 December 2024 Page 324 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SL04.08
Logging the data migration
The logging of the data migration (in particular of the automatic corrections made) must be provided by the
contractor in a form that can be analysed electronically, so that a technical correctness check is possible.
It must at least be logged:
-
Transferred data
-
Data not transferred
-
Error states with error code and error description
A
SL04.10
Detailed migration script
The contractor must prepare a detailed migration script for the cut-over based on the migration concept
(SL04.), detailing all activities with start and end times and the person responsible for the migration time.
is created.
A
5.8
Requirements for acceptance and establishing operational readiness
This chapter lists the requirements relating to the acceptance process (chapter 5.8.1), the establishment of operational readiness,
support during the productive phase (chapter 6.3.1) and participation in audits (chapter 5.8.2).
5.8.1
Initiating and carrying out the acceptance procedure
The prerequisite for the performance of functional tests on the part of the Client is that the Contractor has successfully
performed and demonstrated system tests. Testing is therefore carried out by both the Contractor and the Client. A test concept
(see also section 6.8) must be submitted for the Contractor's tests as part of the project implementation. For a successful
acceptance, no acceptance-relevant defects according to the specified defect classification (Section 5.1.1.2 EVB-IT System
Contract) may be detected during the functional test.
"Response and recovery times, defect classes") must be available. The quality gates within the scope of the system or acceptance
test are described in DT01.08 (Permitted number of defects in the system test) and DT01.09 (Acceptance tests of the client).
13 December 2024 Page 325 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DT01.01
Test procedure of the AN
In preparation for the provision of the overall system or individual system components for testing or
acceptance, the Contractor must first carry out all necessary tests on the basis of test cases for quality
assurance and record their results. The test cases shall be provided to the Client by the Contractor
before the start of the test execution. The Client has the right to check the test cases provided and to
object to faulty or missing test cases or test cases that do not fully cover the respective requirements,
which are to be corrected/added by the Contractor. The successful execution of the tests by the
Contractor shall not lead to a reduction in the scope of the Client's acceptance tests.
Necessary tests are in particular
-
Tests to check the technical correctness
-
Integration tests with the connected systems
-
Tests to check compliance with data protection
-
Tests to check compliance with IT security, including penetration tests
-
Tests to check the fulfilment of load and performance requirements
-
Tests to check the operational requirements (only necessary if operation is not carried out by the
contractor)
-
Recovery/restart tests
-
Migration tests
-
Accessibility tests according to chapter 5.6
A
DT01.02
Test execution of the AN
The test results in accordance with DT02.01 must be made available to the Client upon completion of the
respective test. Furthermore, the Contractor shall provide all information, data, etc. that enable the
Client to carry out these and other tests independently on its test environment.
A
DT01.03
Test concept of the contractor
As part of the project implementation, a test concept must be created by the contractor, which must be
agreed with the client and approved by the client. The concept must at least fulfil the requirements
specified in this chapter (DT01). In addition, the specifications in section 6.8 must be complied with.
A
DT01.04
Test coverage of the AN
The Contractor must use suitable means to ensure that all requirements of the overall system are tested
by at least one test case, including several variations and error states. To this end, the Contractor shall
provide the Client with an overview that clearly shows which test cases test which requirements.
A
DT01.05
Independent testing of the system components (KP and HR system)
The client must provide the system components to the contractor for a system component test in such a
form that they can be tested by the client independently of the other system component. When the
system component is made available for testing, the documentation (SL02.04 (Technical
documentation)) and the proof of quality (DT01.04 (Test coverage of the Contractor) and DT01.07 (Proof
of achievement of the Client's quality target for the start of the tests by the Contractor (system component
test, acceptance test)) are also made available.
proximity test))).
A
13 December 2024 Page 326 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DT01.06
Integration tests of the AN
The Client shall provide the systems to be integrated into the overall system (see section 3.1.1) for the
Contractor to carry out the integration tests. The Contractor must ensure in an integration test that the
HR system works together with these systems.
The Contractor must coordinate the requirements for the integration test environment (preparation of
the test systems with test data, etc.) in good time in advance (at least 20 working days before the start of
the integration test).
A
DT01.07
Proof of achievement of the client's quality target for the start of testing by the contractor (system
component test, acceptance test)
When providing system components or the entire system for testing or acceptance, the Contractor must
also hand over the test results of the Contractor's previous tests (see DT01.01), which prove the
achievement of the respective quality target for the start of the tests or the functional test. In particular,
the Contractor shall prove by means of a meaningful protocol that the required test coverage has been
achieved.
The detailed protocol must contain at least the following information:
-
Specification of the number of
•
tested in total,
•
of which successfully tested and
•
failed test cases per system component,
-
an overview of the number of faults (preventing, hindering operation, other) categorised from the
contractor's point of view,
-
a detailed list of the tests carried out and, above all, the defects, categorised according to the
defect classes of the EVB-IT System Contract in Annex 1.5
-
If applicable, an indication of omitted test areas.
A
DT01.08
Permitted number of errors in the system test
The following number of errors per category may not be exceeded with the system test:
no defects in the category "hindering operation" no defects in
the category "hindering operation" 20 defects in the category
"slight".
A
DT01.09
Acceptance tests of the AG
Acceptance is only granted if the limit values from DT01.08 are not exceeded. Clause 12.5 ff. of the EVB-IT
applies to the cancellation of the functional test
System T&Cs.
A
5.8.2
Auditing
The following requirements govern the involvement of the contractor in the event of an audit, for example by the State Court of
Auditors or the State Data Protection Officer.
Requirement
labelling
Requirement
Criterion
13 December 2024 Page 327 of 366
13 december 2024
DT03.01
Participation in audits
The Contractor must co-operate in audits carried out by or on behalf of the Client (for the requirements,
see § 5.3 of the agreement on commissioned processing). This includes not only free access to premises,
but also the provision of documents and data relating to the project/order.
A
DT03.02
Auditing of subcontractors
The Contractor must ensure the participation of its subcontractors in audits carried out by or on behalf
of the Client in accordance with requirement DT03.01 (Participation in audits).
A
DT03.03
Auditing rights
If the subcontractor in turn uses subcontractors, the contractor must contractually ensure that an audit
by the client or on behalf of the client at the subcontractors analogous to DT03.01 (participation in
audits) is also carried out in
can take place in these cases.
A
5.9
Requirements for ensuring the cash register security and audit security of the
overall system as well as the authorisation procedure of the State Court of Auditors
The overall system must comply with the requirements for ensuring cash register security and concretising the principles of
proper accounting. The procedure and the necessary prerequisites are set out in the procedural guideline for the use of IT
procedures in budget, cash and accounting in the state of Mecklenburg-Vorpommern (VerfRi-IT-HKR). The overall system must
fulfil the requirements for approval/release described in the procedural guideline. Approval/release is granted by the MV Ministry
of Finance in agreement with the MV State Court of Audit.
On the one hand, the contractor must in particular create a role and authorisation concept (see section 3.3), a process description
(see KS01.04) and an archiving concept (see SA01.11) that stands up to scrutiny as part of the consent procedure.
On the other hand, the contractor must support the client in the consent procedure, for example by providing information or
supporting the creation of documents. In particular, the Contractor shall support the Client in the preparation of the procedural
documentation based on the procedural description (to be provided by the Contractor), the risk analysis, the compliance concept
and the checklist in accordance with VerfRi-IT-HKR and shall provide the information and support services necessary for a
successful consent procedure (e.g. for testing the interface to the HKR procedure and the state's payment transaction procedure).
The necessary support from the contractor as part of the consent procedure is set out in the VerfRi-IT-HKR and its annexes and
sample documents.
Requirement
labelling
Requirement
Criterion
13 December 2024 Page 328 of 366
13 december 2024
KS01.01
requirements to ensure the cash register security of the overall system and
Concretisation of the principles of proper accounting
The overall system must fulfil all software-related requirements specified in the procedural guideline for the
use of IT procedures in the budget, cash and accounting system in the state of Mecklenburg-Vorpommern
(Ver- fRi-IT-HKR). The requirements are fulfilled at the earliest when the approval of the State Court of Audit
has been obtained in agreement with the Ministry of Finance as part of the approval procedure.
A
KS01.02
Advice and support from the contractor in the consent procedure 1
The Contractor shall prepare the necessary concepts and documentation and provide full advice and
assistance in the consent procedure or provide the necessary input. This applies in particular to the
documents to be prepared and tests to be carried out as part of the approval procedure, as well as to the
procedural documentation, the risk analysis, the compliance concept and the checklist in accordance with
the VerfRi-IT-HKR and the test of the electronic interfaces to the HKR procedure and payment transaction
procedure of the state, so that there are no reasonable doubts about the compliance of the overall system
within the framework of the approval procedure by the State Court of Auditors. The content/description and
scope can be found in the IT procedure guideline including the guideline appendix, Annex 5.9.
A
KS01.03
Advice and support from the contractor in the consent procedure 2
The contractor advises and fully participates in the technical configuration of the system and corresponding
organisational processes in order to develop accepted solutions, for example in workshops, as part of the
approval process. This applies in particular to the establishment of risk management.
A
KS01.04
Procedure description
The contractor's process description (see documentation requirements in section 5.7.2) must include all
required functionalities and technical descriptions of the system. It must also be clear from the process
description that all relevant legal regulations are complied with, cf.
in particular chapter 2.4).
A
5.10
Auditability of the overall system
The overall system must ensure the auditability of the formal and material correctness with regard to the auditability of the
procedure both with regard to individual business transactions (individual audit) and with regard to the auditability of the entire
procedure (procedure or system audit based on a procedure description).
Requirement
labelling
Requirement
Criterion
RV01.01
Appealability of the procedure (1/7)
The overall system must be designed in such a way that factual and chronological evidence is provided for all
business transactions subject to accounting for the duration of the retention obligation (cf. VV No. 4.7 in
conjunction with No. 6 of Annex 6 to §§ 70-0-80 LHO).
can
A
13 December 2024 Page 329 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
RV01.02
Reviewability of the procedure (2/7)
The overall system must ensure that the proof in accordance with RV01.01 (auditability of the procedure 1/7)
can be checked within a reasonable period of time by an expert who is not involved in the procedure to
determine whether
-
the procedural requirements of the provisions according to VV No. 6 to §§ 70-80 LHO including GoBIT-
HKR and this guideline have been complied with (formal correctness) and
-
the substantive requirements for a posting and for a receipt or payment, in particular the existence of a
legal basis, are met (material accuracy).
A
RV01.03
Appealability of the procedure (3/7)
In the overall system, it must be possible to check the business transactions retrogradely and progressively,
i.e. the connection between recorded and processed data up to posting must be recognisable and traceable
both chronologically progressing from data recording (progressive) and chronologically regressing from
posting (retrograde).
A
RV01.04
Appealability of the procedure (4/7)
In the overall system, the completeness of business transactions from their origin to their documentation
must be ensured by means of controls or other measures.
A
RV01.05
Appealability of the procedure (5/7)
The bookings made and their sequence must be documented in the overall system by means of documents
(proof of bookings). The following information must be verifiable for each booking process:
-
Sufficient explanation of the process,
-
Amount to be posted,
-
the payment partner with the information required for the payment transaction,
-
Time of the process and
-
the certificates issued.
If the document includes substantiating documents, it must be ensured that both the substantiating
documents and the supporting documents can be clearly assigned to the document.
A
RV01.06
Appealability of the procedure (6/7)
The overall system must make the vouchers (see RF01.05) unalterable and readable after they have been
created.
A
RV01.07
Appealability of the procedure (7/7)
The overall system must display the business transactions both in full and in extracts, as well as filterable by
time, G/L and person accounts.
A
5.11
Software as a Service
This chapter contains the specific requirements for the operation of the overall system by the Contractor in the case of the offer of
a SaaS solution. In addition, the requirements of the "Non-functional requirements for the overall system", sections 5.1 to 5.4 and
5.7 to 5.8 also apply to an offered SaaS solution, unless expressly regulated otherwise there.
For printing and mailing services, requirement OM01.17 "Covered printing and mailing services" must be met.
services" in the Output management chapter.
13 December 2024 Page 330 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SC01.01
Operating time
The operating time is the time during which the Client can use the agreed services, i.e. all owed system
components (HR system, KP). The use of the service must be guaranteed 24 hours a day, 7 days a week (see
Section 8 EVB-IT Cloud GTC).
A
SC01.02
Availability
Notwithstanding Section 8 EVB-IT Cloud T&Cs, the availability* owed during the core operating time* (see
SC01.03) corresponds to availability class* VK2.The overall system must fulfil the availability* per system
component (KP and HR system).
The target achievement of availability* is determined for each system component using the performance
measurement data (SC01.09) in accordance with the procedure defined in Appendix 5.2 (Performance
requirements and measurement product supplier) in Section 4.
The terms marked with * are defined at the end of the EVB-IT Cloud T&Cs.
A
SC01.03
Core operating time*
The Contractor must adhere to the following core operating times* (for definition see EVB-IT Cloud GTC):
- Mon.-Fri. 07:00 - 18:00
A
SC01.04
Maintenance window
Notwithstanding Section 8 EVB-IT Cloud T&Cs, periods of planned unavailability (in particular maintenance
work) may only take place during the following periods:
- Fri. 22:00 - Sun. 23:00
-
Additional service-related maintenance can be agreed and carried out in consultation with the client,
preferably outside the core operating hours (SC01.03).
A
SC01.05
Response time to fault report from the client
The response time to fault messages from the client is specified in DT02.08.
A
SC01.06
Recovery times
The Contractor must comply with the recovery times after the occurrence of a fault in accordance with
DT02.09.
A
SC01.07
BSI certification
The Contractor must have certification of its information management system (ISMS) in accordance
with BSI ISO 27001, which includes all components required for the SaaS operation of the overall
system and operated by the Contractor, and enclose corresponding proof with the offer.
A
SC01.08
Cloud certification
The Contractor must fulfil one of the following cloud-specific norms and standards at the latest upon
provision of the overall system for Go-Live Phase 1 (Milestone M01) and demonstrate their fulfilment
through test certificates or other meaningful tests by third parties:
- ISO 27017
- ISO 27018
- BSI C5
A
13 December 2024 Page 331 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SC01.09
Performance
For each system component (KP and HR system), the overall system must fulfil the
5.2 (Performance requirements and measurement product supplier) defined in section 1 for each system
component.
The target achievement is checked using the measuring procedures defined in Section 2 with the measuring
tools in accordance with SC01.10. The measurement must be carried out automatically and continuously at
least during the core operating time (SC01.03).
Deviations in target achievement are assessed on the basis of the performance assessment criteria defined in
section 3.
A
SC01.10
Measuring tools for the service levels
The Contractor must use suitable measuring tools to measure or check compliance with the requirements
SC01.02, SC01.03, SC01.04, SC01.05, SC01.06, SC01.09 (hereinafter referred to as "Service Levels"). The
results of the measurements carried out in SC09.09 serve as evidence. It must be possible for the Client to
verify compliance with these service levels with minimal effort, in particular by submitting the raw
measurement data and, in cases of doubt, by carrying out an on-site inspection. The Contractor must report
regularly (at least once a month) on compliance with the service levels.
A
SC01.11
Productive environment
The Contractor must provide a productive environment for the overall system that contains all system
components required for the processing steps of real data and fulfils the quality objectives in the
requirements SC01.02 to SC01.09.
A
SC01.12
Reference environment
The Contractor must provide the Client with a reference environment that represents an image of the
product systems, including the adaptations to be accepted and, if necessary, also contains real data. This
reference environment shall be used by the Client for the acceptance of changes to be accepted. After
acceptance, the Contractor transfers the changes to the production system.
Production-relevant changes must be documented and saved via configuration management and transferred
to the production system via the quality assurance systems.
A
SC01.13
Training environment
The Contractor must provide a training environment that represents an image of the production systems but
does not contain any real data. The client uses this environment to carry out the training of its employees.
A
SC01.14
Test environment
The contractor must provide a test environment that represents an image of the production environment
but does not contain any real data. Production-relevant changes must be documented and quality-assured
via configuration management and transferred to the production environment via the test and reference
environment.
A
SC01.15
Configuration development by specialised administration
At the request of the client, the contractor must provide a development environment for up to 5 specialist
administrators for the configuration. This environment corresponds to the configuration status of the
production environment and is used to test configuration changes.
before they are carried out in the production environment.
A
13 December 2024 Page 332 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
SC01.16
IT service management
The IT service management must be provided on the basis of customary market standards (ITIL v3 etc.),
insofar as this does not result in any deviations from the provisions on the system service contained in this
service description or in the system contract. The Contractor must provide evidence of the performance of
the ITSM by means of certificates (e.g. ISO 20000-1) or comparable audits by third parties by the time the
overall system is provided for overall acceptance at the latest.
A
SC01.17
Integration into the network of the state of MV
The HR system must be linked to the MV Netz CN LAVINE so that the HR system can only be accessed via this.
The connection to the MV network is made via a DVZ service (see Appendix 2.1 Connection of online services
and specialised procedures to the MV service platform V1.0).
A
SC01.18
Accessibility of the CP
The CP must be accessible via the Internet. The CP must be network-separated from the HR system and the
OCR/ICR software in compliance with the BSI guidelines (NET.1.1: Network architecture and design).
A
SC01.19
Protection against unauthorised changes to data
The Contractor must ensure that loss and unauthorised modification (manipulation) of the stored data (files
and processing programs) cannot occur and must take precautions to this end. Proof of the technical and
organisational measures taken for this purpose must also be provided during implementation.
phase.
A
13 December 2024 Page 333 of 366
13 december 2024
6 Requirements for project realisation/implementation
This chapter describes the client's requirements for cooperation with the contractor. In addition, quality requirements for their
acceptance in accordance with the contract are defined.
6.1
GeneralThe Contractor shall bear overall responsibility for ensuring the operational readiness of the tendered service
items and the overall system.
Within the scope of the assignment, the following overarching regulations shall apply for project management as well as test,
quality and error management, among other things. At the request of the Client, the parties shall agree on specifics and details
during the term of the contract. The implementation of these concretisations/detailings in the project procedure shall take place
without separate remuneration.
6.2
Project language and documentation
The project language is German. It is therefore necessary that all project participants who come into contact with the client or its
authorised representative are fluent in written and spoken German. Exceptions to the language requirement are possible for
code comments and documentation, which may alternatively be in English.
The project documentation (at least project manual, software architecture, test concept, test plan, milestone planning, manuals,
etc.) must effectively support the project work and be stored in an audit-proof manner. The collaboration tool to be used for this
purpose is selected in consultation with the client. Appropriate reporting formats in accordance with PRINCE2
(12) (
see section 6.3)
must be established in consultation with the client
Requirement
labelling
Requirement
Criterion
PD01.01
Project language
The project language is German. The exchange of information and documents between the
contractor and the client must be in German.
A
PD01.02
Project documentation
The project documentation must be written in German.
A
PD01.03
Inline commenting of the source code
The inline commenting of the source code of any programming for the adaptation and/or extension
of the standard software must be in either English or German.
A
PD01.04
Documentation language and inline commenting of additional programmes
The documentation and inline commenting of any programming of additional scripts (e.g. shell
scripts, batch jobs, etc.) must be in either English or German.
A
PD01.05
Correspondence with the AG
All correspondence with the client must be in German.
A
12
PRojects IN Controlled Environments
13 December 2024 Page 334 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
PD01.06
Communication with the AG
Named contact persons and other employees involved in the fulfilment of the contract (as well as
possible subcontractors) who communicate with the client must be fluent in written and spoken
German (language level C2).
A
PD01.07
Ongoing adaptation of the project documentation
The Contractor must keep the project documentation (at least project manual, software
architecture, test concept, test plan, milestone planning, manuals, etc.) to be agreed with the Client
up to date throughout the entire term of the system service without separate remuneration.
A
PD01.08
Provision of project documentation
For the duration of the collaboration, the entire project documentation must be made available in
the current version at a central location (online, e.g. on the LAF's SharePoint) as specified by the
client.
A
PD01.09
Revision security when using a collaboration tool
If the Contractor uses a collaboration tool, the Contractor must ensure audit compliance on the part
of the Client, for example by providing regular data exports or alternative replication options.
However, this does not affect the Contractor's overall responsibility and does not extend the
Client's obligations.
A
PD01.10
Report formats according to PRINCE2
In coordination with the client, appropriate reporting formats must be
PRINCE213 (see chapter 6.3).
A
6.3
Project management and implementation, roles
The Mecklenburg-Vorpommern state standard provides for the PRINCE2®
13
project management method. The project structures,
roles and processes are to be aligned with this by the contractor for the project. Integration of the contractor's sub-project
structure including its decision-making structures/control loops at delivery level is expected, whereby the LAF project/programme
structure must be taken into account in the acceptance and decision-making structure. The specific design for this and the
integration of the project into the LEBE.digital programme and the personnel management sub-project will be agreed between
the client and the contractor at the beginning. The contractor must integrate itself into the overall project organisation with
suitable management principles and take into account the strategic guidelines of the overarching LEBE.digital programme.
Acceptance and approval of services shall be based exclusively on the provisions of the EVB-IT system contract, irrespective of
this.
The figure below shows the structure of the LEBE.digital programme.
13
PRojects IN Controlled Environments
13 December 2024 Page 335 of 366
13 december 2024
Figure 7: LEBE.digital programme structure
13 December 2024 Page 336 from 366
13 december 2024
Project management
Committee
Change
Committee
Project assurance
Project
management
Work packages
The following diagram clearly illustrates the existing internal LAF project structures:
Figure 8: Project structure LEBE.references
Project Steering Committee
The project steering committee, hereinafter referred to as the steering committee, is the overarching monitoring and decision-
making body for the project. The steering committee is also the central reporting body for the project management. The steering
committee monitors the fulfilment of the project's objectives in terms of performance, resources (human and monetary) and
deadlines. If a need is recognised or reported, it initiates the control measures required for correction. Decisions that require a
significant change to the promised resources or have far-reaching consequences are made by the steering committee in
consultation with the LEBE.digital programme steering committee.
Meetings of the Steering Committee are held as required. Each member of the steering committee has the right to convene an
extraordinary meeting. The meeting dates are planned and coordinated by the project management. They are also responsible
for the agenda.
The steering committee was set up when the project was initiated by the programme. The steering committee is made up of the
LAF's management as a representative of the AG, the LAF departmental management
13 December 2024 Page 337 from 366
13 december 2024
2 - Remuneration as a representative of the users, the LAF Department Management 6 - IT as a supplier representative and the
Ministry of Finance MV (IV 150 - Information Technology, IV 180 - Basic Issues of Salary and Pension Law, IV 190 - Basic Unit for
Collective Bargaining Law) as a representative of the technical supervision and the LAF programme management of the
superordinate LEBE.digital programme. If necessary, the steering committee will be expanded to include a user representative
from the departments involved in the personnel management sub-project.
Amendment Committee
The Change Committee serves to speed up the decision-making process for ad hoc topics or issues. It is formed at programme
level by the LAF authority management and at project level by the LAF authority management, LAF Department Management 6 -
IT and LAF Department Management 2 (Remuneration and Salaries) and is therefore a subset of the Steering Committee in each
case. The Change Committee decides independently on the majority of issues and the need for an overall consultation of the
Steering Committee.
Decisions made in the change committee are communicated promptly by the project management to the project steering
committee, e.g. via the project status reporting tools.
Project steering committee
The project steering committee is convened on an ad hoc basis as required (on an ad hoc basis, can be convened by any
member). The members are made up of the overall project management of the AN, the LAF 64 programme management, the LAF
64a project management and other members of the AN (e.g. management). Other participants may include members of the
Change Committee, suitable representatives of the DVZ and other participants depending on the main topic. The project steering
committee is consulted in order to discuss key topics (e.g. with regard to the expansion or amendment of the scope of services
owed). If necessary, the project steering committee can be involved and consulted for preliminary coordination, pre-qualification
and pre-negotiation. The decisions themselves are made by the change committee or the programme manager.
Project assurance
The role of project assurance is performed by the LAF. Project assurance acts as an assurance and control body for the steering
committee, assesses the implementation of the project as the guardian of the method, advises the project management and
promotes a quality-compliant mode of operation and problem identification.
Project management of the AG
The role of the client's project management is the direct point of contact for the contractor's project management and
coordinates the timely, proper and professional provision of the cooperation services requested by the contractor. The client's
project management is responsible for communicating progress and results to the steering committee and acts as a mediator for
change requests and with regard to required resources. In particular, the project management acts as the central point of contact
for the steering committee and reports on an ad hoc or quarterly basis in a project status report.
Project resources of the AG
The project team is expected to consist of a proportionate programme manager, a project manager, two technical/organisational
project managers, seven technical project managers, requirements and test managers, 11 technical and testing managers and
two migration managers. Individual roles can be assigned to
13 December 2024 Page 338 of 366
13 december 2024
can be divided between different people. One person can also have several roles. The team is also supported by Department 2 -
Remuneration (in particular the Civil Service Remuneration, Pensions and Remuneration departments) and, if necessary, by two
departments of the IT department.
Project management of the contractor
The Contractor shall be responsible for project management in the area of its responsibility as a general contractor (in particular
the creation of the overall system and bringing about the operational readiness of the overall system within the meaning of the
EVB-IT System Contract). This includes in particular the planning, control and project management during the implementation of
the project, the integration of all sub-projects and service components including quality assurance as well as documentation and
assurance of results with regard to all project steps.
Project management also includes holding project meetings at project level at least once a week together with the persons
representing the client, in which the current progress of the project is presented by the contractor. The Contractor takes the
minutes and prepares a results protocol that clearly documents its understanding of the findings/information and action points
("who" has to deliver "what" "by when"). The contractor's results log must be provided to the client no later than 2 days after the
weekly project meeting. In addition to the project meetings, the contractor shall report to the client's project management in the
middle of the quarter as part of the regular reporting to the steering committee.
The Contractor shall make new development statuses available to the Client at reasonable intervals to be agreed with the Client,
without this giving rise to a testing or release obligation for the Client. Irrespective of any agile approach to internal work
organisation at the Contractor, the Client is not involved in the Contractor's internal working methods and accordingly does not
provide for any agile roles or agile participation. Furthermore, the Client is not obliged to test the development statuses provided.
Individual sprint results are not released.
The Contractor must prepare a functional specification in accordance with section 7.2. The documentation of the tasks,
responsibilities and the specification of the implementation of the requirements by the contractor is carried out in a suitable
project management tool (e.g. Jira) in the form of tickets based on the respective requirement of the service description. This
documentation must cover every requirement from the service description. The information relevant to the test phase and test
management (e.g. test cases, tester results, test runs, etc.) is also documented and managed in a suitable tool (e.g. in the JIRA
plug-in Atlassian Xray). In this way, the contractor provides complete documentation of the software lifecycle, including end-to-
end traceability of the requirements from the service description to the specification to the test case and the test result as well as
any defects during the entire duration of the project.
However, the Client shall receive from the Contractor the necessary access (including authorisations) to the tools used in order to
be able to track the status of the specification, implementation, quality assurance and thus the progress of the project. The tools
are to be designed in such a way that they serve as a central reporting basis, supplemented by any further documentation
required (e.g. accompanying presentations).
The contractor must nominate employees in key positions for the following roles and the associated tasks within the scope of the
person/employee profiles requested:
13 December 2024 Page 339 of 366
13 december 2024
Project management
- Central contact person for the AG
- Coordination of the contractor's project team
- Planning and control of the project and project activities in accordance with generally recognised project management
standards (see ISO 21500, among others), in particular PRINCE2, taking into account the dimensions of cost, time frame,
quality, scope, risk and benefit
- Monitoring the achievement of project objectives
- Coordination of change management
- Preparation and moderation of project meetings
- Concretisation of time and milestone plan
- Implementation of project risk management
- Preparation and presentation of weekly project status reports and project reports for the steering committee
- Advice and proposals for process innovation based on the technical possibilities of the
System for optimum system utilisation (also "process follows system" where applicable)
Specialist advisor References
- Specialist contact persons and advisors for the AG for the area of remuneration
- Responsible for the functional architecture of the overall system
- Persons with expertise in the current remuneration law for the areas of salaries, pensions and remuneration
(knowledge of public service collective bargaining law, salary and pension law, knowledge of the relevant social security
and tax regulations and company pension schemes. - cf. 2.4 as well as good to very good knowledge of specialised
regulations and in the area of references to software-specific core components and processes (including calculation,
objection, workflow).
- Prioritisation and planning of requirements and changes to be implemented
- Advising and supporting the client in the technical implementation of the agreed cooperation services (including
checking conformity with current legal regulations)
- Monitoring the implementation of technical regulations
- Advice, support, guidance, support in the context of process innovation based on the technical possibilities of the
system for optimal system utilisation (if necessary also "process follows system")
Technical architect
- Contact person and advisor to the client for the overall system on technical issues in all areas (interfaces, operation, IT
security, etc.)
- Responsible for the technical architecture of the overall system and the implementation of non-functional
requirements
- Person with expertise in IT architectures and IT architecture patterns in general and for the overall system in particular
- Design of product architecture and the technical components of the overall system
- Advising and supporting the client in the technical realisation of necessary cooperation services
13 December 2024 Page 340 of 366
13 december 2024
- Preparation and coordination of the technical documentation, establishing operational readiness and, if necessary,
implementation and support of operational and administration training for the client
- Technical contact person for the transfer of functional requirements and architecture into technical requirements and
architectures
- Technical contact person for the architecture of the existing interfaces to be adapted or created from/to the new/old
payroll system or HR system, as well as the associated other systems
- Support in the preparation, definition of criteria, evaluation of technical QA during acceptance of the final solution
- Support and QA in establishing operational readiness from the client's point of view, for IT service management and
from a technical/architectural point of view
- Contact person for subsequent IT operations during the project phase
- In the preparation and during the project implementation, contact person and supporter in the establishment,
standardisation and automation of modern methods of the release management process (DevOps, CI/CD, etc.)
- Support with provider management, project planning and project progress control from the AG's perspective
- Advice and proposals for process innovation based on the technical possibilities of the
System for optimum system utilisation (also "process follows system" where applicable)
Test and quality manager
- Contact person and advisor for the client for questions relating to testing and quality assurance for the client's overall
system
- Monitoring of all contractually agreed quality objectives as well as the correct and complete implementation of all
requirements (functional and non-functional) in the overall system
- Person with expertise in test procedures, test methodology, test types (e.g. usability, automation, performance and
load tests, functional tests, etc.) of the overall system
- Creation and coordination of test documentation (e.g. test concept), test analysis and test case creation as well as test
reporting, etc. for the overall system
Tester
- Person with expertise in test procedures, test methodology, at least usability testing, test automation, performance and
load testing and functional testing of the overall system
- Creation, planning and execution of functional and non-functional tests
- Documentation of the tests performed and any deviations from the expected result (defect management)
Developer
- Person with expertise in the technical principles used in the overall system (programming language, architecture,
interface standards, etc.)
- Programming of specific requirements (not covered by the standard product) in the overall system
- Carrying out developer tests in the extensions of the overall system
- Creation of documented, maintainable and expandable codes in the overall system
13 December 2024 Page 341 of 366
13 december 2024
- Creation of fault-tolerant and robust codes in the overall system
- Implementation of the coding standards and coding style of the programming language used in the overall system
6.3.1
Support and operational monitoring
This chapter contains requirements with regard to establishing operational readiness and the productive phase.
Requirement
labelling
Requirement
Criterion
DT02.01
Installation and updating
The system components (HR system and KP) must be individually automated, installable and updatable (e.g. via
script).
A
DT02.02
Backups
It must be possible for the operator to perform backups during operation, without interrupting operations.
A
DT02.03
Production realisation
The Contractor shall be responsible for ensuring that the entire system is ready for operation, including
going live (for the responsibility section in the on-premise model, see section 2.3 EVB-IT System Contract
(on premise variant)).
During the implementation phase, the Contractor shall continuously qualify the Client's procedural support
(LAF and DVZ) as the first point of contact for users so that typical sup- port issues and their processing and
resolution are as transparent as possible to the LAF and the DVZ. In addition, the Contractor must provide
the relevant employees of the LAF and the Data Processing Centre with the know-how to be able to process
atypical cases in a qualified manner. The tools used for support (e.g. ticket system, reviews and processes)
and the procedures must be coordinated, implemented and evaluated on the basis of the contractual
provisions with the client.
A
DT02.04.
Go-live support
Even after acceptance of the overall system, the client has the option of requesting ongoing professional
and technical support for the administration and operation of the overall system in addition to the system
service ("go-live support"). Administration support includes, in particular, support in configuring the system,
setting up and configuring specific test environments and designing test settings.
A
DT02.05
Availability
The overall system (consisting of the contractor's infrastructure and software system, among other things) must
be designed and implemented for 24/7 operation.
A
DT02.06
Maintenance window
Maintenance of all components of the overall system shall be carried out exclusively within a maintenance
window specified by the Client (in the periods Tues. + Thurs. from 19:00 - 23:00) and within the agreed
response and troubleshooting times.
It must be possible to activate a notice to the users of the HR system for maintenance announcements.
A
13 December 2024 Page 342 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DT02.07
Option for the AG:
Optional support services
The Contractor must provide suitable personnel for further support and advice to the Client in accordance
with the submitted employee profiles (e.g. for general software consulting, further development, interface
customisation). This can be commissioned by the Principal optionally and if required at the hourly rate
specified for the role in the price sheet (see Section 6.1, 2nd tick box in conjunction with Section 7 EVB-IT
System Contract)
A
DT02.08
Response time to fault report
The Contractor must guarantee the following response times in the event of a fault:
-
Response time, malfunction preventing operation: 1 hour
-
Response time, disruption to operation: 2 hours
-
Response time, slight malfunction: 4 hours
The response time is the period within which the Contractor confirms the fault and begins to rectify it. The
response time begins with the receipt of the fault report from the Client. If a fault occurs outside the agreed
service times, the response time begins at the start of the next service time.
A
DT02.09
Recovery time
The Contractor must guarantee the following recovery times in the event of a fault:
-
Recovery time, malfunction preventing operation: 8 hours
-
Recovery time, disruption to operation: 24 hours
-
Recovery time, minor malfunction: Elimination in the next release, but after 3 months at the latest
Monthly productive billing runs are subject to particular time criticality. For this reason, a shortened
recovery time of 6 hours applies for disruptions that prevent operations. The recovery time is the period
within which the Contractor must successfully complete the fault or defect rectification work.
The period begins with the response time within the agreed service times (DT02.10 (Service times for the
entire system)) and runs exclusively during the agreed service times.
If the Contractor provides a workaround solution that leads to a reduction in the fault class, the recovery
time for the lower fault class shall apply from the time of provision, whereby the time already elapsed since
receipt of the fault report shall be deducted.
A
DT02.10
Service times for the entire system
The Contractor must ensure the following service times* (for definition see EVB-IT System GTC):
Mon - Fri 08:00 - 18:00 (except public holidays)
If a message is received or an agreed event occurs outside the agreed service times, the response and
recovery time begins at the start of the next service time.
A
DT02.11
Technical administration
The HR system and the CP must provide a means of carrying out its technical administration via an
administration interface suitable for the purpose of technical management and monitoring.
A
13 December 2024 Page 343 of 366
13 december 2024
Requirement
labelling
Requirement
Criterion
DT02.12
Status logging
The HR system and the CP must continuously provide information on the technical status of the system
components. The status information must be traceable, stored until the end of the retention period,
logged, technically analysable by machine and readable by authorised users.
A
DT02.13
Exchange with technical operational monitoring
In the case of on-premise operation, it must be possible to transfer the status data in accordance with
DT02.12 (status logging) via the HR system and the KP to an operational monitoring system via a standard
market interface and analyse it there. The log format, the format of the messages, their meaning and
reaction options for technical management must be documented. The requirements for the design of the
interfaces in accordance with chapter 5.5 apply.
There must be "docking points" to be able to query all important data and statuses or these must be
automatically transmitted to the monitoring system. This information must be organised and enriched with
timestamp, user, status level, error and processing information.
In the case of SaaS or housing operation, the Contractor must provide access to the technical status data
required for first-level support as defined in DT02.12.
A
DT02.14
Scope of technical information
The provision of the scope and level of detail of the technical information on the status of the system for
the HR system and KP (DT02.12 Status logging)) must be customisable.
A
DT02.15
Message monitoring
For all messages exchanged via the interfaces of the overall system between the systems involved via
WebService or similar, the bidirectional send and receive steps and the parameters of all active interfaces in
particular should be monitored and logged.
B
DT02.16
Own monitoring functionality
The HR system should also have its own monitoring functions and thus record functional and system-
related problems that can be viewed via the central specialised administration.
In the event that the monitoring functionality is available, an alarm system must be available in the event of
a fault. In addition, the technical administration interface must provide continuous information about the
status monitoring.
and tracking.
B
6.4
Project team and personnel continuity of the contractor
While the project manager and the deputy are the main contact persons responsible for the activities for which the contractor is
responsible in all phases, the deployment of the other main employees or roles mentioned above depends on the phase-specific
activities of the project. The project manager or, in the event of deputisation, their deputies must be available on working days
Monday to Friday, except on national public holidays, between 09:00 and 17:00 for queries from the client.
13 December 2024 Page 344 of 366
13 december 2024
The Contractor must provide a deputy for the role of project manager who has qualifications and experience comparable to those
of the project manager. As proof of suitability, the Contractor shall submit a professional CV of the deputy to the Client. The client
has the right to reject a deputy who does not fulfil the above requirements. The deputy shall primarily be responsible for
assuming the tasks of the above-mentioned role of "project manager" with all duties if the deputy is temporarily unable to
perform their activities in person for justifiable reasons (e.g. holiday, illness). The project manager is therefore in charge of
carrying out the project management activities of the contractor and is only to be represented by the designated deputy in
justified exceptional cases.
The change of employees involved in the project on the part of the Contractor is only possible for an important reason. If a change
of employees on the part of the Contractor is nevertheless necessary, this change must be organised in the background of the
Contractor in such a way that there are no time delays for the Client in the qualified provision of services in the respective role or
additional expenses due to, for example, the transfer of knowledge. At the same time, the new appointment must be made as
quickly as possible and the client must be informed of a planned change at an early stage, i.e. at least four weeks before the
change. The suitability of the new employee must be proven to the client in advance. The basis of the proof is the person profile
submitted for the role in the tender. Suitability is given if the minimum requirements for the role are met and at least the same
number of points as the profile of the employee to be replaced is achieved. The client has the right to reject individual persons
due to a lack of professional qualifications and experience.
6.5
Confidentiality
The Contractor shall treat all work processes and work results confidentially. The Contractor shall ensure that it familiarises the
employees engaged in the performance of the work with the data protection provisions applicable to them before they
commence their work and that they are bound to secrecy in an appropriate manner for the duration of their work and after
termination of the employment relationship (Art. 28 para. 3 sentence 2 lit. b and Art. 29 GDPR). Confidential information,
including all documents and data, may only be disclosed to an authorised group of persons who are obliged to maintain
confidentiality. In addition, the contractor must ensure that it carefully selects the subcontractors, taking particular account of
the suitability of the technical and organisational measures taken by them within the meaning of Art. 32 GDPR. The relevant test
documents shall be made available to the Client upon request. The Contractor shall ensure by individual contractual agreement
that subcontractors and their employees are subject to the same obligations to cooperate in and tolerate monitoring activities by
the monitoring body as the Contractor itself.
6.6
Place of work and core working hours
The Contractor is expected to work flexibly on projects, mainly remotely. In special cases, the client may also require on-site
deployment at the premises of the LAF (primarily Neustrelitz and Schwerin) or the DVZ as well as affected departments. The
intensity of the on-site presence (in terms of personnel and time) and the regularity of the on-site activities depend on the phase-
specific need for coordination between the contractor and the client. It can also be assumed that not all roles involved in the
project need to be on site at the same time. Detailed arrangements for on-site presence are agreed as part of the project set-up
phase. Taking into account pandemic-related circumstances (such as COVID-19), the following can be agreed between the client
13 December 2024 Page 345 of 366
13 december 2024
and the Contractor can make short-term adjustments to the on-site presence. For remuneration of travelling time and travel
expenses, see Section 7.4 of the EVB-IT System Contract.
In addition to the on-site presence, in particular for different coordination and clarification of open questions, regular video
conferences between the client and the contractor are to be provided.
6.7
Co-operation by the client
The co-operation which is incumbent on the Client is described in Annex 5 to the EVB-IT System Contract and additionally in the
price sheet (Annex 3 to the EVB-IT System Contract), there worksheets P4 and P5. When specifying the content of the
cooperation services in Annex 5 to the EVB-IT System Contract, additional quality requirements on the part of the Contractor for
the Client's personnel cannot be taken into account and are therefore ineffective.
6.8
Test, quality and error management
The contractor is responsible for test and quality management. An essential part of the project is the successful execution of
tests, which is a prerequisite for the acceptance of the overall system or its components.
The Contractor must carry out its own internal tests for quality testing in order to check the achievement of the quality objectives
defined in the non-functional requirements and the successful implementation of the functional and non-functional
requirements. The internal test procedure must be documented in an internal test concept of the Contractor and handed over to
the Client. The Contractor must prove the achievement of these quality objectives and the implementation of the requirements
by submitting the test results, the test cases, the test data and the test coverage to the Client. The submission must be in a form
that enables the client to understand the tests, to check them and to carry them out independently in order to verify the test
result.
In the on-premise operating model, the test and quality assurance environment is provided by the client; with SaaS, it is provided
by the contractor.
At the beginning of the project, the Contractor must draw up the test concept mentioned in the previous paragraph and have it
approved by the Client and, if necessary, update it during the course of the project. The aim is to achieve the quality objectives
and the correct implementation of the requirements by means of a standardised test procedure with uniform processes, roles
and terms for the entire project. The contractor takes up the requirements of the client specified in the tender documents and
takes into account corresponding personnel planning and approaches to test automation, etc. The test concept thus forms the
basis for the creation of standardised test cases and sets the course for the implementation of specific tests, such as test
methodology/test types and roles. The test concept also contains the specifications and procedures for creating or generating
test data for the various test levels.
The contractor must also create a test specification that must include all test cases to be carried out by the contractor. The
Contractor must ensure that each functional and non-functional requirement is covered by at least one (1) test case. Technical
tests are to be automated, functional tests as well, unless the effort would be demonstrably disproportionate. At least the
following information must be documented in the test specification for each test case:
- Unique test case number
13 December 2024 Page 346 of 366
13 december 2024
- Brief description of the test case (e.g. purpose)
- Setup and prerequisites (e.g. specific data required, required system status at the start of the test, etc.)
- Test steps (actions for executing the test case)
- Expected results per test step (specific, testable values/system states to be tested against the actual results)
- Reference to the requirement covered by the test case.
The Contractor is responsible for the generation and ongoing updating of the test data as well as the test cases and the scripts for
migration and test automation. When generating test data, taking into account the properties of real personal data, it must be
ensured that the test data does not replicate the real data in such a way that it is possible to re-identify data subjects by using the
test data. System migration and specific functionality tests, e.g. of user authorisations, are also examples of anonymisation
applications. An anonymisation concept must be submitted for the use of real data as test data. If it is necessary to use
pseudonymised real data, this must be included in the corresponding anonymisation concept and a data protection impact
assessment must be prepared with the associated justification for use. In consultation with the client, the contractor shall be
responsible for the creation and execution of all relevant test cases for the anonymisation.
- Functional tests
- Load and performance tests (LuP)
- Security tests (penetration tests)
- Usability tests
- Integration tests between the system components and connected systems (provision of the connected systems by
the client)
- End-to-end tests (with support from the client)
- Operational tests incl. recovery and restart tests
- Data migration tests for the HR system
- Tests as part of the LRH's consent procedure
Test cases that check technical interfaces or process mass data (LuP, penetration test, etc.) must be automated.
The Client is expected to create its own test cases for the acceptance independent of the Contractor, supplemented by other test
methods (e.g. exploratory tests) in order to validate the acceptance object. For the execution of the acceptance tests by the
Client, the Contractor shall enable the import of the Client's own test data into the overall system and the individual system
components by providing corresponding import functionalities and instructions for use and, if necessary, instruct the Client in the
use of the import functionalities. The client's test procedure is planned in two stages. In the first stage, the Client shall separately
verify the quality of the system components claimed by the Contractor (as far as reasonable and technically possible) (e.g. smoke
testing, quick check). In this way, the Client wishes to ensure that only a quality level of the functionality developed and tested by
the Contractor for each system component is included in the test of the overall system. In the second stage, the overall system and
the integration between the system components and connected systems are tested end-to-end, thus validating the overall
system's readiness for acceptance. Data migration with real data is also tested as far as possible in both the HR system
component test and the overall test.
Functional tests
The Contractor is responsible for the preparation, planning, execution and documentation of functional tests. The Contractor is
expected to follow a structured test procedure that not only tests the functionalities of the
13 December 2024 Page 347 of 366
13 december 2024
The functional tests must not only include software components developed by the Contractor, but must also demonstrate these
functionalities in interaction with other components of the overall system (e.g. third-party components used by the Contractor,
functionality of the implemented interfaces) or in interaction with the third-party systems provided by the Client as part of end-
to-end tests. Functional tests must be carried out. This includes, among other things
- Integration tests: Tests to check the developed interfaces
- System tests: Test of requirements after successful integration of all system components in interaction (end-to-end
test)
- Regression tests: As part of development, to ensure functionality. Also when a system is delivered to confirm that the
functionalities have been retained. Are necessary for updates to revise new functionalities.
Non-functional tests
The contractor is responsible for the preparation, planning, execution and documentation of non-functional tests to cover non-
functional requirements. Non-functional testing refers to the testing of non-functional aspects of software, as opposed to
functional testing, which tests the main functions or features of the software. While functional tests ensure that the software
fulfils its intended tasks, non-functional tests ensure that the performance and behaviour of the software is acceptable under
various conditions. These include, among others:
- Load and performance tests: this involves testing the response time and stability of the software under a specific load.
This test includes:
•
Load testing: Checks the system behaviour under an expected load.
•
Stress testing: Checks the system behaviour under extreme conditions.
•
The load and performance tests must be carried out in a test environment close to production. For example, it
must be possible to technically simulate the load by processing large amounts of data and many user requests
at the same time. These tests should also test the behaviour with increasing load and/or abruptly changing
load. The specific load scenarios to be tested by the contractor should be agreed with the client during the
preparation phase of the load and performance tests. A load and performance test must also be carried out
on the production system before the overall system is handed over for regular operation.
•
The load and performance tests must be automated.
- Security tests: The purpose of a security test is to identify vulnerabilities, threats and risks in software to ensure that
data and resources are protected against possible intrusions. The contractor should carry out its own security tests on a
production-related test environment (e.g. negative test, SQL injection, security-specific software tests, penetration
tests), which are defined in the security concept.
- Usability testing: this involves testing how user-friendly, intuitive and easily accessible the overall system is for end
users.
- Compatibility testing: this involves checking software compatibility in various environments, operating systems,
browsers, networks, etc.
- Reliability testing: this checks whether the software can work continuously without interruption.
13 December 2024 Page 348 of 366
13 december 2024
- Scalability testing: this determines the ability of the overall system to determine the extent to which performance,
functionality and response time behave under a growing workload.
- Recovery testing: this tests the ability of the overall system to recover quickly after a crash or error.
- Volume testing: here the behaviour of the entire system is checked when a large amount of data is processed.
- Installation/uninstallation tests: this checks whether the entire system can be successfully installed and uninstalled.
- Data migration tests: Tests to check the data migration
- Operational tests to verify the operational requirements.
The Contractor must prove that each requirement is checked by at least one test case in its tests. The Client may request that the
Contractor adds further specific tests.
By making the entire system available for acceptance by the Contractor, the Contractor declares to the Client that the entire
system is ready for acceptance. The test results of the previous tests, which prove that the system is ready for acceptance, are
also handed over. Furthermore, an error list with all errors found and not yet rectified, classified according to the defect classes of
the EVB-IT system contract, is also handed over. It should be noted that the maximum number of errors defined in requirement
DT01.08 must not be exceeded when providing for acceptance. The test results and the error list shall not bind the Client.
A distinction is made between the following three fault/defect classes:
A defect that prevents operation or a malfunction that prevents operation exists if the use of the entire system or a significant
part of it is impossible or severely restricted. These include, among other things
- Calculations are carried out incorrectly so that a payment of remuneration is made incorrectly or would potentially be
made incorrectly,
- Data is not stored or is stored incorrectly, so that the processing of payments and/or their correct and audit-proof
documentation or updating is no longer guaranteed, not only in individual cases,
- An error prevents the completion of several sub-processes of an operation (for example, a process step cannot be saved
in the operation; incorrect plausibility checks that prevent the processing of technically correct data),
- Availability is limited by crashes, resulting in repeated processing interruptions for several users of the system
components that are within the provider's sphere of influence (e.g. communication platform and/or HR system, etc.),
- the performance deviates significantly from the performance specifications according to Annex 5.2 (Performance
Requirements and Measurement Product Supplier) and/or is so low that processing is no longer possible within a
reasonable time according to the average execution standard,
- Incorrect data is provided via an interface and this cannot be corrected by means of manual intervention with
reasonable effort or at a reasonable cost to the client,
- Data received via an interface is transferred incorrectly into the system and cannot be corrected by means of manual
intervention in the target system with reasonable effort,
13 December 2024 Page 349 of 366
13 december 2024
- legal provisions (e.g. GDPR) are not or not correctly implemented and there are no technical, organisational or other
measures in place to circumvent or rectify such errors,
- known aspects of insufficient IT security, in particular vulnerabilities with a CVSS score of 7.0 or higher (High or Critical).
A defect that impedes operation or a malfunction that impedes operation is present if the use of the overall system is
significantly restricted. Defects in this category mean that an essential function or an essential business process cannot be
executed or is faulty, but no direct subsequent errors occur. There is no failure of the overall system as a whole, working with the
system is possible with restrictions in operation, time-critical functions and business processes are affected. A workaround is
possible. However, bypassing the system involves a great deal of effort or considerable additional manual work, which can only
be expected of the client in the short term. Unreasonableness is also given if the performance of the system is significantly
restricted and time-sensitive functionalities are involved. These include, among others:
- Defects in individual cases which, if they were to occur in several cases, would be deemed to prevent operation,
- Supporting functions, such as plausibility checks, do not recognise all errors,
- Values are not pre-selected or restricted, or not to the extent possible,
- The performance is limited and there are waiting times of more than up to 3 seconds for non-complex activities,
- Incorrect data is provided to other system components or third-party systems via an interface of the overall system,
which must be corrected by means of manual intervention, but this can only be expected of the client in the short term
- legal provisions (e.g. GDPR) are not or not correctly implemented and there are technical, organisational or other
measures to circumvent or rectify such errors, which, however, can only be expected of the client in the short term,
- known aspects of insufficient IT security, in particular vulnerabilities of medium criticality with a CVSS score of 4.0 to
6.9,
- Search functions do not provide the correct result, or search criteria can only be achieved in a different way, for
example through several search steps.
A minor defect or a minor malfunction is deemed to exist if the overall system can be used without or with insignificant
restrictions. These are among others:
- Incorrect placement of UI elements, typing errors in the GUI, colour errors, font errors etc.,
- Errors in documents that do not limit their usefulness (format, alignment, colouring, etc.),
- A functionality is faulty, but can be achieved via alternative functions without significant additional effort,
- Supporting functions are not available, but do not lead to any significant additional work.
A defect or malfunction that impedes operation also exists if the minor defects or malfunctions lead to a significant restriction in
the use of the overall system or one or more system components (CP, HR system). See chapter
3.1 and the associated requirements DT01.08 Permitted number of errors in the system test and DT01.09 Acceptance tests of the
client in chapter 5.8.
13 December 2024 Page 350 of 366
13 december 2024
7 Offer contents, delivery items and project results
7.1
Offer contents
As part of its bid, the Contractor shall submit five concepts in which it describes its approach with regard to the conceptual work
described below in the event that it is awarded the contract. At the request of the client, the concepts can form the basis for the
detailed concepts to be developed later in the project (see 7.2 below). They are part of the evaluation of the tender and the
subject of the negotiation procedure.
13 December 2024 Page 351 of 366
13 december 2024
Concept for project scheduling and project approach (AI01.01-AI01.04)
Requirement
labelling
Requirement
Criterion
AI01.01
Concept for project scheduling and project approach (1/3)
The bidder must prepare a detailed and realistic project plan proposal (schedule and performance plan)
for the introduction of the overall system based on and in compliance with the milestones of the project
plan in section 2.1.4, stating assumptions, phases, work packages and any additional milestones, and
submit this with the bid. Mandatory components with special consideration of the LAF's maximum
contribution are
-
Planning the implementation of the individual modules and system components including
interfaces and master data management and their integration into the overall planning for the
introduction of the entire system.
-
A proposal for the chronological realisation of milestones M01-M09 according to the project plan.
-
If applicable, proposals for additional milestones for which testable service parts are provided
-
The presentation of a practicable process model for the integration of the LAF's project staff,
specifying the required supplies and competences in the individual project phases and work
packages, presentation in monthly slices to make peaks in effort visible
-
The presentation of the contractor's planned resource deployment (size of the project team,
deployment by role, organisational affiliation, designation of key employees for the required
roles).
-
Presentation of the impact of a change to a Go Live date during the year on the project plan (latest
Go Live Prio 2 on 1 July 2029).
-
The presentation of the advantages and disadvantages of a go-live at the end of the year compared
to a go-live during the year and the effects on the AG's cooperation services
-
The integration of the project structure into the LAF-internal project structure described under 6.3.
The concept must not exceed 35 pages (DIN A4, single-sided, Calibri text body font, font size 12).
The submission of the concept with the above-mentioned minimum content is binding (exclusion
criterion in this respect). The quality of the submitted concept will then be assessed on the basis of the B
criteria AI01.02 - AI01.03 with regard to various aspects.
A
AI01.02
Concept for project scheduling and project approach (2/3)
The project plan submitted by the bidder (schedule and performance plan, see AI01.01
) should show a consistently comprehensible presentation of the minimum components and, in
particular, should not provide for unusually short and/or long implementation times. In addition, the
project plan should include a practicable procedure model for the involvement of LAF project staff,
specifying the competences required in the individual project phases and work packages and their scope
(presented on a monthly basis). The aims here are to
The company's risk management system is designed to minimise the negative impact and equalise the
greater impact on the client.
B
13 December 2024 Page 352 of 366
13 december 2024
Requirement
labelling
Requirement
AI01.03
Concept for project scheduling and project approach (3/3)
The project plan submitted by the bidder (schedule and performance plan, see AI01.01
) should allow sufficient time for the client to analyse the modules and system components, including
interfaces and master data management, individually and in detail.
at an appropriate distance from each other before overall acceptance.
The planned maximum capacities available to the AG are as follows:
The LAF employs o n e
FTE with approx.
190 project working
days.
Concept for
master data
management
management
Requirement
labelling
Requirement
Criterion
AI02.01
Concept for master data management (1/2)
The contractor must submit a concept with the offer in which he describes the specific form in which the
overall system will provide the required master data to the partner systems (at least for the specialised
procedures for benefits and business trips).
The concept must include statements on the following points:
-
Consideration of the HR system as a leading system with centralised master data management
with the following features:
•
For HR master data, the HR system is the leading system that makes its master data available
to other specialised processes, which they can use as
A
13 December 2024 Page 353 of 366
Contribution
2025
2026
2027
2028
2029
Project team References
Project management
1
1
1
1
1
Organisational/technical Project
management
1
2
2
2
2
(T) F(a) a(b) c(e) h(ll) le
ic
(2) h(:) e(K) sapacities
Project management,
requirements management including
test and migration management
5
7
7
7
7
Specialist area of reference
Line support for the implementation of non-functional
requirements
0
2
2
2
2
Line support for the implementation of functional
requirements
8
8
8
8
8
Quality and test management
2
3
3
3
3
Personalakt and Personnel Administration
Department
Organisational/technical project management
1
1
1
1
1
Technical project management,
requirements management including test
and migration management
3
3
3
3
3
13 december 2024
save a persistent copy. Maintaining and updating the references
master data is managed by the HR system as the leading system.
•
Master data from other leading specialised procedures is included in the HR system's
integrated database. The data is maintained and updated via the respective specialised
procedures.
-
Description of the methods and processes used for the initial provision of centralised master data
management, the time required (lead time and implementation) for setting up centralised master
data management and the required involvement of the client.
-
Description of the future need for changes to the data structures (adding and removing further
interfaces and data fields).
-
Supported and/or adaptable market and industry standards for data supply and data exchange
(such as REST, SOAP, WebServices)
-
Supported integration options (such as integration layers, integration patterns)
-
Information on the methods of replication or (re)synchronisation of master data between the
partner systems, e.g. after a failure of a partner system.
-
Information on handling replication and (re)synchronisation errors as well as logging options
-
Description of the functions available for extracting and transferring master data to the partner
systems.
-
Description of the methods that enable the client to independently create the necessary interfaces
between the partner systems.
-
Description of how the central master data management can be extended to other specialised
processes in the state of Mecklenburg-Vorpommern (scalability).
-
For operations: Information on automation options, e.g. for ETL processes.
-
Description of how the requirements of the GDPR are met.
The concept should not exceed 20 pages (DIN A4, single-sided, Calibri text body font, font size 12).
The submission of the concept is binding (exclusion criterion in this respect). The quality of the
submitted concept is assessed on the basis of B criterion AI01.02.
AI02.02
Concept for master data management (2/2)
The master data management concept submitted by the contractor should be comprehensible and
plausible throughout. The use of integrated master data management should be possible for other
specialised procedures with few technical hurdles.
be.
B
Concept for rules and configurability
Requirement
labelling
Requirement
Criterion
AI03.01
Concept for rule sets and configurability (1/2)
A
13 December 2024 Page 354 of 366
13 december 2024
The contractor must create a concept in which he describes the configuration options of the
Centralised specialist administration and related support functions. The concept must contain at least
the following points:
-
Support for users during configuration through pre-selection, hints and error messages, etc.
-
Tools for defining workflows, rules, etc. (use of native rule language (e.g. if-then formulations),
graphical workflow or rule definition, etc.)
-
Avoidance of incorrect configurations through final testing
-
Test option and test support for the change
-
Transferring the configuration to production
-
Configuration of user roles
The concept should not exceed 20 pages (DIN A4, single-sided, Calibri text body font, font size 12).
The quality of the submitted concept is assessed on the basis of B criterion AI03.02.
AI03.02
Concept for rule sets and configurability (2/2)
The submitted concept for rules and configurability (AI03.01) should clearly show the configuration
options of the system throughout. It should also be clear from the concept that configurations t h a t
can b e c h a n g e d by the specialist administration are possible without or with only minimal
involvement.
The IT department is also able to minimise the use/burden of IT personnel resources.
B
IT security concept
Requirement
labelling
Requirement
Criterion
AI04.01
IT security concept (1/2)
The contractor must submit a concept with the offer in which it describes how the requirements for IT
security in accordance with BSI IT-Grundschutz are ensured in the overall system and in operation.
A
13 December 2024 Page 355 of 366
13 december 2024
The concept must include statements on the following points (with reference to the
specific requirements, if any, in accordance with the award documents):
-
Protection needs analysis
-
Risk management
-
Access and access controls
-
Data encryption
-
Vulnerability management
-
Compliance and proof of safety standards/certifications
-
Incident and emergency management system
-
Continuous safety monitoring and regular safety audits
-
Training and sensitisation of deployed staff
-
External service providers (ensuring that subcontractors and other external service providers
of the contractor also comply with the safety requirements)
The concept should not exceed 20 pages (DIN A4, single-sided, Calibri text body font, font size 12).
The submission of the concept is binding (exclusion criterion in this respect). The quality of the
submitted concept is assessed on the basis of B criterion AI04.02.
AI04.02
IT security concept (2/2)
The concept submitted by the contractor should contain measures to ensure IT security. The measures
should focus on the topics in the requirements.
AI04.01 and be consistent, comprehensible and plausible.
B
Migration strategy concept
The Contractor must prepare a migration strategy concept and submit it when submitting the offer. Based on the data schema
(see Annex 5.6), this must describe the migration strategy in detail, i.e. the procedure for data migration, the technical solution
for automating the migration and the method of implementation and evaluation of the migration result, among other things
In addition, potential difficulties, risks and possible measures to reduce/avoid risks (mitigations) must be presented in the
migration strategy concept. For the overall concept requirements, see AI05.01, AI05.02. For details of the content as part of the
implementation in coordination with the client, see section 7.2 below (SL01.04 - Migration concept).
13 December 2024 Page 356 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
AI05.01
Migration strategy concept
The contractor must submit a migration strategy concept for the migration when submitting the tender. In
this concept, the contractor must describe how the big bang migration will be carried out and address at
least the following points ("minimum components"):
-
Comprehensive presentation and justification of the migration strategy, in particular the description
of the trial migrations to be carried out during the project term. Clear phases and milestones,
including timelines, must be outlined.
-
Presentation of the migration steps, in particular the following points must be addressed:
o
which migration steps are carried out manually/semi-automatically/fully
automatically
o
Which migration steps need to be checked for consistency
o
which migration steps can be repeated (as often as required)
o
which migration steps can be simulated
-
Illustration of how a continuous improvement of the migration result can be achieved.
-
Description of the data required by the LAF for the trial migrations. In particular, a description of
the required data quality and the interfaces to be used by the AN.
-
Presentation of the LAF's contribution.
-
Presentation of a risk analysis of the migration strategy and suitable measures to minimise the risk.
-
Presentation of the test strategy, in particular how trial migrations and their success/failure are
tested and evaluated.
-
Presentation of how data protection and data deletion is guaranteed, in particular a comprehensive
presentation of how the security and deletion of data as well as data integrity is guaranteed during
the trial migrations.
-
Explain in detail how a reset to the original state is guaranteed in the event of a test migration error.
-
Comprehensively describe how data is anonymised and which migration tools (e.g. for
anonymisation) are used, including the system environment and time of use.
The quality of the submitted concept is then assessed on the basis of the B criteria AI05.02 with
regard to various aspects.
A
SL04.12
Planning and structure
The migration strategy concept should set out clear phases and milestones, including timelines, for the trial
migrations.
B
SL04.13
Carrying out trial migrations
The contractor should describe in detail how trial migrations can be carried out and how continuous
improvement of the migration result can be achieved.
B
SL04.14
Risk analysis and minimisation
The contractor's migration strategy concept should contain a good risk analysis of the migration strategy
and set out suitable measures to minimise the risk.
B
13 December 2024 Page 357 of 366
13 december 2024
Requirements
labelling
Requirement
Criterion
SL04.15
Data security and integrity
The migration strategy concept of the contractor should comprehensively explain how the security and
deletion of the data as well as data integrity is guaranteed during the trial migrations.
B
SL04.16
Fallback strategy
The migration strategy concept of the contractor should explain in detail how a reset to the original state
is guaranteed in the event of a test migration error.
B
SL04.17
Test strategy
The Contractor's migration strategy concept should explain how trial migrations and their success/failure
will be tested and evaluated. For this purpose, the Contractor shall present a suitable test strategy and
demonstrate how test cases can be checked by the Client.
B
SL04.18
Anonymisation
The contractor's migration strategy concept should comprehensively describe how data is anonymised and
which migration tools (e.g. for anonymisation) are used, including the system environment and time of use.
B
AI05.02
Migration strategy concept
The migration strategy concept submitted by the contractor should show a consistently comprehensible and
plausible presentation of the minimum components. The migration steps described in the migration
strategy concept should be visualised in a comprehensible manner throughout.
B
7.2
Delivery items in the project work
The delivery items listed below must be provided by the Contractor during the project work. The documents listed below must be
released by the Client after the Contractor has provided them ready for acceptance and represent the prerequisite for achieving a
quality gate.
Project management
In the project initiation phase in particular, the Contractor must provide various delivery items, coordinate them with the Client
and release them when the Client is ready to accept them. These include
- Project management documentation (project manual) comparable to the project management documentation
according to PRINCE2 (see section 6.3), which must set out the contractor's project approach.
•
Detailed project plan: As part of the project initialisation, the contractor prepares a detailed version of
the project plan submitted with the offer. The original milestones must at least be adhered to. Earlier
achievement of the milestones is desired. This project plan must include at least the following:
•
The "planning out" (detailed planning) of the individual project phases (when are which
work packages are processed and which delivery items are developed).
•
Workshop planning, including the time required for preparation and follow-up. In agreement with the
client, the time sequence of the workshops is defined in this plan, taking into account
13 December 2024 Page 358 of 366
13 december 2024
The planning must take into account the respective availabilities. The planning shall also specify which
preparations and technical contributions are expected from the Client for the realisation of the
workshops. The Contractor must also take into account in its planning that decision-makers of the Client
will probably not be able to be present at all workshop dates, but only after timely notification of a
corresponding need, and that essential strategic decisions will be made within the framework of the
decision-making structures outlined above and must be communicated at an early stage. Necessary
strategic decisions that are to be addressed to the Change or Steering Committee must be scheduled with
an appropriate lead time.
•
If applicable, duration and number of planned sprints with agile approach
•
The involvement of the specialist teams/groups and other project roles, with a particular focus on the
intended client participation services, taking into account the availability of the client's personnel
resources
•
Early specification of the (preparatory) activities to be performed by the client as part of the cooperation
services, e.g. in the form of a backlog
•
The timing of concept deliveries, including sufficient review cycles and review periods per cycle (review
by the client and rectification by the contractor)
•
Proposals for further project milestones in addition to milestones M01- M07 in accordance with the
terms of reference
•
The dependencies between the work packages/work streams
•
The critical path to project implementation
- Risk management approach (incl. risk matrix)
- Change control approach
- Quality management approach
- Communication management approach
- Establishment of project management resources
- Benefit management approach
The agreed project plan approved by the client replaces the project planning submitted by the contractor in the tender
procedure.
Change / acceptance management concept
The contractor submits a change/acceptance management concept. This must include conceptual planning of the change
management processes for LAF employees and potential users of the communication platform with a view to achieving a high
level of acceptance for the use of the communication platform and for employees in the personnel departments with a view to
increasing their own responsibility with the new overall system through direct entry instead of conventional paper form filling.
LAF administrators, HR departments and potential users of the communication platform must be involved from the outset and
taken into account in change management / acceptance management by the contractor. The concept must include a model for
structuring change management processes (for example: Krüger's 5-phase model, John Kotter's 8-step model, Jeff Hiatt's ADKAR
model).
In particular, the following aspects must be considered and presented in the concept:
- Quantify objectives: Analyse the situation from the perspective of the client and the user.
- Multipliers: Identify multipliers and actively involve users in workshops and training courses.
13 December 2024 Page 359 of 366
13 december 2024
- Methodical approach: Creation of a detailed change management strategy and integration of suitable methods.
Specifications
The contractor must provide a functional specification. This is a documentation of the planned implementation of all
requirements from the service description up to the declaration of provision of the acceptance capability (how is which
requirement implemented where in the specialised procedure). Based on this document, the client can recognise whether a
requirement is to be implemented through standard functionality or through adaptation of the standard functionality or through
extension programming.
Specialised documentation
The following technical documentation must be submitted by the contractor in electronic form:
- The user documentation must convey the basic working techniques with the overall system and contain a description of
all implemented functions.
- The utilisation documentation must be developed specifically for the target group (applicants, LAF administrators,
service administrators, technical administrators, etc.) and take their knowledge into account.
- In the event of changes to programme versions that affect the operation of the overall system, updated versions of the
user documentation must be provided in electronic form (e.g. PDF).
- For the overall system and its system components, documentation must be provided for the specialist administration
that comprehensively describes all the intended operating options for parameterisation and configuration (e.g. setting
up users, assigning user rights, etc.).
- Documentation must be provided for the entire system for the specialised administration, which fully describes the
configurations carried out for the entire system.
- Documentation of roles and rights
Technical documentation
The Contractor must provide technical documentation. This must contain a complete description of the installation/de-installation,
operating environments, parameterisation, error handling and configuration of the software solution.
The technical documentation includes in particular
- System architecture incl. diagram
- Entity Relationship Diagram (ER diagram) of the database, incl. description of all database objects (e.g. tables, fields,
indices, views, constraints, etc.)
- Documentation of all test procedures used
- Documentation of the test results
- Operating manual/maintenance documentation
- Documentation of the operating conditions
- Installation instructions
- Documentation of the communication paths between the individual system components (e.g. database, client,
application server, interfaces)
13 December 2024 Page 360 of 366
13 december 2024
- Documentation of all interfaces for connection to external systems
- Documentation of the interfaces between the system components
- Documentation for data backup
During project implementation, various concepts must be developed by the contractor. These are checked and approved by the
client. After consultation with the Contractor, the Client shall determine when the concepts must be provided. The required
concepts include in particular
- Test and quality assurance concept
- Master data management concept
- Archiving and deletion concept
- Data migration concept
- Data backup concept
- Multi-factor authentication concept
- Training documents
- Concept for professional maintenance and further development
- IT security concept
- Administration manual
Test and quality assurance concept
The Contractor shall provide a concept in which the procedure for tests and quality assurance is concretised on the basis of the
relevant requirements in Section 6.8. In particular, the Contractor must describe the measures and methods that will be used to
support the achievement of the project's quality objectives within the scope of test management. Other important points for the
client are the achievement and control of test coverage, the link between test cases and requirements and how the contractor
enables the traceability and reproducibility of the contractor's test cases.
Master data management concept
On the basis of the master data management concept included in the offer, the contractor shall describe in detail the
implementation of master data management in compliance with the GDPR and with the once-only principle (single-entry multiple
use).
The aim is to provide the required master data in at least two specialised procedures (benefits and business trips) via master data
management in the HR system. Furthermore, the provision for other systems, such as personnel management, is to be ensured in
the future so that master data no longer needs to be stored in their own systems.
Part of the concept is the description of the technical solution in the context of the implementation of required interfaces as well
as the presentation of potential difficulties, risks and possible measures to reduce/avoid risks (so-called mitigation).
The master data management concept must be approved by the client. The implementation is finally agreed between the client
and the contractor as part of the project implementation.
13 December 2024 Page 361 of 366
13 december 2024
Archiving and deletion concept
The Contractor shall submit an archiving and erasure concept for the data protection-compliant implementation of the deadlines
and regulations, as well as for the implementation of the right to erasure upon request of personnel cases (implementation of the
right to erasure upon request by data subjects in accordance with the GDPR) and the justified implementation of solutions (e.g. in
legal proceedings).
Rights and roles implementation concept
The Contractor shall submit a data protection-compliant implementation concept for rights and roles that maps both functional
access restrictions and data access restrictions for users (see SA01.13 in section 5.3.1).
Data migration concept
The Contractor must prepare a data migration concept in which it describes in detail the migration strategy, the data migration
procedure, the technical solution for automating the migration and the way in which data corrections are carried out, based on
the data schema (see Annex 5.3). The migration concept must also describe potential difficulties, risks and possible measures to
minimise/avoid risks (mitigations). The strategy is finally agreed between the client and the contractor during project
implementation.
Multi-factor authentication concept
The contractor shall submit a suitable implementation concept for the realisation of multi-factor authentication (MFA). This must
provide full technical support for the technical implementation of the relevant business and data protection requirements
In particular, the following points of multi-factor authentication must be considered and presented in the concept:
- Registration of users at the KP
- User registration at the CP and HR system
- Critical transactions that require authentication to be repeated.
- Information on the specific factors
- Information on user integration, guidelines and administration from an MFA perspective
•
Information on user management must be provided on how individual or multiple new users are to be given
access to MFA functionality.
•
How to manage policies.
•
How the factors selected by AG are to be used and how user groups are to be authenticated. A distinction
must be made between at least the user group of internal processing (users of the HR system), the user group
of end users of the CP (employees and pensioners) and the user group of functional and technical
administration (both HR system and CP).
- Information on the security of the transmission path of the authentication factors
- Information on adaptability: It must be described which MFA method can be used to cover which levels of security
requirements and how the MFA method offered can be used to fulfil them.
13 December 2024 Page 362 of 366
13 december 2024
solution can be customised to meet the very high security requirements of the HR system and its operating
environment.
- Information on user-friendliness in the administration of the MFA solution
•
The client must describe how the MFA solution offered is to be used by the end user.
- In addition to confirmation of compliance, it is expected that the EU standard on accessibility (EN 301 549), and in
particular the use of the intended identification tools for disabled users, will be described. Integration into the CP and
the MV-IDM
•
The contractor must describe how integration into the communication platform (CP) and the MV Identity
Management (IDM) can take place.
Training documents
The Contractor shall prepare the following training documents:
- for the training of the central specialised administration
- for the training of system administrators
- for the training of multipliers (on call)
- for employee training LAF (on call)
- for the training of managers
- for the training of users in the departments
- for the training of application support in the departments
- for the basic training
- for the use of the CP by the users
- for training employees who use the BI tool as designers
- for the training of employees who use the BI tool as producers
The training documents are provided in electronic form and are written in German. They are self-explanatory and suitable as a
reference work (comprehensive requirements for the training concept can be found in chapter 5.7.3).
Concept for professional maintenance and further development
The contractor submits a concept in which it explains how it intends to organise the further development of the technical rules
and regulations in the future. The technical rules and regulations are constantly evolving, e.g. due to ordinances, amendments to
the law, agreements between the parties to collective agreements, etc. In the concept for professional maintenance and further
development, the contractor shall describe how it intends to fulfil the corresponding responsibility for the ongoing adaptation of
the overall system with regard to changes in the legal situation. The Contractor shall explain the existing remuneration expertise
and the availability of the corresponding infrastructure (organisational structure of the Contractor in the area of maintenance and
further development, technical tools, etc.) and explain the value chain starting with the amendment of the regulations and
provisions through to implementation in the HR system.
IT security concept
13 December 2024 Page 363 of 366
13 december 2024
The Contractor must fully support the creation and regular review of an IT security concept by the Client.
Data backup concept
The contractor shall submit a concept in which it explains the measures taken to protect IT systems and data from accidental loss
and how data can be quickly reconstructed in the event of loss.
Above all, the type of data backup (full, incremental or differential) and the associated influencing factors must be described.
Administration manual
The contractor shall submit an administration manual that describes which administration functions are provided. In particular,
tasks and roles, the authorisation concept, user management and the administration of groups and mailboxes must be taken into
account.
13 December 2024 Page 364 of 366
13 december 2024
8 Attachments
The list of annexes provides an overview of the additional documents referred to in this service description and the respective
annexes. Some of the annexes to the general interface descriptions refer to the following annexes. These are also available for
viewing.
1 Appendices on the initial situation, general system description and offer contents
1.1 Annex: Offices
1.2 Appendix: OrgPlan - Employees (as at 16/02/2014)
1.3 Annex ANG 2 a EVB-IT system contract (on premise variant)
1.4 Annex ANG 2 b EVB-IT System Contract (SaaS variant)
1.5 Appendix: EVB-IT System GTC
2 Systems Communication platform
2.1 Annex: Connection of online services and specialised procedures to the MV Service Platform V1.0
2.2 System e: Standard configuration
2.3 Attachment: Document status_Actions
2.4 Appendix e: Knowledge database
3 Systems for processing covers
3.1 Appendix e: Personnel case status
3.2 Annex e: Groups of persons
3.3 Appendix e: further reference components
3.4 Appendix e: List Evaluations_Documents_Protocols
3.5 Attachment e: Suteda_File
3.6 Appendix: Dataset_structure_references_inventory_procedure
3.7 Annex e: Sample attachment sheet
3.8 Annex e: Objection process
3.9 Attachment: Route of objection
3.10 Attachment: Reclaim process_BE_VE_AG
3.11 Attachment: Reclaim process_EG
3.12 Annex e: statutory retention periods
13. December 2024 Page 365 from 366
13 december 2024
4 Plant interfaces
4.1 Appendix: Interfaces_reporting_procedure_overview
4.2 Appendix: Standards
4.3 Annex e: ST01.02_Profiskal
4.4 Annex e: ST01.03_PPM
4.5 Annex e: ST01.04_Printing/Inserting
4.6 Annex e: ST01.05_Signature
4.7 Annex e: ST01.06_OCR/ICR
4.8 Annex e: ST01.08_Communication platform
4.9 Annex e: ST01.14_BIC_SCL
4.10 Annex e: ST01.16_KIDICAP-TMS
4.11 Annex e: ST01.22_PAJA
4.12 Annex e: ST01.23_PAMA
4.13 Annex e: ST01.24_PKH
4.14 Appendix e: ST01.25_Professor evaluation
4.15 Annex e: ST01.49_TRE-SOR
4.16 Annex e ST01.50_beBPo
4.17 Attachment: PKH_for_tariff_matrix_structure
5 Systems non-functional requirements
5.1 Appendix: Gender-equitable language
5.2 Appendix: Performance requirements and measurement Product supplier
5.3 Enclosure: Extract from password policy
5.4 Attachment: SDM_Logging
5.5 Appendix: Usability_Testing according to ISO 9241-114
5.6 Appendix: Master data
5.7 Appendix: Metadata
5.8 Appendix: Test criteria for multi-client capability
5.9 Appendix: IT procedure guideline
5.10 Appendix: Accessibility criteria catalogue
5.11 Appendix: Multi-factor authentication and single sign-on
5.12 Annex: Governance guidelines LEON MV
5.13 Appendix: Excelerate information on the tool
13. December 2024 Page 366 of 366