Sunday, September 7, 2025
4 changes · master
Enhancements to existing features
The user preferences and administrator user forms have been streamlined to show more relevant information and use consistent naming. Users can now update more of their own employee information from preferences, with HR teams notified of relevant changes, and signature font loading is more reliable.
Original PR description
This PR aims to improve the UI of the forms allowing users to read or modify their own data or those of other users. It has been spit in several commit. - Commit 1: remove unused fields. - Commit 2: make sure fonts are loaded before rendering font selection widget in sign. - Commit 3: fields of the preferences form and the user form for administrators are modified to only display relevant fields. The preferences form is now displayed in a modal. - Commit 4: users can edit their own employee data from the preferences form. The hr employee are notified when some changes are done. The notification is sent by the hr module and not by the hr_payroll module anymore. - Commit 5: the preferences form is sometime referred as the profile form. From now on, it is only referred as the preferences form. task-4775990
Barcode-based inventory adjustments have been revamped to make stock counts easier and more reliable for business users. The update adds clearer confirmation flows, counting requests, configuration options, and supporting access controls so warehouse teams can manage inventory checks more efficiently.
Original PR description
Task-4681370
This update simplifies Danish tax return handling by merging related reporting modules and adding Denmark-specific VAT return support. It also helps users submit Intrastat and EC Sales List documents with clearer guidance, downloadable files, deadlines, and Danish translations.
Original PR description
This commit will merge the two modules, it will be easier for user to use the tax return api. Also, following the implementation of the Tax returns feature in 18.3 which was focused on the general implementation and Belgium, we want to add the specification for other country and in this case Denmark. Instrat and ec sales list is a part of this which is generated when the VAT Return is submitted. task-4826286
Code cleanup and technical improvements
Inventory now uses a simpler, more flexible way to connect related business documents such as sales orders, purchase orders, transfers, and manufacturing orders. This improves traceability across inventory and manufacturing flows, while changing how purchase requests are grouped for suppliers based on scheduled dates.
Original PR description
The model `procurement.group` is replaced by a more flexible one: `stock.reference`. The first one was somehow not well understood and a bit limited by its many2one links to other business model…
The model `procurement.group` is replaced by a more flexible one: `stock.reference`. The first one was somehow not well understood and a bit limited by its many2one links to other business model (Sales Order, Purchase Order, ...). The reference is made of a name and many2many to all the documents integrated with Inventory. It's purpose has been shrank to the minimal "make links between object". For instance opening the manufacturing order created for a MTO sale. The merge of stock move is delegated to existing parameters (`sale_id`, created_purchase_line_ids`, ...) The `mrp.production` needed an extra effort to group them according to inheritance relationships. This commit add a new object to group productions together either in a backorder relation or in a child-parent one. This allow for instance to have a Sale Order linked to the MTO product of the sold product and the production them selves to be linked to the SO *and* the potential child MOs. The procurement group propagation, before set on the Stock Rule, allowing the stock moves to be merged in an existing picking or not has been removed and replaced (for the creation of purchase order only) by a new parameter on `res.partner` allowing the group of Request for Quotation base on the scheduled date of the potential merge candidate (never, same week, same month, always). All other merge scenarios should use batches and waves transfers. task: 4279803