Wednesday, September 9, 2026
10 changes · master
New functionality added to Odoo
Mass mailing users can now save campaigns as reusable templates and manage them from a dedicated Templates menu. This makes it easier to standardize future mailings, reuse proven designs, and preview templates more reliably.
Original PR description
Overview ------ This commit introduces the mailing templates in mass mailing. Before this commit, the only way to save a mailing as a template is to set it as favorite so that it will appear in the…
Overview ------ This commit introduces the mailing templates in mass mailing. Before this commit, the only way to save a mailing as a template is to set it as favorite so that it will appear in the theme selector alongside the common themes. Setting a mailing as favorite does not create a new mailing (template) it only set the favorite flag to true. This commit extends the favorite behavior and adds a complete template library, where the mailing can be saved as a true template, and hence a new mailing (with is_template=True) is created and listed under the `Templates` menu. Specification ------ - Remove the 'favoritism' from mailing.mailing: this includes the favorite star icon and the favorite field. - Add a cog menu item in the form view to save a mailing as a template. - Using a template (clicking on the `use this` button) will create a new mailing out of that template. Technical Notes ------ In order to have a proper display of the templates in the kanban view, we had to add a few things: - Load the kanban renderer inside an iframe: this will help isolate the html content of the templates from the outer Odoo one. -> Better for security and customized stylesheets load. - Wrap the renderer component in a wrapper component to make the reload smoother at every props update; the rationale behind this is to avoid reloading the whole iframe, which is a costing operation with all the stylesheets being refetched, at every props update. task-5358279 subtask-6110541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Thai localization now creates compliant tax invoices for VAT sales and receipts, including cases where tax is due on invoice or on payment. Users get separate numbering, a dedicated tax invoice print action, clearer PDF details, and an invoice page to manage generated tax invoices, while older simplified print options are removed.
Original PR description
For VAT-registered sellers, tax invoices must comply with the Revenue Code and Revenue Department regulations. A tax invoice can also serve as a standard invoice or a receipt, so support is required…
For VAT-registered sellers, tax invoices must comply with the Revenue Code and Revenue Department regulations. A tax invoice can also serve as a standard invoice or a receipt, so support is required for both invoice and payment-based tax invoicing. - Create TINV tax invoices when posting invoices containing invoice lines with tax_exigibility='on_invoice'. - Create RCT tax invoices for payments when reconciling payments against invoice lines with `tax_exigibility='on_payment'`, including both full and partial payments. - Use independent numbering sequences for TINV and RCT tax invoices. - Add a dedicated action to print Thai tax invoices. - Display the tax invoice number, date, payment information, and tax breakdown on the PDF. - Support the appropriate tax invoice lifecycle for invoice posting, payment reconciliation, and cancellation. Note: - Initially, in the TH localization, we only added 'Tax' as a prefix to the invoice PDF title to indicate that it was a tax invoice. To print the regular invoice PDF, we provided a separate Commercial Invoice print option. - With this task, we are introducing a complete Thai tax invoice feature. As part of this change, we are removing the old template that only added the 'Tax' prefix to the PDF, since it is no longer needed. - We are also removing the Commercial Invoice print option from the menu. The normal Print PDF button will now print the standard invoice PDF. - To manage and print tax invoices, we have added a new page to the invoice form view where users can see all the tax invoices generated for the invoice and print their corresponding PDFs. - As a result, we are removing the old tax invoice templates and introducing new templates specifically for printing the complete Thai tax invoices. Upgrade: https://github.com/odoo/upgrade/pull/11191 task-[6384295](https://www.odoo.com/odoo/project/967/tasks/6384295)
Belgian payroll now supports the 281.30 and 274.30 declarations used mainly for reporting presence tokens. Businesses can also mark employees to be excluded from existing .10 and .20 declarations and included in the new .30 declaration instead, improving compliance coverage for Belgian payroll reporting.
Original PR description
This commit introduces the 281.30 and 274.30 declarations to the Belgian payroll localization. Those declarations are used mainly for reporting presence tokens (jetons de présence). There was also an option added for the version where an employee can be excluded from .10 and .20 declarations, and be included in the .30 declaration instead. task-6147823
Odoo now supports submitting Pakistan customer invoices and debit notes to the Federal Board of Revenue through Odoo's proxy service. Businesses can validate partner registration, complete required compliance checks, store FBR references and responses, and print QR codes on invoice reports for compliant e-invoicing.
Original PR description
Add support for submitting customer invoices and debit notes to Pakistan's FBR (Federal Board of Revenue) via Odoo's proxy service. Add a button that lets users check a partner's FBR registration status. Sending is blocked by compliance checks until required parameters are set. Once posted to FBR, the request/response and FBR reference are stored and printed with a QR code on the invoice report. Onboarding support is also included to run FBR's required sandbox test scenarios needed to whitelist the database. see odoo/iap-apps#1168 task-2879519
Enhancements to existing features
Chilean electronic invoicing now supports branches that operate under the same legal entity as their parent company. Branches can share official folio ranges and certificates, roll over to new ranges correctly, and receive incoming documents routed to the right branch.
Original PR description
A branch is the same legal entity as its parent: it shares its RUT, SII registration and certificate, and issues folios out of the ranges the SII granted that RUT. CAFs, folio counters and the localization config were scoped to a single company, so branches could not issue at all. Resolve the legal entity a company issues under and read it wherever a DTE states the issuer, draw folios from the first range still in use so branches sharing a range continue one series and a spent range rolls over to the next, and route incoming documents to the branch named in `CdgIntRecep`. A company ever granted a range of its own never falls back on the one above it, so a branch out of folios is asked for a new CAF instead of consuming its parent's. upgrade: odoo/upgrade#10893 task-6218881
The Bank Reconciliation Summary now gives finance teams a fuller view by showing both reconciled and unreconciled bank activity, including partially reconciled items. It also adds clearer balance checks, line-level warnings, and a period-based layout so users can more easily spot mismatches between bank balances and the general ledger.
Original PR description
- Structure of the report would be like below:- - Bank Account Name - Opening Bank Balance - Reconciled Transactions - Reconciled Receipts - Reconciled Payments - Unreconciled Transactions -…
- Structure of the report would be like below:-
- Bank Account Name
- Opening Bank Balance
- Reconciled Transactions
- Reconciled Receipts
- Reconciled Payments
- Unreconciled Transactions
- Unreconciled Receipts
- Unreconciled Payments
- Misc. operations
- Calculated Ending Bank Balance
- Ending General Ledger Balance
- Outstanding Receipts/Payments
- Outstanding Receipts
- Outstanding Payments
- The main change in the report is that report now shows both reconciled and
unreconciled transactions. (Before this commit it displayed only unreconciled
transactions.)
- Reconciled transactions will report reconciled amount of the transaction and
Unreconciled transactions will report residual amount of the transaction.
So partially reconciled transaction will appear twice in the report.
- Opening bank balance = last statement before period's starting balance
+ that statement's transactions before period
+ transactions without statement before period
- If we don't find any transactions before period, then we'll look for period's
first statement and take its starting balance as opening bank balance.
- Opening bank balance will redirect to transactions used in above calculation.
- If opening or calculated ending bank balance mismatches with GL balance as of
that day, an error icon with warning message tooltip will be added on that
respective lines and that error icon will redirect to General Ledger.
- Similar warning icon will be added on Misc. Operations line if there are any
misc operations and that icon redirects to that misc entries.
- Before this commit misc entries line only reported total balance and that
balance redirected user to misc entries, but with this commit that misc entries
are now added in this report itself like transactions and redirect on misc
balance has been removed.
- A new warning at top of the report has been added for transactions without
statement and warnings for GL mismatch and misc entries have been moved from
there to related report line.
- Change reconciliation report name from `Bank Matching` to
`Bank Reconciliation Summary`.
- Replace the current date selection with period selection, with previous month
selected by default.
- Enable `Add totals below sections` setting for this report.
- Remove journal groups from report options, as this report is mainly about Bank
Journal from which this report was opened.
- Remove `Currency` column from the report as `Amount Currency` column's amounts
will be already formatted with their respective currencies.
- Remove red color from negative amounts, as they are just outgoing payments
and by looking at red color user will assume that there is something wrong with
that payments.
- Opening balance, ending balance and GL balance lines will be always visible
even if filter `Hide lines at 0` is applied. Same logic is applied for misc
entries but only if we have misc entries.
UPGRADE PR: https://github.com/odoo/upgrade/pull/10951
[task-4638579](https://www.odoo.com/odoo/project/967/tasks/4638579)Belgian payroll calculations now reflect the 2026 rules for intellectual property income, including ONSS exemptions, withholding tax limits, yearly caps, and artistic certificate cost treatment. This helps payroll teams apply the correct employee remuneration split and reporting rules automatically.
Original PR description
Since 2026, the intellectual property (IP) is exempt from ONSS up to 30% of the total remuneration (DmfA code 47), unless the ONSS contributions are forced on the contract (default). The IP withholding tax (15%) only applies within that share and while the average IP of the 4 previous years stays under the yearly limit (77220€ in 2026); the lump-sum costs only remain for the owners of a certificate of artistic work. The IP paid in the year is capped on the yearly limit, the exceeding part being a regular remuneration. The rule cp200_employees_salary_ip_part_onss becomes generic: ONSS on the remuneration exempt from withholding tax (category ONSS_NO_WT).
Product names are no longer mixed into line-item descriptions on sales orders, purchase orders, and invoices. This makes descriptions clearer, improves electronic document exports, and reduces inconsistent behavior across related business documents.
Original PR description
Sale order lines, purchase order lines, and account move lines currently store the product's display name together with its description in the `name` field. This behavior was originally introduced so…
Sale order lines, purchase order lines, and account move lines currently store the product's display name together with its description in the `name` field. This behavior was originally introduced so the product field could remain hidden while still displaying both the product and its description in a single field. Maintaining this behavior requires a significant amount of JS logic and has led to several inconsistencies across the different models. Now that the framework supports stacking multiple fields in the same column, this workaround is no longer necessary. Keeping the product name in the description also has several drawbacks: - Product names are unnecessarily exported as EDI descriptions. - The description field always contains a value, making it impossible to tell whether a custom description was actually provided. - Models such as sale order templates do not follow the same convention,resulting to complex logic to make it work. - The JS widget needs complex logic to strip the product name while taking translations into account. - The product/description logic has become tightly coupled with the sections widget, making it difficult to maintain. This commit stores only the product description in the `name` field and introduces a new non-stored computed `label` field on sale order lines, purchase order lines, and account move lines. The `label` field combines the product display name and description and is used wherever both pieces of information need to be displayed, such as reports, the portal, and list view seachable text field introduced in d069ce59e28fda2bc25fb89fd01ee7b988a30fa0. For sale, the extra logic required to preserve the product name across sale orders and sale order templates is removed, allowing the `name` field to be used consistently as the product description. For purchase, the seller-specific naming logic is removed from the compute methods and delegated to the product display name retrieval. For accounting, EDI exports now contain only the actual line description instead of the product name followed by the description. This PR is the first step towards adapting the new framework `<column>` support for the product and description field, allowing the remaining JS logic to be significantly simplified in follow-up PR. task-6241473 See Also: - https://github.com/odoo/enterprise/pull/122792 - https://github.com/odoo/upgrade/pull/10919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll now settles remaining mobility budget amounts at year-end or on an employee's final payslip, aligning calculations with Partena requirements. The update improves accuracy for yearly prorations, termination fees, compliance checks, and warnings for cases such as budgets outside limits or employees combining a mobility budget with a CO2-emitting company car.
Original PR description
Rework the mobility budget logic according to Partena requirements. - Settle the remaining mobility budget in December or on the employee's final monthly payslip instead of in the anniversary month. - Include the mobility budget amount in termination fee computations. - Compute the yearly mobility budget as a prorated amount based on all employee versions within the calendar year. - Add warnings when the mobility budget falls outside the configured boundaries or exceeds 20% of the yearly wage. -Add a dashboard warning for employees with a mobility budget and a company car emitting CO₂. -Move the computation of the default mobility budget amount from l10n_be_hr_contract_salary to l10n_be_hr_payroll. related Upgrade commit: https://github.com/odoo/upgrade/pull/10877 task: 6263962
VoIP users can now manage multiple caller ID numbers and have the right personal number selected automatically based on the country they are calling. This helps teams with numbers in multiple countries present a more appropriate caller ID, while still allowing manual selection of shared or pinned numbers when needed.
Original PR description
A user could only ever be assigned a single DID number, which forced Wazo customers with numbers in several countries to always present the same caller ID abroad. Users can now hold several active DIDs; the outbound caller ID is picked automatically based on the destination country (falling back to a persisted choice), and can be reviewed, pinned, or toggled off from the status menu's "My numbers" section. The in-call view shows which number is being used while dialing out.