Before this commit: this.document.getSelection() can return null and causes traceback when accessing anchorNode at preserveSelection After this commit: ensure document selection is not empty --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202884

Before this commit: this.document.getSelection() can return null and causes traceback when accessing anchorNode at preserveSelection

After this commit: ensure document selection is not empty



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

Forward-Port-Of: odoo/odoo#202884

In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed. Steps to reproduce: - Have a Loyalty Program configured as follows: - Program Type: Loyalty Card - Grant 1 point per $ spent - Create a Loyalty card for [Partner] - Open POS Session - Add a [Partner] as customer - Add product - Leaving

In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed.

Steps to reproduce:
- Have a Loyalty Program configured as follows:
  - Program Type: Loyalty Card
  - Grant 1 point per $ spent
- Create a Loyalty card for [Partner]
- Open POS Session
- Add a [Partner] as customer
- Add product
- Leaving the order as it is, create a new order
- Add just a product
- Validate & Pay the second order

Issue: Loyalty points will be added to [Partner] Card, as if the order was actually paid

This occurs because we don't check that the order has been actually paid before processing rewards

opw-4538040

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#202298
Forward-Port-Of: odoo/odoo#199108

Description of the issue this commit addresses: When registering a SEPA payment, it is possible to get a UserError telling you to validate therecipient bank account while it is validated. --- Steps to reproduce: 1. Install account. 2. Activate SEPA Credit Transfer (SCT) in the settings. 3. On the Bank journal's settings, input an account number. 4. Make sure the accounts used for the transfer authorize sending money. 5. Create a move in the misc journal with multiple lines and d

Description of the issue this commit addresses:

When registering a SEPA payment, it is possible to get a UserError telling you
to validate therecipient bank account while it is validated.

---

Steps to reproduce:

1. Install account.
2. Activate SEPA Credit Transfer (SCT) in the settings.
3. On the Bank journal's settings, input an account number.
4. Make sure the accounts used for the transfer authorize sending money.
5. Create a move in the misc journal with multiple lines and distinct partners.
6. Post the move. Go in the journal entries. Select it. "Register Payment".
7. Change the Payment Method for SEPA Credit Transfer. "Create Payments".
8. A UserError shows up.

---

Desired behavior after this commit is merged:

No UserError shows up, the payments are created.

---

Note on the fix:

The error happened because one of the condition for raising the UserError is a
value of a record in a many2one relation which is a stored computed field. As
the payment is created with a list of values, the compute method is not
triggered and the many2one remains empty while it should not.

This fix makes sure the partner_bank_id is only put in the payment values once
it has been computed to avoid keeping it false.

---

opw-4518374

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

Forward-Port-Of: odoo/odoo#203003
Forward-Port-Of: odoo/odoo#201608

Before this commit, when doing the reconciliation of a statement line with an invoice without a journal entry, we were trying to find a matching payment for that statement line and setting it as paid. However, it didn't do the opposite when breaking the matching between the invoice and the statement line. This commit adds that opposite behavior. Forward-Port-Of: odoo/odoo#202692

Before this commit, when doing the reconciliation of a statement line with an invoice without a journal entry, we were trying to find a matching payment for that statement line and setting it as paid. However, it didn't do the opposite when breaking the matching between the invoice and the statement line.

This commit adds that opposite behavior.

Forward-Port-Of: odoo/odoo#202692

### Steps to reproduce: - Create a new draft invoice - In the actions click "PDF without Payment" - In the PDF the name is "Draft Invoice INV/2023/0001" - It should only be "Draft Invoice" ### Cause: "INV/2023/0001" is the placeholders in the XML. It is displayed because the name for draft moves is no longer '/' but null. ### Solution: Change the condition to also check if `o.name` exists. opw-4607518 Forward-Port-Of: odoo/odoo#202676

### Steps to reproduce:
- Create a new draft invoice
- In the actions click "PDF without Payment"
- In the PDF the name is "Draft Invoice INV/2023/0001"
- It should only be "Draft Invoice"

### Cause:
"INV/2023/0001" is the placeholders in the XML. It is displayed because the name for draft moves is no longer '/' but null.

### Solution:
Change the condition to also check if `o.name` exists.

opw-4607518

Forward-Port-Of: odoo/odoo#202676

This commit adds Canary Island CoA from OCA's l10n_es_igic module. The initial migration was done using the script from: `https://github.com/william-andre/transform_coa` Along that, we also applied few more things: - use the english translations in `name` and moved the spanish names in `name@es` - added auto-apply on canary's fiscal position based on zip codes - adapt `-100` taxes on some of the taxes in canary - refactored the template flow From now on, the flow of the template d

This commit adds Canary Island CoA from OCA's l10n_es_igic module.

The initial migration was done using the script from: `https://github.com/william-andre/transform_coa`

Along that, we also applied few more things:

- use the english translations in `name` and moved the spanish names in `name@es`
- added auto-apply on canary's fiscal position based on zip codes
- adapt `-100` taxes on some of the taxes in canary
- refactored the template flow

From now on, the flow of the template dependencies will be like the following:

```
  es_canary_common       es_common_mainland
        |                   |
(canary-assoc/full/pymes)  (assec/full/pymes/coop_pymes)
```

task-id: 3354514

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#195864

When picking type is changed, the locations on the moves should also be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181769

When picking type is changed, the locations on the moves should also be updated.

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

Forward-Port-Of: odoo/odoo#181769

Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500 Forward-Port-Of: odoo/enterpris

Even though it's been commonplace in Odoo for a while,
tags (or more precisely facets) with index-0/False color where still shown
on Documents kanban cards.

This should remain the case functionally as users are not expected to
go and change the color of all their tags, nor can we decide for them
at upgrade (and it'd be too late for many as well).

Task-4645015

Also, cleaning up some test stuff for hoot. See details in individual commits.
Task-3861500

Forward-Port-Of: odoo/enterprise#76201

Some datasource functionalities (i.e. insert PIVOT and LIST) create a new sheet based on the source name. Unfortunately, sheet names cannot contain some predefined characters (mostly for excel compatibility purpose). This revision adds a sanitization of the source name before creating the sheet. task-4347719 Forward-Port-Of: odoo/enterprise#81844 Forward-Port-Of: odoo/enterprise#74313

Some datasource functionalities (i.e. insert PIVOT and LIST) create a new sheet based on the source name. Unfortunately, sheet names cannot contain some predefined characters (mostly for excel compatibility purpose).
This revision adds a sanitization of the source name before creating the sheet.

task-4347719

Forward-Port-Of: odoo/enterprise#81844
Forward-Port-Of: odoo/enterprise#74313

Test that resetting a statement line that was merged with a batch payment also resets the payments, especially for payments without an outstanding account. It wasn't the case because there is no real link between the batch payment and the statement line, and neither between the statement line and the payment itself. The fix is in community. Forward-Port-Of: odoo/enterprise#81839

Test that resetting a statement line that was merged with a batch payment also resets the payments, especially for payments without an outstanding account.
It wasn't the case because there is no real link between the batch payment and the statement line, and neither between the statement line and the payment itself.

The fix is in community.

Forward-Port-Of: odoo/enterprise#81839

The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122 Forward-Port-Of: odoo/enterprise#81369

The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals.

Ticket - 4606122

Forward-Port-Of: odoo/enterprise#81369