Daily updates from Odoo
Thursday, July 31, 2025
5 changes · 18.0
Enhancements to existing features
Saudi e-invoicing setup now sends ZATCA the correct company information depending on whether a business is a standalone company or a branch. It also prevents invoices from being posted with a mismatched journal company, reducing compliance errors and improving test coverage for business-to-business invoicing.
Original PR description
…nches Description of the issue/feature this PR addresses: The current implementation of generating CSR files for EDI doesn't differnetiate between parent companies and branches. ZATCA, however,…
…nches Description of the issue/feature this PR addresses: The current implementation of generating CSR files for EDI doesn't differnetiate between parent companies and branches. ZATCA, however, expects slightly different information depending on whether the company is a branch or a parent. This also includes a refactor of the tests for l10n_sa_edi. Current behavior before PR: The Organization Name, Organization Unit Name, and Organization Identifier of whichever company on the journal were being sent to ZATCA. You could also Onboard/Re-Onboard a journal in different company. The unit tests for EDI document generation were primarily using a partner based in the US, which meant that the b2b invoicing main flow was not being properly tested Desired behavior after PR is merged: Parent/Standalone Company: - Organization Name: The name of the company - Organization Unit Name: First 10 characters of the VAT - Organization Identifier: The VAT of the company Branch: - Organization Name: The name of the parent - Organization Unit Name: The name of the branch - Organization Identifier: The VAT of the parent - Prevent users from posting invoices, credit notes, or debit notes whose invoice company doesn't match the journal company - The tests are easier to read and they test the b2b flow correctly opw-4794842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213518
Portal users can now sort their signature requests by their current status, making it easier to find the most relevant or urgent documents. This improves day-to-day navigation for users managing multiple signature requests.
Original PR description
This improvement adds a new sorting option in the user portal to allow sorting sign requests by their current state. This provides users with a more intuitive way to view their requests, prioritizing the most relevant or urgent ones. To support this, a new computed field `state_order` was added to the `sign.request.item` model. It determines the item's sort order based on the state of the linked `sign.request`. The ordering logic follows the definition order of the `state` selection field in the `sign.request` model. Developers should maintain this order when modifying the selection list to preserve consistent behavior. task-4978713
Resolved issues and error corrections
Manufacturing orders created manually in a three-step warehouse setup are now included correctly in stock forecasts. This helps replenishment teams see expected finished goods sooner and avoid unnecessary extra production or purchasing.
Original PR description
### Steps to reproduce: - In the settings enable Multi-Steps Routes - Put your warehouse in manufacture in 3 steps - Create a storable product P - Create and confirm an MO for 1 unit of P - Go to…
### Steps to reproduce: - In the settings enable Multi-Steps Routes - Put your warehouse in manufacture in 3 steps - Create a storable product P - Create and confirm an MO for 1 unit of P - Go to Inventory > Operations > Procurement > Replenishment - Create a new one for P in WH/stock #### > The forecasted quantity in stock is still 0 but should be at 1, just as if the the MO had been generated using the replenishment for 1 unit ### Cause of the issue: When an MO is created using a procurement, a `location_final_id` is set to WH/Stock on the MO and propagated on the move for the finished product: https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/stock_rule.py#L165 https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/mrp_production.py#L1169-L1175 As such, even if the manufacturing is now handled in push, this move will contribute positively to the forecast in the `virtual_available` quantity of the product in WH/Stock bevause of the `location_final_id`. By contrast, if hte MO is created by hand, it does not bear a `location_final_id` so that the MO can only contribute to the stock forecast has been processed and the related internal transfer `WH/post-prod -> WH/Stock` is created. opw-4882390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how accident insurance days are calculated in Swiss payroll reports. It helps ensure payroll declarations use accurate day totals, reducing the risk of reporting errors for employers.
Original PR description
Forward-Port-Of: odoo/enterprise#91358
This fix prevents depreciation edits on negative-value assets from swapping debit and credit amounts in journal entries. It helps keep accounting records accurate when adjusting depreciation schedules for negative assets.
Original PR description
Before this commit, creating an asset with a negative value then editing the depreciation caused a inversion between credit and debit in the Journal entries The account_depreciation_id and account_depreciation_expense_id were not inverse for negative depreciation, in the function `_inverse_depreciation_value()` We add that missing account inversion for negative assets Steps to reproduce: - Create an asset with negative Original Value - You can choose any Depreciation Account and Expense Account - Click on Compute Depreciation - Check the Posted Entries and note the values position (credit/debit) - Go back to the Asset > Depreciation Board - Add 10 to the first line Depreciation - Remove 10 to the second line Depreciation - Save the Asset - Check the Posted Entries again - The changes ones should have credit/debit inversion before the fix opw-4759988 Forward-Port-Of: odoo/enterprise#91300 Forward-Port-Of: odoo/enterprise#88907