Thursday, December 18, 2025
10 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue that previously caused errors when processing invoices with reverse charge accounting (BIS3) in Japan. The fix ensures invoices are correctly generated and transmitted, improving the reliability of financial reporting. This change impacts how invoices are handled for businesses using the Odoo accounting module.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240275
This update resolves an issue where assigned values in project task properties would disappear after saving. The fix ensures that property values are correctly saved and retained, improving the usability of the project task management feature. This change was made to enhance data integrity and prevent user frustration.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238052
This update resolves a bug where currency conversion rates weren't being created with the correct date, leading to inaccurate tax calculations for non-UYU currencies. The fix ensures all rates are now generated with today's date, improving data accuracy and financial reporting for companies using currencies other than UYU.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065
This update fixes an error in how sales margins are calculated for multi-currency transactions. The previous calculation was producing an incorrect margin figure due to a bracket issue. The fix ensures accurate margin reporting by applying the correct formula, resulting in a more reliable view of sales profitability.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost…
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost price (300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation ( for TWD currency , multiply with currency rate) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Before <img width="687" height="97" alt="image" src="https://github.com/user-attachments/assets/3a821a5c-eb12-4eae-9465-1702e9d4ac97" /> After <img width="679" height="110" alt="image" src="https://github.com/user-attachments/assets/d62dbb1d-6839-4099-90b1-6f9a19576721" /> opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239407
This update resolves an issue where ECO applications incorrectly linked product documents to attachments, leading to database errors. The fix ensures that ECOs correctly reference the associated attachments, preventing application failures and data inconsistencies. This improves the reliability of ECO implementation.
Original PR description
When applying an ECO, the system incorrectly sets the origin_attachment_id of a product.document to a product.document record itself instead of its related ir.attachment. As a result, if the incorrectly referenced ir.attachment is missing, the ECO will attempt to reference a record that does not exist, leading to a foreign key violation during action_apply. Steps to reproduce: 1.) Create an mrp.eco record 2.) Upload a document, take note of the product.document ID 3.) Unlink the ir.attachment with ID = (document ID + 1) (+1 is to account for the .copy within action_apply) 4.) Run eco.action_apply 5.) Observe SQL Constraint Expected result: The ECO should correctly link the product.document to its related ir.attachment. Actual result: origin_attachment_id may point to an unrelated ir.attachment, causing constraint violations when those attachments do not exist. opw-5050263 Forward-Port-Of: odoo/enterprise#94958
This update resolves a bug preventing users from adding products to invoices when navigating from a project task using the invoice smart button. The issue stemmed from differing context settings between accessing the invoice from a sale order versus a task, impacting the product search domain. This ensures consistent functionality across all invoice access methods.
Original PR description
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce:…
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce: ------------------- * Create a product - Purchase: False - Sale : True * Create a fsm task * Add products * Go to the sale order * Create the invoice (regular invoice) * Go back to the task * Go to the invoice using the invoices smart button * Try to add your product -> issue it's not possible. Observation: --------------- The domain of the search is not the same if we go from the sale order or from the task. This is because the domain depend on the context and the context is not the same : [Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141) When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice": [SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453) Instead when using it on the task, the context does not have that element: https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327 This will be calculate here in the js files: [evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400) opw-5135567 Forward-Port-Of: odoo/enterprise#101938 Forward-Port-Of: odoo/enterprise#98612
This update resolves an issue where duplicate gift cards were being created during order synchronization with preparation displays. The fix ensures that a key processing step is properly waited on, preventing the system from incorrectly handling loyalty points multiple times. This improves the accuracy of gift card usage and prevents potential customer confusion.
Original PR description
Before this commit, it was possible that double gift cards were created when syncing orders with preparation display. This was due to the fact that the postSyncAllOrders method was not awaited, leading to duplicate processing of loyalty when calling syncAllOrders twice. opw-5246407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235956
This update ensures that only administrator users can override the 'Maximum closing difference' setting when closing a point-of-sale session. Previously, users could override this limit regardless of their role. This change enhances security and prevents unauthorized adjustments to financial data, aligning with best practices for financial control.
Original PR description
Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos. Steps to reproduce:…
Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos. Steps to reproduce: ------------------- * Set max closing difference as 0 * Have 1 admin user and 1 pos user * Have 2 employees * Set admin user and employee 1 as advanced employees of the pos * Set pos user and employee 2 as basic employees Steps with admin: * Make sure you are logged as the admin in the database * Open pos (could be a session opened by other user) * Log in with Admin user * Try to close the pos with a difference of 10 -> You can, ok * Log in with employee 1 (advanced) * Try to close the pos with a difference of 10 -> You ca but shouldn't Steps with pos user * Now log in the database as pos user * Open pos (could be a session opened by other user * Log in with employee 1 (advanced) * Try to close the pos with a difference of 10 -> You cannot, ok * Log in with Admin user * Try to close the pos with a difference of 10 -> you cannot but should Why the fix: ------------ Employees that have no linked user should not ba able to override the max difference. Employees who have a connected user should only be able to override the max difference if their user is admin of the pos. opw-5184041 Forward-Port-Of: odoo/odoo#239770 Forward-Port-Of: odoo/odoo#235356
This update fixes an issue where subscription payments failed due to missing country information. The change ensures that subscriptions, even for services, correctly require a country to be set during checkout, preventing payment failures and improving the reliability of recurring invoices. This resolves a technical glitch impacting subscription billing.
Original PR description
## Versions saas-18.3 > saas-18.4 Backport of OE's commit c02eb8584da1cef7d28310d9be947b56a38a5cbd ## Issue A customer subscribing to a service can checkout without filling its data (incl. country).…
## Versions
saas-18.3 > saas-18.4
Backport of OE's commit c02eb8584da1cef7d28310d9be947b56a38a5cbd
## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".
## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
- Look for a subscription service (ending with "SUB") and add it to cart;
- Go to the cart and click the checkout button (automatically bypassing the addresses form);
- Pay with Demo.
- Logout and sign in as admin user:
- Go to Sales and open the latest SO (related to the test user):
- Duplicate the SO and activate debug mode;
- Open "Other Info" tab:
- Change the subscription starting date for any date in the past;
- Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
- Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
- Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
- OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".
## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757
opw-5412037This update resolves an issue where VAT reports were incorrectly setting the 'Client Nihil' field to 'YES' outside of the allowed year-end timeframe, as per Belgian regulations. The pull request restores the checkbox option for this setting, ensuring accurate VAT report generation. This prevents potential reporting errors and compliance issues.
Original PR description
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year…
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf ## Cause: Prior to 18.3, nihil was a checkbox option on export Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date This PR brings back the Client Nihil checkbox in 19.0 But didn't change the default value Causing the issue to still be present https://github.com/odoo/enterprise/pull/99496 ## Steps to reproduce: - Select the Belgian company - Open the Tax Return and select the VAT Return - Click Returns and enter an opening date in January - Click Review for the first available report - Ignore errors and return to previous page - Click on Submit -> Download XML - Before the fix, ClientListingNihil is set to YES ## Potential remaining issue: The legal document specify that it should also be checked in case of "cessation d’activité" So it may be interesting to consider adding the option back opw-5184056