diff --git a/app/docs/gelijkwaardige-beloning/usage-notes/conditions.md b/app/docs/gelijkwaardige-beloning/usage-notes/conditions.md index c09ffc0..7eae976 100644 --- a/app/docs/gelijkwaardige-beloning/usage-notes/conditions.md +++ b/app/docs/gelijkwaardige-beloning/usage-notes/conditions.md @@ -6,47 +6,164 @@ The message models can be found in [Semantic Treehouse](https://setu.semantic-tr The REST API specifications can be found here: [Purchase to Pay API specifications](../api/oas-gelijkwaardige-beloning) ::: -For nearly all benefit components certain conditions may apply. This means that the component is or is not applicable to workers that meet these conditions. For example: -* an overtime allowance might only be applicable up to salary scale 10 -* an allowance for home working costs is applicable for certain functions +For nearly all benefit components, certain conditions may apply. This means that the component is or is not applicable to workers who meet these conditions. For example: +* An overtime allowance might only be applicable up to a certain salary scale. +* An allowance for home working costs might be applicable only for specific job functions. +* A youth salary scale might only apply to employees within a certain age range. -To specify those conditions, all benefit components elements can have a `conditions` list element. The element can contain zero, one or many (`0..n`) condition elements. A benefit component applies to workers that satisfy **all** conditions. +To specify these conditions, most benefit component elements (like those in `remuneration`, `allowance`, `leave`, etc.) can have a `conditions` list element. This element can contain zero, one, or many (`0..n`) condition objects. A benefit component typically applies to workers who satisfy **all** specified conditions within that list. ## Condition types -The SETU has identified that there are many conditions. In order to be able to automate the evaluation of conditions as much as possible, the SETU-standard introduces `condition types`. The first version of the standard contains 6 standardized condition types: -1. Salary scale conditions -2. Function conditions -3. Age conditions -4. Employment duration conditions -5. After `x` hours per day -6. Textual conditions; catches "other conditions" +SETU has identified various conditions. To enable automation in evaluating these conditions, the SETU standard introduces `conditionType`. The first version of the standard includes several common condition types, such as: +1. Salary scale conditions +2. Function conditions (related to job roles) +3. Age conditions +4. Employment duration conditions +5. Conditions based on hours worked (e.g., "after X hours per day") +6. Textual conditions (for "other conditions" not covered by specific types) -For next versions, more common conditions types can be added. The `conditions` list structure is designed for this. +Future versions may include more common condition types. The `conditions` list structure is designed for this extensibility. -Each condition type has its own set of object properties that are needed for the automatic evaluation. E.g. a salary scale condition can contain a `salaryScaleMaxInclusive` element to specify that a benefit component is only applicable for workers up to and including a certain salary scale. +Each `conditionType` can be accompanied by specific properties relevant to its evaluation. However, for version 1.0, only the conditionType is implemented. The following (commented out) sections of the following examples showcase the models future capabilities. For instance, an `ageCondition` will include properties like `ageMinInclusive` or `ageMaxExclusive`. If a structured `conditionType` is not available or suitable, the `textualCondition` type can be used with a `description` field. The list of defined condition types is maintained as a codelist here: [SETU Condition types](https://setu.semantic-treehouse.nl/codelist/Codelist_89d3b9a9-8927-45de-b578-1cf96a90e6a3). -## Example json -The example below gives an impression of how the `conditions` element is used. It specifies 3 conditions that apply to the overtime allowance. A worker needs to meet ALL 3 conditions for the allowance to apply. +## Example JSON +The examples below illustrate how the `conditions` element is used in various parts of the pay equity specification. + +### 1. Function-based Condition on a Remuneration Block + +This example shows a condition applied to an entire remuneration block. This block is applicable to all functions, except for the function with ID "function123". + +```json +{ + "remuneration": [ + { + // ... other remuneration details ... + "conditions": [ // Conditions that apply to this entire remuneration block (salary table). + { + "conditionType": "functionCondition", // Specifies the condition relates to job functions. + // "applicableToAllFunctions": true, // Indicates if it applies to all functions by default. + // "except": ["function123"] // List of position IDs (from positionProfile) that are excluded from this remuneration block. + } + ] + } + // ... other remuneration blocks ... + ] +} +``` +In this case, the `remuneration` settings would apply to employees in any job function, unless their specific `positionId` is "function123". + +### 2. Employment Duration Condition for an Individual Salary Increase + +This example shows a condition for an individual salary increase. The increase is dependent on the employee meeting certain employment duration criteria. + +```json +{ + "remuneration": [ + { + // ... + "individualSalaryIncreaseRate": [ + { + "expenseDate": "2026-01-01", // Date when this specific increase rule takes effect. + "line": { + // ... amount and interval details ... + "conditions": [ // Conditions that must be met for this specific increase rate to apply. + { + "conditionType": "employmentDurationCondition" // Type of condition (e.g., based on tenure). + // Other condition fields like 'durationYears' (e.g., minimum years of employment) + // would be specified here, based on the detailed schema for "employmentDurationCondition". + } + ] + } + } + ] + // ... + } + ] +} +``` +This `employmentDurationCondition` would be further detailed with specific properties like the required number of years/months of employment for the increase to apply. + +### 3. Textual Condition based on Performance + +Here, an individual salary increase is based on employee performance. The `conditionType: "textualCondition"` with a separate `description` field can be used as a way to list any type of condition in a free text field. + +```json +{ + "remuneration": [ + { + // ... + "individualSalaryIncreaseRate": [ + { + "expenseDate": "2026-01-01", + "line": { + "amount": { + "value": "4", + "unitCode": "percentage", + // ... baseAmount ... + }, + // ... intervalCode ... + "conditions": [ + { + "conditionType": "textualCondition" // Example of a textual condition. + // "description": "Based on performance of the employee." + } + ] + } + } + ] + // ... + } + ] +} +``` + +### 4. Age-based Condition on a Salary Step + +This example is from a salary scale for youth minimum wages. A specific salary step applies only if an age condition is met. ```json -"conditions": [{ - "conditionType": "salaryScaleCondition", - "salaryScaleMaxInclusive": "10" // value refer to enumerations > salaryScale > name -},{ - "conditionType": "functionCondition", - "applicableToAllFunctions": true, - "except": ["function123"] // values refer to positionProfile > positionId > value -},{ - "conditionType": "textualCondition", - "description": "Indien u overwerkt aansluitend aan uw dagelijkse werktijd geldt als aanvullende voorwaarde dat u dan pas recht heeft op een vergoeding als u: * minimaal 15 minuten overwerkt als uw werktijd die dag minder dan 4 uur bedraagt of * minimaal 30 minuten overwerkt als uw werktijd die dag 4 uur of meer bedraagt." -}] +{ + "remuneration": [ + { + // ... (details for a youth remuneration block) ... + "salaryScale": [ + { + "name": "Minimum wage youth", + // ... + "salaryStep": [ + { + "name": "Pay for youth: Age 18", + "value": 1850.75, + "minimumWage": true, + "conditions": [ + { + "conditionType": "ageCondition" // Condition is based on age. + // Specific age fields like 'ageMinInclusive': 18, 'ageMaxExclusive': 19 would be detailed here + // according to the "ageCondition" type's schema. + } + ] + } + // ... other salary steps ... + ] + } + ], + "conditions": [ // This outer condition applies to the whole "Minimum wage youth" remuneration block + { + "conditionType": "ageCondition" + // Specific age fields like 'ageMaxExclusive': 21 (e.g., applies to employees under 21) would be detailed here. + } + ] + } + ] +} ``` +In this scenario, the `salaryStep` "Pay for youth: Age 18" is only applicable if the employee's age meets the criteria defined within its `ageCondition` (e.g., the employee is 18 years old). The entire "Minimum wage youth" `remuneration` block itself also has an overarching `ageCondition`. -## JSON schema +## JSON Schema Snippet -Below is a **snippet** of how the condition types are specified in JSON schema. This is used as such in the Open API specifications. +Below is a **snippet** illustrating how condition types might be specified in a JSON schema, often used in Open API specifications. This demonstrates a common approach using `anyOf` to allow different structures based on `conditionType`. ```yaml schemas: @@ -55,41 +172,48 @@ Below is a **snippet** of how the condition types are specified in JSON schema. items: $ref: '#/components/schemas/Condition' Condition: - type: object anyOf: - $ref: '#/components/schemas/TextualCondition' - $ref: '#/components/schemas/SalaryScaleCondition' - $ref: '#/components/schemas/FunctionCondition' - required: - - conditionType + - $ref: '#/components/schemas/AgeCondition' + - $ref: '#/components/schemas/EmploymentDurationCondition' TextualCondition: type: object properties: conditionType: type: string - const: textualCondition + const: textualCondition description: type: string + required: + - conditionType + - description SalaryScaleCondition: type: object properties: conditionType: type: string - const: salaryScaleCondition + const: salaryScaleCondition salaryScaleMaxInclusive: type: string salaryScaleMinInclusive: type: string + required: + - conditionType FunctionCondition: type: object properties: conditionType: type: string - const: functionCondition + const: functionCondition applicableToAllFunctions: type: boolean except: type: array items: type: string + required: + - conditionType + # AgeCondition, EmploymentDurationCondition, etc., would be similarly defined. ``` diff --git a/app/docs/gelijkwaardige-beloning/usage-notes/rates.md b/app/docs/gelijkwaardige-beloning/usage-notes/rates.md index 0743c25..0a8266f 100644 --- a/app/docs/gelijkwaardige-beloning/usage-notes/rates.md +++ b/app/docs/gelijkwaardige-beloning/usage-notes/rates.md @@ -1,4 +1,4 @@ -# Building block pay equity +# Building block: Pay Equity Structure :::info DOCUMENTATION The message models can be found in [Semantic Treehouse](https://setu.semantic-treehouse.nl/specifications). There you can also find example messages and validation artifacts in both XML and JSON. @@ -8,159 +8,312 @@ The REST API specifications can be found here: [Purchase to Pay API specificatio ## Introduction -The 'inquiry-pay-equity' data standard is created from a set of building blocks and a set of generic elements. The template of the building blocks all follow a similar structure, which we call "pay equity". Multiple of these building blocks taken together can be used to describe almost all regulations and employment conditions applicable to a certain employee. As the building block 'pay equity' is reused throughout the 'inquiry-pay-equity', below its general structure will be further explained. - -## What is the building block 'pay equity'? -As stated, the 'pay equity' building block is a standardized set of elements that is used to describe almost all employment conditions and regulations in the 'inquiry-pay-equity' data standard. This building block makes it possible to describe a great variety of regulations in a uniform way. These regulations range from allowances & compensations to paid leave & sick pay. - -## What are some of the key features of the building block 'pay equity'? -- **Type of regulation:** This element indicates the type of regulation. Examples include: the type of compensation (e.g. overtime compensation) or type of leave (e.g. paid leave). -- **Effective period:** This period indicates what period the regulation is applicable. It uses the elements 'validFrom' and 'validTo'. This element is not connected to when the regulation is earned or the compensation is granted, but rather focusses on the effective time period of the regulation itself. -- **Periods:** This element defines the time period in which the regulation is applicable to an employee and thus 'earned'. The combination of the three following elements allows us to specify individual points in time, ranges of times and recurring times. - - **Date period:** A specific date or a range of dates (e.g. '31/03/2025'). - - **Weekdays:** A recurring time during the week. (e.g. 'Friday, Saturday') - - **Time period:** A specific time or a range of times during the day (e.g. from 18:00 until 23:00). -- **Regulation rates (Lines):** This element allows us to convey the different rates that are applicable for this regulation. The distinction between the different rates is made through the conditions that can also be provided in this element. Due to the great variety of ways in which a regulation can be provided to the employee (e.g. extra pay/paid leave/lunch/etc.). The lines element allows us to model this great variety. It consists of three key elements (Value, Base and Interval), which together can be used to express almost any type of compensation/allowance/benefit the employee can receive. - - **Amount:** (container element) which contains the compensation/allowance/benefit that the employee receives. - - **Value:** The actual value of the compensation/allowance/benefit. - - **Base Amount:** The base amount over which the value of the compensation/allowance/benefit is calculated. - - **Interval Code:** An element that can indicate the recurring nature of the compensation/allowance/benefit. An example: a certain regulation X is earned **PER** week/month/item. This indicates that every week or every month or for every item the regulation that is described is applicable. - - - - - -### Period Structure - -This JSON-example describes a compensation for irregular work hours called "irregular hour compensation summer". The regulation is valid from July 1st 2025 until 31st of December 2025. The compensation is applicable on mondays, tuesdays and wednesdays from 18:00 until 23:00. +The 'Inquiry Pay Equity' data standard is constructed from a set of common structural patterns (building blocks) and generic elements. Many of these building blocks, such as those for allowances, leave, and sick pay, follow a similar structure. We refer to this recurring pattern as the "Pay Equity Structure". Multiple components using this structure can collectively describe a wide array of regulations and employment conditions applicable to an employee. This page explains the general nature of this Pay Equity Structure. +## What is the Pay Equity Structure? +The Pay Equity Structure is a standardized set of elements used within various components of the 'Inquiry Pay Equity' data standard (e.g., `allowance`, `leave`, `sickPay`, `remuneration`). This consistent structure allows for a uniform way to describe diverse regulations, ranging from monetary compensations and allowances to non-monetary benefits like paid leave. -``` +## Key Features of the Pay Equity Structure +Most components using this structure will include some or all of the following key features: + +- **Identifier (`id`):** A unique identifier for the specific regulation or component instance, often assigned by the customer. +- **Name:** A human-readable name or description of the regulation (e.g., "Special Event Surcharge," "Annual Leave Entitlement"). +- **Type Code (if applicable):** A code that categorizes the regulation, often from a standard list (e.g., an allowance type code from a SETU codelist). +- **Effective Period (`effectivePeriod`):** This defines the overall validity period of the regulation itself (i.e., when this rule is in force). It uses `validFrom` and `validTo` dates. This is distinct from when an employee might earn or receive the benefit. +- **Applicability Periods (`period`):** This element (often an array) defines when the regulation is actively applicable to an employee and thus when the benefit is 'earned' or accrued. It can specify: + * **Date Period (`datePeriod`):** A specific date or a range of dates (e.g., "2025-07-26" to "2025-08-11"). + * **Time Period (`timePeriod`):** A specific recurring time or range of times during the applicable dates/days (e.g., "18:00:00" to "23:00:00"). + * **Weekday (`weekday`):** Recurring days of the week (e.g., "Saturday", "Sunday"). +- **Regulation Rates/Details (`line`):** This element (often an array) details the specific rates, amounts, or entitlements for the regulation. Multiple lines can exist to define different rates under varying conditions. A typical `line` includes: + * **Amount (`amount`):** Describes the value of the benefit. + * **Value (`value`):** The numeric or descriptive value (e.g., "25", "100"). + * **Unit Code (`unitCode`):** The unit of the value (e.g., "percentage", "euro", "hour", "day"). + * **Base Amount (`baseAmount`):** If the `value` is a percentage or derived, this specifies the base for the calculation (e.g., "percentageHourlyRate", "fixed"). + * **Interval Code (`intervalCode`):** Defines the interval over which the `amount` is applied or earned (e.g., "1" "hour" means per hour; "0.5" "year" means per half year). + * **Conditions (`conditions`):** Specifies any conditions that must be met for this particular line/rate to apply (see the "Conditions" documentation page for more details). +- **References (`reference`):** Allows linking this regulation to others, for instance, to define calculation dependencies (e.g., an allowance being compounded on another). +- **Other specific fields:** Depending on the component (e.g., `waitingDays` for `sickPay`, `payDate` for `holidayAllowance`). + +### Period Structure Example + +The following JSON snippet, taken from an `allowance` component, illustrates how the `period` element defines when a "Special Event Surcharge" is applicable. This surcharge is for a major sporting event. + +```json { - "ID": { - "Value": "12345", - "Scheme Agency ID": "Customer" - }, - "Name": "irregular hour compensation summer", - "Effective Time Period": { - "Valid From": "2025-07-01T00:00:00", - "Valid To": "2025-12-31T23:59:59" - }, - "Type Code": "HT704", - "Period": { - "Weekday": ["Monday", "Tuesday", "Wednesday"], - "Time Period": { - "Start": "18:00", - "End": "23:00" - } - }, + "allowance": [ + { + "id": { // Unique ID for this specific allowance regulation. + "value": "2b497da74f7", + "schemeAgencyId": "Customer" + }, + "name": "Special Event Surcharge (e.g. Major Sporting Event)", // Descriptive name of the allowance. + "effectivePeriod": { // Validity period for this allowance rule. + "validFrom": "2025-01-01", + "validTo": "2025-12-31" + }, + "typeCode": { // Code identifying the type of allowance (from SETU codelist). + "value": "HT320" // Example: Code for shift/irregular hours allowance. + }, + "period": [ // Defines when this allowance is applicable ('earned'). + { + "datePeriod": [ // Specific date or range of dates. + { + "start": "2025-07-26", + "end": "2025-08-11" // Example: Applicable during the Olympics. + } + ], + "timePeriod": { // Specific time or range of times during the applicable dates/days. + "start": "00:00:00", // Start time (HH:MM:SS). + "end": "23:59:59" // End time (HH:MM:SS). + }, + "weekday": [ // Recurring days of the week. + "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" // Applicable all days within the datePeriod/timePeriod. + ] + } + ], + // ... line details for the allowance rate ... + } + ] } ``` +This structure indicates the surcharge is active for the duration of the special event (July 26 to August 11, 2025), applies 24 hours a day, on all days of the week within that date range. +### Rates (Lines) Structure Example +The `line` array within a component defines the actual benefit(s). The following example for "Overtime Compensation" shows two different ways overtime can be compensated, each defined as a separate object in the `line` array. +```json +{ + "allowance": [ + { + "id": { + "value": "2dsajofoiasd", + "schemeAgencyId": "Customer" + }, + "name": "Overtime Compensation (Money and Time)", + // ... effectivePeriod, typeCode, period ... + "line": [ // Multiple lines can represent different compensation methods. + { + // Line 1: Monetary compensation (e.g., 150% of hourly rate). + "amount": { + "value": "150", // The numeric value (150%). + "unitCode": "percentage", // Unit is percentage. + "baseAmount": { + "unitCode": "percentageHourlyRate" // Base for the percentage is the hourly rate. + } + }, + "intervalCode": { + "value": "1", // For every 1 unit. + "unitCode": "hour" // Unit is hour (i.e., per hour of overtime worked). + }, + "conditions": [ // Conditions for choosing this rate. + { + "conditionType": "textualCondition" + // A 'description' field within this condition might state: + // 'Default overtime compensation in money, unless employee opts for time-off.' + } + ] + }, + { + // Line 2: Time-for-time compensation (e.g., 1 hour off for 1 hour overtime). + "amount": { + "value": "1", // 1 hour of leave. + "unitCode": "hour", // Unit is 'hour' representing leave time. + "baseAmount": { + "unitCode": "fixed" // It's a fixed amount of time, not percentage based. + } + }, + "intervalCode": { + "value": "1", // For every 1 unit. + "unitCode": "hour" // Unit is hour (i.e., per hour of overtime worked). + }, + "conditions": [ // Conditions for choosing this rate. + { + "conditionType": "textualCondition" + // A 'description' field might state: + // 'Overtime compensation as time-off, if chosen by employee and operationally feasible.' + } + ] + } + ] + } + ] +} +``` +This example clearly shows how different rates or forms of compensation for the same underlying regulation (overtime) can be specified, each with its own calculation logic and potential conditions. -### Rates (lines) structure -Within the building block, multiple different rates can be defined. This JSON example describes two different irregular working hour compensations for employees: +## Examples of Pay Equity Components -- **Administrative employees:** All administrative employees receive a 20% increase on their hourly rate for the hours worked at irregular times. +Below are brief examples of how different pay equity components are structured using this common building block approach. -- **All employees above pay scale '10':** All employees that are in pay scale 10 or higher receive a 10% increase on their hourly rate. +### Allowances +Allowances are additional payments made to employees for specific reasons, such as working irregular hours, special events, or specific job conditions. -``` -"Line": [ - { - "Line": { - "Amount": { - "Value": 20, // 20 % - "Unit Code": "percentage" - }, - "Base": { - "Code": "hourlyRate" // percentage of hourly rate - }, - "Interval Code": { - "Value": 1, // every full hour, so a value of 1. (a value of 0.5 would mean every half hour) - "Unit Code": "hour" // per irregular hour worked. - } - }, - "Conditions": { - "conditionType": "functions" - "Description": "This rate is only applicable to administrative employees.", - "Position Title": "Administrative employee" - } - }, - { - "Line": { - "Amount": { - "Value": 10, - "Unit Code": "percentage" - }, - "Base": { - "Code": "percentagehourlyRate" - }, - "Interval Code": { - "Unit Code": "hour", // per irregular hour worked. - "Value": 1 // every full hour, so a value of 1. (a value of 0.5 would mean every half hour) - } - }, - "Conditions": { - "conditionType": "general" - "Description": "This rate is applicable to every employee that is in or above pay scale 10.." - } - } -] +```json +{ + "allowance": [ + { + "id": { // Unique ID for this allowance. + "value": "jdhebridka23", + "schemeAgencyId": "Customer" + }, + "name": "Basic Weekend Surcharge", // Name of the allowance. + "effectivePeriod": { // When this rule is valid. + "validFrom": "2025-01-01", + "validTo": "2025-12-31" + }, + "typeCode": { // Type of allowance. + "value": "HT320" // Example: Shift/irregular hours code. + }, + "period": [ // When this surcharge is earned. + { + "timePeriod": { // Applicable full day. + "start": "00:00:00", + "end": "23:59:59" + }, + "weekday": [ // Applicable only on weekends. + "Saturday", + "Sunday" + ] + } + ], + "line": [ // The rate for the surcharge. + { + "amount": { + "value": "5", // Fixed amount. + "unitCode": "euro", + "baseAmount": { + "unitCode": "fixed" // Indicates it's a fixed Euro amount. + } + }, + "intervalCode": { + "value": "1", + "unitCode": "hour" // 5 Euro per hour worked during the weekend. + } + } + ] + } + ] +} ``` +### Reimbursements +Reimbursements cover expenses incurred by employees, such as travel costs. The `allowance` component is used for this, with specific `typeCode` values. -## Voorbeelden - -### Toeslagen - -To be filled +```json +{ + "allowance": [ + { + "id": { + "value": "5oidsan23d", + "schemeAgencyId": "Customer" + }, + "name": "Travel Allowance with Distance Brackets", + "effectivePeriod": { + "validFrom": "2025-01-01", + "validTo": "2025-12-31" + }, + "typeCode": { + "value": "EA103" // Example: Code for travel costs home-work. + }, + "period": [ /* ... applicable workdays ... */ ], + "line": [ // Multiple lines for different distance brackets. + { + "amount": { "value": "25.00", "unitCode": "euro", /* ... */ }, + "intervalCode": { "value": "1", "unitCode": "day" }, + "conditions": [ { "conditionType": "textualCondition" /* 'description': 'For travel > 50 km' */ } ] + }, + { + "amount": { "value": "0.23", "unitCode": "euro", /* ... */ }, + "intervalCode": { "value": "1", "unitCode": "kilometer" }, + "conditions": [ { "conditionType": "textualCondition" /* 'description': 'For travel < 20 km or bicycle' */ } ] + } + // ... other brackets ... + ] + } + ] +} +``` -### Vergoedingingem +### Sick Pay +Sick pay regulations define how employees are compensated during periods of illness. -To be filled +```json +{ + "sickPay": [ + { + "id": { + "value": "9c36cb78897", + "schemeAgencyId": "Customer" + }, + "name": "Continued sick pay.", + "effectivePeriod": { + "validFrom": "2025-01-01", + "validTo": "2026-01-01" + }, + "period": [ /* ... when sick pay rules apply ... */ ], + "line": [ + { + "amount": { + "value": "100", // 100% of pay. + "unitCode": "percentage", + "baseAmount": { + "unitCode": "percentageMonthlyRate", // Based on monthly rate. + "value": "3201" // Optional: Example monthly rate. + } + }, + "intervalCode": { "value": "1", "unitCode": "month" }, + "conditions": [ { "conditionType": "textualCondition" /* 'description': 'Applies during first 52 weeks of sickness' */ } ], + "waitingDays": { // Defines unpaid waiting days. + "value": 5, + "conditions": [ { "conditionType": "textualCondition" /* 'description': 'Waiting days apply if...' */ } ] + } + } + // Additional lines for different rates (e.g., 70% for second year). + ] + } + ] +} +``` -### Doorbetaling bij ziekte +### Leave +Leave regulations cover various types of time off, such as annual vacation, public holidays, and special leave. -To be filled +```json +{ + "leave": [ + { + "id": { + "value": "37605f8e84f", + "schemeAgencyId": "Customer" + }, + "name": "Leave ruling that is valid for all employees.", + "effectivePeriod": { + "validFrom": "2023-01-01", + "validTo": "2028-01-01" + }, + "period": [ /* ... when leave can be accrued/taken ... */ ], + "holidays": [ // Recognized public holidays. + { + "amount": { "value": 7 }, // Number of recognized holidays. + "name": [ "Christmas Day", "Easter", "etc." ], + "conditions": [ { "conditionType": "textualCondition" /* 'description': 'If holiday falls on a workday' */ } ] + } + ], + "paidLeave": [ // General paid leave (vacation days). + { + "amount": { "value": 25 }, // E.g., 25 days. + "intervalCode": { "value": "1", "unitCode": "year" }, // 25 days per year. + "conditions": [ { "conditionType": "ageCondition" /* Example: accrual rate varies by age */ } ] + } + ], + "adv": [ /* ... Arbeidsduurverkorting (reduction in working hours) details ... */ ], + "leaveDayValue": { "value": "133.00 euros" }, // Financial value of one leave day. + "specialLeave": { "description": "Extra leave of 1 day per overtime shift worked." }, + "WAZO": { "description": "Three extra days of parental leave." }, // Employer supplement to statutory leave. + "MandatoryLeaveAllocation": { "description": "Leave days must be spent within 3 years." } + } + ] +} +``` -### Verlof +These examples demonstrate the Pay Equity Structure in capturing a wide range of employment conditions in a standardized manner. Each main component (`allowance`, `sickPay`, `leave`, etc.) shares these core structural elements. Understanding these elements is key to understanding the Pay Equity Inquiry data model as a whole.