In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store.

This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation.

Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents).

task-4038651

Forward-Port-Of: odoo/enterprise#78742

Description of the issue:

Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key.

Solution:

Define localOverlayContainers and its corresponding key in studio’s wysiwyg config.
Additionally, adjust the table menu position calculation when the table cell is inside an iframe.
Also Before localOverlayContainers was not defined in studio, so power buttons did
not appear in studio reports. Now that localOverlayContainers is defined,
power buttons must be excluded from the main plugin to prevent them from
appearing inside studio.
Community PR: https://github.com/odoo/odoo/pull/250503

Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724

Forward-Port-Of: odoo/enterprise#109506
Forward-Port-Of: odoo/enterprise#109012

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#110657
Forward-Port-Of: odoo/enterprise#107424

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

**Steps to reproduce:**
- Install Accounting

- From a Bank journal, create a transaction with an amount of -1000
- Set Account to "Liquidity Transfer"
- From a Cash journal, create a transaction with an amount of 999.99
- Set Account to "Liquidity Transfer"
- Create a MISC entry:

  |       Account        | Debit | Credit |
  | -------------------- | ----- | ------ |
  |  Liquidity Transfer  |  0.00 |  0.01  |
  | Cash Difference Gain |  0.01 |  0.00  |

- Post the entry

- From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them

- Go back to the Bank journal and try to edit the previous transaction

**Issue:**
A traceback is raised.

**Cause:**
In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved.
A single line is expected and some operations that are only allowed on a singleton are performed.
In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition.

**Solution:**
The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line.
Therefore, the computation can be skipped in such a case.

opw-6031879

Forward-Port-Of: odoo/enterprise#110857

To reproduce the issue, on a large db:
- Open the form view of a res.partner
- Click on the "Due" smart button, to open the Followup Report

==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out.

This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field.

While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime.

# Description of the issue/feature this PR addresses

In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders.
In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag.

From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. 
As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders.

# Current behavior before PR

With ZATCA enabled on saas-18.2:

- Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account.
- Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines.
- This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported.
- Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported.

# Desired behavior after PR is merged

After this fix:

- ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag.
- Even if invoice is checked, the invoice is not sent to ZATCA
- Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing.
- Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting.

This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2.

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

Forward-Port-Of: odoo/odoo#252984
Forward-Port-Of: odoo/odoo#244712

Currently an exception is generated when the user tries to submit
a job application through the form.

Steps to produce an error:
- Install the `web_studio` and `website_hr_recruitment` modules
- Add a new File field to the `hr.applicant` module with the studio.
- Go to the website editor and add the form `Apply for a Job` and
  add the recently created field into the form and save it
- An error will occur when submitting the form with the added field

Error: `KeyError: 'manual'`

This issue occurs because the `manual` key(attribute) is not included in the
`authorized_fields` variable, which is generated by the `get_authorized_fields`
method. After the recent refactoring introduced in commit [1], the code
was changed to fetch only a limited set of attributes instead of all attributes,
and the manual attribute was not added to this list.

This commit resolves the above issue by including the `manual` attribute when
retrieving model fields, which was not added in commit [1].

[1]: https://github.com/odoo/odoo/commit/bfae7140d3951bec93fb7f2e49018649045edd40

Sentry-7271118700
opw-5933992

**Description:**

In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.

This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.

**To fix the issue**

the code now handles multiple expenses instead of assuming a singleton.

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
    'name': self.expense_ids.name,
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```

opw-5494047
upg-3974547

[^1]: https://github.com/odoo/odoo/pull/189701

Forward-Port-Of: odoo/odoo#254167

Currently, submitting a website form that creates a task crash for portal users on the confirmation page.

### **Steps to reproduce:**
1) Install website_project with demo data
2) Create a website form that creates a task
3) Set a project on the form
4) Submit the form as a portal user

### **Error:**
`AccessError: You do not have enough rights to access the field project_privacy_visibility on Task (project.task)`

### **Root Cause:**
The confirmation template evaluates `task.project_privacy_visibility` in a t-if condition at [1].

since [commit](https://github.com/odoo/odoo/pull/203891/changes/17664b3f118491f954dd6a810521ce5865d51a43), project task restricts portal users to a whitelist of fields defined by [_portal_accessible_fields()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1015-L1019). Field access is then validated in [_has_field_access()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1021-L1031), which denies read access to fields not present in this whitelist.

`project_privacy_visibility` is not part of the portal readable fields list. When the template tries to read it, _has_field_access() rejects the operation and raises an AccessError.

[1]- https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/website_project/views/project_portal_project_task_template.xml#L13-L16

### **Fix:**
Use `sudo()` when reading `project_privacy_visibility` in the template to avoid the portal field access restriction.

**opw-6010622**

Forward-Port-Of: odoo/odoo#254326
Forward-Port-Of: odoo/odoo#254099

- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.

```sql

Traceback (most recent call last):
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
    delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
    delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
 MemoryError

(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682

Lot_id 11412: delivery_by_lot size = 7420, parents = 3

Lot_id 11753: delivery_by_lot size = 0, parents = 7

Lot_id 12845: delivery_by_lot size = 11, parents = 5

Lot_id 14646: delivery_by_lot size = 12, parents = 2

Lot_id 15801: delivery_by_lot size = 1700, parents = 3

Lot_id 19817: delivery_by_lot size = 0, parents = 4

Lot_id 22370: delivery_by_lot size = 0, parents = 1

Lot_id 25072: delivery_by_lot size = 6827, parents = 2

Lot_id 25134: delivery_by_lot size = 3, parents = 2

Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones

UPG - 3869661
OPW - 5900313

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

Forward-Port-Of: odoo/odoo#248826

# How to reproduce
- Create a BOM for a product
- Create a MO for a set quantity (Exemple: 1) for that product
- Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3)
- Confirm the unbuild
- Go to the stock moves of that unbuild via the smart button

# The problem
3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated

# Why
The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves.

When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected.

This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'.

opw-5915981

opw-5449109

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

Forward-Port-Of: odoo/odoo#254016
Forward-Port-Of: odoo/odoo#248056