Daily updates from Odoo
Tuesday, July 1, 2025
37 changes · 18.0
Resolved issues and error corrections
Malaysia e-invoicing now allows credit notes to be reported even when the original invoice was not previously sent to MyInvois, supporting cases where older invoices predate MyInvois use. The issue date sent to MyInvois is also corrected to use the current UTC date, matching platform requirements.
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#215347
Argentina B invoices for final consumers or exempt customers will now include the required tax breakdown table even when VAT totals are 0.0. This keeps printed PDFs aligned with ARCA expectations and avoids missing compliance information for zero-tax sales.
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
Changing a leave request from “Extra Hours” to another time-off type now properly removes the old overtime link. This prevents incorrect overtime deductions or stale attendance overtime records when HR updates leave requests.
Original PR description
This commit fixes a bug that occurs when switching a leave request of type "Extra Hours" to another time-off type. The issue happens when editing a leave request that allows deduction from overtime, as it remains linked to attendance overtime that needs to be unlinked. task-4756706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207780
Fixes an issue where opening allocations from a time off type could show the same remaining balance information for every employee. This helps HR users see accurate allocation details instead of employee-specific values being reused incorrectly.
Original PR description
### Steps to reproduce: - Create a Time off type - Create allocations for some employees with the created type - Navigate to an allocation for a specific employee - Click on the time off type in the allocation form - Click on the smart button 'Allocations' - Notice each record showing the same time off type (X remaining out of Y) ### Cause: This is happening because when going through the allocation of a specific employee we add him in the context 'employee_id' so we compute the display name of the leave type and set it for each record as the same value as we compute leaves depending on the contextual employee. ### Fix: We are preventing the computation of the display name by forcing the employee_id in the context to force when we are using the smart button for allocations in the time off type form view opw-4841096 Forward-Port-Of: odoo/odoo#215454
This fix keeps the source reference on stock transfers when items from different replenishment actions are combined. Instead of clearing the origin field, Odoo now appends the additional reference so users retain traceability for inventory movements.
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
Fixes an issue where images in email templates could stay locked to a previously saved size after being edited. Users can now resize images or return them to their default size without old dimensions overriding their changes.
Original PR description
Problem: When resized images (e.g., with `style.width: 50%`) are processed by `convert_inline`, `width` and `height` attributes may be added for email client compatibility. These attributes override resizing changes, forcing the last saved dimensions and preventing fallback to the image's default size. Solution: Remove `width` and `height` attributes from the content inserted into the editor. They will be correctly re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Resize the image to 100% - Save - Resize the image back to default - The image keeps the 100% size opw-4863515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops refunds in Point of Sale from being paid again with an online payment method, a flow that is not supported. It prevents affected POS sessions from getting stuck and failing to close after such a refund.
Original PR description
**Problem:** When refunding an order that has been done in the frontend from the backend, then when trying to pay for it again using an online payment method, it will currently work. The problem is…
**Problem:** When refunding an order that has been done in the frontend from the backend, then when trying to pay for it again using an online payment method, it will currently work. The problem is that doing this will prevent the user from closing their session afterwards. The issue is that refunding through online payment method is not supported but is going though either way. **Steps to reproduce:** - Have an online payment method. - Go to your POS session and make a purchase, pay for it in cash. - Go back to the backend, to orders and chose your order. - Return the products and click payment to pay for it again. - Chose your online payment method and make the payment. - Try to close your POS session, an error prevents you from doing so. **Why the fix:** The problem is that an error should be thrown when trying to pay the refund with an online payment method. But this error is never reached. It was reached before this commit https://github.com/odoo-dev/odoo/commit/2dce0f22e92299b17162343e3629dcdab8a697b5 This commit is fixing an error that has since been avoided by this commit https://github.com/odoo-dev/odoo/commit/0c8f0d730465028657ff8da28e7ab14e2df08f69 The use case does not even go through the fixed *create* function anymore, so there should be no problem reverting the fix. Before said commit, we set the *online_account_payment_id* whether it exists or not. This then allows us to check if one of them is None later on. If it is, it means we can't create the online payment, as we can't create one without an accounting payment. After said commit, we didn't add it if the accounting payment didn't exist, so the error was never thrown as the code couldn't be reached. opw-4815049
This change corrects a printing layout problem where multi-page invoices using the boxed template could show unwanted vertical lines at the bottom of a page. It improves the appearance of printed invoices by adjusting spacing so totals and payment terms flow cleanly across pages.
Original PR description
Before this commit, a print invoice that's on 2 pages with a boxed template left 2 vertical lines on the page bottom A negative margin top in applied that push the table top to the first page I…
Before this commit, a print invoice that's on 2 pages with a boxed template left 2 vertical lines on the page bottom A negative margin top in applied that push the table top to the first page I change the layout of `report_invoice_document` to avoid a negative margin. The negative margin-top to `total` was there to move the float div higher to compensate the ´table` margin-bottom. I remove the `table` margin-bottom and replace that by a `payment term` margin-top. The margin were collapsed for `total` and `payment term` so I had to add an overflow-hidden on the parent div. ## Before :  ## After :  ## Steps to reproduce : - Change the document layout to a boxed one in the Settings - Create products with long descriptions (example can be found in the linked ticket) - Create an invoice with the products - Print the invoice (the total should be on the second page top) - The vertical lines should be there opw-4841652
Long product descriptions on sale order lines now resize correctly after reopening a quotation. This removes unwanted blank space at the bottom of lines, making quotations easier to read and edit.
Original PR description
## Versions 18.0+ ## Issue Blank spaces appear at the bottom of each Sale Order line when a long product description is set. ## Steps to reproduce - Create a new quotation: - Add a product; - Change the description for a long one (3+ lines) or add one; - Go back to the quote list view; - Come back to the quote. ## Cause The component's height computation is done before the columns' widths' computation which then resizes based on font styles, making the text take less space and blank spaces appear. ## Fix Force the computation of the SO line's height once the component is mounted. opw-4766800
This fixes report formatting so long units of measure can wrap instead of forcing other report columns to be cut off. Quantity values remain on one line, making invoices, sales, stock, and delivery reports easier to read and print.
Original PR description
*: l10n_gcc_invoice,l10n_it_stock_ddt,sale,stock,web [1]: https://github.com/odoo/odoo/commit/344bdb1ed4cecdaef007200c011f87e58e36c87d Issue: [Commit](https://github.com/odoo/odoo/commit/344bdb1ed4cecdaef007200c011f87e58e36c87d) introduced a `text-nowrap` on the quantity column, this unnecessarily crops the other columns if we use a long UoM. This commit adds a max-width to the UoM column and applies the text-nowrap to the quantity only, letting the long UoM wrap if too long. task-4478718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an invoice with deferred revenue or expenses is reset to draft under Audit Trail, posted deferred entries are now cancelled as intended instead of being reversed. This keeps accounting records consistent with audit protections and avoids incorrect reversal handling for affected invoices.
Original PR description
**Steps to reproduce:** - Install accountant - In Accounting settings, activate "Audit Trail" - Create an invoice: * Customer: [any] * Invoice Lines: - Product: [any] - Start Date: [2 months ago] -…
**Steps to reproduce:**
- Install accountant
- In Accounting settings, activate "Audit Trail"
- Create an invoice:
* Customer: [any]
* Invoice Lines:
- Product: [any]
- Start Date: [2 months ago]
- End Date: [2 months later]
- Confirm the invoice
=> Deferred Entries are created. Posted for the previous months and in draft for the future ones.
- Reset the invoice to draft
**Issue:**
The draft entires are correctly unlinked, but the posted ones are reversed instead of being cancelled.
**Cause:**
This fix https://github.com/odoo/odoo/commit/cc448bf77aa3d11e634e6bab6da1690a1b67a723 is supposed to cancel the deferred entries when the move is protected by the audi trail.
However we never get into the `elif move._is_protected_by_audit_trail():` branch because its condition is also included in the previous `if not move._can_be_unlinked():` branch.
Linked enterprise PR (test): https://github.com/odoo/enterprise/pull/88992
opw-4891975
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPoint of Sale self-invoicing now updates an existing customer record when the customer enters new details through the receipt QR code form. This prevents outdated customer information, such as VAT numbers, from remaining in the back office after a self-invoice is created.
Original PR description
When doing a self invoice with the QR code on the PoS receipt, if a partner was linked to the order, the record would not be updated with the values entered in the self invoice form. Steps to reproduce: ------------------- * Enable the self service invoice feature in the PoS settings. * Open a PoS session. * Make and order with a partner set on it. * Finalize the order and scan the QRCode on the receipt. * Fill the form with some new informations (like a new VAT number) > Observation: Check the partner on the backend, the values are not updated. Why the fix: ------------ We update all the mandatory and optionnal fields of the partner record with the values entered in the self invoice form. opw-4676244
This fix prevents Odoo from creating an incorrect extra delivery transfer when a confirmed sales order quantity is reduced on routes using a destination location from the rule. Inventory adjustments now use the intended destination location, keeping delivery records and stock movements accurate.
Original PR description
Steps to reproduce: - Install Sales and Stock - Activate the multi-step routes setting - Go to a Delivery route in the warehouse - Change the `location_dest_id` of the operation type set on the rule…
Steps to reproduce: - Install Sales and Stock - Activate the multi-step routes setting - Go to a Delivery route in the warehouse - Change the `location_dest_id` of the operation type set on the rule - Enable the "Location Dest. Taken from Rule" checkbox - Ensure `rule.location_dest_id` and `operation_type.location_dest_id` are different - Create a Sales Order (SO) for a product with quantity = 5 and confirm - Change the SO line quantity to 3 and save Issue: A second picking is created with a move taking the product from `rule.operation_type.location_dest_id -> rule.operation_type. location_src_id` with quantity = -2. This happens because the decrease in the SO quantity triggers a negative move, and this move is not merged with the existing positive move. Instead, a new move is created in the opposite direction. In `_merge_moves`: https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193 It checks if the negative move has similar characteristics to the existing positive moves. However, the `neg_key(neg_move)` differs in `location_dest_id`, so the merge fails. This happens because the negative move does **not** read the `location_dest_id` from the rule — unlike the procurement, which **does** use the rule and therefore creates positive moves with the correct destination. When the negative move is created with the procurement, it initially has the correct `location_dest_id`. But then: https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191 triggers `_compute_location_dest_id`, which doesn't consider the `rule.location_dest_id` and defaults to `operation_type. location_dest_id`, causing the merge to fail due to mismatched destination_locations. The positive move has read the correct value, because when it was assigned to a picking, the picking has the correct destination from the procurement. But for the neg_move it has picking None so it maps to the operation_type without consdiering the location from rule checkbox. opw-4793171
This fixes crashes that could happen when forms accidentally included technical binary fields containing unexpected data. Odoo now avoids showing unsuitable technical binary fields in generated forms and handles unusual binary values more safely, improving reliability for users.
Original PR description
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#216377 Forward-Port-Of: odoo/odoo#213967
Sales order emails now show the intended sender: the salesperson when one is set, or the company email when no salesperson is assigned. This avoids customer confusion when a shared company email matches an administrator account.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set company email to the same as the admin's; 2. log in as demo user; 3. set up a sales order without a salesperson; 4. send sales order via email. Issue…
Versions -------- - 18.0+ Steps ----- 1. Set company email to the same as the admin's; 2. log in as demo user; 3. set up a sales order without a salesperson; 4. send sales order via email. Issue ----- Sales order shows as being sent from admin user instead of the company email. The expected behavior for sales orders is that they're sent from the salesperson email if available, else the company's email. Cause ----- When sending the email, it has the correct `email_formatted` value, i.e. Company Name <company@email.com>. To get the author however, `mail` uses the `_mail_find_partner_from_emails` method, which normalizes the given emails before searching matching partners. Without the "Company Name" part, it will also match admin user's email, and because the method prioritizes user emails over partner emails, the company's `partner_id` doesn't even get checked in the lookup. Solution -------- Add a `_computer_authorship` override for `sale.order` messaging. opw-4690644
Employees with flexible working hours will now see all days normally in the Time Off calendar instead of having some days incorrectly greyed out. This avoids confusion when reviewing or requesting time off for flexible schedules.
Original PR description
The calendar view in the Time Off app was displaying greyed-out days. These days corresponded to those from the underlying work schedule on which the flexible working hours were based. Steps to reproduce: ------------------- * In the Work Information tab of an Employee, set the Working Hours to flexible. * Save and click on the Time Off smart button > Observation: Some days were greyed-out Why the fix: ------------ `get_unusual_days()` usually return a dict of each days with True or False. That dict is then interpreted to display white or greyed-out days. Simply be returning False, every days are going to be white. opw-4816609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a rounding problem when breaking down multi-level Bills of Materials for kit deliveries. This prevents incorrect component quantities from being reserved or delivered, helping inventory and fulfillment stay accurate.
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#215821This fixes the boxed invoice PDF layout so the totals table has a consistent border after recent spacing changes. The update prevents printed invoices from looking visually disconnected or unfinished.
Original PR description
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf.…
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf. Previously,in the box layout, this table did not have a top border because it appeared visually connected to the preceding table — they seemed seamlessly joined. However, after the margin was added,the table now appears visually disconnected, making the absence of a top border look inconsistent and awkward. Steps to reproduce: - install account module - select box external layout - create invoice - print report as pdf Before commit:  After commit:  opw - [4873157](https://www.odoo.com/odoo/project/70/tasks/4873157) upg - [2839564](https://upgrade.odoo.com/odoo/upgrade.request/2839564) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated stock workflow test that could fail because it checked information before recent changes were fully saved. The update makes the test process more dependable, helping prevent false failures in validation pipelines.
Original PR description
The `test_add_new_line_in_detailled_op` fails in 18.0+ since clicking on the head of the modal content will trigger a web_read before the records has been updated in db. So that the last applied change disappear. This commit attempt to clean the tour to be more reliable. runbot-113534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unstable automated test in the mailing area that was failing during nightly checks. The change makes test results more predictable, helping maintain release quality without affecting end users directly.
Original PR description
Not sure why we did that strange construct in subtest but it fails in nightly. Added order on model to try to reduce non deterministic behavior. runbot-162367
Customer follow-up reports now ignore accounting entries that do not have a due date or payment terms when deciding whether action is needed. This prevents customers from being flagged incorrectly and avoids misleading statements showing an outstanding balance of zero.
Original PR description
Linked to a commit in enterprise for account_followup: https://github.com/odoo/enterprise/pull/88515 ### Issue: It is possible to break the followup reports by directly creating entries in the past.…
Linked to a commit in enterprise for account_followup: https://github.com/odoo/enterprise/pull/88515 ### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accounting Dashboard > Bank > new with Amount: 500.0 - "Save & Close" then click on it - In the page "Manual Operations" change the partner to the one from the MISC entry - Change the Account to "400000 Customers" - Validate - The follow-up report is no longer "In need of action" - Create an invoice with a due date in the future - The follow-up report is back to "In need of action" with the amount of the invoice - When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€" ### Cause: The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€. The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`. ### Solution: The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due. So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`. opw-4784250
Hungarian electronic credit notes now report the supplier and customer bank accounts correctly instead of duplicating the customer's account as the supplier's. This helps ensure NAV submissions contain accurate payment details and reduces the risk of reporting errors.
Original PR description
### Steps to reproduce: - Install l10n_hu_edi and switch to a Hungarian company - In the settings set the NAV mode to "demo" - Create an invoice to a Hungarian contact with an account number - Send it to NAV - Create the credit note for this invoice - Send it to NAV and download the XML in the page "NAV 3.0" - The account number in `supplierBankAccountNumber` and `customerBankAccountNumber` are the same ### Cause: The code was doing: `'supplierBankAccountNumber': format_bank_account_number(self.partner_bank_id or supplier.bank_ids[:1]),` But for credit notes `self.partner_bank_id` is the bank account of the customer not the supplier. ### Solution: Only use `supplier.bank_ids[:1]`. As the bank account were never tested in l10n_hu_edi, this commit adds it in the setup and changed the XMLs to always test it. opw-4845026 Forward-Port-Of: odoo/odoo#214714
Sales orders now calculate unit prices correctly when a branch company sells products whose taxes are defined on the parent company. This prevents incorrect untaxed pricing when fiscal positions switch between tax-included and tax-excluded sales taxes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set up 10% price-included tax; 2. copy the tax to a B2B version that's price-excluded; 3. create a B2B fiscal position mapping the first tax to the second; 4. create a $10 product using the first tax; 5. create a branch for the current company; 6. switch to the branch company; 7. set up a sale order with the fiscal position; 8. add the product to the order. Issue ----- While the line displays the correct B2B tax, the unit price displays $10, as if it was computed without any taxes, instead of a price-excluded tax. Cause ----- In the `_compute_price_unit` method, it filters out all tax records linked to the product that don't have the same company as the order line, so the parent company's tax does not get factored in. Solution -------- Rather than requiring strict equality between companies, also allow taxes that belong to a parent company of the line's company. opw-4853042 Forward-Port-Of: odoo/odoo#216124
Vendor payments now keep their original payment number when they are edited and posted again, even when an outstanding payments account is configured. This prevents unexpected numbering gaps or changes, helping accounting teams maintain consistent records and audit trails.
Original PR description
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than…
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than preserving the original. This issue only occurs when the Outstanding Payments account is configured for the journal. **Steps to Reproduce** 1.Install the Accounting module. 2.Go to Accounting > Configuration > Journals, and open a Bank journal. 3.In the Outgoing Payments tab, set an Outstanding Payments Account. 4.Go to Accounting > Vendors > Payments. 5.Create and post two vendor payments (e.g., 00001 and 00002). 6.Reset the first one (00001) to draft, change any field (e.g., amount), and repost it. 7.The number changes to 00003 instead of preserving 00001. **Root Cause** When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction. **Fix** The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated. Opw-4805870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Posting a final invoice linked to an unsubmitted down payment will now show a clear warning instead of crashing. This helps users complete the required ZATCA submission steps in the right order and supports Saudi e-invoicing compliance.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes a crash that occurs when posting an invoice linked to a down payment that has not yet been submitted to ZATCA. The issue is caused by a missing l10n_sa_confirmation_datetime on the referenced prepayment move. Current behavior before PR: When the prepayment invoice is not ZATCA-posted, its l10n_sa_confirmation_datetime is False, causing a crash during UBL generation for the final invoice. It raises AssertionError: Datetime instance expected Desired behavior after PR is merged: The system will raise a clear ValidationError, notifying the user that the related prepayment must be successfully submitted to ZATCA before continuing. This prevents silent failures and ensures proper compliance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Saudi e-invoicing flow now stops final invoices linked to unconfirmed prepayments with a clear message instead of crashing or producing invalid data. This helps users correct the prepayment submission first, supporting proper ZATCA sequencing and compliance.
Original PR description
Description of the issue/feature this PR addresses: Invoices linked to prepayments (down payments) crash during ZATCA UBL generation when the related prepayment invoice lacks a l10n_sa_confirmation_datetime. This happens when the prepayment has not yet been successfully submitted to ZATCA. Current behavior before PR: If a prepayment is missing the confirmation datetime, posting the final invoice results in an error or invalid QR/UBL structure, with no clear user guidance. Desired behavior after PR is merged: The system raises a clear ValidationError instructing the user to first post the related prepayment to ZATCA. This prevents crashes and ensures proper invoice sequencing and compliance. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chilean electronic factoring files now always report the assigned invoice amount in Chilean pesos, even when the invoice uses another currency. This prevents incorrect AEC documents being sent or downloaded for Chilean invoicing workflows.
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
The incomplete transfer window in Barcode now avoids overlapping column headers on very small screens, especially when using languages with longer labels such as French. This makes partial receipt validation easier to read and reduces confusion for warehouse users on mobile devices.
Original PR description
Issue ----- When processing partial receipts on small resolution screens, the incomplete transfer window has an overlap of its headers for translations with long terms. Steps to reproduce ----- - Set…
Issue ----- When processing partial receipts on small resolution screens, the incomplete transfer window has an overlap of its headers for translations with long terms. Steps to reproduce ----- - Set DB language to French - On Inventory>Configuration>Operation Types, configure the operation type "receipts" to create backorders on "Ask" - Create an incoming transfer - Open barcode on a low resolution screen (eg 340x400px) - Open the transfer in barcode - Process part of the quantity - Validate the partial transfer --> The "Terminé /" & "A faire" column headers overlap Cause ----- The resolution is not wide enough to fit the headers without word break. However breaking words isn't a suitable solution either as it makes headers unreadable. For example, "Terminé /" & "A faire" would read as "Term A " " iné fair" " / e " Given that the 2 columns are semantically related, we can merge their headers together without losing readability. Visual comparison ----- Low resolution before (left) & after the fix (right).  Desktop display is a bit affected but still readable.  ----- Ticket: opw-4715939
Rental orders using material resources now correctly count their planned shifts when calculating planning status. This prevents already-planned rental services from incorrectly showing as still needing planning, reducing confusion for sales and operations teams.
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
This fix ensures the journal smart button remains visible when creating accounting entries for individual payslips within a batch. Payroll users can now access the related journal entry even when other payslips in the same batch are not yet completed.
Original PR description
**Steps:** - Install the hr_payroll_account module - Navigate to the payroll menu and open a batch payslip. - Select a batch containing two or more payslips and create a draft entry for any single payslip in the batch. --- **Description of the issue/feature this PR addresses:** When a draft entry is created for a single payslip within a batch, the journal smart button becomes invisible. --- **Cause:** The issue occurs during the account move creation process. When generating an account move for a batch payslip, the process checks the status of all payslips in the batch. If any payslip is not in the done state, the account move is not created, resulting in the journal smart button not appearing. --- **Fix:** This PR adjusts the account move creation logic to allow account moves to be created for batch payslips, ensuring the journal smart button remains visible even if some payslips are not in the done state. task-4440533
This fix prevents an error when online payment synchronization checks a missing provider type. It helps keep batch payment processing stable when provider information is incomplete.
Original PR description
The aim of this commit is making sure that we don't have a traceback when we are trying to do a "in" comparison with an empty `provider_type`. no task id
The salary configurator now shows the minimum wage warning only for Belgian companies. This prevents employees in other countries, such as the United States, from seeing irrelevant Belgian wage alerts when Belgian localization is installed.
Original PR description
The warning for a basic wage below minimum level appears for non Belgian employees, such as L10N_US, because the L10N_BE was installed. The logic for the warning has been limited to be applied only on Belgian companies. Task #4907771
Users can no longer open Studio to customize the Bank Reconciliation view. This prevents unsupported changes to a sensitive accounting workflow and helps keep bank reconciliation behavior stable.
Original PR description
- Install `web_studio` and `account_accountant` - Open Accounting -> Bank You can open studio on this view but this should not be possible opw-4859464
The French FEC import now preserves the existing names of accounts when importing files that contain multiple accounts with similar codes. This prevents unintended renaming of accounts and helps keep financial records accurate after import.
Original PR description
Steps to reproduce: - import a fec with different account 164*** with different names Issue: All the account's name will be overriden Cause: Before 18.0, apparently, code and name were joined and was not an issue solution: update the code to the new logic by filtering out the name from the override (`_apply_template`) opw-4690284
Resetting an invoice to draft now ensures its already posted deferred accounting entries are cancelled as expected. This prevents inconsistent accounting records and adds test coverage to confirm the behavior remains reliable.
Original PR description
When resetting an invoice to draft, its posted deferred entries should be cancelled. This is adding a test to the linked fix. Linked community PR: https://github.com/odoo/odoo/pull/216628 opw-4891975
The Kenyan NHIF/SHIF payroll report now selects payslips for the exact month chosen, preventing payslips from the previous month from appearing in the wrong report. The report wording was also simplified by removing an explanatory line that could cause confusion.
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#85609
Users can now share shortcut folders directly from the cog menu next to the breadcrumbs. This fixes a missing action in Documents and removes unused code, making folder sharing more consistent.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840