**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Create an account (e.g. Test Account)
- Go to "Accounting / Accounting / Miscellaneous / Journal Entries"
- Create a journal entry:
  * Journal Items:
------------
        Account    |    Debit    |    Credit
    --------------------------------------------
     Test Account  |    $0.00    |    $410.34
         [any]     |   $410.34   |     $0.00

- Post the journal entry
- Go to "Accounting / Accounting / Management / Automatic Transfers"
- Create an automatic transfer:
  * Origin Accounts: Test Account
  * Automated Transfer:
-----------
        Percent (%)    |    Destination Account
    -----------------------------------------------
           15.00       |           [any]
           42.50       | [any, but a different one]
           42.50       | [any, but a different one]

- Activate the automatic transfer
- Compute transfer

**Issue:**
A UserError is raised while trying to create a journal entry because of a $0.01 difference between the total credit and the total debit.

**Cause:**
When the amounts of each line are computed from the percentage, they are not rounded.
These amounts are used to create the journal entries generated by the automatic transfer.
However, each created journal entry line is rounded, which can generate a rounding difference.

**Solution:**
Directly round the amounts when they are computed from the percentage to be sure that the amounts used for the computation and the ones that will be set in the journal entries are the same.

opw-3998808

Forward-Port-Of: odoo/enterprise#67956
Forward-Port-Of: odoo/enterprise#67644

Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix.

Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured':

