Tuesday, March 17, 2026
34 changes · saas-19.2
Enhancements to existing features
This update streamlines the timesheet assistant for sales and project teams by simplifying labels and improving the user interface. Key changes include restricting access to certain features based on sales permissions and optimizing how project information is managed, leading to a more efficient timesheet process.
Original PR description
[IMP] {helpdesk,sale,project}_timesheet_{,enterprise,forecast}: timesheet assistant generic improvements
In this Commit,
- Assistant Form > "Billable" boolean hidden for users without Sales access rights
- Assistant Form > Labels updated:
- "Project Name" → "Project"
- "Task Name" → "Task"
- "Time Spent" → "Time"
- "Save Changes" → "Save"
- Assistant Form UI Improved by applying same changes done in master,
REF: https://github.com/odoo/enterprise/pull/104347
- Assistant Form > create and edit option removed for projects
- Suggestions logic reviewed for better results
- Correct time calculation for chronological grouping
- Unmatched project display issues resolved in both suggestions and local config
- Local Config List view aligned with Odoo UI views
- Local Config Storage limited to project/task/ticket IDs instead of `display_name`
and `id`
task-5902077
Forward-Port-Of: odoo/enterprise#108360Resolved issues and error corrections
This update corrects a visual issue where the unit price wasn't shown on product pages when using the 'boxed' layout in the ecommerce section. The fix adds the necessary code to display the unit price correctly, ensuring a consistent and informative shopping experience for customers regardless of the layout they choose. This improves the clarity of product pricing on the website.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253071
Forward-Port-Of: odoo/odoo#250319This update resolves an issue where the offer simulation feature in employee paychecks was incorrectly using existing employee data. The fix ensures a temporary version is used for simulations, generating accurate payroll projections. This improves the reliability of pay calculations.
Original PR description
### Steps To Reproduce:
- Go to any employee > generate payslip
- Come back to employee's form view and click on simulate button
### Issue:
- We were using actual employee's version in simulation.
### Fix:
- Instead of using existing employee version, use the temporary created
employee's version
### Additional Issues Encountered:
- When creating simulate payslip, model('hr.payslip.worked_days') need version_id
- When click on simulate button, the values, salary, pay structure, work schedule should be filled with value corresponding to selected employee.
task: 5936444This update fixes a key issue preventing UK users from correctly setting up their Stripe accounts for expense reimbursement. The team added specific instructions for UK account creation and implemented a secondary check (Stripe currency set to Euros) to ensure users in the UK flow are properly configured. This improves the user experience for UK employees.
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros. Forward-Port-Of: odoo/enterprise#110103 Forward-Port-Of: odoo/enterprise#109667
This update fixes an issue where delivery batches weren't correctly grouped with the selected carrier after order confirmation. Now, when changing the carrier during the delivery process, the new batch will be associated with the original carrier, ensuring accurate batch management for shipments. This improves order fulfillment efficiency.
Original PR description
**Problem:** If you have group by carrier option in automatic batches, when you create an SO with a stocked product, confirm the order, and in the delivery step you set/change a carrier, it creates a…
**Problem:** If you have group by carrier option in automatic batches, when you create an SO with a stocked product, confirm the order, and in the delivery step you set/change a carrier, it creates a new batch transfer, and it doesn't group it with the appropriate batch with that carrier. **Steps to reproduce:** 1) In the settings enable: Batch, Wave & Cluster transfers 2) Inventory > Configuration > Warehouse Management > Operation types 3) Enable Auto-batches, Batch grouping by carrier on Delivery orders 4) Make sure there is no batches made before contains the carrier you're going to use (to cleanly test this issue) 5) Make a sales order, add storable product, press on 'Add shipping' button and add 'standard delivery' 6) Go to the delivery of the pick from the smart button > validate it 7) Go to the next transfer to see the batch number 8) Make a new sales order, add storable product > confirm it > go to the delivery step > additional info 9) Add 'standard delivery' in the carrier field > validate the delivery > go to the next transfer button 10) check the batch it got added to, you will find it is a new one and didn't get grouped to the last batch created with the same carrier. **Expected behaviour:** It should get grouped in the batch containing that same carrier. **Cause:** When the SO is confirmed without a carrier, and then you edit the carrier in the delivery step (pick) then press on validate, it gets the carrier from the vals in the SO (blank), then along the way while validating the pick, `find_auto_batch` gets called with the empty carrier, so it creates a new batch, *AND then* it propagates the carrier from the SO to the pick using `get_new_picking_values` method, but by then it's too late as the batch is already created with the blank carrier. **Solution:** The problem happened because of this commit: https://github.com/odoo/odoo/commit/7c32adcd82119c35485addd1b198a7fcc0053c9f We need to add the propagation of the carrier_id to the vals if it was already changed or set before the validation of the pick. opw-5882310 Forward-Port-Of: odoo/odoo#248490
This update corrects an issue where QR codes weren't consistently generated on PDF invoices sent to customers in Peru. The fix resolves a technical problem related to how attachments were linked during the PDF generation process, ensuring accurate QR code display. This improves the customer experience by guaranteeing correct invoice formatting.
Original PR description
In [^1] we refactored Peru to use the send and print api instead of account_edi. One issue that was missed is in the case of sending the pdf to the customer in the same call as sending to SUNAT. Since the field that is storing the attachment (`l10n_pe_edi_attachment_id`) is linked to `l10n_pe_edi_attachment_file` via the compute, creating the attachment with a link to the res_field doesn't update within the transaction so `l10n_pe_edi_attachment_id` is still false at the time of PDF generation. There are two fixes, we can either invalidate the recordset at time of computation to make sure that it is truthy in the transaction, or use the `l10n_pe_edi_attachment_file` directly as it means we don't need to access the data field on `ir.attachment`. The use of the `l10n_pe_edi_attachment_file` field seemed cleaner. task-none [^1]: #97593
This update resolves an issue that was causing errors during upgrades related to fetching archived warehouse picking types. The fix prevents the system from attempting to use inactive warehouse locations, which was leading to database errors. This ensures smoother upgrades and reliable stock operation creation.
Original PR description
revert the commit as when we fetch archived warehouse's pos type it will raise error for other source or destination loction for newly created stock operation type like even functinally also there is…
revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like
even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL: Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```
due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files
so we need to avoid to fetch archived warehouse's picking type.
ref:
odoo/upgrade#6631
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191652
Forward-Port-Of: odoo/odoo#185244This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes any rental amounts from this calculation, ensuring accurate reporting for tax purposes. This improves the reliability of financial data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919
This update resolves an issue where serial numbers weren't being generated correctly using date-range sequences. The fix ensures that each new receipt creates unique serial numbers based on the specified date range, improving inventory tracking accuracy. This change was implemented by adjusting how the system updates the sequence, addressing a previous limitation in the generation process.
Original PR description
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable:…
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable: `Use subsequences per date_range`, add a range date containing today - Create a product tracked by Serial numbers - Create and confirm a receipt for 3 units of your product - Detailed of the move > Generate Serials/Lots > New > Generate #### > 3 serial numbers were created but the date specific sequence has only been updated once. This can be checked by creating a new receipt and processing the same exact flow. ### Cause of the issue: Generating the serial numbers will call the `action_generate_lot_line_vals`. However, this method is not tailored to deal with the `use_date_range` and increments the main sequence rather than the actual subsequence: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/stock_move.py#L1103-L1106 ### Fix: We rely on the apparently unused `_get_current_sequence` method to recover the appropriate sequence by date range to update: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/odoo/addons/base/models/ir_sequence.py#L114-L128 This method has been introduced in an accounting naming IMP: 915aa9e4db3169a4767617b5310721f0d9c16812 and is unused since the accounting is no more relying on name sequences: dfd01b8c5c7e1177f37bf199790a0732a61eed78 In addition, we fine tune the current version of the code updating the serial sequence on lot generation since it is currently updating the sequence only if the first generated lot has been set via the`New` button and hence has incremented the sequence via a `next_by_id` call: https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/lots_dialog.xml#L33 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/generate_serial.js#L48-L56 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L261-L275 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L335-L337 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L53-L55 While if the value of first lot is given manually to the wizzard is given manually to the wizzard, the sequence does not get incremented by the nextval. opw-5931056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253618
This update resolves an issue where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. The fix ensures that stock moves accurately reflect the BoM's requirements, preventing errors and improving the reliability of the manufacturing process. This improves data accuracy for inventory management.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110540 Forward-Port-Of: odoo/enterprise#90408
This update fixes an issue where refund calculations for orders with multiple line items in the Mexican VAT (l10n_mx_edi_pos) module were inaccurate due to incorrect summing of line amounts. The change ensures accurate comparisons against the original order total, preventing refund errors and improving the reliability of the refund process.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#109124 Forward-Port-Of: odoo/enterprise#105301
This update resolves an issue where 'View more' and 'View less' labels within the eCommerce product filters were not being translated correctly when browsing in languages other than English. The fix ensures that all filter labels are properly localized, providing a consistent user experience across all supported languages. This improves the usability of the eCommerce platform for international customers.
Original PR description
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to…
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to reproduce: 1. Install eCommerce 2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce) 3. Add a language (e.g. French) and translate the eCommerce's website 4. Open the website and set the language to French 5. In the left column, open the filter for the attribute previously created 6. Click on "Voir plus" 7. "View less" is not translated, if you click on it, "View more" is not translated anymore Issue: The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore Solution: Use `_t` to translate the "View more" and "View less" terms opw-5985712 Forward-Port-Of: odoo/odoo#253684 Forward-Port-Of: odoo/odoo#252828
This update resolves recent performance issues experienced when using the Point of Sale (POS) and self-ordering systems on iOS devices. The team optimized the user interface by adding styling to improve responsiveness and reduce delays when interacting with elements, resulting in a smoother user experience.
Original PR description
There was some issues when touching elements in the POS and self. We added the parameter role="button" to the elements that were not already and a pe-none to the images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253686 Forward-Port-Of: odoo/odoo#253583
This update ensures that quality checks are only performed on tracked products with assigned lot or serial numbers. Previously, users could initiate quality checks without this information, now a user error is displayed, preventing incorrect data entry. Additionally, the quality check display now intelligently filters based on whether move lines have been picked, improving the user experience.
Original PR description
This commit fixes the behavior when the user tries to do quality checks for tracked products without setting their lot/sn on the picking. Before this commit: Nothing happens if the user tries to do quality checks if lots are not set on the tracked products. After this commit: A User Error is raised telling the user to assign lots/sn to the tracked products. Additional improvement: Before this commit, when having quality checks and user click on `Quality Checks` button, all quality checks appear regardless of whether all moves are picked or only some of them are picked. After this commit, clicking on `Quality Checks` button will only show quality checks related to picked move lines if at least one move line is picked, otherwise it will show all quality checks. Task-5730239 Forward-Port-Of: odoo/enterprise#104945
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that skills are correctly copied to all appraisals, regardless of how they're initially created, improving appraisal accuracy and data consistency. This impacts users relying on the automated appraisal system.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110601 Forward-Port-Of: odoo/enterprise#107760
This update fixes a bug where journal entries could be posted even when referencing inactive analytic accounts. The fix adds a validation step during posting to ensure all referenced accounts are active, preventing incorrect financial postings. This improves data accuracy and reliability within the accounting system.
Original PR description
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic…
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic account in the analytic distribution. - Post the entry and export it(Make sure `journal items/account` and `journal items/analytic distribution` are also included). - `Archive` the analytic account. - Import the exported entry `OR` Duplicate the previous created entry. - Try to post the imported entry. **Issue:** - The entry is posted even if the analytic account used in the analytic distribution is inactive. **Root cause:** - The `analytic_distribution` field is stored as JSON. - At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error. **Solution:** - Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active. [1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202 opw-5350980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253752 Forward-Port-Of: odoo/odoo#239988
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's selection. Now, the MPS correctly uses the chosen BoM to calculate and update component demand, ensuring accurate forecasting and production planning.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693This update fixes a performance issue in our testing process. Previously, asset bundles were repeatedly regenerated during test runs, slowing things down. Now, bundles are pregenerated once and reused, significantly improving test execution speed and stability.
Original PR description
The commit [^1] introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. [^1]: odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 Forward-Port-Of: odoo/odoo#248014
This update fixes a performance issue in the Web Studio module by ensuring binary asset bundles are pregenerated during testing. Previously, tests repeatedly regenerated these bundles, slowing down the testing process. Now, bundles are created once and reused, significantly improving test run times.
Original PR description
The commit odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. Forward-Port-Of: odoo/enterprise#110555
This update corrects a previous error in the Indian payroll configuration, ensuring the default basic salary percentage is set to 50% instead of 60%. Now, benefit adjustments only affect gross salary and employer costs, without altering employee wages or the underlying payroll structure. This provides a more accurate and stable payroll calculation for Indian businesses.
Original PR description
- Fix the default Indian basic salary percentage to 50% instead of 60%. - Ensure benefit amounts are treated as additional employer payments and do not rebalance the employee’s wage or basic salary in the salary configurator. After this change, benefit updates only impact gross salary and employer cost, while the wage remain unchanged. task-[5501683](https://www.odoo.com/odoo/project/1251/tasks/5501683)
This update corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the incorrect filename prevented proper processing. Now, the ZUGFeRD file passes validation across multiple platforms, ensuring accurate e-invoice handling.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253704 Forward-Port-Of: odoo/odoo#252681
This update resolves an issue where clicking on 'reply' links within Odoo's email inboxes didn't function correctly. Now, clicking on a reply link will seamlessly jump to the original email thread, improving the user experience and ensuring efficient email management. This change enhances the usability of Odoo's communication features.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253990 Forward-Port-Of: odoo/odoo#253334
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. By checking the last posted bill, the system ensures consistent tax grouping for improved accuracy and efficiency in invoice processing. This simplifies reconciliation and reduces manual effort.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#253322
Forward-Port-Of: odoo/odoo#251419This update fixes an issue where refund payments in Point of Sale were incorrectly created as inbound payments. When a refund is processed using the Card payment method with Identify Customer enabled, the system now correctly identifies these payments as outbound, ensuring accurate financial reporting. This change improves the reliability of our accounting processes.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254079 Forward-Port-Of: odoo/odoo#247760
This update corrects a previous issue where event ticket prices were incorrectly locked to the event's price in the Point of Sale system. Now, event tickets will recalculate their price based on either the event's price or a relevant pricelist, ensuring accurate pricing at the POS. This improves the overall POS experience and pricing accuracy for event tickets.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248454
This update optimizes the Point of Sale system to use less memory, particularly when handling large product catalogs. The changes result in a significant reduction in memory consumption across browsers (Chrome, Safari, Firefox) when loading more than 20,000 products, leading to a smoother user experience.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Enterprise PR: https://github.com/odoo/enterprise/pull/107978 Forward-Port-Of: odoo/odoo#250480 Forward-Port-Of: odoo/odoo#249542
This update optimizes the Point of Sale (POS) system to use less memory, particularly when handling large product catalogs. The changes result in significantly reduced memory consumption across Chrome, Safari, and Firefox, leading to a smoother and more responsive user experience for sales teams.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Community PR: https://github.com/odoo/odoo/pull/249542 Forward-Port-Of: odoo/enterprise#108586 Forward-Port-Of: odoo/enterprise#107978
This update resolves an issue where certain Non-Resident (NRI) GSTINs were not recognized during the partner autocomplete process. The fix updates the validation logic to accept a wider range of valid NRI GSTIN formats, ensuring accurate data entry for NRI customers. This improves the user experience and data integrity.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves an issue where changing a company's VAT information on Peppol would cause invoices to be rejected by accounting partners. The fix prevents automatic recalculation of EAS/Endpoint values, ensuring accurate synchronization between invoice data and accounting systems. This eliminates the need for users to un-register and re-register their companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254057 Forward-Port-Of: odoo/odoo#249017
This update corrects a performance issue in the budget report, ensuring it runs efficiently when the account_budget_purchase module is enabled. Previously, a workaround bypassed a key optimization, leading to slower report generation times. This change restores the expected performance improvement.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127 Forward-Port-Of: odoo/enterprise#109322
This update resolves an issue where the Point of Sale in Mexico was incorrectly flagging an error when setting an invoice to public for customers without a ZIP code or country. The fix ensures the necessary data is correctly shared with the underlying database, preventing the error and allowing users to properly set invoices to public.
Original PR description
## Issue In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the…
## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896
## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.
## Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871This update fixes a calculation error in the monthly VAT reports for Italian companies (l10n_it). Incorrect formulas were causing inaccurate credit and debit values, particularly when carryovers from previous periods (VP8) were involved. The fix ensures accurate VAT reporting and compliance.
Original PR description
The VP14 formulas for both debit and credit were incorrect, leading to wrong values in the monthly VAT report For example, this occurs when there is a carryover from the previous period in VP8 ## Steps to reproduce: - Install l10n_it_reports and switch to the IT company - Create and confirm a Bill (Bill Date: 01/01/2026, Price: 100, Taxes: 10% G) - Create and confirm an Invoice (Invoice Date: 01/02/2026, Price: 200, Taxes: 10%) - Go to Reporting → Tax Report and select Monthly VAT Report (IT) - Select January, then click Returns - Select the period 01/01–31/12 with Monthly periodicity - Review the December and January tax returns by setting all errors to Reviewed, then Validate → Close (to trigger the VP8 carryover) - Return to the report view for February 2026 Check the VP14 credit value: it should be 0 (since the computed amount is negative) opw-6032147 Forward-Port-Of: odoo/odoo#254150
This update ensures shift emails are automatically sent to employees in their preferred language, regardless of the user sending the email. Previously, emails defaulted to the sender's language. This improves communication clarity and user experience for international teams.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#110778 Forward-Port-Of: odoo/enterprise#109619
This update fixes an issue where currency rates were being used incorrectly in certain reports (CTA queries). The change ensures that the correct, current-day currency rate is used, leading to more accurate financial reporting. This improves the reliability of key financial data.
Original PR description
We use currency rate at day x - 1 to be applicable at a date x, which shouldn't be applicable in the cta queries. Use same-day rate for the CTA query. task-5969168 Forward-Port-Of: odoo/enterprise#108879