Payroll integration
Oracle HCM to Zenegy integration: Danish employees, address changes and leavers from Oracle HCM Cloud in Zenegy Payroll
An integration between Oracle HCM Cloud and Zenegy creates a hire at the Danish legal employer in Oracle as an employee in Zenegy Payroll, with CPR number, address and seniority date, and then passes on personal changes, leavers and approved leave. Danish payroll settings such as ATP type and pension stay in Zenegy, through the global value sets payroll manages there.
What the integration does
Organisations that use Oracle HCM Cloud as their central HR system and run Danish payroll in Zenegy enter a Danish starter in both systems. When an employee moves house or leaves, payroll often only hears about it once the payslip is ready.
- HR completes a hire at the Danish legal employer in Oracle.
- KoppelHet reads the newhire feed, fetches CPR, address and dates and picks the global value set that fits the job.
- KoppelHet creates the employee in Zenegy with the Oracle PersonNumber as employee number.
- Address and name changes go as JSON Patch; a leaver becomes a resignation with last working day.
- After the payroll run KoppelHet checks whether the resignation was processed, and reports differences to payroll.
What to watch for with Oracle HCM Cloud and Zenegy
- Zenegy asks for both an employment date and a seniority date on creation. Besides the start date of the work relationship, Oracle also keeps seniority dates. KoppelHet uses the latter when filled, so a Danish employee who moves within the group keeps their built-up seniority.
- Oracle sends a cancelworkrelship event when a hire is reversed. Zenegy only allows deletion as long as the employee has not been in any payroll run. KoppelHet therefore only deletes the profile before the first Danish run; after that it becomes a notice to payroll.
- Oracle's empupdate feed reports new addresses, name corrections and changed national identifiers among other things. Zenegy only wants the properties that actually change in a PATCH; sending other fields causes errors in the employee data. KoppelHet only puts the changed fields in the patch for each event.
- Fields that run through a global value set in Zenegy do not change with a PATCH, and Zenegy returns no error either. If a job change from the empassignment feed leads to a different set, KoppelHet writes nothing to those fields but reports the change to payroll.
- A leaver from the termination feed becomes a resignation with last working day in Zenegy. That resignation is only processed after a payroll run covering that day, after which isProcessed is true. KoppelHet does not start a run itself and checks after the next run whether the flag is set.
- The newhire feed also reports a rehire. Zenegy has an endpoint for that to reactivate a deactivated profile, with a new global value set. KoppelHet uses it instead of creating a second profile with the same CPR.
- Zenegy only counts absence when its status is Approved, and only one registration fits on a single day. KoppelHet therefore writes approved leave from Oracle as Approved; if something already falls on that day, the request goes on the difference list.
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 salary amounts from Oracle also go to Zenegy?
Not in the first version. Salary settings in Zenegy partly run through global value sets, which payroll manages. A salary flow can be added later as an extension, after a test in the customer's environment.
Who grants permission for the API?
A user with access to the Zenegy company signs in through OAuth and approves the integration. Which role is needed is agreed with payroll.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Oracle HCM Cloud through the employee Atom feeds (newhire, empupdate, empassignment, termination, cancelworkrelship) on /hcmRestApi/atomservlet/employee/, then the REST resource workers for nationalIdentifiers, addresses and workRelationships, filtered on the Danish legal employer.
- Zenegy Payroll-DK with OAuth 2.0 authorization code flow (token from /auth/token, refresh token for long-term access). Create employee, change with JSON Patch, register and check resignation through employee resignations, reactivate with globalValueSetUid, and create absence with status Approved.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Oracle HCM Cloud | Field in Zenegy | Notes |
|---|---|---|
PersonNumber | employeeNumber | Otherwise Zenegy builds a number from the CPR |
nationalIdentifiers (DNK) | CPR-nummer | Required |
names (FirstName, LastName) | naam | |
addresses (thuisadres) | adres, postcode, plaats | Required |
Start date van de work relationship | in-diensttredingsdatum | |
Termination date | lastWorkDay en dateOfResignation | |
Absence type | absence type-ID | Lookup table to the Zenegy types |
Related
Ashby → Oracle HCM Cloud
Ashby to Oracle HCM integration: an accepted offer on an opening becomes a pending worker
Bullhorn → Oracle HCM Cloud
Bullhorn to Oracle HCM integration: an approved placement of an employee becomes a pending worker
Carerix → Oracle HCM Cloud
Carerix to Oracle HCM integration: successful placement as a pending worker in Oracle HCM Cloud
Greenhouse → Oracle HCM Cloud
Greenhouse to Oracle HCM integration: accepted offer as a pending worker in Oracle HCM Cloud