Daily updates from Odoo
Thursday, February 5, 2026
204 changes
26 changes
Enhancements to existing features
This update enhances the booking view in the Odoo Enterprise system by adding breadcrumbs. This provides clearer navigation for users, making it easier to understand their location within the booking process. It's a simple improvement that enhances the user experience.
Original PR description
In this commit: - Enable breadcrumbs for the booking view by explicitly allowing them in the action context. Task:5490961 Forward-Port-Of: odoo/enterprise#104560
Resolved issues and error corrections
This update fixes an issue where annual returns incorrectly used a fiscal year filter when a company's fiscal year differed from the calendar year. Now, annual returns always follow the company's fiscal year, ensuring accurate reporting and eliminating confusion for users. This improves the reliability of financial data presented in reports.
Original PR description
When a company fiscal year differs from the civil year, the annual return incorrectly falls back to the report’s FY-aligned year filter. The return should always follow the civil year, so the fallback is skipped and the return period filter is shown instead. task-5511074 Forward-Port-Of: odoo/enterprise#104726
This update resolves an issue preventing the legal validation of annual VAT reports for Luxembourg. The PR adds missing required fields to the XML export, ensuring compliance with tax regulations. This corrects a previous validation error related to specific data fields.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update corrects a bug where subscriptions with zero-sum quantities resulted in invoices being set to the subscription start date instead of the correct invoice period. The fix ensures accurate invoice date calculations for subscriptions with mixed positive and negative quantities, preventing incorrect billing.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#106364 Forward-Port-Of: odoo/enterprise#103705
This update resolves an issue where the printer selection wizard could generate errors if it encountered printers that were no longer active in the system. The change filters out these inactive printers, ensuring the wizard functions smoothly and avoids potential disruptions. This improves the user experience and data integrity.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device. Forward-Port-Of: odoo/enterprise#106268
This update ensures that freight costs are now accurately included in the customs documents generated for international sales. Previously, these costs were missing, leading to potential discrepancies in customs declarations. This change aligns with SendCloud API specifications and improves the accuracy of international shipping documentation.
Original PR description
Issue ----- For international deliveries, the customs document does not include the freight costs. Steps to reproduce ----- - Create an international sale (eg BE -> US) - Validate delivery - Open the commercial invoice > Freight costs is set to 0 Change ----- The `freight_costs` should be included in the `customs_information` field of the request (along with all customs-related data, as other fields have been deprecated) https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/operations/create-a-parcel#:~:text=object%2E-,customs%5Finformation ----- Ticket: opw-5486742 Forward-Port-Of: odoo/enterprise#106387 Forward-Port-Of: odoo/enterprise#105543
This update resolves an error that occurred when employees were linked to multiple commission plans using the same payslip input. The fix ensures accurate currency conversion for commissions, preventing a system error and guaranteeing correct payslip generation for users with multiple commission plans. This improves payroll accuracy and reliability.
Original PR description
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the hr_payroll_sale_commission module. 2. Create a user and link to an employee. Set a contract for the employee. 3. Create two commission plans for the same user: - Use the same Payslip Input in both plans. - Set the Target Frequency to "Monthly" for both. 4. Generate a payslip for the employee. Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing) **Error:** `ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)` **Cause:** When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion. **Fix:** This commit ensures the currency conversion is applied per commission and prevents the singleton error. sentry-7187854690 Forward-Port-Of: odoo/enterprise#106124 Forward-Port-Of: odoo/enterprise#104464
This update fixes an issue where WhatsApp messages to blacklisted numbers wouldn't be blocked if the recipient's country differed from the sender's company. The fix ensures that all international phone numbers are correctly processed, regardless of the sender's location, preventing unwanted messages. This improves compliance and protects users from spam.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update resolves an issue where malformed PDFs caused errors during the signature process. The change allows Odoo to attempt a less strict PDF parsing method, ensuring that more PDF documents can be successfully processed and used for signatures. This improves the reliability of the signature workflow.
Original PR description
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859 Forward-Port-Of: odoo/enterprise#106276
This update resolves an issue where the quantity of components in a manufacturing order wasn't correctly updated after exiting the barcode MRP operation. Specifically, the system incorrectly handled reserved quantities, leading to inaccurate component tracking. This fix ensures that component quantities are accurately reflected after the operation completes.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update corrects a bug that was incorrectly flagging miscellaneous entries with both expense and revenue accounts as invalid. Previously, the system would generate an error when using different deferred entry methods for expenses and revenues. Now, the validation only applies to entries with actual deferred dates configured, improving usability for common accounting scenarios.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update resolves an issue where CFDI payroll validation failed when users created payrolls with no deductions. The fix ensures that the CFDI report accurately reflects the absence of deductions, aligning with Mexican tax regulations. This prevents validation errors and ensures compliance.
Original PR description
…eductions Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail. Steps to reproduce: - Set up…
…eductions
Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail.
Steps to reproduce:
- Set up Payroll Structure "Mexico: Regular Pay" with Salary Rules:
- Used subsidy:
- Code: SUBSIDY
- Category: Allowance
- CFDI Concept: (O02) Employment Subsidy (Effectively Delivered to the Worker)
- Deduction:
- Code: DEDUCTION
- Category: Deduction
- CFDI Concept: (D04) Others
- Net Salary:
- Code: NET
- Category: Net
- CFDI Concept: (P01) Salaries, Wages, Stripes, and Day Labor
- Formula: `result = payslip.paid_amount`
- In Payroll > Payslips, Click 'New Off-Cycle'
- Select employee, compute sheet, create draft journal entry and post it
- Back to the payslip, mark as paid and generate CFDI
Issue:
CFDI Validation will fail with error
`Code : 301 Message : Error en complemento Nómina. [Error #NOM38] El atributo Nomina.TotalDeducciones, no debe existir. Folio: 0002. Serie: SLR/2025/12.`
It occurs because, according to the official specs [1] attribute `TotalDeducciones` should not be reported in case there are no deductions
[1] http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/GuiallenadoNomina311221.pdf
opw-5348789
Forward-Port-Of: odoo/enterprise#104311This update ensures that product prices within Odoo Enterprise are stored with a minimum level of precision. This change addresses a technical issue identified in previous development and improves data consistency. It primarily impacts the accuracy of product pricing calculations.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#106382 Forward-Port-Of: odoo/enterprise#104728
This update simplifies the one-time payment form accessed through the employee record. The version field, previously required, has been removed as it's automatically determined by the system. This change ensures a cleaner user experience and avoids potential errors related to incorrect employee or version selection.
Original PR description
… payment form The one time payment view is accessed only via the smart button on the employee form for a specific version. This view displays only that employee's one time payments for the selected version. Since the version is provided by the context and creating a payment for a different employee or version would not make sense, the version field is made invisible. Task: 5384437 Forward-Port-Of: odoo/enterprise#103245
This update resolves a technical problem where sales commission IDs were exceeding JavaScript limits, causing errors. The fix increases the range of the plan ID, allowing for a significantly larger number of sales plans (from 900 to 90,000) while maintaining security and minimizing the risk of duplicate records.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable. Forward-Port-Of: odoo/enterprise#106513
This update resolves an issue where sign requests created on older Odoo versions (before 16.0) would fail due to missing communication company information. The fix automatically uses the user's company date format in these cases, ensuring sign requests can be processed correctly. This prevents crashes and improves the reliability of the sign request workflow.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update corrects a technical issue related to the HR payroll tour in the Swiss localization. The tour was incorrectly displaying a Work Entries button, which isn't relevant for Swiss companies. This fix ensures the tour functions correctly for Swiss businesses, streamlining the payroll process.
Original PR description
The Work Entries button on the form view of the hr_payslips is defined differently in the Swiss localization. We need to override the tour to make it work for swiss companies. Runbot Error: 234647 Forward-Port-Of: odoo/enterprise#106147
This update fixes an issue where the business card scanner button disappeared from the mobile version of the CRM. The change restores the button's functionality, allowing users to easily scan business cards directly within the CRM's mobile interface. This ensures a seamless experience for mobile users adding leads.
Original PR description
After the introduction of the lead generation dropdown (task-4876662) in the CRM kanban control panel, the business card scanner button was no longer rendered on mobile devices. This commit restores the business card scanner button in the kanban control panel on mobile. Task-5899751
This update ensures salary configuration details (like address and personal information) are automatically populated when creating contracts from templates. Previously, templates didn't use employee data, but this change now leverages the employee's latest version, streamlining the offer creation process. This improves data accuracy and reduces manual input.
Original PR description
The personal informations in the salary config is prefilled using the version selected in the offer. When making a new offert for an already employed person, the default version is the last active version, the address and other personal info are already set on that version and the salary has the last up-to-date data. But when selecting a contract template in an offer, the version does not have the personal info from the employee (as it's a template). In this commit, we force to use the employee itself (from the active version of the employee, or the employee linked to the contract template copy - created during the offer creation). may it be an applicant or an existing employee, when an offer is generated, an employee is created (or re-used) and set on the contract template. So it works in every case. Taks-5162703 Forward-Port-Of: odoo/enterprise#104375 Forward-Port-Of: odoo/enterprise#99908
This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or localization-specific). The fix ensures that payment reports now automatically use the correct format based on the company's localization, improving report accuracy and usability for users. The changes have been backported to version 18.0 and include new tests.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#104377
Forward-Port-Of: odoo/enterprise#100126This update fixes a potential issue where applicants could incorrectly reopen and re-sign expired job offers. The system now prevents access to fully signed offers, ensuring data integrity and a smoother applicant experience. A database constraint has also been added to prevent invalid offer validity dates.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#104354 Forward-Port-Of: odoo/enterprise#101834
This update fixes an issue where appraisal templates couldn't select departments without a linked company. The fix ensures all departments, including those without a company association, are now available for selection within the template configuration. This improves usability and prevents limitations in defining appraisal processes.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581
Forward-Port-Of: odoo/enterprise#103531This update fixes an issue where the employee's filling status wasn't updating correctly when the associated address state was changed. The fix adjusts the system to dynamically reflect the correct filling status based on the employee's working address location, ensuring accurate payroll calculations for users in different states.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740 Forward-Port-Of: odoo/enterprise#106000
This update resolves an issue where toggling the Studio feature in Odoo Enterprise could disrupt the layout of form stat buttons. The fix ensures the stat button layout remains consistent, regardless of whether Studio is active, improving the user experience and preventing potential formatting problems.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309 Forward-Port-Of: odoo/enterprise#106452
This update resolves an issue causing duplicate Worldline receipts to appear in POS transactions. The fix ensures receipts are only added when a Worldline transaction is fully completed, improving the accuracy and reliability of sales records. This prevents potential discrepancies and ensures data integrity.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655 Forward-Port-Of: odoo/enterprise#106554
This update ensures that sign templates are correctly named in all languages, reflecting the actual document being signed. Previously, templates created in non-English languages defaulted to 'New Template' due to a comparison issue. This fix guarantees accurate naming across all supported languages, improving the user experience and data consistency.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#104846 Forward-Port-Of: odoo/enterprise#92682
12 changes
Resolved issues and error corrections
This update resolves an issue where the blackbox device ID wasn't being sent correctly, impacting the functionality of the CleanCash v1 blackbox. A secondary change restricts blackbox device selection within the POS configuration, ensuring data integrity and compliance. This improves the reliability of the POS system.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update resolves an issue preventing the legal validation of annual VAT reports for Luxembourg. The PR adds missing required fields to the XML export, ensuring compliance with reporting regulations. This corrects a previous validation error related to specific data fields.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 payment files, causing rejection by strict banks. The fix ensures compliance with SEPA regulations, preventing errors and guaranteeing successful payment processing for our European users. This improves compatibility with major banking systems.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#105792 Forward-Port-Of: odoo/enterprise#105518
This update fixes an issue where WhatsApp messages to blacklisted numbers were sometimes sent successfully if the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers are correctly identified, regardless of the recipient's location, improving message delivery and compliance.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update resolves an issue where the quantity of components in a manufacturing operation wasn't accurately reflected after exiting the barcode MRP process. The fix ensures that move quantities are correctly updated, preventing discrepancies between the expected and actual component quantities. This improves the reliability of the manufacturing process.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update corrects a bug that was incorrectly flagging miscellaneous entries with mixed expense and revenue accounts as invalid. Previously, the system checked for deferred entry methods across all accounts, even those without deferred dates. Now, the validation only applies when actual deferred dates are configured, improving the usability of miscellaneous operations.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update corrects a test failure in the l10n_uy_edi module caused by a recent change to a payment method. The commit simply adds the necessary update to the test suite to account for the new method extension, ensuring the system continues to function correctly.
Original PR description
The PR odoo/odoo#244443 introduces a new extension to the method _is_downpayment hence the test fails since it is not patched. This commit adds the new extension to the patched list. task-5135918 Forward-Port-Of: odoo/enterprise#105165
This update resolves a failing test case related to Indian GST reports. A recent community fix changed how payment references are handled, resulting in a different label format. The test cases have been updated to reflect this new format, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update resolves an issue where sign requests created on older Odoo versions (before 16.0) would sometimes fail due to missing communication company information. The fix automatically uses the user's company date format in these cases, ensuring sign requests can be processed correctly. This prevents crashes and improves the reliability of the sign request workflow.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update prevents zero-priced charge products from being sent to UrbanPiper during menu synchronization. Previously, these products caused issues on UrbanPiper's side. Now, only products with actual prices are synced, ensuring smoother integration with our UrbanPiper partner.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a problem where long item codes were causing errors in the AvaTax integration. The system now automatically limits item codes to 50 characters, ensuring successful tax calculations and preventing transaction failures. This improves the reliability of our tax processing.
Original PR description
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50…
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50 characters or fewer to comply with Avalara's field length constraints. Actual Behaviour before the Fix: When an itemCode exceeded 50 characters, the system attempted to send the request as-is. This resulted in the AvaTax API returning an error, causing the transaction or tax calculation to fail. Behaviour with the Fix: The system now ensures that the itemCode adheres to the 50-character limit before the API call is made, by trancating the code to the first 50 characters if it exceeds 50 characters. This prevents API rejection and ensures successful tax processing for items with long identifiers. Steps to reproduce: 1. Create or select a product/item with a reference (or barcode if using UPC) longer than 50 characters. 2. Trigger an action that calculates tax via the AvaTax integration (e.g., creating an invoice or updating a line item). 3. Observe the API response. - Before fix: API returns a validation error regarding the itemCode length. - After fix: Request is successful as the itemCode is properly handled/validated. opw-5406451 Forward-Port-Of: odoo/enterprise#105017
This update resolves an issue that prevented subscription cancellations for internal users (like 'Mitchel Admin'). The fix uses 'sudo' to allow necessary data updates to the partner record, preventing access errors. This ensures subscription cancellations work correctly for all users, regardless of their role.
Original PR description
*: sale_subscription_partnership To reproduce: ============= 1/ be sure Marc Demo has only sales admin righ 2/ as admin create a subscription with customer = Mitchel Admin (or other internal user) and confirm it (only confirm, do not invoice) 3/ as demo, cancel the SO => Acccess error on res.user Problem: ======== When cancelling a subscription we want to write some fields on the partner related to the SO. If the partner is an internal user, and the current user has no access to write on res.users, we get an access error. Solution: ========= Use sudo when writing on the partner when cancelling a subscription. opw-5857627 Forward-Port-Of: odoo/enterprise#105901
9 changes
Resolved issues and error corrections
This update fixes an issue where Odoo didn't properly account for credit notes during bank reconciliation. Now, when reconciling a bank transaction with a partially paid invoice and a credit note, the system correctly uses the remaining balance ($800) instead of the full invoice amount ($1000). This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663
This update resolves an issue preventing the legal validation of annual VAT reports for the LU region. The fix adds missing required fields to the XML export, ensuring compliance with Luxembourg tax regulations. This ensures accurate reporting and avoids potential validation errors.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and improving compatibility with financial institutions. This ensures seamless payment processing for SEPA transactions.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#105792 Forward-Port-Of: odoo/enterprise#105518
This update fixes an issue where WhatsApp messages to blacklisted numbers weren't being blocked correctly when the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers, regardless of the recipient's location, are properly blocked, improving communication security and preventing unwanted messages.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update fixes an issue where the quantity of components in a manufacturing order wasn't correctly updated after exiting the barcode MRP operation. Specifically, the system incorrectly displayed quantities after editing a component's quantity. The fix ensures that move quantities are accurately reflected, preventing discrepancies in inventory tracking.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update resolves a failing test case in our Indian GST reports. A recent community fix changed how payable lines are labeled, now using bill references. The test cases have been updated to reflect this new labeling format, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update fixes an issue where the activity menu in web_studio was displaying all records for custom models, regardless of whether the user had an activity assigned to them. Now, the menu only shows records with activities linked to the current user, improving performance and ensuring users only see relevant data. This change was driven by a bug fix (opw-5778806).
Original PR description
After commit odoo/odoo@5c5fbc10b7024c7227f03e37897d421bba64df82 , actions spawned by the activities menu have their domain managed by dynamic <filter /> rather than a plain readonly domain. Before this commit, clicking on the activity menu to go to a custom model showed every record, not just ones with activities after this commit, only records with activities assigned to the current user are showed opw-5778806
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with our UrbanPiper partner.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves an issue where customer display URLs weren't being properly transmitted to the IoT devices when records were updated. The change ensures that the correct URL is sent, improving the functionality of the IoT integration. This fix was triggered by a reported bug.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106331
5 changes
Resolved issues and error corrections
This update resolves a bug where the POS ID wasn't correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, and a secondary change restricts blackbox device selection to the Fiscal Data Module in POS configuration, improving data security and consistency.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update resolves an issue preventing the legal validation of the annual VAT report for Luxembourg. It adds missing required fields to the XML export, ensuring compliance with tax regulations. This fix addresses a technical problem related to data validation within the LU reporting module.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update resolves an error that prevented non-employee users from creating expenses from documents. The issue stemmed from a required field ('employee_id') not being populated correctly. The fix now displays a user-friendly error message when this condition is met, ensuring a smoother expense creation process.
Original PR description
Currently an exception is generated when the non-employee user tries
to generate expenses from the documents.
Steps to produce an error:
- Install the `documents_hr_expense` module without demo data
- Delete employee `Administrator`
- Upload any PDF/image file inside the company's `Internal` folder
- Click on the uploaded document and click on the `Create an Expense` button
Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...`
This error occurs because `employee_id` is required when creating an
expense. Since the current user is not linked to an employee record,
`employee_id is` set to false, which causes the issue.
This commit resolves the issue by raising a `UserError` when the current
user is not linked to an employee.
sentry-7192984733
Forward-Port-Of: odoo/enterprise#104762This update corrects a display issue in the bank reconciliation widget. When a user removes a partner from the liquidity line, the associated partner name on the statement line was incorrectly remaining. The fix uses a direct database update to ensure the partner name is cleared, resulting in accurate display of information.
Original PR description
When a user removes the partner from the liquidity line in the bank reconciliation widget, the 'partner_name' field on the statement line is not cleared. This results in the UI displaying the old name even though the partner is removed. in the first time i wanted to fix the issue with the standard ORM (e.g., `self.st_line_id.partner_name = False`) but it triggered a traceback. This occurs because `bank.rec.widget` is a virtual model defined with `_table_query = "0"`. When the ORM propagates the write operation, it attempts to query this virtual table `SELECT ... FROM (0)`. the fix now is a raw SQL update to set `partner_name` to NULL on the `account_bank_statement_line` to bypasses the ORM's dependency tracking for the virtual model. The cache is then explicitly invalidated to update UI. opw-5400705 Forward-Port-Of: odoo/enterprise#104596
This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when records were updated. The change ensures that the correct URL is transmitted, improving data synchronization between the enterprise system and the IoT devices. This prevents potential data discrepancies and ensures accurate device configuration.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106331
21 changes
Enhancements to existing features
This update separates the user interface data from the core account report logic. This change optimizes the performance of account reports by reducing the amount of data processed by the UI, leading to faster loading times and a smoother user experience. It's a key improvement for users generating and viewing reports.
This update adjusts the layout of the POS order form by updating the underlying XPath expressions. This ensures the form correctly displays information after a recent design revamp, improving the user experience for point-of-sale operations. This change impacts the l10n_mx_edi_pos and l10n_pe_edi_pos modules.
Original PR description
*= l10n_mx_edi_pos, l10n_pe_edi_pos In this commit: ================ This commit adapts the existing xpath expressions to support the revamped POS order form view layout. Task-5481883 Related Comm. PR: https://github.com/odoo/odoo/pull/243453
This update enhances the initial user experience for the Documents module by revamping the onboarding tour to showcase new features and streamlining the process. It also includes UI adjustments to the document creation dialog, making it easier for users to get started with the system.
Original PR description
**Purpose:** Revamp the Documents onboarding tour to highlight newly added features. **Specifications:** - Add a dependency on Contacts - Revamp the onboarding tour to reflect the new features. - UI changes in select add document create dialog Task-5152401
This update streamlines quality check reporting by removing redundant fields and ensuring accurate recording of manufacturing order lot IDs. It also fixes a bug related to handling multiple lot numbers in quality wizards, enhancing the reliability of quality control processes.
Original PR description
Changes of note: * `finished_lot_ids` is removed from existing tests and replaced with `lot_ids` wherever it makes sense. * The MO's SN/lot id is written to every quality check it has, instead of just 'Register Production' ones. * 'Register Consumed Material' checks write 'Success' or 'Failure' to the result field like 'Pass – Fail' checks do, instead of the component name, UoM and SN/lot id like 'Register Byproducts' checks do. * Fix for a bug that triggers when the quality wizard is opened if the MO has more than one SN/lot id assigned. Task ID: [5025510](https://www.odoo.com/odoo/my-tasks/5025510)
This update allows users to select the desired label format (ZPL, PDF, or PNG) when sending labels through Sendcloud. This increased flexibility improves the compatibility and usability of shipping labels for various printing and receiving systems. It’s a small improvement that streamlines the label generation process.
Original PR description
Add a option to choose the label format in the parameters when requesting labels from Sendcloud (ZPL, PDF, PNG). Task 5392134
Resolved issues and error corrections
This update fixes an issue where annual returns incorrectly used a fiscal year filter when company fiscal years differed from the standard civil year. Now, annual returns always adhere to the company's civil year, ensuring accurate reporting and a better user experience. This improves the reliability of financial data presented in reports.
Original PR description
When a company fiscal year differs from the civil year, the annual return incorrectly falls back to the report’s FY-aligned year filter. The return should always follow the civil year, so the fallback is skipped and the return period filter is shown instead. task-5511074 Forward-Port-Of: odoo/enterprise#104726
This update resolves an issue preventing legal validation of the annual VAT report XML export for the Luxembourg (LU) localization. The fix adds missing required fields based on Luxembourg tax regulations, ensuring accurate report generation and compliance. This impacts users generating the annual VAT declaration.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update removes tax reports from the invoicing app to align with its intended purpose of providing basic invoicing features. Previously, the invoicing app was displaying tax reports, which are designed for accounting functionality. This change ensures users access the correct tools for invoicing while maintaining a streamlined experience.
Original PR description
Invoicing app is intended to provide basic invoicing features. Having the tax report shown allow the users to access return features that are intended for Accounting. Therefore, tax reports should be hidden in Invoicing and visible when accounting installed. task-5489532
This update resolves an issue where the softphone call list wasn't displaying correctly when a call session was missing. The fix ensures the ActionList is always rendered in CallInvitation and InCallView, providing a complete and functional call interface. This improves user experience and prevents missing call creation buttons.
Original PR description
We fix two problems: - With https://github.com/odoo/enterprise/pull/100630, a call session might be presented even it the associated call object is missing. In that case the session call is null. - With https://github.com/odoo/enterprise/pull/104426, when a call session is displayed and the call object is missing (i.e. the session call is null), the ActionList is not renderered and the button Create is missing. Here we improve the ActionList props validation and make it renderered in CallInvitation and InCallView even when the session call is null.
This update adjusts how product category names are handled within Odoo. Previously, complete category names were stored, but this has been removed. This change ensures data consistency and improves performance, particularly in reporting.
Original PR description
Adapt to product.category complete_name not being stored anymore Odoo PR: https://github.com/odoo/odoo/pull/236067 Upgrade PR: https://github.com/odoo/upgrade/pull/9279 task-4804824
This update resolves an issue where file uploads were incorrectly formatted as Base64 encoded data. Previously, this caused problems with importing files into the system. This change ensures files are handled correctly, improving the reliability of data import processes.
Original PR description
Like other Binary fields. https://github.com/odoo/odoo/pull/247189
This update fixes a bug in the automatic tour engine that prevented it from correctly identifying elements behind overlays like popovers and notifications. The change ensures the tour engine accurately avoids interacting with elements behind modals, improving the user experience and preventing potential issues with tour functionality.
Original PR description
Before this commit, the automatic tour engine checked whether the DOM contained a `.modal` and whether the trigger element was inside it, in order to avoid interacting with elements behind a modal. However, when the DOM also contained a popover or a notification, this check was skipped. With this commit, this logic has been improved to also take other overlay items into account. This improvement involves some fixes and adaptations in a few tours.
This update resolves an issue where subscriptions with zero-quantity lines resulted in invoices being incorrectly set to the subscription's start date. The fix ensures that invoice dates are accurately calculated, even when subscriptions include both positive and negative quantities, preventing incorrect billing.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#106364 Forward-Port-Of: odoo/enterprise#103705
This update resolves an issue where the printer selection wizard could generate errors when trying to use outdated printer records. The system now filters out printers that no longer match existing devices, ensuring a smoother and more reliable user experience. This prevents potential disruptions to business processes.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device. Forward-Port-Of: odoo/enterprise#106268
This update ensures that freight costs are now accurately included in the customs documents generated for international shipments. Previously, these costs were incorrectly set to zero, leading to potential inaccuracies in customs declarations. This change aligns with Sendcloud's API specifications and improves the accuracy of international delivery data.
Original PR description
Issue ----- For international deliveries, the customs document does not include the freight costs. Steps to reproduce ----- - Create an international sale (eg BE -> US) - Validate delivery - Open the commercial invoice > Freight costs is set to 0 Change ----- The `freight_costs` should be included in the `customs_information` field of the request (along with all customs-related data, as other fields have been deprecated) https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/operations/create-a-parcel#:~:text=object%2E-,customs%5Finformation ----- Ticket: opw-5486742 Forward-Port-Of: odoo/enterprise#106387 Forward-Port-Of: odoo/enterprise#105543
This update resolves an error that occurred when employees were linked to multiple commission plans using the same payslip input. The fix ensures accurate currency conversion for commissions, preventing a system error and guaranteeing correct payslip generation for employees with multiple commission plans. This improves payroll accuracy and reliability.
Original PR description
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the hr_payroll_sale_commission module. 2. Create a user and link to an employee. Set a contract for the employee. 3. Create two commission plans for the same user: - Use the same Payslip Input in both plans. - Set the Target Frequency to "Monthly" for both. 4. Generate a payslip for the employee. Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing) **Error:** `ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)` **Cause:** When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion. **Fix:** This commit ensures the currency conversion is applied per commission and prevents the singleton error. sentry-7187854690 Forward-Port-Of: odoo/enterprise#106124 Forward-Port-Of: odoo/enterprise#104464
This update fixes an issue where WhatsApp messages to blacklisted numbers weren't being blocked correctly when the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers, regardless of the recipient's location, are properly identified and blocked, improving communication security and compliance.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update fixes an issue where move quantities weren't correctly updated after exiting a barcode MRP operation. Specifically, when adjusting component quantities, the system incorrectly displayed remaining quantities. The fix ensures accurate tracking of product movements during and after barcode-based manufacturing processes.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update resolves a CFDI validation error that occurred when generating payroll reports with no deductions configured. The fix ensures that the system correctly handles payroll structures without deductions, aligning with Mexican tax regulations. This prevents validation failures and ensures accurate CFDI reports.
Original PR description
…eductions Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail. Steps to reproduce: - Set up…
…eductions
Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail.
Steps to reproduce:
- Set up Payroll Structure "Mexico: Regular Pay" with Salary Rules:
- Used subsidy:
- Code: SUBSIDY
- Category: Allowance
- CFDI Concept: (O02) Employment Subsidy (Effectively Delivered to the Worker)
- Deduction:
- Code: DEDUCTION
- Category: Deduction
- CFDI Concept: (D04) Others
- Net Salary:
- Code: NET
- Category: Net
- CFDI Concept: (P01) Salaries, Wages, Stripes, and Day Labor
- Formula: `result = payslip.paid_amount`
- In Payroll > Payslips, Click 'New Off-Cycle'
- Select employee, compute sheet, create draft journal entry and post it
- Back to the payslip, mark as paid and generate CFDI
Issue:
CFDI Validation will fail with error
`Code : 301 Message : Error en complemento Nómina. [Error #NOM38] El atributo Nomina.TotalDeducciones, no debe existir. Folio: 0002. Serie: SLR/2025/12.`
It occurs because, according to the official specs [1] attribute `TotalDeducciones` should not be reported in case there are no deductions
[1] http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/GuiallenadoNomina311221.pdf
opw-5348789
Forward-Port-Of: odoo/enterprise#104311Code cleanup and technical improvements
This update replaces outdated HTML elements (`<a>` tags) with more appropriate `<button>` elements within the Odoo Notebook. This improves the user experience by ensuring interactive elements are correctly handled and aligns with standard web development practices. It's a minor refactoring that enhances usability.
Original PR description
This commit properly uses `<button>` element for interactive DOM elements instead of relying on a "hacky" and non-semantic `<a href="#">` (tl;dr: `<a>` HTML tag are for navigation, `<button>` are for interactivity). task-4380519
This update streamlines the integration of IoT devices into the MRP module. By consolidating related modules and maintaining a separate quality control module, the setup process is simplified and the option to install the separate quality app is preserved.
Original PR description
IoT integration into mrp was divided in four modules: `quality_iot`, `quality_control_iot`, `mrp_workorder_iot` and `quality_mrp_workorder_iot`. In order to simplify the integration, we merged `mrp_workorder_iot` and `quality_mrp_workorder_iot` into one single `mrp_iot` module, and kept `quality_control_iot` as a separate module. We also kept `quality_iot` as it's a base for `mrp_iot` and `quality_control_iot` to link IoT Devices `quality.check` and `quality.point` models. Note: the reason for not merging everything into `mrp_iot` is to allow NOT having to install the quality app (tech name: `quality_control`). see odoo/upgrade#8711 Task: 5215787
20 changes
Enhancements to existing features
This update enhances the booking view in the Odoo Enterprise system by adding breadcrumbs. This provides clearer navigation for users, making it easier to understand their location within the booking process and improving the overall user experience. The change was implemented to streamline workflow and reduce potential confusion.
Original PR description
In this commit: - Enable breadcrumbs for the booking view by explicitly allowing them in the action context. Task:5490961
Resolved issues and error corrections
This update resolves an issue where toggling the Studio feature in Odoo Enterprise would sometimes disrupt the layout of form stat buttons. Now, the stat button layout remains consistent regardless of whether Studio is active, ensuring a better user experience when designing and editing forms.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309
This update resolves a technical problem with the way sale commission IDs were generated, preventing errors caused by IDs exceeding JavaScript's maximum safe integer limit. The change increases the range of IDs allowed for the 'plan_id' field, significantly expanding the number of commissions that can be tracked without causing errors. This improves system stability and scalability.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable.
This update corrects a technical issue causing duplicate Worldline receipts to be generated in POS transactions. The fix ensures receipts are only added when a transaction is fully completed, improving the accuracy of sales records. This resolves a reported problem impacting transaction reporting.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655
This update fixes an issue where appraisal templates couldn't select departments without a linked company. The fix ensures all departments are visible in the dropdown, improving usability and preventing employees from being restricted to departments with company associations. This resolves a bug impacting template configuration.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581This update resolves a critical issue preventing the legal validation of annual VAT reports for Luxembourg. The fix adds missing required fields to the XML export, ensuring compliance with reporting regulations. This ensures accurate tax reporting and avoids potential delays or penalties.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update ensures that freight costs are accurately reflected on international delivery customs documents generated by SendCloud. Previously, these costs were missing, leading to potential discrepancies in customs declarations. This change aligns with SendCloud's API specifications and improves the accuracy of international shipping documentation.
Original PR description
Issue ----- For international deliveries, the customs document does not include the freight costs. Steps to reproduce ----- - Create an international sale (eg BE -> US) - Validate delivery - Open the commercial invoice > Freight costs is set to 0 Change ----- The `freight_costs` should be included in the `customs_information` field of the request (along with all customs-related data, as other fields have been deprecated) https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/operations/create-a-parcel#:~:text=object%2E-,customs%5Finformation ----- Ticket: opw-5486742 Forward-Port-Of: odoo/enterprise#106387 Forward-Port-Of: odoo/enterprise#105543
This update resolves an error that occurred when employees were linked to multiple commission plans using the same payslip input. The fix ensures accurate currency conversion for each commission, preventing a system error and guaranteeing correct pay calculations for employees with multiple commission agreements. This improves the reliability of payroll processing.
Original PR description
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the hr_payroll_sale_commission module. 2. Create a user and link to an employee. Set a contract for the employee. 3. Create two commission plans for the same user: - Use the same Payslip Input in both plans. - Set the Target Frequency to "Monthly" for both. 4. Generate a payslip for the employee. Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing) **Error:** `ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)` **Cause:** When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion. **Fix:** This commit ensures the currency conversion is applied per commission and prevents the singleton error. sentry-7187854690 Forward-Port-Of: odoo/enterprise#106124 Forward-Port-Of: odoo/enterprise#104464
This update resolves an issue that prevented the 'hr_expense_stripe' module from installing correctly in countries without Stripe integration (like Romania). The fix removes a redundant constraint that triggered the error, ensuring proper installation and functionality across all supported localizations.
Original PR description
[FIX] hr_expense_stripe: error when installing loca not supported Step to reproduce the bug: - install 'hr_expense_stripe' - try to install a localization where Stripe is not available (e. g. Romania) - The error raise This is due to an @api.constrains that can be removed no-task
This update adjusts the scheduling of a daily report generation process. By extending the cron interval to 9999 months, the automatic execution is disabled, preventing unnecessary database activity and improving system performance. This change ensures the real-time, trigger-based workflow remains efficient.
Original PR description
The cron interval is updated from 1 day to 9999 months to effectively Disable automatic execution. The workflow is fully real-time and trigger-based, and running this cron Daily would unnecessarily wake up registries and databases. task-5885482
This update fixes an issue where WhatsApp messages to blacklisted numbers weren't being blocked correctly when the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers, regardless of recipient location, are properly blocked, improving communication security and preventing unwanted messages.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update fixes an issue where the quantity displayed after exiting a barcode MRP operation was not accurately reflecting the remaining quantities. Specifically, the system incorrectly handled move quantities when the operation was completed, leading to display discrepancies. This ensures accurate quantity tracking within the MRP process.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update resolves a bug that incorrectly flagged journal entries with mixed expense and revenue accounts (without deferred dates) as invalid. Previously, the system enforced a strict rule about matching deferred entry generation methods. Now, the validation only applies when actual deferred dates are configured, improving usability for common miscellaneous operations.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update resolves a bug where the POS ID wasn't correctly sent to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, and a related change restricts blackbox device selection in the POS configuration, improving data integrity and security.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update fixes a potential issue where bank reconciliation cron jobs would fail if notification emails couldn't be sent. Now, notifications are queued for later delivery, ensuring the cron job completes successfully and avoids rescheduling the next day. This improves the reliability of bank statement reconciliation.
Original PR description
[FIX] account_accountant: cron auto reconcile - mail notification concurency The aim of this commit is to prevent the cron from failing due to an issue in sending notification in the post_commit hook. Context: The issue was spotted on odoo.com while import bank statement transaction Before this commit: Failing to write on mail_notification during the post_commit hook could make the entire cron fail and be reschedule to the next execution date. (The next day by default) After this commit: The mail_notification are put in the mail queue to be sent later on. Task-id: None
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. Now, reloading the spreadsheet after deleting archived revisions correctly applies the most recent changes, ensuring data integrity and preventing data loss.
Original PR description
Steps to reproduce - create a spreadsheet - do a few changes - leave the spreadsheet (to snapshot) - reopen the spreadsheet - do a few more changes - from another tab, go to Settings/Technical/Revisions - delete all archived revisions - reload the spreadsheet => the last changes are lost and new changes are no longer saved.
This update resolves an issue where sign requests created on older Odoo versions (prior to 16.0) would fail due to missing communication company information. The fix automatically uses the user's company date format in these cases, ensuring sign requests can be processed without errors.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price charge products from the sync process, ensuring smoother integration with UrbanPiper.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a problem with Indian GST reports where test cases were failing due to a recent community fix. The test cases have been updated to correctly reflect the new label format that includes the bill reference, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update resolves a technical issue related to how time off is reported to the next month. A rounding error was causing incorrect work entries, preventing employees from properly deferring time off. This fix ensures accurate reporting and avoids potential payroll discrepancies.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours
4 changes
Resolved issues and error corrections
This update resolves a technical error that prevented the correct display names from being set for spreadsheet cell threads. The change ensures that only one display name is retrieved, preventing a system crash and improving spreadsheet functionality. This resolves a minor internal issue.
Original PR description
**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947
This update resolves an issue where the bank reconciliation widget incorrectly displayed the previous partner's name after a partner was removed from the liquidity line. The fix uses a direct database update to clear the partner name field, ensuring the UI accurately reflects the current bank statement. This improves the user experience and data accuracy.
Original PR description
When a user removes the partner from the liquidity line in the bank reconciliation widget, the 'partner_name' field on the statement line is not cleared. This results in the UI displaying the old name even though the partner is removed. in the first time i wanted to fix the issue with the standard ORM (e.g., `self.st_line_id.partner_name = False`) but it triggered a traceback. This occurs because `bank.rec.widget` is a virtual model defined with `_table_query = "0"`. When the ORM propagates the write operation, it attempts to query this virtual table `SELECT ... FROM (0)`. the fix now is a raw SQL update to set `partner_name` to NULL on the `account_bank_statement_line` to bypasses the ORM's dependency tracking for the virtual model. The cache is then explicitly invalidated to update UI. opw-5400705
This update resolves a performance issue in the tests related to importing attachments for the l10n_co_dian module. The change optimizes the test process to prevent it from taking too long, ensuring smoother development and testing. This improves the overall stability and efficiency of the Colombian localization updates.
Original PR description
This PR adapts the test "test_dian_import_vendor_xml" to align with the changes introduced by this PR : https://github.com/odoo/odoo/pull/245577 We patch the attachments import to not exceed the tests time. task-5500236 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves a technical issue that caused a SQL error when creating invoices with non-deductible tax values in Odoo. The fix prevents the error by skipping the problematic SQL query when invoice lines are not yet saved, ensuring smoother invoice creation.
Original PR description
**Steps to reproduce:** * Install **account_asset** and **l10n_be**. * Enable **developer mode**. * Using **Studio**, add the field **non_deductible_tax_value** to invoice lines. * Create a new invoice. * Select a partner and add a product with **21% VAT** applied. * Do not save the invoice before adding the line. **Observed behavior:** * A **SQL syntax error** occurs: `WHERE tdq.base_line_id IN ()`. * The error is triggered when accessing the non-deductible tax value on unsaved records. **Cause:** * `_compute_non_deductible_tax_value()` executes SQL query with `tuple(self.ids)`. * For unsaved records, `self.ids` is empty, creating invalid SQL `IN ()` syntax. * This path is only reached for **non-deductible taxes**. **Fix:** * Skip the SQL query when no record IDs are available. * Return a default value for unsaved records. opw-5896716
3 changes
Enhancements to existing features
This update enhances the accuracy of financial reports by addressing discrepancies caused by partial analytic item distributions. It introduces a 'coverage ratio' for each analytic plan, allowing users to easily identify and resolve incomplete distributions during audits, leading to more reliable financial insights.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978
Resolved issues and error corrections
This update corrects a misleading error message displayed when validating Argentine VAT invoices. The message has been changed to accurately reflect the issue: that the invoice date cannot be before the last validated invoice in AFIP. This ensures accurate invoice processing and compliance with Argentine regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first item. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417