Daily updates from Odoo
Monday, January 12, 2026
9 changes · 19.0
Resolved issues and error corrections
This pull request includes updates to translations for various languages and addresses several bug fixes across different modules. Specifically, it fixes issues with address formatting in the contact module, improves printer linking in the inventory app, and resolves a problem preventing ticket creation from email aliases.
This update fixes an issue where Odoo was incorrectly selecting DIAN number ranges, leading to upload errors. The system now consistently uses the highest available number range returned by the DIAN service, ensuring successful document uploads. This improves the reliability of our integration with DIAN.
Original PR description
**PROBLEM** The GetNumberRange service of DIAN used to retrieve the attributed number ranges can return multiples ranges for the same prefix. In odoo, for each prefix, we only store the last range we encountering in the xml the service respond with. This means there is a chance we select a number range that is already full. This cause an error when trying to upload a new document to DIAN. **STEP TO REPRODUCE** Not reproducible on runbot since this need a production DIAN setup (GetNumberRange service is only available in prod). 1. In DIAN portal, have two valid numbering ranges for the same shortcode. 2. In Odoo, go to Accounting > Configuration > Journals, select the journal, and click "Reload DIAN Configuration" 3. Only one of the NumberRangeResponse is pulled into Odoo, and it may not be the correct one **FIX** For each prefix, we keep the highest range we find in the DIAN response. opw-5086590
This update resolves an error that occurred when creating attendance records using the 'Planning' work entry source. The fix corrects issues with how the system calculates working time and handles partial day allocations, ensuring attendance creation now functions correctly.
Original PR description
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to…
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):** - Install the `hr_work_entry_planning_attendance` module. - Go to `Employees` and create a `new employee` or open an `existing one`. - In the `Payroll` section, set `Work Entry Source` to `Planning`. - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%. - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates. **Error 1:** `AttributeError: 'method_descriptor' object has no attribute 'min'` **Error 2:** `TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given` **Cause:** When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot. If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples. **Fix:** This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format. [1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57 [2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60 **No Task ID**
This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The fix ensures the wizard now correctly selects the customer-facing 'OUT' operation, streamlining the return process and improving data accuracy.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134 Forward-Port-Of: odoo/enterprise#93154
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures compliance with Luxembourg tax regulations and accurate reporting to tax authorities, resolving a potential data discrepancy.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This pull request addresses several critical issues impacting payroll processing for Australian businesses using the Odoo Enterprise system. Specifically, it resolves errors related to Medicare calculations, STP reporting accuracy, and rounding discrepancies, ensuring more reliable and compliant payroll operations. The fixes improve data integrity and reduce the risk of financial inaccuracies.
Original PR description
Tracebacks on zeroing Medicare computation to require the variation form Rounding error on STP reporting of Additional withholding task-5416549
This update restores automatic follower copying from parent sale orders for subscription renewals and upsells, aligning with expected business processes. Previously, this feature was removed for all users, but this change specifically addresses the needs of subscription-based sales. It maintains the existing restrictions for other record types.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181
This update fixes issues with document folder synchronization and the order of actions when creating accounting records. Specifically, it ensures documents are moved to the correct accounting folders and that multi-step actions execute in the correct sequence, preventing data inconsistencies.
Original PR description
This PR addresses two related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Execution Order of Multi-Actions.…
This PR addresses two related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Execution Order of Multi-Actions. Previously, multi-step server actions (e.g., 'Create Vendor Bill') executed child actions alphabetically. This caused the manual "Move to Taxes" action to execute after the record creation sync, effectively overriding the correct journal folder placement and moving the document to a generic folder (e.g. 'Taxes'). Changes: - Enforced a specific execution order: The document is now moved before the accounting record is created. This ensures the final automatic sync prevails. - Additionally, the action is temporarily embedded (pinned) on the intermediate folder during execution to allow the subsequent record creation to proceed even after the document has been moved to a new folder (which would otherwise fail consistency checks). **Fix 2:** Sync on Miscellaneous Entry Creation Previously, creating a Miscellaneous Entry (move_type='entry') from an existing document failed to move the document from its original location (e.g., "Finance") to the correct accounting folder. The existing sync logic explicitly skipped entries to avoid issues with multi-attachement invoices. Changes: - Extended `ir.attachment.write` to detect when a document is linked to an account.move of type 'entry'. - Triggers `_update_or_create_document` immediately upon linking to ensure tags and folders are synchronized. Task-5452729
This update fixes an issue where payment advice reports (PDF and XLSX) were incorrectly displaying only the first bank account when an employee had multiple salary distributions. The fix ensures that all bank accounts with salary splits are accurately reflected in the payment advice, providing correct payment information for employees.
Original PR description
Issue: When an employee had multiple bank accounts with salary distribution, the payment advice (PDF and XLSX) was displaying only the first bank account and assigning the full salary amount to that account. This resulted in incorrect payment information being generated. Fix: When multiple bank accounts are configured with salary distribution, the payment advice now displays the correct information in both PDF and XLSX reports. task-5390429