Daily updates from Odoo
Thursday, September 25, 2025
10 changes · master
Resolved issues and error corrections
Czech VAT control statements now place invoices without a partner VAT number in section A5 regardless of amount. Special VAT regime entries for travel services and margin schemes are also consistently reported in A5, helping businesses avoid incorrect VAT classifications.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833
The audit balances view now shows cumulative balances, including amounts from previous periods and unaffected earnings. This gives finance teams a more accurate view of balances for audit and reporting work.
Original PR description
The audit balances view should accumulate the balances from previous periods. Before it only computed the balance for the current period. It also take into account the unaffected earnings. Forward-Port-Of: odoo/enterprise#94634
This fixes a situation where an IoT Box action could run twice if the first connection method timed out and a fallback connection retried the same request. Each action now carries a unique identifier so repeated fallback requests can be recognized and ignored, reducing risks like duplicate prints or registrations.
Original PR description
Community PR: odoo/odoo#225678 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. This PR handles the client side code, which just involves adding the new `action_unique_id` key to all our actions that are using fallbacks. task-5067737 Forward-Port-Of: odoo/enterprise#94031 Forward-Port-Of: odoo/enterprise#93985
This fixes an issue where Sign templates created from records such as sales orders did not use the original document to choose which fields could be added. Users can now drag and drop the expected fields for that document, while templates are protected from combining incompatible fields from different document types.
Original PR description
Before this commit, when a new template was created from a mail thread record, the reference doc was not used to filter out the fields to display. it would prevent to drag and drop sale.order fields even if the template was created from the sale application. task-5085468 Forward-Port-Of: odoo/enterprise#94591
The Indian GSTR-1 document summary now keeps existing generated data instead of recreating it each time the summary card is opened. This prevents accidental data loss, avoids unnecessary processing, and removes an incorrect “Missing” status when summary data is already available.
Original PR description
Issue: - Document summary was regenerated every time the user clicked on the document summary card. - This caused data loss for already existing summaries and unnecessary restart of the process. - 'Missing' tag appeared in document summary even when data was present. - Additionally, record_name was passed in _check_suite_in_gstr1_report, but as a computed field it never worked as intended. Fix: - Adjusted logic so the document summary is generated only when empty. - Subsequent clicks now reuse the existing summary instead of regenerating it. - No missing tag appears if document summary exists. - Replaced record_name with record_model to ensure correct record count and computed record name. Forward-Port-Of: odoo/enterprise#94447
This fixes an issue where users working across multiple companies could be blocked from creating Helpdesk timesheets when the linked project had no company set. The change preserves the correct company during timesheet creation, helping avoid validation errors in daily support and migration workflows.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
This fix restores one-time payment options in Swiss payroll and hides salary attachment items that should not be available. It helps payroll users access the correct payment actions while reducing confusion from unsupported or unwanted menu entries.
Original PR description
- Reintroduce one time payments - Blacklist salary attachments Forward-Port-Of: odoo/enterprise#95438
The mobile Point of Sale payment screen now correctly keeps the Validate button disabled when no payment method is selected. This helps prevent incomplete payments from being confirmed by mistake and improves consistency between mobile and desktop checkout flows.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#95357 Forward-Port-Of: odoo/enterprise#94100
Point of Sale receipts are now sent to the receipt printer selected in the POS setup, even when other printers are also connected. This prevents customer receipts from accidentally printing on kitchen or preparation printers, reducing confusion during checkout.
Original PR description
Steps to reproduce: 1. Configure a POS with a receipt printer and a preparation printer. 2. Ensure that the preparation printer has a higher ID than the receipt printer (you can force this by deleting it and letting the IoT redetect it.) 3. Try to print a receipt. EXPECTED: The receipt is printed on the configured receipt printer. ACTUAL: The receipt is printed on the prepation printer. This was caused by the hardware proxy code assuming that there will only be 1 printer `iot.device` model loaded, and that it will correspond to the receipt printer. The fix is to ensure the hardware proxy only chooses the printer that is configured as the receipt printer. Forward-Port-Of: odoo/enterprise#93225
Purchase bills that are reset to Draft now return to their initial GSTR-2B reconciliation state. This prevents old GST return links or exception flags from carrying over, helping teams reconcile corrected bills accurately.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95471 Forward-Port-Of: odoo/enterprise#95026