Daily updates from Odoo
Monday, October 6, 2025
18 changes · master
Resolved issues and error corrections
Romanian SAF-T reporting now correctly identifies partners as customers or suppliers even when their balance is zero, avoiding validation errors in required tax submissions. The change also prevents empty-value ledger lines from being reported while keeping related source documents included, improving compliance and report accuracy.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96355 Forward-Port-Of: odoo/enterprise#95804
This fixes a crash that could occur when validating Register Production/Serial from the shop floor if multiple related quality checks existed. Manufacturing users can now complete production validation without being blocked by an unexpected error.
Original PR description
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data…
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data - Go to Quality > Create a new Control point > Product: Table Top > Operations: Manufacturing > Save - Create a new MO > Product: Table Top > Confirm > Shop Floor > Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate - Click on 3 dots > Register Production/Serial > Validate - Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate Traceback: ``ValueError: Expected singleton: quality.check(1, 5)`` https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848 When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``. The code expects only one record, which causes a traceback. sentry-6839419788 Forward-Port-Of: odoo/enterprise#93624
Payroll users can now generate payslips from a pay run without hitting an error. This fixes a broken field reference introduced after work entry dates were simplified, restoring a key payroll processing step for batches with multiple employees.
Original PR description
Steps to reproduce: - In the Payroll app, go to Pay Runs - Select a pay run with several employees in it - Click on "Generate Payslips" - Get a traceback Reason: The function responsible to generate payslips did not get updated when the fields "date_start" and "date_stop" where replaced by "date" in work entries, causing the error. How it was fixed: Changed "date_start" and "date_end" in the condition to "date" Task ID: 5084666 Forward-Port-Of: odoo/enterprise#94919
Rental product prices in the online shop now use the decimal precision configured for the website currency. This prevents public customers from seeing unnecessary decimals, such as showing whole-number currencies with two decimal places.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#96226 Forward-Port-Of: odoo/enterprise#95634
Odoo Studio now correctly handles clearing calendar view settings such as color fields. This prevents crashes when users remove these settings and keeps the calendar editor working smoothly.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This update adjusts how Studio approval rules are checked so they no longer trigger an unnecessary warning in newer database environments. It is an internal cleanup that helps keep system updates and migrations smoother without changing user-facing behavior.
Original PR description
See community change, merge `_method_or_action_not_null` into `_method_or_action_together` to avoid warning. https://github.com/odoo/odoo/pull/229287 https://github.com/odoo/upgrade/pull/8521
Fixed ESG demo data so it no longer depends on accounting records tied to a specific country setup. This prevents errors when loading demo data in fresh databases using non-US fiscal localizations, such as India.
Original PR description
**Note: issue not reproducible in runbot, but in fresh database** **Step to reproduce:** - in fresh database, install esg module - go to setting > invoicing > add india as Fiscal Localization -…
**Note: issue not reproducible in runbot, but in fresh database**
**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data
**Observation:**
- You will receive traceback
```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```
**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628
- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback
**Fix:**
- make demo data independent of any localization
opw-5048417
Forward-Port-Of: odoo/enterprise#94540Mexican electronic invoices will no longer automatically replace a missing invoice date with the current date in the Mexico City timezone when posted. This avoids unexpected mismatches between invoice and due dates and makes invoice behavior more consistent.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041 Forward-Port-Of: odoo/enterprise#96303
Swiss payroll users can once again access Individual Account reports and monthly payroll report menu entries. This restores missing navigation so payroll teams can find and use the expected reports without workarounds.
Original PR description
… menuitems Forward-Port-Of: odoo/enterprise#96162 Forward-Port-Of: odoo/enterprise#95929
The sales planning test tour was failing when run on non-working days because it focused on the current date. This fix changes the test so it selects only valid working dates, improving reliability of automated checks without changing user-facing behavior.
Original PR description
Before this commit, the tour was failing on non-working days as the focused day was the current date. This commit removes the focus on the current date so that only working dates are selected. Additionally, this commit also fixes the formatting issues of the modified file. runbot error 226741 Forward-Port-Of: odoo/enterprise#96239
A missing component was added back to the Spanish reporting setup after a forward-porting oversight. This helps ensure the related accounting return functionality is properly available when the module is initialized.
Original PR description
Little oopsie while fw-porting https://github.com/odoo/enterprise/pull/96106 Forward-Port-Of: odoo/enterprise#96354
Uploaded files added to field service worksheets are now shown correctly when customers view or sign worksheet reports in the portal. This prevents missing attachment information and helps ensure signed reports match the completed worksheet.
Original PR description
Steps to reproduce: ------- - Install industry_fsm_report module - Open FSM app - Select worksheets from settings in the configuration - Go to worksheet templates in the configuration - Create a worksheet template - Click the design template button. You arrive in the studio - Add file field and close it - Create a new task and select a newly created template in the worksheet template - Click the worksheet button in the control panel - Upload a file and save it - Click on the sign report button - Here file field is not visible Issue: ------- The file field is not visible in the worksheet portal. Cause: ------ The view of the file field is not created for the worksheet portal. Solution: ------- Created the view of the file field to display in the worksheet portal. task-3691529 Forward-Port-Of: odoo/enterprise#95970 Forward-Port-Of: odoo/enterprise#56035
Field service project settings now show the correct label for the timesheet product when a customer is selected. This prevents confusion caused by the sales order line label appearing in the wrong place.
Original PR description
Steps to reproduce: - Install the `industry_fsm_sale` module. - Open the FSM app. - Go to Projects. - Open a project’s settings. - Select a customer. Issue: The label for the timesheet product is not displayed. Instead, the label for the sale order line appears on FSM projects. Cause: In the PR, https://github.com/odoo/odoo/pull/128967 changed the project settings form structure by wrapping `sale_line_id` in a `div` and separating its label, breaking the xpath for `timesheet_product_id`. Fix: - Update the XPath for `timesheet_product_id` to target the correct container. - Hide the `sale_line_id` label on FSM projects. task-4581748 Forward-Port-Of: odoo/enterprise#96022
The Belgian 325 form PDF export now shows a helpful message instead of a server error when there are no 281.50 lines to include. This prevents a confusing crash and tells users what information is needed before exporting.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
Chilean electronic delivery guide XML files now show the quantity actually delivered instead of the quantity originally ordered. This prevents mismatches in official DTE documents when a shipment is partially delivered without a backorder.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#93260 Forward-Port-Of: odoo/enterprise#89633
The payroll document generation process now skips payslips that cannot be linked to a valid employee contact. This prevents scheduled PDF generation from failing when an employee's related contact record has been deleted, keeping payroll document automation running smoothly.
Original PR description
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.…
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner. **Prerequisites:** - Ensure HR is enabled in `settings>Documents` **Steps to Reproduce:** 1) Install `documents_hr_payroll` module.(with Demo) 2) Navigate to the Employees App. 3) Select any Employee(e.g Abigail Peterson) and open form view. >- click on **contacts** smart button. >- Delete that Record 4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 5) Activate Developer mode and navigate to schedule Actions. >- Search for 'Payroll: Generate pdfs'. >- Run Manually. Error: `NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint` Root Cause: When the partner is deleted, the value received from `_get_document_partner` at [1] is `False`, which later on tries to create the `documents.access` record for the new document, it fails because no partner is available to assign access rights, resulting in the error. Solution: This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner. [1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 sentry-6814524392 Forward-Port-Of: odoo/enterprise#96191 Forward-Port-Of: odoo/enterprise#92865
German PoS payments are now sent to Fiskaly in the required format, preventing payment validation errors. The update also avoids creating unnecessary zero-value payment lines caused by rounding when multiple decimal payments use the same method.
Original PR description
This ticket fixes two bugs: ### Problem 1 Fiskaly requires `amounts_per_payment_type` values to be strings with 2 to 5 decimal places. After this PR: https://github.com/odoo/enterprise/pull/83300, amounts started being sent as numbers, which caused bad request error when paying a PoS order in version 19.0. ### Solution 1: Restore the use of `.toFixed(2)` to ensure amounts are sent as strings. ### Problem 2 When adding two payment lines with decimal amounts using the same payment method, the system merges both payments into a single line by adding the second amount to the first. This can cause a rounding difference and may trigger sending an additional payment line to Fiskaly with a 0.00 amount. ### Solution 2: Check if rounded change is zero before creating the change line. opw-5115157 Forward-Port-Of: odoo/enterprise#96020
This fixes how Odoo links exchange difference entries when multiple bank reconciliation lines are selected at once. It helps ensure the exchange adjustment is attached to the correct transaction line, reducing the risk of confusing or inaccurate reconciliation records.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id Forward-Port-Of: odoo/enterprise#95620 Forward-Port-Of: odoo/enterprise#94160