
Leave, absence and time
Planday to AFAS integration: approved shifts as payroll entries, employees and contract hours back
With an integration between Planday and AFAS Profit, the approved shifts and supplements from Planday go to AFAS after every payroll period as payroll entries per pay component. New employees, contract hours and terminations from AFAS come back into Planday, so scheduling works with what HR recorded.
What the integration does
Anyone scheduling in Planday and running HR and payroll in AFAS Profit often moves hours by hand. Hours go to payroll as an export at the end of the month, where they are retyped per pay component, and an hourly wage in Planday sometimes differs from AFAS.
- HR records a new employee in AFAS with employment, job and scheduled hours.
- KoppelHet places the employee in Planday, in the right department and employee group, with the matching contract rule.
- Managers approve the shifts in Planday. After the payroll period KoppelHet fetches approved shifts only.
- Hours and supplements appear per pay component as payroll entries on the right employment in AFAS, ready for the payroll run.
- On termination KoppelHet deactivates the employee in Planday as of the end date, and shifts after it become open again.
Back: New employees with department and employee group · Contract rule matching the scheduled hours · Deactivation on the end date
What to watch for with Planday and AFAS Profit
- Planday already calculates an amount per shift, using the employee group's hourly rate and supplements as an amount or percentage. AFAS calculates pay itself, with the collective agreement and its own rates. KoppelHet sends only the hours per pay component and leaves out the Planday amounts, so AFAS stays leading for pay.
- Planday returns payroll data for a free start and end date, while AFAS works in payroll periods, monthly or four-weekly. KoppelHet requests exactly the days of the AFAS period from Planday, approved shifts only, so a shift never ends up in two periods.
- In Planday the salary identifier can differ per department. If someone has two employments in AFAS, for example in two different departments, each department gets the number of its own employment. The hours therefore land on the right contract in AFAS.
- AFAS gives no warning when the same payroll entry arrives twice through an integration. Planday gives every shift its own number. KoppelHet records per shift number what is already in AFAS, and for a corrected shift changes the existing line instead of booking a second one.
- Contract hours are not stored as a number on the employee in Planday, but as a contract rule the administrator creates in advance. KoppelHet matches the scheduled hours from AFAS to an existing contract rule, and reports it when no rule exists yet for a number of hours.
- A username in Planday must be an email address. Not every hospitality worker has a work address in AFAS. KoppelHet uses the address HR designates for this in AFAS, and reports an employee without an address instead of creating them with an invented one.
- On termination Planday can deactivate someone as of a date and release the shifts after that date. KoppelHet does this on the end date from AFAS, so the location manager sees open shifts instead of shifts assigned to someone who has already left.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Do leave balances from AFAS also go to Planday?
That can be added later as an extension. Planday has vacation accounts on which an integration can post adjustments, and AFAS can supply the balance per leave type. We start with hours and employees.
What if a Planday salary code has no pay component in AFAS?
Then the line is not booked and an alert appears in the platform. Payroll assigns a pay component or confirms that the code is not paid out.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Planday is read through the Payroll API (GET /payroll/v1.0/payroll with departmentIds, from, to and shiftStatus=Approved). The response contains shiftsPayroll (per shift id, employeeId, departmentId, salaryCode, breaks with isPaid and supplements with salaryCode and duration), supplementsPayroll and salariedPayroll. Salary identifiers through GET /pay/v1.0/salaryIdentifiers/employees, also per department. OAuth 2.0; per portal 20 requests per second and 750 per minute.
- Payroll entries go to AFAS through the HrCompMut UpdateConnector; corrections and deletions through HrCompMutGUID with the GUID KoppelHet stores per Planday shift. Extra parameters (VaD1 to VaD3) only when set up on the pay component. Employees and scheduled hours are read from AFAS with a dedicated GetConnector on change date.
- Planday is written through the HR API (POST and PUT /hr/v1.0/employees with userName, departments, employeeGroups, salaryIdentifier and contractRulesRuleId; PUT /hr/v1.0/employees/deactivate/{employeeId} with date and keepShifts) and the Contract Rules API.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Planday | Field in AFAS Profit | Notes |
|---|---|---|
salaryIdentifier | Medewerker (EmId) en dienstverband | Can be set per department, so two employments stay separate |
salaryCode van dienst of toeslag | Looncomponent in HrCompMut | Through a translation table approved by payroll |
Duur van de dienst minus onbetaalde pauze | Waarde (uren) van de loonmutatie | |
supplements.duration | Waarde van de toeslagcomponent | |
date van de dienst | Periode van de loonmutatie | |
AFAS roepnaam, achternaam, e-mail (terug) | firstName, lastName, userName en email | |
AFAS organisatorische eenheid (terug) | departments | Through a translation table |
AFAS functie (terug) | employeeGroups | |
AFAS roosteruren per week (terug) | contractRulesRuleId | An existing contract rule in Planday |
AFAS einddatum dienstverband (terug) | deactivate met date |
Related
ADP iHCM → Planday
ADP iHCM to Planday integration: employees, department and contract hours from ADP in Planday
BambooHR → Planday
BambooHR to Planday integration: employees, time off and balances in scheduling, and open shifts after a departure
Dayforce → Planday
Dayforce to Planday integration: employees, work assignments and approved time off from Dayforce in Planday
Deel → Planday
Deel to Planday integration: own employees with work hours in Planday, approved time off and balance included