Tuesday, October 14, 2025
7 changes · 17.0
Enhancements to existing features
Opening the analytic distribution popup on invoice lines with many accounts now avoids unnecessary extra data requests. This should make the popup load faster and feel smoother for users working with complex analytic allocations.
Original PR description
Currently opening the analytic distrubtion popup on an invoice line creates N network requests per account set on the line. Steps to reproduce ----- 1. Edit the analytic distribution on an invoice line and add a lot of accounts 2. Open the popup again 3. A lot of web_read requests are made Issue ----- The display_name for the account and currency is not being passed to the field values in recordProps(), resulting in another fetch when each Field element is rendered. Solution ----- Pass account.accountDisplayName. The display name for the currency is actually not initially loaded by the client, but since that field is invisible, we can safely use an empty string. opw-5106219
Resolved issues and error corrections
This fixes an issue where some draft Point of Sale orders stayed saved on the server even after users deleted them. The change helps prevent blocked POS session closures caused by undeletable draft orders.
Original PR description
In certain conditions some draft orders could be saved on the server but you wouldn't be able to delete them. This prevented you to close the PoS. Steps to reproduce: ------------------- * Use a PoS…
In certain conditions some draft orders could be saved on the server but you wouldn't be able to delete them. This prevented you to close the PoS. Steps to reproduce: ------------------- * Use a PoS that is NOT a restaurant * Make sure the PoS has a preparation display * Open the PoS * Leave the first order empty and create a new one * In the second order add any items * Go back to the first order, add items and validate it * Delete the second order from the order list * Now try to close the session > Observation: You will get an error saying you still have draft order Why the fix: ------------ When you have a preparation display linked to the PoS, when you pay an order it will synchronize all the order of the PoS. So the draft order will be saved on the server. But when deleting it, it is not deleted from the server because the function `isOpenOrderShareable` would return false. To fix this we make sure to delete the order from the server if the order has a server_id. opw-4946204
Journal item reconciliation now reliably treats write-offs as standard journal entries, even when custom defaults are configured differently. This prevents avoidable errors about missing customer/vendor details or account type restrictions, helping accounting users complete reconciliations without interruption.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155
The Barcode app now respects the Manufacturing operation type setting that blocks full order validation when no quantities have been scanned or entered. This prevents manufacturing orders from being completed accidentally and keeps barcode behavior consistent with other warehouse operations.
Original PR description
17.0+ In the Barcode app, users can fully validate a Manufacturing Order (MO) without scanning or adding quantities, even when the `Allow full order validation` option is disabled in the…
17.0+
In the Barcode app, users can fully validate a Manufacturing
Order (MO) without scanning or adding quantities, even when the
`Allow full order validation` option is disabled in the
Manufacturing operation type. This behavior is inconsistent with
other operations like pickings, where the setting is correctly
enforced.
- In Inventory / Configuration / Warehouse Management / Operations Types:
- Open `Manufacturing` operation type:
- Under `Barcode App` tab, uncheck `Allow full order validation`;
- In Manufacturing / Operations / Manufacturing Orders:
- Create a new MO wit any BoM and confirm it;
- Make it available for production (add stock on products if needed);
- In Barcode App:
- Move to `Manufacturing` and find your MO then click on it;
- Without adding quantities, click on `Produce`:
- The final product is considered as created.
**CAUSE**
When a picking type is scanned from the barcode main menu, the
picking type's config is not loaded. This results in (among
other options) the full validation option is not properly set
once inside the barcode component.
**FIX**
Use the picking type record of the scanned mrp operation to get
the config and any required default records in the barcode cache
upon the intial load.
opw-4461309Project revenue now remains visible even when the related prepaid service product has been archived. This keeps project financial status accurate for sales and project teams reviewing past or ongoing work.
Original PR description
**Steps to reproduce:** 1. Install the Sale, Project, and Timesheet modules. 2. Create a service-based product with `invoicing policy > Prepaid`, linked to `Create on Order > Project and Task`. Add a project template. 3. Create a sale order with that product. 4. Go to the created project and check the project status. **Observed behavior:** * Revenue is visible in project status while the product is active. * Once the product is archived, its revenue disappears. **Root cause:** Archived products were not considered when calculating revenue. **Solution:** Backport the fix from v18 to include archived products in revenue calculations. v18 pr : https://github.com/odoo/odoo/pull/129089 added test for product archive case. opw-5070289
This fixes an issue where the import screen could crash when a model offered more than one sample import template. Users can now see and choose from multiple templates reliably, with button spacing adjusted for a cleaner display.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.Reverse charge taxes are now reported with the correct payable tax amount instead of zero in SAF-T exports. This helps businesses submit Romanian SAF-T reports that better match tax authority requirements and reduces the risk of incorrect filings.
Original PR description
When a reverse charge tax is used, we export a `TaxInformation` with a zero amount instead of the real amount of the tax. The tax authority requires to show the tax to pay and doesn't care about the tax to receive... In order to fix this, we only sum the tax details of lines having positive repartition lines. opw-5125678