### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#102495
Forward-Port-Of: odoo/enterprise#96007

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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

Forward-Port-Of: odoo/odoo#237599

revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like

even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL:  Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```

due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files

so we need to avoid to fetch archived warehouse's picking type.

ref:
odoo/upgrade#6631

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#191652
Forward-Port-Of: odoo/odoo#185244

Follow-up of https://github.com/odoo/odoo/issues/239537

PR Above improve style of category title. One of the change is reduce opacity of title when not hovered.

The chevron icon was not taken into account, which makes the category title line more visible than intended.

This commit put same condition to reduce opacity of category title when not mouse-hovering on the chevron icon.

Before / After
<img width="297" height="854" alt="Screenshot 2025-12-18 at 15 59 43" src="https://github.com/user-attachments/assets/90e9c49f-7105-4f35-965c-0be5c5822a39" /> <img width="297" height="853" alt="Screenshot 2025-12-18 at 15 58 59" src="https://github.com/user-attachments/assets/65246008-b5b8-4d94-b095-544c99e1e3aa" />


<img width="304" height="858" alt="Screenshot 2025-12-18 at 16 00 30" src="https://github.com/user-attachments/assets/9c5bdaac-b113-45f3-9bd6-fb9171eaa260" /> <img width="300" height="858" alt="Screenshot 2025-12-18 at 16 00 51" src="https://github.com/user-attachments/assets/47f26fe0-bdb4-45f8-af2d-125dfe72f59a" />

Commit 8f3e242e197b2f26982749 added an Etag to reduce the load on the network when loading a spreadsheet.

Now, this commit ensures the Etag is computed as fast as possible to also reduce the load on the server.

The Etag is based on the latest revision (field `current_revision_uuid`). When computing `current_revision_uuid`, we look at the lastest revisions. However, the current code only look at *active* revisions, and fallback on the snapshot.
The snapshot is a json file (potentially large) that needs be parsed. This is not fast.

To make it worse: spreadsheets are snapshotted as often as it can be, which means we almost always fall in the slow path when computing the Etag.

With this commit, we consider all revisions (active or not). We also load in memory only the latest instead of fetching multiple revisions for each spreadsheet (the work is done by postgres through `_read_group`)

On a spreadsheet with a snapshot of 9.8MB, server time
`"GET /spreadsheet/data/documents.document/17 HTTP/1.1" 304`

before: ~310ms
after:    ~5ms


Task-5431940

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#101919
Forward-Port-Of: odoo/enterprise#95111

When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions.

### Steps
1. Create a new Company with country Uruguay
2. Change current logged company to new Company
3. Change the currency to USD
4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank
5. Click manual synchronization
6. Check rates  

### Current behavior before PR

All currencies except UYU currency has created taxes with date today.
Only one error in UYU currency that is created with yesterday rate
![image](https://github.com/user-attachments/assets/adfdf9a1-f0cf-4825-bfe4-47ff5c8da2c4)

### Desired behavior after PR is merged:

All the currencies are created with the same date, the correct day that is today rate.

References: LATAM 1341 / ADHOC Task 51716

Forward-Port-Of: odoo/enterprise#85065

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#96007

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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

Forward-Port-Of: odoo/odoo#237599

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041

Forward-Port-Of: odoo/odoo#239770
Forward-Port-Of: odoo/odoo#235356

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#96007

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

[this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102219

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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

Forward-Port-Of: odoo/odoo#237599

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages,
but the server correctly rejects their unpin requests. This creates confusion
and a poor user experience where external users see functionality that doesn't
work for them.

**Current behavior before PR:**
----------------------------------------------
- Guest users see the unpin button on pinned messages
- Clicking the unpin button results in server rejection
- UI shows functionality that guest users cannot actually use

**Desired behavior after PR is merged:**
----------------------------------------------
- Guest users cannot see the unpin button on pinned messages
- Internal users continue to have full pin/unpin functionality
- UI accurately reflects user permissions and capabilities
- Better user experience with appropriate access control

Task-5033295

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

Forward-Port-Of: odoo/odoo#240640
Forward-Port-Of: odoo/odoo#229211

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#96007

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

[this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102219

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#102495
Forward-Port-Of: odoo/enterprise#96007

Purpose:
--------
- It should be easier to visualize maintenance requests than what is possible today. The calendar view is useful but does not provide a comprehensive overview of all equipment or work centers, nor the ability to plan interventions easily.
- It should be much easier to perform maintenance directly from an equipment or work center, instead of creating a maintenance request manually.
- It should also be easy to quickly visualize which equipment is currently undergoing maintenance and update their status once the maintenance is completed.

With this commit:
-----------------
- Makes maintenance planning more easier to manage by adding gantt view by equipment/workcenter.
- Replaced the `Maintenance Calendar` menu with `Planning by Equipment` and `Planning by Workcenter`, providing a more practical way to plan maintenance requests by resources rather than relying on the calendar view.
- Allows creating maintenance requests directly from equipment or work center views, reducing manual effort.
- Prevents scheduling conflicts by showing unavailable workcenter intervals due to workorders or non-working hours.
- Removes the `Request Date` field from maintenance requests as it is redundant with `Scheduled Date`; `Scheduled Date` more accurately reflects the intended start of the maintenance request, whereas `Request Date` only indicates when the request was created.
- The Gantt view defaults to filtering records for the respective workcenter/equipment by `Todo` and `Active`, excluding `Done` and `Archived` maintenance requests, to focus on the remaining active requests.
- It also makes other views (e.g., Kanban, List, Pivot, etc.) of Maintenance Requests available alongside the Gantt view
under `Planning by Equipment` or `Planning by Workcenter`, with the default grouping by equipment or workcenter respectively.
- Improve planning by adding a Plan Popup for unscheduled maintenance requests. It is especially useful when maintenance planners have created requests but are not yet sure when they should be scheduled.
- The Plan Popup applies default `Todo` and `Active` filters to prevent accidental planning of cancelled or already repaired requests.

task-4698325

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#101919
Forward-Port-Of: odoo/enterprise#95111

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

Forward-Port-Of: odoo/enterprise#96007

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#101804
Forward-Port-Of: odoo/enterprise#93034

**Issue:**
Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries

**Cause:**
`_get_worked_day_lines()`  skips worked day computation if the contract has no calendar

https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674

**Steps to Reproduce:**
- Assign an employee a fully flexible contract with attendance as work entry source.
- Create work entries based on the attendance records of the employee record
- Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top.

**Fix:**
removing the calendar requirement in the main method and adding a fallback calendar in the called utility method

**Note:** same issue happens if work entry source of the contract is Planning

opw-4931972

Forward-Port-Of: odoo/enterprise#98194
Forward-Port-Of: odoo/enterprise#93935

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


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

Forward-Port-Of: odoo/odoo#237599

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Behavior before:
Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the
gross paid for certain vendors. Some payment lines were excluded from the SQL query,
leading to discrepancies in the report.

Behavior after:
The SQL query has been updated to include all relevant payment lines, including those in
asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the
TPAR report to be exported without errors.

Root Cause:
The previous query only considered asset_current and liability_current accounts, ignoring
asset_cash accounts. This omission caused the gross paid amount to be understated relative to
the total GST paid.

Steps to Reproduce:

1. Create a vendor bill.

2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal).

3. Create a bank statement line for the bill amount.

4. Validate the statement line with the corresponding invoice line.

5. Generate the TPAR report — the payment amount should now be correctly included.

OPW: 5148697

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349