Problem
------------------
When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce:
1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day)
2. From the allocations view -> New Group Allocation
3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off
4. Go to the newly created allocation The allocation amount is 0.

Reason
----------------------
When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed.

Solution
------------------
Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations.

task-4938695

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

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

__

## Short functional explanation of the error
When confirming a Purchase Order holding lines with an analytic distribution that has been manually added, and creating a vendor bill out of this PO using the Auto-Complete field. When we change the account of that line, the line loses the manually added Analytic Distribution.

## Reproduction Steps
1. Go to Accounting. Click on the tab Configuration; under the Analytic Accounting section, click on Analytic Distribution Models.
2. Create an Analytic Distribution Model for a product.
3. Go to Purchase. Create a new PO, set a Vendor and select the product you created the Analytic Distribution Model for. On the right side of the form, click on the view menu and check Analytic Distribution to make it appear.
4. Click on the Analytic Distribution of the product and add a new one; for example, select Administrative in the Departments section.
5. Confirm order.
6. Go to Accounting and click on the Vendors tab > Bills. Create a new bill, and in the field Auto-Complete, select the PO you just created.
7. Change the account of the line.

### Expected behavior
Only the account should be changed on the line.

### Unexpected behavior
The manually added Analytic Distribution has disappeared.

## Origin of the issue
When we change the `account_id` field, the compute method `_compute_analytic_distribution` is triggered. This method retrieves the related distributions of the line:
https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/account/models/account_move_line.py#L1154 which, in the context of Purchase, calls this method: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/purchase/models/account_invoice.py#L540-L545 We retrieve the distribution of the related line using `self.purchase_line_id.analytic_distribution`. However, this code isn't triggered when the move line has an analytic distribution, even though the related line `purchase_line_id` might have one! Therefore, we need to execute that code whether or not our move line has an analytic distribution.
Note: the same behavior is to avoid when creating invoices for
quotations.
__
opw-6062466

**Steps to reproduce**
1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`.
2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice.
3. Generate the FA(3) XML.

**Issue**
`P_6` is omitted from the payload even though the delivery date differs from the invoice issue date.

The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at
https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped.

Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires.

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

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

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

Forward-Port-Of: odoo/odoo#266374