Daily updates from Odoo
Monday, March 30, 2026
16 changes · 19.0
Resolved issues and error corrections
This pull request fixes inaccuracies in the PEPOL XML files generated for Peru (l10n_pe_edi). Specifically, it adjusts the number of digits used for unit prices and multiplier factors to ensure accurate calculations, resolving discrepancies in tax amounts. This improves the reliability of financial reporting.
Original PR description
PR https://github.com/odoo/odoo/pull/255358 introduce a fix that increase the unit price number of digits in the peppol xml if they are significants. It also increases the precision for MultiplierFactorNumeric, which fixes some xml in l10n_pe_edi. For example, previously: MultiplierFactorNumeric = 0.00965 BaseAmount = 10097.46 Amount = 97.46 But `0.00965 * 10097.46 = 97.440489 ≃ 97.44 != 97.46` Now we have multiplierFactorNumeric = 0.00965193227 `0.00965193227 * 10097.46 = 97.4600000190342 ≃ 97.46` Overall, we are more precise, which means the computation are correct now. opw-6009771
A recent update caused long partner names in approval reports to overflow, making the reports visually unreadable. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing formatting issues. This improves the report's usability and data clarity.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update corrects a bug where planning slots were incorrectly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, streamlining the rental planning process and preventing potential confusion. This change improves the accuracy of rental order planning.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012 Forward-Port-Of: odoo/enterprise#112278
This update resolves an issue where users without write access to the Point of Sale (PoS) in the AT (Austria) version of Fiskaly would receive an access error when attempting to authenticate after a token expiration. The fix ensures that access errors are handled correctly, preventing disruptions to sales transactions for our AT customers.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203
This update resolves an issue where kitchen tickets were being printed multiple times when orders were rejected. The fix prevents duplicate printing by ensuring the print token is properly managed during order rejection, improving the reliability of order processing. Preparation messages are now correctly sent after order acceptance.
Original PR description
Bug fix: - Prevent duplicate kitchen ticket printing on order rejection. When a user rejects an order, the reject RPC triggers a webhook that calls _fetchPlatformOrder on all devices. This led to deleteOrders being called twice (once by the reject flow, once by the webhook). Fix: claim the print token via mark_platform_prep_order_as_printed in _rejectOrder before sending the reject RPC, so no device gets isReadyToPrint=true from the webhook. - Preparation needs to be sent after PoS accepts the order. ticket-6071740
This update resolves an inconsistency in the tax report when creating vendor bills with mixed vehicle and non-vehicle expense lines. The fix allows for accurate reporting by relaxing a strict matching rule for vehicle IDs, ensuring shared tax lines are correctly processed regardless of whether a vehicle is assigned. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update strengthens security by adding validation when bank statements are automatically synchronized with a journal. Previously, any bank account linked to a journal using online synchronization was automatically trusted. Now, the system will validate the bank account to improve data integrity and reduce potential risks.
Original PR description
When a journal is configured to register bank statements using online synchronization, the bank account linked to the bank journal is automatically trusted. task-6017819
This update fixes an issue related to how dates and times are displayed, specifically the inclusion of seconds. The change restores the previous behavior of showing seconds when desired, and clarifies the datetime format system. This ensures consistent and accurate time formatting across Odoo.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342
This update fixes an issue where tax returns for Italian companies incorrectly included pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return calculation, ensuring accurate reporting and alignment with customer data. This resolves a previous inconsistency impacting financial reporting.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
This update fixes an issue where global invoices generated from customer invoices weren't correctly including the issued address's zip code in the XML export. The change ensures that the 'LugarExpedicion' field accurately reflects the shipping address, which is crucial for compliance with Mexican tax regulations. This improves the accuracy of invoice data for reporting and auditing.
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#112107 Forward-Port-Of: odoo/enterprise#108732
This update resolves a test failure related to calculating AVS deductions in the payroll module. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating a year of 2027. The fix uses a frozen test time of 2026-02-28 to accurately replicate the test conditions.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices that don't meet the required criteria. This ensures accurate reporting and compliance for Peruvian tax requirements.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance records. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or work during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#111995
Forward-Port-Of: odoo/enterprise#110991This update resolves an issue where tax lines within the bank reconciliation widget couldn't be manually unmatched when the related tax account was set to 'reconcilable'. Now, users can correctly unmatch these lines, ensuring accurate reconciliation of tax payments. This improves the usability of the bank reconciliation process.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#110186
This update resolves an issue that caused errors when deleting counterpart lines in the Bank Reconciliation widget. The fix ensures the system correctly handles data, preventing unexpected errors and improving the stability of this key financial process. This change was triggered by a bug in how a specific method handled data, impacting the Bank Reconciliation workflow.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781
This update adds specific journal entry options for F4 and F2 VAT types within the Spanish VAT reporting module. This ensures accurate accounting and reporting for these common VAT classifications, aligning with Spanish tax regulations. The change enhances the functionality of the l10n_es_reports module.