### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Forward-Port-Of: odoo/odoo#237544
Forward-Port-Of: odoo/odoo#235112

Steps to reproduce:
1. Open database with version saas-18.4
2. Install module l10n_fr_hr_payroll_with_accounting
3. Make sure that your company's country is France.
4. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
5. In Payroll app create a payslip for any employee having contract.
6. Make sure in `other inputs` you make new type and in that in the `availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

In saas-18.4, the model hr.contract was [changed](https://github.com/odoo/upgrade/blob/fa44eb03c2b46d948e20dc6f5ac01dca2b625b90/migrations/hr/saas~18.4.1.1/pre-migrate.py#L41) to hr.version . All related code https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8 was updated to use version instead of contract. in this commit.

However, in the module l10n_fr_hr_payroll, there where some fields which is still using `contract` to refer other fields .
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/data/l10n_fr_hr_payroll_employe_cadre_data.xml#L130 Because of this, Odoo raises the error `Wrong python code name 'contract' is not defined when evaluating the code`.

I have fixed the issue by updating the name from contract to version in that module contract to version.

opw: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

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

Forward-Port-Of: odoo/odoo#237060

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

Forward-Port-Of: odoo/enterprise#98808

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved.

Steps to reproduce:
-------------------
* Open the restaurant
* Open booking tab
* Create a new booking for 3 people
* Select 2 tables of 2 capacity
* Save
> Observation: Only one table resource is saved

Why the fix:
------------
By having the context key `default_resource_total_capacity_reserved` we would recompute the resources for the booking. It was recomputed in a way that we just une the minimum resources needed in regards of the resource capacity. For example if we had 3 tables of 2 and we are booking for 3, we wouldn't need the 3rd extra table.

In our case the capacity was always set to 2, as the point of sale form actually uses the field `waiting list capacity`. Since most table are usually for at leat 2 people only 1 would be needed. Removing `default_resource_total_capacity_reserved` from the context gives more freedom upon reservation and does not compute resources, it uses those selected on the form.

opw-5109501

Community: https://github.com/odoo/odoo/pull/230920

Forward-Port-Of: odoo/enterprise#96811

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657