Daily updates from Odoo
Monday, June 8, 2026
236 changes
23 changes
Resolved issues and error corrections
This update ensures that all date references within the stock accounting module consistently use Odoo's standard date format. Previously, the system relied on the user's device settings, which could lead to inconsistencies in reports and data. This change improves data accuracy and reliability for financial reporting.
Original PR description
Why this Commit: --- toLocaleString() relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format,the toLocaleString() usages should be replaced to ensure consistency. After this commit: --- <img width="1884" height="363" alt="image" src="https://github.com/user-attachments/assets/8cee2d86-10dc-48d7-8c3a-369ec257c101" /> date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259651
This update resolves an issue that prevented successful testing of duplicated databases for the l10n_de_pos_cert module. Specifically, the commit removes `client_id` and `tss_id` during database duplication, allowing for proper testing in neutralized environments. This ensures consistent and reliable testing of the German POS certification functionality.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update resolves an issue where kit products were incorrectly included in inventory valuation reports. The fix ensures that kit product quantities are accurately displayed in the inventory history report, preventing inflated inventory values. This improves the accuracy of stock valuation calculations.
Original PR description
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo…
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo data. * Create a product with inventory tracking enabled. * Create a BoM of type kit for that product. * Add component products with a defined cost and on-hand quantity greater than 0 to the BoM. * Recompute the kit product’s cost from its BoM on the product page. * Go to Inventory > Reporting > Stock > Inventory at date > Confirm ## Observed Behavior: Even though kits do not appear on stock valuation they still do appear the inventory history report. **Why kits should not appear on inventory history** For example, consider a kit product called 'Computer' that is composed of the following components: | Product | Quantity | Cost | |--------|--------|--------| | CPU | 1 | $300 | | Motherboard | 1 | $300 | The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value at that particular date as $1,200, which is incorrect because it is counting both the kit and its components ## Root cause: This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm. At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear. **Why doesn’t this issue occur in the normal stock view?** Because the domain is overridden at [2] to explicitly exclude kit products from the stock view. However, the quantity history report does not apply this same domain override, so kit products continue to appear there. [1]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166 ## Solution: To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered. This can be achieved by modifying and overriding the domain to explicitly exclude kit products. This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835). opw-6164547 Forward-Port-Of: odoo/odoo#262185
The configurator was incorrectly inflating the extra price of products, causing inaccurate sales order calculations. This fix prevents the configurator from repeatedly modifying the product price when reopened. The issue stemmed from a technical bug in how the configurator tracked variant IDs.
Original PR description
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as…
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save. - Create a sales order, add the product > configurator opens. - Without saving, open and close the configurator repeatedly (using the pencil icon). Issue: --- - Product price keeps increasing on every open. Root cause: --- - After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation. Fix: --- - Clone the array to avoid mutating the live `currentIds`. [commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b opw-6267273 --- **Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267991
This update fixes an issue where portal users were redirected to the wrong folder when accessing documents. The fix ensures that links from the Documents section correctly navigate users to the intended folder, improving the user experience and preventing confusion. This was caused by a minor coding oversight that has now been resolved.
Original PR description
# How to reproduce - As admin, give access to folder X & folder Y to a portal user - As that portal user, go to Documents, click on folder X and copy the page url - Click on folder Y - Paste the URL in the browser's search bar # The problem You are still in folder Y, even though the link should be to folder X. # Cause We forgot to keep `documents_init`' s `folder_id` (refactored into `user_folder_id`) in https://github.com/odoo/odoo/commit/6bdcc357b195faa0aad8c05eac23aa0a762dd76b opw-6132231 Forward-Port-Of: odoo/enterprise#116928
This change fixes an error that occurred when users removed the CRM module after installing it. The tour service incorrectly attempted to retrieve a tour data based on a module that was no longer present, leading to a system error. This fix ensures the tour service functions correctly regardless of the CRM module's installation status.
Original PR description
When the user installs the ``crm`` module and later uninstalls it, a traceback is generated. Steps to reproduce the error: - Install ``crm`` module and then uninstall it Traceback: ```py IndexError:…
When the user installs the ``crm`` module and later uninstalls it, a traceback is generated. Steps to reproduce the error: - Install ``crm`` module and then uninstall it Traceback: ```py IndexError: list index out of range ``` When the tour service starts, it retrieves the last tour stored in localStorage at [1] which is ``crm_tour``. In commit [2], ``options.fromDB`` was removed. Because of this, the condition is bypassed and ``get_tour_json_by_name`` called for ``crm_tour`` at [3], which does not exist in the database. It then calls ``_get_tour_json``, which leads to the above traceback from the following line. https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/models/tour.py#L48-L53 [1]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_state.js#L13-L15 [2]: https://github.com/odoo/odoo/commit/7e5fdec2e600feb0fbfc663107175b75ec842fea [3]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_service.js#L163-L164 sentry-7473093931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request reverts a recent change that was causing missing information (like order details) on the DIN 5008 delivery slip. The fix prioritizes stability and avoids impacting a large number of customers. This ensures accurate delivery slip printing for all users.
Original PR description
This reverts [1] since it breaks the delivery slip To reproduce the issue: (Need `stock`) 1. Configure the document layout as DIN 5008 2. Create and validate a delivery order 3. Print the delivery slip Error: Some information have disappeared (order, shipping date, and so on) Reverting [1] since it's a recent commit, its use case is neither important nor urgent, and it impacts several customers. [1] 8d588f8198d9057311304e596c009a0795ca6ec7 OPW-6250072 OPW-6260066 OPW-6249926 OPW-6264966 Forward-Port-Of: odoo/odoo#268475
This update fixes an error in the German localization (l10n_de) module where the title of a specific section was incorrect. Specifically, two lines of data related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting within the Odoo system.
Original PR description
title of the B section is wrong. 2 lines need to be multiplied by -1 because they come from credit note but must be reported positively since they are revenue. Source https://www.odoo.com/odoo/documents/tPsLeM-TT--tTeztKJYzmAo4ae27b opw-6204994 Forward-Port-Of: odoo/odoo#267759
This update corrects a bug in the VAT record book export that was incorrectly displaying '01' as the operation code for invoices with 'No Sujeto por reglas de localización' (PT VAT). The fix ensures accurate reporting of VAT transactions, aligning with Spanish tax regulations and the SII data format.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#119467 Forward-Port-Of: odoo/enterprise#117236
This update corrects a rounding issue in the generation of Peppol invoices, preventing validation errors related to unit price calculations. The fix ensures accurate invoice amounts are generated, resolving a problem that could have caused invoices to fail validation and disrupt electronic invoice processing. This improves compliance with Peppol standards.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because priceAmount*InvoicedQuantity != LineExtensionAmount. **STEP TO REPRODUCE** Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. Generate an XML with peppol, and try validating the invoice. You should have the following error: [PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount opw-6009771 Forward-Port-Of: odoo/odoo#267904 Forward-Port-Of: odoo/odoo#262242
This update corrects a bug in the Point of Sale cash rounding method (DOWN). Previously, the system incorrectly absorbed overpayments as rounding offsets, resulting in lost change. This fix ensures accurate change calculations and prevents overpayments from being incorrectly applied as rounding adjustments.
Original PR description
With the DOWN cash rounding method, `asymmetricRound` used `this.isNegative(a)` to decide whether to invert the rounding direction. `isNegative` internally applies the configured method before comparing. This caused `asymmetricRound` to return 0 for genuinely negative remainders, making `appliedRounding` absorb the full overpayment as a rounding offset and zeroing out the change. opw-6268670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268592 Forward-Port-Of: odoo/odoo#268272
This update resolves a permission issue that prevented users from correctly sorting fiscal positions when they were linked to companies outside their authorized access. The fix ensures that access checks are performed correctly, preventing errors and improving data accuracy. This change enhances the stability and reliability of the accounting module.
Original PR description
_get_first_matching_fpos() sorts fiscal positions by company specificity using `f.company_id.parent_ids`. The `parent_ids` field on `res.company` is compute_sudo=True, but `convert_to_record` still builds the resulting recordset in the caller's environment and then calls `filtered('active')` on it. When the fiscal position belongs to a child company whose parent is outside the current user's allowed companies, reading `active` on the parent company record raises an AccessError.
opw-6266568
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#268619
Forward-Port-Of: odoo/odoo#267747This update resolves an issue preventing billing users from completing payment registrations for invoices in the Polish localization. The fix adjusts access permissions to allow billing users (Invoicing group) to correctly access and utilize bank verification records, ensuring payments can be processed without errors. This improves the user experience for billing workflows.
Original PR description
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish…
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for l10n_pl.bank.account.verification was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ). ### Current behavior before PR: • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice: │ You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. • This triggers a failure to write/compute the transient field account.payment.register.l10n_pl_bank_verification_ids during the payment wizard load, completely blocking billing users from processing payments. ### Desired behavior after PR is merged: • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices. • The payment register wizard computes the l10n_pl_bank_verification_ids and displays warning banners regarding VAT verification without throwing security exceptions. • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group. Closes #263938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267992
This update resolves an issue where a payrun would unexpectedly be marked as cancelled after removing a single payslip. Previously, removing a payslip could disrupt the payrun's status, even if other employees were still associated with it. This fix ensures payruns remain in the correct state after individual payslip removal.
Original PR description
Fixes the following bug in payruns: - create a payrun, leave it in draft - create a single payslip, add it to the previously created payrun. The payslip employee will appear in the payrun employee list - for the previously created payslip, remove it from the payrun - go back to payruns kanban view, the payrun will results as cancelled even if there still were other employee entries in it (the one defined at start) task: 6237460
This update resolves an issue preventing users from editing the short description of new partners within the website interface. The change re-enabled necessary styling and formatting to allow for text input, improving the partner management experience. It also includes a minor fix to preserve placeholder attributes for improved usability.
Original PR description
Steps to reproduce: 1. Create a new partner with any level. 2. Click on the Go to Website button and publish it. 3. Now go to the /partners page and activate editor. 4. Now try to edit the short…
Steps to reproduce: 1. Create a new partner with any level. 2. Click on the Go to Website button and publish it. 3. Now go to the /partners page and activate editor. 4. Now try to edit the short description of the partner. Current behavior: The short description is not editable in the frontend. This is due to the changes made in the editor, before the changes, the o_editable class was getting added additional properties to give it a minimum height and width, along with making it an inline-block element. But now, these properties has been removed, which is causing an issue for users adding new partners and trying to edit the short description in the website. Solution: We brought back the crm_partner_assign.scss and added the properties back to the o-editable element inside our specific partner short description. Also added a placeholder to the short description to make the interaction more intuitive for users. opw-5955922 Forward-Port-Of: odoo/odoo#266211 Forward-Port-Of: odoo/odoo#253097
This update optimizes how spreadsheet dashboards handle multiple filter changes. Previously, each filter update triggered a slow reload, leading to excessive server requests. Now, updates are batched, significantly reducing server load and improving dashboard responsiveness, especially with many filters.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - Applying multiple global filters triggered one command per filter. - Each command reloaded all data sources (pivot/chart/list). - This caused redundant RPC calls: (no of filter change * no of data sources). - With many filters and data sources, server load increased heavily and could lead to slowdowns or 502 errors. Desired behavior after PR is merged: - Use `SET_MANY_GLOBAL_FILTER_VALUE` to update filters in batch. - Data sources are reloaded only once per batch update. - RPC calls and reload now scale with number of data sources only. Impact: - Significantly reduces server calls when applying multiple filters. - Improves dashboard responsiveness and avoids server overload. Task: [6216133](https://www.odoo.com/odoo/project/2328/tasks/6216133) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264314
The appearance of the portal chatter message delete dialog has been corrected. This change addressed a visual issue caused by a recent update that lacked the necessary styling for the dialog's size and content, specifically related to HTML formatting within messages. This ensures a consistent and professional user experience for portal users.
Original PR description
The delete message dialog in the portal chatter has been visually broken since #247708, which replaced the generic `MessageConfirmDialog` (size="xl") with a dedicated `MessageDeleteDialog` (size="md"). The md size triggers the `o_modal_design_minimal` design path in `dialog.js`, whose styles are defined in `dialog.scss`. Additionally, message content may contain html_editor-formatted elements (blockquote in thi scase) whose styles come from `html_editor.assets_editor`. Neither was included in `portal.assets_chatter_style`. This change adds those missing styles to the portal chatter shadow DOM. **Before:** <img width="637" height="290" alt="image" src="https://github.com/user-attachments/assets/2dae0e72-383d-4277-94e7-ef23a01ea53b" /> **After:** <img width="637" height="317" alt="image" src="https://github.com/user-attachments/assets/ca36bc51-3cc9-43c6-bcf2-30c03498353c" /> Forward-Port-Of: odoo/odoo#268233
This update fixes a visual misalignment issue with the alert content displayed in the Odoo portal. The change was a result of a previous fix, and we've simplified the styling to ensure alerts appear correctly. This improves the overall user experience and consistency.
Original PR description
The alert content is misaligned these changes are side effects of commit[1], the `h5` and `p` in the alert have margin that creates whitespace in the alert. Commit[2] addressed a misalignment issue and alignment issue due to nested `row` but these became irrelevant with commit[1]. This is why we remove the styling. task-5262108 [1]: odoo/odoo@513931a5e540f22f37e317f80fd131701cbbc8f0 [2]: odoo/odoo@d64dbaadcb1bef27d89a89e9d42bdb38890c73e0 | Before | After | |--------|--------| | <img width="1029" height="523" alt="image" src="https://github.com/user-attachments/assets/ff3f827b-652a-4a84-ad7e-205200cf3256" />| <img width="1022" height="486" alt="image" src="https://github.com/user-attachments/assets/b86163d8-bedd-4cb6-a950-ba36a6b401ee" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268249 Forward-Port-Of: odoo/odoo#267776
This update resolves a technical error that prevented users from correctly configuring billing targets within the timesheet settings. The fix ensures that the system accurately retrieves necessary data for billing calculations, improving the reliability of timesheet reporting. This change was triggered by a necessary update to a core component of the timesheet functionality.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price accurately reflects the total price, including tax, for transactions using the UrbanPiper integration. This improves order accuracy and provides a more reliable customer experience.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
A recent update caused payment failures in the self-order POS system. This fix corrects a compatibility issue where a new payment method wasn't supported. The change simply ensures the system falls back to the standard POS configuration, restoring payment functionality.
Original PR description
The PR odoo/odoo#267280 changed the Viva class to use the `getCashier` method to determine the `cashRegisterId`, however this method does not exist in self order, so an error is always thrown. This commit fixes the issue by simply adding a `?` so that it falls back to the POS config name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268548
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports. Specifically, fields 2955 and 2956 must always be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the eCDF, preventing data rejection and maintaining accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update corrects a calculation error in the Swiss Balance Sheet's equity reporting. A new 'Profit / Loss brought forward' line has been added to accurately separate legal reserve and retained earnings, aligning with Swiss accounting standards. The previous 'Annual profit or annual loss' field is now purely informational.
Original PR description
Fix the Equity section in the Swiss Balance Sheet. Adding a new line 'Profit / Loss brought forward' for the result brought forward, that allows to separate the legal reserve and the results. The new structure for the equity section is: - Share, corporate or foundation capital - Legal reserve - Retained earnings - Profit / Loss brought forward - Previous years' unallocated profit or loss - Treasury shares The 'Annual profit or annual loss' is now purely indicative and is not taken into account in the equity computation, as the amounts in this section are considered in the new Retained Earnings section. task-6220525 Forward-Port-Of: odoo/enterprise#117601
26 changes
Resolved issues and error corrections
A bug was preventing users without Live Chat access from viewing visitor reports. This was caused by a misconfigured access check within the website reporting feature. This update corrects this issue, ensuring all users can access visitor data.
Original PR description
**Steps to Reproduce** 1. Open a database in version 19.2 with demo data. 2. Install the `website` and `im_livechat` modules. 3. Login with another user who has access to the Website application but…
**Steps to Reproduce**
1. Open a database in version 19.2 with demo data.
2. Install the `website` and `im_livechat` modules.
3. Login with another user who has access to the Website application but does not have access to the Live Chat application.
4. Navigate to: **Website → Reporting → Visitors**
5. An `AccessError` is raised with the traceback below.
**Issue:**
The traceback is caused by the following [commit](https://github.com/odoo/odoo/pull/240778/changes#diff-580c2ced97a218f926605037b31c4fd2d01253eb1b4f290038f251f9ef31be3b) introduced in v19.2.
In this commit, a new [computed field](https://github.com/odoo-dev/odoo/blob/381aede4fde0f871b51df41911c28be3153cd489/addons/website_livechat/models/website_visitor.py#L32) `current_livechat_agent_ids` was added on `website.visitor`.
Inside this compute, data from `im_livechat.channel.member.history` is accessed using `_read_group`.
However, `im_livechat.channel.member.history` is only accessible to users belonging to the following group: `im_livechat.im_livechat_group_user`
At the same time, the Website Visitors menu is accessible to normal Website users through the Website module [ACLs](https://github.com/odoo/odoo/blob/006a6a1cc6e50bd8b328d0cabb7abbcf610e34bb/addons/website/security/ir.model.access.csv#L30)
The issue occurs because the same `website.visitor` views/actions are reused from multiple menus (Website, Social Marketing, Live Chat), but the compute method assumes that the current user has Live Chat access.
As a result, when a user without Live Chat permissions opens: **Website → Reporting → Visitors**
the compute of `current_livechat_agent_ids` triggers an `AccessError`.
**Solution:**
To fix this issue, a group access added on the field `current_livechat_agent_ids`
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-19.2/addons/
website_livechat/models/website_visitor.py", line 32, in
_compute_current_livechat_agent_ids
self.env["im_livechat.channel.member.history"]._read_group(
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 1933, in
_read_group
self.browse().check_access('read')
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
raise result[1]()
odoo.exceptions.AccessError: You are not allowed to access
'Keep the channel member history' (im_livechat.channel.member.history) records.
This operation is allowed for the following groups:
- Live Chat/User
Contact your administrator to request access if necessary.
```
opw : 6169395
upg : 4286153, 4286493, 4283345
tbg : 2676
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-prThis update fixes a calculation error in online orders using UrbanPiper, ensuring that the displayed price (Tax Included) accurately reflects the total cost, including GST. Previously, the system incorrectly calculated the price, leading to discrepancies. This change ensures accurate pricing and a better customer experience.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update resolves an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank exports, leading to file rejections. The fix ensures '&' is preserved in name and address fields, aligning with banking standards and preventing export failures. This improves data accuracy and streamlines payment processing.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118604
Forward-Port-Of: odoo/enterprise#115409This update resolves an issue where users were unintentionally able to select properties within the field selector widget. The fix adds a new option to the widget, allowing for proper property selection, and includes a corresponding test to ensure functionality. This improves the user experience and prevents potential data entry errors.
Original PR description
- Backporting this [commit], for adding the `allow_properties` option to `field_selector` widget in `saas-18.2` for using the functionality in linked enterprise commit. - Also, added a test for `allow_properties` option. - For forward ports, only the test will be merged, as `allow_properties` is already included in the original commit. [commit]: https://github.com/odoo/odoo/pull/215767/changes/7cd18c07b5e008bff072d10375c908eb77434fde sentry-7378769090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268471 Forward-Port-Of: odoo/odoo#257833
This update resolves an issue where users were encountering errors when attempting to use property fields within auto-fill fields in the Sign module. The fix restricts property field selection, ensuring stability and preventing errors during data entry. This improves the user experience when configuring sign items.
Original PR description
Currently, an error occurs when user tries to select a property field in auto field. Steps to replicate: - Install `sale_management` and `sign`. - Open Sales > Products > Products > Open any product.…
Currently, an error occurs when user tries to select a property field in auto field.
Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.
Error:
- saas-18.3 and later:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
field = records._fields[field_name]
^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```
- saas-18.2:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
if len(records) > PREFETCH_MAX:
^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```
Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.
- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.
Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.
[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41
sentry-7378769090
Forward-Port-Of: odoo/enterprise#119493
Forward-Port-Of: odoo/enterprise#113091This update ensures all date displays within the stock accounting module use Odoo's standard date format, regardless of the user's device settings. Previously, the system relied on local device settings, leading to inconsistent date representations. This change improves clarity and accuracy for all users.
Original PR description
Why this Commit: --- toLocaleString() relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format,the toLocaleString() usages should be replaced to ensure consistency. After this commit: --- <img width="1884" height="363" alt="image" src="https://github.com/user-attachments/assets/8cee2d86-10dc-48d7-8c3a-369ec257c101" /> date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259651
This update resolves an issue that prevented proper testing of the German POS certification module when duplicating databases. The code now safely removes identifying information (client_id and tss_id) during duplication, allowing for accurate testing in neutralized database environments. This ensures the module functions correctly and reliably.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update fixes an issue where downpayments made in the Sale module weren't correctly reflected when processed through Point of Sale (PoS). The fix ensures that downpayments are calculated as a percentage of the remaining balance, improving the accuracy of PoS transactions. This prevents overcharging and ensures proper accounting for customer payments.
Original PR description
**Steps to reproduce:** - Make a quotation - Make a downpayment of 50% for it - Go to PoS, make a downpayment of 50% for it - It will be a downpayment for 50% of the total price, even though it should be 50% of what's left **Why the fix:** Since 2736cf99f8f5e42b294366252d903111764ec352 the amount is now calcultated with the account helpers. But the flow with a downpayment that was already added to the SO in the Sale module was not implemented, meaning the full price will be displayed in the case of a % downpayment in POS. The issue is that the price of a downpayment in the baseLines will be 0, because the qty of a downpayment is 0 in the Sale module, and it's imported as is. So we first set it to -1 to make sure we subtract the price from what's left to pay. opw-6087777 Forward-Port-Of: odoo/odoo#268235 Forward-Port-Of: odoo/odoo#259215
This update resolves an issue where kit products were incorrectly inflating inventory valuation reports. The fix ensures that kit products are accurately reflected in inventory history, preventing overestimation of total inventory value by excluding their total value calculation. This improves the accuracy of stock reporting.
Original PR description
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo…
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo data. * Create a product with inventory tracking enabled. * Create a BoM of type kit for that product. * Add component products with a defined cost and on-hand quantity greater than 0 to the BoM. * Recompute the kit product’s cost from its BoM on the product page. * Go to Inventory > Reporting > Stock > Inventory at date > Confirm ## Observed Behavior: Even though kits do not appear on stock valuation they still do appear the inventory history report. **Why kits should not appear on inventory history** For example, consider a kit product called 'Computer' that is composed of the following components: | Product | Quantity | Cost | |--------|--------|--------| | CPU | 1 | $300 | | Motherboard | 1 | $300 | The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value at that particular date as $1,200, which is incorrect because it is counting both the kit and its components ## Root cause: This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm. At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear. **Why doesn’t this issue occur in the normal stock view?** Because the domain is overridden at [2] to explicitly exclude kit products from the stock view. However, the quantity history report does not apply this same domain override, so kit products continue to appear there. [1]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166 ## Solution: To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered. This can be achieved by modifying and overriding the domain to explicitly exclude kit products. This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835). opw-6164547 Forward-Port-Of: odoo/odoo#262185
The configurator was incorrectly inflating the extra price of products, causing inaccurate sales order calculations. This fix prevents the configuration from repeatedly modifying the product price by cloning the relevant array, ensuring accurate price updates. This ensures correct pricing for customized products.
Original PR description
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as…
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save. - Create a sales order, add the product > configurator opens. - Without saving, open and close the configurator repeatedly (using the pencil icon). Issue: --- - Product price keeps increasing on every open. Root cause: --- - After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation. Fix: --- - Clone the array to avoid mutating the live `currentIds`. [commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b opw-6267273 --- **Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267991
This change reverts a recent update that was causing missing information (like order details) on the DIN 5008 delivery slip. The fix ensures the delivery slip prints correctly with all necessary data. This resolves an issue impacting multiple customers.
Original PR description
This reverts [1] since it breaks the delivery slip To reproduce the issue: (Need `stock`) 1. Configure the document layout as DIN 5008 2. Create and validate a delivery order 3. Print the delivery slip Error: Some information have disappeared (order, shipping date, and so on) Reverting [1] since it's a recent commit, its use case is neither important nor urgent, and it impacts several customers. [1] 8d588f8198d9057311304e596c009a0795ca6ec7 OPW-6250072 OPW-6260066 OPW-6249926 OPW-6264966 Forward-Port-Of: odoo/odoo#268475
A recent update has fixed an issue where portal users were redirected to the wrong folder when accessing documents. This was due to a technical oversight in how folder permissions were handled. Now, links to documents will reliably take users to the intended folder.
Original PR description
# How to reproduce - As admin, give access to folder X & folder Y to a portal user - As that portal user, go to Documents, click on folder X and copy the page url - Click on folder Y - Paste the URL in the browser's search bar # The problem You are still in folder Y, even though the link should be to folder X. # Cause We forgot to keep `documents_init`' s `folder_id` (refactored into `user_folder_id`) in https://github.com/odoo/odoo/commit/6bdcc357b195faa0aad8c05eac23aa0a762dd76b opw-6132231 Forward-Port-Of: odoo/enterprise#116928
This update corrects a bug where Spanish users were incorrectly interpreting durations entered with decimal separators (e.g., "0,5"). The fix reverses the order of replacements in the parsing process, ensuring that the decimal point is correctly identified and handled. This ensures accurate duration input and calculation in Spanish.
Original PR description
Issue: ---------------------------------------- In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes. Steps to reproduce: ----------------------------------------…
Issue:
----------------------------------------
In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes.
Steps to reproduce:
----------------------------------------
- Install Project and Timesheet
- Switch the user language to Spanish
- Open a task, in the "Timesheet" page, create a new line
- Input "0,5" as duration
Cause:
----------------------------------------
In the parser, the value is transformed according to the language decimal point and thousands separator:
```js
value = value
.replaceAll(localization.decimalPoint, ".")
.replaceAll(localization.thousandsSep, "");
```
In Spanish `decimalPoint` is "," and `thousandsSep` is ".". So the first `replaceAll()` changes "0,5" into "0.5", then the second one deletes the point.
Solution:
----------------------------------------
We need to invert the two `replaceAll()`.
As the `thousandsSep` is just removed, this will not create a new issue in another language.
opw-6263523This update fixes an error in the German localization (l10n_de) module where the title of a specific section was incorrect. Specifically, two lines related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting for German-speaking customers.
Original PR description
title of the B section is wrong. 2 lines need to be multiplied by -1 because they come from credit note but must be reported positively since they are revenue. Source https://www.odoo.com/odoo/documents/tPsLeM-TT--tTeztKJYzmAo4ae27b opw-6204994 Forward-Port-Of: odoo/odoo#267759
This update resolves an issue where the VAT record books generated for Spanish invoices with 'No Sujeto por reglas de localización' taxes (like PT VAT) incorrectly displayed '01' in the 'Clave de Operación' column. The fix ensures the correct '17' code is used, aligning with Spanish VAT regulations and SII reporting requirements. This improves the accuracy of VAT reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#119467 Forward-Port-Of: odoo/enterprise#117236
This update ensures that Cashdro payments are automatically cancelled when a payment is manually 'forced' to complete. Previously, a forced payment would leave the Cashdro machine stuck waiting for a payment that could no longer be cancelled, causing delays and potential issues. This change prevents this scenario and streamlines the payment process.
Original PR description
Since the Cashdro machine has no way for the user to cancel the payment through its interface, if a payment was forced the machine would remain waiting for a payment that could no longer be cancelled from the POS. To fix this, we now send a cancel request whenever a payment is forced. task-6276665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268496
This update addresses a potential issue where lengthy address fields during credit card payments via Authorize.net could cause errors. The system now automatically limits address field lengths to comply with the Authorize.net API, ensuring smoother payment processing. This change improves payment reliability and reduces potential disruptions for our customers.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
This update corrects a visual issue in the POS control panel. Previously, a split button was always displayed, even when bill splitting was disabled within the restaurant module. This change ensures the button is only visible when bill splitting is enabled, improving the user experience and preventing unnecessary clutter.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267359 Forward-Port-Of: odoo/odoo#266654
This update resolves an issue preventing billing users from completing payment registrations for invoices in the Polish localization. The fix adjusts access permissions to allow standard billing users to correctly register payments and compute VAT verification information, improving the payment process for all users.
Original PR description
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish…
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for l10n_pl.bank.account.verification was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ). ### Current behavior before PR: • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice: │ You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. • This triggers a failure to write/compute the transient field account.payment.register.l10n_pl_bank_verification_ids during the payment wizard load, completely blocking billing users from processing payments. ### Desired behavior after PR is merged: • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices. • The payment register wizard computes the l10n_pl_bank_verification_ids and displays warning banners regarding VAT verification without throwing security exceptions. • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group. Closes #263938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267992
This update fixes a potential error that could occur when calculating rental availability for products with start and return dates. Specifically, it prevents a traceback when dates are incompatible, ensuring a smoother experience for users adding rental items to their carts. This improves reliability and prevents disruptions during the booking process.
Original PR description
Preventing traceback on incompatible dates between the cart and the product page. How to reproduce: 1. Add to cart a product with periodicity Hours/Days with a start date = return date (e.g.: Projector). 2. Go to the product page of a product configured with Pickup > Return (e.g.: Premium Bike, Luxury Room) 3. Traceback, as we try to get the availabilities on a negative period. start date > end date, as both dates are equals and the time is set from the Pickup and Return fields. Forward-Port-Of: odoo/enterprise#119480
This update resolves an issue where a confusing time slot selection popup appeared unexpectedly when using order presets in the restaurant POS. The fix ensures that the preset selection flow is properly exited after an order is merged and deleted, preventing the popup and associated errors. This improves the overall user experience for restaurant staff.
Original PR description
pos*: point_of_sale, pos_restaurant Steps to reproduce: - Configure a preset identified by name and managed by time. - Open the restaurant POS. - Create a direct order and set a tab for it. - Return to the floor screen and create another direct order. - Select the configured preset and choose the previously created order from the order name popup. Issue: - The time slot selection popup appears unexpectedly. - Selecting a time slot triggers a traceback. Cause: - When selecting an existing order, the current order is merged into the selected order. - However, the time slot selection flow remains active for the merged order, which has already been deleted. Fix: - Exit the preset selection flow when the order is merged and deleted. Task-6032880 Forward-Port-Of: odoo/odoo#268546 Forward-Port-Of: odoo/odoo#253586
A technical issue preventing users from configuring billing targets in the Timesheets app has been resolved. This fix ensures that users can correctly set billing rates for employee timesheets, improving the accuracy of billing data. The underlying cause was a missing field required by a core component of the Timesheets functionality.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
This update ensures receipts can now be prepared and printed offline, regardless of whether the order was synced. Previously, synced orders caused errors, preventing offline receipt generation. This enhancement improves the user experience by allowing for offline operations.
Original PR description
Preparation receipts could be printed offline only if the order was not synced. If orders were synced, the `ConnectionLostError` were preventing the call to be executed. Forward-Port-Of: odoo/odoo#268570
This update fixes a bug that prevented payroll calculations from correctly generating worked day lines for employees using attendance-based work schedules. The change ensures that all employees, regardless of their flexible working arrangement, receive accurate wage calculations based on their attendance records. This improves payroll accuracy and reporting.
Original PR description
### **Steps to reproduce:** - Install Payroll and Attendance apps. - Create an employee with a flexible working schedule and work entry source as attendance. - Create an attendance record for this…
### **Steps to reproduce:** - Install Payroll and Attendance apps. - Create an employee with a flexible working schedule and work entry source as attendance. - Create an attendance record for this employee. - Create and compute a payslip for this employee. ### **Observed Behavior:** Worked Day lines are not generated, and Basic Wage is calculated as 0. ### **Expected Behavior:** Worked Day lines should be populated based on attendance records. ### **Root Cause:** During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id` at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed. [1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898 ### **Fix:** Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries. **opw-6146452**
This update corrects a technical error that prevented email notifications from being sent correctly within the planning module. The fix ensures that email actions function consistently across Odoo Enterprise, opening the standard email composer for sending messages. This resolves a minor disruption to workflow.
Original PR description
the used action name for the Send Email action was false its supposed to be action_send and not action_send_email task: 6244506
This update resolves a payment issue that occurred in self-order mode within the Viva POS system. The previous change introduced an error because a required method wasn't available in self-order. This fix simply adds a fallback mechanism to ensure payments continue to process correctly.
Original PR description
The PR odoo/odoo#267280 changed the Viva class to use the `getCashier` method to determine the `cashRegisterId`, however this method does not exist in self order, so an error is always thrown. This commit fixes the issue by simply adding a `?` so that it falls back to the POS config name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268548
24 changes
Resolved issues and error corrections
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price and total tax-inclusive price accurately reflect the product's price with tax, resolving a discrepancy in order line calculations. This improves the accuracy of online sales transactions.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update fixes an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank exports, leading to rejection by banks. The change ensures '&' is preserved in name and address fields, aligning with industry standards and preventing export failures. This improves the reliability of our SEPA payment processing.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118604
Forward-Port-Of: odoo/enterprise#115409This update ensures that all date references within the stock accounting module consistently use Odoo's standard date format. Previously, the system relied on the user's device settings, which could lead to inconsistencies in reporting and data display. This change improves data accuracy and reliability for financial reporting.
Original PR description
Why this Commit: --- toLocaleString() relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format,the toLocaleString() usages should be replaced to ensure consistency. After this commit: --- <img width="1884" height="363" alt="image" src="https://github.com/user-attachments/assets/8cee2d86-10dc-48d7-8c3a-369ec257c101" /> date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259651
This update resolves an issue where duplicating a database would cause errors during testing of the German POS certification module. The code now safely removes identifying information (client_id and tss_id) during duplication, allowing for proper testing in neutralized database environments. This ensures consistent and reliable testing of the module.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update fixes an issue where downpayments made in the Sale module weren't correctly reflected when processed through Point of Sale (PoS). The fix ensures that downpayments are calculated as a percentage of the remaining balance, improving accuracy in PoS transactions. This prevents incorrect pricing and ensures proper accounting for downpayments.
Original PR description
**Steps to reproduce:** - Make a quotation - Make a downpayment of 50% for it - Go to PoS, make a downpayment of 50% for it - It will be a downpayment for 50% of the total price, even though it should be 50% of what's left **Why the fix:** Since 2736cf99f8f5e42b294366252d903111764ec352 the amount is now calcultated with the account helpers. But the flow with a downpayment that was already added to the SO in the Sale module was not implemented, meaning the full price will be displayed in the case of a % downpayment in POS. The issue is that the price of a downpayment in the baseLines will be 0, because the qty of a downpayment is 0 in the Sale module, and it's imported as is. So we first set it to -1 to make sure we subtract the price from what's left to pay. opw-6087777 Forward-Port-Of: odoo/odoo#268235 Forward-Port-Of: odoo/odoo#259215
This update resolves an issue where kit products were incorrectly included in inventory valuation reports. The fix ensures that kit product quantities are accurately displayed in the history report without impacting the overall inventory valuation calculation, which is already based on its component parts. This improves the accuracy of stock reporting.
Original PR description
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo…
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo data. * Create a product with inventory tracking enabled. * Create a BoM of type kit for that product. * Add component products with a defined cost and on-hand quantity greater than 0 to the BoM. * Recompute the kit product’s cost from its BoM on the product page. * Go to Inventory > Reporting > Stock > Inventory at date > Confirm ## Observed Behavior: Even though kits do not appear on stock valuation they still do appear the inventory history report. **Why kits should not appear on inventory history** For example, consider a kit product called 'Computer' that is composed of the following components: | Product | Quantity | Cost | |--------|--------|--------| | CPU | 1 | $300 | | Motherboard | 1 | $300 | The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value at that particular date as $1,200, which is incorrect because it is counting both the kit and its components ## Root cause: This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm. At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear. **Why doesn’t this issue occur in the normal stock view?** Because the domain is overridden at [2] to explicitly exclude kit products from the stock view. However, the quantity history report does not apply this same domain override, so kit products continue to appear there. [1]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166 ## Solution: To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered. This can be achieved by modifying and overriding the domain to explicitly exclude kit products. This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835). opw-6164547 Forward-Port-Of: odoo/odoo#262185
The configurator was incorrectly inflating the extra price of products. This update fixes a bug where repeatedly opening and closing the configurator caused the price to increase. The fix involves cloning an array to prevent unintended modifications to the product's price calculation, ensuring accurate pricing.
Original PR description
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as…
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save. - Create a sales order, add the product > configurator opens. - Without saving, open and close the configurator repeatedly (using the pencil icon). Issue: --- - Product price keeps increasing on every open. Root cause: --- - After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation. Fix: --- - Clone the array to avoid mutating the live `currentIds`. [commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b opw-6267273 --- **Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267991
This pull request reverts a recent change that was causing missing information (like order details) on the DIN 5008 delivery slip. The fix prioritizes stability and avoids impacting a large number of customers. It's reverting a less critical change to ensure correct delivery slip generation.
Original PR description
This reverts [1] since it breaks the delivery slip To reproduce the issue: (Need `stock`) 1. Configure the document layout as DIN 5008 2. Create and validate a delivery order 3. Print the delivery slip Error: Some information have disappeared (order, shipping date, and so on) Reverting [1] since it's a recent commit, its use case is neither important nor urgent, and it impacts several customers. [1] 8d588f8198d9057311304e596c009a0795ca6ec7 OPW-6250072 OPW-6260066 OPW-6249926 OPW-6264966 Forward-Port-Of: odoo/odoo#268475
This update fixes an issue where portal users were redirected to the wrong folder when accessing documents. The fix ensures that links from the Documents section correctly navigate users to the intended folder, improving the user experience. This was caused by a minor oversight in how folder IDs were handled.
Original PR description
# How to reproduce - As admin, give access to folder X & folder Y to a portal user - As that portal user, go to Documents, click on folder X and copy the page url - Click on folder Y - Paste the URL in the browser's search bar # The problem You are still in folder Y, even though the link should be to folder X. # Cause We forgot to keep `documents_init`' s `folder_id` (refactored into `user_folder_id`) in https://github.com/odoo/odoo/commit/6bdcc357b195faa0aad8c05eac23aa0a762dd76b opw-6132231 Forward-Port-Of: odoo/enterprise#116928
This update resolves an issue where invoices for Colombian 'Persona Natura' customers were incorrectly formatted for export to the DIAN tax authority. The change ensures the correct XML structure is generated, addressing a mismatch in account identification and party identification. This prevents export errors and ensures compliance with Colombian tax regulations.
Original PR description
Issue: Colombian partner being Persona Natura are misinterpreted as Person Juridica. It raises issue while exporting XMLs for dian. Steps to reproduce: - In a Colombian company - Create a Customer with NIT and "Obligaciones y Responsabilidades" to "R-99-PN" - Create an invoice - Send the invoice Current behavior: - node <cbc:AdditionalAccountID> is set to 1 and node PartyIdentification is missing Expected behavior: - node <cbc:AdditionalAccountID> is set to 2 and there is a PartyIdentification node Cause: Colombian partners having a NIT have is_company to True. However, Persona Natura have NIT but aren't companies. opw-6206308
This update resolves a technical error that prevented users from successfully attaching PDF invoices when using the Nilvera e-invoice system. The change ensures that the system correctly handles the raw PDF data returned by the Nilvera client, aligning with Python 3.14's stricter data validation requirements. This ensures invoices with PDFs are now processed without errors.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update adjusts the sequence of the ‘Configuration’ menu item within the Contracts module. Previously, a low sequence value caused conflicts with other modules, disrupting Odoo’s standard menu organization. This change ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update fixes an error in the German localization (l10n_de) module where the title of a section was incorrect. Specifically, two lines related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting.
Original PR description
title of the B section is wrong. 2 lines need to be multiplied by -1 because they come from credit note but must be reported positively since they are revenue. Source https://www.odoo.com/odoo/documents/tPsLeM-TT--tTeztKJYzmAo4ae27b opw-6204994 Forward-Port-Of: odoo/odoo#267759
This update resolves an issue where VAT book reports incorrectly displayed '01' for invoices with 'No Sujeto por reglas de localización' taxes (like PT VAT). The fix ensures the correct '17' operation code is generated, aligning with Spanish VAT regulations and SII data, improving the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#119467 Forward-Port-Of: odoo/enterprise#117236
This update ensures that Cashdro payments are properly cancelled when a payment is manually 'forced' through the POS system. Previously, a forced payment would leave the Cashdro machine stuck waiting for a payment that couldn't be cancelled, causing delays. This fix prevents this issue and streamlines the payment process.
Original PR description
Since the Cashdro machine has no way for the user to cancel the payment through its interface, if a payment was forced the machine would remain waiting for a payment that could no longer be cancelled from the POS. To fix this, we now send a cancel request whenever a payment is forced. task-6276665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268496
This update resolves a previous issue that prevented users from exporting records with properties from kanban and list views. Now, records containing properties can be exported successfully, and individual properties are automatically included in the export process, simplifying data retrieval for reporting and analysis.
Original PR description
**Before this commit:** - Exporting records with properties from the kanban view caused a `Client Error`. - Inserting records with properties from the kanban view into a spreadsheet caused a `Client Error`. - Individual properties were not exported by default in list views (even when optionally displayed) or in kanban views. **After this commit:** - Records containing properties can be exported from the kanban view. - Records with properties can be inserted into a spreadsheet without errors. - Individual properties that are optionally displayed are listed by default in `Fields to Export`. enterprise: https://github.com/odoo/enterprise/pull/118913 task-6123524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264267
This update enhances the way properties are exported from records when using the spreadsheet edition. Previously, sub-properties weren't supported, but this fix ensures that all record properties are now included in the export. This change is designed to align with existing functionality in newer Odoo versions and maintain a consistent user experience.
Original PR description
* = [documents_spreadsheet] When exporting properties from records in the web kanban and list views, sub-properties created within a record were previously not supported. Support for exporting these sub-properties has now been added. However, in spreadsheet this should only be enabled from saas-19.2 onwards (where it is already available). To keep the behavior aligned with the usual flow on earlier versions, this filters out the sub-properties exported from the record in `spreadsheet_edition`. community: https://github.com/odoo/odoo/pull/264267 task-6123524 Forward-Port-Of: odoo/enterprise#118913
This update corrects a visual issue in the POS system where a split button was always displayed, even when bill splitting was disabled for a restaurant. The fix ensures the button is hidden when the restaurant module is active, aligning the user interface with the current bill splitting configuration. This improves the user experience by removing unnecessary options.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267359 Forward-Port-Of: odoo/odoo#266654
This update resolves an issue preventing billing users from completing payment registrations for invoices in the Polish localization. The fix adjusts access permissions to allow standard billing users to correctly register payments and compute VAT verification information, improving the payment process for all users.
Original PR description
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish…
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for l10n_pl.bank.account.verification was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ). ### Current behavior before PR: • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice: │ You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. • This triggers a failure to write/compute the transient field account.payment.register.l10n_pl_bank_verification_ids during the payment wizard load, completely blocking billing users from processing payments. ### Desired behavior after PR is merged: • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices. • The payment register wizard computes the l10n_pl_bank_verification_ids and displays warning banners regarding VAT verification without throwing security exceptions. • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group. Closes #263938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267992
This update corrects a bug in how overtime calculations are handled across multiple days, specifically when an attendance crosses into a non-working day. The fix prevents overlapping overtime intervals caused by rounding errors, ensuring accurate overtime tracking. This improves the reliability of employee time reporting.
Original PR description
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are…
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are saved to 3 decimals, but this is normally fine since the durations are accumulated when calculating the next interval. However, on a day boundary in the employee timezone, the end of the interval is forced to the end of day, which incidentally removes the rounding error. This causes the overlap when calculating the next interval since its start will be based on the rounded duration, not the actual end of day. **Steps to Reproduce:** - Configure an overtime rule where >8 hours is considered overtime, and a second rule applies to non-working days - Set Overtime Rule on employee "Anita Oliver" - Set employee work entry source to "Attendances" - Create an attendance that exceeds 8 hours in a day and crosses into a non-working day and creates enough of a rounding error (see unit test) -> Traceback error: `ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)` **Solution:** Add an additional check to ensure the overtime cannot start on the previous day. opw-6067969 Forward-Port-Of: odoo/enterprise#118570
A technical issue preventing users from accessing billing targets within the timesheet feature has been resolved. This fix ensures a smoother workflow for employees and managers managing billable time. The change addresses a problem related to a required field within the timesheet configuration.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports due to incorrect data in XML fields. Specifically, fields 2955 and 2956 must always be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the tax authority, preventing rejection and potential compliance problems.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update corrects a technical issue where archived delivery carriers were being unintentionally included in the carrier selection process. Previously, the system would pass information about inactive carriers, leading to incorrect choices in the delivery wizard. This change ensures that only active carriers are considered, improving the accuracy and reliability of delivery options.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264945 Forward-Port-Of: odoo/odoo#263819
This update ensures receipts can now be prepared and printed offline, regardless of whether the order was synced. Previously, syncing orders caused errors, preventing offline receipt generation. This change improves the user experience by allowing for offline operations without disruption.
Original PR description
Preparation receipts could be printed offline only if the order was not synced. If orders were synced, the `ConnectionLostError` were preventing the call to be executed. Forward-Port-Of: odoo/odoo#268570
3 changes
Resolved issues and error corrections
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price accurately reflects the total amount, including the tax, for transactions using the UrbanPiper integration. This improves order accuracy and provides customers with the correct pricing.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update resolves an issue that prevented proper testing of the l10n_de_pos_cert module when duplicating databases. Specifically, the commit removes client and tss identifiers during duplication, allowing for seamless testing in neutralized database environments. This ensures consistent and reliable testing of the module's functionality.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update corrects a setting that was automatically generating CFDI invoices for all orders placed through the e-commerce website. Previously, invoices weren't automatically generated for e-commerce orders, which is now the intended behavior. This change ensures that invoices are only created when a customer provides their information.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119442 Forward-Port-Of: odoo/enterprise#116061
7 changes
Resolved issues and error corrections
This update fixes a calculation error in online orders using UrbanPiper, ensuring that the displayed price (including tax) accurately reflects the total cost. Previously, the system incorrectly calculated the price excluding tax. This change ensures accurate pricing and a better customer experience for online transactions.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update resolves an issue that prevented Odoo from correctly duplicating databases used for testing the German POS certification module (l10n_de_pos_cert). Specifically, the system was removing key identifiers during duplication, leading to errors. This change ensures proper functionality during database duplication, improving testing and development processes.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update resolves an issue that prevented users from successfully attaching PDF invoices when using the Nilvera e-invoicing client. The fix ensures that the system correctly handles binary PDF data, addressing a compatibility problem with Python 3.14's stricter base64 validation rules. This ensures invoices with attachments are processed correctly.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update resolves a technical issue where the ‘Configuration’ menu item within the Contracts module was being incorrectly positioned due to a low sequence number. This caused conflicts with other modules and disrupted the standard Odoo menu structure. The change ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update fixes an issue where invoices from certain Peppol suppliers (using a specific XML format) weren't being correctly imported. The fix ensures the system correctly identifies the supplier's VAT information, automatically creating the invoice and linking the bank account, resolving a previous import failure.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974 Forward-Port-Of: odoo/odoo#268011 Forward-Port-Of: odoo/odoo#261933
This update corrects an issue where the balance sheet report was generating incorrect data due to missing or incorrect values in specific XML fields. The changes ensure these fields (2955 and 2956) are always set to zero, aligning with Luxembourg's eCDF reporting requirements. This prevents report rejections and ensures accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update corrects a technical issue where archived delivery carriers were being unintentionally included in the carrier selection process. Previously, the system would pass information about inactive carriers, leading to incorrect choices in the delivery wizard. This change ensures only active carriers are considered, improving data accuracy and usability.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264324 Forward-Port-Of: odoo/odoo#263819
6 changes
Resolved issues and error corrections
This update resolves an issue where a traceback error occurred when changing POS configurations in the kitchen display setup. The fix ensures that the preparation display correctly handles orders even after a POS configuration change, improving stability and preventing disruptions to order processing. This enhances the reliability of the Point of Sale system.
Original PR description
Steps: = - Create a kitchen display linked to any one Point of Sale. - Open the POS, create a draft order, and send it to the kitchen display. - Open the kitchen display configuration from the backend and change the POS configuration to a different one. - Open the kitchen display again. Issue: = - A traceback occurs when opening the preparation display after changing the POS configuration while orders from the old configuration are still open and linked to selected kitchen display. Fix: = - Apply a POS config domain while fetching open orders for the preparation display to avoid processing orders from old configurations, eliminating the traceback. task-6196096 Forward-Port-Of: odoo/enterprise#116696
This update introduces a new wizard that allows administrators to revert previously generated payslips. This provides greater flexibility in correcting payroll errors and ensures accurate record-keeping for Belgian companies using the Odoo Enterprise HR Payroll module. The change improves data accuracy and compliance.
Original PR description
Task: 6117478
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system safely ignores these errors, ensuring the 'Get Pictures from Barcode Lookup' action continues to function without interruption.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**
Forward-Port-Of: odoo/enterprise#116925This update resolves an issue that occurred when duplicating Odoo databases used for testing the German POS certification module. Specifically, the system now correctly handles the removal of identifying information (client_id and tss_id) during database duplication, preventing errors and ensuring proper functionality in test environments. This ensures consistent and reliable testing of the module.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update simplifies the tour selector within Web Studio. The previous logic was no longer needed due to a change in how the Kanban dropdown toggle is displayed. This adjustment ensures the tour selector functions correctly and efficiently, streamlining the user experience.
Original PR description
Since the visibility of the kanban dropdown toggle is now always visible when the media query 'pointer: fine' isn't met, in the case of this tour, it is no longer useful to check for the non visibility of the element in the selector. task-6259816
This update ensures consistent behavior across Odoo by adapting how live chat and VoIP features are initialized. The change aligns with recent community updates, streamlining the process and improving the reliability of these core services.
Original PR description
The community counterpart of this PR removed the `onStarted` method as overrides should all use `initialize`. This commit adapts the enterprise modules. community: https://github.com/odoo/odoo/pull/267160
6 changes
Resolved issues and error corrections
This update fixes a calculation error in Odoo's Point of Sale integration with UrbanPiper. Previously, tax was incorrectly displayed on online orders with 'tax included' products. The fix ensures that the displayed unit price and tax-inclusive price accurately reflect the total cost, improving order accuracy for customers.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update resolves an issue that prevented successful testing of the l10n_de_pos_cert module when duplicating databases. Specifically, the commit removes identifying information (client_id and tss_id) during database duplication, allowing for proper testing in neutralized environments. This ensures consistent and reliable testing of the German POS certification functionality.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update resolves a technical problem preventing the correct display of the daily report title in POS reports. The change ensures compatibility with a related reporting module and corrects a previous bug where the report would render without a title when the Colombian tax module was not enabled. This improves the user experience and report accuracy.
Original PR description
The daily report template was replacing `//h2[@id='daily_report_title']` entirely, removing the node from the XML source. This caused `pos_hr.single_employee_sales_report` (a primary template that applies its own xpaths against the same patched base) to crash at compile time since its xpaths could no longer find that node. Switch from `position="replace"` to `position="attributes"` + `position="after"`: the h2 stays in the XML source at all times so pos_hr's xpaths always resolve, while the original title is hidden at render time via t-if when CO EDI is enabled and the Colombian content is inserted as a sibling after it. As a side effect, this also fixes a pre-existing bug where installing the module with DIAN disabled would render the daily report with no title at all. opw-6265637
This update corrects a previous issue where website orders automatically generated CFDI invoices publicly. Now, invoices are only created publicly when a customer provides all necessary information through the e-commerce platform, aligning with standard business practices. This ensures compliance and avoids unnecessary public invoice disclosures.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119442 Forward-Port-Of: odoo/enterprise#116061
This update resolves a technical issue that was preventing users from accessing billing targets within the Timesheets module. The fix addresses a problem caused by a missing field required by a core component of the Timesheets functionality. Enabling billing rate indicators and specific user access configurations were necessary to trigger this issue, and the update ensures a smoother workflow for managing billable time.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports. Specifically, the XML files now ensure that fields 2955 and 2956 are always set to zero, as required by Luxembourg's eCDF reporting standards. Failure to adhere to these standards previously resulted in report rejections.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
4 changes
Resolved issues and error corrections
This update resolves an issue that prevented PDFs from being attached to invoices when using the Nilvera e-invoicing client. The change ensures compatibility with Python 3.14's stricter base64 validation, allowing the system to correctly handle the raw PDF data.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update resolves an error that occurred when generating payment reports for Swiss companies. The issue was triggered when the 'hr_payroll_account_iso20022' module wasn't installed. The fix ensures the system handles missing module configurations gracefully, preventing the report generation process from failing.
Original PR description
*=l10n_ch_hr_payroll,hr_payroll_account_iso20022 When clicking the create payment report button on a payslip for a Swiss company, a traceback occurs if the ``hr_payroll_account_iso20022`` module is…
*=l10n_ch_hr_payroll,hr_payroll_account_iso20022 When clicking the create payment report button on a payslip for a Swiss company, a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed. Steps to reproduce the error: - Install ``l10n_ch_hr_payroll`` module - Switch to CH Company - Create an Employee and running contract for it - Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report Traceback: ```py ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch' ``` https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13 Here, ``iso20022_ch`` is passed as ``export_format``, However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1]. When that module is not installed, the selection value does not exist, leading to the above error. [1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11 sentry-7391832811
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports due to incorrect data in XML fields. Specifically, fields 2955 and 2956 must be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the eCDF, preventing data rejection and maintaining accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update fixes a calculation error in the purchase order reporting, ensuring the 'Effective Days To Arrival' metric accurately reflects the time between order confirmation and receipt. Previously, the calculation was flawed, leading to incorrect lead time reporting. This change improves the accuracy of purchase data analysis.
Original PR description
Steps to reproduce --- 1. Confirm a purchase order and receive it a few days later. 2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure. Observed: the value is…
Steps to reproduce --- 1. Confirm a purchase order and receive it a few days later. 2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure. Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date. Issue --- The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573). The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the scheduled date and the receipt) rather than date_done - date_order. https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28 opw-6226523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update fixes a bug where untaxed invoice lines were incorrectly inheriting the Datev code from the previous line. The fix ensures that untaxed lines now properly have an empty Datev code, resolving a discrepancy in the Datev export file. This ensures accurate reporting for German tax compliance.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003