Daily updates from Odoo
Friday, March 27, 2026
297 changes
30 changes
Enhancements to existing features
This update adjusts how Odoo handles Indonesian NPWP (tax identification numbers) to accurately reflect whether a business is an individual or a company. The change ensures correct classification based on the NPWP prefix, improving data accuracy for Indonesian accounting and tax reporting. This update aligns with evolving Indonesian regulations regarding company identification.
Original PR description
For Indonesia, NPWP is distinguishable between an individual and company by prefix If an NPWP starts with 001, 002, or 003, treat it as a Company. Anything else is likely an Individual (local or foreign). For Indonesia, NPWP is distinguishable between an individual and company by prefix An NPWP must consist 16 digits How to distinguish between individual and company details: - Individual (Local) -> first two digit is province code start from 11 to 92 - Individual (Expat/Foreign) -> first digit = 0, second and third digit 07-09 - Company (Local or Foreign) -> first digit = 0, second and third digit 01-03 Task [#5915988](https://www.odoo.com/web#model=project.task&id=5915988) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250840
Resolved issues and error corrections
This update fixes a minor issue that prevented users from successfully updating timesheet entries while a timer was running. The fix ensures that the system handles urgent saves properly, preventing an error that would disrupt the timesheet update process. This improves the reliability of timesheet management.
Original PR description
Steps to reproduce: 1. Install `timesheet_grid` 2. Open timesheet and start timer 3. Update any cell by clicking on seach icon. 4. Now after updating go back by clicking "My Timesheet" breadcrumb Issue: - Tracback: `Uncaught Promise > Cannot convert undefined or null to object` Cause: : - The error was occurring because the updateTimerState function in timesheet_timer_service.js was trying to iterate over timerState.data when it was undefined or null. This happens when the list view's urgent save is triggered. Solution: - added a safeguard to updateTimerState so that it simply returns early if timerState.data is empty opw-6018970 Forward-Port-Of: odoo/enterprise#110637
This update resolves an issue where the Customer Ratings form in the Helpdesk reporting module displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the user experience and ensuring data consistency. This improves the clarity and accuracy of customer feedback reporting.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update fixes a problem where users with limited accounting access couldn't validate invoices when audit reports were active. The change ensures invoices can be validated correctly without requiring additional user permissions, improving usability for standard users. This resolves an access error preventing a key business function.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259 Forward-Port-Of: odoo/enterprise#111782
This update addresses a potential issue where automated email verification systems (Mail Defender) could inadvertently cancel or reschedule appointments. To prevent this, the system now uses a form instead of a direct link for cancellation/rescheduling, ensuring these actions are handled correctly. This improves the stability and reliability of our appointment scheduling feature.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#112085 Forward-Port-Of: odoo/enterprise#79831
This update resolves a minor issue in the Belgian payroll module (l10n_be_hr_payroll) related to how termination holiday reports are generated. Specifically, a fallback value was incorrectly handled when certain property settings were missing, preventing accurate reporting. This ensures all termination holiday reports are generated correctly.
Original PR description
Forward-Port-Of: odoo/enterprise#112200
This update resolves a bug where report date filters were not correctly applied, particularly when using custom date ranges. Users could experience reports defaulting to previous periods. The fix simplifies date selection by removing the requirement for a 'custom' period type.
Original PR description
original pr: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 The The original pr forgot to change some values in the options of reports concerning the filter date. This is an issue for example when the report opens by default on previous period. Another way to reproduce is for example to create a working file with very custom dates, for example 1st February to 14 March, then exporting it. Then the date of the options won't be correct. To simplify the process, we don't require the key 'period_type': 'custom' when specifying dates on the options.
This update aligns the user interface of the Sign Now wizard to provide a more consistent experience, regardless of whether the user initiates a signature request through the 'Sign Now' flow or the 'Send Request' option. This enhances usability and reduces confusion for users completing the sign process.
Original PR description
in this commit i alligned the UI of sign send request wizard to look similar for both cases when the user click sign now and when the user click send request (self sign and send request) Task: 5942397
This update resolves an issue where editing a value in a report caused incorrect calculations. The system was incorrectly interpreting data sent from the client, leading to errors when aggregating report lines. This change ensures accurate report calculations after manual value adjustments.
Original PR description
…getting column_group_totals from json Backport of f91e98fe645768db4af590fa4cdfe2ddfe85f888 // Bug The following flow failed: 1) Create a report with 3 lines: - Line 1: using the "domain" engine -…
…getting column_group_totals from json
Backport of f91e98fe645768db4af590fa4cdfe2ddfe85f888
// Bug
The following flow failed:
1) Create a report with 3 lines:
- Line 1: using the "domain" engine
- Line 2: using the "external" engine, with subformula="editable"
- Line 3: an aggregation summing lines 1 and 2
2) Open the report, and edit the amount in line 2
===> Error message, stating Line 1 cannot be evaluated while evaluating Line 3's formula.
// Cause of the issue
When editing a manual value, to avoid recomputing the whole report uselessly, the client sends the column_groups_totals that were computed to render report back to the server. When modifying the external value, that data structure is used to get the results of all other expressions, and reevaluate the aggregations that depend on the modified external value. json is used to send the column_group_totals.
json conversion always forces the keys to be strings. In the past, this was no problem, since the column_group_totals' keys were column group keys, which were also strings server-side. However, https://github.com/odoo/enterprise/commit/ec3581cd759d8c4e03db9e08f6f95546e5724e1f now makes those key indices of a list, hence integers. So, when column_group_totals were sent from the client, they basically were ignored, since none of their keys matched any column group index, causing the bug.This update fixes a problem that prevented users from completing the offer signing process. The issue stemmed from an error in how the system handled empty fields for UAN/PAN/ESIC, causing a duplicate key violation. The fix ensures empty fields are correctly stored as NULL, resolving the error and allowing offer signing to proceed smoothly.
Original PR description
**Version:** master **Issue:** An error occurs during the offer signing process stating that the UAN/PAN/ESIC already exists. **Cause:** When a unique Char field is submitted empty in the salary configurator form, it is stored as an empty string in the database instead of NULL. Since PostgreSQL's unique constraint treats empty strings as real values, any subsequent configurator form opened for a new applicant triggers a duplicate key violation error. **Fix:** Explicitly convert empty unique Char field values to NULL before storing them in the database. **Task-5924388**
This update resolves an issue with how payslips are calculated, specifically related to date and version information. The change eliminates a technical dependency that was causing calculation errors, ensuring accurate payroll processing. This improves the reliability of payroll data.
Original PR description
In this commit, the computes of payslip for the date_to and version_id fields were merged, in order to avoid a circular dependency between them. The date_to field is now computed in the same compute as the version_id, and it is computed based on the date_from and the older schedule of the payslip. (this older schedule is a compromise in order to avoid the circular dependency, as the schedule is needed to compute the date_to, but the schedule itself depends on the version_id). Task-6022151
This update fixes an issue where manufacturing order notes with only images were being hidden in the Shop Floor view. The change ensures that notes containing images or text are now correctly displayed, improving the clarity of information for users.
Original PR description
In the Shop Floor view, manufacturing order notes containing only images were being hidden. The logic was stripping all HTML tags to check for text content; if no text was found, the entire note was treated as empty and returned false. This commit: - Updates `logNote` in `MRPDisplayRecord` to ensure the note is returned if it contains either visible text or an `<img>` tag. task-6048473
This update streamlines the timesheet process by adapting the user tour after a recent change. Now, users won't see validation errors when adding timesheets, and an empty grid view will display a few default lines. This improves usability and prevents tour interruptions.
Original PR description
In this commit: - Timesheet tour was adapted after the timer removal - To avoid blocking the tour: - An employee is automatically generated for the current user when trying to add a timesheet instead of displaying a validation error - My timesheets > few empty lines are displayed when the Grid view is empty task-5925597
This update resolves an error that occurred when users attempted to convert Helpdesk tickets into opportunities. The fix ensures the system correctly handles cases where a ticket lacks a partner email, preventing a technical error and allowing the conversion process to complete successfully. This improves the usability of the CRM.
Original PR description
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. -…
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. - Create a `new ticket`, set only the `ticket name`, and `save` the record. - Click on the `Convert to Opportunity` button. **Error:** `TypeError: 'bool' object is not iterable` After this [recent commit], the system attempts to find the partner using the partner email. Since the helpdesk ticket does not have partner email, False is passed as the email [1]. As result, when retrieving emails based on the ticket record, it returns False, and iterating over it raises the error [3]. This commit ensures that the system attempts to find the partner from the email only if the partner email exists. It also passes the partner email as a list, since _partner_find_from_emails_single expects emails in list format. [recent commit]: https://github.com/odoo/enterprise/commit/41aa34b74f59d48c3ad2fc87a5655866fda968c9 [1]- https://github.com/odoo/enterprise/blob/241b2b0174731558795572d8843d9b184d98e2e0/crm_helpdesk/models/helpdesk_ticket.py#L21 [2]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2050 [3]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2052 sentry-7359614247
This update corrects a technical issue impacting the accuracy of timesheet suggestions. Previously, the system incorrectly used a field for frequency calculations, leading to inaccurate event matching. This fix ensures timesheet suggestions are calculated correctly, improving the overall efficiency of time tracking.
Original PR description
This PR fixes two bugs related to the timesheets assistant, and its recently introduced feature that allows counting event project matching frequency separately from their label. - When saving timesheets from suggestions, we were taking its "Description" field for frequency calculations instead of the "Template" field, which was introduced in this purpose. - The "Template" field was added in the wrong place in the code, causing it to be sent to the back end as a field value when creating timesheets and causing a traceback.
This update resolves an issue where scanning packaging barcodes didn't correctly link to associated lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes are properly recognized and linked to the correct lots during scanning, improving the accuracy of inventory management.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#108666 Forward-Port-Of: odoo/enterprise#98701
This update fixes a problem preventing users from successfully connecting to their databases. Previously, connection attempts were blocked due to access rights issues. Now, users are correctly directed to the database website for connection or login, ensuring seamless access.
Original PR description
The aim of this commit is to allow a db_user to be able to connect to a database in which he should be able to connect. Before this commit: Clicking on connect would stumble upon access rights issues on system.parameter and on `database_api_key_to_use`. After this commit: User are correctly redirected on the db website, either already connected or on the login page. task-id: 6046086 Forward-Port-Of: odoo/enterprise#112081 Forward-Port-Of: odoo/enterprise#111965
This update resolves a technical issue where the signing dialog wasn't consistently sending necessary information. The fix ensures that all required data is correctly transmitted, improving the reliability of the signing process. This prevents potential errors and ensures a smoother experience for users completing the signing workflow.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181
Forward-Port-Of: odoo/enterprise#111786This update fixes an issue where duplicating a product template automatically published it. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior. This prevents accidental product listings and maintains data consistency.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#112063 Forward-Port-Of: odoo/enterprise#111340
This update resolves a technical issue where Web Studio exports were incorrectly formatting property data. The fix ensures that property data is now exported in the correct XML format, improving the reliability of exported configurations. This ensures consistent and accurate exports for users of the Web Studio tool.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update corrects a technical issue preventing a key onboarding tour from running correctly. The fix involved adjusting the company referenced within the tour, resolving a previously unreplicable access rights problem. This ensures new users can successfully complete the referral onboarding process.
Original PR description
Before this commit, the tour `hr_referral_utm_campaign_tour` was failing because of some weird access rights issues. The issue did not seem to be reproducible in local with similar condition. This commit changes the company used in that tour runbot issue 239152 Forward-Port-Of: odoo/enterprise#111805
This update adds a 200% overtime wage type within the Swiss payroll module for Odoo Enterprise. This change ensures accurate compensation calculations for employees working overtime hours, aligning with Swiss tax regulations and reporting requirements. The update improves payroll accuracy and compliance for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly with trimester-based tax periods. The change ensures that report values correctly reflect the appropriate tax period boundaries, preventing incorrect reporting figures. This improves the accuracy of financial data.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111721 Forward-Port-Of: odoo/enterprise#110504
This update fixes an issue where imported invoices from Mexico (CFDI) were not automatically marked as 'public.' Previously, the system incorrectly defaulted to 'private' status. This change ensures that invoices generated as 'public' CFDI documents are correctly recognized and processed during import, improving data accuracy and compliance.
Original PR description
**PROBLEM** When importing a XML to create an invoice, even if the XML is an invoice to public, l10n_mx_edi_cfdi_to_public is False. **STEP TO REPRODUCE** 1. Create an invoice to public, and generate the xml (send with CFDI). 2. Use this xml to upload an new invoice and notice the cfdi to public checkbox is unticked. **NOTE** Previously, there was a [bug](https://www.odoo.com/odoo/my-support-tasks/5911542) where it would always be ticked. opw-5934626 Forward-Port-Of: odoo/enterprise#108287
This update resolves a recurring issue where the Italian Point of Sale (POS) system generated errors when offline, specifically when printing receipts. The fix adds a safety mechanism to gracefully handle network interruptions, preventing tracebacks and ensuring smoother operation for users with the Italian fiscal printer. This improves reliability and prevents disruptions during offline transactions.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#111487 Forward-Port-Of: odoo/enterprise#105515
This update resolves a problem where percentage fields in employee salary calculations were not loading or displaying correctly. The fix ensures accurate salary values are presented, improving the reliability of payroll processing within the Enterprise module. This update primarily impacts how salary percentages are managed.
Original PR description
Forward-Port-Of: odoo/enterprise#110785
This update optimizes the testing process by pre-generating a key asset bundle used by the bus system. Previously, this bundle was rebuilt repeatedly during tests, causing delays. This change significantly speeds up test execution times, improving overall development efficiency.
Original PR description
This commit sets the `bus.websocket_worker_assets` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +900 times with a db "all"). Forward-Port-Of: odoo/odoo#255843
This update optimizes the testing process for the Live Chat module by pre-generating a key asset bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall system stability.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#256149 Forward-Port-Of: odoo/odoo#255847
This update fixes an issue where the 'Buy to Resupply' setting was automatically re-enabled after being manually disabled. The change ensures that this setting remains disabled unless a specific warehouse is actively part of the 'Buy' route, improving order management accuracy and preventing unintended stock replenishment.
Original PR description
Steps to produce: --- - Install `purchase_stock` module. - Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`. - Go to Configuration > Warehouse Management > Warehouses. -…
Steps to produce: --- - Install `purchase_stock` module. - Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`. - Go to Configuration > Warehouse Management > Warehouses. - Open `YourCompany` record. - Click on Routes > open `Buy` > enable `Products`. - Return to `YourCompany` and disable `Buy to Resupply`. Issue: --- - After disabling `Buy to Resupply`, the option is automatically re-enabled. Root cause: --- - In [1], `buy_to_resupply` is set to true if either buy route is product selectable OR the current warehouse is included in buy route warehouses. - In the `_inverse_buy_to_resupply` method, unchecking the flag only unlinks the warehouse from the route. However, if `product_selectable` is still enabled, the compute logic will continue to set the field back to true. Solution: --- - `warehouse.buy_to_resupply` is now set to True only when the warehouse ID is present in the buy route’s warehouse_ids. [1] https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/purchase_stock/models/stock.py#L57 opw-5476302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250360
This update fixes an issue where receipts were displaying company information twice. This change was triggered by a previous update and ensures a consistent and accurate representation of company details on all receipts. It improves the user experience and data accuracy for point-of-sale transactions.
Original PR description
Before this commit, the receipt was showing the company information twice. It happened after the commit https://github.com/odoo/odoo/commit/dca40d16481ba504d608cc65d82e7821e01c5932. opw-6053013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255368
19 changes
Enhancements to existing features
This update improves Odoo's Taiwanese localization by aligning tax settings with local accounting rules and e-invoicing requirements. Key changes include new fiscal positions for VAT exemptions and simplified tax mappings, ensuring accurate reporting and compliance with Taiwanese regulations. The update also corrects a minor labeling error.
Original PR description
This commit improves the Taiwanese localization by refining fiscal positions and their associated tax mappings to better align with local accounting practices and e-invoicing terminology. Key…
This commit improves the Taiwanese localization by refining fiscal positions and their associated tax mappings to better align with local accounting practices and e-invoicing terminology. Key changes: - Updated Chinese translations (`name@zh_TW`) for B2B/B2C fiscal positions to explicitly include e-invoices (電子發票). - Added a new fiscal position for VAT Exempt (`l10n_tw_fiscal_position_vat_exempt`). - Removed redundant purchase-specific fiscal positions (Unified Invoices, Duplicate/Triplicate Cash Register) and Deemed Sales. - Remapped purchase taxes to standard B2B/B2C fiscal positions to simplify the fiscal position structure. - Updated `original_tax_ids` and `fiscal_position_ids` across sales and purchase taxes to reflect the consolidated fiscal positions. - Fixed a typo in the invoice label for the "2% ART 11 GBRT" tax (changed "25" to "2%"). Task-6007589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254826
Resolved issues and error corrections
This update resolves an issue where the Customer Ratings reporting form in Helpdesk displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving data clarity. This ensures a consistent and accurate user experience.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update resolves an issue where users with limited access (Invoicing Users) were encountering errors when validating invoices while audit reports were present. The fix ensures proper invoice validation functionality without requiring additional user permissions, improving usability for all users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259 Forward-Port-Of: odoo/enterprise#111782
This update resolves a recurring error that occurred when the POS system in Italy (l10n_it_pos) lost its internet connection. By adding a safety mechanism to handle offline printing attempts, the system now gracefully manages errors instead of crashing, ensuring smoother transactions for Italian retailers.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#111487 Forward-Port-Of: odoo/enterprise#105515
This update resolves an issue where discounts weren't correctly processed in the self-order point-of-sale flow. The fix ensures that discount information is properly handled, preventing errors and ensuring accurate order totals. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update fixes an issue where audit reports weren't using the correct company-specific account report variants. Now, when creating an audit report in the Denmark localization, the system will automatically load the correct balance sheet report, ensuring accurate financial reporting for Danish businesses. This improves the reliability of financial data generated within the system.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886 Forward-Port-Of: odoo/enterprise#101377
This update resolves a technical issue where the signing dialog wasn't reliably sending necessary information. The fix ensures that the correct data is consistently transmitted to the controller, improving the stability and functionality of the signing process. This prevents potential errors and ensures a smoother experience for users.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181
Forward-Port-Of: odoo/enterprise#111786This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency and reduces potential errors.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#112063 Forward-Port-Of: odoo/enterprise#111340
This update resolves an issue where Web Studio exports were incorrectly formatting property data. The fix ensures that properties are exported in the correct XML record format, improving the reliability and accuracy of exported configurations. This enhances the overall usability of Web Studio for users.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update adds a 200% overtime wage type within the Swiss payroll module for Odoo Enterprise. This change aligns with Swiss tax regulations and ensures accurate payroll calculations for employees working overtime hours. It improves compliance and reporting accuracy for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing users from seeing important communication details. Now, the portal displays a 'View Document' option for canceled requests, mirroring the experience for completed requests.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#110974
This update fixes an issue where payslips for UAE employees with attendance-based work entries were incorrectly calculating hourly wages due to a technical error in how worked days were tracked. The change ensures accurate wage calculations, particularly when processing paid leave, by using the correct record object within the calculation process. This improves payroll accuracy for UAE employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#112098 Forward-Port-Of: odoo/enterprise#111280
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly when using trimester tax periods. The fix ensures correct period boundaries are used, preventing incorrect report values and improving the reliability of tax reporting data. This impacts financial reporting accuracy.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111721 Forward-Port-Of: odoo/enterprise#110504
This update fixes an issue where XML invoices for public CFDI documents weren't correctly marked as 'public' during import. Previously, the system incorrectly defaulted to 'private'. Now, the system automatically identifies and processes invoices to public CFDI standards, ensuring accurate invoice creation and reporting.
Original PR description
**PROBLEM** When importing a XML to create an invoice, even if the XML is an invoice to public, l10n_mx_edi_cfdi_to_public is False. **STEP TO REPRODUCE** 1. Create an invoice to public, and generate the xml (send with CFDI). 2. Use this xml to upload an new invoice and notice the cfdi to public checkbox is unticked. **NOTE** Previously, there was a [bug](https://www.odoo.com/odoo/my-support-tasks/5911542) where it would always be ticked. opw-5934626 Forward-Port-Of: odoo/enterprise#108287
This update resolves an issue where timesheet updates wouldn't consistently save while a timer was running. The fix prevents a technical error that occurred when the timesheet was navigated away from, ensuring timesheet entries are reliably saved and updated.
Original PR description
Steps to reproduce: 1. Install `timesheet_grid` 2. Open timesheet and start timer 3. Update any cell by clicking on seach icon. 4. Now after updating go back by clicking "My Timesheet" breadcrumb Issue: - Tracback: `Uncaught Promise > Cannot convert undefined or null to object` Cause: : - The error was occurring because the updateTimerState function in timesheet_timer_service.js was trying to iterate over timerState.data when it was undefined or null. This happens when the list view's urgent save is triggered. Solution: - added a safeguard to updateTimerState so that it simply returns early if timerState.data is empty opw-6018970 Forward-Port-Of: odoo/enterprise#110637
This update improves how Odoo handles Indonesian NPWP (tax identification numbers) by correctly classifying them as either individual or company based on the leading digit. This ensures accurate tax reporting and compliance in Indonesia, aligning with the latest regulations regarding company type identification.
Original PR description
For Indonesia, NPWP is distinguishable between an individual and company by prefix If an NPWP starts with 001, 002, or 003, treat it as a Company. Anything else is likely an Individual (local or foreign). For Indonesia, NPWP is distinguishable between an individual and company by prefix An NPWP must consist 16 digits How to distinguish between individual and company details: - Individual (Local) -> first two digit is province code start from 11 to 92 - Individual (Expat/Foreign) -> first digit = 0, second and third digit 07-09 - Company (Local or Foreign) -> first digit = 0, second and third digit 01-03 Task [#5915988](https://www.odoo.com/web#model=project.task&id=5915988) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoice quantities were incorrectly calculated when using timesheets for sales orders. The system was adding timesheet hours directly to the invoice line instead of converting them to the Sale Order line's unit of measure (Days). This change ensures invoices accurately reflect the time spent on the order, providing correct quantity calculations.
Original PR description
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm…
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm the quotation and click on the smart button Recorded. 4. Record 16 hours of timesheets. 5. Create an invoice using a timesheet period (starting from SO date) 6. Check the invoice quantity Issue: ----------- The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours). Cause: ----------- After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied. Solution: --------------- Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice. opw-6024804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255790 Forward-Port-Of: odoo/odoo#254273
This update allows users to easily re-upload files within the link popover without needing to manually delete the previous URL. Previously, users were required to remove the old URL before adding a new file, which was a cumbersome process. This change simplifies the file upload experience and improves usability.
Original PR description
Specification: - When a user uploads a file in the link popover, user can not re-upload another file without manually removing previous URL. <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/9e67535a-22a1-4d41-808d-a91d07593251" /> <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/92a33d8c-a325-4979-9956-42e81b369bd7" /> After this commit: - This commit allows user to re-upload a file without removing previously generated URL first. - TL;DR : upload button won't disappear. task-5470111 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247552
This update fixes an issue where discount popups displayed incorrect default discount values. Previously, the way decimal separators were handled caused problems when users clicked the discount button without manually changing the value. Now, the discount popup correctly formats the starting value, ensuring accurate discount calculations.
Original PR description
Before this commit, if the decimal separator was different than the dot, the starting value of the discount was not correctly formatted in the discount popup. This caused incorrect default discount values to be applied when the user clicked on the discount button without changing the value. opw-6018555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253848
9 changes
Resolved issues and error corrections
This update resolves a technical issue where the AI system incorrectly identified the current user as a potential correspondent. The fix prevents this misconfiguration, ensuring accurate AI interactions and improving the reliability of the system. This change focuses on internal AI processes.
Original PR description
The fallback logic in computeCorrespondent was unintentionally allowing cases where the current user could be returned as the correspondent for AI.
This update resolves an issue where planning slots were unexpectedly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, preventing unnecessary planning entries and improving the accuracy of rental order scheduling. This change impacts the rental planning process.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012
This update corrects an issue where Web Studio exports were incorrectly formatting property data. The fix ensures that properties are exported in the correct XML format, improving the reliability and accuracy of exported configurations. This resolves a technical problem that could have impacted the ability to properly recreate Web Studio setups.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update fixes an issue where the XML generated for Mexican invoices wasn't correctly incorporating the issued address's zip code. Previously, the zip code was not being populated in the 'LugarExpedicion' field, which is a required data element for Mexican tax compliance. This change ensures accurate invoice data for tax reporting.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#112107 Forward-Port-Of: odoo/enterprise#108732
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise system. Specifically, it adds a 200% overtime wage type, aligning with Swiss labor regulations and ensuring accurate payroll processing for employees working overtime. This change improves compliance and reporting accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update resolves an issue where tax lines within the bank reconciliation widget couldn't be manually unmatched when the related tax account was set to 'reconcilable'. Previously, this prevented users from correctly reconciling transactions. Now, users can unmatch these tax lines, ensuring accurate bank reconciliation and tax reporting.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#110186
This update resolves a crash issue in tax reports when a report lacks a defined return type. The fix ensures reports automatically fall back to the company's tax periodicity, providing greater stability and reliability for financial reporting. This change addresses a previously identified bug related to date scope calculations.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111796
This update corrects a technical issue related to how international payment data (QR-IBANs) is processed for creditor accounts. The fix ensures that QR-IBANs are correctly categorized, aligning with industry standards and preventing potential payment rejection by banks. This improves the reliability of international payment processing.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301
This update fixes an issue where rental shifts remained in 'draft' status after confirming a rental order. The fix automatically updates the shift status to 'published' upon order creation, ensuring accurate tracking and consistency with other order actions. This improves the reliability of rental planning workflows.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839
10 changes
Enhancements to existing features
This update incorporates changes to Odoo's tax calculations to align with the Income Tax Bill 2025. Specifically, it adds support for new TDS and TCS taxes and sections as defined in the Act, ensuring compliance with the latest regulations for Indian businesses. Existing tax configurations have been updated and deactivated.
Original PR description
The Income Tax Bill 2025 introduces TDS and TCS provisions in a more structured way compared to the existing Income-tax Act 1961, with the addition of new sections and taxes. This commit adds new sections and corresponding taxes for sections 392, 393, and 394, along with their respective reports. It also introduces new TDS and TCS tax groups for these taxes to differentiate them from the existing ones. The old taxes are deactivated as they are no longer applicable. task-6035844 Forward-Port-Of: odoo/odoo#256102
Resolved issues and error corrections
This update ensures the HTML editor's testing environment consistently uses the Roboto font. Previously, variations in font settings could cause test failures. This change improves the reliability of our tests and guarantees a uniform user experience for the HTML editor.
Original PR description
Purpose of this PR: - Explicitly load Roboto using FontFace in indent.test.js to avoid fallback fonts (e.g. Ubuntu) across environments. This ensures consistent rendering and prevents flaky failures caused by font-dependent computed values. task-5916115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet library used within Odoo. The changes address several bugs and performance improvements related to how spreadsheets are rendered and exported, specifically focusing on Excel compatibility and data handling. This ensures consistent and reliable spreadsheet functionality across the Odoo platform.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/778fcde50a [REL] 18.3.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/778fcde50a [REL] 18.3.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cf46880a22 [FIX] grid_renderer_store: keep wrapping width with explicit align [Task: 6032407](https://www.odoo.com/odoo/2328/tasks/6032407) https://github.com/odoo/o-spreadsheet/commit/fcf19a9283 [FIX] functions: stop debugging context [Task: 6052128](https://www.odoo.com/odoo/2328/tasks/6052128) https://github.com/odoo/o-spreadsheet/commit/c0a274790c [FIX] config: fix release flow [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9cba5f14d8 [FIX] SheetView: dirtify sheet viewport at UPDATE_CELL [Task: 5953775](https://www.odoo.com/odoo/2328/tasks/5953775) https://github.com/odoo/o-spreadsheet/commit/9fb65d6112 [FIX] xlsx: do not export dynamic tables to excel [Task: 5214240](https://www.odoo.com/odoo/2328/tasks/5214240) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update modifies the Swiss payroll module to include a 200% overtime wage type, aligning with Swiss tax regulations. This change ensures accurate reporting of overtime earnings for employees in Switzerland, improving compliance and financial reporting. The update was implemented as a bug fix to address a specific requirement.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes an issue where Odoo's translation caching wasn't working correctly when related fields were updated. Specifically, when a translated field changes, dependent fields relying on that translation were sometimes recomputed with the wrong language setting. This change ensures translations remain cached, improving performance and accuracy when working with multi-language data.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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#256207 Forward-Port-Of: odoo/odoo#256111
This update resolves an issue where the HTML editor would unexpectedly scroll to the top when the command palette was closed. The fix ensures the editor's selection is maintained, preventing a disruptive user experience. This is a related follow-up to a previous fix and avoids impacting core UI components.
Original PR description
Before this commit: the editable area scrolls to the top when the command palette is closed by clicking the gray zone After this commit: we override the focus function of the editable and use focusEditable instead, which keeps the selection. Note it's a succession fix of https://github.com/odoo/odoo/pull/250624 and both of them are a workaround without touching the ui_service and command palette. Also added super.destroy() in the previous fix till 18.4. task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253638
This update fixes an issue where invoices with 0% taxes incorrectly displayed "Not subject to VAT" in XML reports, violating ZATCA standards. The changes add support for zero-rated and exempt taxes, ensuring accurate VAT reporting and compliance, while maintaining compatibility with existing 0% tax configurations.
Original PR description
Issue: - The field `l10n_sa_exemption_reason_code` was not mapped for zero-rated, zero-rated export, and exempt taxes. - As a result, invoices using 0% taxes incorrectly showed "Not subject to VAT" in the XML, which misrepresented the actual nature of the supply. Imp: - Added new zero-rated and exempt taxes with proper ZATCA/UN CEFACT codes. - Kept legacy 0% taxes unchanged for backward compatibility. - Added Invoice Legal notes to make exemption reason visible in pdf also. - Improved error spacing and removed redundant comma text. Impact: - Ensures full compliance with ZATCA XML standards. - Prevents misleading VAT data representation. Backport of https://github.com/odoo/odoo/pull/234096 taskID-5494997 Forward-Port-Of: odoo/odoo#255922 Forward-Port-Of: odoo/odoo#244656
This update corrects a bug where loyalty programs weren't functioning correctly when pricelists were disabled. Previously, loyalty points continued to accumulate even when a program was restricted to a specific pricelist. This change ensures accurate point tracking and rewards for customers regardless of pricelist settings.
Original PR description
When `use_pricelist` is disabled, `available_pricelist_ids` retains previously configured pricelists. This caused loyalty programs restricted to a specific pricelist to still match and accumulate points incorrectly. opw-5952960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253865 Forward-Port-Of: odoo/odoo#252718
This update fixes a technical issue related to international payments (ISO 20022). Specifically, it ensures QR-IBANs are correctly handled within creditor accounts, aligning with documentation standards. This improves the reliability of payment processing and avoids potential bank rejection issues.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301
A technical issue with how Odoo processed spreadsheet data was causing errors. This fix removes a trailing character from JSON files before they're used, ensuring proper data handling and preventing the spreadsheet from failing. This improves the reliability of the Sales Commission spreadsheet.
Original PR description
Steps to reproduce: - Share the Sales Commission spreadsheet - Open the shared link ⮕ traceback This was caused by the trailing line break in the json, so the last character was not a `}`. Task: 6064328 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#255523
4 changes
Resolved issues and error corrections
This update resolves an issue where confirming quantities of archived products through the barcode app would trigger an error. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality. This improves the usability of the barcode app for all product types.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise module. It adds a new wage type allowing for 200% overtime pay, ensuring accurate Swiss tax and social security reporting (ELM). This change aligns with Swiss labor regulations and improves payroll accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The fix allows for flexibility in handling tax lines across mixed vehicle and non-vehicle expense lines, ensuring accurate reporting. This improves the reliability of the tax reporting process.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#110616
This update corrects a technical error related to how QR-IBANs are processed in international payments. Specifically, it ensures QR-IBANs are correctly placed within the account structure as required by banking standards. This resolves a potential issue that could have caused payment failures.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301
15 changes
Resolved issues and error corrections
This update resolves an issue where changes to lot IDs on stock move lines were failing due to an outdated data assignment method. The change utilizes a more reliable technique to link records to the Many2many field, ensuring correct lot ID updates and preventing errors. This improves the stability of the stock management process.
Original PR description
Since ce2a8f9c929, quality.check.lot_id (Many2one) was changed to lot_ids (Many2many), but the write() override in stock.move.line still assigns a raw integer to the field. This causes a ValueError when changing the lot on an MO move line. With this commit, use Command.link() to properly link the record to the Many2many field.
This update fixes an issue where selected failure locations weren't being applied during product repairs. Now, when a quality check fails in a repair order, the product is automatically moved to the user-specified failure location, ensuring accurate inventory and streamlining the repair process. This improves data integrity and operational efficiency.
Original PR description
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not…
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not being set at the final product move. - Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process. Steps to reproduce: ------------------------- 1. Install the quality_repair module. 2. In Quality, create a Control Point with: - Type = Pass-Fail - Control Per = Product or Operation - Set at least 1 Failure Location 3. Create a Repair Order for any product and start the repair process. 4. Perform a quality check, set it to Fail, and select a failure location. 5. Open the product moves, the destination location does not match the selected failure location. Cause of the issue: ------------------------- The failure location was not correctly assigned when a quality check failed during the repair process because _move_to_failure_location determines the destination location based on a stock picking (for receipts) or a production_id (for manufacturing). In the Repair module, however, quality checks are linked to a repair order, so the selected failure location was not set correctly. After this commit: ----------------------- - When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user. - This ensures that, upon completion of the repair, the product is moved to the selected failure location, maintaining accurate inventory tracking and management. Task ID:5254334
This update fixes an issue where long product names in the Master Production Schedule would cause other schedule columns to disappear. The fix wraps long product names within the display to ensure all schedule elements are visible, regardless of product name length. This improves usability and prevents data loss.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088
This update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through the system, preventing errors and guaranteeing accurate discount calculations during self-order transactions. This improves the reliability of the POS system.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update resolves an issue where the Customer Ratings reporting form in Helpdesk displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures consistent and accurate reporting on customer feedback.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update corrects a technical error related to international payment processing (ISO 20022). Specifically, it ensures QR-IBANs are correctly formatted within creditor accounts, aligning with industry standards and preventing potential payment rejections. This improves the reliability of international transactions.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301
This update fixes an issue where quarterly VAT returns in the Italian tax reports didn't automatically generate the necessary XML files. The fix correctly uses the 'date_to' field for quarter detection, ensuring accurate XML generation and download. This resolves a critical functionality gap for Italian businesses using the Enterprise module.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#108548
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format in web_studio. The fix prevents the system from trying to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#112053 Forward-Port-Of: odoo/enterprise#88613
This update fixes a calculation error in payslips for employees using the UAE Monthly pay structure, specifically when paid leave is involved. The change ensures that worked days are accurately considered for each employee, preventing incorrect wage calculations. This improves payroll accuracy for UAE-based staff.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#112098 Forward-Port-Of: odoo/enterprise#111280
This update resolves an issue preventing SBR tax reports from being submitted due to incorrect date formatting and overly long consultant information. The commit restores the original date format and simplifies the consultant name to ensure compliance with validation requirements, allowing reports to successfully pass the necessary checks.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update resolves a technical issue causing AI conversations to incorrectly loop and display an OOO banner. The fix clears the AI conversation correspondent when it matches the current user, ensuring proper agent flows are maintained while preventing self-chat issues. This improves the overall AI app experience for users.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112003 Forward-Port-Of: odoo/enterprise#111736
This update resolves a problem where Web Studio exports were incorrectly formatting property data. The fix ensures that property data is now exported in the correct XML format, improving the reliability and accuracy of exported configurations. This prevents potential errors when importing these configurations back into Odoo.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update fixes an issue where quality control moves weren't correctly splitting stock quantities when a partial failure occurred. Previously, the system incorrectly divided the failed quantity, leading to inaccurate stock tracking. This change ensures that failed quantities are properly split into new stock moves with the correct quantity values, improving inventory accuracy.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#112209 Forward-Port-Of: odoo/enterprise#107493
This update adds a 200% overtime wage type within the Swiss payroll module for Odoo Enterprise. This change ensures accurate compensation calculations for employees working overtime hours, aligning with Swiss labor regulations. The update improves payroll accuracy and compliance for businesses using the Odoo Enterprise solution in Switzerland.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes a crash in tax reports when a return type isn't linked. It now automatically falls back to the company's tax periodicity, ensuring reports open reliably. The change also addresses a previous issue with multiple return types, only raising an error if they have different periodicities.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111796
10 changes
Resolved issues and error corrections
This update corrects a calculation error in the bank reconciliation widget's tax handling. Previously, RC taxes were incorrectly calculated as 'price included' leading to inaccurate tax amounts. This fix ensures RC taxes are calculated correctly, resulting in the expected tax amount of $25.00 for transactions.
Original PR description
Currently, when we add a tax in the manual operations tab of the bank reconciliation widget, tax computation will be forced as price included. The computation reverts to price excluded when altering the amount. Steps to reproduce: - Create a Statement line of 1000$ - In the Writeoff add 2.5% RC tax - Check created tax lines Issue: Adding a 2.5% RC tax gives 24.39 instead of 25.00 opw-5039386
This update resolves a bug that occurred when creating contracts with working schedules that had zero hours. The issue caused a calculation error (division by zero) during wage computation. This fix ensures accurate wage calculations for employees with zero-hour schedules, preventing the error and improving payroll reliability.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930
This update adds a 200% overtime wage type within the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). This change ensures accurate reporting of overtime compensation to tax authorities in Switzerland, complying with local regulations. It corrects a previous limitation and improves payroll accuracy for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update resolves an issue preventing the export of Profit & Loss reports with footnotes enabled for the l10n_lu_reports module. The fix corrects a dependency on an outdated model, ensuring proper XML generation and report functionality. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#107765
This update resolves an issue where QR-IBANs were incorrectly processed for creditor accounts. The fix ensures QR-IBANs are handled according to documentation, aligning with best practices for payment processing and preventing potential bank rejection errors. This improves the reliability of our payment integrations.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank).
This pull request removes a context dependency within the quality control module. A previous change needed to be reverted due to issues on the OC side. This change ensures the quality control functionality operates consistently without relying on specific contextual data, improving stability.
Original PR description
Commit [1] must be reverted, cf commit OC side [1] 690293e3daae7ac393e93df1976c2c8364dbe0e0
This update resolves a problem where the Settings app stopped working after uninstalling the `hr_recruitment_extract` module. The fix ensures that if one module is removed, its dependency on another module is also handled, preventing errors and maintaining app functionality. This improves stability and user experience.
Original PR description
Consider the following scenario: 1. User installs the `hr_recruitment_integration_monster` module. 2. User can access the Settings app just fine. 3. User uninstalls the `hr_recruitment_extract` module. 4. User can no longer access the Settings app due to a view rendering error. This is because a view in the `hr_recruitment_integration_monster` module depends explicitly on an XPath introduced by the `hr_recruitment_extract` module. When the latter is uninstalled, the view in the former module becomes invalid, causing a rendering error in the Settings app. This commit makes the module dependency explicit in the manifest so that if the `hr_recruitment_extract` module is uninstalled, the `hr_recruitment_integration_monster` module will also be uninstalled.
This update resolves an issue where the Master Production Schedule (MPS) wasn't properly considering safety stock levels for indirect demand. The change ensures that demand forecasts accurately reflect the need to buffer against potential supply disruptions, improving production planning accuracy. This primarily impacts how the system calculates and schedules production for components.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838
This update fixes an issue where Odoo's translation caching wasn't working correctly when related translated fields were updated. Now, when a translated field changes, dependent calculations using that field's translation will continue to use the existing cached translation, improving performance and ensuring accurate translations across different languages. This enhances the user experience by reducing unnecessary processing.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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#256111
This update streamlines the testing process for the Live Chat module by pre-generating a key asset bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall system stability.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#255847
3 changes
Resolved issues and error corrections
This update adds a new overtime wage type (200%) to the Swiss payroll module, aligning with local regulations. This change ensures accurate calculation and reporting of overtime compensation for employees in Switzerland, improving payroll compliance. The update impacts the calculation of Swiss payrolls.
This update resolves a test failure related to calculating AVS deductions in version 17. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating dates in 2027. By adjusting the test's time setting to 2026-02-28, the test now passes reliably.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940This update fixes an issue where Chrome logs weren't captured during shutdowns, and also addressed inconsistent logging behavior due to Chrome's buffering. The changes now ensure all Chrome errors are logged and make the shutdown process more reliable by handling potential issues with Chrome and its data directory.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256061