Friday, March 27, 2026
9 changes · saas-18.2
Enhancements to existing features
This update enhances the budget reporting feature to now include tracking of asset accounts. When budget reporting is set to 'Expenses' or 'Both', the system will automatically incorporate data from asset accounts like current, non-current, and fixed assets, providing a more complete financial picture.
Original PR description
Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048 Forward-Port-Of: odoo/enterprise#109496
Resolved issues and error corrections
This update resolves an issue where the POS scale integration was not accurately displaying product weights, particularly with newer IoT box versions. The fix adjusts how the scale's measurement data is handled, ensuring correct weight readings are shown in the system. This improves the accuracy of product tracking for businesses using the POS scale feature.
Original PR description
Steps to reproduce - Use a localisation other than a european one (l10n_eu_iot_scale_cert must not be installed) - Setup the scale for the POS - Open the POS - Add a product to be weighted by scale to the order - Add product to the physical scale - The displayed weight is always 0 Cause: New versions of the IoT box uses the field result to return the scale measure instead of value. Fix for version 18.0 and its intermediary versions. [opw-5990467](https://www.odoo.com/odoo/project/49/tasks/5990467) Forward-Port-Of: odoo/enterprise#111963
This update fixes an issue where global invoices generated from customer invoices weren't correctly using the issued address's zip code in the required XML format for Mexican tax reporting. The change ensures accurate data transmission for compliance with Mexican regulations, preventing potential errors and delays in processing.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#108732
This update fixes an issue where paid leave calculations were inaccurate for employees using the UAE Monthly pay structure. The change ensures that worked days are correctly accounted for in individual payslips, preventing incorrect salary adjustments. This improves the accuracy of payroll processing for UAE-based employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#111280
This update corrects a previous issue where partner totals were incorrectly hidden, regardless of their value. Now, all partners with totals exceeding €3,005.06 are included, and insurance operations accurately track sales and purchase journal amounts for more complete reporting. This ensures greater accuracy in BOE file generation.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#111983 Forward-Port-Of: odoo/enterprise#100413
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode readings. The fix ensures the scanner uses the correct company information, resolving the problem of misidentified products and enabling accurate barcode scanning across different company setups.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#111662
This update resolves an issue preventing SBR tax reports from submitting correctly. The commit restores the correct date format and limits the consultant name description to the abbreviation, ensuring compliance with validation requirements and allowing successful tax return submissions.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update resolves an issue where confirming quantities of archived products through the barcode app would trigger an error. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality. This improves the usability of the barcode app for all product types.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise module. It adds a new wage type allowing for 200% overtime pay, ensuring accurate Swiss tax and social security reporting (ELM). This change aligns with Swiss labor regulations and improves payroll accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796