Daily updates from Odoo
Wednesday, February 4, 2026
163 changes
11 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability where temporary customer data credentials (RDTs) were being logged in application logs. This prevented sensitive information like buyer names and addresses from being exposed outside of controlled environments, reducing potential data breaches. The change prevents logging of RDTs during specific operations.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
New functionality added to Odoo
This update adds missing templates for Equity and Government checks within the Odoo Enterprise accounting reports. This ensures accurate and comprehensive financial reporting, fulfilling a key requirement for compliance and data integrity. It builds upon previous work to fully complete the data set.
Original PR description
Completes the work started in odoo/enterprise#88360. The Equity and Government check templates were missing and are added here to fully complete the data. task-5365677 Forward-Port-Of: odoo/enterprise#103954
Enhancements to existing features
This update significantly improves the speed of database synchronization for our SaaS customers. By intelligently grouping and processing database requests in parallel, we've reduced synchronization times from 50 seconds to just 15 seconds. This translates to a more responsive and efficient system for our users.
Original PR description
With this commit, the requests sent to retrieve the information from the databases are grouped by IP, and each group is treated in parallel using a ThreadPoolExecutor, which uses a pool of 5 times the number of CPUs. On a set of SaaS databases, we reduced the time needed to synchronize 30 databases from 50s to 15s. Forward-Port-Of: odoo/enterprise#105673
This update ensures Odoo complies with Mexican tax regulations (SAT) regarding the descriptions of refunded products. Specifically, for global invoices, refund descriptions now include the return amount, discounts, or bonuses, as required by the SAT. This change simplifies reporting and reduces the risk of compliance issues.
Original PR description
The SAT specifies how the description of refunded product should be set and specifically for refunds of global invoices it should contain the amount of the return, discount or bonus and why. Currently, Odoo when a credit note of a global invoice is issued, it sets an specific label for the description. To keep with what SAT asks for, we will keep that label only for credit notes of pos global invoices, and for the others, we keep from what the user put as an input on the line task-5170675 target: 19.0 -> master Forward-Port-Of: odoo/enterprise#97681
Resolved issues and error corrections
This update reactivated previously disabled tests related to MRP work orders, ensuring proper functionality. Specifically, tests now verify that users with limited access can still complete work orders and that the system correctly handles scenarios involving analytic accounting. The changes include a fix for a setup issue related to user creation.
Original PR description
Bring back all tests temporarily disabled by [1] `.test_mrp_aa_employee_without_account_rights` `.test_user_can_complete_workorder_despite_project_restrictions` Use lowest rights level. This explains the needed `sudo` in: `/project_mrp_workorder_account:MrpWorkcenterProductivity.write` [1] https://github.com/odoo/enterprise/commit/be6eb5e22283e952554b1bab435a7113f3061e23 Forward-Port-Of: odoo/enterprise#105626
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by qua
Original PR description
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an…
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by quantity - Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point) - Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1) - Click on Order - Open the created MO and the Shop Floor (Remove the filters to see the WO) - Complete the Quality Point - Modify the Reordering Rule (Min/Max: 2) - Click on Order - the error should be raised ### Cause: The MO to update is retrieved here: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153 In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created opw-5012588 Forward-Port-Of: odoo/enterprise#104158 Forward-Port-Of: odoo/enterprise#101313
This update resolves an issue preventing users from viewing Lazada order package status within Odoo. The fix grants necessary access to the 'Lazada Order Item' model for users with Sales and Inventory permissions, ensuring accurate order tracking. Users needing access should contact their administrator.
Original PR description
Versions -------- - 19.0+ Steps ----- Two issues: 1. Create a new user with `Sales "User: Own Documents Only"` rights, and `Inventory "User"`. 2. Try to access any picking or sale order. Issue ----- ``` Failed to read field stock.move.lazada_order_item_ids You are not allowed to access 'Lazada Order Item' (lazada.order.item) records. This operation is allowed for the following groups: - Sales/Administrator Contact your administrator to request access if necessary. ``` Cause ----- Both the picking form view and the sale order form view need access to the `lazada.order.item` model to display the pacakge status on Lazada. However, all Lazada specific models are only accessible with Sales "Administrator" rights. Solution -------- Add read access to `lazada.order.item` for stock and sales users. Forward-Port-Of: odoo/enterprise#105889
This update fixes an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas. The change moves a key component to resolve this truncation problem, ensuring statements are displayed cleanly and accurately. This improves the user experience when reviewing financial transactions.
Original PR description
When we have a lot of reconciled names, it can happens that you just have a long list of comma. It's because the text truncate was misplaced. This commit will fix this by moving the text truncate no task id Forward-Port-Of: odoo/enterprise#106242 Forward-Port-Of: odoo/enterprise#105674
This update fixes an issue where subscription invoices were being generated prematurely when a note or section was added to the subscription. The fix ensures that invoices are now correctly tied to the end of the subscription period, regardless of whether a note is present. This improves invoice accuracy and prevents potential billing discrepancies.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update resolves a bug that caused incorrect schedule calculations when using planning-based work entries, particularly with material-type resources. The fix restricts schedule computations to only include employee time slots directly associated with the current employee, ensuring accurate time tracking and reporting.
Original PR description
Steps to reproduce: - Set the work entry source to planning for an employee. - Create an attendance for that employee. Issue: - Errors occurred when planning slots linked to material-type resources were included in schedule computation. Fix: - Restrict planning slots used for schedule computation to records whose employee_id belongs to self.ids. task-5476771 Forward-Port-Of: odoo/enterprise#103951
This update corrects a minor issue where project forms accessed through SmartButtons were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing edits, ensuring users can now properly manage projects. The cause of this setting is currently unknown.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#1052257 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability where temporary credentials (RDTs) were being logged in Odoo's system logs. This prevented sensitive customer information, like names and addresses, from potentially being exposed in support tickets or monitoring reports. The change now prevents logging of these credentials, strengthening data protection.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Resolved issues and error corrections
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 delayed invoicing.
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#106226 Forward-Port-Of: odoo/enterprise#103705
This update resolves an issue where the fuel card benefit was incorrectly enabled in the salary configurator when no company car was chosen. The fix ensures the field is initially disabled and remains so until a company car is selected, preventing data inconsistencies and simplifying the user experience. This improves data accuracy and reduces potential errors.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
This update ensures that freight costs are now accurately included in the customs documents generated for international deliveries. Previously, the system incorrectly reported freight costs as zero. This change aligns with Sendcloud's API specifications and ensures accurate customs documentation for international shipments, improving compliance and transparency.
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#105543
This update fixes a problem that prevented payslips from generating correctly when employees were linked to multiple commission plans using the same input. The change ensures accurate currency conversion for each commission, resolving a technical error that impacted payslip generation. This ensures consistent and reliable commission calculations for all employees.
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#104600 Forward-Port-Of: odoo/enterprise#104464
This update fixes an issue where subscription invoices were being generated prematurely when a note or section was added to the subscription. The fix ensures that invoices are now correctly calculated based on the end of the subscription period, regardless of whether a note is included. This improves invoice accuracy and prevents billing discrepancies.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The team removed a setting that was causing this behavior, which was unexpectedly added. This ensures all project forms are correctly editable within Odoo.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#1052258 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability where temporary customer data credentials (RDTs) were being logged in application logs. This prevented sensitive information like buyer names and addresses from being exposed outside of controlled environments, reducing potential data breaches. The change prevents logging of RDTs during specific operations.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Resolved issues and error corrections
This update corrects a bug in the salary configurator where the fuel card benefit would incorrectly appear enabled if no company car was selected. The fix ensures the field is properly initialized on initial load, preventing inconsistent data and ensuring the correct benefit options are displayed.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
This update resolves a bug in the Odoo 18.3 website sale subscription test. The test was failing to correctly enable pricelists. A simple code change was made to the test itself to ensure pricelists are properly activated, improving test reliability.
Original PR description
In the current 18.3 configuration, the test for pricelists fails to properly enable the feature when initialising the test class. Added a write call enabling the feature to the test code itself. runbot error [222878](https://runbot.odoo.com/odoo/error/222878)
This update resolves an issue where sign requests created on older Odoo versions (before 16.0) would crash due to missing communication company information. The fix automatically uses the user's company date format when a communication company isn't available, ensuring sign requests can be processed correctly.
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)This update fixes an issue where subscription invoices were being generated prematurely when a note or section was added to the subscription order. The fix ensures that invoices are now correctly calculated based on the subscription period, regardless of whether a note is present. This improves invoice accuracy and prevents potential billing discrepancies.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows partners to be correctly identified as both customers and suppliers, ensuring accurate reporting of financial balances. This resolves a discrepancy impacting the SAFT report generation.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#105893 Forward-Port-Of: odoo/enterprise#100749
This update resolves a bug that incorrectly flagged miscellaneous entries without deferred dates as incompatible with different entry generation methods. The fix ensures validation only applies when deferred dates are actually configured, improving usability for users managing general operations. This prevents unnecessary errors and streamlines the posting process.
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
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The team removed a technical setting that was causing this behavior, ensuring all project forms now function correctly. This resolves a usability problem for users.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#1052257 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability by preventing the logging of sensitive access tokens (RDTs) used to access customer data. Previously, these tokens were inadvertently exposed in application logs, increasing the risk of unauthorized access. This change enhances data protection and aligns with security best practices.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Resolved issues and error corrections
This update ensures that freight costs are now accurately included in the customs documents generated for international deliveries. Previously, the system was omitting this crucial information, which could lead to incorrect 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#105543
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#106299
Forward-Port-Of: odoo/enterprise#104556This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments accurately reflect the current employee status, preventing data inconsistencies and improving reporting accuracy. This change was made to maintain data integrity within the payroll system.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where the fuel card benefit was incorrectly enabled in the salary configurator when no company car was selected. The fix ensures the field is initially disabled until a car is chosen, preventing inconsistencies and simplifying the user experience. This improves data accuracy and reduces potential errors.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
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 guaranteeing successful payment processing for our European customers. 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#105518
This update corrects an issue where project forms accessed through SmartButtons were initially displayed as uneditable. The fix removed a redundant setting that was causing this behavior, ensuring users can now properly interact with project forms. The root cause of the original setting is currently unknown.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#1052257 changes
Enhancements to existing features
This update improves sales forecasting by displaying Monthly Recurring Revenue (MRR) within sales quotations. Previously, only recurring and non-recurring amounts were shown, making it difficult to accurately predict revenue targets. The MRR is now prominently displayed below the quotation totals, streamlining the sales process.
Original PR description
As a salesperson, I need to easily see the Monthly Recurring Revenue (MRR) of a subscription in the quotation so that I can forecast targets in the commission module. Currently, only the recurring and non-recurring amounts are shown, but the MRR is not displayed. The MRR is now shown below the totals in the quotation form. If the MRR is equal to the recurring amount, the recurring amount is hidden to avoid duplication. task-5436781
Resolved issues and error corrections
This update fixes issues with how Odoo websites extract content, specifically addressing problems with robots.txt checks and content cleaning. The changes ensure accurate data collection from Odoo websites by refining noise removal and preventing errors in content extraction logic.
Original PR description
## Fix Summary - Include the instance's base URL in internal domains to allow bypassing robots.txt checks for sites that have no domain. - Fix the scraper's cleaning logic to prevent content containers deletion edge cases on Odoo websites. - Refine noise removal for Odoo websites (popups, cookie bars, etc.). Forward-Port-Of: odoo/enterprise#106237
This update resolves an issue where overtime approvals weren't consistently linked to attendance records. Previously, only one attendance was associated with overtime, leading to data inconsistencies. This fix ensures accurate tracking of overtime hours against all relevant attendance records, improving reporting and payroll accuracy.
Original PR description
…dance and overtime
STEP TO REPRODUCE:
------------------
1- Create an overtime rule with this configuration :
quantity rule differs from hours defined in the contract
2- Create two attendances on the same day (should be a worked day and should not be today)
one from 1AM-2PM
second from 2PM-undefined
3- Approve the overtime of the first attendance
REASON:
------
The link between overtime to attendance is not correctly done Attendance -> overtime (only the first attendance have a link with overtime) overtime, attendance -> the two will be returned
Forward-Port-Of: odoo/enterprise#106083
Forward-Port-Of: odoo/enterprise#105988This update fixes an issue where canceled refunds were incorrectly included in global invoices generated from Point of Sale orders. The fix filters out canceled refund lines during invoice generation, ensuring accurate reporting. This improves the reliability of financial data for Mexican VAT reporting (l10n_mx_edi_pos).
Original PR description
When generating global invoices for orders in the PoS, refund of those orders are also included in the global invoice. However, if the refund has been canceled, it should not be included in the global invoice. Steps to reproduce: ------------------- * Create a PoS order and validate it. * Go to the backend and create a refund for that order. * Cancel the refund. * Go to the PoS order list and select the original order * Click on "Generate Global Invoice" > Observation: The canceled refund is included in the global invoice. Why the fix: ------------ We simply filter out the canceled orders when searching for refunded order lines. opw-5492576 Forward-Port-Of: odoo/enterprise#106243 Forward-Port-Of: odoo/enterprise#105868
This update fixes an issue where the headers in the Gantt view were not staying in place while scrolling. The change restores the sticky header functionality, ensuring users can easily see and interact with the view's title, group headers, and column headers. This improves usability and data visibility within the Gantt chart.
Original PR description
Following DOM structure changes introduced in https://github.com/odoo/enterprise/pull/103230, the Gantt view title, group headers, and column headers lost their sticky behavior and would scroll out of view. This commit restores the sticky positioning by applying the `sticky-top` class to the relevant header elements. task-5896158
This update fixes an issue where malformed PDFs caused errors during the signature process. The system now attempts a more lenient PDF parsing method if the initial attempt fails, ensuring signatures can be processed more reliably. This improves the overall stability and functionality of the signature workflow.
Original PR description
Before this commit, opening some malformed PDFs 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
The Odoo portal payment screen now displays a warning message when no payment providers are available, preventing the screen from scrolling to the bottom. This ensures users receive clear guidance and avoids a confusing user experience when payment options are unavailable. This resolves a previous issue where users didn't see any payment methods or warnings.
Original PR description
The portal payment screen incorrectly scrolls to the bottom when the Pay button is clicked, but no payment methods or warning message are shown. This happens when no payment provider is published. This PR fixes the issue by ensuring the "no provider" warning message appears in all cases. task-5388313 Forward-Port-Of: odoo/enterprise#101632
11 changes
Security fixes and vulnerability patches
This update fixes a potential security vulnerability by preventing the logging of sensitive access tokens (RDTs) generated by the Amazon connector. These tokens contain customer data and, if exposed in logs, could lead to privacy breaches. This change enhances data protection and aligns with security best practices.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Enhancements to existing features
This update simplifies the one-time payment form by removing a redundant version field. The form now automatically displays payments for the correct employee based on the context, ensuring accuracy and streamlining the process. This change improves usability and avoids potential errors.
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
Resolved issues and error corrections
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
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
This update resolves an issue where the printer selection wizard could generate errors when attempting to use printers that had been removed from the database. By filtering out printers without corresponding devices, the system now avoids these errors, ensuring a smoother user experience.
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.
This update fixes an issue where recurring prices on ecommerce product pages used incorrect grammar, specifically displaying billing periods in singular form. The change ensures that recurring prices always use the correct plural form, resulting in a more professional and user-friendly experience for customers.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937
This update fixes an issue causing payment terminal receipt text to display with unwanted styling (borders and light/dark mode). The fix removes a specific CSS file that was incorrectly applied to the POS, ensuring a cleaner and more professional receipt appearance. This improves the user experience for customers using the point-of-sale system.
Original PR description
The `pos_appointment` module includes all of the `html_editor` assets into POS, despite only a small subset of the functionality being used. One of these assets was an SCSS file that set code block styling on all `pre` elements. Since the POS uses `pre` elements to display the text from payment terminals on the receipt, it was causing this text to be drawn with a border box and light/dark mode styling. The fix is to remove this specific SCSS file from the POS bundle. It shouldn't affect `pos_appointment` functionality since the code editing plugin is not loaded. Before: <img width="325" height="694" alt="image" src="https://github.com/user-attachments/assets/1c23ee18-0832-496f-b69e-8d9e90b5ed73" /> After: <img width="337" height="700" alt="image" src="https://github.com/user-attachments/assets/2998e66f-c582-422b-b3c7-31bcb849e75b" />
This update resolves an issue where users with only sales access couldn't view invoices. The fix grants the 'salesman' group the necessary read permissions to the asset data, allowing them to correctly access and manage invoices within the Enterprise module. This ensures sales teams have full visibility into related financial transactions.
Original PR description
### Issue: User with sale access group cannot access invoices. #### Steps to reproduce: - Install demo data - In user setting, `Access Rights` tab, remove `Accounting` access and set `Sale` access to Administrator for user Demo. - Log in using Demo user. - Create a SO, and after confirming, create an invoice. - As you see, you will get access rights error. ### Cause: Group salesman doesn't have `read` access on `account.asset`. As a result on enterprise, `account.move._compute_asset_ids` fails: https://github.com/odoo/enterprise/blob/c366abe1d3423d5e184675b5fb786b5f401ae94f/account_asset/models/account_move.py#L320 Community PR: odoo/odoo#242516 Ticket [link](https://www.odoo.com/odoo/project.task/5461135) opw-5461135
This update fixes an issue where the employee's filling status wasn't updating correctly when the associated address state was changed. The system now dynamically adjusts the filling status based on the employee's working address location, ensuring accurate payroll calculations for states like Alabama. This resolves a discrepancy in state-based filling status updates.
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
This update adjusts the way product prices are stored within Odoo, ensuring greater accuracy and consistency. The change addresses a technical issue identified in previous testing, improving the reliability of price calculations. This update primarily impacts the core functionality of product management.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#106203 Forward-Port-Of: odoo/enterprise#104728
This update resolves a bug where invoice users were inadvertently viewing subscription details within the Odoo Enterprise system. The change filters access to subscription information, ensuring that only authorized users (e.g., subscription managers) can see these sensitive data. This improves data security and prevents unauthorized access to subscription information.
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, returns always adhere to the correct 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
10 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability where temporary credentials (RDTs) used to access customer data were being logged in application logs. This prevented sensitive information like buyer names and addresses from being exposed outside of controlled environments, reducing the risk of data breaches. The change disables logging for operations handling these sensitive credentials.
Original PR description
Previously, the connector logged all SP-API responses for debugging purposes. When operation is `createRestrictedDataToken`, this would also log the `restrictedDataToken` in plaintext. RDTs are short-lived credentials that grant access to PII (buyer names, addresses, etc.) and should not appear in application logs. While the token is only stored in memory while in use, logs are frequently shared in support tickets, error reports, and monitoring systems without the same access controls, making credential exposure far more likely. This commit adds a parameter to disable logging for operations that return sensitive data. opw-5491878 Forward-Port-Of: odoo/enterprise#105178
Enhancements to existing features
This update adjusts a test case within the l10n_pe_edi module to reflect a recent change in how debit notes are processed through Peppol. This ensures the test case accurately validates the system's functionality after the Peppol update. The change was necessary to accommodate the addition of a new node during debit note creation.
Original PR description
A Node was added when creating debit notes in peppol, so the change was also applied to the debit note template to adjust a test case task-5875689
Resolved issues and error corrections
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, improving the reliability of the fiscal data reporting process. Additionally, a security enhancement restricts blackbox device selection to the Fiscal Data Module in POS configuration settings.
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
This update resolves an issue where tickets in 'folded' (closed) stages were incorrectly displayed in the helpdesk email plugin. The fix ensures that closed tickets are filtered out, preventing them from appearing in the plugin's results and improving the user experience. This ensures users only see active tickets.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477
This update resolves a problem with Indian GST reports where test cases were failing due to a recent change in how payable lines are labeled. The test cases have been updated to now correctly account for 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
A bug was causing incorrect order quantities to be sent to the kitchen when using the numpad in the POS Restaurant Preparation Display module. This was resolved by adding a brief delay to ensure the quantity is updated before the order is submitted, preventing errors in the kitchen display.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We add a small delay after using the numpad to ensure the quantity is updated before sending the order.
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 UrbanPiper and preventing potential errors.
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
This update resolves an issue preventing the legal validation of annual VAT reports for Luxembourg companies. The fix adds missing required fields to the XML export, ensuring compliance with reporting regulations. This resolves a technical problem impacting report generation and submission.
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#105143
This update resolves an issue where the 'Validate' button in the shopfloor picture instruction wizard remained disabled after a user encountered an error (missing picture). The fix ensures the button is re-enabled, preventing users from needing to restart the wizard and improving the manufacturing workflow. This enhances user experience and efficiency.
Original PR description
Current behavior: When trying to validate a picture instruction in shopfloor, Odoo legitimately raises a UserError if the picture is missing. However, even after adding a picture afterward, the…
Current behavior:
When trying to validate a picture instruction in shopfloor, Odoo legitimately raises a UserError if the picture is missing. However, even after adding a picture afterward, the Validate button remains unclickable, forcing the user to close the wizard and start again.
Expected behavior:
Even if an error occurs during validation, the Validate button should remain clickable (especially once the cause is addressed).
Steps to reproduce:
- Create a BoM with one operation - Save.
- Add a "take a picture" instruction on this operation.
- Create a MO with this BoM, confirm it.
- Go to the shopfloor, find the WO of the created MO. Open "instructions".
- Click on the small camera to open the check wizard.
- Confirm without taking a picture or uploading an image.
- Error pops up ("Please upload a picture"), close the popup.
- Then add a picture. => The Validate button remains unclickable. We need to close and re-open the wizard to continue, which can be frustrating and time-consuming for manufacturing users, especially with many instructions.
Issue Explanation:
In MrpQualityCheckConfirmationDialog/doActionAndClose, this.props.record.model.orm.call can legitimately raise a UserError, but the button is disabled at the beginning of the method and remains in this state regardless of what happens afterward.
Fix:
Add a try-catch clause to re-enable the button if an error occurs.
Alternative fix:
The button should remain disabled until a picture is taken, but that sounds like a more disruptive change that might impact other flows.
### Open questions
Do we need to add a test for it? Only a JS tour is suitable which it seems a bit much for this kind of bug. What do you think?
https://github.com/odoo/odoo/pull/246481This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of the financial data.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018 Forward-Port-Of: odoo/enterprise#103357
2 changes
Resolved issues and error corrections
This update fixes an issue in the French Profit & Loss report where accounts 65 were incorrectly categorized. They have now been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of financial data for French users.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018
This fix resolves an issue where Modelo 390 reports for past years were incorrectly generating empty BOE files. The update ensures the report period is accurately identified, pulling the correct data for the specified year. This guarantees accurate tax reporting for Spanish businesses.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374