For administrators: how to replace the add-on safely, refresh the Apps registry, run the module upgrade, and smoke-test finance flows.
Overview
An upgrade keeps your database and data, but loads newer Python, XML, and security rules from the vendor’s package. Always take a backup first and prefer a staging copy of the database when the jump is large (for example many minor versions at once).
How it works
Replacing files on disk does not change the database schema by itself. After files are in place, Odoo must run the module’s upgrade hooks so new fields or menus appear. Skipping the upgrade step after copying new code is a common reason for errors or “old” behaviour.
Step-by-step guide
- Backup the database and filestore (or confirm your host’s automatic backup window).
- Download the new Accounting Pro package from your vendor and note the release notes.
- Stop or quiesce heavy user activity if possible (not always required on small teams).
- Replace the old
account_profolder on the server with the new one (same parent path, same folder name). Do not nest a secondaccount_proinside the old folder. - Restart the Odoo service so workers load fresh Python.
- Turn on Developer mode if your process requires it, then open Apps and run Update Apps List.
- Remove the Apps filter so “Extra” modules show, search for Accounting Pro, open the module card.
- Click Upgrade (wording may be “Upgrade” on the module form when the module is already installed). Wait until it finishes.
- Ask users to refresh the browser (or log out and in).
- Run the smoke test below on staging first, then repeat on production after sign-off.
Fields table
Smoke-test checklist after an upgrade (treat each row as a pass/fail gate).
| Step | What to verify | Pass criteria (example) |
|---|---|---|
1 |
General Settings → Accounting Pro block still visible |
Toggles load; Save works without traceback. |
2 |
Configuration → Account Pro lists open |
Collection strategies (or another list) opens in list view. |
3 |
Accounting → Pro Dashboard loads |
No client error; tiles render (values may be zero). |
4 |
Open a posted invoice with Pro fields |
Header and line Pro fields visible per your Settings toggles. |
5 |
Open a posted payment with Pro fields |
Strategy / treasury / fee fields visible when enabled. |
6 |
Open a partner bank with Pro fields |
KYC / rails fields visible when enabled. |
Field explanations
Each paragraph matches one row in the table above, in the same order.
Step 1 – Settings block
Confirms the module’s settings UI still loads; upgrade problems often show here first as a Python error when opening Settings.
Step 2 – Account Pro lists
Confirms configuration menus and security for master data still work; missing views usually mean upgrade did not run or a file conflict occurred.
Step 3 – Pro Dashboard
Confirms the client action and JavaScript assets load; asset bundles sometimes need a hard browser refresh after upgrades.
Step 4 – Posted invoice
Confirms invoice extensions and optional field groups survived the migration; try both customer and vendor documents if you use both.
Step 5 – Posted payment
Confirms payment model extensions; treasury and fee columns are common regression spots if access rules changed.
Step 6 – Partner bank
Confirms partner bank extensions; validates another inheritance chain than invoices alone.
Hospitals/Pharmacies
Sites where the drug is available to staff.
Coverage (Min/Target/Max)
Policy thresholds per site for reordering and caps.
Current Qty
Live on‑hand quantity aggregated from configured locations.
Has Expiring Lots
True when any lot expires within the next 30 days.
Tip: Keep the vendor’s changelog next to this checklist – if they renamed a group or moved a menu, your smoke test should follow the changelog for one extra minute.
Common mistake: Copying new files but only restarting without clicking Upgrade on the module – users keep running the old database definition until upgrade runs.