Implement the Belgian Registered Cash Register (Caisse Enregistreuse Certifiée) v2 specification as required by FPS Finance for certified POS restaurant systems.

The implementation is split into a core module and five bridge modules:

l10n_be_pos_blackbox (main module):
- FDM (Fiscal Data Module) communication layer that signs every fiscal
  event by sending a structured message to the blackbox device and
  receiving a hash + VSC counter in return.
  M110 (sale), M111 (refund), M112 (partial refund), M121 (order),
  M122 (cost-centre change), M123 (pre-bill), M130 (money in/out),
  M131 (drawer open), M140/M141 (work in/out), M150 (invoice),
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
- Input generator that encodes all line-level fiscal data (PLU hash,
  VAT groups, price rounding, grouping IDs) according to the spec.
- Fiscal receipt template (XML) that renders the blackbox hash,
  VSC counter, POS system identifier, and event sequence number on
  every printed receipt.
- X/Z daily report views with fiscal totals per VAT category.
- Training-mode support: activates the FDM training flag so the
  device does not count test transactions.
- Inspect popup (debug) for examining raw FDM messages.
- Error/warning popup system with traceback messages from the device.
- LocalStorage queue to replay pending mutations after a network
  outage.
- pos_config / pos_session overrides: enforce blackbox constraints
  (only EUR, no rounding, mandatory restaurant mode, etc.),
  manage device pairing, and accumulate per-session fiscal counters.
- Extensive unit-test suite: >6 000 lines covering the input
  generator's grouping-ID logic, price-consistency rules, and every
  mutation type against golden JSON fixtures.
- Browser tour tests (oracle + regression tours).

l10n_be_pos_blackbox_hr:
- Clock-in / clock-out flows for employees trigger M140/M141 work
  in/out mutations; employee INSZ/NISS number is required and stored
  on hr.employee; pos_session accumulates per-employee work records.

l10n_be_pos_blackbox_loyalty:
- Gift-card and discount reward lines are mapped to the correct MPV
  fiscal codes (UC260/UC261); loyalty products are flagged so the
  input generator can calculate their contribution to the signed
  total correctly.

l10n_be_pos_blackbox_self_order:
- Intercepts self-order confirmation on kiosk screens to sign the
  order with the FDM before the confirmation page is shown; adds a
  controller to expose the required blackbox data to the kiosk
  frontend.

l10n_be_pos_blackbox_settle_due:
- Handles the "settle due" payment flow: products used to represent
  deferred payments are flagged and treated as zero-VAT lines in the
  signed message.

l10n_be_pos_blackbox_urban_piper:
- Patches the Urban Piper ticket-screen and pos_store so that online
  orders routed through Urban Piper are also signed before finalisation.

task-id: 5864870

community PR: https://github.com/odoo/odoo/pull/229692

Forward-Port-Of: odoo/enterprise#96130

Refactor several POS core methods into overridable hooks so that
l10n_be_pos_blackbox (v2) can intercept and extend critical flows
to implement the new blackbox requirements.

point_of_sale:
- pos_store.js: extract posBackOnline(), openCashbox(),
  getSelfOrderToPrint(), and resetCashier() as dedicated methods;
  setCashier() now returns a boolean; preSyncAllOrders() now returns
  the orders array, and the sync loop skips an order when it returns
  falsy (allows blackbox to block premature syncing); add
  orderReceiptComponent class property so the receipt component can
  be substituted by submodules.
- order_payment_validation.js: extract canPrintReceipt getter (makes
  it overridable); fix absolute import path for error_handlers; fix
  typo "occured" → "occurred".
- pos_session.py: load product.template / product.product before
  account.tax in _load_pos_data_models to satisfy the blackbox data
  dependency order; include account_move id in the invoice list
  returned by the session sales-details report.

pos_hr:
- Split setCashier() into setCashier() + setCashierUpdateSession()
  so the session-update side-effect can be called independently by
  the blackbox during clock-in/out flows. Return true from
  setCashier() consistently with the base method.

pos_loyalty:
- Override displayPrice on order lines so gift-card trigger products
  always display a positive price, even when the order is a refund.

pos_restaurant:
- Refactor mergeOrders() into _mergeOrders() + _mergeLines() private
  helpers; add getLinesToMerge() hook so blackbox can filter which
  lines participate in a merge; mergeOrders() now returns the
  destination order; extract syncRestoredOrders() for overridability;
  replace the while-loop-with-guard-counter with a plain for-of loop.

