Daily updates from Odoo
Thursday, April 30, 2026
11 changes · master
Resolved issues and error corrections
This update resolves a bug where rental tour scheduling was failing due to invalid time selections. The fix ensures tours always use a valid future date, preventing errors when attempting to book tours at times before the current day. This improves the reliability of the rental booking process.
Original PR description
Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day. Tours override the time of the rental period, but not…
Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day. Tours override the time of the rental period, but not the date. If the tours tries to set a time which is in the past, the datepicker will discard the time, breaking the tour. Scenario: Running the tour between 11am-11:59am breaks test_website_sale_renting_ui: - Product page shows default times: today 12pm (start) to 1pm (end) - Tour tries to set start time to 8am - Datepicker rejects 8am (it's before the current time 11am-11:59am) and keeps 12pm - Tour then sets end time to 12pm, resulting in equal start and end times - Equal times are invalid, cart addition fails, tour breaks This commit, extracts the existing utility function into a shared helper that returns a guaranteed future date (next Monday + offset), ensuring tours always set valid times regardless of when they run. runbot-243459 Forward-Port-Of: odoo/enterprise#115687
This update resolves an issue where the XML files generated for the Hong Kong payroll system were not using the correct encoding format, preventing proper processing by the IRD platform. The fix includes adding a required file header and ensuring the correct encoding is used, ensuring accurate data transmission.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115582 Forward-Port-Of: odoo/enterprise#115227
This update fixes an issue where the IRN number, generated during e-invoicing, wasn't saved to the invoice itself. Now, the IRN number is correctly displayed in both the invoice PDF and the invoice form view after the EDI submission process. This ensures accurate record-keeping and compliance with Indian regulations.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update fixes an issue where leave calculations were incorrectly recomputed due to outdated employee version references. The change ensures that time off calculations now accurately reflect the employee's active status at the time the leave was created, leading to more reliable time off reporting.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. Replace the related fields with a compute based on date_from, resolving the version active at the leave's start date. task-6175086 Forward-Port-Of: odoo/enterprise#115607
This update fixes an issue where outstanding amounts weren't accurately calculated after a refund was processed within a point-of-sale transaction. Previously, only the original order total was considered. Now, refund orders are included, ensuring the correct net due amount is displayed and settled, improving financial accuracy.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#114143 Forward-Port-Of: odoo/enterprise#107883
This update enhances the Odoo Enterprise sign process to be more user-friendly on touch screen devices. The changes address usability issues and optimize the interface for touch interactions, making it easier for users to complete sign requests. Unrelated changes from another branch have been removed.
Original PR description
Sign is not well optimized for touch screen users, fields can't be placed and other operations are also hard. This PR is made to fix that. Task: 5001223
This update streamlines the calculation of payslips by restoring a previously removed wizard and implementing inline computation. This change enhances the accuracy and efficiency of payroll processing, ensuring employees receive correct payments. It addresses a previous removal that impacted the functionality of the payroll system.
Original PR description
We replace the previously removed payslip line edition wizard with inline payslip computation Forward-Port-Of: odoo/enterprise#112972
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts when a vendor bill had multiple tax repartition lines. The fix ensures that all tax amounts are accurately included in the export, improving the reliability of financial reporting for Datev.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update ensures that the expiration date from a GS1 barcode on a packaging is correctly applied when creating a new lot in Odoo. Previously, the system didn't recognize the due date on the packaging, leading to incorrect lot expiration settings. This fix improves inventory accuracy and reduces the risk of expired stock.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490This update ensures that missing payslip alerts are triggered only when the payroll closing date has passed. Previously, alerts were raised regardless of the closing date status. This change improves the accuracy of payroll reporting and helps ensure timely payment processing, particularly around end-of-period payroll runs.
Original PR description
In this commit, missing payslip in a payrun issue will be raised only if the payroll closing date is due (old conditions remains). task-6008297 Forward-Port-Of: odoo/enterprise#115646 Forward-Port-Of: odoo/enterprise#112182
This update fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to stock movements. Now, byproducts added to MOs are accurately tracked, ensuring correct inventory updates and reporting. This improves the accuracy of production tracking and reduces potential discrepancies.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582 Forward-Port-Of: odoo/enterprise#115548 Forward-Port-Of: odoo/enterprise#110122