```
File ".../l10n_br_avatax/models/res_config_settings.py", line 85, in create_account
result = json.loads(result['message'])
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

This makes the error handling more robust by first attempting to decode the string as JSON. If that fails we fall back on the other two scenarios.

A new test class is included that provides examples of each type of response.

opw-4067842

Forward-Port-Of: odoo/enterprise#67477

### Main Issue:
When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house number from the 'street' field of the partner.

### Main change:
Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats.

### Before:
- Regex Pattern: `([1-9]+\w*)`
- Explanation: This pattern captures one or more digits (not starting with zero) followed by any number of word characters (letters, digits, or underscores).

### After:
- Regex Pattern: `(\d+[-\/]?\d* ?[a-zA-Z]?\d*)(?![a-zA-Z])`
- Explanation: This improved pattern captures a broader range of house number formats, including those with dashes, slashes, spaces, and letters.

### Examples of the Differences:

    "Friedrichstr. 13/1"
        Before: '13'
        After: '13/1'

    "Rue du pont 11 A"
        Before: '11'
        After: '11 A'

    "Place Albert 1er 15B"
        Before: '1er'
        After: '15B'

    "123-456 Main Street"
        Before: '123'
        After: '123-456'

    "789 C Oak Avenue"
        Before: '789'
        After: '789 C'

[opw-4042552](https://www.odoo.com/odoo/project/49/tasks/4042552)

Forward-Port-Of: odoo/enterprise#67344
Forward-Port-Of: odoo/enterprise#67286

**Current behavior:**
There are several related bugs when operating in a multi-company
environment with the barcode app:

*Given:* we have three companies in the selector (A, B, C) where
company A is the first/default/primary of the three.

***Case 1: (CompanyB and CompanyC are checked, either can be focused)***
1) Scanning the barcode for CompanyC's manufacturing operation and
then, within the barcode view, scanning a product which belongs
exclusively to CompanyB will make it impossible to use the back
button (despite the product correctly not being added as a line
in the operation).

2) Repeating the setup with a different operation type (e.g.,
receipt) *will* add the product to the picking but it will not
be possible to validate/take out of draft from either the
barcode app nor from the backend.


***Case 2: (only CompanyC checked and focused)***
1) Scanning the barcode for CompanyC's manufacturing operation type
will open the barcode operation view for CompanyA's manufacture
operation. Products available to CompanyC can be added. Trying
to validate the order will cause an access error, however the MO
is still created in the backend.

2) Scanning the barcode for either CompanyB or CompanyA's
non-manufacturing operations will show an access error dialog,
but an (empty) transfer will still be created in the backend for
the respective company.

---

**Expected behavior:**
In case 1, scanning a product which is not available to the
current company should not trap the user in the barcode
operation view. It should also not add these inaccessible
products to a picking thereby making them unable to be
validated.

In case 2, we should respect the company defined on a
manufacturing operation type which corresponds to a scanned
barcode. Additionally, it should not be possible to create empty
transfers for companies which are not currently checked/active.

---

**Cause of the issue:**
Problem 1: production records (unlike pickings) cannot be
created until a product is added in the barcode view. Because of
this different flow, they are created with less context than
other operation types and there was no mechanism by which their
`company_id` could be inferred.

This caused them to use the default value as defined in the
`MrpProduction` model (`self.env.company`)- which is problematic
in the barcode app, as this field does not actually correspond
to the focused/active company.

Problem 2: when scanning a picking type from the main menu of
the barcode app, the company of the picking type was not getting
respected which would cause a new picking record to be created
even when the current user/environment did not have permission.

---

**Fix:**
1. Create production records using a default `company_id` value
informed by their `picking_type_id` rather than the environment

2. In the main_menu barcode scan route, use the current user's
allowed company ids (from their cookies) to restrict searchable
records

3. When scanning products in a barcode operation view, use the
company_id of the opened operation type to restrict the domain
of searchable records.

opw-3999622

Forward-Port-Of: odoo/enterprise#67134
Forward-Port-Of: odoo/enterprise#65433

When User opens an appointment with resource that does not have Opening Hours,
a traceback will appear.

Steps to reproduce the error:
- Go to 'Appointments' > Configuration > Resources >
  Create a new Resource without opening hours (ex. court) > Save
- Create new Appointment > Availability on: resources > Resource: court > Save
- Click on Go to website or Preview

Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2232, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1807, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1827, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1805, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1812, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1950, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.2/appointment/controllers/appointment.py", line 210, in appointment_type_page
    return self._get_appointment_type_page_view(appointment_type, page_values, state, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/website_appointment/controllers/appointment.py", line 108, in _get_appointment_type_page_view
    return super()._get_appointment_type_page_view(appointment_type, page_values, state, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/appointment/controllers/appointment.py", line 228, in _get_appointment_type_page_view
    slots = appointment_type._get_appointment_slots(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 798, in _get_appointment_slots
    self._slots_fill_resources_availability(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1183, in _slots_fill_resources_availability
    availability_values = self._slot_availability_prepare_resources_values(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1369, in _slot_availability_prepare_resources_values
    resources_values.update(self._slot_availability_prepare_resources_leave_values(resources, start_dt_utc, end_dt_utc))
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1422, in _slot_availability_prepare_resources_leave_values
    unavailabilities = appointment_resources.sudo().resource_id._get_unavailable_intervals(start_dt_utc, end_dt_utc)
  File "addons/resource/models/resource_resource.py", line 152, in _get_unavailable_intervals
    resources_unavailable_intervals = calendar._unavailable_intervals_batch(start_datetime, end_datetime, resources, tz=timezone(calendar.tz))
  File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

https://github.com/odoo/odoo/blob/6cb52b4a02a7b3236c20863b177bfaadf474651d/addons/resource/models/resource_resource.py#L147 Here, when the user does not select Opening Hours in resource,
"calendar.tz" will be False.
So, it will lead to the above traceback.

sentry-5475389977

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#169038

Versions
--------
- 15.0+

Steps
-----
1. Have an employee on a 40 hour/week work schedule;
2. for a past week, create a sick leave for monday & tuesday;
3. create 8 hour timesheets for the remaining weekdays;
4. switch the employee's work schedule to 35 hour/weeks;
4. navigate to the week with the leaves in Timesheets.

Issue
-----
The hours displayed next to the employee name shows -11:00, ignoring the the timesheets created by the leaves.

Cause
-----
`resource.calendar.leave` records have a `calendar_id` field which is inialized to the resource's calendar, and updates if the resource changes, but not when the resource's calendar changes.

As a consequence, the `_work_intervals_batch` method used for this calculation gets called on the employee's new calendar, which is no longer related to the calendar associated with their leaves.

Solution
--------
Replace the `onchange_resource` method with a compute method which updates the leave's field if the employee's calendar changes.

opw-3693131

Forward-Port-Of: odoo/odoo#172346
Forward-Port-Of: odoo/odoo#169291

__Current behavior before commit:__
If `crm` is installed `test_import_multiple_invoices` will fail because the crm demo data are changing the email of the partner `base.res_partner_12` (i.e. Azure Interior)(see [crm_lead_demo.xml][1]). `partner` will therefore be `False`.

__Description of the fix:__
Getting `partner` from the `base.res_partner_12` external id so this test does not depend on modifications from other modules.

__Steps to reproduce the issue:__
Run:
```sh
./odoo/odoo-bin -d test-17 -i crm,l10n_es --test-tags .test_import_multiple_invoices --addons-path=./enterprise,./odoo/addons
```
You will get:
```log
odoo.addons.l10n_es_edi_facturae.tests.test_edi_xml: FAIL: TestEdiFacturaeXmls.test_import_multiple_invoices
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/l10n_es_edi_facturae/tests/test_edi_xml.py", line 283, in test_import_multiple_invoices
    self.assertRecordValues(moves, [
  File "/home/odoo/src/odoo/odoo/tests/common.py", line 659, in assertRecordValues
    self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.

==== Differences at index 0 ====
---

+++

@@ -1 +1 @@

-partner_id:14
+partner_id:False

==== Differences at index 1 ====
---

+++

@@ -1 +1 @@

-partner_id:14
+partner_id:False
```

opw-4009379

[1]: https://github.com/odoo/odoo/blob/1c8e2555366fe6e6b0d74d6db71a29d09bd5f06a/addons/crm/data/crm_lead_demo.xml#L606

Forward-Port-Of: odoo/odoo#175601
Forward-Port-Of: odoo/odoo#173863

Versions
--------
- 17.0+

Steps
-----
1. Go to Website / Shop;
2. click on a product;
3. click on the phone icon to get mobile view;
4. open the editor;
5. click on the product image;
6. set Layout / Image Zoom to Both;
7. save.

Issue
-----
Clicking on the product image doesn't zoom it.

Cause
-----
Commit 75cb82490200 improved zoom features. In the `_startZoom` function it added a comment to an early return, explaining zoom-on-hover should be ignored on mobile:

https://github.com/odoo/odoo/blob/75cb824902000b2c05716c8992ec486cf7102cea/addons/website_sale/static/src/js/website_sale.js#L490-L495

The issue is that this function also handles zoom-on-click, which gets skipped as well with the early return.

This early return didn't fire in the editor before commit 55f182291164, because it checked the value of `config.device.mobile`, which was `undefined`. After this commit, it checks `uiUtils.isSmall()` instead, which does return true in the editor, fully disabling the ability to zoom-on-click:

https://github.com/odoo/odoo/blob/55f1822911641a63309078dbc6dadf0c9fdc0796/addons/website_sale/static/src/js/website_sale.js#L341-L343

Solution
--------
Move the check on `uiUtils.isSmall()` from the early return to the `salePage.dataset.ecomZoomAuto` check, so that only zoom-on-hover gets skipped on mobile.

opw-3880081

Forward-Port-Of: odoo/odoo#170747

## Description
It's really slow to archive a published course with many participants

## Analysis
In `_recompute_completion`, we are recomputing the set of resume lines to check against to see if we should add a new resume line upon completion of a course for *each* employee associated with the course. Also the creation of resume lines is not batched.
There is also *no* indexes of any sort on the `hr.resume.line` model.

## Solution
- Refactor to remove the `search` inside the `for`
- Batch the create
- Add missing indexes

## Benchmark
Archiving a published course with ~30k participants, with a over 100k resume lines in the database.

| No indexes | Before | After | Speed up |
|------------|--------|-------|----------|
| Timings    | 1m39s  | 17s   | 5.8x     |

| With indexes | Before | After | Speed up |
|--------------|--------|-------|----------|
| Timings      | 1m39s  | 4.14s | 23.9x    |

## Reference
task-4043098

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#173857

Issue:
The `_get_weight` method is called for each location to compute the weight and it sums up all the incoming and outgoing lines for forecasted weight. Using filtered for each record is compute intensive and gets slower over time.

While returning a delivery with 30 stock moves the _create_return took 7:41 minutes most of which were on `_get_weight`. Here filtered alone was taking over 6 minutes.
![image](https://github.com/odoo/odoo/assets/111344786/52f2bdef-f486-4e07-aab3-0ced1d68bd1c)

For a single run, 
|| Before| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 246.05s |

Solution:
Optimized the `_get_weight` method to use `read_group` to get the sum of incoming and outgoing lines. This reduces the number of reads. Total time for the same return reduced to 28s.

![image](https://github.com/odoo/odoo/assets/111344786/9cc83c93-3502-44a2-af54-9a269a98394a)
For a single run:
|| After| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 0.4s |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#174660
Forward-Port-Of: odoo/odoo#170675

### Version:
15, 16, 17, master

### Description of the issue/feature this PR addresses:

Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly.

[Video](https://drive.google.com/file/d/1D4uqNnXMkguS813NiLl9td4_f_TJ35Xf/view) showing how to replicate the bug:

### Steps to reproduce:

1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module.
2. Take position on company "Responsable Inscripto"
3. Go to "Accounting / Customers / Invoices" and create a new customer invoice with customer "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a sale journal "Pre-printed Invoice" AFIP POS System (i.e Ventas Preimpreso), add an invoice line and confirm it. ![image](https://github.com/user-attachments/assets/5e770259-6195-45af-b2d2-6e7a701f9fb5)

4. Reset to draft the invoice mentioned in step 3 (now journal and document type are readonly fields), change customer to "Consumidor Final Anónimo" (this partner has "Consumidor Final" AFIP Responsibility) and save. Check that the document type has changed from "(1) FACTURAS A" to "(6) FACTURAS B" and this is not the desired behavior because is a readonly field now because the invoice was posted before. 
![image](https://github.com/user-attachments/assets/d9d4cced-59df-4f0b-8222-1a581702bd0b)

### Current behavior before PR:

When a customer invoice with customer with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted.

### Desired behavior after PR is merged:

When a customer invoice with customer with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is not changed.

Ticket Adhoc side: 77058
Task latam: 1235


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#172003

### [FIX] hr_holidays: search for leaves in user's tz

For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed.
Let's also assume that the everything happens in GMT+10

Now if we have a valid leave allocation for Mon and Tue, we should
NOT be able to able to take it on Wed. However, because of the way
Timestamps are casted to dates it is possible. It happens as follow:
user "asking" server for leave on Wed, defines requested day by passing by
the datetimes in the context ranging from Tue 21:00 to Wed 09:00

Why such datetime range? Firstly because we have hardcoded devault values
for events that range from 07:00 to 19:00 in local time (ref.1).
Secondly because we're in GMT+10 so this range gets shifted:
 07:00 on Wed becomes 21:00 on Tue
 19:00 on Wed becomes 09:00 also on Wed

Then because allocations ranges are defined by dates not datetimes,
implicit casting is performed that causes cut-off of the time from the datetime
and in the end instead of checking if leave is allowed on Wed we check if
it is allowed on Tue and Wed.

### [FIX]
Shifting back into the user's timezone before casting.

### [Reproduction of the original issue]
- install hr_holidays
- create employee E
- create & validate new Allocation A  (in TimeOff/Allocations):
        - of type T (creating new type will help identify the issue)
        - for employee E
        - valid from Mon to Tue
- Open E's time off (Employee E -> Time Off)
- Switch your browser TZ that is +10
- Attempt to book time off for E on Wed
- BUG: you are allowed to do so

opw-3850159

(ref.1)
calendarEventToRecord from calendar_model
https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75


![3850159 Can apply for a leave with expired allocissueation; Timezone  _0 excalidraw](https://github.com/user-attachments/assets/ed06411b-7403-4676-bd8b-82ebb203090e)

Forward-Port-Of: odoo/odoo#175567
Forward-Port-Of: odoo/odoo#172748

## Description
On large MOs with many lines, the `onchange` triggered when setting the `lot_producing_id` can be really slow.

## Analysis
In `_set_quantity_done`, the `__set__` on `move_line_ids` triggers the computation of fields that depends on it.
This necessitates the creation of a trigger tree, to know what fields on what model with what records needs to be recomputed. In this context, because some of the frequent dependencies, `raw_material_production_id` and `production_id` on `stock.move` don't have a respective inverse *without* a domain on it, in `_modified_triggers`, we fall back on a generic lookup of cache entries + filtering, which can be costly, as it's `O(n)` in complexity, and `n` can be large, in this case it's over 18k records of `stock.move`, that's done 4 times (the tree has 2 instances for each of the above-mentionned `Many2one`)
The process of resolution of the dependencies tree is repeated for each line of the MO, accentuating the bottleneck.

## Solution
Adding two `One2many` fields to be the generic inverse of `raw_material_production_id` and `production_id` on `mrp.production`, so the ORM can use those to fall into the fast-path when resolving these dependencies.
There are already two `One2many` on this model that are inverse of these `Many2one` (`move_raw_ids` and `move_finished_ids`), but they each have a domain, therefor the ORM cannot use them as an inverse during creation of the trigger tree.

## Benchmarks

|         | Before | After |
|---------|--------|-------|
| Timings | 91.8s  | 14.1s |

## Reference
opw-4003495

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170881