Manufacturing shopfloor users can now update the most recent time log when a timer was started or stopped incorrectly. This helps keep work order time tracking accurate and reduces the need for back-office corrections.

The "Update Time Log" dialog inside shopfloor is added to increase the timer's reliability by manually entering the desired time. If someone forgot to start or stop the timer, this option now enables them to edit the last entry on the timer's list.

Task-6164336

We remove the "refresh" button used to refresh the customer display screen from the debug windows as it's almost never used. see odoo/enterprise#123483 task-6357970

We remove the "refresh" button used to refresh the customer display screen from the debug windows as it's almost never used.

see odoo/enterprise#123483
task-6357970

In saas-19.3, `account_peppol` no longer uses `_log_verification_state_update()` and now logs partner verification changes through `_track_add()`. French PDP still needs to display a PDP-specific verification state in the chatter instead of the raw Peppol state, because the same Peppol technical result can have a different business meaning when the receiver is routed through the French PDP annuaire. Task-6296383 Forward-Port-Of: odoo/odoo#271325

In saas-19.3, `account_peppol` no longer uses `_log_verification_state_update()` and now logs partner verification changes through `_track_add()`.

French PDP still needs to display a PDP-specific verification state in the chatter instead of the raw Peppol state, because the same Peppol technical result can have a different business meaning when the receiver is routed through the French PDP annuaire.

Task-6296383

Forward-Port-Of: odoo/odoo#271325

LEGAL REQUIREMENTS - As of January 2026, the 9% VAT will increase to 12%. PURPOSE - For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines. - And add the missing taxes from the sheet provided in the task description. Related PR: https://github.com/odoo/enterprise/pull/101773 Task-5269617 Forward-Port-Of: odoo/odoo#276414 Forward-Port-Of: odoo/odoo#239388

LEGAL REQUIREMENTS
- As of January 2026, the 9% VAT will increase to 12%.

PURPOSE
- For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines.
- And add the missing taxes from the sheet provided in the task description.

Related PR: https://github.com/odoo/enterprise/pull/101773

Task-5269617

Forward-Port-Of: odoo/odoo#276414
Forward-Port-Of: odoo/odoo#239388

To ensure that terms are exported to translation files, they need to use `_t`. Using the previous method won't export terms. No Task (issue identified by blse)

To ensure that terms are exported to translation files, they need to use `_t`. Using the previous method won't export terms.

No Task (issue identified by blse)

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice. task-6365267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274996

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice.

task-6365267




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#274996

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

