It defeats the purpose to use `SQL` with f-strings. We observed that if there is an uppercase letter in field names we get an error. Steps to reproduce:

1. Install account_reports
2. Add a manual field `x_M` to `account.move.line`
3. Open Profit and Loss report
4. Group by Analytic.

Error (edited to reduce space):
```
2024-11-13 11:12:53,437 1855548 ERROR test_17.4 odoo.sql_db: bad query:
            -- Create a temporary table, dropping not null constraints because we're not filling those columns
            CREATE TEMPORARY TABLE IF NOT EXISTS analytic_temp_account_move_line () inherits (account_move_line) ON COMMIT DROP;
            ALTER TABLE analytic_temp_account_move_line NO INHERIT account_move_line;
            ALTER TABLE analytic_temp_account_move_line DROP CONSTRAINT IF EXISTS account_move_line_check_amount_currency_balance_sign;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN move_id DROP NOT NULL;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN currency_id DROP NOT NULL;

            INSERT INTO analytic_temp_account_move_line (...)
            SELECT account_move_line.company_id AS "account_move_line.company_id",... to_jsonb(UNNEST(ARRAY[account_analytic_line.account_id, x_plan2_id, x_plan3_id])) AS "account_move_line.analytic_distribution", ... account_move_line.x_M AS "account_move_line.x_M", ...
            FROM account_analytic_line
            LEFT JOIN account_move_line
                ON account_analytic_line.move_line_id = account_move_line.id
            WHERE
                account_analytic_line.general_account_id IS NOT NULL;

            -- Create a supporting index to avoid seq.scans
            CREATE INDEX IF NOT EXISTS analytic_temp_account_move_line__composite_idx ON analytic_temp_account_move_line (analytic_distribution, journal_id, date, company_id);
            -- Update statistics for correct planning
            ANALYZE analytic_temp_account_move_line

ERROR: column account_move_line.x_m does not exist
LINE 10: ... AS "account_move_line.discount_amount_currency", account_mo...
                                                              ^
HINT:  Perhaps you meant to reference the column "account_move_line.x_M".
```

After this patch the same query is:
```
            -- Create a temporary table, dropping not null constraints because we're not filling those columns
            CREATE TEMPORARY TABLE IF NOT EXISTS analytic_temp_account_move_line () inherits (account_move_line) ON COMMIT DROP;
            ALTER TABLE analytic_temp_account_move_line NO INHERIT account_move_line;
            ALTER TABLE analytic_temp_account_move_line DROP CONSTRAINT IF EXISTS account_move_line_check_amount_currency_balance_sign;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN move_id DROP NOT NULL;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN currency_id DROP NOT NULL;

            INSERT INTO analytic_temp_account_move_line (...)
            SELECT "account_move_line"."company_id" AS "account_move_line.company_id", ... "account_move_line"."x_M" AS "account_move_line.x_M", ... to_jsonb(UNNEST(ARRAY["account_analytic_line"."account_id", "account_analytic_line"."x_plan2_id", "account_analytic_line"."x_plan3_id"])) AS "account_move_line.analytic_distribution", ...
            FROM account_analytic_line
            LEFT JOIN account_move_line
                ON account_analytic_line.move_line_id = account_move_line.id
            WHERE
                account_analytic_line.general_account_id IS NOT NULL;

            -- Create a supporting index to avoid seq.scans
            CREATE INDEX IF NOT EXISTS analytic_temp_account_move_line__composite_idx ON analytic_temp_account_move_line (analytic_distribution, journal_id, date, company_id);
            -- Update statistics for correct planning
            ANALYZE analytic_temp_account_move_line

```

A similar issue can be triggered if we add a manual field `x_plan2_id` to `account.move.line`:
```
ERROR: column reference "x_plan2_id" is ambiguous
LINE 10: ...nb(UNNEST(ARRAY[account_analytic_line.account_id, x_plan2_id...
```

Both issues are fixed here.

This was observed during upgrades. Mainly due to studio fields being generated with uppercase letters. Still, as shown above, it also fails for manual fields.

