Steps to Reproduce:
--------------------
- Install the l10n_es_pos module in version 18.0.
- Navigate to Contacts.
- Search for Simplified Invoice Partner (ES) and archive the record.
- Open the Point of Sale (POS) and proceed to place an order.
- Select a product.
- Proceed to the payment screen.
- Choose a payment method and click Validate.

Issue:
---------------------
In version 18.0, when the user proceeds with placing an order, a blank screen appears without any error message,
leading to confusion for the customer.

This issue occurs because during the [pos_load_data](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/models/pos_session.py#L181) process,  while preparing the pos.config, the `simplified_partner_id` is fetched. However, the corresponding `res.partner` record is not included during the preparation of the `res.partner` model data, as the record is archived. As a result, when the system attempts to link the related partner record to `pos.config.simplified_partner_id` on the [JavaScript side](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1063-L1131 ), [ref](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1114)
 the simplified_partner_id remains undefined. This eventually leads to an error when attempting to access [simplified_partner_id.id](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/l10n_es_pos/static/src/overrides/models/pos_store.js#L8)  and will lead to the blanck screen

video ref: https://drive.google.com/file/d/1oG6bBIWxhlvnJAgj22hEVtlW0hr8_1eU/view?usp=sharing
```text
Other Approaches:
- We can override the _load_pos_data method and append the simplified partner to ensure it's included during the data loading process.
- Instead of showing a blank screen, we can display an alert message informing the customer to unarchive the simplified partner and proceed with the flow.
`I’m open to any suggestions or alternative approaches that would be the best way to handle this.`
```

OPW: 4953896

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

**FIX - 1 : rectify default account on tax line**
Before this **PR**:

The Withholding Tax (WTH) base account, if set on the company, was being used as the default account. This account overrode the expected behavior and was applied not just to the base and counterpart lines, but also to the tax line, when the tax repartition line had no account defined.

After this **PR**:

If the tax repartition line has no account set, the system now uses the account from the invoice line (typically an income or expense account) instead of the WTH base account. Additionally, in cases where withholding is added directly on a payment or payment registration, a constraint has been added on the tax_id field in account_withholding_line to prevent users from selecting a tax that lacks an account on its repartition line.

**Technical background**:
Previously, when a WTH base account was available, it was used in the creation of withholding lines. These lines, created during payment processing via _prepare_withholding_amls_create_values, inherited the WTH base account on the base line. Later, _add_accounting_data_in_base_lines_tax_details used this base account for tax line creation if the tax lacked its own repartition line account, resulting in incorrect account assignment.

**Solution**:
Always use the invoice line’s account (e.g., income/expense) when creating withholding lines. This ensures that the tax lines use the appropriate account. If a WTH base account is configured, it will only be applied to the base and base counterpart lines, not the tax lines in the
_prepare_withholding_amls_create_values.

**FIX - 2 : rectify domain on tax_id**
With this commit, the domain for account_id in the account_withholding_line model correctly includes group taxes that contain at least one withholding tax.

**task**-4883286

Steps to reproduce
===================
1. Insert any list view in the knowledge article.
2. Click on open view from the article.
3. Come back and click edit.
-> Traceback occurs

Technical
=============
When we open a view from an embedded view in the article, we add `orderBy` from the
action context to the action props if it exists. As the action prop is initialized
and assigned directly from `embeddedState.additionalViewProps` without copying, it
mutates the original object, changing the `data-embedded-props` attribute in the DOM
and marking the body of the article as unsaved from `StateManager.changeState`. The
action continues, and the action service commits those unsaved changes to the article.

Once it is saved and the action is executed, when we get back to the article and
click on edit, we check for `additionalViewProps` to be undefined/empty for all
other views except calendar. As the DOM already has saved data in attributes, we
get `orderBy` in `additionalViewProps`, and thus a manual error is thrown in the
`editView` function.

After this commit
===============
Clone `additionalViewProps` when preparing the view action props.

Task-4921282

In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines.

In POS, however, there is the possibility of generating journal entries that break this flow:

- In a single POS session, add product A with tax 19% and product B with tax 7%.
- In the same session, refund product A.
- Close the session to generate the entries.

In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated.

Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272)
opw-4915272

Forward-Port-Of: odoo/enterprise#92664