Employment Hero Work Entries
Pull Employment Hero work and roster data into Odoo Work Entries, mapped from the screen, no code.
Store price is USD 206 all-in: installing this also pulls the 3 paid ERP Heritage modules it depends on.
Why this module
Employment Hero Work Entries
Mapping is data, not a fork
Endpoints, field mappings and sync jobs ship as records you edit from the screen. The starter mappings load with no update protection, so adjust a source path to match your organisation's payload and an upgrade leaves your change in place. No Python, no patched module.
Re run all you like
Each record is keyed to its Employment Hero id through a cross reference, and the last payload is hashed. Re running a job finds the existing row and updates in place, and a record that has not changed is skipped. There is no way to double up a work entry.
Types first, then entries
The work entry type job runs ahead of the work entry job, so each entry resolves its type, and its employee, through the same external id cross reference. Relations land correctly on the first pass instead of dangling until a second run.
Day in the life
A nightly roster pull, start to finish
The scheduled run opens the company's HR connection, refreshing the OAuth token if it has aged out. It pulls work entry types first, page by page, creating or updating each one and registering its Employment Hero id. Then it pulls work entries: for each one it resolves the employee and the work entry type by their Employment Hero ids, applies the date and duration transforms, and writes the entry. A row that came through last night unchanged is skipped on its hash. One entry whose employee was never synced fails on its own, gets logged as an error line, and the run finishes in the partial state with everything else written. If the API returns a rate limit response mid pull, the engine backs off and retries rather than giving up. Next run, the delta filter asks only for what changed since this one.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
A re run, or the same record seen twice, resolves to the existing cross reference row and updates in place. The unique constraint on model, connection and external id makes a duplicate link impossible.
The mapped values plus a fingerprint of the mapping are hashed. A record whose hash matches the last sync is skipped, so a nightly pull does not rewrite rows that did not move. Editing the mapping changes the fingerprint and forces a rewrite next run.
Each record is processed inside its own savepoint. A failed write rolls back just that record, is recorded as an error line, and the run ends in the partial state instead of aborting the whole batch.
Transient failures, timeouts and rate limit responses are retried with exponential backoff and jitter. A server Retry-After header is honoured and clamped, so a hostile or buggy value cannot park a worker for hours. Non retryable errors raise at once.
When a job runs in delta mode the cursor advances only to the latest record that processed cleanly, and never past a record that failed, so a failed or late changing entry is re fetched next run rather than skipped forever.
Pages are followed until a short or empty page ends the set. A safety cap guards against an endless loop, and hitting it is logged loudly as truncation rather than silently dropping records.
An entry pointing at an employee or type that has no Employment Hero id yet does not poison the batch. It fails its own record and is logged, and once the missing relation is synced it resolves on the next run.
Connections are scoped per company and per product, and the cross reference inherits the connection's company, so two companies with their own Employment Hero organisations never cross bind to each other's records.
What is inside
Built to do the job, end to end.
- Two endpoints, ready to call. Work entry types and work entries, both on the HR platform paths, paginated with the page index and item per page style the platform uses, reading items from the data envelope. Page size and rate group are set, and you can point them elsewhere from the screen.
- Two mappings, pull direction. One for hr.work.entry.type and one for hr.work.entry. Lines cover name, code, date, duration and the employee and type relations. The employee and type resolve by Employment Hero id through the external id transformer, dates and durations through the date and number transforms.
- Two sequenced sync jobs. A work entry type pull at an earlier sequence than the work entry pull, each binding an endpoint, a mapping and a target model. The work entry job declares its source timestamp path, so it can run as a delta once a first full pull has seeded the cross reference.
- Editable, upgrade safe data. Mappings and jobs load with no update protection, so a deployment tunes them to its own payload shape and a module upgrade does not overwrite the edits. Endpoints load updatable, so the catalogue can move with the module.
- Dry run preview. Run a job in dry run and nothing is written, but the run still reports the creates, updates and skips it would have made. Useful for checking a mapping change against live data before letting it touch the database.
Honest about the edges
What this does not do, so nothing surprises you.
- One way only. This module pulls Employment Hero work data into Odoo. It does not push Odoo work entries back to Employment Hero. The mappings are pull direction and no create or update endpoints are shipped.
- Scheduled pull, not real time. Out of the box the jobs run on a schedule or on demand. They do not subscribe to webhooks, so a change in Employment Hero appears at the next run, not the instant it happens.
- Configuration, not engine. This is data on top of the Employment Hero sync engine and HR base modules it depends on. The pagination, retry, idempotency and cross reference logic live in those modules, which install automatically as dependencies.
- Posting work entries is deployment specific. Creating a live, validatable hr.work.entry needs the employee to have a running contract or employment version in your Odoo. This module maps and writes the data; your own HR configuration governs whether an entry can be validated.
- Source paths assume a payload shape. The starter mapping source paths reflect a typical organisation payload. If your Employment Hero organisation returns differently named fields, adjust the mapping lines from the screen before the first run.
- First run must seed relations. Work entry types and employees need their Employment Hero ids registered before entries can resolve them, which is why the type job runs first and why employees should already be synced.
employment hero work entries odoo, employment hero odoo integration, odoo 18 work entry sync, roster import odoo, employment hero hr sync, work entry type mapping odoo, external id cross reference sync, delta sync odoo 18, idempotent hr data import, odoo community payroll integration, employment hero api odoo connector, scheduled hr work entry pull
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
The New Zealand country pack for the ERP Heritage Employment Hero integration
The complete ERP Heritage Employment Hero integration in one install
Sync timesheet entries from the Employment Hero people and payroll platform into the standard Odoo Timesheets app...
Real-time MRA fiscalisation for Point of Sale receipts in Odoo 18 Community, mapping each paid POS order to the M...
Shared foundation for the ERP Heritage Employment Hero country packs
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 4140 |
| Technical Name |
eh_hero_ent_payroll |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module