Task [link](https://www.odoo.com/odoo/project.task/6037525)
task-6037525

Forward-Port-Of: odoo/odoo#259197

Payment initiation data now includes additional payer and creditor information such as names, VAT numbers, and addresses. This helps Powens process online payments with richer transaction details and may improve compatibility with its requirements.

Powens requires more information that what is already provided in the payment initiation payload. This commit adds payer/creditor name and VAT.

task-5977148

Draft bank statement lines now appear in blue in the reconciliation view. This helps accounting users quickly distinguish unfinished statement lines from confirmed ones, reducing review time and confusion.

This commit will put the text in blue when the statement line is in draft to be able to see quickly which lines are in draft.

task-6327308

Forward-Port-Of: odoo/enterprise#121775

The journal creation wizard now supports navigating options with keyboard arrow keys. This makes setup faster and easier for users who prefer keyboard navigation or rely on it for accessibility.

This commit aims to allow for navigation through the journal create wizard via keybaord arrows.

Related Odoofin PR: https://github.com/odoo/odoofin/pull/502
task-5796200

Forward-Port-Of: odoo/enterprise#105541

LEGAL REQUIREMENTS - As of January 2026, the 9% VAT will increase to 12%. PURPOSE - For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines. - And add the missing taxes from the sheet provided in the task description. Related PR: https://github.com/odoo/enterprise/pull/101773 Task-5269617 Forward-Port-Of: odoo/odoo#276414 Forward-Port-Of: odoo/odoo#239388

LEGAL REQUIREMENTS
- As of January 2026, the 9% VAT will increase to 12%.

PURPOSE
- For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines.
- And add the missing taxes from the sheet provided in the task description.

Related PR: https://github.com/odoo/enterprise/pull/101773

Task-5269617

Forward-Port-Of: odoo/odoo#276414
Forward-Port-Of: odoo/odoo#239388

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice. task-6365267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274996

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice.

task-6365267




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#274996

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

Task [link](https://www.odoo.com/odoo/project.task/6037525)
task-6037525

Forward-Port-Of: odoo/odoo#259197

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276345 Forward-Port-Of: odoo/odoo#267482

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call.

opw-6237180

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276345
Forward-Port-Of: odoo/odoo#267482

While upgrading the database to v19.2, several Tags are missing from the tax grid - Tags following the `mod349[X]` pattern (e.g., A, T, I, etc.) missing in upgraded database - Without these tags, the accounting reports display 0 - Earlier, I created an [upgrade](https://github.com/odoo/upgrade/pull/10434/changes/6afa01302928d77591430ff6e2779b35d7c92126) script to handle this issue, but after discussing with the reviewer, I created a fix in the community <img width="1846" height="845" al

While upgrading the database to v19.2, several
Tags are missing from the tax grid

- Tags following the `mod349[X]` pattern (e.g., A, T, I, etc.) missing in upgraded database
- Without these tags, the accounting reports display 0
- Earlier, I created an [upgrade](https://github.com/odoo/upgrade/pull/10434/changes/6afa01302928d77591430ff6e2779b35d7c92126) script to handle this issue, but after discussing with the reviewer, I created a fix in the community

<img width="1846" height="845" alt="image" src="https://github.com/user-attachments/assets/618bf6fd-73df-4ad2-af35-17cc018d7cf4" />







---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The French balance sheet report now presents establishment costs before fixed assets and includes additional impairment accounts in the relevant tangible fixed asset lines. This improves report alignment with expected French accounting presentation and helps ensure these balances are reflected in the right sections.

Move establishment costs before fixed assets in the French balance sheet,
and include the missing 2912, 2913, 2914, and 2915 impairment accounts in
the relevant tangible fixed asset amortization/provision lines.

task-6226138

Forward-Port-Of: odoo/enterprise#117689

Users can now move through the journal creation wizard using keyboard arrow keys. This makes setup faster and more accessible for people who prefer or rely on keyboard navigation.

This commit aims to allow for navigation through the journal create wizard via keybaord arrows.

Related Odoofin PR: https://github.com/odoo/odoofin/pull/502
task-5796200

Forward-Port-Of: odoo/enterprise#105541

Spreadsheet users can now use a new filter label function to display the readable name of a selected global filter value, such as a customer name, instead of only its internal ID. This makes spreadsheet reports easier to understand and share with business users.

Before this commit:
If you use ODOO.FILTER.VALUE and have a customer set in the global filter, it returns the id of the customer. That can be useful in some cases but in others you might simply want the label.

Task: 6167605

Forward-Port-Of: odoo/enterprise#115984

Add the missing 2912, 2913, 2914, and 2915 accounts from the 2026 PCG so the French chart matches the balance sheet impairment mappings for tangible fixed assets. task-6226138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265160

Add the missing 2912, 2913, 2914, and 2915 accounts from the 2026 PCG
so the French chart matches the balance sheet impairment mappings for
tangible fixed assets.

task-6226138

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265160

When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276543 Forward-Port-Of: odo

When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode:
- The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank.
- The `no_variant`-mode attributes (e.g. Size) are shown for user input.

opw-6220883

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276543
Forward-Port-Of: odoo/odoo#265189

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice. task-6365267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274996

When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice.

task-6365267




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#274996

Task: 6167605 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261793

Task: 6167605

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#261793

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

Task [link](https://www.odoo.com/odoo/project.task/6037525)
task-6037525

Forward-Port-Of: odoo/odoo#259197

French VAT declarations now handle SIRET numbers that include spaces by cleaning them before submission. The update also warns users when a bank account number appears incorrectly formatted, helping prevent failed filings.

This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input.

Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted.

task-6253745

Forward-Port-Of: odoo/enterprise#120689

Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#269465

Move French e-invoicing technical statuses out of the main invoice UI and into the chatter.

The PPF status is kept available in debug mode for troubleshooting,
while regular users get a concise chatter summary with the PA status, PPF status,
and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter.

Task-6273270

Forward-Port-Of: odoo/odoo#269465

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time.

Forward-Port-Of: odoo/odoo#276600

The Sendcloud delivery setting previously called "Use Batch Shipping" is now named "Use Multicollo". This aligns the wording in Odoo with Sendcloud terminology, reducing customer confusion without changing the underlying functionality.

In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud.

task-6048477

Forward-Port-Of: odoo/enterprise#123195
Forward-Port-Of: odoo/enterprise#122133

Timesheet Assistant suggestions can now be selected more quickly by dragging over them while holding the mouse button. This also prevents Ctrl-clicking a suggestion from accidentally opening a new Odoo page, making bulk actions smoother and less disruptive.

Currently when the user uses ctrl + click on a suggestion, a new odoo page is opened. This is an undesirable side effect and it is removed in this commit.
Also, users have to manually click on each suggestion when they want to remove them in batch, or create one timesheet for a bunch of suggestion. This commit lets user hover over suggestion with the mouse button pressed to select them.

task-6385047

Updates improve the AI-powered website builder workflow, including its configuration data, builder integration, and supporting utilities. This should help users create or adjust website content more smoothly with AI assistance, though the change appears to be work in progress.

The settings pages for Planning and Field Service have been reorganized into clearer sections such as Planning, Operations, Sales & Billing, and Analytics. This makes configuration easier for users as the number of available options has grown, helping teams find the right setup choices faster.

Reorganize the settings view for Planning and Field Service into intuitive sub-categories (Planning, Operations, Sales & Billing, Analytics).

As the available options have grown significantly, this restructuring guides the user more effectively through the configuration steps.

- Planning: Employee Unavailabilities, Project Planning, Recurring Shifts
- Operations: Field Service, Stock by Vehicle, Worksheets, Equipment, Customer Report, Geolocation
- Sales & Billing: Billing, Website Form, Products, Quotations, Travel Fees
- Analytics: Customer Ratings

task:6172495

Accounting users can now open the related budget directly from an account move form using a new smart button. This saves time when reviewing financial entries and makes it easier to trace how entries affect budgets through analytic lines.

On the account move form view, add a smart button that redirects to the linked budget (linked through the analytic lines)

task-6307932

The bank reconciliation screen now finds eligible accounting entries more efficiently on large databases. This reduces long wait times when loading reconciliation suggestions, helping accounting teams work faster without changing their workflow.

The bank reconciliation widget's `search_read` on `account.move.line` use `search_account_id.reconcile` to filter reconcilable accounts. This caused PostgreSQL to prefer an ordered
index scan on `_date_name_id_idx`, walking ~3M rows for ~100 matches (40+ seconds on large db).

Solution :
match the approach already applied on
the Python side in `_get_default_amls_matching_domain` This lets the planner use the existing
_unreconciled_index partial index instead.

opw-6328640

This update prevents Chilean electronic documents from being submitted with more business activities than the official XML format allows. By enforcing the four-activity limit earlier, companies can avoid document rejections and related processing delays.

The Chilean XML schema supports maximum of 4 activities (l10n_cl_company_activity_ids), but we allow to add more than that. If this happens, it causes rejections since electronic documents are being sent with more than 4 options selected, and returning rejection errors.

Adding constraint to limit l10n_cl_company_activity_ids

task-id: 6329320

This commit implements a way for user to manually set a default value for the `invoice_cash_rounding_id` field in moves, and apply by default a standard `account.cash.rounding` record based on the found `ir.default` record or the ISO-4217 standard for every available currency. It adds 5 new `account.cash.rounding` record included on the data of the `account` module. They're set with the 'biggest_tax' strategy so that the user doesn't need to add required account data on the fields. We

This commit implements a way for user to manually set a default value
for the `invoice_cash_rounding_id` field in moves, and apply by default
a standard `account.cash.rounding` record based on the found `ir.default`
record or the ISO-4217 standard for every available currency.

It adds 5 new `account.cash.rounding` record included on the data of the
`account` module. They're set with the 'biggest_tax' strategy so that
the user doesn't need to add required account data on the fields.

We use the `ir.default` object to store the "preferred" default value of
the move rounding field. The rounding field will also be computed to
make sure it gets filled with the default value. An override on
`default_get` is needed so that the default `ir.default` behavior does
not interferre with the compute and making sure the rounding field gets
computed correctly.

To set a preferred `ir.default` on the cash rounding field, the user
must create a new record on "User-Defined Defaults" menu, select the
cash rounding, fill the JSON value with the rounding record ID, and fill
either the company field and/or the condition string with
"currency=<currency_name>" (e.g. "currency=USD"). When searching through
the `ir.default` records to apply, the code will by priority search
through the record sorted by:

- company and currency condition filled
- currency condition filled
- company filled

By default, 3 `ir.default` record are created when installing `account`
module as an exception to the ISO-4217 standard in Odoo for the currency
of IDR, INR, and CHF.

An options for digits is added on the rounding field in the
`account.cash.rounding` list and form view, to make sure the additional
decimal points are shown (it's set to hide anything smaller than 2
digits behind the decimal separator)

In master (18.1), an additional preferred default value for the rounding
field will be saved on the partner of the move, and will be made a
priority over all current `ir.default` for this rounding field.

task-id: 4338116

Before this commit, when an authentication process was ongoing it was not very clear to the user This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted. task-6372665

Before this commit, when an authentication process was ongoing it was not very clear to the user
This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted.

task-6372665

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time.

Forward-Port-Of: odoo/odoo#276600

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600

Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time.

Forward-Port-Of: odoo/odoo#276600

task-no

task-no