RATIONALE

In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.

SPECIFICATIONS

Add some tests improve coverage of synchronization, as we recently
discovered limitations

  * "opposite" triggers when checking brother traces to skip in
    'action_update_participants' (which synchronizes traces): sub
    addons (sms, whatsapp) is not taken into account;
  * 'schedule_date' is not correct for user-based activities (e.g.
    mail_open, mail_click, ...) when new activities are added to
    a campaign. They should not have scheduled dates, as it depends
    on user action. Date is correct for activities when participants
    enter child activities but not when doing the synchronize;
  * add some checks on participant state;
  * globally try to improve some corner cases coverage;

Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.

Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.

Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.

Task-4224152: [marketing_automation] Performance / Scalability

Forward-Port-Of: odoo/enterprise#124367
Forward-Port-Of: odoo/enterprise#124126

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#123216
Forward-Port-Of: odoo/enterprise#117879

### Steps to reproduce:

- In the settings enable: "Storage Locations" and "Consignment"
- Create a storable product and put 1 unit in stock with a set owner
- Go to the barcode app > Operations > Delivery Orders > New
- Scan your product and validate
#### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit.

### Cause of the issue:

The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407
However, the option also make sense for none tracked products.

### Note:

Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330
Setting the same owner on the new move line as on the quant we are going to reserve:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715

Additional subtelties appearing when prefilling for non tracked product:

1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually
relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants.

2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line:
https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387
> This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned.

opw-6050657

Forward-Port-Of: odoo/enterprise#124017
Forward-Port-Of: odoo/enterprise#115021

Before this commit, _compute_l10n_be_computed_seniority looped over cp200_versions but still read self.employee_id and self.l10n_be_scale_seniority, so when Odoo batched multiple CP200 versions together, the whole recordset was passed to _get_first_version_date(), crashing with a singleton error.

After this commit, the loop correctly uses version.employee_id and version.l10n_be_scale_seniority instead.

Traceback (important part):

```py
    File "/home/odoo/src/enterprise/l10n_be_hr_payroll/models/hr_version.py", line 1508, 
  in _compute_l10n_be_computed_seniority                                                 
      company_seniority = relativedelta(fields.Date.today(),                             
  self.employee_id._get_first_version_date()).years                                      
                                                                                         
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                             
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 621, in             
  _get_first_version_date                                                                
      versions = self._get_last_consecutive_versions(date_limit)                         
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                         
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 595, in             
  _get_last_consecutive_versions                                                         
      self.ensure_one()                                                                  
    File "/home/odoo/src/odoo/odoo/orm/models.py", line 5406, in ensure_one              
      raise ValueError("Expected singleton: %s" % self)                                  
  ValueError: Expected singleton: hr.employee(30, 1)           
  ```

task-6377630

Forward-Port-Of: odoo/enterprise#123753

## Context

When generating a CFE (Comprobante Fiscal Electrónico) that contains both a configured addenda (e.g. bank account details stored in `l10n_uy_edi_addenda_ids`) and terms & conditions from the invoice's `narration` field, the resulting addenda string could end up with unnecessary blank lines between the two sections, causing the addenda to be rendered on a separate page even when the logical content fits within the 6-line threshold.

## Root Cause

`_l10n_uy_edi_get_addenda` joins both parts without stripping whitespace from either of them first, and adds two lines between addendas and terms and conditions:

         addenda = addenda + "\n\n" + term_and_conditions if addenda else term_and_conditions

Two sources independently introduce extra newlines around the separator:

1. **Addenda content** — `_get_legends` returns the raw `content`  field value of each addenda record. These fields commonly end  with a trailing `\n`, so the addenda string already ends with a newline before the `"\n"` separator is concatenated.
2. **`html2plaintext`** — the `narration` field is stored as HTML. When converted to plain text, `html2plaintext` typically wraps paragraph content in leading/trailing newlines.

The combination of the trailing `\n` from the addenda, the explicit `"\n\n"` separator, and the leading/trailing `\n` from `html2plaintext` produces 2–3 consecutive newlines, which `splitlines()` counts as blank lines. 
A realistic 4-line addenda + 1-line narration thus produces **7 lines** instead of the expected 5, crossing the 6-line threshold in `_get_report_params` and triggering `adenda=true` — which forces the addenda onto a separate page unnecessarily.

