Wednesday, May 21, 2025
8 changes · 18.0
Enhancements to existing features
This update stops multiple pending recurring payment transactions from being created for the same document when using Razorpay payment tokens. It helps ensure RBI pre-debit notification timing is respected and reduces the risk of duplicate customer charges or payment confusion.
Original PR description
As per RBI Notification RBI/2019-20/47, ensure a pre-debit notification is sent at least 24 hours before the actual debit for recurring payments. Prevent creation of duplicate pending transactions with token for the same document because every transactions confirm after 24 hours. task - 4678509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Point of Sale now shows the correct tax-free price when a customer is exempt from tax on products whose listed price already included tax. This prevents customers from being overcharged and keeps receipts and order totals aligned with the customer’s tax status.
Original PR description
**Issue:** When selling a product with a tax-inclusive price to a customer who is tax-exempt (e.g., under a "Rest of the World" fiscal position with a 0% tax mapping), the Point of Sale displayed the…
**Issue:** When selling a product with a tax-inclusive price to a customer who is tax-exempt (e.g., under a "Rest of the World" fiscal position with a 0% tax mapping), the Point of Sale displayed the tax-inclusive price instead of the correct tax-exclusive price. **Steps to Reproduce:** 1. Install the Sales, Point of Sale, and Accounting applications. 2. Create a product with a price configured to include taxes (e.g., a 20% VAT included in the sale price). 3. Create a customer and assign them a fiscal position that maps the product's default inclusive tax to a 0% tax (e.g., a "Rest of the World" fiscal position). 4. Create a fiscal position tax rule for the "Rest of the World" position, mapping the inclusive tax on the created product to a 0% tax. 5. Open the Point of Sale interface. 6. Select the customer created in step 3. 7. Add the product created in step 2 to the order. 8. Observe the total price displayed for the product. Expected Behavior: The Point of Sale should display the price of the product excluding the previously included tax, reflecting the 0% tax rate for the selected customer. Actual Behavior: The Point of Sale incorrectly displayed the original tax-inclusive price, even though the applied tax amount was shown as $0. **Root Cause:** The `get_tax_details` method calculates the base price (tax-exclusive) after the product's taxes have already been potentially remapped to 0% based on the customer's fiscal position. Consequently, when a product with an inclusive price is sold to a tax-exempt customer, the `total_tax_amount` becomes zero. The logic in `get_tax_details`,at line 368, that intends to adjust the base price when taxes are included doesn't trigger correctly because `total_tax_amount` is already zero, leaving the `raw_base` (which is derived from the tax-inclusive `price_unit`) unchanged. **Fix:** To resolve this, when preparing the base lines for tax computation, the code now detects if a product originally had a tax-inclusive price and if the effective tax rate has become 0%. In such cases, the `price_unit` of the order line is explicitly adjusted to its tax-exclusive value by reversing the original tax inclusion. This ensures that subsequent tax calculations and the final displayed price correctly reflect the tax-exempt status of the customer. Opw-4592602 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures company branches in Italian e-invoicing share the same official connection settings as their parent company. It prevents duplicate-user errors when branches have the same VAT or tax code, making activation smoother in multi-branch setups.
Original PR description
- Prevent duplicate user conflict during official mode activation in multi-branch setups - Handle scenario where branches of the same company use the same Partita IVA (VAT number) or codice fiscale - Avoid "An user already exist in the database" error by validating user association logic - The branch should affect the same record in the db the will have the same proxy user Task [link](https://www.odoo.com/odoo/project/967/tasks/4737181) task-4737181
This fix prevents invoice submissions to Malaysia's MyInvois service from failing when a customer reference is present. Businesses using Malaysian e-invoicing can submit invoices more reliably without errors caused by this additional customer information.
Original PR description
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users from opening the Paid Seats appointment template if the default booking fee product had been deleted. The system now restores the needed product when loading the template, preventing the crash and keeping appointment setup usable.
Original PR description
Currently a `ValueError` is arising when user try to load the appointment template `paid seat`. To get this error: - Create database without demo data and install appointment_account_payment - Delete the Booking Fee Product from products. - Open Appointment and click the `Paid Seats` to select template options. - The error appears in the console log. Error: ``` ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted ``` To fix this issue, used `convert.convert_file` to restore deleted product while loading appointment template. Sentry ID: 6013528364
This update ensures longer Mexican Payment 2.0 XML files are read correctly when uploaded to EDI documents. As a result, the Fiscal Folio is filled in automatically instead of being left blank, reducing manual correction and document processing issues.
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487
This fix allows existing customers to use the newer pain.001.001.09 ISO20022 payment format beyond SEPA credit transfers. It helps businesses generate compatible payment files for banks that require this newer format, enabled through a system setting.
Original PR description
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016
This fix prevents an error when users submit Chilean electronic invoices to SII using certificates that do not include a subject serial number. It helps keep invoice submission working reliably for companies using Chilean localization, even with certificates missing that optional detail.
Original PR description
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/account_move.py#L290 Here, If ``subject_serial_number`` of certificate is False. It will lead to the above traceback. ``subject_serial_number`` can be False because Some certificates do not provide this number. ref-https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/certificate.py#L19-L20 sentry-6591311577