Friday, October 17, 2025
7 changes · saas-18.2
Enhancements to existing features
Refreshing UrbanPiper webhooks from the settings now also disconnects products from the point of sale before publishing a fresh menu. This helps ensure UrbanPiper receives an up-to-date menu and reduces mismatches between Odoo and the delivery platform.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Uruguay electronic invoicing now recognizes VAT rates outside the standard exempt, minimum, and basic rates as reduced VAT. This ensures invoice XML totals, line classifications, and tax reporting grids correctly reflect these reduced-rate taxes for compliance.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#91392The POS booking screen no longer automatically opens the on-screen keyboard on tablets and phones. This makes the booking flow smoother for restaurant and appointment users on touch devices.
Original PR description
Task: [#5016943](https://www.odoo.com/odoo/project/1737/tasks/5016943) --- On tablets and phones, the search bar was autofocus when opening the booking screen in the POS frontend. This was causing the keyboard to open automatically, which was not a good user experience. Now the search bar is not autofocus on touch devices for the booking screen by creating a new controller to manage this. Forward-Port-Of: odoo/enterprise#96873
Resolved issues and error corrections
Swedish Bankgiro and Plusgiro accounts are now handled correctly when generating SEPA payment files and Peppol invoices. This prevents missing bank details in payment exports and helps ensure Swedish invoices meet required electronic invoicing rules.
Original PR description
… number Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents…
… number Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts. This commit introduces overrides for SE-specific account types: _get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML. _skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file. This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries. Backport of https://github.com/odoo/enterprise/commit/0534491bcd7eed7d246bea85d6ac217a80af815b Forward-Port-Of: odoo/enterprise#97330
Uruguayan electronic invoices now correctly include invoice lines that have a zero value by marking them as free delivery. This helps ensure invoices sent to the tax authority are complete and compliant when businesses provide free items or fully discounted lines.
Original PR description
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by…
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount ## Steps to reproduce 1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 2. Add a line with quantity 1. price 0 3. Add a second line with quantity 1, price 500 and discount 100% ## Before this PR 1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery. 4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all ## After this PR Both lines are informed to DGI using the invoice indicator 5 (Free Delivery) You can check this on to generate CFE XML in demo mode (not need to connect to UCFE) If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file. References [Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691) LATAM 1350 / ADHOC task 53445 Forward-Port-Of: odoo/enterprise#89808
The update prevents failures when creating vendor bills from IRN data in Indian GST reports for tax units with multiple companies. It now looks for a valid purchase journal across the full tax unit instead of only the main company, helping bill creation complete reliably.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. Forward-Port-Of: odoo/enterprise#97255
This fix prevents German POS session closing from failing when an order is missing its assigned user during required DSFinV-K export generation. The system now uses the order creator as a fallback, keeping export data valid and reducing operational disruption.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. Although the exact reproduction steps are not consistently found, this issue is recurrent. This change makes the code more robust by defaulting to the order's create_uid when the user_id is empty or missing, ensuring the transaction export data remains valid. opw-5123890 Forward-Port-Of: odoo/enterprise#96002