Forward-Port-Of: odoo/enterprise#73735

**Description of the issue/feature this PR addresses**:
Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final"  afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice.

The bug was introduced on this pr:
https://github.com/odoo/enterprise/pull/71562  --> The goal of this pr was to be able to create Factura B for a foreign customer. But prior to this pr the user was allowed to validate an invoice Factura B to a customer "Consumidor Final" without a country set on that customer, with  "DNI" identification type, with a vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487

**Video explaining the bug**:
https://drive.google.com/file/d/1Qb2oUtT26twjCI-pB6oMGMC9gZ6_EBSz/view

**Steps to reproduce**:

1) Log ing with admin user on runbot odoo enterprise 16 or 17 instance, activate developer mode and install l10n_ar_edi module.
2) Take position on company "Responsable Inscripto".
3) Create an electronic invoice "Factura B" for customer "Consumidor Final Anónimo" with an invoice line with quantity 1 and price 500000. Select electronic journal. The Partner doesn`t have country and has "dni" identification type, dni and "Consumidor final"  afip responsibility type.
![image](https://github.com/user-attachments/assets/ba3af345-f9df-49df-8a77-c1c651f5ad44)
![image](https://github.com/user-attachments/assets/acdb5021-42b5-4b7c-86ce-f1f7808e3197)

4) Validate the invoice and then you will receive this message:
![image](https://github.com/user-attachments/assets/ce3ef33b-ec85-4263-8eed-a05fd89b6d76)

**Current behavior before PR**:
It is not allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final"  afip responsibility type when the invoice has an amount higher than $344487.

**Desired behavior after PR is merged**:
It is allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final"  afip responsibility type when the invoice has an amount higher than $344487.

Ticket Adhoc side: 82498
Task latam side: 1283

Forward-Port-Of: odoo/enterprise#73200

**Steps to reproduce:**
- Install l10n_mx_reports
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Create an account:
  * Account Name: [any]
  * Code: 123456789
  * Type: Bank and Cash
- Go to "Accounting / Reporting / Audit Reports / Trial Balance"
- Download "COA SAT (XML)"
- Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx)

**Issue:**
The validation fails because the XML contains lines with incorrect or missing value for "CodAgrup" attribute.

**Cause:**
The "CodAgrup" in the "COA SAT (XML)" refers to the code of the account groups.
The accepted values are defined in the "Catálogo de Códigos Agrupadores" XSD file.
https://github.com/odoo/enterprise/blob/ecce698637dc2ef13dfdb27dfde303a7f1191aaf/l10n_mx_xml_polizas/data/xsd/1.3/CatalogosParaEsqContE.xsd#L4-L1086
The created account [123456789] is put in the root account group with code "1" and a line is added in the "COA SAT (XML)" with this value.
However, it is not an accepted value.

**Solution:**
From the account groups created automatically by MX localization, only the root account groups (i.e. with code "1", "2", "3",...) do not have a valid code for the "COA SAT (XML)".
These ones can be ignored.
This solution is not perfect as it is still possible to create an account group with an invalid code that is not a root account group.
However, handling this use case would require to check that each code is included in the set of valid codes (there is more than a thousand).

opw-4209089

Forward-Port-Of: odoo/enterprise#73647

Versions
--------
- saas-17.4+

Community PR: https://github.com/odoo/odoo/pull/186284

Steps
-----
1. Have Planning installed;
2. change localisation to 'en_GB' (or any whose weeks start on Monday);
3. open in Gantt view in weekly granularity;
4. go to the week of 2024-12-30.

Issue
-----
Label on top right displays "W1 2024";

Cause
-----
It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combines it with the `year` of the date, which is 2024.

Solution
--------
### Community:
- Like the `weeknumber` function added in https://github.com/odoo/odoo/commit/9c47e911d0ca707826d8907ae773aeb7484a270b to `odoo.tools.date_utils`, have a function in `web` that returns both year and week number.
- Remove the `getLocalWeekNumber` function in master, and replace usages with `getLocalYearAndWeek(date).week`.

### Enterprise:
- Define a `formatLocalWeekYear` function in `web_gantt` using the new `getLocalYearAndWeek` function from `web`.

opw-4280192

Forward-Port-Of: odoo/enterprise#73318

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system
Use case:
- In an MX Company with PAC Quadrum
- Enable currency USD
- Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148
- Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16%
- Confirm
- Make 2 partial payments of 100'000 MXN
- On the Invoice, click 'Update Payments'
- In the CFDI tab, on one of the payments, click 'Force CFDI'

Issue: Validation will fail with error
Note: This does not occur with other providers (Solucion Factibles)
```
Code : CRP20275
Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado,
convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto.
```

This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance

opw-4314798

Forward-Port-Of: odoo/enterprise#73772
Forward-Port-Of: odoo/enterprise#73696

Steps to reproduce:
- Install Attendances
- New employee > New Contract > Set a wage
- Set 'Work Entry Source' to 'Attendances'
- Payroll app > New Payslip > Compute Sheet
- Salary Computation tab > Basic salary = contract Wage

Steps to check salary configurator:
- Install Salary Configurator and Recruitment
- Recruitment > Any Job Position > New Application
- Generate Offer > Pick template > Configure your package
- Under 'Net Salary' click Details

The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure.

We can't just set it to 0 though:
This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0.

This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach.

opw-4266880

Forward-Port-Of: odoo/enterprise#73469

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Add a barcode to a different location that WH/Stock
- Go to the barcode > Operations > Internal Transfers > New
> The header propose to scan a product
- Do not scan the product by click on `+ ADD PRODUCT`
- Add 1 unit of your favorite product
> The header propose to scan a product or a destination location
- Scan the location you had set
#### > The location scan is ignored

### Cause of the issue:

During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions:
https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination.

opw-4201489

Forward-Port-Of: odoo/enterprise#73114
Forward-Port-Of: odoo/enterprise#72283

### API  Changes
1. **Dependencies**
   - Replaced `shared.method_name` with `dependencies.pluginName.methodName`
   - Plugin `name` property renamed `id` to avoid clashing with the global `name` property on classes. Values changed to camelCase.

2. **Commands**
   - Introduced "user commands" as a unified interface for commands that can be triggered by users (e.g. from the toolbar, powerbox and powerbuttons)
   - Standardized api for toolbar items, powerbox items, shortcuts, and power buttons
   - Removed `Plugin.dispatch` and `Plugin.handleCommand` methods
   - Introduced `dispatchTo` for event handling and `delegateTo` for overrides

3. **Resource Categorization**
    - handlers: functions that are called in response to an event (e.g. selectionchange_handlers)
  
    - overrides: functions that replace a default behavior (e.g.  paste_text_overrides)
   
     - predicates: functions that test a condition, returning boolean (e.g. unremovable_node_predicates)
  
    - providers: functions that supply data on demand (e.g. collaboration_peer_metadata_providers)
  
    - processors: composable functions that transform data (e.g. history_step_processors)
 
    - data (no suffix): not functions (e.g. system_classes)

task-4266746

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

Forward-Port-Of: odoo/enterprise#73500

TO REPRODUCE
===========
1. Create an appointment with users A and B
2. ...using 'no picture' and 'user then time'
3. go to front end
4. pick a date D both users have slots in
5. go to next month
6. change user in the dropdown (or change TZ)
7. slots appear for day D in previous month

ISSUE
=====

When selecting an other resource or user in the dropdown in resource_time mode, even if the selected one has no available slot for the current month, slots will appear in the slot list, corresponding to the first availability overall.

This leads to a very strange mismatch between the calendar dates and the slots. The user may select a slot and book for a month they do not currently see on the calendar.

SOLUTION
========

Now, we will select the previously selected date if it is in the current month and has slots. Otherwise we select the first day with slots in the currently displayed month (NOT overall). This way, the day is selected and displayed as so in the calendar. The slots match that day. If no availability exist for the current month, we do not click on any day, and show no slots.

Task-4169513

Forward-Port-Of: odoo/enterprise#73673
Forward-Port-Of: odoo/enterprise#71460