Daily updates from Odoo
Friday, January 2, 2026
10 changes · master
Resolved issues and error corrections
This update fixes a critical bug that caused Odoo to crash when sending invoices via Peppol with invoice lines lacking a product name. Now, the system gracefully displays an error message, guiding users to ensure each invoice line has a product or label before sending. This improves invoice processing reliability and prevents data loss.
Original PR description
Before this commit: When sending an invoice via Peppol with an invoice line that has no product name, the system crashes with a TypeError instead of showing a error message. Steps to reproduce: 1. Go to Accounting 2. Navigate to Customers > Invoices 3. Create a new invoice 4. Add an invoice line without entering a product name 5. Click 'Send' 6. Select 'by Peppol (Demo)' 7. Click 'Send' -> TypeError: 'NoneType' object is not subscriptable After this commit: System validates that the product name exists before accessing its text content. Users see a clear, error message: `Each invoice line should have a product or a label.` task-5432061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241135 Forward-Port-Of: odoo/odoo#240908
This update ensures that inventory valuation lines are correctly generated when closing Point of Sale sessions using the Continental perpetual accounting method. Previously, lines were missing for orders not invoiced, creating an inconsistency between Anglo-Saxon and Continental accounting. This fix aligns the POS valuation process with best practices for perpetual inventory management.
Original PR description
Currently, in a continental perpetual setting for the stock valuation, the inventory valuation lines are not created when closing the session if the orders when not invoiced. Steps to reproduce:…
Currently, in a continental perpetual setting for the stock valuation, the inventory valuation lines are not created when closing the session if the orders when not invoiced. Steps to reproduce: ------------------- * Using My Belgian Company * In the settings search for inventory valuation * Set inventory valuation to Perpetual * Any cost method, AVCO for example * Set up valuation account and journal * Create a product * Type -> Goods * Track inventory by quantity * Set a purchase cost * Put some quantity on hand * Add category * In the settings of the category * Set up Stock account * Set up costing method, AVCO for example * Set inventory valuation to perpetual * Open pos session * Make an order for the product, put partner, invoice it * Close session, go to session journal items > Observation: Valuation lines are present * Open pos session * Make an order for the product, no partner, no invoice * Close session, go to session journal items > Observation: Valuation lines are missing. Why the fix: ------------ When the company is set with perpetual inventory valuation, in the context of the point of sale, there should not be any difference between anglo saxon and continental accounting. When we check the same flow with anglo-saxon, there is no difference for the creation of the inventory valuation move line whether we invoice the order or not. Inventory valuation lines are always present. Valuation entries are created in `_create_stock_valuation_lines()` if information is available regarding `stock_valuation`. https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L1258-L1273 The information for `stock_valuation` is supposed to be computed in `_accumulate_amount()`. However this is currently only computed when we have the anglo saxon accounting: https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L953 Instead we will now only check if the company is valuating the inventory in real time. We also apply the same fix on paid orders we want to invoice afterwards. opw-5167946 Forward-Port-Of: odoo/odoo#240176
This update ensures invoices exported with foreign VAT numbers (e.g., for EU Distance Selling) accurately reflect the correct VAT information in the PDF invoice and the underlying XML file. Previously, the company's VAT was used instead of the appropriate foreign VAT, leading to potential discrepancies. This fix improves invoice accuracy and compliance.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1.…
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837 Forward-Port-Of: odoo/odoo#241436 Forward-Port-Of: odoo/odoo#236692
This update corrects a problem where product names were duplicated on delivery slips when a kit's component lacked a description. The fix ensures that product names appear only once on delivery slips, improving the accuracy and clarity of shipping documents. This resolves an issue impacting sales order fulfillment.
Original PR description
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with…
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with a bom of type kit * Add a product "comp" in the bom (don't give it a description) * Create a sales order with the product A and confirm it * Go on the delivery and create a delivery slip -> Issue, the name of the product "comp" appears twice. Observation: ------------- The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name: https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301 In _compute_description_picking, information about the bom will be added : https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236 This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML: https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85 However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name. opw-5265906 Forward-Port-Of: odoo/odoo#236948
This update fixes usability issues with hidden channels in the Odoo discussion platform. It adds a clear button to find hidden conversations and automatically repins conversations when opened, eliminating the previous 'hide' action. The design has also been refined for better clarity and consistency.
Original PR description
1. Discoverability of "hidden channels" was poor in just ctrl-k => Added a new button at bottom of discuss sidebar with "View hidden conversations". 2. When opening a hidden conversation, it's not possible to "undo" the hide. => Automatically repin conversation when opening the conversation. 3. Hide action was in same group as "Leaving", which is confusing because the actions are quite different as shown by color. => Moved "Hide conversation" action in its own group just above the highly destructive action like "Leave" but below settings actions. 4. Iconography of action is poor with a cross icon => use fa-eye(-slash) that matches more the semantics of action. Task-5431819 <img width="506" height="857" alt="Screenshot 2025-12-19 at 15 34 35" src="https://github.com/user-attachments/assets/453258bb-e83d-49db-986e-9c1c74eafc8d" /> Forward-Port-Of: odoo/odoo#240716
This update resolves an error that prevented users from paying invoices when an invoice line lacked a due date. The fix ensures the system correctly handles invoices with multiple payment terms and due dates, preventing a 'date' vs. 'boolean' comparison error. This improves the reliability of the invoice payment process.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241744 Forward-Port-Of: odoo/odoo#241060
This update resolves an issue where clicking on bookings in the Gantt view was causing errors. The underlying website structure changed, breaking a key reference point used in the application. This fix directly updates the application's code to correctly identify the booking element, ensuring bookings can be accessed reliably.
Original PR description
### Steps to reproduce 1 - Create a booking. 2 - Go to Gantt view. 3 - Click on the booking, traceback occurs. --- The popover footer no longer contains an inner wrapper div, which broke existing xpath inheritance. See: https://github.com/odoo/enterprise/pull/101482 This PR updates the xpath to target the popover-footer container directly. Task-5445909 Forward-Port-Of: odoo/enterprise#102983
This update ensures that changes to product descriptions within Odoo are now correctly reflected in the UrbanPiper system during menu synchronization. Previously, updates to product descriptions weren't consistently propagated to UrbanPiper, leading to outdated information. This fix improves data accuracy for our integrations with UrbanPiper.
Original PR description
Before this commit: --- When we sync the menu with the product description and later update the product description, re-syncing the menu does not update the product description in UrbanPiper. After this commit: --- This fix ensures that any change in the product description is properly sent to UrbanPiper during menu synchronization. task-5439271 Forward-Port-Of: odoo/enterprise#102946 Forward-Port-Of: odoo/enterprise#102846
This update resolves an issue where VAT reports for Belgian companies were incorrectly setting the 'Client Nihil' field to 'YES' outside of the year-end. The fix reintroduces a checkbox option for this setting, aligning with Belgian regulations. This ensures accurate VAT reporting and avoids potential 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 Forward-Port-Of: odoo/enterprise#102482 Forward-Port-Of: odoo/enterprise#98982
This update resolves a technical issue impacting the accuracy of payroll calculations for Belgian employees within the Enterprise module. The fix corrects a 'DDP' error, ensuring that salary figures are correctly processed and reported according to Belgian tax regulations. This improves the reliability of payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#102867 Forward-Port-Of: odoo/enterprise#102787