Daily updates from Odoo
Tuesday, July 8, 2025
36 changes · 18.0
Enhancements to existing features
Users can now adjust the exchange rate used on invoices, choose a rate from a specific date, and refresh it when it differs from the expected rate. This gives accounting teams more control and accuracy when handling invoices in foreign currencies.
Original PR description
- Make `invoice_currency_rate` editable. - Add a date picker widget that let the user apply the rate of a certain date. - Add a refresh button when the rate is not the expected one. To that end, the computed field `expected_currency_rate` is added. task-4378994
Point of Sale connected scales can now detect additional error states from Mettler Toledo devices. This helps prevent incorrect weight readings from being sent to the cashier when the scale is not operating normally.
Original PR description
This PR adds the detection of different error states of the Mettler Toledo 8217 protocol. When the scale is in an error state we need to make sure that the PoS user doesn't get any wrong scale data sent to the PoS. Related PR: https://github.com/odoo/enterprise/pull/89602
The Spanish SII electronic invoicing module updates its AEAT demo certificate used for testing and validation. This helps keep localization test data current so related workflows can continue to be checked reliably.
Original PR description
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#217341
This update makes an internal account follow-up check clearer and less prone to confusion when identifying related accounting records. It helps reduce the risk of errors in payment follow-up processing without changing how users interact with the system.
Original PR description
Refactored the SQL construction for checking the existence of related account.move records for res.partner entries. The account.move query is now built separately and referenced explicitly, making the code more readable and reducing the chance of ambiguity in field resolution. Using `SQL.identifier(query.table, "id")` ensures that the correct table is referenced in each condition, which is particularly important when dealing with multiple joins or subqueries.
This update keeps POS IoT scale validation aligned with recent Toledo scale error checks. It helps ensure connected weighing scales continue to report weights reliably after the related scale-handling changes.
Original PR description
This PR adapts the scale checksum to the PR adding the error checks to Toledo scales: https://github.com/odoo/odoo/pull/217674
Resolved issues and error corrections
Updates to analytic items now automatically keep the related journal item’s analytic distribution in sync. This prevents invoices and accounting entries from showing outdated analytic allocation information after edits or deletions.
Original PR description
overrode the write and unlink functions related to the analytic_line so that it synchronize the analytic distribution in the move_line every time a change happen before this commit whenever an analytic line is edited it is not reflected to its linked journal line's analytic distribution. so an update function is created so that the analytic distribution is updated whenever an analytic line is edited or deleted. task-4378407 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
Changing a company's country VAT label now reliably updates the label shown on contact forms. This prevents users from seeing outdated field names after their configuration changes, reducing confusion and ensuring the interface matches the saved settings.
Original PR description
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should…
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should and the old views with the old label are presented to the user instead of the new ones. This can be confusing to the user, because while their change had an effect on the database, it doesn't reflect on the views showed to them. **STEP TO REPRODUCE** 1. On a fresh database, install the contact app. 2. From the contact app, Configuration->Countries, select United States which should be the country of the demo company. 3. Change the Vat Label field value. 4. Go on any contact form view, and notice the label of the `vat` field wasn't updated. 5. You can refresh the pages, and sometimes the new value will be there, sometimes not. **CAUSE** https://github.com/odoo/odoo/blob/ac106704f3c2d3e3fa94415134b9d5522b325378/odoo/addons/base/models/res_partner.py#L41C1-L55C1 In the mixin `FormatVATLabelMixin` we modify the form view, changing the label of the vat field accordingly. However, the `_get_view_cache_key` override that would add the field used to make the change (`self.env.company.country_id.vat_label`) to the cache key is missing. Which means the cache isn't invalidated when it should. **FIX** Invalidating cache when writing on `vat_label` opw-4825749
This fix adjusts automated login flow checks so the two-step authentication step is only monitored when it is actually active. It helps prevent false test failures around sign-in and improves confidence in the authentication process.
Original PR description
In this commit, we change the login page step by a step with isActive property. So this step is only active when the input#login is not on the page and then expectUnloadPage will be only listen when this step is active. 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
This fix ensures the background-position editing overlay fills the full area of affected website snippets. It helps editors accurately adjust background images and keeps related tooltips positioned correctly.
Original PR description
Before this commit in some snippets background overlay wouldn't have
proper height and/or width because of the snippets `h-{}, w-{}` classes.
This commit overrides it with `!important`.
To reproduce the issue:
- open website and start editing
- drop columns snippet, add background image to one of the cards, click
on it
- Click on the background position option to change it(the one with
a crosshair icon)
- the overlay isn't shown properly, which also breaks the tooltip
position
This should be forward-ported up to 18.3 inclusive, and from 18.4 on, `background_position_overlay.js L135` should be changed because of the [html_builder refactoring].
task-4930050
[html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbThis fix corrects mismatched formulas in the POS HR spreadsheet dashboard. Business users should see more reliable dashboard figures when reviewing point-of-sale and employee-related reporting.
Original PR description
Task: 4930419 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
Long spreadsheet dashboard names in the search panel now show in full when users hover over them. This makes it easier to identify dashboards without changing the panel layout or requiring extra clicks.
Original PR description
Before this pr: - Long dashboard names were truncated in the search panel. - There was no way for the user to see the full name. After this pr: - A tooltip has been added to display the full dashboard name on hover. Task: [4903713](https://www.odoo.com/odoo/2328/tasks/4903713) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216578
This change prevents key activity types such as calls, meetings, todos, leave reminders, fleet contracts, and finance-related activities from being deleted or tied to the wrong business area. It reduces crashes and broken automated workflows when shared activity settings are missing or changed unexpectedly.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/odoo#156731Creating a new replenishment rule in Inventory no longer triggers an error when no product has been selected yet. This prevents an interruption in the replenishment setup flow and lets users continue entering the required details normally.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/213154/commits/ea480703b64d88ac572c3e37da3d9fb3327b4445 Steps to reproduce the bug: - Go to "Inventory" → "Operations" menu → "Replenishment" - Click "New" to create a new replenishment rule Problem: Traceback is triggered: ``` in _float_check_precision assert precision_rounding > 0,\ ^^^^^^^^^^^^^^^^^^^^^^ AssertionError: precision_rounding must be positive, got 0.0 ``` As the product is not set, the `product_uom` is not set either, which leads to a `product_uom.rounding` of 0.0. Opw-4925719 Opw-4928957 Opw-4926504 Opw-4925919 Opw-4928684 Opw-4925080 Opw-4928788 Opw-4926719 Opw-4927440 opw-4928540
Stock report PDFs now show table headers in bold as expected, matching the formatting users see in the report template. This improves readability and keeps printed inventory documents visually consistent.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380 enterprise PR: https://github.com/odoo/enterprise/pull/87852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Rotating large images in the HTML editor now keeps the rotation controls active even when the editing area becomes scrollable. This prevents interruptions during image adjustments and makes content editing smoother for users.
Original PR description
Problem: When a user rotates an image, certain image sizes can cause the editable area to become scrollable. This triggers `resetHandlers` from `usePositionHook`, resulting in loss of focus on the rotate controller. Solution: Add a flag to detect when the user is actively transforming (`mousedown`). Delay the reset until interaction ends (`mouseup`), preventing premature handler reset. Steps to reproduce: - Add a long image - Transform > Rotate until a scrollbar appears - You lose focus on the rotate controller opw-4890029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing payment details such as the amount no longer clears the existing journal entry name. This prevents unnecessary new numbering when payments are reposted, reducing confusion and avoiding unexpected gaps in accounting sequences.
Original PR description
Since PR #204507, the move name is reset whenever a payment with a `move_id` is modified, which was intended to allow changing the journal. However, this also resets the journal entry name unnecessarily when unrelated fields (e.g. amount) are updated. This causes confusion for users, especially when the payment is re-posted and a new sequence is generated, leading to gaps in the journal entry numbering without any apparent reason. This fix ensures the journal entry name is only reset when the `journal_id` field is updated. Steps to reproduce: 1. Create a payment and post it 2. Reset it to draft 3. Change the amount 4. Check the journal entry name → it is reset to '/' 4. Repost the payment, and a new sequence is generated Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4886466) opw-4886466
Sales order lines linked to a newly created project now automatically include the project's analytic account when no project account is already present. This restores expected cost tracking on invoices so project-related revenue and costs are reported against the correct project as well as any existing distribution model.
Original PR description
Steps to reproduce: ------------------- 1. Create a product of type service which creates on order project & task 2. Create a distribution model for that product with an analytic account "Operating…
Steps to reproduce:
-------------------
1. Create a product of type service which creates on order project & task
2. Create a distribution model for that product with an analytic account "Operating costs" set on the plan "Internal"
3. Create a new sales order and add the product to a SOL (the line will have the "Operating costs" analytic account thanks to the distribution model)
4. Confirm the SO (it automatically creates a project and the analytic account of the project)
5. Now create an invoice from that SO and look at the analytic distribution on the line:
- In v17.4, we had both analytic accounts (the one from the line & the one from the project)
- In v18, we only have one analytic account (only "Operating costs" but not the one from the project)
Fix:
-------------------
When adding a new SOL or adding a project to the SO:
=> We will now add to the SOL distribution a new line set at 100% containing the analytic account from the main plan (e.g. "Project") of the SO project if:
- No account is already set in the main plan (e.g. "Project") in any line of the SOL distribution
task-4630617
version-18.0Pasted multi-line content from apps like Discord is now cleaned more reliably in the Odoo editor. Invisible empty blocks are removed and valid content blocks are kept, preventing broken placeholder behavior and unwanted spacing.
Original PR description
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type…
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type '/' for commands" is getting destroyed. Description of the issue this PR addresses: - The issue was caused by visually empty `<div>` elements included in pasted content and not converted into baseContainer. - This regression was introduced in commit [#196481](https://github.com/odoo/odoo/pull/196481/files?diff=split&w=0#diff-1b8ed5b7d66a870806b1e7400a0d6cb9ba8810327824244eca868be9583b7fd9L467-L477), which stopped replacing blacklisted tags like `<div>` with `<p>`. - As a result, cleanForPaste no longer strips inline styles from `<div>` elements. Current behavior before PR: - Pasted content includes non-visible `<div>` elements. - These empty blocks occupy space without contributing visual content. - Inline styles from copied content remain intact. - `<div>` elements are not replaced with valid block tags. - Placeholder rendering is broken in these ghost spaces. Desired behavior after PR is merged: - Non-empty `<div>` elements are replaced with a baseContainer element. - Empty `<div>` elements are automatically removed from pasted content. - This restores the expected cleaning behavior, removes unwanted styles, and preserves line breaks. task-4805536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from seeing an access error when creating a bank account number that already exists in another company they cannot access. The duplicate check now respects company boundaries, so multi-company accounting users can continue their work without being blocked by records from other companies.
Original PR description
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only…
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only rights of company B and rights of Accounting/setting groups 5. create a Bank account(Contact->Configuration->Bank Account) with partner A in company A 6. Now login with user B and create a bank account number with same account number. Access error will come. For resolve the access error fetching the correct result according to company so it won't fetch other company result the changes merged last week https://github.com/odoo/odoo/commit/ad6c9001b447f5ffebafe1581512f48708c7d746#diff-22e97cf61c6826e67cd9a3276bdb292e997cb1117ca44c1749c69d5d01931787R69 ``` Access Error Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Test B (id=7) doesn't have 'read' access to: - Contact, A (res.partner: 8) Blame the following rules: - res.partner company If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. This seems to be a multi-company issue, but you do not have access to the proper company to access the record anyhow. ``` upg-2986193 opw-4876839 tbg-2093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents electronic invoice generation from failing when an invoice line contains a tax detail without a grouping key. The system now skips those incomplete tax details when building export tax categories, improving reliability for UBL/CII invoice exports.
Original PR description
Before this commit: If a tax detail of an invoice line has the None tax grouping key, there is a traceback when generating the UBL InvoiceLine/ClassifiedTaxCategory After this commit: We exclude tax details that have the None grouping key when generating the InvoiceLine/ClassifiedTaxCategory. task-none
This fixes an issue where adding a company-paid expense to an empty expense report did not set the correct payment journal. As a result, users can continue processing the report without encountering a payment method error.
Original PR description
Current behavior before PR: 1. Create an expense paid by company 2. Create an empty expense report (not through the expense form view) 3. Add the expense to the report (Updates the payment_method and payment_method_line_id but not the journal_id) 4. Try to move forward to create the move 5. Error (The selected payment method is not available for this payment, please select the payment method again.) Desired behavior after PR is merged: The right journal_id is set when adding an expense to an empty expense report. task-4804970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211190
Sale orders created from CRM no longer carry over the CRM lead's assigned salesperson when confirming related records. This prevents quality checks and other linked records from being assigned to the wrong user, improving operational accuracy.
Original PR description
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 Forward-Port-Of: odoo/odoo#215499
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The UAE Corporate Tax Report now prevents taxable and tax amounts from appearing as negative when profits are below the exemption threshold. This avoids confusing report results and ensures businesses see zero tax due instead of an incorrect pay-back amount.
Original PR description
The Corporate Tax Report was incorrectly showing a negative"Corporate TAX Amount" when the taxable profit fell below the exemption threshold (e.g 375,000 AED). This issue happened because the formula used to compute the Corporate TAX Amount was: `AE_CORP_TAXABLE.balance * (AE_CORP_TAX_PERC.balance / 100)` This formula applies the tax rate even when `AE_CORP_TAXABLE.balance` is negative, which results in an incorrect negative tax amount in the report. Since the report engine doesn't support conditional logic like `max(...)` or `> 0` in XML formulas, we couldn't fix this in the formula definition directly. To solve the issue, we added a check in the Python report handler `_custom_line_postprocessor` to override the value of the Corporate TAX Amount and cap it at zero when it would otherwise be negative. Steps to reproduce: In run bot or any db go to Corporate tax report OPW-4739052
Mexican electronic payment documents now calculate VAT bases consistently when invoices are paid in a foreign currency. This prevents valid USD payments from being rejected due to small exchange-rate rounding differences, helping businesses send compliant payment CFDIs successfully.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
- line 1: price_unit 93.76, quantity 172, tax 16%
- line 2: price_unit 74.18, quantity 161, tax 16%
- line 3: price_unit 74.18, quantity 162, tax 16%
- line 4: price_unit 93.76, quantity 384, tax 16%
- line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI
Issue: Payment validation will fail with error
> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".
opw-4750981
Forward-Port-Of: odoo/enterprise#88952This change prevents important activity types such as calls, meetings, approvals, tax tasks, payroll leave tasks, and bank synchronization from being accidentally deleted or reassigned. This helps avoid workflow failures across several apps that rely on these predefined activities, while also improving stability when activity data is missing or changed.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#58164PDF reports now show table headers in bold as intended, matching the formatting users see in the report template. This makes printed inventory reports clearer and more consistent for users who rely on PDF outputs.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380
Fixed an issue in the Barcode app where scanning a destination package after picking products could incorrectly overwrite earlier products' source locations. This helps keep delivery records accurate when warehouse staff pick items from multiple locations into the same package.
Original PR description
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to…
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to reproduce ================ - Enable multi-locations and package; - Create an empty package, two locations and two products; - Create a delivery in the Barcode app; - Scan the first location then the first product; - Scan the second location then the second product; - Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location. Cause of the issue ================== When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package. Solution ======== When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location. [opw-4859851](https://www.odoo.com/odoo/project.task/4859851) Forward-Port-Of: odoo/enterprise#89142
The German Intrastat XML report now includes all required fields and formatting needed by the German Federal Statistical Office. This prevents report rejections caused by missing XML details, region codes, test indicators, or interchange agreement information.
Original PR description
In the German Intrastat-Report some elements are missing when downloding the xml report First, the XML version and character encoding must be included in the XML prolog Second, the element testIndicator is missing when its false Third, the element interchangeAgreementId under Party Fourth, the element regionCode under Declaration > Item `interchangeAgreementId` field is entirely form Odoo, and absence of one of these elemetns prevents the report from being accepted by German Federal Statistical Office via INSTAT/XML. To solve this we need to add a new field for interchangeAgreementId in the res_company opw-4752415
This fix prevents Uruguay electronic invoicing from failing when a user clears a journal item description. It ensures invoices can still generate the required tax authority XML without an unexpected error.
Original PR description
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description automatically populates with the product name upon line creation. However, users can intentionally clear this field. If the description field becomes empty, its value is interpreted as `False`. This leads to an `AttributeError: 'bool' object has no attribute 'replace'` traceback when the `_l10n_uy_edi_get_line_nom_and_desc` method attempts to process this boolean value, as it expects a string. This issue specifically affects the generation of the "DscItem" tag in the XML file sent to DGI. ### Solution: To prevent this error, an additional validation has been implemented for the line description. This validation ensures that if the field's value is `False`, it is not processed by the `_l10n_uy_edi_get_line_nom_and_desc` method, thus avoiding the traceback.
This update adds validation for a specific return scenario involving intercompany dropship orders. It helps ensure these returns continue to work correctly and reduces the risk of regressions in multi-company sales and purchasing flows.
Original PR description
Adds test coverage for return of an intercompany dropship use-case (see corresponding community PR). opw-4526750
Employee document counts now include files stored in any folder under the Human Resources document area, not just files in the top-level HR folder. This prevents uploaded employee documents from appearing missing and ensures the employee record shows the correct document count.
Original PR description
Issue: currently, only the direct descendant of `hr_folder` are considered for counting employee documents. step to reproduce: - install documents_hr - from settings -> documents -> enable "Human Resources" (default folder is HR) - open a record from employees app - click on "documents" smart button - create a new folder inside HR folder and go inside it - upload a document **observation 1** : - uploaded document vanishes - return to employee record **observation 2** : - document count is still 0 Fix: change the responsible domain to consider all the documents inside hr_folder opw-4913495
Budget reports now avoid creating an extra duplicate line when a purchase order includes a negative discount line. This keeps budget figures accurate and prevents overstating discounted amounts in purchase-related budget views.
Original PR description
Steps to reproduce: - Create a new Budget with budget line having Project [TEST] - Create a purchase order with 2 lines: 1. Product A, analytic [TEST], price unit 100, qty 1 2. Product B, analytic [TEST], price unit -10, qty 1 - Confirm the PO, mark products as received - Create the bill and confirm - Go back in PO, click on Budget smart button, open list view Issue: The budget report will correctly show a line for each invoiced line, but an extra line with double discount amount is present Occurs because we use a SQL code to replicate the qty_invoiced field of a purchase order line, but we adjust the sign based on the aml balance instead of taking into account the move type opw-4775631
Customers with overdue invoices can now have follow-up letters printed without triggering an error. This helps accounting teams continue collection workflows smoothly even when report settings are incomplete.
Original PR description
**Issue** Printing a follow-up letter for an invoice with a past due date sometimes causes a traceback error. **Steps to Reproduce** 1. Install the Accounting module 2. Enable developer mode 3. Go to…
**Issue** Printing a follow-up letter for an invoice with a past due date sometimes causes a traceback error. **Steps to Reproduce** 1. Install the Accounting module 2. Enable developer mode 3. Go to Settings > Technical > Actions > Reports 4. Enable the Follow-Up letter print action 5. Navigate to Accounting > Customers > Invoices 6. Create an invoice with a past due date 7. Open the related customer’s contact form 8. Use the gear icon to print the follow-up letter 9. Observe the traceback error **Root Cause** The `_get_invoices_to_print` method expects the `options` dictionary to contain the key `'followup_line'`, but when `options` is empty or missing this key, the method tries to access `options['followup_line']` without verifying its presence. This results in a `KeyError` or attribute access on `None` **Fix** Added proper safety checks to verify the presence of `followup_line` in `options` before accessing its attributes. Also ensured `join_invoices` defaults safely to `False` if missing. This prevents the traceback and allows the method to handle empty or incomplete `options` gracefully Opw-4804896
Miscellaneous changes
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible w
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213410 Forward-Port-Of: odoo/odoo#201583
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible w
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#87228 Forward-Port-Of: odoo/enterprise#81354