Daily updates from Odoo
Thursday, July 10, 2025
32 changes · 18.0
Resolved issues and error corrections
Employees in Indian companies can now open their approved time off requests without running into an access error. The change prevents the system from trying to update leave details after approval, keeping approved records stable while preserving the existing time off calculation behavior.
Original PR description
**Steps to reproduce:** 1. Install l10n_in_hr_holidays and l10n_in 2. Switch to IN company 3. Create an employee related to Marc Demo in IN Company 4. Log in with Marc Demo and create a timeoff 5. Approve the timeoff by Mitchel admin 6. Open the form view of approved timeoff by Marc Demo **Issue:** - The _get_durations method in l10n_in_hr_holidays attempts to update the l10n_in_contains_sandwich_leaves field whenever it runs, including when opening the form view of an approved time off. This causes an access error, as updates are not allowed for Marc demo in the approved state. **Solution:** - Added a state check in the _get_durations method to prevent updating the field for approved records. opw-4741162
This fixes how Mexican DIOT tax report columns are calculated so they use the correct tax tags and tax values. Businesses should see more accurate DIOT reporting for paid VAT and import-related tax categories, reducing confusion from previously misleading column definitions.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. Current behavior before PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. Desired behavior after PR is merged: Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly. Likewise, the way of computing the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% has been simplified. Now it no longer adds up different types of taxes, but only one type. opw-4920577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217441
The Point of Sale product configuration popup now works even when multiple pricelists have the same name. This prevents checkout staff from encountering errors in setups where pricelist names are reused, improving reliability without changing normal workflows.
Original PR description
Before this commit, an error would occur when opening the product configuration popup if two pricelists shared the same name. This was due to the pricelist name being used as a key, which must be unique. This commit resolves the issue by switching to the pricelist ID as the key, ensuring uniqueness and preventing errors when duplicate pricelist names exist. opw-4882900 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where employees with flexible schedules could have incorrect timesheet entries for one-day leave. The system now records leave using the average daily hours, keeping timesheets aligned with time off calculations.
Original PR description
After https://github.com/odoo/odoo/pull/209570 , the way work intervals are computed might not reflect real working time for flexible employees, since the virtual schedule is based on a weekly span. In this PR we chose to allocate a timesheet for single day leaves corresponding to average hours per day to be consistent with hr_holidays calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Windows printer handling now sends documents to the printer one at a time when multiple jobs arrive simultaneously. This prevents print jobs from failing during busy periods and improves reliability for businesses using Odoo IoT printing on Windows.
Original PR description
Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218300
Turkish Nilvera e-invoice XML notes now include the remaining invoice amount written out in uppercase text. For invoices in a foreign currency, the note includes both the Turkish Lira amount and the foreign currency amount, helping recipients and compliance checks read the payable amount clearly.
Original PR description
This commit will add the amount residual in text in the note of the xml we sent to nilvera. If the invoice is in another currency than Turkish Lira, we have to add two notes one for the amount in turkish lira and one in the other currency task-4518269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195938
Odoo now shows a plus sign when a list selection may include more records than the displayed count, such as "10,000+". This helps users understand the true scope of bulk actions and reduces the risk of applying actions to more records than expected.
Original PR description
Previously, when selection was made in domain mode, the system used the global `web.active_ids_limit` config parameter instead of the actual number of records selected (based on session limit). This caused unintended behavior. For example: - Open a list view of a model with 25,000 records. - The pager limit is initially set to 10,000. - When selecting all 10,000 visible records and performing an action (e.g., archive), the system would incorrectly apply the action to 20,000 records (based on the default value of `web.active_ids_limit`), not the selected 10,000.
Automatic check-out now uses the employee schedule's local date instead of UTC when calculating expected and previous working hours. This prevents employees in time zones ahead of UTC from being checked out too early when they clock in before UTC midnight.
Original PR description
**Issue** The auto check out cron was using the check in time in UTC to determine the excepted working hours and the previous attendances. For example: - have an employee with a working schedule using a UTC+8 timezone. - check-in on a monday before 8am (0:00 UTC) in the employee's tz. - the auto check-out cron closes the attendance immediately because there are no working hours for the attendance's check in day in UTC (Sunday). **Change** Use the date of the check-in localized in the tz of the calendar used by the attendance's employee to determine the previous worked hours for that day and the expected worked hours. opw-4654847
This fix prevents an error when a cancelled sales order containing a kit is returned to quotation and confirmed again. It ensures cancelled delivery moves are ignored so users can proceed with the sales workflow normally, even when a kit uses the same component more than once.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/207955
Steps to reproduce the bug:
- Create a kit product:
- BoM:
- Components:
- 1 unit of C1
- 1 unit of C1 (same product)
- Create a SO with one unit of kit
- Confirm the SO
- The delivery is created
- Cancel the SO → the delivery is canceled.
- Set the SO back to quotation and confirm again
Problem:
A traceback is triggered:
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: mrp.bom.line(24, 25)
When a kit's BoM contains the same product multiple times, multiple bom_line_ids match a given move. Assigning them causes an error. Additionally, cancelled moves were incorrectly considered.
Solution:
Filter out cancelled stock moves before accessing the bom_line_id to ensure only active moves are considered.
opw-4919875Odoo now avoids trying to display raw binary file contents, such as PDF data, in the developer record data view. This prevents connection errors and keeps administrators' debugging tools usable when inspecting attachments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable developer mode; 2. go to Settings / Technical / Database Structure / Attachments; 3. open a PDF attachement; 4. open developer tools; 5. click on Record / Data. Issue ----- > Connection lost. Trying to reconnect... Traceback in logger: > `UnicodeDecodeError: 'utf-8' codec can't decode byte ...` Cause ----- Commit 5ef4c07ada1b4 moved the `json_default` function from `date_utils` to `json`, with the purpose of letting it serialize objects besides `date` & `datetime`. When used for raw data of binary files like PDF, it encounters values that cannot be represented in UTF-8, and because `decode` defaults to strict error handling, an exception is thrown. Solution -------- When sending the `read` request to the ORM, only request fields of that aren't of type `binary` to ensure they're serializable. opw-4717657
Cash-rounded invoices now export and import correctly in UBL electronic invoice formats. This prevents validation failures and helps ensure totals, taxes, and payable amounts remain consistent when invoices are exchanged with customers or authorities.
Original PR description
Currently these problems can appear when an invoice is cash rounded. 1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy: The rounding amount is added to the taxes in…
Currently these problems can appear when an invoice is cash rounded.
1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy:
The rounding amount is added to the taxes in Odoo but not in the UBL XML
- This affects everything that uses `_prepare_invoice_aggregated_taxes`
(and not just UBL XML)
2. The generated UBL XML is invalid (for any rounding strategy).
See below for details.
3. The import of the exported UBL XML does not yield back the same invoice
(even after fixing the export / the previous 2 problems).
Also there are some problems with the correction of tax values
of imported UBL XML (`correct_invoice_tax_amount`).
(They probably do not cause issues in practice but would after this
fix. We adapt the correction as part of the fix for (3).)
#### Runbot: How to generate problematic XML
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method
(in the settings where cash rounding can be enabled):
- precision `1.00`
- strategy: any
- profit / loss account: any
4. Create an invoice
- Set a Belgian partner (e.g. "BE Company CoA" is okay)
- Set the the cash rounding method from step 2
- Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding)
In the journal items there should be the following
non payment term items:
- 70.00€ base
- 14.70€ tax
- 0.30€ rounding (depending on the cash rounding strategy the tax is set or not)
6. Confirm & Send (with BIS Billing 3.0)
7. Look at the UBL BIS 3 XML in the `Invoice` element
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
8. This fails validation `BR-CO-15`:
```
Invoice total amount with VAT (BT-112)
= Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
```
(`LegalMonetaryTotal/TaxInclusiveAmount` = `LegalMonetaryTotal/TaxExclusiveAmount` + `TaxTotal/TaxAmount`)
Since the cash rounding is included in `LegalMonetaryTotal/TaxInclusiveAmount` but not in
`TaxTotal/TaxAmount` (or `LegalMonetaryTotal/TaxExclusiveAmount`)
#### Tax value correction details (with examples)
Currently we try to fix the tax amounts after importing an invoice.
The function we use for that (`_correct_invoice_tax_amount`) has the following issues:
- We look for `TaxTotal/TaxSubtotal` elements anywhere.
But i.e. such elements can also exist inside `InvoiceLine` elements.
Example:
- module `l10n_dk_oioubl` file `test_xml_oioubl_dk.py`
- function `test_oioubl_import_exemple_file_4` / XML file 'external/BASPRO_01_01_00_Invoice_v2p1.xml'
- The tax total parsed from the document may need to be inverted.
E.g. credit notes can be given as an invoice with negative amounts.
See function `_get_import_document_amount_sign`.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_be.py`
- function `test_import_invoice_xml_open_peppol_examples` / XML file 'bis3_invoice_negative_amounts.xml'
- We compare the tax total from the document only with a single line of that tax.
But there can be multiple lines for a single tax. We have to use the sum of all those lines for the comparison.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_au.py`
- function `test_export_import_invoice` / XML file 'from_odoo/a_nz_out_invoice.xml'
#### The fix
This commit does the following to fix that
1. We include cash rounding lines belonging to a tax in the tax computation for the UBL XML export
(or rather everything any tax computation done with `_prepare_invoice_aggregated_taxes`).
2. After fixing (1) we only have to fix the "Add a rounding line" (`add_invoice_line`) strategy.
This is as follows
- Subtract the cash rounding from the `LegalMonetaryTotal/TaxInclusiveAmount`
- Add node `LegalMonetaryTotal/PayableRoundingAmount` with the value of the cash rounding
3. Cases
- `add_invoice_line`: We create a dedicated invoice line with the amount found in node
`LegalMonetaryTotal/PayableRoundingAmount` (if it is present).
- `biggest_tax`: We update the amount on the tax line to match the value found in the XML.
(Currently we only do this if the difference is not greater than '0.05')
The fixes for the tax value correction on import are also needed for 3./`biggest_tax`.
#### Runbot: example XML after the fix
The export in the example then looks like this for the different cash rounding strategies
- `add_invoice_line`
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
- `LegalMonetaryTotal/PayableRoundingAmount`: 0.30€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
The validation for the `LegalMonetaryTotal/PayableAmount` is still
okay since (in the example) it is just `LegalMonetaryTotal/TaxInclusiveAmount` + `LegalMonetaryTotal/PayableRoundingAmount`.
- `biggest_tax`
- `TaxTotal/TaxAmount`: 15.00€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 15.00€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableRoundingAmount`: (not exported)
- `LegalMonetaryTotal/PayableAmount`: 85.00€
#### References
Also see
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals
task-4854592
Forward-Port-Of: odoo/odoo#213378This fixes an issue where newly created, automatically validated attendance records could show zero extra hours even when an employee worked overtime. The correction ensures overtime is calculated immediately when the record is saved, improving accuracy for attendance and payroll-related reviews.
Original PR description
Introduced by cc81bb59f87540cf4dd8da65510417d8023ef65b **Steps to reproduce** 1. Create a new automatically validated attendance. 2. Set the employee, check in and check fields before saving the form. Issue: the "Extra hours" field is not computed. e.g.: if the employee has worked 1 hour more than expected, "Worked Extra Hours" equals 1:00 (ok), but "Extra hours" appears as 0:00. **Cause** The previous fix intended to avoid recomputation of the `validated_overtime_hours` field. No better way was found than to exclude records where the `overtime_hours` was different than the `validated_overtime_hours` (meaning it had been manually modified by the user). The problem comes from the fact that at creation, `validated_overtime_hours` was sent in the `vals_list` to the create with a value of 0. **Solution** Force the computation of the field at creation.
Odoo now hides star and mark-as-read options on chatbot messages while a live chat thread has not yet been saved. This prevents users from triggering errors by clicking actions that cannot work in that temporary state.
Original PR description
**Before this PR:** the toggle-star and mark-as-read actions were visible on chatbot messages in a non-persisted livechat thread. Clicking these actions caused errors. This PR hides these actions when the thread is in a non-persisted state, preventing such errors. task-[4743758](https://www.odoo.com/odoo/project/1519/tasks/4743758) Forward-Port-Of: odoo/odoo#214382
The hardware drivers module now skips certificate updates when the data received from Odoo.com is empty. This helps prevent web server restart issues that could disrupt connected hardware services.
Original PR description
We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. Task: 492610
Products available for store pickup will now still show an out-of-stock message when relevant. This helps shoppers understand product availability more clearly and reduces confusion during checkout or pickup selection.
Original PR description
Before the commit, when a 'pick up in store' was published, the out-of-stock message was hidden to avoid confusion. However, customers want to benefit from it, and now we reintroduce it. opw-4791969
Users can now return to the expense list after opening an expense from dashboard filters such as "To Submit". This fixes a navigation issue that made reviewing filtered expenses less efficient.
Original PR description
**Steps to reproduce:**
- Install the `hr_expense` module.
- Go to the Expense menu and click on "To Submit" in the My Expense dashboard.
- Open any record from the list view.
**Observation:**
- You can't go back to the list view after opening a record.
**Cause:**
- A tag `menu` was added to the action to hide breadcrumbs, but it removed all breadcrumb navigation, unable to go back.
https://github.com/odoo/odoo/blob/92993d7790bb641e5822a5358db35c7fcc7bd091/addons/hr_expense/static/src/components/expense_dashboard.js#L44
**Solution:**
- Used a better way by passing `{ clearBreadcrumbs: true }` to stop the breadcrumb from changing when a filter is applied.
opw-4790643
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCancelling accounting entries no longer removes their reference when the entry is not linked to an expense. This prevents unrelated records from losing important identifying information when the Expenses app is installed.
Original PR description
### Issue: On 18.0 and 18.1, cancelling an `account.move` will clear the `ref` value in all situations if `hr_expense` is installed. While clearing the `ref` is necessary if unlinking an expense, this isn't the case for unrelated records. ### Solution: Check to see if the `expense_sheet_id` is set on the `account.move` to determine if the `ref` should also be removed. ### Additional Note: This flow was reworked in 18.2 via #189701, so we only need to adjust this for the affected versions. opw-4853903
Manufacturing users can now create a new workcenter directly from the operations form even when no Bill of Materials has been selected. This removes an unnecessary company setting that caused an error and interrupted setup workflows.
Original PR description
**Current behavior:** Can't create a workcenter from the operations (workorder) form view without having a BoM filled in (due to company check issue). **Expected behavior:** Can **Steps to reproduce:** Open `Manufacturing / Configuration / Operations` -> create new -> type in a new workcenter name -> hit create -> error **Cause of the issue:** in `mrp_routing_workcenter_form_view` we get some context for a `default_company_id`- it's not only unnecessary because `Mrp.Workcenter` will get a default company just fine via its its `resource.mixin` inheritance. The currently provided company comes from the BoM, thus the issue happens when the BoM has not yet been filled in on the view. **Fix:** Remove the context in the view. opw-4836904
Mobile dialog headers no longer use backend-specific colors such as the community theme color. This keeps website dialogs visually consistent for visitors and prevents internal Odoo styling from appearing on the public front-end.
Original PR description
Before this PR: header color of `Dialog` on mobile was "community color" or white, depending on the version of Odoo the database is running. This was creating issues in in the front-end, where the user of the website would see back-end specific colors in different `Dialog`s. This PR removes the color customization of `Dialog`'header as it was fitting a design line we had before we introduced MILK. task-4001365 Example of the issue (mobile front-end): <img width="376" alt="Screenshot 2024-06-20 at 10 54 04" src="https://github.com/odoo/odoo/assets/110090660/dad6a4b2-6164-45dd-9e16-0160e2989607"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170087
When a purchase order linked to a sales delivery is cancelled, Odoo now allows the delivery to use available inventory instead of continuing to wait for the cancelled purchase. This helps orders move forward when stock is later added or already available, reducing unnecessary delivery delays.
Original PR description
Steps to reproduce the bug:
- Unarchive the MTO route
- Create a product P1:
- Type: Storable
- Route: MTO
- Supplier: Vendor A
- Create a sales order for 1 unit of P1
- Confirm the SO
→ A purchase order is created for Vendor A with 1 unit of P1
- Cancel the PO
- Update the quantity on hand of P1 to 1
- Go to the delivery picking of the SO
- Check availability
Problem:
The quantity on hand is not taken into account, and the picking remains
in the "Waiting Availability" state.
When the purchase order is cancelled, the stock move should switch to
MTS instead of remaining in MTO.
opw-[4876611](https://www.odoo.com/web#id=4876611&view_type=form&model=project.task)
opw-[4874199](https://www.odoo.com/web#id=4874199&view_type=form&model=project.task)The Discuss message composer now keeps the send button's opacity behavior aligned with other composer buttons when the message field is empty or focused. This creates a more consistent and polished user experience without changing how messages are sent.
Original PR description
Before this commit, the paper-plane button to send a message was not changing opacity when the composer was empty and the user focused on the composer. Whereas the other buttons such as the emoji picker were changing it. Now the opacity of this button is changing like the other buttons while still changing when the composer is not empty (like before this commit) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance reports now respect the employee’s weekly contracted hours when calculating expected hours for flexible schedules. This prevents reports from overstating expected time when an employee works more days than their contract allows.
Original PR description
### Issue: - When the attendance is flexible, the weekly expected hours shown in reports are incorrect. - This happens because the calculation is based only on the hours worked per day and doesn't…
### Issue:
- When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
- This happens because the calculation is based only on the hours worked per day and doesn't
take into account the total hours worked during the week.
It ignores the weekly limit defined in the employee's working schedule.
- As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.
Example:
- An employee has a 32h/week contract and 8h/day.
- If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.
### Steps To reporduce:
- Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
- Log 5 attendances in one week with 8 worked hours each.
- Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.
### Solution:
- Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
- If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.
OPW-4583064
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change corrects how monthly payroll summaries are aggregated for Swiss ELM transmissions. It helps ensure payroll reporting totals are calculated accurately, reducing the risk of incorrect submissions or follow-up corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#89839
The Italian point of sale flow now makes sure the invoice option is selected before validating an order. This prevents a validation error and helps sales complete correctly when an invoice is required.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349
Updates the Mexican DIOT report logic to use the correct reporting references after related column changes. This helps ensure DIOT tax report values are calculated from the intended categories and avoids confusion from outdated labels.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. This issue was addressed in PR: https://github.com/odoo/odoo/pull/217441, but a small adjustment still needs to be made in the l10n_mx_reports module. Current behavior before PR: The l10n_mx_diot_get_values function uses references to the old account.report.expression that were removed in the pr mentioned above. Desired behavior after PR is merged: The l10n_mx_diot_get_values function uses the new references to account.report.expression that were introduced in the pr of the community repo. opw-[4920577](https://www.odoo.com/odoo/my-tasks/4920577) "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" Forward-Port-Of: odoo/enterprise#89481
Shipping label printing now includes a unique print identifier when sending jobs to connected IoT printers. This prevents unnecessary printer-related error messages while keeping the label printing process working smoothly.
Original PR description
Before this commit, the shipping label printing would send documents to the printer without using a print_id, which would cause an error (but the document would still print). After this commit, we send a print_id using a UUID just like for report printing, ensuring no error occurs on the IoT. opw-4829908 Forward-Port-Of: odoo/enterprise#89930
Fixes Colombian electronic invoicing so cash rounding lines are included correctly in tax calculations and UBL invoice output. This helps ensure legally required invoice files match rounded invoice totals, reducing validation errors when submitting invoices.
Original PR description
#### [FIX] l10n_co_dian: UBL related cash rounding issues In the community PR the UBL XML generation was adjusted to support cash rounding. (See there for more details) This commit adjusts the code in `l10n_co_dian` to be compatible. #### [FIX] l10_co_edi: tax_amls include rounding lines Currently rounding lines (with taxes) are not included in the tax lines. This is fixed in this commit. See the community PR / commits for motivation. #### info task-4854592
The Spanish tax report now avoids adding rectification lines for bills and credit notes that fully cancel each other within the same reporting period. This prevents incorrect BOE 349 declarations while preserving expected rectifications for documents from previous periods.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
Fixed an issue where returning to a receipt in the Barcode app could incorrectly increase the requested quantity for lot-tracked products. This keeps warehouse receipts accurate when users partially process and later complete grouped barcode lines.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back…
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back to the picking register the 9 remaining units - Exit the picking and comeback #### > The demand of the receipt has been updated from 10 to 19. ### Cause of the issue: Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand: https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand. opw-4731803
Amazon order shipping now better recognizes DPD, Hermes, and Royal Mail carrier names used in Great Britain. This helps prevent carrier mapping issues when Sendcloud provides country-specific carrier codes, improving fulfillment accuracy.
Original PR description
For DPD and Hermes (not the others), Sendcloud adds an unnecessary ISO code. In order to keep it should it be necessary (e.g. rml_gb), we map them to the Amazon const instead of stripping the code. While testing, it was also found that royal mail seems to have been renamed and was thus not working. Forward-Port-Of: odoo/enterprise#87745
The Belgian POS blackbox integration now acknowledges status messages properly, preventing repeated or misplaced responses. This reduces failed communications with the device and helps ensure sales certification requests receive the expected replies.
Original PR description
We did not send an `ACK` after asking for blackbox status, leading in BlackBox sending it again. This lead to situations where we sent requests to the BlackBox, and received the status instead of the actual response. In addition, the repeated status responses were missing the leading `ACK`, resulting in our log: `sent 1 NACKS without receiving response, giving up.` More, if we sent a command too soon to the BlackBox (before it finished instanciating), we were receiving its `certified ref` instead of the actual response, due to the `_push_status` method called from the `run` method of the BlackBox Driver parent class. This `run` method is now overridden by the BlackBox driver Task: 4750435 Backport of https://github.com/odoo/enterprise/pull/87659
Work permit fields have been restored in the Swiss payroll employee view. This helps Swiss payroll users access and maintain important employee permit information directly where they need it.
Original PR description
In this PR we reintroduce the work permit fields for the swiss localization, which is heavily used. Forward-Port-Of: odoo/enterprise#89864