pos_self_order:
- Add orderReceiptComponent property; extract
  handleKioskSessionStatusChange() so the kiosk status-change
  behaviour can be overridden by the blackbox self-order bridge.

task-id: 5864870

enterprise PR: https://github.com/odoo/enterprise/pull/96130




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

Forward-Port-Of: odoo/odoo#229692

Steps to reproduce:
-------------------
1. Install `sale_project_stock` and Accounting.
2. Create a storable product with **Real-time valuation** and 
configure the COGS account in the product category expense account.
(Ensure you have enabled automatic & analytic accounting from accounting>config.)
3. Create a project with a specific analytic account and ensure the project is billable.
4. Create a sale order with the created product and set the same
analytic account in the analytic distribution.
5. Confirm the order, deliver the product, generate the invoice, and post it.
6. Open the project and go to the *Profitability* report.
7. Click on the **Cost of Goods Sold** dashboard item.
8. Repeat steps 4–7 with multiple invoices.

Issue:
------
When there is only one invoice, clicking the COGS dashboard item correctly
displays the related move lines. However, when there are multiple invoices,
the action opens with empty results.

Cause:
------
`_get_action_for_profitability_section` sets `res_id` only when a single record exists. 
When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83

Solution:
---------
When `res_id` is not set, search `account.move` records using the
domain to retrieve the relevant move IDs, then apply a proper domain
to display all related COGS journal items.


opw-5949261



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

Forward-Port-Of: odoo/odoo#267097
Forward-Port-Of: odoo/odoo#253639

Currently, an error occurs when the user clicks on the translate button.

**Steps to Reproduce:**

 - Install the `CRM` module.
 - Go to `settings` and in `Languages` add 1 more language.
 - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`.
 - Click `New` and, in the `Name` field click the `translate button` on the right.

**Behavior in 18.0**

When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, 
the translation dialog shows the translated value on the second click.

**Behavior in saas-19.1**

`AssertionError: Invalid falsy real id`

Error:
After this [recent commit], when the user clicks on the translate button, if the record has a 
root record, the root record is saved before opening the translation dialog. However, in the 
case of an editable DynamicList view, the record does not have a root record so saving 
the record returns a promise instead of the resolved value [1].
Because of this promise, the condition fails [2], and the translation dialog is opened with a 
falsy ID since the record is not yet saved [3]. 
In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f).

This commit ensures that await is used so the resolved value is returned after the record is 
saved before opening the translation dialog.

[recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be

[1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23

[2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26

[3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41

sentry-7384270487

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

Forward-Port-Of: odoo/odoo#267914

### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number

While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice

DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check

Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>SETP990001021</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432

### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number

opw-6164321

Forward-Port-Of: odoo/enterprise#118319

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692

Forward-Port-Of: odoo/odoo#268269
Forward-Port-Of: odoo/odoo#265352

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Forward-Port-Of: odoo/enterprise#117725

[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
-  Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
  (e.g. `8426904171073`).
- Select the product and trigger the server action:
  `Action -> Get Pictures from Barcode Lookup`

Issue:

**During image fetching:**

-  Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
-  `_get_image_from_url()` assumes the response is always a `requests.Response`
   object and directly accesses:  `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`

**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
     - `requests.Response` for successful requests
     - `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
   response attributes.

**Solution:**
- Make barcode_lookup_request() always return a One Response
  object.
- Move the response validation to the callers instead of returning custom
  dict objects.

**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.

**OPW-6200749**

Forward-Port-Of: odoo/enterprise#116925

## Steps to reproduce:
- Install the `quality_mrp` module.
- Create a new product.
- Create a Quality Point with: 
  Type: Measure,
  Control per: Product/Operation
  Operations: Manufacturing
- Create and confirm MO for the product.
- Update the Quality Point: 
  Remove the 'manufacturing' operation type and add 'receipts' type. 
  Change Control per to 'Quantity'.
- Open the MO and start a quality check.
- Enter an invalid measure and try to validate it.

## Error:
`AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'`

## Cause:
Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error.

## Fix:
This commit uses the first lot/serial from the MO.
Note: Multiple produced lots are only possible for serial-tracked products.

sentry-7511513479

Forward-Port-Of: odoo/enterprise#119231

Currently, an error occurs when user tries to select a property field in auto field.

Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.

