Adds a configuration option to limit how many work order cards are shown on the shop floor display. This helps teams keep the screen focused and easier to manage when many manufacturing orders are active.

…e shop floor

Adds a configurable limit for how many work order cards appear on the shop floor display. This helps manufacturing teams keep the screen manageable and focused, improving usability when many work orders are available.

…e shop floor

A new manufacturing setting lets teams limit how many work order cards are shown on the shop floor screen. This helps keep the display manageable and focused for operators, especially in busier production environments.

…e shop floor

Amazon customer alias emails are now saved directly on the customer's primary contact email. This helps Odoo processes that rely on the standard contact email, such as shipping and customer communication, work more consistently.

This commit set amazon alias directly on customer's main contact
email instead create field to store that email on contact. This
will ensure flow that are related to contact's email like
shipping address and other where email on contact is required.

task-3877861

A new shop floor setting lets manufacturers control how many work order cards are shown at once. This helps teams keep the screen focused and easier to use when many manufacturing orders are active.

…e shop floor

This update fixes how the Master Production Schedule handles ordering limits and lead times across different planning periods. It helps avoid misleading replenishment quantities, such as applying a monthly cap to a yearly view, and improves demand forecasts for components with lead times.

This PR contains the following commits:
- [IMP] mrp_mps: hide Order buttons in non-default periods
When the date type shown (year, month, week, day) is different from the one
defined in the settings, we hide the order buttons.
- [FIX] mrp_mps: disable max_to_replenish_qty in non-default period
`max_to_replenish_qty` should only be applied for the period defined in the settings.
Otherwise we have situation where a limit of 15 per month is applied for a whole year.
- [FIX] mrp_mps: use real dates with lead times
When a bom has a lead time, we want to use the real date to compute the
indirect demand forecast of the components in the MPS.

task 4172967

Point of Sale preparation now uses product templates as the main product card, reducing limitations around variants, attributes, and pricing. This lays the groundwork for better performance and more flexible product management in PoS workflows.

Historically, the point of sale module used the product.product model to
represent products cards in PoS. A workaround has been done to handle
variants, attributes and pricelist.

Now the fact that we miss the product.template model in the PoS module
is a blocker for the future of the PoS module. Causing a lot of
performance issues and limitations.

This commit replace the use of product.product as product card by the
product.template model. This will allow us to use the product.template
with pricelist, attributes, variants and other features.

The old product.product models has been proxied to the product.template
each variable that isn't on the product.product model will be taken from
the product.template model.

taskId: 4134659

Related to https://github.com/odoo/odoo/pull/182438 Since this fix, we make an extra query per batch, so we need to adapt the query count of `test_recurring_order_creation_perf` opw-4072691 Forward-Port-Of: odoo/enterprise#72019 Forward-Port-Of: odoo/enterprise#71903

Related to https://github.com/odoo/odoo/pull/182438
Since this fix, we make an extra query per batch, so
we need to adapt the query count of
`test_recurring_order_creation_perf`

opw-4072691

Forward-Port-Of: odoo/enterprise#72019
Forward-Port-Of: odoo/enterprise#71903

We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2]. This key is used to find an already existing tax, and creates it if it doesn't yet exist. _constrains_name() of account.tax however, doesn't consider the description field. This means that two taxes with the same name (e.g. CA STATE 6%) and different jurisdiction codes (e.g. 001 and 013) cause iss

We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2]. This key is used to find an already existing tax, and creates it if it doesn't yet exist.

_constrains_name() of account.tax however, doesn't consider the description field. This means that two taxes with the same name (e.g. CA STATE 6%) and different jurisdiction codes (e.g. 001 and 013) cause issues. The first one will be created as normal. When the second one is processed it will fail to find a match because the description is different, so Odoo will create a second one resulting in a constraint error.

To resolve this, stop adding the jurisdiction code and stop looking at the description all together. In the end it's not critical information that needs to be in Odoo. For tax details the user already relies on the Avalara portal anyway.

[1] https://github.com/odoo/enterprise/pull/68549
[2] State assigned code identifying the jurisdiction. Note that this is not necessarily a unique identifier of the jurisdiction.

Forward-Port-Of: odoo/enterprise#70980

There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#71825 Forward-Port-Of: odoo/enterprise#69973

There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company.

If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees.

task-4167727

Forward-Port-Of: odoo/enterprise#71825
Forward-Port-Of: odoo/enterprise#69973

Before this commit, posting any tax closing would always set the tax lock date. This was a bit restrictive, and required making lock date exceptions in order to post operations for other non-closed reports. We alleviate that by only setting the tax lock date when the domestic closing is posted ; the idea being it's the main one. So, tax closings posted for other countries for which a foreign VAT fiscal position is defined do not affect the tax lock date anymore. Forward-Port-Of: odoo/enterprise

