Third-party layer

1. Purpose

This page documents Tier 2 — the modules NestERP ships but CodeNest did not write and does not own. They sit between Odoo core and our custom code, and in several places they are not optional extras but load-bearing parts of the product.

It exists because a client is entitled to know what is in their stack and who stands behind each part of it. Undisclosed third-party dependencies become disputes at upgrade time.

The two facts that matter most

1. The Accounting app itself is third-party. Core Odoo Community gives only Invoicing. The Accounting menu, Profit & Loss, Balance Sheet and asset management come from Cybrosys base_accounting_kit, and the drill-down reports from Heritage dynamic_accounts_report.
2. All payroll is third-party at its base. Odoo's official payroll is Enterprise-only, so every NestERP payslip is computed on Cybrosys hr_payroll_community.

Neither is a defect — both are the normal way to run serious accounting and payroll on Odoo Community. But they must be disclosed, not discovered.

2. Features

What the third-party layer contributes to the product:

• The Accounting application — root menu, financial statements, asset management, cheque printing configuration, recurring entries (base_accounting_kit)
• Drill-down financial reporting with filters (dynamic_accounts_report)
• Budget definition and budget-versus-actual (base_account_budget)
• Payroll computation — salary structures, salary rules, payslips, payslip batches (hr_payroll_community)
• Payroll accounting — posting payslips to the ledger (hr_payroll_account_community)
• HR operations suite — loans, salary advances, resignations, transfers, document expiry, reminders, rewards and warnings, HR dashboard, multi-company HR (OpenHRMS)
• Excel report engine used by our export features (OCA report_xlsx)
• Branch-level separation of documents beyond company level (multi_branch_base)

3. Where to find it

These appear inside the apps they extend rather than as separate menus. base_accounting_kit supplies the Accounting root menu; OpenHRMS appears throughout the Employees and Payroll areas.

4. Modules used

Cybrosys — accounting

Module	Role	Optional?
base_accounting_kit	Supplies the Accounting app: root menu, financial statements, assets, recurring entries	No — always installed
base_account_budget	Budget definition and comparison	Where budgeting is used

Heritage — reporting

Module	Role	Optional?
dynamic_accounts_report	Filterable, drill-down financial reports	No — always installed

Cybrosys — payroll

Module	Role	Optional?
hr_payroll_community	Salary structures, rules, payslips, batches	No — payroll does not exist without it
hr_payroll_account_community	Posts payslips to accounting	No, where payroll posts to the ledger

Cybrosys — OpenHRMS suite

Module	Role
ohrms_core	Suite umbrella; pulls in most of the rest
ohrms_loan, ohrms_loan_accounting	Employee loans and their accounting
ohrms_salary_advance	Salary advances
hrms_dashboard	HR dashboard across leave, attendance, recruitment, events
hr_employee_updation	Extended employee data
hr_employee_transfer	Inter-department and inter-company transfers
hr_resignation	Resignation workflow
hr_reward_warning	Rewards and disciplinary warnings
hr_reminder	HR reminders
hr_leave_request_aliasing	Leave requests by email
hr_multi_company	HR across multiple companies
oh_employee_creation_from_user	Creates an employee from a user account
oh_employee_documents_expiry	Document expiry tracking and alerts

OCA

Module	Role
report_xlsx	Excel report engine
report_xlsx_helper	Helper layer on top of it

Vendor to confirm

Module	Role	Why it needs confirming
multi_branch_base	Branch separation across sales, purchase and stock	Vendor and licence not yet verified from the manifest
advanced_loan_management	Loan management	Same
employee_bonus_manager	Employee bonuses	Same

5. Configuration

Third-party modules are configured inside the apps they extend — see Accounting, Employees and Time Off & Attendance.

What is specific to this layer is install order and version discipline:

1. Install third-party modules before our custom modules, since ours depend on them.
2. Install hr_payroll_community before hr_payroll_account_community, and both before payroll_custom_module.
3. Install ohrms_core last of the OpenHRMS set — it pulls in the rest, and installing it first can mask a missing sibling.
4. Record the exact version of each third-party module deployed, per client. When one is upgraded, our modules must be re-tested against it.
5. Never edit a third-party module in place without recording it. A local patch that is not documented is lost at the next vendor update — and we have carried exactly this kind of undocumented local divergence in production before.

Configuration traps

• base_accounting_kit is not removable. Uninstalling it removes the Accounting menu and the financial statements the client works from daily.
• OpenHRMS installs a large surface area. ohrms_core brings in fourteen modules, several of which a client will never use but all of which appear in their menus and all of which must survive every upgrade.
• Local patches to vendor modules are invisible. Track them, or an upgrade silently reverts a fix.

6. How it's used

End users do not experience this layer as separate — they use the Accounting app and the Payroll app without knowing where the code came from. The audience for this page is implementers, and CodeNest at upgrade time.

7. Access rights

Third-party modules define their own access groups, which appear alongside core groups in the user form. OpenHRMS in particular adds several HR groups. Review them when granting access: a user given "all HR groups" may receive loan-approval or salary-advance rights nobody intended.

8. Version differences (16 / 17 / 18)

Odoo 16Odoo 17Odoo 18

• base_accounting_kit and base_account_budget present.
• No payroll and no OpenHRMS on this line — the 16 deployments are inventory and dangerous goods.

• The fullest third-party surface: accounting kit, dynamic_accounts_report, payroll, the complete OpenHRMS suite, OCA report_xlsx, multi_branch_base.
• The version of the Thalia reference instance.

• Accounting kit, payroll and OpenHRMS all present and verified working — the payroll stack plus three Cybrosys dependencies were upgraded to 18 and confirmed on the nesterp instance.
• dynamic_accounts_report, report_xlsx and multi_branch_base are not present on the 18 tree. Anything depending on them is therefore 17-only, which is part of why the Thalia finance modules and management dashboards have not moved to 18.

9. Known limitations

The limitations of this layer are commercial and operational rather than functional:

• We do not control the roadmap. If Cybrosys or Heritage does not release for a future Odoo version, that functionality stops at that version. For accounting and payroll — the two most business-critical areas — this is the single largest risk in the product.
• We cannot fix upstream bugs cleanly. We can patch locally, but the patch is ours to carry forward through every vendor update.
• Licence terms are the vendors', not ours. Confirm them per module before a client contract relies on them.
• Upgrade cost is unpredictable because it depends on three parties releasing, not one.
• The dynamic_accounts_report gap on Odoo 18 already demonstrates this: a client upgrading from 17 to 18 today would lose their drill-down financial reports.

Needs verification

• Confirm the vendor and licence of every Tier 2 module from its manifest author and license fields — this is the authoritative source and settles the three "to confirm" entries
• Confirm which Tier 2 modules are actually installed on the Thalia live instance (ir_module_module), versus merely present on disk
• Record the exact deployed version of each
• Identify any locally patched vendor module on the live instance by diffing the deployed copy against a clean vendor download
• Confirm whether dynamic_accounts_report has since released an Odoo 18 version