Friday, April 17, 2026
23 changes · saas-19.2
Enhancements to existing features
This update simplifies the Balance Sheet in both the generic and US versions of Odoo, making it clearer to distinguish between 'Earnings' and 'Equity'. The changes enhance the chart of accounts to better track the allocation of earnings, providing a more organized view of financial reporting.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259485 Forward-Port-Of: odoo/odoo#256674
This update enhances the accuracy of product imports by making the matching process case-insensitive and using a similarity ratio. Previously, exact matches were required, leading to missed products. Now, a 90% similarity threshold is used to find more relevant matches, improving data import reliability.
Original PR description
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match…
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`. - Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with `Wireless bluetooth speaker battery`), leading to unrelated matches. After this commit: - Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`. - Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names. Technical: - Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive. - Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match. - Added system parameter for configurable product name similarity threshold. task-5951469 Forward-Port-Of: odoo/odoo#258709 Forward-Port-Of: odoo/odoo#252147
This update automatically handles new offer amendments as contract revisions, ensuring accurate tracking of employee contracts. It proactively archives outdated versions and provides a warning to users, preventing data conflicts and maintaining data integrity. The changes improve the system's ability to manage evolving salary agreements.
Original PR description
**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new…
**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract. * For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract. * When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data. * Added a warning to notify users when a new offer will replace existing future versions. **Technical Refactoring** * Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's * Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation. **Simulation & Chatter** * Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors. * To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`. * Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution. task: 5408192 Forward-Port-Of: odoo/enterprise#103846
This update simplifies the balance sheet reports to clearly separate 'Earnings' and 'Equity' accounts, enhancing financial reporting clarity. The changes improve the presentation of key financial data in both the standard and US versions of the balance sheet, making it easier to understand financial performance.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 Forward-Port-Of: odoo/enterprise#114012 Forward-Port-Of: odoo/enterprise#112499
Resolved issues and error corrections
This update adjusts how Odoo assigns leads to sales team members. Previously, team members with specific preferences received too many low-probability leads. Now, leads are prioritized by probability, ensuring the most suitable team members receive the highest-quality opportunities, leading to better sales efficiency.
Original PR description
Since we've added the preferred domain field, the leads are firstly assigned to members matching the preffered domain. The issue with this behavor is that a memeber with prefered domain can get a lot of leads with low probability because they match his preferred domain. So we process the leads in the order of probabilities and if it match a preferred domain, it'll be assigned to the member, and if not we choose one without the matching preferred domain. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that table assignments are consistently synchronized across all devices within a POS session. Previously, a waiter selecting an empty table wouldn't update its status on other devices. This fix corrects this issue, improving the accuracy of table availability information for all users.
Original PR description
When a waiter selects a table without adding any items and returns to the floor screen, the table appears as occupied (green) on their device but not on other devices in the same POS session. Steps to reproduce: ------------------- * Open POS session on device A * Open same POS session on device B * On device A: click a table, don't add items, go back to floor * On device B: observe the table does not appear as occupied > Observation: Empty table assignments were not being synced to the server, so other devices couldn't detect the table occupancy. Why the fix: ------------ Also treat orders with a table_id as pending so they sync immediately when a table is opened. The backend already supports this: pos.order can be created with just table_id, and pos_restaurant._get_open_order looks orders up by table_id for table-based sync. opw-5236119 Forward-Port-Of: odoo/odoo#241321
This update clarifies ledger reports by displaying the company name alongside each journal when selecting journals within a journal group. Additionally, the system now includes archived journals in ledger calculations, ensuring more complete financial reporting across multiple companies. This enhancement improves data accuracy and provides a more comprehensive view of financial activity.
Original PR description
In multi-company, when choosing the included journals of a journal group, display the name of the journal's company before the journal name. Also, add the 'active_test=False' context for the journal in the ledgers in order that ledgers also take into account the archived journals. task-6111366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a limitation where users couldn't edit images (resize, crop, etc.) when replacing them on product pages. The change ensures that editing options are only displayed for images that are *not* recently uploaded, streamlining the user experience and preventing unexpected behavior. This improves the visual consistency of product listings.
Original PR description
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only…
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size. ## Steps to reproduce 1. Install the *eCommerce* (`website_sale`) app. 2. Create a product and set a picture for it. 3. Go to that product's page in the Website app and open the website editor. 4. Click on the picture and replace it. 5. **The options to transform the picture are not displayed.** ## Cause The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16 ## Solution We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173 We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo. On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are: - Description - Tooltip - Transform (*"Transform the picture"*) - Size ## Tests The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it. https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16 ## Options displayed | | Before this commit | After this commit | Previous versions | |---|---|---|---| | **Before replacing the image** | Media, Re-order | Media, Re-order | Media, Re-order | **After replacing the image** | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality opw-5251864 Forward-Port-Of: odoo/odoo#247706 Forward-Port-Of: odoo/odoo#241071
This update fixes an issue where the average cost calculation in the 'Inventory at Date' report was inaccurate for products using the AVCO cost method. The fix ensures that the average cost is correctly calculated based on actual transactions, preventing discrepancies in inventory valuation. This improves the reliability of stock reporting.
Original PR description
When we open the Stock report at date, we filter out moves anterior to that date and, if the cost method is AVCO, Odoo recompute the `avg_cost` up to that point of time with `_run_average_batch`. However, when iterating over the moves, `move._get_value(at_date)` might return a value calculated from the current standard_price if the move is not associated with any accounting entry or PO/SO. Steps to reproduce the issue: 1. Create a new product with AVCO cost method 2. On the product form, set the cost to 5$ 3. Manually adjust the inventory to 5 units 4. Create a PO and receive 5 products at a unit cost of 10$ > Total value: 75$ > Total quantity: 10 units > avg_cost: 7.5$ 5. Navigate to Stock report and run "Inventory at Date" at current time 6. avg_cost is 8.75$ instead of 7.5$ Ticket: opw-5951072 Forward-Port-Of: odoo/odoo#253659
This update fixes an issue where refund orders paid with eWallet top-ups weren't correctly identified as refunds, leading to incorrect invoice generation. The fix ensures that refund flows, including those using eWallet, are accurately processed, producing the correct accounting documents and tax calculations. This improves the reliability of our point-of-sale accounting.
Original PR description
[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs Refund orders paid through eWallet top-up can have a net total of 0, which made refund detection based only on negative…
[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs Refund orders paid through eWallet top-up can have a net total of 0, which made refund detection based only on negative totals inconsistent. As a result, some refund flows were treated as normal invoices and refund tax/invoice signs were incorrect. Steps to reproduce: ------------------- * Configure an eWallet program in POS. * Create and pay a POS order for one product, then invoice it. * Refund that order and choose eWallet as refund payment method (refund + top-up). * Validate and inspect the generated accounting document. > Observation: The refund flow may not be consistently treated as a refund when the order’s net amount is 0, causing incorrect invoice move type/sign handling and wrong tax booking behavior. Why the fix: ------------ Refund detection now also relies on `refunded_order_id` in key paths: * `_compute_prices`: apply refund factor when order is linked to a refunded order (or already negative), so totals/taxes keep refund semantics. * `_prepare_invoice_vals`: create `out_refund` when the order is linked to a refunded order (or has negative total), ensuring a credit note is produced. * `_prepare_base_line_for_taxes_computation`: consider refund context with `is_refund` or negative total for tax base sign consistency. This keeps existing negative-total refund behavior while correctly handling refund+eWallet cases where the arithmetic total can be 0. opw-5426818 Forward-Port-Of: odoo/odoo#259217 Forward-Port-Of: odoo/odoo#247948
This update fixes an issue where the unit cost of products was incorrectly calculated when considering stock held in internal locations like subcontracting warehouses. The change ensures accurate valuation by properly accounting for all relevant stock locations, leading to more reliable inventory reporting. This resolves discrepancies in reported values.
Original PR description
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can…
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273 2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65 ### Steps to reproduce: - In the settings enable Multi-Steps Routes - Create a storable with an avco perpetual valuation with a cost of 5$ - Click the `On hand` smart button > Update Quantity - Put 1 unit in WH/Stock and 2 units in Subcontracting - Go to Inventory > Reporting > Stock #### > The unit cost of your product is 15$ instead of 5$ - Click on locations on the line and remove the `internal` filter #### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$ ### Cause of the issue: The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines: https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363 ### Additional issue: The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it. opw-5959720 opw-5883980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257103
This update resolves an issue where the chat composer on mobile devices would become unresponsive when the mobile menu was open. The fix prevents the mobile menu from stealing focus from the composer, ensuring users can consistently access and use the chat feature. This improves the mobile user experience.
Original PR description
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.…
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open. https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef Steps to reproduce: 1. Open the website in a mobile view. 2. Tap the navbar toggler to open the mobile menu. 3. Without closing the menu, open the chat window. 4. Tap on the message composer text area. → The composer is not accessible. This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard. This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus. Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259486 Forward-Port-Of: odoo/odoo#250294
This update fixes an issue where offline POS orders were incorrectly having their payment dates automatically updated to the current date. Previously, when these orders were imported into the POS system, the payment date would be overwritten. This change ensures that the original, saved payment date for offline orders is preserved, improving order accuracy and preventing potential discrepancies in reporting.
Original PR description
Before this commit, saved orders that were captured offline, would have their payment_date overridden to the current date when they were loaded in the POS. opw-6117966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259114
This update fixes an issue where MyInvois was incorrectly reducing invoice amounts due to pre-payments on individual POS e-invoices. The change ensures the Total Amount Payable accurately reflects the e-document's total amount, aligning with MyInvois requirements and preventing discrepancies.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#259339 Forward-Port-Of: odoo/odoo#258824
A technical issue causing negative values in the Luxembourg tax report has been resolved. The formula for a specific tax line (226) was incorrectly calculated, leading to inaccurate reporting. This update corrects the formula to ensure accurate tax reporting for Luxembourg companies.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/odoo#259388
This update resolves an access error that prevented users from correctly adding TDS entries when working within a branch company setup in India. The fix ensures the system uses the correct company ID for currency calculations, granting the necessary permissions for branch operations. This improves functionality for businesses operating with multiple company branches.
Original PR description
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator**…
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company. * Login from this user . * Create and confirm a vendor bill in the branch company. * Click **TDS Entry** and select any TDS section. **Observed behavior:** * An **AccessError** is raised when selecting the TDS section. **Cause:** * In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`. * For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent. * The user operating in the branch company does not have access to the parent company, triggering an access error. **Fix:** * Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency. * The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights. **Note:** * Regression test is not feasible due to ORM cache behavior: * In tests, `mock` environments share a transaction-level cache. * `compute_sudo=True` fields populate cache with superuser access. * By the time `_compute_amount` runs, values are already cached. * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced. opw-6095312 Forward-Port-Of: odoo/odoo#259091
A bug was causing mobile self-orders to incorrectly appear in order lists for different Point of Sale (PoS) configurations within the same company. This fix corrects a filtering issue that was pulling in orders from all configurations, ensuring that mobile orders are only displayed within their intended PoS setup (kiosk or trusted).
Original PR description
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back,…
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back, open Restaurant, click on Orders tab -> The Bar's self-order shows up in the Restaurant's order list. What's happening ---------------- In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company. But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config). The fix ------- We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method. opw-6068187 Forward-Port-Of: odoo/odoo#258712
This update ensures that live chat agents can consistently see and use the live chat button while actively engaged in existing conversations. Previously, agents couldn't initiate new chats while already part of an active live chat. This improvement streamlines the user experience for live chat support.
Original PR description
Previously, users who were part of active livechats as agents could not see the livechat button to start a new conversation. This change ensures the button remains visible so users can start additional livechats as a visitor. task-[5119098](https://www.odoo.com/odoo/project/1519/tasks/5119098) Forward-Port-Of: odoo/odoo#258884 Forward-Port-Of: odoo/odoo#253894
This update resolves an issue where date filters in financial reports were incorrectly displaying calendar year ends when using custom fiscal periods. The fix ensures that reports accurately reflect the user-defined fiscal year, improving the reliability of financial data presented to users. This change impacts how financial reports are generated and interpreted.
Original PR description
To reproduce, we set a fiscal year in the settings for instance(31 March). Next, we open the balance sheet and in the report settings, disable use_fiscal_periods. Then back on the report, we open the date filter and set a custom date to the fiscal year end. This would show the calendar year end. This is because when we are in a custom period, we try to infer a period from the user input.
This update addresses a regulatory requirement in Mexico regarding electronic payments (CFDI). The system now prevents users from registering payments with future dates, which were previously allowed and not compliant with government regulations. This ensures accurate reporting and avoids potential issues with tax authorities.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#114038 Forward-Port-Of: odoo/enterprise#112320
This update addresses an issue where delivery confirmations were failing due to missing tracking data from Easypost. The fix prevents errors when tracking information is unavailable, ensuring accurate picking validation and correct shipping creation in Easypost. Easypost support suggested a slight delay between order placement and tracking retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#111833
A technical issue causing negative values in the Luxembourg tax report's calculations has been resolved. The formula was incorrectly referencing a negative value, leading to inaccurate reporting. This update corrects the formula to display credited amounts as positive values, ensuring accurate tax reporting for Luxembourg companies.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/enterprise#113952
This update fixes an issue where subscription invoices were incorrectly calculating due dates when upsells with deferred payment dates were present. The change prevents upsell invoice lines from influencing the next invoice date calculation, ensuring accurate and timely billing for subscription customers.
Original PR description
When we compute the next invoice date of a subscription, we are checking all account move lines of the invoices linked to the subscription. But if we have an upsell with a deffered date higher than the next invoice date that should be calculated, it will set a too high next invoice date. To avoid this issue, we don't take into account the invoice lines linked to upsell to compute the next invoice date Forward-Port-Of: odoo/enterprise#113170