## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#264777
Forward-Port-Of: odoo/odoo#263792

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

Backport of 7c68c3dbb29eaad4e09d59ef7c86bd525969caec Including its fix: e490c0c66561715853a3f80658f47c940bc453dc

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO, amnufactured product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
#### > There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 0
#### > The delivery is cancelled but no activity is logged what's so ever

### Expected behavior:

Both of these operations should log an activity as the demand of the MO is not updated on quantity decrease.

opw-6010109
opw-6105366
opw-6100043
opw-6087909

X-original-commit: 796316c341c4346152ad9610c30679f47aaa2ff8

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

Forward-Port-Of: odoo/odoo#264732
Forward-Port-Of: odoo/odoo#258093

this pr fixes 3 bug, as all are closely related.

  Step to reproduce (hide is_custom attr in kiosk mode):
  - have two attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B can have any two value ( ex. gender: male/female)
  - use it on a product  and make it available in POS for kiosk
  - start kiosk and open that product

  Observation:
  - we do not get option to select option from A but the heading is visible
  - when we select from B, Add to cart is disabled.

  Cause:
  - we do not allow attribute values with is_custom = True in kiosk
  - but we display the attribute regardless
  - the Add to cart btn depends on `selectedValues`, which requires
  value from each attribute, in this case, we are not seletion anything from A
  - so it is disabled

  Fix:
  - we introduced  `attributesToDisplay` which will hide heading in case of single
  custom value for any attribute
  - for Add to cart, wenow do not expect value from `is_custom`  attribute values.

   Allow product with 1 attr which is `is_custom` to be
   configurable in configs other than kiosk) correct fix for commit

   Step to reproduce
  - have attributes A
  - A has only 1 attribute value with is_custom = True
  - use it on a product and make it available in POS
  - start pos and open that product

  Observation:
  - we do not get option to select add text for A

  Cause:
  - in pos, we consider product to be configurable only it has more than 1
  attributes, which misses is_custom attr

  Fix:
  - we backport commit[1] and also considers its side effect by introducing
  `isProductConfigurable` for pos_self_order, which will still avoid
  `is_custom` attrs for kiosk

  [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7

  Empty page is displayed if product has only `is_custom` attribute value
  and other attribute with type other then 'no_variant' for combo item

   Step to reproduce
  - have attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B has two values with type "always"
  - use it on a product and add that product in combo item and make it available
    in Kisok
  - start kiosk and open that combo and select that product

 Observation:
- we do not get option to select

Cause:
- `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
   values in attributeSelection component.

Fix:
- before mounting Attributeselection component, we check if product has required
  attribute or not.

opw-6100965

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

Forward-Port-Of: odoo/odoo#264402
Forward-Port-Of: odoo/odoo#257880

**Steps to reproduce:**
- On a new company, activate automatic valuation and anglo-saxon accounting.
- Create a new product, and set the cost to 5.
- On the product category, set the costing method to AVCO and the valuation to automatic.
- Create a Purchase Order for the product, confirm it and recieve it, but don't create a Bill yet.
- Create a sales order with the same quantity as the purchase order, and deliver it.
- Now create a bill for the original Purchase Order, and change the price to 6.
- Manually change the total tax amount on the Bill, and then post it.

**Issue:**
After posting the Bill, the value set manually on the total tax is recomputed and overwritten.
This is because the price difference between the bill and the original cost creates two new price difference lines on the bill, and this triggers the move sync to recompute the tax.

**Solution:**
Set the context `skip_invoice_sync` to True when creating the price difference lines.

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

Forward-Port-Of: odoo/odoo#263391
Forward-Port-Of: odoo/odoo#259331

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#116944
Forward-Port-Of: odoo/enterprise#115085

**Steps to reproduce**
1. Create a company with a branch.
2. Create account journals for both the parent and branch companies.
3. Create an employee in the branch company and assign a salary structure to the employee. Also, make sure the employee’s contract is started.
4. Create a pay run for this employee while staying in the parent company.
5. Generate and validate the payslip.
6. Check that the `move_id` (draft journal entry) is created for the employee’s company, not the currently selected company.

**Issue:**
When an employee belongs to a branch company and we create a pay-run/payslip for that employee, the draft journal entry is created using the default company.

**Fix:**
Since `journal_id` is a company-dependent field, we will use `slip.struct_id.with_company(slip.company_id).journal_id`. This ensures that we will pass correct slip's `journal_id` to `_create_account_move()`.

After that `_compute_company_id()` in `account_move.py` will be executed, and the `move_id` will have the correct `company_id`. Ref [code](https://github.com/odoo/odoo/blob/1839e68cad91f6b16865f6ac365500ab6fbda835/addons/account/models/account_move.py#L889-L896)
Hence, the issue will be fixed.

task: 6123216

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#116639
Forward-Port-Of: odoo/enterprise#111304

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#116670
Forward-Port-Of: odoo/enterprise#115285

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

Forward-Port-Of: odoo/enterprise#117414

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#115760