Wednesday, March 11, 2026
30 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits could occur before the field was correctly marked as dirty, preventing users from seeing updates. This fix ensures that the HTML editor accurately tracks changes and updates the FormStatusIndicator correctly.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#252655
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that skills are correctly copied to new appraisals, regardless of how they're initially created, improving appraisal accuracy. This impacts users relying on the system's appraisal scheduling.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110013 Forward-Port-Of: odoo/enterprise#107760
This update ensures invoices are generated correctly by only using bank accounts that allow outgoing payments. Previously, errors could occur if the selected bank wasn't valid. Now, the system prioritizes customer and payment journal banks, preventing invoice generation failures and improving overall transaction reliability.
Original PR description
Before this commit: --- - Invoice generation could fail when the selected partner or company bank did not allow outgoing payments. - The first available bank account was used without checking whether it was valid for out payments. After this commit: --- - Select only bank accounts that allow outgoing payments. - Prioritize customer banks for refunds, then payment journal banks, and finally company banks as fallback. - Prevent errors caused by untrusted or unsupported bank accounts. task-5954530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251526 Forward-Port-Of: odoo/odoo#250062
This update resolves an issue preventing barcode scanning of product packaging when a product doesn't have a barcode defined. The fix ensures that the system now searches for the product when a barcode is scanned on packaging, allowing for seamless barcode scanning functionality within the Point of Sale module. This improves the user experience and accuracy of sales transactions.
Original PR description
Step to reproduce - Create a product - Add two attributes: 1. One with Instantly creation mode 2. One with Never creation mode - Define packaging from the Sales tab - Add a barcode on the variant packaging ex: 111356,11357 - Scan the packaging barcode in POS Observation: - we get a traceback `TypeError: Cannot read properties of undefined (reading 'product_template_attribute_value_ids')` Cause: - when we do not have barcode on product, when opening `openConfigurator` - (as we have few varianst) product get undefined. https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/point_of_sale/static/src/app/services/pos_store.js#L738 - Hence the traceback Fix: - For the case, when packaging has barcode but not the product, we search for product in that case too. opw-5886570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248838
This update fixes an issue where refund payments in Point of Sale were incorrectly created as 'inbound' instead of 'outbound'. When processing refunds with the 'Identify Customer on the Card' payment method, this change ensures accurate payment record creation, improving financial reporting and reconciliation within the invoicing system. The fix was implemented to address a specific workflow and is considered a minor improvement.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247760
This update corrects a previous issue where users with the invoicing & banks role were restricted from accessing certain transaction features. The change ensures these users have the necessary permissions to manage duplicate and missing transactions, improving their ability to utilize core accounting functionality. This resolves a prior limitation and maintains consistent access for key user groups.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update fixes an issue where landed cost accounting wasn't correctly accounting for stock already in transit for subcontracted products. The fix ensures that the appropriate account move lines are created to accurately reflect the value of received goods, resolving discrepancies in inventory valuation. This improves the accuracy of financial reporting for subcontracted operations.
Original PR description
…lues landed cost sbc **Problem:** account move line created from a landed cost on a subcontracted receipt do not take into account already out quantity. **Steps to reproduce:** - create a tracked…
…lues landed cost sbc **Problem:** account move line created from a landed cost on a subcontracted receipt do not take into account already out quantity. **Steps to reproduce:** - create a tracked product with avco auto category - create a subcontracted bom for this product with no comp - create and confirm a PO for 10 unit of this product with the same partner as the subcontractor of the bom - validate the receipt - create and validate a delivery for 4 unit of your product - navigate to inventory/operations/adjustments/landed costs - create a new landed cost - select the receipt from the PO - add a landed cost of 10$ and validate - select the valuation smart button - a 6$ svl was created (which is correct because 6 out 10 products of the receipt are still in stock) - click on the book widget to open the account move view **Current behavior:** Only two account move lines were created both with a value of 10 One crediting sotck interim received On debiting stock valuation **Expected behavior:** 4 extra account move lines (all with a value of 4) should have been created to compensate the out quantity like it is the case for non subcontracted product. One debiting stock interim delivered One crediting stock valuation One debiting expenses One crediting stock interim delivered **Cause of the issue:** _is_in() will return false for the move of a subcontracted receipt https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185 This is wanted and happens because _should_be_valued() will return true when called on the subcontracted location https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_account/models/stock_move.py#L129 As a consequence, qty_out stays 0 https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185-L186 and we do not append the values for the extra amls inside _create_account_move_line() https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L465-L466 **fix:** if we make sure the the adjustment line is linked to the move of the MO instead of the move of the receipt, this problem does not happen because _is_in() returns true for the move of the MO. Also in this case we don't need _get_stock_valuation_layer_ids() which was introduced by this PR https://github.com/odoo/odoo/pull/166107 to solve the same issue. That is because the move used in button_validate is the move linked to the adjustment line, which will, after this fix, be the one of the MO, so we can directly take its stock valuation layers. opw-5723126 Forward-Port-Of: odoo/odoo#251972 Forward-Port-Of: odoo/odoo#248231
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a problem where date formats like '2500/1222' were mistakenly identified as '%Y.%m.%d'. This ensures that import files with various date formats are processed accurately, preventing import errors and data inconsistencies.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update corrects a bug that caused incorrect currency conversions during batch payment reconciliation in foreign currency journals. Specifically, when reconciling bank statements, the system was using the wrong currency for calculations, leading to inaccurate balances. This fix ensures accurate currency conversions for a more reliable reconciliation process.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218
This update resolves an issue in the Odoo Report Editor where certain field types were not correctly supported. The change prevents users from attempting to select fields with properties through the /field command, aligning with how properties are handled in other report elements. This ensures more reliable report generation.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime in Ecuador from being properly processed. The fix ensures the system recognizes only the approved string value for this regime, resolving a validation error during the electronic signing process. This ensures compliance with SRI specifications and proper invoice generation.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update fixes an issue where selecting an office on the Jobs page would remove the previously applied country filter. The fix ensures that country filters remain active and functional when users select offices, improving the user experience for job searches. This change was made to ensure accurate filtering results.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252477
This update resolves an issue that occurred when users attempted to remove a company association from an expense record. The fix ensures the system handles company removal gracefully, preventing a technical error that could disrupt expense management. This improves the reliability of the expense tracking process.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update resolves an issue where changing the note on a food item after a quantity update would cause an error. The fix ensures that the note update process works reliably, preventing disruptions in order management within the POS system. This improves the overall user experience for restaurant staff.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#104889
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant information to ensure compliance with regulations, preventing invoice submission errors. This ensures seamless integration with Peppol networks for Danish businesses.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update removes an unnecessary check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now reachable through a websocket, this redundant step has been removed, streamlining the process. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
This update fixes an issue where sandwich leave durations were incorrectly calculated when public holidays were involved. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing accurate leave duration calculations for employees. This improves the reliability of leave management.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#252466
This change corrects a typo in the XML format used when sending debit notes to the Italian SDI (electronic reporting system). The original error caused debit notes to be rejected, preventing accurate tax reporting. The fix updates a field name to ensure compliance with the required XML structure.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252272
Forward-Port-Of: odoo/odoo#249284A recent issue causing Distro builds to fail during the quality control tour has been resolved. The fix increases a delay in the tour process to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing environment.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio interface, leading to a validation error. The fix prevents this conflicting input, ensuring date range fields function as expected and improving data accuracy. This change impacts the usability of date-based fields in project configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a problem in the Odoo stock module where error messages about package consistency were unclear. Now, the messages specifically identify the problematic package, allowing users to quickly diagnose and resolve issues, especially during large product transfers. This improves efficiency and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by converting it to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and reducing manual adjustments. This improves data accuracy and efficiency for invoice processing.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#251948
Forward-Port-Of: odoo/odoo#251419This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (specifically, 2 payments instead of 4). This change improves the user experience by providing accurate information about the payment schedule. Additionally, the 'group payment' button is now correctly hidden when necessary.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing under certain circumstances has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where event tickets in the POS were not correctly calculating prices. Now, ticket prices will dynamically adjust based on the event's price or a linked pricelist, ensuring accurate pricing for event attendees. This improves the POS experience and prevents discrepancies in ticket costs.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when generating lots without a defined sequence. The fix ensures the system handles cases where the lot sequence is initially empty, preventing a critical error and allowing users to correctly generate lot numbers. This improves the reliability of inventory management.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a bug in how scrap quantities are calculated for products. Previously, if a product didn't have a related Bill of Materials, the calculation would stop, leading to incorrect scrap quantities being reported. Now, all products are correctly processed, ensuring accurate scrap tracking.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When 'Create Backorder' is always enabled, a process triggered a duplicate labour entry. The fix ensures labour costs are only recorded once per workorder time, preventing inaccurate financial reporting.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 --- Forward-Port-Of: odoo/odoo#250237