Error:
- saas-18.3 and later:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
    field = records._fields[field_name]
            ^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```

- saas-18.2:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
    if len(records) > PREFETCH_MAX:
       ^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```

Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.

- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.

Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.

[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41

sentry-7378769090

Forward-Port-Of: odoo/enterprise#113091

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#267869
Forward-Port-Of: odoo/odoo#264272

Currently, it's possible to experience very slow loading speed of the partner list and/or browser crashes in the POS when there are thousands of customers stored in the browser cache.

This appears to be caused by a few reasons compounding together:

1. While we limit the number of customers in the initial render of the list, there is no limit during the search. Therefore, if there are thousands of customers matching the search pattern loaded in the browser cache, the browser will attempt to render equally as many `PartnerLine` components.
2. A 100 ms debounce time is fast enough to trigger the render after each key stroke. 200~300ms is the industry standard for Software UI debounce.
3. For each customer rendered in the list, we may perform a search for its parent partner amongst all loaded customers with the function `PosStore.getPartnerCredit()`.

This PR aims at reducing the number of partner lines rendered in a short period of time and thus, at improving speed and avoiding crashes.

Steps to reproduce:
1. Create a fresh db + install the point_of_sale with demo data
2. Populate the res.partner model by a factor of 100 to reach 4000+ partners
3. Update the following system parameter to make sure that we load all partners in the browser cache when we open the POS session:
    - `point_of_sale.limited_customer_count` -> 5000
4. Open a POS session and and click on the `Customer` button to render the partner list
5. Type `adm` in the search bar at normal typing speed
6. Crash

Ticket: opw-5435973

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

Forward-Port-Of: odoo/odoo#258667

### [FIX] website: prevent inserting block snippet with powerbox in inlines

Inserting block snippet with powerbox when the selection is inside an editable part limited to an element that can only contain inline nodes leads to invalid html (like `<div>` inside `<span>`).

This commit disables insertion of block snippets when the selection is such a part of the document.

Steps to reproduce:
- Open website builder
- Put cursor in "copyright" at the bottom of the footer
- Type `/alert` and press enter
- Bug: `<div>` element is inserted inside `<span>`, that is invalid html

task-6259092

### [FIX] website: prevent unwrapping `s_blockquote` on insert with powerbox

When the snippet `s_blockquote` was inserted with the powerbox or pasted from clipboard in an unbreakable element which does not allow blocks as children, the `<blockquote>` element itself was abandonned and its children were inserted instead. This lead to insertion of a broken snippet.

This commit marks the `s_blockquote` snippet as "unsplittable" so that always stays in one piece when inserted.

Steps to reproduce:
- Open website builder
- Put cursor in a link
- Type `/blockquote` and press enter
- Bug: the snippet's children are inserted, instead of snippet itself

task-6259092

Forward-Port-Of: odoo/odoo#267111

**Steps to reproduce:**
- Install eLearning app with gamification
- Go to Settings > Gamification Tools > Challenges
- Set a challenge with multiple participants (portals / internals)
- Set its state to Done
- Notification email is sent to every participants
- They can see each other in the mail header
(portal user can see all other portal users, internal user can see all portal users)

**Issue:**
Since [1] external recipients are added in the mail header, but this is not adequate for every flows
(here there is no need for the participants to be aware of each other).

**Fix:**
In [2] this issue was mitigated by removing the `'X-Msg-To-Add'` from the header for models which don't need it.
Then in [3] the solution was replaced by a more generic approach using `_CUSTOMER_HEADERS_LIMIT_COUNT = 0`.

[1] https://github.com/odoo/odoo/commit/42aaaef59d21558438c767c6dd8a21674e5df9df
[2] https://github.com/odoo/odoo/commit/e6c13ce4436b3c8b3a2058d2ccf65a7da1b256b2
[3] https://github.com/odoo/odoo/commit/c4dbd868b9c7e26f11db4d2cacef7ffce6c87082

opw-6099745

Forward-Port-Of: odoo/odoo#267192

# How to reproduce
- Install the Accounting module
- In the settings, enable "Sales Credit Limit"
- Remove the Accounting access rights of the current user
- Try to create a new user

# The issue
An access error is raised on the field `credit_limit`

# Cause
Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518

When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users`  inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error.

# Proposed solution
Back port of this commit : https://github.com/odoo/odoo/pull/267193

Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150

opw-6240494

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

Forward-Port-Of: odoo/odoo#268303
Forward-Port-Of: odoo/odoo#268039