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

*: planning_field_service, project_enterprise, stock_fleet_enterprise, web_studio

This commit acts as a follow-up to https://github.com/odoo/enterprise/pull/104618, heavily improving the map view's routing capabilities and pin list UI:

**Routing & Optimization:**
* **Automated Routing:** Manual record resequencing has been completely removed. Routing now utilizes the Mapbox Optimization API to automatically calculate the most efficient point-to-point route, including a return to the starting point.
* **Dynamic Starting Point:** Added a new input for the starting (and returning) address. It uses the Mapbox or OpenStreetMap API for autocomplete and coordinate fetching. It defaults to the user's location (if available) or falls back to the active company's address. A toggler allows users to quickly reset to their location or clear the input.

**Pin List & UI Improvements:**
* **Unlocated Records:** Records without coordinates are now isolated in a dedicated group and can be clicked to open their form view directly.
* **Empty Groups:** Groups containing only unlocated records are no longer displayed in the pin list to reduce clutter.
* **Formatting:** The route duration tooltip now uses the latest duration formatter for a cleaner display.

task-5930464

## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896

## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.

## Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

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

Issue
-----
Orders created through the MPS aren't grouped in a single RFQ.

Steps to reproduce
-----
- Create a product with a vendor
- Add it to the MPS with the buy route
- Change the forecast to 2
- Order
- Change the forecast to 5
- Order
- Go to RFQs

> There are 2 different RFQs

Cause
-----
When doing `_run_buy`, no existing PO is found

https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102

so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15

However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB.

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10

This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime.

-----
Ticket:
opw-5171041

Forward-Port-Of: odoo/enterprise#110068
Forward-Port-Of: odoo/enterprise#106968

Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error

The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.

This commit improves error handling for both public and internal AI chat
by:

- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.

The following behavior will now be observed during error in the UI.

- Public AI chat:
  - Initial fetch failed: shows "oops" message
  - Stream interrupted:
    - Server handled: shows "oops" message
    - Server stopped: shows "Connection Interrupted" dialog

- Internal AI chat:
  - Initial fetch failed: show RPCError dialog
  - Stream interrupted:
    - Server handled: shows RPCError dialog
    - Server stopped: shows "Connection Interrupted" dialog

We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.

TASK-ID: 5886825

Forward-Port-Of: odoo/enterprise#110478
Forward-Port-Of: odoo/enterprise#105875

**Problem:**
When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.

**Steps to reproduce:**
1. Go to Settings app and enable debug mode
2. Navigate to Technical → Reports
3. Search for "slot_report"
4. Click "Add to print menu" button
5. Refresh the browser
6. Go to Planning app and switch to list view
7. Select a few planning.slot records
8. Click Print → Planning

**Current behavior:**
A blank or invalid PDF is generated.

**Expected behavior:**
Users should receive a clear error message directing them to use the correct print method from the calendar view.

**Cause of the issue:**
The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports.

**Fix:**
Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data.

opw-5477184

Forward-Port-Of: odoo/enterprise#108772
Forward-Port-Of: odoo/enterprise#105168