Wednesday, July 2, 2025
18 changes · saas-18.3
Resolved issues and error corrections
This fixes an issue that prevented users from saving public holidays when they overlapped with existing time-off requests. HR teams can now manage holiday calendars without being blocked by an unnecessary validation error.
Original PR description
## Steps to Reproduce: - Create a new time-off request for a specific date range using the admin panel. - Try creating public holidays that overlap with the selected date range. ## Fix: - To resolve the above issue, we will pass a context variable to skip the thrown error. Task: 4770292 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stock transfer records now keep all relevant source references when items from different replenishment actions are grouped together. This prevents the reference field from being blanked out, making it easier for users to trace why a transfer was created.
Original PR description
**Current behavior:** During the assignment of a picking, if any of its moves have an origin that does not match its own, the origin will be cleared altogether. **Expected behavior:** The different…
**Current behavior:** During the assignment of a picking, if any of its moves have an origin that does not match its own, the origin will be cleared altogether. **Expected behavior:** The different origin should be appended to the existing origin string (as is done in batch replenishment, for example). **Steps to reproduce:** 1. Create 2 products, create a secondary warehouse 2. Create an orderpoint for each product, make the route on both of them the (first?) pointed to by `resupply_route_ids` on the primary warehouse 3. Set `qty_to_order` 1 on each of the orderpoints, and one at a time click the 'Order' button 4. The move generated for each replenishment action will ultimately be added to a single picking -> in the end see that its `origin` field is cleared **Cause of the issue:** We currently decide to clear the picking origin during assignment if any of its moves have a different origin. **Fix:** Instead, append the different origin string to the picking. opw-4749519 Forward-Port-Of: odoo/odoo#212674
When a new Argentine company is created, Odoo now installs the more commonly used Responsable Inscripto chart of accounts by default instead of the Monotributista option. This reduces the chance that most Argentine businesses start with the wrong accounting setup and need manual correction.
Original PR description
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in…
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in Argentina we have different CoA depending on the AFIP Responsibility, and the one that is currently installed by default is the 'ar_base' (Responsable Monotributista): the less used one. In this case we prefer to do not install any CoA and let the user to install it manually (as it was working in older versions, but it is not possible). For that reason we made this change force to install 'ar_ri' (Responsable Inscripto) CoA by default instead ### Current behavior before PR: 1. Create a new company with country AR 2. Will automatically install the "Responsable Monotributista" Coa ### Desired behavior after PR is merged: Now will install the "Responsable Inscripto" Coa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215916
Saudi and GCC invoice reports now show the invoice date and confirmation date separately, reducing confusion when invoices are backdated. The issue date is also kept consistent in Saudi Arabia timezone, regardless of the customer's location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216684 Forward-Port-Of: odoo/odoo#214937
Argentina Invoice B PDFs for final consumers or exempt customers now always include the required tax breakdown legend, even when VAT totals are 0.0. This helps ensure printed invoices match local ARCA expectations and avoids missing required information on customer documents.
Original PR description
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or…
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0) After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0 ### **Steps to reproduce** Go to an Argentina Company Create a new invoice for "Final Consumer" with document type "Invoice B" Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed) Print the PDF ### **Current behavior before PR:** The PDF is NOT showing the Tax Breakdown table  ### **Desired behavior after PR is merged:** The PDF is showing the Tax Breakdown with the line VAT Content 0.0  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367 Forward-Port-Of: odoo/odoo#214866
This fix ensures that when customers choose a future shipping date in Point of Sale, the selected date is saved correctly across time zones. It prevents orders from being scheduled one day earlier than intended, reducing fulfillment errors for shops using Ship Later.
Original PR description
This is a fix to the bug when a shipping date in picked in specific timezones, the previous day is set. The steps to reproduce: 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- The previous day is picked which is the bug. The reason is that the shippingDate is parsed into shipping_date which is an object. We now manually deserialize and serialize the date to avoid automatic timezone handling. opw-4853757 Forward-Port-Of: odoo/odoo#215140
This fix prevents the Point of Sale screen from crashing when a customer pays a self-order while the related POS configuration is open. It avoids processing empty synchronization data, making ticket printing and order updates more reliable for staff.
Original PR description
The issue is not reproducible in saas-18.2 however since the method _read_pos_record is introduced in saas 18.2 the issue could arise in this version. Step to reproduce in saas-18.3: - Make an order in self order mode - Pay it, while the linked pos config is open - A traceback will be shown in the pos config Issue: When printing the ticket on the pos config, notify_synchronisation function is called with no records in the session model. _post_read_pos_data will be called with empty data array. Fix: Prevent calling _post_read_pos_data with empty records. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216229
This fix ensures component quantities are calculated correctly when a kit contains another kit with large quantity ratios. Delivery orders will now match the Bill of Materials overview, avoiding overstated component needs and inventory movements.
Original PR description
## How to reproduce - Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision - Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1" - Create Kit BoM…
## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
- "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
- "CMP 2" quantity is 0.50 Units (KO)
OPW-4804958
---
### BoM Overview
### BoM exploded
---
### Test result without fix:
```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216709
Forward-Port-Of: odoo/odoo#215821Restaurant preparation tickets printed after using Fire Course now clearly identify which course should be prepared, avoiding confusing blank kitchen slips. The update also improves receipt test coverage to help prevent this issue from returning.
Original PR description
- Since this PR (https://github.com/odoo/odoo/pull/212490), when clicking `Fire course` in restaurant generate empty preparation ticket. This commit fix this issue by ensuring the preparation ticket…
- Since this PR (https://github.com/odoo/odoo/pull/212490), when clicking `Fire course` in restaurant generate empty preparation ticket. This commit fix this issue by ensuring the preparation ticket contains "Course x fired".
- Improve `preparation_receipt_util` to generate preparation receipt as close as the one we generate with a real printer.
- Add test to make sure the preparation ticket contains the course that is being fired.
Steps to reproduce:
- Configure a preparation printer linked to your pos.config
- Open POS
- Open a table
- Add items, organized by courses
- Click on order btn
- The whole order is sent to the kitchen (good)
- Go back on the table, click on 'fire course' btn
- The preparation printer prints a ticket to warn the kitchen that they need to prepare the next course but it does not contain the course number that is being fired
task-id: 4897844
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prBarcode receiving now correctly keeps unreceived items open when only subcontracted products are validated. This prevents remaining products on the same purchase delivery from being incorrectly marked as received, improving inventory accuracy and follow-up purchasing operations.
Original PR description
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one…
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself. When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193 Since the move has a quantity but picked is still False, the full picking is being picked at once https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207 ----- Ticket: opw-4726229 Forward-Port-Of: odoo/odoo#216566 Forward-Port-Of: odoo/odoo#212687
Malaysian e-invoicing now allows credit notes to be reported to MyInvois even when the original invoice was not previously submitted there. This helps businesses handle older invoices created before MyInvois adoption, and aligns the reported issue date with MyInvois requirements by using the current UTC date.
Original PR description
So far, we have enforced that credit notes must be linked to an invoice that has been sent to MyInvois. In real life, this is too strict. Users could be issuing credit notes for invoices created before MyInvois was used, in which case these must still be reported to MyInvois even though the original invoice isn't on the platform. This also fixes a small issue with the issue date, which was set to the invoice date up until now but on their platform they explicitly ask for today in UTC timezone. task-4889022 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216988 Forward-Port-Of: odoo/odoo#215347
The Kenyan NHIF/SHIF payroll report now uses the selected month correctly, so payslips appear in the right reporting period. This prevents reports from showing records from the wrong month and removes confusing explanatory text from the selection screen.
Original PR description
- load payslip according to the Month value, currently, may payslip appears on june selection - remove the line 'the selection will cover ...' task-4775801 Forward-Port-Of: odoo/enterprise#88996 Forward-Port-Of: odoo/enterprise#85609
This fix ensures Chilean electronic factoring documents always show the assigned amount in Chilean pesos, even when the original invoice uses another currency. It prevents incorrect official XML values and helps companies avoid reporting errors when submitting factoring documents to the tax authority.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MontoCesion tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on `Send Now to SII` and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MontoCesion is in selected currency which is wrong opw-4830957 Forward-Port-Of: odoo/enterprise#88175
Fixed an issue in barcode receipt processing where changing the unit of measure updated the completed quantity but left the reserved quantity unchanged. This keeps inventory demand and received quantities aligned, reducing confusion and preventing inaccurate stock handling.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- Create a receipt for 200 units of P1
- Mark it as To Do
- Go to the barcode module and start processing the receipt
- Edit the quantity:
- Set it to 2 and change the UoM to Dozen
- Save
Problem
The quantity done is correctly set to 2 dozens, But the reserved quantity remains 200
Solution:
When the UoM is changed, compute and update the reserved quantity accordingly
OPW-4716104
Forward-Port-Of: odoo/enterprise#87766
Forward-Port-Of: odoo/enterprise#85004This fixes an error that could prevent payslips from being generated for Mexican employees who only have variable income, such as commissions or bonuses. Payroll processing is more reliable for these employee cases, reducing manual intervention and payroll delays.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89041 Forward-Port-Of: odoo/enterprise#85756
Barcode receipts for purchase orders that include subcontracted products now correctly leave unreceived items open instead of marking the whole delivery as received. This prevents inventory and purchasing records from showing products as received before they actually arrive.
Original PR description
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one…
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself. When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193 Since the move has a quantity but picked is still False, the full picking is being picked at once https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207 ----- Ticket: opw-4726229 Forward-Port-Of: odoo/enterprise#88925 Forward-Port-Of: odoo/enterprise#86979
Users can now connect a bank journal to an online account even when existing entries use a different currency than the one provided by Odoo Fin. Instead of blocking setup with an error, the system leaves the existing currency unchanged and lets synchronization continue.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
Rental orders using material resources now count their planned time correctly. This prevents already-planned material shifts from incorrectly showing as still needing to be planned, giving teams a more accurate order status.
Original PR description
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861