Daily updates from Odoo
Navigate
Branch
Wednesday, April 15, 2026
227 changes
9 changes
New functionality added to Odoo
This update introduces basic financial reports tailored for Uzbekistan businesses within Odoo. It includes essential reports like the Balance Sheet and Profit & Loss Report, allowing users to generate key financial data specific to Uzbekistan's accounting standards. This expands Odoo's capabilities to meet the needs of businesses operating in that region.
Original PR description
This commit introduces basic report package for Uzbekistan and includes Balance Sheet and Profit & Loss Report. task-3927927 Community PR - https://github.com/odoo/odoo/pull/241811 Forward-Port-Of: odoo/enterprise#113652 Forward-Port-Of: odoo/enterprise#103136
Enhancements to existing features
This update automatically populates the TimesheetSystray with the project and task the user was working on when they opened it, making it easier to start logging time. Before this change, users had to manually select these values. The update also ensures that the selected project and task are actually valid for timesheet tracking.
Original PR description
To ease UX, we default the project and/or task field of the TimesheetSystray to the one that the user has opened (if the values were not already set manually by the user). OPW-6122906
Resolved issues and error corrections
A recent update caused a type error during sign request processing, preventing users from accessing the sign functionality. This fix reorders the checks to ensure the existence of the sign item is verified before type comparisons, resolving the error and restoring normal operation.
Original PR description
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.…
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.
Traceback:
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```
Solution:
We first perform the existence check and then compare the types.
[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d
sentry-7376866293
Forward-Port-Of: odoo/enterprise#112659This update corrects a minor issue in the Batch Payment report. Previously, the report would incorrectly display placeholder values ('ABC Holder Name' and 'Demo Ref') when the Account Holder Name field was left blank. This fix ensures the report accurately reflects the payment details, providing a cleaner and more professional output for users.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update resolves a test failure related to inter-company stock transfers. The test required demo data to function correctly, which is no longer needed. By removing the dependency on demo data, the test now passes consistently in a standard Odoo environment.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update fixes an issue where the payroll warning date incorrectly jumped to the next month when the system date was set before the closing day. The fix ensures the warning remains in the current month until the closing day has passed, improving payroll accuracy and reducing potential user confusion.
Original PR description
steps to reproduce: - install `hr_payroll` - set closing day as "5th of next month" (via schedule warning) - set system date as <5 of the month - notice that the warning date jumped to next month description: - it should stay in the current month until closing day has passed cause: - there was no check for if the closing day has passed while in the next month scenario fix: - jump to next month only if today has passed closing date. (also fixed a wrong docstring) [task#6084911](https://www.odoo.com/odoo/project/1251/tasks/6084911)
This update fixes a calculation issue related to canteen costs in the payroll module for Belgium (l10n_be_hr_payroll). Previously, the system didn't accurately calculate canteen costs when there were no recorded workdays. This change ensures that canteen costs are now correctly simulated within the payroll configuration.
Original PR description
We add simulation context in the canteen cost condition, since we dont have worked day lines in that case
This update fixes a calculation error in the employment bonus payments for Belgian businesses. The change ensures that bonus calculations now precisely align with the requirements outlined by the Belgian Social Security authorities, as detailed in their official documentation. This correction improves accuracy and compliance for payroll processing.
Original PR description
The employment bonus computation was missing two roundings steps that are explicitely asked for in the following documentation: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/deductions/workers_reductions/workbonus.html Forward-Port-Of: odoo/enterprise#113776
This update fixes an issue where global invoices generated from customer invoices weren't correctly using the issued address's zip code in the XML file. The fix ensures that the 'LugarExpedicion' field accurately reflects the shipping address, improving compliance with Mexican tax regulations. This impacts invoicing accuracy for Mexican customers.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#112523 Forward-Port-Of: odoo/enterprise#108732
7 changes
New functionality added to Odoo
This update adds a guided tour for Worldline payment terminals when used with kiosks. This ensures seamless and correct payment processing, addressing a potential issue with kiosk integration and improving the overall user experience for customers using these payment methods.
Original PR description
We add a tour to ensure worldline payment terminals work correctly with kiosk. Forward-Port-Of: odoo/enterprise#105478
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment report. Previously, the report would incorrectly display placeholder text ('ABC Holder Name' and 'Demo Ref') when the Account Holder Name field was left blank. This change ensures the report accurately reflects the payment details, providing a cleaner and more professional output.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515A recent change in the sign request process caused a technical error that prevented users from accessing sign requests. This fix ensures that the system correctly checks for the existence of sign items before attempting to compare their types, resolving the underlying issue. This improves the reliability of the sign request functionality.
Original PR description
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.…
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.
Traceback:
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```
Solution:
We first perform the existence check and then compare the types.
[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d
sentry-7376866293
Forward-Port-Of: odoo/enterprise#112659This update corrects a bug in how Odoo calculates depreciation for companies with non-standard fiscal years (e.g., May-December). The fix ensures that depreciation entries are correctly generated for all months, regardless of the company's fiscal year start date, preventing missed accounting periods.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update resolves a test failure related to inter-company stock transfers. The test required demo data to function correctly, which is no longer present. This change ensures the test runs reliably in a production environment without relying on the demo database.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update fixes a calculation error in the employment bonus payments processed for Belgian employees. The change ensures that the bonus calculations now fully comply with specific requirements outlined by Belgian social security regulations, as detailed in the provided documentation. This correction improves accuracy and compliance with local laws.
Original PR description
The employment bonus computation was missing two roundings steps that are explicitely asked for in the following documentation: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/deductions/workers_reductions/workbonus.html Forward-Port-Of: odoo/enterprise#113776
Code cleanup and technical improvements
This update streamlines a key function within Odoo's account reporting module, specifically related to how it calculates analytic coverage. This simplification improves the speed and efficiency of generating reports, leading to faster processing times for financial data. The change focuses on internal technical improvements without impacting user-facing features.
Original PR description
Simplification of the function 'compute_sql_analytic_coverage' in account_analytic_line in the report module.
5 changes
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment reports. Previously, the report would incorrectly display default 'demo' values (like 'ABC Holder Name') when a customer's name wasn't provided. Now, the report correctly leaves these fields blank, ensuring accurate and professional-looking payment documents.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes an error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were incorrectly skipped for months within the wrong fiscal year. The fix ensures accurate depreciation calculations, particularly for companies using shortened fiscal years like May-December.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update corrects a discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate counts. Now, receipts are incorporated, ensuring dashboard metrics align with actual sales and purchase records for a more reliable view of business activity.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828 Forward-Port-Of: odoo/enterprise#111142
This update resolves an issue where users without administrator privileges accessing invoices created from email aliases with CFDI attachments would encounter an access error. The fix ensures that attachment records are properly configured, allowing the system to correctly fetch and display the attached XML files.
Original PR description
When accessing a bill created from an email alias with a user that is not system administrator, we get an access error if there is an xml attachment. Steps: - Configure an email alias for the…
When accessing a bill created from an email alias with a user that is not system administrator, we get an access error if there is an xml attachment. Steps: - Configure an email alias for the purchase journal - Receive a mail wth an xml attached - Create a user with group_user role and administrator right on accounting - log in with new user - access the created bill -> Access Error The root of the issue is that we don't attach xml files when we receive them from an email alias. To do so, we set res_model and res_id fields to False/0 (see `AccountDocumentImportMixin._fix_attachments_on_record`) Then, when trying to access the bill the method `AccountMove._get_mail_thread_data_attachments` add the `l10n_mx_edi_cfdi_attachment_id` to the attachments to fetch. Then the fetch method get a query from the `_search` method or `ir.attachment` and because the attachment has no res_id or res_model and user is not system (see https://github.com/odoo/odoo/blob/8f7807a763e7e272347e9c1622be862700409c34/odoo/addons/base/models/ir_attachment.py#L564-L578) we don't fetch the record and we end up with an access error (https://github.com/odoo/odoo/blob/8f7807a763e7e272347e9c1622be862700409c34/odoo/orm/models.py#L3497-L3500) Fix: Adding res_model and res_id to the `l10n_mx_edi_cfdi_attachment_id` record in its compute method opw-5953578
This update fixes a previous error that prevented invoice settlement when the associated customer information wasn't fully loaded. The change streamlines the process by directly using the customer's ID, ensuring smoother invoice processing and preventing disruptions to the payment workflow. This improves reliability and efficiency.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#111957
7 changes
Enhancements to existing features
This update enhances the process of updating German Point of Sale certification orders by ensuring sequential processing of changes. Additionally, redundant UI validation steps (ZIP and address checks) have been removed as the backend now handles default value assignments, streamlining the user experience.
Original PR description
In this commit: ------------------- - We have added logic to execute API calls using a mutex for order updates (such as line updates and removals). This ensures that each update is processed (sequentially), allowing us to properly track and maintain order consistency. - We removed the ZIP and address validation on the UI since the backend already assigns default values if they are missing. So, there’s no need to restrict the user on the UI. task:5941742 Forward-Port-Of: odoo/enterprise#113690 Forward-Port-Of: odoo/enterprise#108694
Resolved issues and error corrections
This update resolves an issue preventing Point of Sale (PoS) users from accessing the sinvoice symbol. By granting the necessary access rights, this change ensures PoS users can properly utilize the feature as intended. This improves functionality for retail operations.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update fixes an issue where MyInvois was receiving incorrect invoice amounts for individual POS transactions. The change ensures the Total Amount Payable accurately reflects the e-document's total value, aligning with MyInvois requirements and preventing payment discrepancies. This improves data accuracy for tax reporting.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#258824
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, presenting accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes a potential issue where website tours could incorrectly proceed if the chat feature was temporarily empty. The change implements a more reliable check to ensure the tour only continues when the empty chat is definitively confirmed, improving the overall user experience. This ensures tours function consistently and reliably.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed. Forward-Port-Of: odoo/odoo#258921
This update fixes an error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were incorrectly skipped for months within the wrong fiscal year. The fix ensures accurate depreciation calculations, particularly for companies using shortened fiscal years like May-December.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update ensures the 'send by Peppol' option in the accounting send wizard is only available for companies that are actually registered on the Peppol network. Previously, it was enabled automatically, which was misleading and inaccurate. This change improves data accuracy and aligns with registration requirements.
Original PR description
Previously, the send wizard would automatically enable the send "by Peppol" option whenever Peppol was available for the company's country. This behavior was misleading, as it didn't check whether the company was actually registered on Peppol. This commit ensures the option is only enabled for companies that are registered on Peppol. task-6044073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255791 Forward-Port-Of: odoo/odoo#254671
3 changes
Enhancements to existing features
This update simplifies the creation of Spanish tax reports (303 and 347) for users. Specifically, the 'exonerated from 390' field is now automatically displayed on the print wizard for recent periods, eliminating manual steps. Additionally, the annual report 347 now groups data by move type and date for enhanced audit capabilities.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#108057
Resolved issues and error corrections
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for customers without specified account holder names.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes an error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were incorrectly skipped for months within the wrong fiscal year. This change ensures accurate depreciation calculations, particularly for companies using shortened fiscal years like May-December.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
55 changes
New functionality added to Odoo
This update introduces support for Flexi-Jobs, a key feature in Belgium's payroll system. It implements two crucial rules: a percentage-based remuneration deduction (flexi-pecule) and an exemption from ONSS and withholding taxes for the first €18,440 of annual earnings. This enhancement simplifies payroll processing for employees in flexible work arrangements.
This update adds a new configuration option within the Belgian payroll module to accurately track sick leave taken without requiring a certificate. This change ensures compliance with Belgian regulations and provides more precise reporting on employee absences related to illness.
Original PR description
Adding configuration for the Belgian sick time off without certificate work entry. task-6110080 Forward-Port-Of: odoo/enterprise#113666
This update adds a new Balance Sheet report specifically designed to meet the requirements of Mexican financial regulations (NIF B-6). This ensures accurate reporting for Mexican businesses using Odoo Enterprise, aligning with local accounting standards.
Original PR description
Added new Balance Sheet report compliant with Mexican NIF B-6 regulation. task-5943953 target: master
This update enhances the calculation of Belgian holiday pay by introducing configurable limits for employee time-off durations based on their Joint Committee. It automatically flags allocations exceeding these limits, providing a warning and allowing for review, ensuring accurate payroll processing and compliance with Belgian regulations. This improves the accuracy and reliability of holiday pay calculations.
Original PR description
This PR extends the changes in Odoo Community by introducing a rule-parameter-based
configuration for Belgian brief holidays and related payroll warnings.
- Configure maximum allowed allocation durations per Joint Committee using
`hr.rule.parameter` and `hr.rule.parameter.value`, with values defined as
dictionaries mapping JC codes to durations.
- Implement logic on `hr.leave.allocation` to:
- Retrieve the maximum allowed duration from rule parameters based on the
leave type and employee’s Joint Committee.
- Detect when an allocation exceeds this duration.
- Display a warning message on the allocation form.
- Add a Payroll dashboard warning highlighting allocations that exceed the
authorized duration, with a smart action to review them on the list view.
TaskID-5375069This update introduces a new salary structure specifically designed for casual employees within the Odoo Enterprise system. This change allows for accurate payroll calculations and reporting for this previously unsupported employee type, ensuring compliance with Hong Kong regulations. It impacts payroll processing and reporting related to casual staff.
Original PR description
Add a new salary structure for casual employees. task-5366390
Enhancements to existing features
This update streamlines expense reimbursement by integrating it directly into the payslip as a payment option. Previously, a separate reimbursement button was used, which has now been replaced with 'Add to Payslip,' simplifying the process and reducing potential errors. This change improves the accuracy and efficiency of expense tracking.
Original PR description
* 'Add to payslip' is added as a payment_mode instead of having the button for Employee reimbursement. * Posting payslip reimbursment acts as 'Add to payslip' * Prediction of Product is done for batch create of expenes to avoid the glitch effect on expense form view. task-5491410
This update adds a new feature to group sign requests by the email addresses of the signers. This allows for better organization and management of sign requests, particularly when multiple people are signing the same document. The change utilizes a new model to track unique signer email combinations.
Original PR description
Added a new "Group By" option in the sign request view to group documents by signer email combinations. Since request_item_ids are stored in a One2many relation, direct grouping is not possible. To enable this, a new model (`signer.group`) was introduced to represent unique sets of signer emails. Each sign request is linked to a corresponding signer group based on a normalized and hashed list of signer emails. task-4978668
This update seamlessly connects the Documents app with Project Tasks, automatically syncing attachments and providing easy access via a new 'Documents' button. A key addition is a warning system to alert users about potential access rights changes when linking documents to tasks, ensuring data security and preventing unintentional data exposure.
Original PR description
Previously, there was no connection between the Documents app and Project Tasks (`project.task`). Attachments added to a task via the chatter were not synced to the Documents app, and documents…
Previously, there was no connection between the Documents app and Project Tasks (`project.task`). Attachments added to a task via the chatter were not synced to the Documents app, and documents manually saved from the chatter lacked a link back to the corresponding task. This PR bridges that gap. Implementation Details: - Automated Syncing: Inherited `documents.mixin` on `project.task`. Now, whenever an attachment is added to a task via the chatter, the system automatically creates a corresponding Document and links it back to the task. - Improved Navigation: Added a 'Documents' stat button to the task form view, giving users one-click access to all files associated with that task. - Access Rights UI Warning: Added a visual warning in `documents_details_panel`. When a user links a document to a specific record, the UI now warns them that this action may broaden the document's visibility (since the linked attachment inherits the access rights of the parent record). This prevents users from unknowingly exposing sensitive data to portal users or unauthorized internal users. task-5941719
This update enhances the accuracy of Dimona declaration reporting within Odoo Enterprise. Two new warnings have been implemented to identify missing employee information and unpaid payslips, ensuring compliance and providing clearer insights for users. The changes also include improved data storage for employee details within the Dimona declaration.
This update improves the creation of financial reports by allowing external data to be directly linked to existing Odoo records. This eliminates manual data entry, reducing errors and saving users significant time when generating reports like the 'Liasse Fiscale'. The change also corrects a previous issue with string-based external values, ensuring accurate reporting.
Original PR description
External values should be linkable to an existing model. For example, in the french accounting report "Liasse Fiscale", users have to manually fill a lot of fields. For that purpose, external values are used. However, sometimes, the required info are already known in Odoo. Users currently need to rewrite everything manually. It comes with a high risks of errors and time lost encoding data. As those type of forms will become more and more frequent in Odoo, we improve it in generic for everyone. task-5951888
This update allows administrators to set payment tolerance specifically for each journal, addressing previous limitations where a single global setting impacted all accounts. It also introduces a new option to prioritize matching invoices based on either the oldest or newest date when multiple invoices share the same details, leading to more accurate reconciliation processes.
Original PR description
Before: - Payment tolerance for bank fees was managed globally through a system parameter. - It was difficult for users to adjust and applied to all journals. - If multiple invoices matched, the system selected the invoice with the closest prior or equal date. After: - Added payment tolerance to journal settings under Advanced Settings. - Tolerance is now configured per journal. - Added a matching order option to choose whether reconciliation should match the oldest or newest invoice when multiple invoices share the same partner and amount. Impact: - Allows configuring payment tolerance per journal. - Improves reconciliation behavior when multiple invoices have the same amount for the same partner. Related PR-https://github.com/odoo/upgrade/pull/9806 taskID-5985965
This update allows users to directly link to specific sheets within the enterprise spreadsheet application. When a link is shared, it will always open the intended sheet, and the sheet will automatically restore correctly when the page is refreshed. This enhances usability and sharing capabilities.
Original PR description
Add support for `sheet_id` in the router to reflect the active sheet. On initialization, read `sheet_id` from the router and activate the corresponding sheet if it exists. Fallback to the first sheet when the parameter is missing or invalid. Update the router when the active sheet changes, while avoiding unnecessary updates when the sheet remains unchanged. This allows sharing links to a specific sheet and ensures the correct sheet is restored on page refresh. Task: [6068613](https://www.odoo.com/odoo/project/2328/tasks/6068613)
This update enhances how approval notifications are handled in Odoo. It introduces a new message subtype for both approved and rejected approvals, making it easier to filter and manage these notifications. This improves the clarity and organization of approval-related messages within the system.
Original PR description
Adds a message subtype to approval added via studio, when they are approved / rejected for easy message filtering. BEFORE: The message type from an approval notification was a note. NOW: The message type from an approval notification is a validated approval or a rejected approval. WHY: Allows filtering of approval message by subtypes in ` Settings > Technical (debug) > Messages`, Community PR: https://github.com/odoo/odoo/pull/252759 task#5961149
This update improves room booking functionality by limiting users' views to only the companies they are authorized to use. Previously, users could see bookings across all companies. This change aligns with existing multi-company rules and enhances data security and user experience.
Original PR description
Currently, users can see room bookings from all companies. After this PR, users will only see bookings from their allowed companies. Technical: Add an ir.rule record to restrict room.booking records based on the user's allowed companies, consistent with the existing multi-company rules for room.room and room.office.
This update implements the core functionality for CP302 (Joint Committee 302) in Belgian payroll, a key regulatory requirement. It includes features like seniority calculations, various work entry types with premium adjustments, and specific allowances for students and work clothes. This ensures Odoo Enterprise continues to meet Belgian tax and labor law standards.
Original PR description
In this commit, we introduced the basics implementation of CP302 (Joint Committee 302) for Belgian Payroll - Add employee seniority field with automatic calculation - Add work entry types: night work, Sunday/holiday work, flexible work with seniority-based premiums - Add student wage reductions and work clothes allowance - Add CP302 salary scales, Crew/Chef de Partie contract templates task-3081508
This update enhances the pickup delivery process by updating how pickup locations are retrieved, aligning with recent changes in Odoo. It ensures accurate pickup location data is used, streamlining the order fulfillment workflow and improving delivery accuracy. This change was driven by a community enhancement to address data retrieval issues.
Original PR description
*: website_delivery_sendcloud, website_sale_fedex This PR adds several improvements to pickup delivery feature. All details are in community PR. Community PR: odoo/odoo#160187 Upgrade PR: odoo/upgrade#6315 Task-3645144
This update moves the RDO field from the individual partner record to the company record in the Odoo system. This change optimizes database performance by reducing unnecessary data storage and aligns the field's usage with its intended purpose – exporting company-level data. It's a minor improvement that enhances database efficiency.
Original PR description
[IMP] l10n_ph_reports: move RDO field from partner to company This commit moves the field `l10n_ph_rdo` from model `res.partner` to `res.company` As the field is only ever used for export with the company datas, this will avoid to overload the db with a column poorly used task-6071014
This update allows employees to use fuel cards for private vehicle use, offering a more flexible transportation benefit. The system now splits fuel card expenses between taxable private rides (for ONSS and withholding taxes) and non-taxable daily commutes (affecting only withholding taxes). This simplifies benefit administration and provides greater employee choice.
Original PR description
Allow employees to have a fuel card without requiring a company car. This enables more flexible transportation benefits where employees can use a fuel card for private vehicles. Changes: - Add fuel_card_private_ride field to split fuel card between private rides (subject to ONSS and withholding taxes) and daily commute (only impacts withholding taxes) - Create new salary rules FUEL.CARD.PRIV and FUEL.CARD.COMMUTE to handle the split taxation - Remove dependency between fuel_card and transport_mode_car in views and onchange methods - Include fuel card private ride in gross salary calculation The private ride portion is taxable for both ONSS and withholding taxes, while the commute portion only affects withholding taxes. task-5486140
This update adjusts how invoices are handled for Colombian tax reporting (DIAN) to align with current regulations. It now allows non-service products to use mandates and enables different principals for individual invoice lines. This simplifies compliance and supports a wider range of product types.
Original PR description
Allow non-service products as mandate contracts since DIAN no longer restricts this. Remove the mandate principal field from the invoice header and use the standard partner_id field on the lines instead. This way individual invoice lines can have different principals. task-5498047
This update enhances the timesheet assistant by adding icons next to each rule type in the views. This provides a clearer visual representation for users configuring rules, making the process more intuitive and efficient. Additionally, a bug fix has been implemented to prevent issues with default scope settings when selecting rule types.
Original PR description
Task-6094928
This update introduces a new, more flexible way to connect to Avalara, leveraging Odoo's IAP proxy. Users can now choose between using their existing Avalara credentials or creating a new account directly within Odoo. This simplifies the integration process and enhances reliability.
Original PR description
Allow connecting to Avalara through Odoo's IAP proxy ("Avalara Included") as an alternative to direct API credentials ("Avalara Direct"). Users can either create a new Avalara account from within Odoo or migrate an existing direct account to the IAP-backed flow.
The `AvataxClient` now dispatches requests through the IAP proxy or directly based on the chosen connection method. Ping also fetches company info and nexus locations.
task-5259842Resolved issues and error corrections
This update corrects the employment bonus calculations in Odoo's Belgian payroll module (l10n_be_hr_payroll) to reflect the latest regulations from Partena Professional, effective April 1, 2026. This ensures accurate payroll processing for Belgian employees and maintains compliance with local tax laws.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
This update removes a restriction that prevented users from accessing tax returns when the GST e-filing feature was disabled. Previously, a warning forced users to enable this feature, which wasn't always necessary. Now, users can access all tax returns regardless of the GST e-filing setting.
Original PR description
BEFORE: - Before this commit, when we disable the gst e-filing feature from the configuration and try to access the tax return view, we are getting blocked by the redirect warning, which suggests…
BEFORE: - Before this commit, when we disable the gst e-filing feature from the configuration and try to access the tax return view, we are getting blocked by the redirect warning, which suggests enabling the gst e-filing feature from the configuration. - Which is not desirable, as there might be some returns that are not related to gst e-filing, which should be accessible by the user. AFTER: - After this commit, removed the RedirectWarning when accessing the tax return view with gst e-filing feature disabled. So now the user can access tax returns without enabling gst e-filing feature. - At the time of setting the fiscal year(generating/refreshing returns automatically), the GSTR returns will not be created. - And at the time of manual GSTR return creation, we are raising UserError to instruct the user about enabling the gst e-filing feature. Related Com PR: https://github.com/odoo/odoo/pull/247216 Task-5486586 Forward-Port-Of: odoo/enterprise#113741 Forward-Port-Of: odoo/enterprise#105983
This update resolves a test failure related to currency discrepancies in DIAN move detection. The system now ensures that all test moves use the same currency, correcting a previous configuration that caused the test to fail. This ensures accurate duplicate move detection for Colombian tax reporting.
Original PR description
Following [PR](https://github.com/odoo/odoo/pull/248421), duplicate move detection now also checks the currency of both moves. Consequently, the `test_validate_duplicate_cufe` test case is failing because the moves in the test use different currencies. This commit ensures both moves use the same currency to fix the test. task-5916255
This update resolves an issue where overridden group names within the accounting module weren't being correctly translated into Odoo's internationalization files (POT). By adding specific XMLIDs to the `account_accountant` module, the system now accurately exports these group names for consistent translation across all Odoo languages. This ensures accurate translations for users in different regions.
Original PR description
The `account_accountant` module overrides the English name of several `res.groups` records owned by `account`. Without `account_accountant`-scoped XMLIDs for those records, the overridden names are never exported into this module's POT file. At runtime, `account`'s translations are loaded instead, which no longer match the overridden English source strings. We fix this by registering additional XMLIDs under `account_accountant` so the overridden names get translated independently. Forward-Port-Of: odoo/enterprise#113470 Forward-Port-Of: odoo/enterprise#112898
This update fixes a discrepancy in the Board of Accountancy (BOA) generation tests for the Philippine version of Odoo. The tests were failing due to a recent change in the Philippine Chart of Accounts (COA). The commit updated the test assertions to accurately reflect the new account codes and names, ensuring the reports generate correctly.
Original PR description
The expected account codes and names in the BOA (Board of Accountancy) generation tests were failing due to a recent update in the Philippine Chart of Accounts (COA). This commit updates the hardcoded CSV test assertions to reflect the new account codes and names so the tests pass successfully. Key account mapping updates in the tests: * 110000 Accounts Receivable -> 103010 Accounts Receivable - Trade * 110201 Input VAT 12% -> 106010 Input VAT 12% * 200000 Accounts Payable -> 201010 Accounts Payable - Trade * 200300 Output VAT 12% -> 206010 Output VAT 12% * 430400 Sales/Revenues -> 401010 Sales/Revenues * 620000 Admin Expense -> 603090 Miscellaneous Expenses Task-5916666 CE PR: https://github.com/odoo/odoo/pull/254973
This update resolves an issue where ticket submissions with emails in different cases (e.g., 'Partner@mail.com' vs. 'partner@mail.com') incorrectly created a new partner. Now, the system correctly identifies and uses the intended partner, preventing duplicate entries and ensuring accurate ticket assignment.
Original PR description
**Steps to reproduce** - Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123"). - Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com"…
**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.
Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.
Behavior after this fix: no partner is created.
**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)
Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.
opw-5914064
Forward-Port-Of: odoo/enterprise#113613
Forward-Port-Of: odoo/enterprise#109393This update fixes an issue where subscription discounts were incorrectly calculated due to how the base plan price was used. The fix ensures accurate discount calculations by dividing the base plan price by its unit, leading to more reliable pricing on subscription product pages. This improves the consistency and accuracy of subscription offerings.
Original PR description
### Steps to reproduce: - Install Subscriptions and eCommerce modules - Create 3 recurring plans (3 months, 6 months, Yearly) - Create a service subscription product with the created recurring plans - Check the product's page on website - Notice each pricing has a discount tag and with incorrect numbers ### Cause: When calculating the discount we normally use the fixed price of the base plan as the price to compare with. This sometimes introduce inconsistencies if the base plan is not just one unit from the period (>1 week/month/year) ### Fix: We divide the base_plan_price by the unit of the plan so we can get the price of just one plan unit. opw-6048278 Forward-Port-Of: odoo/enterprise#112305
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves the reliability of vendor billing transactions.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#100846 Forward-Port-Of: odoo/enterprise#78380
This update resolves an issue where bank statement lines were incorrectly defaulting to 'upload bills.' Now, the system accurately distinguishes between positive and negative bank statements, presenting the appropriate 'upload bills' or 'upload invoices' option. This ensures accurate reconciliation processes.
Original PR description
Fixed an issue where the default for positive and negative bank statement lines were upload bills, now it distinguishes between positive and negative bank statement lines and shows upload bills/invoices accordingly.
A recent change to the Hong Kong Payroll module's employee view caused an installation error. This fix removes a dependency on a now-unnecessary field, restoring the module's ability to install correctly. It also addresses a related issue with data labeling within the payroll process.
Original PR description
See https://github.com/odoo/odoo/commit/3259a7fae4ca4ee98f7e02da5109c43cd9e77f69 This commit changed the employee view and removed the departure date, which was used in the inherited view in the Hong Kong Payroll. This causes the module to no longer be installable, requiring this fix. Also fixes another issue from the same task, which made the l10n_hk_leaving_hk in `hr.employee.departure` to end up at the wrong place and without label. task-6119117
This update fixes an issue where 'All Day' appointments were incorrectly displayed with inflated durations (e.g., 1 day 7 hours). The change ensures that 'All Day' slots now accurately show the duration in days, aligning with how these appointments are intended to be represented. This improves the clarity and accuracy of booking information.
Original PR description
Enabling the "All Day" option on a slot (e.g. 14 Feb, 10:00–17:00) shifts the `end_datetime` by +1 day internally, turning the slot into a longer duration (e.g. 31 hours). Currently, the duration is computed by adding the delta between start and end while assuming the end falls at midnight, which incorrectly increases the effective duration. This caused the booking details page to display an inflated duration for all-day slots (e.g. 1 day 7 hours). Since all-day slots semantically represent calendar days rather than hour spans, the displayed duration is now computed using the date span between start and end. In short, when `allday` is enabled, duration is shown strictly in days. Normal slots continue to display duration in hours. Task-5386301
A recent update caused a technical error when checking sign requests, preventing users from accessing the sign functionality. This fix ensures that type checks are performed correctly before comparisons, resolving the error and restoring normal sign request processing. This change improves the reliability of the sign process.
Original PR description
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.…
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.
Traceback:
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```
Solution:
We first perform the existence check and then compare the types.
[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d
sentry-7376866293
Forward-Port-Of: odoo/enterprise#112659This update resolves an issue where clicking the 'Details' button during the signing process caused an error. The fix ensures the button is hidden when the system is in signing mode, preventing the error and improving the user experience. This change ensures a smoother signing workflow for internal users.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Create sign request for internal user. - Open document. - Start Signing and click on 'Details' button in contoll panel. Issue: - Clicking this button during signing causes a traceback error. Cause - The button is defined in `sign.SignRequestControlPanel` and is always rendered. In signing mode, the template is reused via XML inheritance (sign.SignSignableRequestControlPanel), but the corresponding JS component (SignableRequestControlPanel) does not implement the openFormView method. As a result, clicking the button leads to a runtime error. Solution - Control the visibility of the "Details" button using a getter. The getter returns true in SignRequestControlPanel (normal mode) and false in SignableRequestControlPanel (signing mode), ensuring the button is hidden when the required method is not available. task-6074593 Forward-Port-Of: odoo/enterprise#112299
This update eliminates a brief, distracting flash of a confirmation button on user messages in the Odoo Enterprise app. The fix ensures the button only appears on genuine agent confirmation messages, improving the user experience and reducing visual noise. This was a minor cosmetic issue.
Original PR description
#### Issue The optimistic user message briefly becomes newestMessage without a subtype, so the “Let’s do it!” button flashes for a few milliseconds on the user’s own message before it gets posted. That looks distracting. #### Fix Guarding on subtype_id in both the message action and isActive logic to make sure the button only appears on real tool-confirmation messages. task-id-6060262
This update fixes a recurring error that occurred when refreshing the Payslips list within the payroll module. The issue stemmed from a system signal causing components to be destroyed prematurely, leading to crashes. The fix prevents components from making calls when destroyed, ensuring a stable and reliable Payslips experience.
Original PR description
Bug: Payroll > Payslips refresh couple of times -> error (componenet is destroyed) Cause: A signal from the controller to re-render before mounting the first one, creates another component and calls for the destruction of the first, yet the first component can make calls and cause a crash. Fix: Prevent the component from making calls if it's destroyed. Task#6067771
This update corrects a bug in the web_studio report editor that was causing unwanted spacing to appear in generated reports. The fix prevents automatic insertions between layout sections, ensuring reports print correctly. This improves the overall quality and consistency of reports created within web_studio.
Original PR description
… sections Before this commit, the html_editor automatically put placeholders between hearder, article and footer nodes (identified with classes) This is caused by odoo/odoo@edf7f7bb0c62978640c181eccb4934855d5d872d. This caused issues because at print time those cracks are not printed because of base/ir_actions_report.py:def _prepare_html (which separates header, footer, and articles to pass them to wkhtmltopdf) After this commit, those placeholders are not present in those cracks. opw-6048955 Forward-Port-Of: odoo/enterprise#113800 Forward-Port-Of: odoo/enterprise#112458
This update resolves a test failure related to inter-company stock transfers. The test required access to specific lot IDs, which were only available when using the Odoo demo database. This fix ensures the test runs correctly in a standard, non-demo environment.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update resolves a visual issue where text in the benefit configuration section would split and misalign with checkboxes when viewed on different screen sizes. The fix ensures all text remains on a single line, improving the user experience and preventing layout problems. This change improves the clarity and usability of the benefit setup process.
Original PR description
Step to reproduce: play with the width of the window, at some point text splits and item are unaligned. Cause: with some window width, the text is splitted on 2 lines, which makes it unaligned with the checkbox. Solution: force text on same line using style="white-space: nowrap". Task: 6069017 Forward-Port-Of: odoo/enterprise#113570 Forward-Port-Of: odoo/enterprise#113386
This update resolves a visual issue where non-internal users were seeing a 'No IM status available' icon in the WhatsApp channel. The fix ensures the icon only appears when status information is actually available. Additionally, a new category has been added to the channel member list for users without status updates.
Original PR description
Since [1], non-internal users don't receive the IM status of other users. This leads to the "No IM status available" icon to be shown to non-internal users. This commit fixes the issue by only showing the icon when the value is available. This commit also adds a category in the channel member list for users missing status information. [1] https://github.com/odoo/odoo/pull/251938
This update fixes a calculation error in the employment bonus payments for Belgian businesses. The change ensures that the bonus calculations now fully comply with the specific rounding requirements outlined by Belgian social security regulations, as detailed in the official documentation. This ensures accurate and compliant bonus payments for employees.
Original PR description
The employment bonus computation was missing two roundings steps that are explicitely asked for in the following documentation: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/deductions/workers_reductions/workbonus.html Forward-Port-Of: odoo/enterprise#113776
This update fixes an issue where global invoices generated from customer invoices weren't correctly incorporating the issued address's zip code into the XML file. The change ensures that the 'LugarExpedicion' field in the XML accurately reflects the customer's shipping address, improving compliance with Mexican tax regulations. This resolves a reported problem (opw-5956837) and ensures accurate invoice data.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#112523 Forward-Port-Of: odoo/enterprise#108732
This update simplifies the way vendor bills are viewed and managed within Odoo Enterprise. It reverts a previous change that disrupted the bill form and list views, restoring the original functionality. This ensures users can easily access and work with vendor bill information.
Original PR description
This reverts commit 509ca37eef3a6dc9d148f0a11f350d41704eb02f.
This update reverts a recent change that incorrectly relied on document sequence editability for predictive name suggestions in the accounting module. The system now correctly uses the established `quick_edit_mode` logic, ensuring accurate and reliable name suggestions for users. This resolves a potential issue impacting the usability of the accounting features.
Original PR description
In https://github.com/odoo/enterprise/commit/4a61583b77835a648279bff492173469f2329a46 the condition in `_onchange_name_predictive` was updated to use `document_sequence_editable` instead of `quick_edit_mode`. However, the predictive logic is based on `quick_edit_mode`, not sequence editability. So this commit reverts that change.
This update corrects a display issue in the batch payment reports. Previously, the report would show default 'demo' values (like 'ABC Holder Name') when an account holder name wasn't specified. Now, the report correctly leaves these fields blank when no account holder information is provided, ensuring accurate reporting.
Original PR description
**Steps to reproduce:** - Install the `account_batch_payment` module. - Navigate to Invoicing > Customers > Payments. - Create a new payment with `Payment Type: Send` and select a customer without…
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113891
Forward-Port-Of: odoo/enterprise#113515This update resolves a technical issue that prevented users from generating sale commission reports when filtering by the current period. The fix corrects a formatting error in the report's data processing, ensuring accurate reporting and preventing a system error. This improves the reliability of sales performance analysis.
Original PR description
Before this commit, the following traceback could occurs when filtering the current period in achievements.
File "/home/arj/PycharmProjects/worktree/saas-19.1/enterprise/sale_commission/report/achievement_report.py", line 79, in _search
date_to_list = date_to_domain and [datetime.strptime(d[2], '%Y-%m-%d') for d in date_to_domain if len(d) == 3 and d[2]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 554, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 333, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data 'today' does not match format '%Y-%m-%d'
Forward-Port-Of: odoo/enterprise#112981This update corrects a bug where the payroll warning date incorrectly jumped to the next month when the system date was set before the closing day. The fix ensures the warning remains in the current month until the closing day has passed, preventing confusion and ensuring accurate payroll calculations. A related documentation error was also addressed.
Original PR description
steps to reproduce: - install `hr_payroll` - set closing day as "5th of next month" (via schedule warning) - set system date as <5 of the month - notice that the warning date jumped to next month description: - it should stay in the current month until closing day has passed cause: - there was no check for if the closing day has passed while in the next month scenario fix: - jump to next month only if today has passed closing date. (also fixed a wrong docstring) [task#6084911](https://www.odoo.com/odoo/project/1251/tasks/6084911) Forward-Port-Of: odoo/enterprise#112597
A recent update removed essential COA buttons from the l10n_mx_reports trial balance report for Mexican businesses. This fix restores these buttons, ensuring users can generate required COA documents as mandated by Mexican accounting regulations. This resolves a critical issue impacting report functionality.
Original PR description
After https://github.com/odoo/enterprise/pull/103445, the multiple mx modules reports were merged into one, on that transition it seems that the buttons required to print the COA documents were removed. As these are a necessary documents in MX localization, we add them again since they should not be removed. How to reproduce: - Install l10n_mx_reports module with demo data - Change to INNOVACION VALOR Y DESARROLLO SA SA company - Go to accounting app and select Trial Balance under reporting menu - Click on gear button. - COA SAT and SAT buttons don't appear. target: master
This update corrects a display issue in predefined filters within Odoo Enterprise, replacing the "Invalid Datetime" error with the correct smart date options. This improves the user experience when editing filters for tasks and messages, ensuring accurate date range selections. A related change also updates date range logic for certain filters, such as excluding today's date in some cases.
Original PR description
In many predefined custom filters (eg. `Project > All tasks > Search Bar > Closed On > Last 30 days`), when editing the filter (eg. click on the label), the editor opens on "Invalid Datetime". This…
In many predefined custom filters (eg. `Project > All tasks > Search Bar > Closed On > Last 30 days`), when editing the filter (eg. click on the label), the editor opens on "Invalid Datetime". This PR makes the predefined filters that match an existing smart date land on the smart dates instead of "Invalid Datetime". WHY: The way the date ranges are coded in the python files does not match the expected structure of the smart dates. FIX: By reformatting the domain of the predefined filter the search model is able to interpret that as smart ranges and displays the correct label and dropdown option when editing the filter. NOTE: - The reformatting of the domain sometimes also changes the logic (ie which records that are displayed). Notably in the IM livechat the "Last 7 days", "Last 30 days" ... filters now exclude today. This was asked by the framework PO (CTH) and I double checked with the discuss PO (FHE). - The task also include making a new relative range filter, but was split in 2 so that this part can be merged before the freeze (see odoo/odoo#252484) - We also change the smart date "Last 12 months" to "Last 365 days" as this is clearer from a user perspective and last 365 days was more used in arch filters. (previously when applying last 12 months smart date the range was set to the the 1st of 12 months ago to the 1st of the current month) - I also added some helpers to the test files to make them more readable and shorter. Community PR: odoo/odoo#257914 task#5959944
This update fixes an issue where rental product prices were incorrectly shown as list prices in search results. The change ensures that users see the accurate rental price, improving the shopping experience and preventing pricing discrepancies. This was a result of recent searchbar refactoring.
Original PR description
After the searchbar refactoring in [1], In the search results, rental product prices were incorrectly replaced by their list price. Ensure the correct rental price is displayed instead of the list price. task-6105283
This update corrects inaccurate titles and links within the Phone dashboard. The changes ensure users are directed to the correct information, enhancing the clarity and usability of this key reporting tool. This fix was made to improve the overall user experience.
Original PR description
This commit fixes two titles (and links) in the Phone dashboard. Task: 6120857 Forward-Port-Of: odoo/enterprise#113828
Features or functions removed from Odoo
This pull request removes a function within the Odoo Enterprise module that was identified as unused. This cleanup simplifies the codebase and reduces potential maintenance overhead. The change has a low impact on business operations.
Original PR description
This function is not used anywhere.
This update removes the 'im_status' field from partner records, which was previously used to track user online/offline presence. This change logically aligns the tracking of user status with the user model itself. It also removes the 'bot' IM status, streamlining data management.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/248168 Upgrade PR: https://github.com/odoo/upgrade/pull/9861 This commit removes the im_status field from python's partner model. The concept of IM status belongs logically to the user model since it's about users's online/offline presence. This commit also removes the "bot" IM status.
Code cleanup and technical improvements
This update simplifies the longpolling service, making it easier for the development team to maintain and update. This change improves the overall stability and reliability of the IoT integration, reducing potential downtime. The update was driven by a need for better maintainability.
Original PR description
We simplify the longpolling service to make it easier to maintain. see odoo/odoo#243554
This update streamlines a key function within the account reports module, specifically in how it generates SQL queries for analytic coverage. This simplification enhances the speed and efficiency of report generation, leading to faster processing times and a better user experience. The change is a routine optimization.
Original PR description
Simplification of the function 'compute_sql_analytic_coverage' in account_analytic_line in the report module. Forward-Port-Of: odoo/enterprise#113842
7 changes
Enhancements to existing features
This update simplifies the calculations for 'Retained Earnings' and 'Result for the Year' within the French Balance Sheet report. This change ensures greater accuracy and consistency in financial reporting for French-speaking businesses using Odoo Enterprise. It's a routine improvement to the reporting functionality.
Original PR description
Simplify the formulas of 'Retained earnings' and 'Result for the year' in the french Balance Sheet. task-6087994
Resolved issues and error corrections
This update resolves an issue where very small order weights (under 1kg) weren't being correctly converted to grams before being sent to the shipping carrier. Previously, the system treated these as zero, leading to rejected orders. Now, all non-zero lightweight orders are accurately converted, ensuring shipments meet carrier minimum weight requirements.
Original PR description
Before this commit, `sendcloud_convert_weight()` used the source UoM rounding to short-circuit zero values. On databases where the weight UoM is `kg` with a rounding of `1.0`, any weight below 1kg was treated as zero and returned unconverted. For example, 0.23kg stayed 0.23 instead of being converted to 230g, `int()` turned it into 0, and Sendcloud rejected the order as being below the carrier minimum weight. This commit ensures that non-zero lightweight orders are properly converted before Sendcloud weight checks are applied. opw-6014572
This update resolves a problem where navigating back in the documents module (specifically in kanban and list views) caused the page to reload unnecessarily. The fix ensures correct page restoration and avoids reopening the same folder after a back navigation, improving the user experience. This prevents data inconsistencies and frustration for users.
This update fixes a calculation error in the employment bonus payments for Belgian companies using the l10n_be_hr_payroll module. The change ensures that bonus calculations now precisely align with the requirements outlined by Belgian social security regulations, as detailed in the official documentation. This correction guarantees accurate and compliant bonus payments.
Original PR description
The employment bonus computation was missing two roundings steps that are explicitely asked for in the following documentation: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/deductions/workers_reductions/workbonus.html
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes an issue where refunds weren't correctly reflected when calculating outstanding balances in the POS system. Previously, only regular orders were considered, leading to inaccurate due amounts. Now, refund orders with negative totals are included, ensuring accurate due calculations and a better user experience.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113458 Forward-Port-Of: odoo/enterprise#107883
This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change corrects a previous omission, ensuring accurate equity reporting for Swiss clients. The change improves the report's precision and aligns with accounting standards.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L1084 changes
Resolved issues and error corrections
This update fixes an error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were missed for certain months, particularly at the beginning of the next fiscal year. The fix ensures accurate depreciation calculations based on the company's actual fiscal year start date.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation in the barcode interface, preventing discrepancies in inventory tracking. This improves data reliability for stock management operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience when reviewing financial data.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300
This update ensures that the date range used to fetch transactions from iap is always accurate. Previously, incorrect dates could be used, leading to inaccurate data. Now, the system uses the latest statement or statement line date, prioritizing the lock date to guarantee correct transaction retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584
3 changes
Resolved issues and error corrections
This pull request addresses a bug in the Czech VAT reporting module (l10n_cz_reports_2025) that was preventing accurate summary reports. The fix corrects a calculation error, ensuring that VAT reports generated for Czech businesses align with local regulations. This update improves the reliability of financial reporting.
Original PR description
opw- 5979262
This update addresses a regulatory requirement in Mexico regarding electronic payments (CFDI). The system now prevents users from registering payments with future dates, which are not permitted by government regulations. This ensures compliance and avoids potential issues with payment processing.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753
This update fixes a potential issue in the l10n_be_hr_payroll_sd_worx module where the report would incorrectly use the current year instead of the specified year. This prevented the report from generating correctly and caused test failures. The fix ensures the correct year is always referenced, improving report accuracy.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148