Before this commit, posting any tax closing would always set the tax lock date. This was a bit restrictive, and required making lock date exceptions in order to post operations for other non-closed reports. We alleviate that by only setting the tax lock date when the domestic closing is posted ; the idea being it's the main one. So, tax closings posted for other countries for which a foreign VAT fiscal position is defined do not affect the tax lock date anymore.

Forward-Port-Of: odoo/enterprise#71896

Steps --- * Create a candidate * Give them a skill * *Create Employee* * => Traceback -> "Two levels for the same skill is not allowed" Cause --- * on `hr.employee.skill` we have a unique constraint on the skill employee pair * but when creating an employee we would attepmt to create the skills twice, once through regualr create and once from the override of `_update_employee_from_candidate` call in the write Fix --- Remove the `_update_employee_from_candidate` method, which seem

Steps
---
* Create a candidate
* Give them a skill
* *Create Employee*
* => Traceback -> "Two levels for the same skill is not allowed"

Cause
---
* on `hr.employee.skill` we have a unique constraint on the skill employee pair
* but when creating an employee we would attepmt to create the skills twice, once through regualr create and once from the override of `_update_employee_from_candidate` call in the write

Fix
---
Remove the `_update_employee_from_candidate` method, which seems unnecessary.

task-4207776

Forward-Port-Of: odoo/enterprise#71672

Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invo

Issue:
The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx).

Step to reproduce the issue:
- Go to the Accounting app --› Customer invoices journal --› Create a new invoice.
- Select a customer with the Spanish (MX) / Español (MX) language set.
- Select any product from the inventory catalog.
- Set the Uso (l10n_mx_edi_usage) as "Gastos en general".
- Confirm the invoice.
- Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again.
- The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX).

Cause of the issue:
The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py.

opw-4212069

Forward-Port-Of: odoo/enterprise#71344

Adapt the layout of the account sepa direct debit report to make it fit on a single page. task-4183056 Forward-Port-Of: odoo/enterprise#71570

Adapt the layout of the account sepa direct debit report to make it fit on a single page.

task-4183056

Forward-Port-Of: odoo/enterprise#71570

Steps to Reproduce: 1. Select a document 2. validate document 3. click on validate again 4. Traceback thrown Technical Reason: Instead of raising a UserError, it throws a ValueError when evaluating directly '_()' in the XML file without using the 'env' context. After this commit: An invalid operation dialog will open with the message 'Impossible to validate twice'. Task-4228827 Forward-Port-Of: odoo/enterprise#71342

Steps to Reproduce:
1. Select a document
2. validate document
3. click on validate again
4. Traceback thrown

Technical Reason:
Instead of raising a UserError, it throws a ValueError when evaluating directly '_()' in the XML file without using the 'env' context.

After this commit:
An invalid operation dialog will open with the message 'Impossible to validate twice'.

Task-4228827

Forward-Port-Of: odoo/enterprise#71342

The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844

The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field.

There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records.

To reproduce:
- Install `l10n_hk_hr_payroll` with demo data
- Upgrade the module

Forward-Port-Of: odoo/enterprise#71844

### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info. ### Steps to reproduce 1. Open runbot install AR and UY modules 2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000 ### Before the PR W

### Description

When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info.

### Steps to reproduce

1. Open runbot install AR and UY modules
2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000

### Before the PR

We receive a traceback error

```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1783, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1810, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 2014, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/data/build/adhoc-cicd-odoo-odoo/addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/addons/base/models/ir_http.py", line 226, in _dispatch
    result = endpoint(**request.params)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 759, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 28, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 468, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 732, in action_send_and_print
    return self._process_send_and_print(
  File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 666, in _process_send_and_print
    self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
  File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 572, in _generate_invoice_documents
    self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
  File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/wizards/account_move_send.py", line 59, in _hook_invoice_document_before_pdf_report_render
    if errors := invoice._l10n_uy_edi_check_move():
  File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/models/account_move.py", line 502, in _l10n_uy_edi_check_move
    dtype=self.partner_id.l10n_latam_document_type_id.name))
AttributeError: 'res.partner' object has no attribute 'l10n_latam_document_type_id'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2891:163)
        at XMLHttpRequest.<anonymous> (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2895:13)
```
This happens because the document type is related to the invoice, the partner actually has identification type field.

### After the PR

Now it shows the proper message telling the message the problem related to the partner configuration so they can fix it before sending EDI invoice

