Tuesday, December 9, 2025
6 changes · 17.0
Resolved issues and error corrections
This update fixes a bug in the contact import process. Previously, if an import batch contained invalid data (like incorrect values), it wouldn't display any error messages. Now, the system will correctly identify and report these errors during batch imports, ensuring data integrity and preventing incorrect data from being added to the system.
Original PR description
Steps to reproduce ================== - Go to contact, - Import the following file ```csv id,name,active __import__.res_partner_SV_test_01,Name 1,TRUE __import__.res_partner_SV_test_02,Name 2,TRUE __import__.res_partner_SV_test_03,Name 3,TRUE __import__.res_partner_SV_test_04,Name 4,TRUE __import__.res_partner_SV_test_05,Name 5,incorrect value __import__.res_partner_SV_test_06,Name 6,TRUE __import__.res_partner_SV_test_07,Name 7,TRUE __import__.res_partner_SV_test_08,Name 8,TRUE ``` - Set the batch size to 4 - Click on the import button => Only 4 records have been imported and no error is displayed Cause of the issue ================== Errors were only checked in test mode opw-5242285
This update resolves an issue where the OCR process incorrectly assigned foreign currencies to expense items, particularly when linked to products with standard costs. The fix now allows users to correct the total amount after the OCR, ensuring accurate currency conversions and proper reimbursement processing. This prevents errors and improves the reliability of expense reporting.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236
This update addresses a change in Facebook's data reporting, specifically regarding audience trends. Due to a rapid fix needed, the trend calculation wasn't fully verified, but the system now utilizes total page follows to account for potential unfollows, ensuring more accurate reporting. This improves the reliability of Facebook insights for our users.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend,…
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend, because we needed a fix rapidly, and we wasn't sure about unfollow. And indeed, `page_daily_follows` only count for positive value, unlike the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent of `page_fan_removes`... Example of data for a month: ``` page_follows 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 page_follows 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ``` So we now use `page_follows`, so the total value at a given time, and we look for the newest and oldest value (note that if we could do the same for `page_post_engagements`, then we could just make 2 APIs calls for the year stat). Task-5353390 Forward-Port-Of: odoo/enterprise#100275
This update ensures that Luxembourg (`l10n_lu`) companies' general ledger reports correctly include vendor invoices in the required FAIA XML format. A recent change in FAIA reporting standards necessitates the addition of a 'PurchaseInvoices' tag, and this PR implements the necessary template to meet these requirements.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572
This update adds a specific group to the teleworking field within the HR contract and employee records. This ensures accurate reporting of employee benefits for Swiss tax compliance (ELM transmission), addressing a previous reporting issue. The change improves the accuracy of payroll calculations for Swiss businesses using the Enterprise module.
This update fixes an error in the Peru tax return (RVIE Sales 14.4) report that incorrectly included credit note amounts in the tax columns. The change aligns with SUNAT regulations, ensuring accurate reporting of credit notes based on their modification period, improving compliance and reducing potential tax discrepancies.
Original PR description
Backport of 5151bbf70a50d3762c4979365fb5412d0a888840 How to reproduce the issue: With l10n_pe localization: - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466