Steps to reproduce:
-------------------
1. Install account_winbooks_import, and switch to a Belgian company
2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"
3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable")
4. Confirm the import

The import fails with:
"You must select a receivable account for 'Tax Receivable Account'."

Why the issue
-------------
In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade".

This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after.

However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import.

Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again.

The fix
-------
Add back the same bypass originally introduced in 20804db6d87.

opw-6092464

Forward-Port-Of: odoo/enterprise#115291

This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills.

This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common).

To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials

How to reproduce it:
- Install l10n_co_dian module
- On CO company with all required DIAN configuration set
- Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected.
- Click on acknowledge receipt, it should be rejected
- Complete information to be accepted and again click on acknowledge receipt
- A traceback appear

Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback

opw-6104541

Forward-Port-Of: odoo/enterprise#114758

### Issue:
When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly inflated, causing the sale to appear less profitable or even at a loss in the accounting records.

### Steps to reproduce:
1. Set a product as storable with FIFO costing and real-time valuation.
2. Create a Sale Order with two lines for the same product at different prices.
3. Confirm the SO and validate the two deliveries (each consumes a different FIFO layer).
4. Invoice the first SO line and post the invoice.
5. Invoice the second SO line and post the invoice.
6. Observe that the COGS on the second invoice is higher than the actual cost of the stock move linked to that line.

### Root Cause:
_get_cogs_qty() and _get_posted_cogs_value() in sale_stock filtered already-posted COGS lines by product_id. This caused them to aggregate quantities and values across ALL SO lines sharing the same product. However, _get_cogs_price_unit() derives the unit cost only from the current line's stock move. The mismatch results in:
  (unit_cost_of_line_2 * total_qty_of_both_lines) - cogs_already_posted

### Fix:
Replace the product_id filter with a sale-line-scoped filter using cogs_origin_id. By checking cogs_origin_id.sale_line_ids & sale_lines, only COGS originating from the same SO line(s) as the current invoice line are considered, correctly isolating each line's COGS from the others.

opw-6004810

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

Forward-Port-Of: odoo/odoo#257868

**Steps to reproduce**:
- Activate analytic accounting on the settings
- Create an Analytic distribution models for a partner
- Create a product P with a cost and Inventory Valuation set to Perpetual
- Create a location L with a Location Type set to Inventory Loss and a Loss Account
- Create an internal transfer from Stock to location L for product P
- Confirm it
- Check the associated journal entry:
-> The analytic distribution is not set of the move lines

**Cause**:
While validating the picking:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock/models/stock_picking.py#L1426 An account move is created without specifying `partner_id`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L178 https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L200-L205 This leads to the creation of account move lines, triggering `_inverse_analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1416-L1417 The method accesses `analytic_distribution` of the `move_line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1410 which triggers its associate compute method:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1213

To retrieve the right `analytic_distribution`:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1224 By defining this search domain:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L85

if `partner_id` is not in the `vals`, it falls back to False: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L79 As a result, the distribution linked to the `partner_id!` is not found, since the `partner_id` of the vals is determined from the `account.move.line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1237 which is False since it is not specified while creating the account move.

opw-5918058

Forward-Port-Of: odoo/odoo#261713

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115723
Forward-Port-Of: odoo/enterprise#114429

When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

Ticket [link](https://www.odoo.com/odoo/project.task/6148039)
opw-6148039

Forward-Port-Of: odoo/odoo#262339
Forward-Port-Of: odoo/odoo#261964