## Steps to Reproduce

1. Configure a `l10n_uy_edi.addenda` record of type `addenda` with multi-line content (4 lines)
2. Create and confirm an invoice with `narration` set to a short  single-line term 
3. Generate the CFE PDF via Uruware.
4. Observe that the addenda is rendered on a separate page despite the logical content being only 5 lines.

<img width="1042" height="448" alt="image" src="https://github.com/user-attachments/assets/b538211c-5f37-4648-979d-99cd75cf31c2" />


## Fix

Strip leading and trailing whitespace (including newlines) from both parts before joining them. The ternary is also replaced with an explicit `if/else` for clarity:

    def _l10n_uy_edi_get_addenda(self):
        addenda = self.l10n_uy_edi_document_id._get_legends("addenda", self)
        if self.narration:
            term_and_conditions = html2plaintext(self.narration).strip()
            if addenda:
                addenda = addenda.strip() + "\n" + term_and_conditions
            else:
                addenda = term_and_conditions
        return self._l10n_uy_edi_clean_non_ascii_chars(addenda)

This guarantees exactly one `\n` separator between sections regardless of how the content fields were stored or how `html2plaintext` formatted the narration.

The threshold logic in `_get_report_params` is unchanged: addendas that genuinely exceed 6 lines (after wrapping at 140 chars) continue to be printed on a dedicated page.

Result
<img width="1117" height="456" alt="image" src="https://github.com/user-attachments/assets/3a2d942c-8c37-40f6-bc25-470c0bd25b08" />

Forward-Port-Of: odoo/enterprise#119283

One of the major changes here is `pos_settle_due` in which is now only
possible to settle invoices and not pos order. That's because when
paying by customer account it will create an invoice each time.

### Removed fields
- `invoice_journal_id` and `pos_invoice_journal_id` because now all
invoice are created with the same journal, the one defined on the pos
config.

- `account_default_pos_receivable_account_id` because now the receivable
account is defined though a default partner on the pos.config

