Daily updates from Odoo
Wednesday, January 29, 2025
14 changes · 18.0
New functionality added to Odoo
This update adds Mexican CFDI electronic payroll XML generation for individual payslips, helping businesses meet local payroll reporting requirements. It makes payroll documents more complete and compliant for companies operating in Mexico.
Original PR description
This adds the CFDI xml on individual payslips. Task: 4299196
Enhancements to existing features
Accounting users can now enter several account prefixes in a single analytic plan line, such as 51, 61, and 71 together. This makes analytic plan setup faster and easier to maintain when the same rules apply to multiple account ranges.
Original PR description
This commit allows the user to put multiple accounts prefix on a single analytic plan line. So, if the user want to add the accounts 51000, 61000 and 71000, he can now add this: 51, 61, 71 in the same line. task-4294662
Users can now use “child of” and “parent of” hierarchy filters more easily in the domain selector when the selected relationship field supports them. The selector also supports choosing multiple records for these filters, making it faster to build accurate hierarchical searches.
Original PR description
First commit introduces the allow_hierachy_operators description on relational fields while second commit allows to use the hierarchical operators (child_of/parent_of) on these fields inside the domain selector while also allowing multiselection with these operators. task-4492974
Ecuadorian localization now supports creating purchase withholding documents when companies distribute dividends to shareholders from a closed fiscal period. This helps businesses meet local electronic reporting and tax withholding requirements for dividend payments more consistently.
Original PR description
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. task: 865
Resolved issues and error corrections
Users can now download original PDF bills attached to newly created draft vendor bills without encountering an error. The fix ensures draft bill records are handled correctly when preparing the download, restoring a standard accounting workflow.
Original PR description
Users currently cannot retrieve original bills attached to newly created draft moves, because an error is blocking the action Steps to reproduce: - Go to Accounting > Vendor > Bills - Upload a pdf - Back in list view, select the created bill, Download > Original Bills Issue: Traceback will raise `AttributeError: 'bool' object has no attribute 'decode'` This occurs because, after https://github.com/odoo/odoo/commit/ce73ed61bcf293953bc0c821ceaef3ddb9a47e3c, draft moves are not named '/' anymore, the name field will be just `False`. However reportlab expects a string and it crashes opw-4502791
This fixes a problem where pressing Escape while editing a form in a dialog could cause an error instead of closing cleanly. It improves reliability when users cancel edits, especially in areas like Studio and other popup form views.
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
This fixes an issue where employees on flexible working schedules could have a one-day time off request counted as two days. The change ensures leave duration is calculated from the actual requested date range, helping keep balances and approvals accurate.
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Check if the employee if on flexible hours we calcualte the duration as the difference between the date_to and date_from rounded up in days opw-4309551
This fixes an issue in Point of Sale where product stock could be shown incorrectly when a cashier changed product options during configuration. The update reduces duplicate stock checks and ensures the displayed on-hand quantity matches the selected product variant, helping staff make more accurate sales decisions.
Original PR description
Before this commit, multiple requests were sent when the user changed options in the product configuration. Additionally, the on-hand quantity was displayed incorrectly when opening the product configuration. When opening the configuration popup, the product was initially set. However, once the configuration was mounted, the selected attributes could result in a different product variant. We call `computeProductProduct` to update the product. The issue occurred because, while the first request was still in progress, a second request was triggered to fetch the correct product information. Since the first request was not yet finished, the second request was ignored, causing the configuration to display an incorrect on-hand quantity for the selected product variant. opw-4385171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings Odoo's spreadsheet engine to a newer maintenance version with fixes for spreadsheet sessions, Excel import/export validation ranges, and chart trendlines. Business users should see more reliable spreadsheet behavior, especially when working with XLSX files and logarithmic chart trends.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot on leave Task: 4356913 https://github.com/odoo/o-spreadsheet/commit/e8ae60230 [FIX] xlsx: fix data validation range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/b52dbde23 [REF] range: rename useFixedReference Task: 4506120 https://github.com/odoo/o-spreadsheet/commit/179614731 [FIX] xlsx: export data validation with unbounded range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/74263151a [FIX] charts: fix logarithmic dataset trendline Task: 4385057 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix keeps XML files from being selected as the main attachment for vendor bills when Italian localization is installed. It prevents unreadable files from being produced when users print original bills, preserving the expected PDF output.
Original PR description
**Issue:** When "l10n_it" is installed, an override of "_message_set_main_attachment_id" method is changing the default value of "filter_xml" param from True to False, which is impacting the general behavior when the module is installed. As a consequence, xml files can be set as main attachment of a bill, which generates unreadable PDF files when using "Print > Original Bills" action on a bill. opw-4439034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Brazilian electronic invoices now send the invoice line description instead of only the product name, letting businesses include the extra detail they entered for each line. The fix also prevents service transaction errors from being incorrectly cleared, improving reliability for Brazilian AvaTax electronic invoicing.
Original PR description
We always send the product name, but sometimes users want to add more information to the electronic invoice. It makes more sense to send the line description (account.move.line's name field) instead. That allows the user to specify what they want and also aligns better with what the API expects (their field is called "description", not "productName"). To avoid changing function signatures in stable we override _l10n_br_build_avatax_line and browse the account.move.line using line_id. In master we'll clean it up by providing "description" directly in _get_line_data_for_external_taxes() for both account.move and sale.order. This also fixes a mistake that cleared errors for service transactions (introduced in the merge of l10n_br_avatax_services [1]). [1] https://github.com/odoo/enterprise/pull/64714 task-4401787
Accountants can now edit Brazilian NCM codes used for service invoices so they match the format required by each city. This helps prevent invoice rejections in cities whose local tax systems expect different code formats, such as leading zeros or no periods.
Original PR description
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different…
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front of the code (e.g., 04.10 instead of 4.10), presumably because that's what non-service NCM codes look like. Other cities may not require periods. Cities reject invoices with "wrong" NCM codes, so at the moment our service invoice integration doesn't work there. This seems to affect around 25% of cities. Avalara states they cannot translate the codes for us due to the large number of cities involved. So, users will have to figure out the required format of the NCM code from their city hall and edit the NCM codes based on that. In order to do so we make the NCM codes editable for accountants and provide views and menu items. NCM codes are loaded from CSV and are non-updateable (noupdate=False) by default. To avoid changes being overwritten during module updates we turn them updateable in the model's init() (called during module update). In master this can be removed and done in post_init_hook instead, so that it only happens once during module installation. It's not needed to change the post_init_hook here. After module installation the records will be noupdate=False, but init() always runs before l10n_br.ncm.code.csv is reloaded so manual changes will persist. [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm task-4374334
The EU OSS reports now show the closing entry button again in version 18.0. This lets users complete closing entries directly from the report because the underlying closing process is expected to work correctly again.
Original PR description
From version 18.0, the closing should work fine and there's no need to hide the closing button anymore. This reverts commit cf86ce0e0c7c47336446da5b335cbc53b7602fcd.
Uploading large images to Documents no longer automatically shrinks them. This preserves the original file quality and avoids unexpected changes to images stored by users.
Original PR description
Bug === When uploading a big image in documents, it's resized. It has been fixed in 17.4 with `Task-3944609`, but we re-introduced the issue during the refactor of documents. Task-4505777