Installing BaseUp HR on Odoo 20

One module, one Odoo application: baseup_human_resources. There are no companion modules to install and no ordering to get right.

Because the module is flagged as an application it shows up under the default Apps filter, so you do not have to clear the filter to find it.

Odoo 20.0 Enterprise. Seven of the twenty-five dependencies are Enterprise-only modules, so the install fails outright on Community — there is no reduced mode.

Odoo module dependencies

All are declared in the manifest and resolved by Odoo automatically — you do not install them by hand. The split matters only for deciding whether your license can run this module at all.

Python packages

pip install geopy PyMuPDF
# optional: OCR for scanned SSS circular PDFs in Import Circular
pip install rapidocr-onnxruntime

Do not add pypdf by hand. Odoo 20 pins the PDF library per Python version — PyPDF2 2.12.1 below Python 3.13, pypdf 5.4.0 from 3.13 — and the BIR report tries pypdf first, then PyPDF2, to follow whichever Odoo installed.

Server

• Python and PostgreSQL — what Odoo 20 requires: Python 3.12 to 3.14 and PostgreSQL 16 or later. This module adds no constraint of its own.
• Outbound HTTPS — needed for the license API, the public holiday calendar sync, the contribution-table watch, address geocoding, and cdn.jsdelivr.net, which serves Chart.js for the HR dashboard. See §6.
• Timezone — schedules and every payroll computation localise to Asia/Manila by default.

The module is distributed through the Odoo App Store. Buy it, download the archive, and unpack it somewhere outside the addons path before you go near odoo.conf.

1. Buy the module and download the archive from your Odoo account's purchases.
2. Unzip it somewhere outside the addons path first, and look at what came out. You should find a single directory, baseup_human_resources. The store metadata sets a limit of one installation per purchase, so check the entitlement before deploying to several databases.
3. Note the version in baseup_human_resources/__manifest__.py and check it matches what you expect (20.0.1.0.0 at the time of writing).

The single most common install failure. What goes in addons_path is the directory that contains baseup_human_resources — never the module directory itself, and never a level higher.

Correct layout

/opt/odoo/custom-addons/          # <- this path goes in odoo.conf
└── baseup_human_resources/
    ├── __manifest__.py          # Odoo looks for this one level down
    ├── models/  views/  data/
    ├── security/  reports/  wizard/
    ├── controllers/  static/
    └── migrations/

Move baseup_human_resources out of the unpacked archive and into your custom addons directory, or symlink it there. The one thing that must be true is that Odoo sees a directory containing __manifest__.py exactly one level below a path entry.

[options]
addons_path = /opt/odoo/odoo/addons,/opt/odoo/enterprise,/opt/odoo/custom-addons
db_host = localhost
db_user = odoo
db_password = <set this>
admin_passwd = <set this>
data_dir = /var/lib/odoo
; the dashboard, kiosk and biometric screens are asset-heavy
limit_time_cpu = 600
limit_time_real = 1200
; several payroll reports build large PDFs
limit_memory_hard = 4294967296

chown -R odoo:odoo /opt/odoo/custom-addons
find /opt/odoo/custom-addons -type d -exec chmod 755 {} \;
find /opt/odoo/custom-addons -type f -exec chmod 644 {} \;

From the command line — preferred for a first install

You get the full traceback on stderr instead of a browser error, which matters for a module that loads this many data files.

sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/odoo-bin \
  -c /etc/odoo/odoo.conf \
  -d <database> \
  -i baseup_human_resources \
  --stop-after-init

From the interface

1. Restart the Odoo service so the new addons path is picked up.
2. Enable developer mode, then go to Apps and click Update Apps List. Without this the module will not appear at all.
3. Search BaseUp and install BaseUp Human Resources. It is flagged as an application, so the default Apps filter will not hide it.

Four things to set before handing the database over. The functional setup — periods, schedules, approvers — is covered in the Operator Guide; this is the deployment layer.

License parameters

The module ships four system parameters that point at the license service. They are loaded noupdate="1", so they are written once at install and are not refreshed by later upgrades — whatever is in the database stays there until you change it.

license.sync_api_url        # license service endpoint
license.sync_api_email     # account used to authenticate
license.sync_api_password  # credential for that account
license.api_key            # shared key guarding /api/v1/license/*

Outbound network access

Mail and branding

• SMTP From — set this, or outgoing payslips and notices go out with the wrong sender.
• System name — the app_system_name parameter replaces the product name in page titles and browser tabs.
• Backend theme — a debranding stylesheet ships in the backend bundle and applies automatically.

Scheduled jobs

Ten jobs are created and enabled. Review them against the deployment before go-live, particularly the three that reach the network and the two biometric jobs, which will try to contact terminals that may not exist yet.

• Auto Import Biometric Attendance · Download Attendance
• Sync Country Holidays · Sync Licenses from API
• Sync Contribution Tables (SSS/PHIC/HDMF) · Activate Due Circulars
• Leave Allocation: Check Validity
• Employee: Years in Service · Employee: Compute Age
• HR Employee Data Expiration

A clean install is not the same as a working one. Six checks, in this order.

1. Module state. Apps shows BaseUp Human Resources as Installed at 20.0.1.0.0.
2. Menus. Employees, Attendances, Overtime, Leaves, Payroll and Salary Loans all appear for an administrator.
3. Statutory data loaded. Payroll ▸ Configuration ▸ Premiums and Tax Tables — SSS should hold the Circular 2024-006 schedule, and Withholding Tax 24 bracket rows.
4. Dashboard renders. Employees ▸ Dashboard. If the counts appear but the charts do not, Chart.js is being blocked — see §6.
5. BIR report works. Open any employee, then the Print menu ▸ BIR Form 2316. A PDF must come back. Try to edit a field in it: if you can, PyMuPDF is missing and issued forms will not be flattened.
6. Payroll computes. Generate one payroll period, one register and one payslip for a test employee with a running contract, and confirm the statutory deductions are non-zero.

The module ships migration scripts, so upgrades run schema and data fixes automatically. Take a backup anyway — payroll data is not reconstructible.

# 1. back up first — database and filestore
pg_dump -Fc <database> > baseup-hr-preupgrade.dump
tar czf filestore.tgz /var/lib/odoo/filestore/<database>

# 2. replace the module files, then upgrade
sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/odoo-bin \
  -c /etc/odoo/odoo.conf -d <database> \
  -u baseup_human_resources \
  --stop-after-init

• Migration scripts present — migrations/ holds 1.0.0, 19.0.1.0.4 and 20.0.1.0.0. Odoo runs the ones between the installed version and the new one, so do not skip a version by hand-editing the manifest.
• Coming from the 19.0 module — a 19.0 database has to go through Odoo's own major-version upgrade; swapping the module files and running -u is not enough on its own. When the module is migrated, the 20.0.1.0.0 script renames the leave-summary column that followed Odoo 20's leave-type rename (holiday_status_id to work_entry_type_id) and moves stored attendances from the old validate state to Odoo 20's validated. Without it, historic leave summaries lose their leave type.
• License parameters survive — they are noupdate, so an upgrade will not undo the hardening in §8.
• Watch the log for view errors — this module inherits heavily from the Odoo HR views, which is where an Odoo point-release change usually surfaces first.