Wednesday, October 1, 2025
19 changes · 19.0
Resolved issues and error corrections
Invoices with early payment discounts are no longer treated as fully paid when the customer pays the discounted amount after the discount deadline. This prevents underpaid invoices from being closed automatically and keeps the remaining balance visible for follow-up.
Original PR description
Purpose: With [commit], a bank line with an amount slightly less than the invoice (within 3% tolerance) marks the invoice as fully reconciled. However, this can be confusing with early payment discounts, as an invoice paid after the discount period and even with the discounted amount may also appear fully reconciled due to the 3% tolerance. After this commit: In case of early payment discount and payment after the discount, 3% tolerance is not applied, so If discounted amount is paid then invoice is only partially reconciled. task-5090274 [commit]: https://github.com/odoo/enterprise/commit/9bea3f2c517e77fdb822eb53b9648e9fc5478dac
Spanish TicketBAI POS orders now automatically retry the earlier failed submission when a new order is paid. This helps prevent one failed posting from blocking later sales from being reported, reducing manual follow-up and compliance delays.
Original PR description
Currently, the post failure of a single pos order can easily cause a backlog of more unposted orders since new orders will not be posted until the chain head is posted. Steps to reproduce ----- 1. Validate a pos order and have the TicketBAI post fail 2. Validate another pos order 3. The post for the second order is never attempted Cause ----- `_check_can_post()` ensures that new orders are not posted if the chain head was not posted successfully. During normal operation, it is common for many new orders to be paid before the user has a chance to manually retry the chain head post in the backend, causing a backlog of unposted orders. Solution ----- During `action_pos_order_paid()` retry the chain head post if is not sent. opw-4669823 Forward-Port-Of: odoo/odoo#229180 Forward-Port-Of: odoo/odoo#228477
Swedish Bankgiro and Plusgiro accounts are now handled correctly when generating SEPA payment files and Peppol invoice XML. This prevents missing bank details and helps ensure Swedish payments and e-invoices can be processed successfully.
Original PR description
Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts. This commit introduces overrides for SE-specific account types: _get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML. _skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file. This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries.
Point of Sale receipts now show the selected shipping date correctly for users in timezones behind UTC, such as US timezones. This prevents customer receipts from displaying the previous day when Ship Later is used.
Original PR description
In this bug, the shipping date in pos receipt is set to previous dates. To reproduce the bug: 1- Setup a database with point_of_sale app installed 2- In configuration -> Setting, check Allow Ship Later option for a pos shop. 3- Change the browser timezone to a US timezone. In chrome it can be in Console -> Sensors -> Location. 4- Open POS register, select a product, choose payment and use Ship Later, to pick a date. 5- After validating the order, you can see the wrong shipping date is shown in the recipt. This is related to #215140 in which the shipping date bug is fixed when the date is picked. However, in generation of receipt a new PosOrder object is created, in which there is a need to explictly deserilizing shippingDate to avoid unwanted timezone effects. opw-5009476 Forward-Port-Of: odoo/odoo#224586
The product image viewer now keeps the selected thumbnail centered when shoppers browse many product images, preventing thumbnails from being cut off at the screen edges. This makes image browsing easier, especially for products with large galleries, and adds smoother swipe navigation on mobile.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Add a bunch of extra images to a published product; 2. enable zoom-on-click via editor; 3. click on an image to zoom it; 4. scroll through images. Issue ----- With too many images added, the thumbnails on the bottom are cut off on the edges of the screen, making it impossible to click on them. Cause ----- The thumbnail row element doesn't get updated when selecting a new image. Solution -------- Define a `_updateCarousel` method which adds a `transform: translate` operation to the thumbnails, moving them such that the currently selected image's thumbnail gets centered on the screen. Call this method on mounting, and again on any render (image change). Bonus: add `touchstart` & `touchmove` hooks to enable easy swiping through the carousel on mobile. opw-4937009 opw-4908881 Forward-Port-Of: odoo/odoo#229256 Forward-Port-Of: odoo/odoo#224981
This fix restores the initialization needed for Turkish localization reports to load correctly. It resolves failures such as the Turkish General Ledger report not opening, helping affected users access required accounting reports again.
Original PR description
## Before this commit: The referenced commit removed `from . import models` from the module’s `__init__.py`. As a result, the files inside `l10n_tr_reports/models/` (such as `account_general_ledger.py`) were not loaded. This prevented their logic from being executed and caused issue like the Turkish General Ledger report to fail to load. Ref commit: https://github.com/odoo/enterprise/commit/a86bc92f9358eed458872a3e60d5c3c791b3860c ## After this commit: Reintroduced the missing import in `__init__.py`, ensuring that the models package is initialized correctly and all related reports and functionality work as intended.
Field service tasks now use the customer’s assigned pricelist when creating service lines on sales orders. This ensures quoted service prices match customer agreements instead of falling back to the product’s default price.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#95744 Forward-Port-Of: odoo/enterprise#88039
Fixes an issue where editing budget amounts after changing date ranges could trigger an error and block users from updating the budget report. The system now matches budget items to the correct monthly period, preventing duplicate incomplete items and keeping budget editing reliable.
Original PR description
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting`…
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting` module. - Go to `Profit and Loss` > `Budget` and `create a budget`. - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line. - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again. - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more. `TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'` This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`. This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained.. [1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49 [2]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79 [3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72 [4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61 sentry-6883207225 Forward-Port-Of: odoo/enterprise#95090
This fixes how Odoo calculates past stock quantities when using strict location rules. Outgoing stock moves are now correctly counted, improving inventory accuracy for historical stock checks.
Original PR description
Description of the issue/feature this PR addresses: - Basic calculations of past quantities with context "strict" miss all "out" stock moves due to the poor domain. Current behavior before PR:…
Description of the issue/feature this PR addresses:
- Basic calculations of past quantities with context "strict" miss all "out" stock moves due to the poor domain.
Current behavior before PR:
Getting a stock quantity in a "strict" context returned a malformed out domain
domain_move_in:
['&', ('location_dest_id', 'in', [879]), ('location_id', 'not in', [879])]
correct - source location is not stock and destination is stock
domain_move_out :
['&', ('location_id', 'in', [879]), ('location_dest_id', 'in', [879])]
incorrect - both source and destination are the same
Desired behavior after PR is merged:
The domain is correct:
domain_move_in :
['&', ('location_dest_id', 'in', [879]), ('location_id', 'not in', [879])]
still correct
domain_move_out :
['&', ('location_id', 'in', [879]), ('location_dest_id', 'not in', [879])]
destination is now "not" stock
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen a cashier selects a customer in Point of Sale and opens quotations or orders, the list now shows only that customer's records. This prevents confusion, reduces the risk of choosing the wrong order, and makes customer service faster.
Original PR description
Before this commit, when selecting a customer in the POS and clicking Actions → Quotation/Order, all quotations and orders were displayed instead of filtering by the selected customer. This commit ensures that only the quotations/orders of the selected customer are shown. opw-5074052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228795 Forward-Port-Of: odoo/odoo#227448
Deleting a countdown block in the website editor no longer leaves background activity running after the block is gone. This prevents repeated errors and helps keep the editing experience stable when content snippets are removed.
Original PR description
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed…
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed by `DeletePlugin`, the interaction is not destroyed, and a recurrent interval keeps expiring every second triggering multiple errors. This commit introduces the following changes: 1. `EditInteractionPlugin.refreshInteractions`, which is called on normalization, now checks for every interaction and destroyes the ones linked to a disconnected DOM element. 2. `websiteEditService.refresh` now checks if the target element is disconnected, and in this case stops the interaction. 3. `Countdown` now uses the `waitForTimeout` function, which does not execute any callback if the interation has been destroyed. How to reproduce the problem with `s_countdown`: 1. Insert the snippet `s_text_block` 2. Insert the snippet `s_countdown` in the middle of the text 3. Place the cursor after the countdown 4. Press "backspace" until the countdown is deleted 5. The error appears (Alternatively, place the cursor before the countdown and press delete, or select a portion of text including the countdown and press backspace). task-4367641 Forward-Port-Of: odoo/odoo#225922
This fix ensures the IoT Box browser reopens using the web address saved in its configuration file, including after a reboot. It prevents the browser from falling back to an outdated database value when only screen orientation settings are updated.
Original PR description
The browser on the IoT Box was always reopening on the url saved in the database instead of the one saved in odoo.conf. When opening the browser, we used to set the orientation and save it in the configuration. As we only set the orientation and not the url at this point, we were mistakenly removing the url from odoo.conf. As it was not set anymore, when reopening the browser later (e.g. after reboot), no url was available in conf, so we fell back on the db's one. Task: 5103536 Forward-Port-Of: odoo/odoo#229002
Manufacturing reports now correctly include estimated employee costs when calculating operation costs. This gives teams a more reliable view of production and cost analysis, helping them compare expected and actual manufacturing expenses.
Original PR description
Make sure that operations with estimated costs are correctly computed in the Cost Analysis Report and the Production Analysis Report. task 4896715 Forward-Port-Of: odoo/enterprise#89135
Scanning a loyalty card barcode in Point of Sale now selects the linked customer instead of showing an invalid code error. This helps cashiers apply loyalty details smoothly and reduces checkout friction for customers using loyalty cards.
Original PR description
When scanning the barcode of a loyalty card, there was an error saying the code is invalid. Instead it should select the partner linked to the card if there is one. Steps to reproduce: ------------------- * Create a loyalty program, and a loyalty card with a partner * Copy the barcode of the loyalty card * Open the POS, and scan the barcode of the loyalty card > Observation: The error "Invalid code" appears, and the partner is not selected opw-4653983 Forward-Port-Of: odoo/odoo#228002 Forward-Port-Of: odoo/odoo#213831
Payroll accounting entries now correctly use analytic distributions when allocating costs. This helps ensure payroll expenses are assigned to the right departments, projects, or cost centers for more accurate reporting.
Original PR description
In this PR we fix some code that was not adapted for analytic distributions
The update stops users from removing the journal linked to an active payment provider. This prevents payment attempts from failing later due to missing accounting journal information, especially in branch company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an active payment provider; 2. create a branch company; 3. set payment provider's company to branch; 4. leave Payment Journal unchanged (parent company Bank); 5. go to Accounting / Configuration / Accounting / Journals; 6. open Bank journal; 7. open "Incoming Payments" tab; 8. enable the "Payment Provider" column; 9. unset the payment provider on the active provider's line & save; 10. attempt paying using the provider. Issue ----- > Error: psycopg2.errors.NotNullViolation: > null value in column "journal_id" of relation "account_payment" violates not-null constraint Cause ----- We shouldn't be able to change the related journal of active providers. Solution -------- Make the field read-only if the payment method is active. opw-5045000 Forward-Port-Of: odoo/odoo#229342 Forward-Port-Of: odoo/odoo#225187
Stripe payments now handle currencies like Ugandan shillings that use different decimal rules in Stripe than in Odoo. This prevents valid card payments from being rejected or sent with the wrong amount for affected currencies.
Original PR description
Steps: - Activate the 'UGX' currency. - Make a sale order with amount 100 with 'UGX' currency - Try to pay that order (100 USh) using card Issue: - stripe throws the following error - > 'The Checkout Session's total amount must convert to at least 50 cents. 1.00 USh converts to approximately €0.00.' - Hence 100 USh sent was identified as 1 USh by stripe. This confirms issue with decimals and currency mapping. Cause: - 'UGX' is zero-decimal currency but stripe identify it as two-decimal. Fix: - Update mapping for such special currency cases for stripe that don't follow general rules opw-5075707 Forward-Port-Of: odoo/odoo#227688
Fixed an issue where using Put in Pack from a selected delivery move line could incorrectly add all move lines to the chosen package. This ensures warehouse users package only the item they selected, reducing packing mistakes and delivery inaccuracies.
Original PR description
Steps to reproduce the bug:
- Create two storable products, e.g., “P1” and “P2”.
- Create a delivery:
- Add one unit of each product.
- Add any carrier (e.g., DHL).
- Mark the picking as "To Do".
- Set the quantity to 1.
- The move lines are created.
- Click on the Moves smart button.
- Select any move line (ML).
- Click Put in Pack.
- A wizard is triggered.
- Select any pack.
Problem:
The pack is applied to both move lines instead of only the selected one.
opw-5104034
Forward-Port-Of: odoo/odoo#228470
Forward-Port-Of: odoo/odoo#228350This fix prevents errors when several employees are clocked in on the same Belgian POS. Businesses can continue selling products and closing POS sessions reliably without interruptions in multi-employee setups.
Original PR description
- Fix traceback when trying to sell a product with multiple employees clocked in on the same POS. - Fix traceback when trying to close a session with multiple employees clocked in. task-id: 4902090 Forward-Port-Of: odoo/enterprise#93942 Forward-Port-Of: odoo/enterprise#93273