- `cash_real_transaction`, `cash_register_balance_start`,
`cash_register_balance_end_real and `cash_journal_id` all these infos
are now handled though the cash statement and its lines, so no need to
have them on the session

- `is_online_payment` because online payment method is now identified by
type == 'online' and not by a boolean field

- `settle_invoice_product_id`, `deposit_product_id` and
`settle_due_product_id` because we don't create a pos.order when
settling an invoice, so no need to have these products.

- `settled_invoice_id` and `settled_order_id` because we don't create a
pos.order when settling an invoice, so no need to link them anymore.

- `init_customer_due_total`, `customer_due_total`,
`settled_order_line_ids`, `settled_orders_count`, `commercial_partner_id`
because we don't settle pos.order anymore

### Test tracking
A lot of tests were replaced because all accounting entries for order
and session closing are now refactored.

Some tests were also removed because they were not relevant anymore with
the new way of handling payment and invoicing on pos.order.

#### Replaced tests
`test_classic_sale_order` replace:
- `test_state_when_closing_register`

`test_fifo_valuation_with_invoice` replace:
- `test_fifo_valuation_with_invoice_when_pos_customer_is_delivery_type`

`test_fixed_tax_negative_qty_should_be_negative` replace:
- `test_fixed_tax_negative_qty`
- `test_fixed_tax_positive_qty`

`test_user_right_on_statement_line_for_pos_user` replace:
- `test_pos_closing_cash_details`

`test_rounding_when_closing_session` replace:
- `test_invoice_rounding_overpaid_backend`
- `test_pos_create_account_move_round_globally`
- `test_rounding_method`

Moved in `test_pos_accounting.py`:
`test_journal_entries_category_without_account`
`test_tax_change_blocked_when_open_pos_session`
`test_order_partial_refund_rounding`

Test suite in `test_pos_accounting.py` replace:
- `test_pos_simple_invoiced_orders.py`
- `test_orders_no_invoiced`
- `test_orders_with_invoiced`
- `test_01_invoiced_order_from_other_customer`
- `test_02_all_orders_invoiced_mixed_customers`
- `test_total_due.py`
- `test_02_orders_without_invoice`
- `test_03_orders_with_invoice`

`test_invoice_a_negative_order_should_create_credit_note` replace:
- `test_manual_refund_negative_qty_invoice_creates_credit_note`

`test_invoice_an_order_from_closed_session` replace:
- `test_invoice_past_order_affecting_taxes`
- `test_invoice_past_refund`
- `test_invoice_past_order`
- `test_sale_order_postponed_invoicing`
- `test_order_invoiced_after_session_closed`
- `test_order_invoiced_customer_account_after_session_closed`
- `test_sale_order_postponed_invoicing`


`test_pos_order_sale_and_refund_with_taxes` replace:
- `test_orders_with_invoiced`
- `test_return_order`

`test_pos_order_sale_and_refund_with_taxes_invoiced` replace:
- `test_pos_create_correct_account_move`
- `test_return_order_invoiced`

`test_pos_order_sale_and_refund_with_taxes_not_invoiced` replace:
- `test_pos_create_correct_account_move`
- `test_return_order`

`test_invoiced_order_with_discount_sale_and_refund_with_tax` replace:
- `test_pos_create_correct_account_move_round_globally_discount`
- `test_pos_create_correct_account_move_round_globally_discount_real_use_case`


`test_tax_change_blocked_when_open_pos_session` replace:
- `test_tax_is_used_when_in_transactions`

`test_pos_payment_direction_and_account` replace:
- `test_pos_payment_direction_and_accounts`

`test_cash_statement_opening_and_closing_consistency` replace:
- `test_cash_register_if_no_order`
- `test_cash_payments_should_reflect_on_next_opening`

`test_invoicing_zero_amount_pos_order` replace:
- `test_orders_with_zero_valued_invoiced`

`test_order_partial_refund_rounding` replace:
- `test_refund_rounding_backend`
- `test_order_partial_refund`

`test_pos_config_with_other_currency_than_company` replace:
- `test_order_to_payment_currency`

`test_accounting_items_when_closing_with_bank_difference` replace:
- `test_payment_difference_accounting_items`
- `test_state_when_closing_register`

`test_pos_order_with_closing_storno` replace:
- `test_sale_order_postponed_invoicing_storno`

`test_various_orders` replace:
- `test_correct_partner_on_invoice_receivables`

`test_pos_order_session_closing_with_fp` replace:
- `test_01_no_invoice_fpos`
- `test_02_no_invoice_fpos_no_tax_dest`

`test_available_stock_order_no_invoice` replace:
- `test_orders_no_invoiced`
- `test_return_order`

`test_available_stock_order_with_invoice` replace:
- `test_orders_with_invoiced`
- `test_return_order`

`test_pos_order_with_company_branch` replace:
- `test_pos_branch_account`

#### Removed tests

`test_split_payment_linked_to_accounting_partner` split transaction is
now only available when using customer account (type == pay_layer)

`test_pos_hr_session_name_gap` removed not useful

`test_order_to_invoice_no_tax` not useful

`test_order_invoiced_customer_account_after_session_closed` not useful,
customer account payment are always invoiced but this test is almost
the same `test_invoice_an_order_from_closed_session`

`test_start_balance_with_two_pos` useless test, cash payment cannot be
shared.

`test_different_customer_invoices_settlement_same_session_reconciled_separately`
settling an invoice doesn't create `pos.order` anymore

`test_split_cash_payments` removed because split on customer account
is now available only when using `pay_later` payment method.

`test_receivable_account_reconciliation.py`, `test_pos_reconcile` no
more necessary, payment are now directly added to the account.move

`test_pos_settling_account_resets_on_payment_screen_unmount` removed
because now when leaving payment screen it will delete the order if its
a settling one.

`test_pos_settle_due_with_rounding` deleted, wtf we round on a money
deposit ?

`test_split_payment_linked_to_accounting_partner` split_transactions is
no more available with classic pm, only with pay_later.

`test_05_tax_base_amount` removed tax base amount are handled and tested
by accounting helpers

`test_no_kitchen_confirmation_for_deposit_money` removed because deposit
money doesn't create a pos.order anymore.

`test_order_with_deleted_tax` is now not possible to archive a tax used
by an open order.

`fastValidate` hoot deleted in pos_settle_due because isn't possible to
use fast validation with settle customer invoice anymore.

`test_double_syncing_same_order` removed, sync data with the same UUID
will update the same order, but since a payment_ids create command is in
the data, its normal that this payment is created two times.