Employment Hero Australia
Australian TFN, superannuation and ABN on the employee, encrypted at rest and synced from the Employment Hero people platform.
Store price is USD 175 all-in: installing this also pulls the 4 paid ERP Heritage modules it depends on.
Why this module
Employment Hero Australia
The TFN is never stored in clear
The Tax File Number and the super member number are encrypted with Fernet, so the database holds only ciphertext. The TFN shows masked on every read; the real value returns only through an HR-only Reveal action that writes an audit row. A database dump never exposes the number.
The upstream number is never overwritten
The TFN and super member number are mapped pull only, because the people platform owns them and the Odoo field renders a mask. The push path provably omits the mask and the key-unavailable placeholder, so a two-way employee job can never write a fake value back over the real one.
AU fields join the sync as data
The country profile, endpoint, mapping lines and pull job ship as data rows you can read and tune in the UI. Adding or repointing an Australian field is a configuration change on the shared engine, not a code deployment, and it inherits the engine's idempotent upsert and audited runs.
Day in the life
An HR officer onboards a new Australian hire.
Payroll detail is created in the Employment Hero people platform, then the superannuation pull job runs. The employee's fund name, type, USI, fund ABN, contribution rate and member number land on a superannuation record matched back to the right employee through the external id cross reference, with the member number encrypted as it is written. On the employee form the officer sees the TFN masked behind asterisks and the ABN in clear. When a super clearing query later needs the actual TFN, they click Reveal: the number is decrypted just for that view and a line is written to the PII access log naming the user and the time. Nothing about that number ever reached the browser unaudited, and re-running the job tomorrow updates the same records in place rather than creating duplicates.
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.
The TFN and super member numbers are stored as Fernet ciphertext. The TFN field masks on every attribute read and ORM read, and a plain read writes no audit. Only the deliberate Reveal returns the clear value, and the audit row it writes contains no TFN. Verified by tests on this branch.
On a two-way employee job the mapper drops the TFN mask and the key-unavailable placeholder entirely, and never sends the pull-only identifiers, so the real upstream value is never clobbered by a masked local field. Both the mask and the decrypt-failure branches are covered by tests.
Every record is keyed by its Employment Hero external id through a cross reference. Re-running the superannuation job finds the existing row and updates in place; an unchanged payload hashes the same and is skipped, so a repeated or retried pull never duplicates a fund record.
Each record is processed in its own savepoint. One bad superannuation row, for example a fund pointing at an unknown employee, is logged as an error line and rolled back alone while the rest of the batch commits, and the run ends in a partial state instead of aborting.
A super membership resolves to its employee through the external id transformer, so a fund record attaches to the correct person even though the payload carries only the upstream employee id, and a required-field guard fails the row cleanly if that link cannot be made.
The shared API client retries 5xx, timeouts and 429 with exponential backoff and jitter, honours a clamped Retry-After header, and meters calls through a database-backed token bucket so multiple workers share one budget instead of triggering a 429 storm.
List pulls page through the platform response (OData, page-number or cursor style) until a short page ends them, with a safety cap that warns loudly rather than silently truncating, so a large employee or fund set is read completely.
Installs that predate the encryption hardening carried plaintext TFN and member-number columns. The shipped migration reads each orphaned column, encrypts the value into the ciphertext column and drops the plaintext, and is idempotent so a second run is safe.
Superannuation records and external id cross references carry a company, and the cross reference is scoped per connection, so each company's Australian data and its link back to the platform stay isolated.
What is inside
Built to do the job, end to end.
- Employee identifier fields. Adds Tax File Number, superannuation fund name and member number, and ABN to hr.employee, shown in an Employment Hero (Australia) group on the HR Settings page of the employee form.
- Encryption and audited reveal. The TFN and super member number are encrypted at rest with Fernet. The TFN masks on read and is decrypted only by an HR-only Reveal action that logs the access; the super member number decrypts for HR users.
- Superannuation fund model. A dedicated eh.hr.super.fund record holds fund name, fund type, USI, fund ABN, encrypted member number and contribution rate, with more than one fund allowed per employee, plus a list, form and menu.
- Australian country profile. Registers the AU country profile against the shared country base so the connector applies the right local handling to Australian employees.
- Data-driven mapping and pull job. Ships mapping lines that extend the employee mapping with the AU fields, a superannuation endpoint, and a pull sync job for superannuation detail, all editable in the UI. Source paths are tunable to your payload shape.
- Engine behaviour it inherits. Runs on the suite sync engine: idempotent external-id upsert, payload-hash skip of unchanged records, per-record savepoint isolation, explicit conflict policies, and an API client with retry, backoff and shared rate limiting.
- Upgrade migration. A post-migration step encrypts any legacy plaintext TFN and member-number columns into their ciphertext columns and drops the plaintext, idempotently, so an older install is hardened on upgrade.
- Community and tested. Works on stock Odoo Community HR with no Enterprise dependency, and ships an automated test suite covering the profile, the fields, encryption at rest, the push guard and the migration.
Honest about the edges
What this does not do, so nothing surprises you.
- The TFN and superannuation member number are pull only. The platform is the system of record for them, so this pack reads them into Odoo and does not push them back.
- No format or check-digit validation is performed on the TFN, ABN or USI. The fields store and sync the values as received; they are not checked against the ATO algorithm.
- This is a localisation layer, not the connector itself. It requires eh_hero_country_base and eh_hero_hr, which bring the connection, transport and sync engine.
- Real-time webhook delivery and the asynchronous job queue are separate modules in the suite. This pack pulls on demand or on a schedule; install the webhook and queue modules for event-driven or background processing.
- The shipped superannuation endpoint is per employee, so a deployment drives that job per employee or supplies the employee id as a path parameter.
- Mapping source paths ship as sensible defaults but are tunable, because where tax and super detail sit in your payload depends on your Employment Hero organisation setup.
- Encryption at rest relies on the cryptography package and a key supplied by environment variable or system parameter. Without a stable key, encrypted values cannot be decrypted later.
- This module does not calculate or lodge payroll, superannuation guarantee or Single Touch Payroll. It synchronises the identifiers, not the statutory filings.
Employment Hero Odoo, Odoo 16 Australia payroll integration, Tax File Number Odoo, superannuation Odoo, ABN employee field Odoo, KeyPay Odoo connector, TFN encryption at rest, Odoo HR Australia localisation, superannuation USI member number, Employment Hero connector country pack, Odoo Community payroll sync, PII access log audit Odoo, idempotent sync Odoo, hr.employee Australian fields
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.
Employment Hero Connector is the integration core of the ERP Heritage Employment Hero suite, providing per compan...
Sync certifications, qualifications and employee document metadata from the Employment Hero people platform into...
Sync Employment Hero leave categories, leave requests and leave balances into the standard Odoo Time Off app, wit...
Show the Hijri (Umm al-Qura) date alongside Gregorian dates across Odoo 16
Connect Odoo partner records to the Saudi SPL National Address service and the Wathq commercial registry
One click install of the full Employment Hero integration for Odoo Community, covering the connector, two way syn...
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Discuss (mail)
• Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 4353 |
| Technical Name |
eh_hero_country_au |
| 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