Wednesday, April 16, 2025
9 changes · 18.0
Enhancements to existing features
The website editor's video-focused editing experience now includes fields for a video title and description. This helps teams provide clearer context for embedded videos and improve the quality of published website content.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request adds and updates themes in the staging environment so they can be tested and reviewed before production use. It also includes setup for the apps bar add-on and deployment workflow changes, helping validate visual and configuration compatibility early.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- 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 calculates customer change correctly when prices include tax and cash rounding is set to round up. This prevents cashiers from giving the wrong change in affected payment scenarios.
Original PR description
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it…
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Create a product B with a Sales Price of 42$ and select the tax you created as the "Sales tax" - Open Accounting/Configuration/Management/Cash Roundings and create a new rounding - As Rounding Precision select 1.00 (the bug can happen also with other values here) - Set Rounding Strategy as "Add a rounding line" - Set Rounding Method to "Up" - Open the point of Sale app and open a store - Select one product A and two product B in the order - Click on payment and Cash - Enter a cash value of 200$ **Current behavior:** The Change has a value of 20 **Expected behavior:** The change should have a value of 21 **Cause of the issue:** In account_tax.js tax_totals_summary.base_amount_currency takes the values of values.total_excluded_currency https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L871 values.total_excluded_currency is computed as the sum of two floats With the values of our steps it creates a floating-point rounding error (the value is 88.79+78.50=167.29000000000002 and the rounding error is 0.00000000000002) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1166 tax_totals_summary.base_amount_currency is then used in another float addition to compute total_amount_currency.Because it's the second float addition the rounding error increases. (the value calculated is 167.29000000000002+11.71=179.00000000000003 and now the rounding error is 0.00000000000003) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1011 total_amount_currency is then used in pos_order.js to compute the remaining https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L157 https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L161 The remaining is used inside of the get_change method https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L887 this 0.00000000000003 rounding error has propagated to there and the value is 20.99999999999997 instead of 21 Because the rounding error comes from two consecutive float addition it's too big to be compensated by epsilon (here epsilon has a value of 1.8651746813702624e-14 which brings the value to 20.99999999999999) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/web/static/src/core/utils/numbers.js#L71 Consequently when it's rounded down (the inversion from up to down is because the change value is negative) it's rounded to 20 instead of 21 **Fix:** Because this rounding mistake only appears with the value of "remaining" I added a rounding inside getRoundedRemaining before applying any customized rounding method. opw-4615638 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that blocked users from creating a debit note from an existing credit note in Latin American invoicing flows. Businesses can now correct an incorrect credit note directly, reducing manual work and avoiding interruptions in localized accounting processes.
Original PR description
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo…
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. ### Steps to reproduce the error. 1. Install the Argentine localization 2. Create an invoice and post it 3. From the invoice using the wizard create a credit note and post it. 4. From the credit note open the wizard to create a debit note. 5. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. ### Current behavior before PR: When creating a debit note from a credit note get an error. ### Desired behavior after PR is merged: We can create a debit memo from a credit note. Adhoc tiket 69428 - 69854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now keeps unavailable pricelists, categories, and products hidden when paid orders are loaded. This prevents staff from seeing or selecting items that should be restricted, keeping the register interface aligned with configured limits.
Original PR description
Before this commit, when limited categories were enabled and a limited pricelist was selected, loading the paid orders caused unavailable categories, pricelists, and products to appear in the PoS interface. This commit filters out these non-available items even if they are loaded, ensuring that only valid data is shown. opw-4629843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes two issues: customer details from UrbanPiper orders now refresh correctly when the same phone number is reused, and Mexican EDI documents can correctly read fiscal folio data from longer uploaded XML files. This helps keep customer records accurate and prevents missing fiscal identifiers on payment documents.
Fixes an issue where uploading longer Mexican Payment 2.0 XML files could leave the Fiscal Folio blank. The system now reads the full XML content instead of a file-size placeholder, ensuring the document identifier is extracted correctly.
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 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
Orders coming from the same phone number now refresh the customer's name and address when those details change. This helps restaurants and delivery operations keep customer records accurate and avoid sending orders to outdated addresses.
Original PR description
Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559
This fixes an error that could appear when exporting the XML file for the Italian tax return. The export now uses the correct process depending on whether it is run from the tax report or from the closing entry, helping users complete the required filing without interruption.
Original PR description
Since https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc , a traceback shows up when exporting the xml of the italian tax return. It was fixing a traceback on the closing entry export which was not usable in the report itself an created another issue there. This fix makes the method chosen depend on wether we are in the report or the closing entry. no-task