![image](https://github.com/user-attachments/assets/53d357d1-f598-40b1-be06-e89e1d8f0758)


Reference: LATAM 1275 / ADHOC TICKET 81219

Forward-Port-Of: odoo/enterprise#71416

After this commit: https://github.com/odoo/odoo/commit/37b35f18bd9138a9a8717d17268f375607b9482e Some attributes were useless in the registry of the tour. They have been deleted. TASK-ID: 4070659 Forward-Port-Of: odoo/enterprise#71519

After this commit: https://github.com/odoo/odoo/commit/37b35f18bd9138a9a8717d17268f375607b9482e Some attributes were useless in the registry of the tour. They have been deleted.

TASK-ID: 4070659

Forward-Port-Of: odoo/enterprise#71519

### Steps to reproduce the issue: 1. Create a Purchase Order and add Analytic Distribution to one of the Product Lines 2. Make sure the "Budget" Smart Button is visible 3. Create a User with no Accounting access rights and maximum Purchase access rights 4. With Purchase User, open the Purchase Order 5. Receive following Access Error: > You are not allowed to access 'Budget' (budget.analytic) records. > > This operation is allowed for the following groups: > - Accounting

### Steps to reproduce the issue:

1. Create a Purchase Order and add Analytic Distribution to one of the Product Lines
2. Make sure the "Budget" Smart Button is visible
3. Create a User with no Accounting access rights and maximum Purchase access rights
4. With Purchase User, open the Purchase Order
5. Receive following Access Error:

>     You are not allowed to access 'Budget' (budget.analytic) records.
>
>     This operation is allowed for the following groups:
>     	- Accounting/Bookkeeper
>     	- Accounting/Read-only

### Explanation:

When accessing `purchase.order`, a list of computes starting with `purchase.order._compute_above_budget` will cause the user to perform a `search` on `budget.line`, which he does not have access to without `account.group_account_readonly` or higher.

### Fix reasoning:

Since the user will only perform a `search`, `sudo` is all indicated to bypass the Access Rights restriction.

opw-4244187

Forward-Port-Of: odoo/enterprise#71576

Forward-Port-Of: odoo/enterprise#71652

Forward-Port-Of: odoo/enterprise#71652

Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980

Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super().

Forward-Port-Of: odoo/enterprise#71980

Adapt to community PR, which add a context key requirement in order to delete an analytic item related to a journal item. Community PR: odoo/odoo#182608 task-3977961 Forward-Port-Of: odoo/enterprise#71378

Adapt to community PR, which add a context key requirement in order to delete an analytic item related to a journal item.

Community PR: odoo/odoo#182608

task-3977961

Forward-Port-Of: odoo/enterprise#71378

Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks

Steps to reproduce:
- Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting
- Timesheets app > Start timer
- Set your helpdesk project and any task (Do not add a description)
- Stop timer > Do it again with same the project and a different task
- Stop timer > Time is added to previous timesheet

The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks' are instead recorded in the 'helpdesk_ticket_id'. Since it is forbidden for a timesheet to have both a 'task_id' and 'helpdesk_ticket_id', it is guaranteed that task_id will be False for both of our entries, leading to a merge. Similarily we can use that property since adding helpdesk_ticket_id to the domain won't change the usual behavior (the field will always be False if the project is not from Helpdesk) to add an extra condition here. Source: we have a contraint '_check_no_link_task_and_ticket' which ensures that.

opw-4203678

Forward-Port-Of: odoo/enterprise#71968
Forward-Port-Of: odoo/enterprise#71784

Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710

Adding some new accounts in the reports

task: 4210069

Forward-Port-Of: odoo/enterprise#70710

In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71743 Forward-Port-Of: odoo/enterprise#71682

In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the
backend nonfunctional.

This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue.

Forward-Port-Of: odoo/enterprise#71743
Forward-Port-Of: odoo/enterprise#71682

### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: o

### Steps to reproduce the issue:

1. In Mexican Company, create an Invoice elligible for CFDI
2. Send & Print
3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same

### Explanation:

In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello`

### Fix reasoning:

Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values

opw-4227743

Forward-Port-Of: odoo/enterprise#71463

Open General Ledger Search for a non existing account/aline (ex. "1111111111111") Issue: All lines are shown This occurs because we update matched lines only if there is a match, otherwise we reset the filter opw-4160605 Forward-Port-Of: odoo/enterprise#69424

Open General Ledger
Search for a non existing account/aline (ex. "1111111111111")

Issue: All lines are shown
This occurs because we update matched lines only if there is a match, otherwise we reset the filter

opw-4160605

Forward-Port-Of: odoo/enterprise#69424

Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71973 Forward-Port-Of: odoo/enterprise#71641

Steps:
- Install rental app.
- Goto rental settings.
- Create product from extra fees product

Issue:
- Consumable type product is creating is should be service product.

Cause:
- No context to set default values for detailed_type field.

Fix:
- Added context `default_detailed_type: service` to create service type product.

opw-4142551

Forward-Port-Of: odoo/enterprise#71973
Forward-Port-Of: odoo/enterprise#71641

In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012

In this PR:
- Updated the matching criteria for GSTR2B late bills to use the specific month
of the bill date.
- Replaced previous date filter on `invoice_date` to limit searches to the start
and end of the bill's month.
- Ensured accurate retrieval of bills by filtering based on the bill number and
company.

This change enhances the precision of bill matching in the GSTR2B late bill
streamline process.

Forward-Port-Of: odoo/enterprise#72012